Best practices for disaster recovery
To protect your database from site failures caused by catastrophic disasters, maintain an off-site replica of your database to provide a standby. In case of disaster, you can switch database users over to the standby database. The amount of data loss between a disaster and fail over to the offsite replica depends on how frequently you save a full database backup.
The solution to employ for disaster recover depends upon two factors that you must determine for your application:
-
Recovery point objective (RPO): How much data loss can your organization tolerate upon a disaster recovery?
-
Recovery time objective (RTO): How quickly do you need to recover the database following a disaster?
Depending on your RPO and RTO, Vertica recommends choosing from the following solutions:
-
Dual-load: During each load process for the database, simultaneously load a second database. You can achieve this easily with off-the-shelf ETL software.
-
Periodic Incremental Backups: Use the procedure described in Copying the database to another cluster to periodically copy the data to the target database. Remember that the script copies only files that have changed.
-
Replication solutions provided by Storage Vendors: Although some users have had success with SAN storage, the number of vendors and possible configurations prevent Vertica from providing support for SANs.
The following table summarizes the RPO, RTO, and the pros and cons of each approach:
| Dual Load | Periodic Incremental | Storage Replication | |
|---|---|---|---|
| RPO | Up to the minute data | Up to the last backup | Recover to the minute |
| RTO | Available at all times | Available except when backup in progress | Available at all times |
| Pros |
|
|
Transparent to the database |
| Cons |
|
Need identical standby system |
|