How to Test Website Backups for Disaster Recovery

A backup is only useful if you can restore it when systems are damaged, unavailable, or compromised. During a cyberattack, backup files may be encrypted or deleted along with production data, backup credentials may be exposed, and an untested restore may take longer than your business can tolerate. Testing website backups for disaster recovery helps reveal these gaps before an incident.

This guide explains how to set recovery targets, protect backup copies, and run practical restore drills for a website. Backups reduce the impact of data loss; they do not prevent ransomware or guarantee that restored systems are clean.

Key takeaways

• Keep at least one backup copy offline or protected with immutability, and separate backup access from routine production access.
• Set a recovery point objective (RPO) and recovery time objective (RTO) based on business needs, then check them in actual restore exercises.
• Test files, databases, configurations, and application behavior—not just whether a backup job reports success.
• Restore into an isolated environment first, and follow incident-response steps before reconnecting recovered systems.
• Record test results, fix gaps, and repeat the exercise after significant changes.

Why backups fail during a cyberattack

A backup can exist and still be unusable. Common causes include:

• Shared access: Production and backup systems use the same administrator credentials. An attacker who gains those credentials may be able to alter or delete both.
• Always-connected copies: A backup repository that is writable from compromised production servers can be affected by the same attack.
• Unprotected retention settings: An attacker or mistake can shorten retention, remove snapshots, or change storage policies unless those actions are restricted.
• Incomplete coverage: A backup may include website files but omit the database, uploaded media, configuration, encryption keys, or other dependencies needed to operate the site.
• Silent corruption or failed jobs: A job can report success while a file is missing, a database dump is inconsistent, or an upload has failed.
• No recovery procedure: The person who knows how to restore the site may be unavailable, or essential credentials and instructions may be missing.
• Unclear recovery priorities: Teams may restore the wrong systems first or discover that the recovery time is unacceptable only during an incident.

Ransomware can also involve data theft or disruption beyond file encryption. A backup does not undo disclosure, prevent an attacker from retaining access, or establish that a restored system is safe.

Set recovery targets before testing

Recovery objectives turn a vague promise to “restore quickly” into targets you can evaluate.

Recovery point objective (RPO)

The RPO is the maximum amount of recent data your organization is prepared to lose, expressed as a period of time. If your RPO is four hours, a recovery may use a backup up to four hours old. That is a target, not proof that every change within the period is recoverable. Choose backup frequency and replication settings accordingly, and account for the time needed to create or transfer a usable copy.

Recovery time objective (RTO)

The RTO is the target time to restore a service after disruption. Define what counts as restored: for example, the website may load, users can sign in, and transactions or publishing workflows work. A server starting successfully is not necessarily service recovery.

Discuss both targets with the people responsible for the site and its business operations. A small brochure site and a revenue-critical store may have very different acceptable data loss and downtime. Make the assumptions explicit, including who can approve recovery and which dependencies must be available.

Protect backup copies and access

A resilient backup plan limits the chance that one compromised account or system can destroy every copy.

• Keep an offline or isolated copy. An offline copy is disconnected from routine network access. An isolated copy may remain online but should have strong access boundaries. These approaches reduce exposure to attacks on production, but each needs careful configuration and testing.
• Use immutable storage where appropriate. Immutability can prevent changes or deletion during a defined retention period. Confirm which accounts can change the policy, how retention works, and what happens when it expires. “Immutable” is not a substitute for restricted administration or tested restores.
• Separate identities and permissions. Avoid reusing ordinary production administrator credentials for backup administration. Limit who can create, delete, or change retention settings, and protect privileged accounts with strong authentication.
• Encrypt copies and protect recovery keys. Encryption helps protect backup data, but recovery depends on being able to access the keys. Store key-recovery instructions securely and separately from the systems they unlock.
• Monitor backup activity. Alert on unexpected job failures, deletion attempts, policy changes, or unusual access. Ensure someone is responsible for reviewing and acting on those alerts.
• Keep more than one recovery point. A recent copy may contain damaged or compromised data. Retention should preserve older, known-good points for a period appropriate to your risks and operational needs.

No storage design is invulnerable. Test that staff can access the protected copy through the documented recovery process, without weakening its protections in day-to-day operations.

What a website recovery test should cover

List the components required to run the site, then decide which are included in each backup and how they will be restored. Depending on the architecture, this may include:

• Application code and deployment artifacts.
• The database, including a consistent snapshot or a documented export and restore process.
• User uploads and other files not stored in source control.
• Configuration, scheduled jobs, and service dependencies.
• DNS, certificates, and external services needed to bring the site back. Some of these may require separate recovery procedures rather than a file backup.
• Recovery instructions and access to credentials or encryption keys, stored securely.

Do not put live secrets into a general backup document or expose them in a test environment. Plan how to retrieve and rotate secrets securely after an incident.

A step-by-step restore drill

Start with a low-risk test, then expand to a full recovery exercise. Record the date, backup point, people involved, results, and elapsed times.

1. Choose a scenario. For example, assume a website host is unavailable or a production server must be rebuilt. Use a scenario appropriate to the systems you own or are authorized to administer.
2. Select a recovery point. Record its timestamp and confirm that it falls within the RPO you intend to meet. If you need an older clean point, test how staff identify and retrieve one.
3. Prepare an isolated destination. Restore to a staging or recovery environment that cannot accidentally overwrite production or expose a partially recovered service to users. Restrict access and avoid connecting it to untrusted systems.
4. Retrieve the backup using the documented process. Measure how long access, approval, and transfer take. This tests the real recovery path, including permissions and key availability.
5. Restore files and the database. Follow the runbook. Check that required files exist and that the database can be opened and queried. Do not assume a successful copy operation means the application data is consistent.
6. Start the application safely. Use test configuration and controlled dependencies. Check logs for errors and verify important functions, such as page rendering, authentication, publishing, or a test transaction, as appropriate.
7. Check integrity and completeness. Compare representative records and files against expected values. Confirm that uploads, permissions, and configuration are present. Use checks appropriate to the system; a basic smoke test is not a full security assessment.
8. Measure recovery time. Record the time from the defined start of recovery to the agreed service-restored condition. Compare the result with the RTO and note delays caused by approvals, missing instructions, or manual work.
9. Clean up and document. Remove temporary data securely, preserve the results, assign owners to gaps, and schedule a retest after fixes.

A drill can be as small as restoring a single database and a sample of files, but it should be clear about what it proves. A partial test does not demonstrate that the entire website can be recovered.

Restore carefully after a real incident

During a suspected compromise, avoid immediately restoring a backup over production. That can destroy evidence, reintroduce compromised files, or return the attacker’s access along with the data. Coordinate recovery with the incident-response lead or qualified security support.

Before returning a recovered system to service, determine which systems and accounts were affected, preserve relevant evidence where required, rebuild or clean systems as appropriate, and review the backup point for signs of compromise. Rotate credentials and keys that may have been exposed. Apply needed security updates and verify that access controls and monitoring are in place. The exact response depends on the incident, environment, and legal or regulatory obligations.

Common mistakes during backup testing

• Checking only the backup dashboard: A green status does not prove the data can be restored or that the application works afterward.
• Testing only the newest copy: A recent recovery point may be incomplete or already affected. Include a procedure for choosing an older point when needed.
• Testing without a clock: If elapsed time is not measured, the exercise cannot show whether the RTO is realistic.
• Restoring into production: A test can overwrite live data or create an outage. Use an isolated destination unless a carefully controlled recovery plan specifically requires otherwise.
• Ignoring dependencies: A restored database is not enough if the site also needs uploads, configuration, certificates, or external services.
• Using undocumented exceptions: If a test succeeds only because an expert knows an undocumented workaround, the runbook is not yet reliable.
• Treating a successful drill as a permanent guarantee: Software, data volume, staff, and infrastructure change. Repeat tests and update the process.

A practical testing cadence

Set a schedule based on business impact, how frequently the site changes, and the complexity of recovery. A useful program can combine routine checks of backup-job alerts, periodic file or database restores, and broader end-to-end recovery exercises. Test again after major infrastructure changes, migrations, or changes to backup permissions and retention.

Keep a short record of each exercise:

Conclusion

Testing website backups for disaster recovery means proving that the right data can be retrieved, restored, and used within agreed recovery targets. Protect copies with offline or immutable storage and separate access, then run isolated restore drills that include the website’s real dependencies. Use each test to improve the runbook and close gaps. Backups are an important recovery control, but they do not prevent ransomware damage or replace incident response.

References

• CISA, #StopRansomware Guide
• NIST, Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1)