A Website Backup Is Only Useful If You Can Restore It: Build a Recovery Plan Before Trouble Starts

The word "backup" feels reassuring. A dashboard says the task completed, a storage folder contains an archive, and everyone assumes the website can be recovered.

That confidence is justified only after a restore test.

A useful recovery plan answers four questions: what must be copied, how often it changes, where the copies are stored, and how the business will return to service. This guide helps you answer them before an outage, failed update or security incident forces you to improvise.

Begin With the Business Impact

Not every website needs the same schedule. A brochure site updated once a month can tolerate a different recovery point than an online store accepting orders throughout the day.

Define two practical targets:

• Recovery Point Objective (RPO): how much recent data can the business afford to lose?
• Recovery Time Objective (RTO): how long can the service remain unavailable?

If losing one hour of orders would create a serious problem, a nightly database backup is not enough. If a site changes only when a quarterly announcement is published, hourly copies may add complexity without meaningful benefit.

These are business decisions first. Technology should support the target, not define it accidentally.

Identify Everything the Website Needs

Copying public_html may not be a complete backup. A typical recovery set can include:

• application files and uploaded media;
• database content;
• configuration files;
• environment variables and secret-location documentation;
• DNS zone export;
• email account and routing configuration;
• scheduled tasks;
• SSL installation notes;
• deployment instructions;
• licenses or integration settings needed to rebuild the service.

Do not place plaintext secrets inside a broadly accessible archive. Document where authorized staff can recover them securely.

For a managed web-hosting account, review which backup functions are included and what the customer must download independently. For a VPS, the server owner usually has more responsibility for the operating system, application and database strategy.

Use More Than One Recovery Point

One copy is fragile. It can be incomplete, corrupted, overwritten or already infected.

A practical retention plan keeps several points across different time windows. For example, the business might retain daily copies for a short period, weekly copies for longer and a monthly archive for historical recovery. The exact schedule should reflect the site's value, change frequency, storage limits and legal obligations.

Version history matters after a slow incident. If malicious code remained unnoticed for twelve days, restoring yesterday's copy may restore the same problem.

Keep a Copy Outside the System It Protects

A backup stored only on the same hosting account can disappear with the account, disk or credentials that caused the outage.

Keep at least one independent copy in a separate storage location with appropriately restricted access. Separation can be logical and administrative as well as geographic: different credentials, different service boundary and protection against routine deletion.

Encrypt sensitive archives at rest and in transit. Record who can retrieve the encryption key and how that access will work during an emergency.

Automate the Copy, but Monitor the Result

Automation reduces forgotten tasks, but a scheduled job can fail quietly. Storage may fill, credentials may expire, paths may change or a database export may complete with an error.

Monitor more than the job's existence:

• completion status;
• archive size compared with normal history;
• age of the newest successful copy;
• available storage;
• integrity or checksum results;
• notification delivery;
• failed or partial database exports.

A surprisingly tiny archive is often more useful as an alarm than a green "completed" badge.

Restore to Staging, Not Over the Live Site

The safest test normally restores a selected copy into an isolated staging environment. That allows you to inspect the result without overwriting the production site.

Test the functions customers depend on:

1. open representative pages;
2. verify images and downloads;
3. sign in with a test account;
4. search the catalog or content;
5. submit important forms;
6. inspect recent database records;
7. test a low-risk order flow where appropriate;
8. check scheduled tasks and integrations;
9. scan the restored site before declaring it clean.

Record the restore duration. If it takes six hours to locate credentials and reconstruct the database, the real recovery time is six hours, regardless of how quickly the files were copied.

Backups and Security Incidents Need Extra Care

After a compromise, do not immediately overwrite production with the latest archive. Preserve logs and evidence, identify the entry point, determine when the compromise began and select a recovery point from before that date.

Then patch the vulnerable component, rotate affected credentials, restore clean data, test the result and monitor for recurrence. A clean archive placed into the same vulnerable environment can be compromised again.

Our guide to website security layers explains how backups fit with account security, updates, monitoring, filtering and protected DNS.

Protect the Domain and DNS Recovery Path

A working website backup does not restore a lost domain account or an undocumented DNS zone. Keep the registrar account secured, record nameservers and export DNS records before major changes.

Use the SoxDomains WHOIS and RDAP tool to confirm registrar and public registration details. If a recovery requires moving the domain, follow the domain-transfer checklist and avoid changing nameservers merely because the registrar changes.

Assign Recovery Roles

Write down who can authorize a restore, who has hosting access, who controls DNS, who communicates with customers and who verifies that the recovered site is safe.

The plan should work when the usual administrator is unavailable. Store contact and access instructions somewhere the team can reach even if the website, company email or primary password manager is affected.

A Recovery Runbook You Can Follow

Use a short, tested sequence:

1. confirm the incident and stop risky changes;
2. preserve logs and the current state when security is involved;
3. choose the appropriate recovery point;
4. prepare an isolated restoration target;
5. restore files, database and required configuration;
6. patch the cause before reconnecting traffic;
7. verify the customer journey;
8. update DNS only if the recovery architecture requires it;
9. monitor closely after service returns;
10. document what happened and improve the plan.

Avoid changing hosting, DNS, email and application code simultaneously unless the recovery truly requires it. Smaller controlled steps make problems easier to diagnose and reverse.

The Test Is the Proof

A backup file is evidence that a process created something. A successful test restore is evidence that the business can recover.

Choose a realistic recovery point, restore it to staging, time the process and document every missing credential or unclear step. Those discoveries are the reason to test before the emergency.