BLOGS

A successful backup job is only one part of a recovery plan. The useful question is whether you can restore the right data, to a usable environment, within the time your business can tolerate. Start by listing what would be needed to rebuild the service if the original server were unavailable.

Define acceptable loss and downtime

Your recovery point objective describes how much recent data you can afford to lose. Your recovery time objective describes how long restoration can take. A small brochure website and a frequently updated customer database will usually have different targets. Set these targets before choosing a schedule or storage destination.

Include more than the website directory

• Application files, uploaded documents and persistent user content.
• Consistent database backups and any logs needed for the chosen recovery method.
• Service configuration, scheduled tasks and dependency information.
• A secure process for recovering credentials and encryption keys.
• DNS records and a record of external services the application depends on.

Copying live database files without a supported consistency method can produce an unusable backup. Use the database engine's documented backup procedure and verify the resulting recovery process. Keep sensitive backup contents encrypted where appropriate, with recovery keys available through a separately controlled process.

Separate failures from recovery copies

A backup stored only on the production server may disappear with that server. Likewise, credentials that can erase every backup make an accidental or compromised action more damaging. Design independent copies, retention and access permissions around the failures you need to survive. Redundant disks can help availability, but they do not preserve a file that the application intentionally deletes from the array.

Test a complete restore

Restore into an isolated environment. Check that the application starts, records are consistent, attachments open and essential workflows operate. Disable outgoing mail, payment actions and scheduled integrations in the recovery test so it cannot affect real customers.

Record the backup date, restoration duration, missing dependencies and corrective actions. Repeat after major application changes. If you are evaluating a storage server as a backup destination, include restore bandwidth and isolation in the requirements, not just total disk space.