Moving or restoring a user database
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.
|
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.
-