Backup and Restore Data in DR Cluster

For details about how to configure backup and restore the data in DR clusters, see Back up and Restore System Data. You can configure either the Full Backup or Incremental Backup mode. However, the Incremental Backup mode is the recommended to ensure that there is no or minimum data loss, if any.

Limitation

Certificate synchronization is not supported on DR-enabled clusters in the backup and restore workflow. Certificate must be manually uploaded for each cluster. For more information, see Manage Certificates.

Handling Certificate Expiry in Secondary Cluster

When the certificate expires in the Datacenter Redundancy (DR) secondary cluster, the restore operation fails due to inconsistencies in the database, preventing data synchronization between primary and secondary clusters.

An audit trail notification is generated on the Analyze > Audit Trail page indicating the failure due to certificate expiry. For more information, see Viewing Audit Trail Logs.

Figure 1 Audit Trail—Certificate Expiry

To resolve, complete the following specific recovery procedure:

Disable the redundancy configuration between the clusters.

For more information, see Disabling Redundancy.
After disabling, first apply the default certificate to the secondary cluster.
Next, apply the root CA Certificate Authority or Certification Authority. Entity in a public key infrastructure system that issues certificates to clients. A certificate signing request received by the CA is converted into a certificate when the CA adds a signature generated with a private key. See digital certificate. .
Lastly, apply the server certificate.
Re-enable the redundancy configuration between the clusters.

This successfully restores the backup operation on both primary and secondary clusters.

Data Synchronization in DR Cluster

The following examples are regarding data synchronization in a DR cluster, particularly focusing on the full backup type. These scenarios aid in setting appropriate restore frequencies to ensure minimal data loss and successful data synchronization.

Recommendations:

For DR clusters, the incremental backup is recommended because there is minimal to no data loss for this method.
If full backup type is configured for Weekly frequency, then set the Restore Frequency (Days) to a value lower than 7 days to avoid data loss.

Failover Checkpoints:

If the Data Sync status is displayed as Failed, then failover is not allowed. This is to avoid any data corruption.
After a failover, the new primary comes up with the data available from the last data sync time.
If the Data Sync status is displayed as Not Started, it indicates that there is no data synchronization.

Scenario 1

Occurrence—Every Day
Backup Day—Monday
Restore Frequency—3 Days

Day	Backup Type	Restore	Data Sync Time	Data Sync Status
Monday	Full Backup	Restore	1 January 2025	Successful
Tuesday—Thursday	Full Backup	No restore, frequency not elapsed	1 January 2025	Successful
Friday	Full Backup	Restore	5 January 2025	Successful

Though there was no restore operation performed from Tuesday to Thursday (Restore Frequency is set as 3 Days), the Data Sync Status is displayed as Successful, because it is based on the latest Data Sync Time that is 1 January 2025 in this example.

Scenario 2

Occurrence—Weekly (7 Days)
Backup Day—Monday
Restore Frequency—3 Days

Day	Backup Type	Restore	Data Sync Time	Data Sync Status
Monday	Full Backup	Restore	1 January 2025	Successful
Tuesday to Sunday	No Backup	No restore	1 January 2025	Successful
Monday	Full Backup	Restore	8 January 2025	Successful

Though there was no restore operation performed from Tuesday to Sunday (Restore Frequency is set as 3 Days), the Data Sync Status is displayed as Successful, because it is based on the latest Data Sync Time that is 1 January 2025 in this example.

Scenario 3

Occurrence—Weekly (7 Days)
Backup Day—Monday
Restore Frequency—7 Days

Day	Backup Type	Restore	Data Sync Time	Data Sync Status
Monday	Full Backup	Restore	1 January 2025	Successful
Tuesday to Sunday	No Backup	No restore	1 January 2025	Successful
Monday	Full Backup	No restore, frequency not elapsed	1 January 2025	Successful
Tuesday to Sunday	No Backup	No restore	1 January 2025	Successful
Monday	Full Backup	Restore	15 January 2025	Successful

Though there was no restore operation performed from Tuesday to Sunday (Restore Frequency is set as 7 Days), the Data Sync Status is displayed as Successful, because it is based on the latest Data Sync Time that is 1 January 2025 in this example.
Also, though the Restore Frequency is set as 7 Days, there was no restore operation on Monday because the frequency was not elapsed after the previous data sync and an overlap of the next backup operation.