<commit_before>---
description: High-level overview of disaster recovery options for the PSaaS Appliance
section: appliance
topics:
    - appliance
    - disaster-recovery
contentType: concept
useCase: appliance
applianceId: appliance56
---

# PSaaS Appliance: Disaster Recovery

When preparing for the possibility of issues with your PSaaS Appliance instances, your options depend on your tolerance for downtime. Below, you will find a discussion of the advantages and disadvantages associated with the various disaster recovery (DR) options available.

Additionally, there is a difference between PSaaS Appliance availability and data availability/recovery. For example, the standard three-node cluster deployment has high availability and can survive a single-node failing. However, in cases of a data center failure or a logical data corruption, you would need a disaster recovery solution to help recover from that.

In cases where the data centers have very low latency, you can run individual PSaaS Appliance instances using three different data centers. For example, if you are using AWS, you can run each of your nodes in a different availability zone (though this may incur a higher service cost).

## Geographic High-Availability PSaaS Appliance Implementation

If your requirements demand regional resilience with little downtime, we recommend a [Geographic High-Availability PSaaS Appliance](/appliance/geo-ha) implementation. This is the only implementation that has automatic failover between data centers.

Issue detection and failover typically occur at the database level in 30 seconds or less. However, switching over and rerouting traffic from one datacenter to another is an expensive operation, so we've configured the infrastructure to detect false positives and *not* switch over in the event that one occurs. This secondary detection process reroutes client traffic through failure detection time-out mechanisms that result in an *effective* failover time of approximately ten minutes.

**Advantages**:

Geo-HA is an PSaaS Appliance implementation that provides:
* Data center redundancy;
* Automatic failure handling;
* The highest form of PSaaS Appliance availability offered by Auth0.

**Disadvantages**:

Geo-HA involves:
* A higher cost due to increased complexity;
* Additional PSaaS Appliance Virtual Machines (VM) that need maintenance;
* An additional layer in front of the load balancer for GEO failover, such as F5 Global Traffic Manager or AWS Route 53;
* Additional configuration to handle logical corruption, since this is not a scenario that is covered by the typical setup.

For more information, please see:
* [Geo HA](/appliance/geo-ha)
* [Disaster Recovery](/appliance/geo-ha/disaster-recovery)

## VM Snapshots
If you have some tolerance for downtime (either in terms of minutes or hours), you can consider using the Virtual Machine (VM) snapshot approach. A VM snapshot contains everything you need to rebuild an PSaaS Appliance. You would be responsible for regularly taking VM snapshots and either storing them either offsite or replicating them to other regions in the cloud.

**Advantages**:
* Recovery via VM snapshots is faster than using database backups (though the process is slower than GEO-HA).
* You may not need manual intervention from an Auth0 Customer Success Engineer (CSE) to restore your cluster.

**Disadvantages**:
* VM snapshots can become very large in size (snapshots are not compressed, and you would need a snapshot of each VM/drive), which makes storage tricky.
* The backup and recovery process requires manual intervention.

### Basic Steps for Recovering with VM Snapshots

The following outlines the basic steps required for restoring your PSaaS Appliance instances using VM snapshots:<commit_msg>[edit]: removed additional verbiage per dseveso<commit_after>---
description: High-level overview of disaster recovery options for the PSaaS Appliance
section: appliance
topics:
    - appliance
    - disaster-recovery
contentType: concept
useCase: appliance
applianceId: appliance56
---

# PSaaS Appliance: Disaster Recovery

When preparing for the possibility of issues with your PSaaS Appliance instances, your options depend on your tolerance for downtime. Below, you will find a discussion of the advantages and disadvantages associated with the various disaster recovery (DR) options available.

Additionally, there is a difference between PSaaS Appliance availability and data availability/recovery. For example, the standard three-node cluster deployment has high availability and can survive a single-node failing. However, in cases of a data center failure or a logical data corruption, you would need a disaster recovery solution to help recover from that.

In cases where the data centers have very low latency, you can run individual PSaaS Appliance instances using three different data centers. For example, if you are using AWS, you can run each of your nodes in a different availability zone (though this may incur a higher service cost).

## Geographic High-Availability PSaaS Appliance Implementation

If your requirements demand regional resilience with little downtime, we recommend a [Geographic High-Availability PSaaS Appliance](/appliance/geo-ha) implementation. This is the only implementation that has automatic failover between data centers.

Issue detection and failover typically occur at the database level in 30 seconds or less. However, switching over and rerouting traffic from one datacenter to another is an expensive operation, so we've configured the infrastructure to detect false positives and *not* switch over in the event that one occurs. This secondary detection process reroutes client traffic through failure detection time-out mechanisms that result in an *effective* failover time of approximately ten minutes.

**Advantages**:

Geo-HA is an PSaaS Appliance implementation that provides:
* Data center redundancy;
* Automatic failure handling;
* The highest form of PSaaS Appliance availability offered by Auth0.

**Disadvantages**:

Geo-HA involves:
* A higher cost due to increased complexity;
* Additional PSaaS Appliance Virtual Machines (VM) that need maintenance;
* An additional layer in front of the load balancer for GEO failover, such as F5 Global Traffic Manager or AWS Route 53;
* Additional configuration to handle logical corruption.

For more information, please see:
* [Geo HA](/appliance/geo-ha)
* [Disaster Recovery](/appliance/geo-ha/disaster-recovery)

## VM Snapshots
If you have some tolerance for downtime (either in terms of minutes or hours), you can consider using the Virtual Machine (VM) snapshot approach. A VM snapshot contains everything you need to rebuild an PSaaS Appliance. You would be responsible for regularly taking VM snapshots and either storing them either offsite or replicating them to other regions in the cloud.

**Advantages**:
* Recovery via VM snapshots is faster than using database backups (though the process is slower than GEO-HA).
* You may not need manual intervention from an Auth0 Customer Success Engineer (CSE) to restore your cluster.

**Disadvantages**:
* VM snapshots can become very large in size (snapshots are not compressed, and you would need a snapshot of each VM/drive), which makes storage tricky.
* The backup and recovery process requires manual intervention.

### Basic Steps for Recovering with VM Snapshots

The following outlines the basic steps required for restoring your PSaaS Appliance instances using VM snapshots:
{'fraction_non_alphanumeric': 0.04364604125083167, 'fraction_numerical': 0.0023952095808383233, 'mean_word_length': 5.105605199025183, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6256809', 'n_tokens_mistral': 1801, 'n_tokens_neox': 1681, 'n_words': 1037}