Databases Reference
In-Depth Information
Testing
One of the easiest ways to test on realistic data is to periodically refresh a test server
with the latest production data. If you're making backups, it's easy; just restore the
backup to the test server.
Check your assumptions. For example, do you assume your shared hosting provider is
backing up the MySQL server provided with your account? Many hosting providers
don't back up MySQL servers all, and others just do a file copy while the server is
running, which probably creates a corrupt backup that's useless.
Defining Recovery Requirements
If all goes well, you'll never need to think about recovery. But when you do, the best
backup system in the world won't help. Instead, you'll need a great recovery system.
Unfortunately, it's easier to make your backup systems work smoothly than it is to
build good recovery processes and tools. Here's why:
• Backups come first. You can't recover unless you've first backed up, so your at-
tention naturally focuses on backups when building a system.
• Backups are automated with scripts and jobs. It's easy to spend time fine-tuning
the backup process, often without thinking of it. Five-minute tweaks to your
backup process might not seem important, but are you applying the same attention
to recovery, day in and day out?
• Backups are routine, but recovery is usually a crisis situation.
• Security gets in the way. If you're doing offsite backups, you're probably encrypting
the backup data or taking other measures to protect it. You know how damaging
it would be for your data to be compromised, but how damaging is it when nobody
can unlock your encrypted volume to recover your data, or when you need to
extract a single file from a monolithic encrypted file?
• One person can plan, design, and implement backups. That person might not be
available when disaster strikes. You need to train several people and plan for cov-
erage, so you're not asking an unqualified person to recover your data.
Here's an example we've seen in the real world: a customer reported that backups
became lightning fast when the
-d
option was added to
mysqldump
, and wanted to
know why no one had mentioned how much that option could speed up the backup
process. If this customer had tried to restore the backups, it would have been hard to
miss the reason: the
-d
option dumps no data! The customer was focused on backups,
not recovery, and was therefore completely unaware of this problem.
There are two Big Important Requirements that are helpful to consider when you're
planning your backup and recovery strategy. These are the recovery point objective
(RPO) and the recovery time objective (RTO). They define how much data you're
