Part of any disaster recovery involves the restoration of the user database from one server to another.
You should have a well-defined backup plan that takes into account whether or not your data is replicated among a set of servers. A plan is the best insurance against significant downtime or data loss in the event of an unrecoverable database issue.
Note:
The server root directory should never be restored from a file system backup or snapshot. External backup methods, such as virtual machine (VM) snapshots, are not recommended, especially if data was corrupted during a transaction.
Keep in mind the following general points about database recovery:
- Regular backup from local replicated PingDirectory server
- Take a backup from a local replicated PingDirectory server and restore to the failed server. This is more recent than any other backup you have.
- Restore the most recent backup
- Restore the most recent backup from a local server. In some cases, this might be preferred over taking a new backup if that would adversely impact performance of the server being backed up although it takes longer for replication to play back changes.
- Contact support
- If all else fails, contact your authorized support provider and they can work with you, and possibly in cooperation with the Oracle Berkeley DB JE engineers, to try a low-level recovery, including tools that attempt to salvage whatever data they can obtain from the database.
- Using VM snapshots
- Although VM snapshots are not recommended for disaster recovery, remember the
following in case you must use them:
- Snapshotting the VM should never result in a corrupted PingDirectory server.
- Shutting down the DB before snapshotting is only recommended for speeding up recovery time.