A backup strategy is more than simply taking a backup of a database and storing it somewhere so it can be fetched and loaded when trouble strikes.
You must be able to get your database back, verified, and online within an expected timeframe. These are the important aspects of a backup strategy.
We cannot stress enough that the requirements outlined in the
It is most important that you verify all data that has been moved. Backed up files or restored files that were corrupted by hardware while they were being written are useless. A cable fault can corrupt data blocks being written to disk.
Knowing how long it takes to backup and verify the database, to restore and verify the database, to restore and verify transaction journals and to perform recovery is also important.
A backup strategy has four components:
Backing up the database
This involves making available verified copies of the database files and transaction journals. Available means accessible for use in getting your database online. Your requirements determine the forms and frequencies of the backups. They may be offline backups, online backups (or a mix of the two), or you may elect to implement a warm standby server or a Synchronized Database Environment (SDE), which would be immediately available. For details about SDE, see the
Restoring the database
This involves loading and verifying the database files and transaction journals so that a recovery can be performed. The number and size of your transaction journals is governed by your determination of how much database update activity you can afford to lose.
In warm standby server and SDE implementations, the database is already resident and ready for recovery once any additional transaction journals are made available and verified. (Additional journal loading is unnecessary on SDS secondaries processing in journal block write mode.)
Recovering the database
This involves activating the database to perform roll‑forward recovery through the transaction journals. This is a continuous state for warm standby server and SDS secondary implementations where takeover operations can be performed. The failure mode might be such that the transaction journal that was current is not retrievable. In this case, that journal contained the database update activity that you have lost.
Proving the strategy
This involves initial and periodic failure drills with critical post‑mortem analysis. You must prove the integrity of the strategy by picking a failure mode, dropping the database, and announcing to your team that the database has become unusable. You must prove that every step of your strategy is appropriate, executable, and produces the desired outcome in the expected timeframe.
These periodic catastrophes highlight any flaws in your processes and enable you to confirm your ability to meet the established critical timeframe for ‘getting back online’.