Website Backup and Restore Guide: Choose a Backup Plan and Test Recovery

Overview

Website backups are copies of the files, databases, configuration, and supporting data required to rebuild or recover a site. Depending on the platform, that may include application files, uploaded media, themes, plugins, a content-management-system database, server configuration, email data, and DNS documentation. A backup of only one component may not be enough to restore the complete website.

A sound plan has three parts: a backup schedule, a storage and retention policy, and a tested restore procedure. Hosting providers may offer snapshots or automated backups, while an application such as WordPress may create its own file and database backups. These options can complement one another, but they are not automatically interchangeable. Check what each backup contains, how long it is retained, where it is stored, and whether you can download it or restore it to a compatible environment.

RPO and RTO in plain language

Your recovery point objective (RPO) is the amount of recent work you are prepared to lose. For example, an RPO of 24 hours means that a daily backup may be acceptable; an RPO of one hour calls for more frequent backups or another way to capture changes. Your recovery time objective (RTO) is how quickly the site needs to be available again. A personal site may tolerate a longer restoration, while a business website may need a documented emergency process and a ready-to-use destination.

Choose frequency and recovery methods based on how often the site changes and how costly downtime or lost data would be. A low-change brochure site may need a different plan from a store, membership site, news site, or application that writes data continuously.

Checklist by scenario

Routine website backups

• List every component that must be restored: files, database, uploads, configuration, scheduled tasks, and domain or DNS notes.
• Set a backup frequency that matches the site's change rate and your RPO.
• Keep more than one recovery point so a bad update or unnoticed problem is not copied into every backup.
• Store at least one usable copy outside the hosting account when the site is important.
• Record the backup location, encryption or access method, retention period, and person responsible for recovery.

Before a plugin, theme, code, or configuration change

• Take a new backup immediately before the change, rather than relying only on the normal schedule.
• Confirm that the backup finished successfully and note its timestamp.
• Write down what will change and how to undo it.
• Check whether the hosting control panel offers a staging copy or a one-click rollback, but do not treat either as a substitute for an independent backup.
• After the change, test the homepage, key forms, logins, checkout or other critical workflows, and recent content.

Before moving to new hosting

• Export the complete site, including the database and media files.
• Save configuration details separately, including PHP or runtime requirements, environment variables, cron tasks, redirects, SSL settings, and DNS records.
• Confirm that the new platform supports the application's version, extensions, database engine, and storage needs.
• Restore a copy on the new host before changing production DNS whenever possible.
• Lowering DNS TTL may help with a planned change, but it does not replace a backup or guarantee instant global switching.
• Keep the old hosting account available until the new site and its data have been checked.

For broader preparation, use the domain and hosting setup checklist and the shared hosting, VPS, and cloud hosting comparison to review platform fit before a migration.

After an outage, failed update, or suspected compromise

1. Record what happened and avoid repeatedly changing the live site while diagnosing it.
2. Preserve logs and, when appropriate, take a copy of the current state for investigation.
3. Choose a restore point from before the problem began, not simply the newest available copy.
4. Restore in an isolated or staging environment first when the situation allows.
5. Verify files, database content, links, forms, user access, integrations, and scheduled tasks.
6. Once the restored version is approved, document the action and investigate the original cause before resuming normal updates.

What to double-check

Read the hosting plan's backup documentation rather than assuming that a backup is included or complete. Check whether backups cover the full account or only selected files, whether databases are included, how many recovery points are retained, whether storage counts toward a quota, and whether restoration is self-service or requires provider assistance. Limits and controls can differ by plan and may change after a hosting migration or product update.

Test compatibility as well. A backup created by one application version may require an upgrade or downgrade path before it can be restored. A server snapshot may depend on the original provider's infrastructure, whereas a downloadable application backup may be easier to move. If email is hosted with the website account, confirm whether mailboxes and messages are included; many website backups do not preserve email in the same way as site files and databases. Keep separate records for domain registration and DNS, using the DNS troubleshooting guide when documenting A, CNAME, MX, and TXT records.

Reusable backup inventory

• Site: domain, platform, hosting account, environment, and application version.
• Data: database, uploads, code, configuration, customer or member data, and email scope.
• Copies: location, format, creation time, retention period, and access owner.
• Recovery: restore destination, required credentials, estimated steps, and validation checks.
• Contacts: hosting support path, domain registrar access, and the person authorized to approve a rollback.

Protect backup access as carefully as production access. Use separate credentials where practical, limit permissions, and avoid leaving unprotected database exports in a public web directory. Sensitive backups should be encrypted in transit and at rest when the storage system supports it, with a documented way to recover the encryption key.

Common mistakes

• Confusing a backup with a snapshot: A snapshot can be convenient for rollback but may not be portable or long-lived.
• Backing up only the files: A database-driven site usually needs both the application files and database content.
• Keeping every copy in one account: A locked, deleted, or failed hosting account can make colocated backups inaccessible.
• Never testing restoration: A successful backup job proves that data was copied, not that the site can be rebuilt.
• Choosing the newest copy automatically: The newest backup may contain corruption, an accidental deletion, or an unwanted change.
• Ignoring credentials and configuration: Files and data alone may not explain how to recreate DNS, scheduled tasks, SSL, or third-party connections.
• Forgetting renewal and ownership access: Recovery can be delayed if domain or hosting access has expired. Review the domain expiration prevention guide as part of continuity planning.

When to revisit

Schedule a restore test at a frequency that matches the site's importance, and repeat it before seasonal planning cycles or other periods when downtime would be especially disruptive. Revisit the plan after changing hosts, control panels, applications, major plugins, themes, code, databases, storage destinations, or security controls.

At each review, create or select a recovery point, restore it to a safe destination, and verify the checks that matter to users. Confirm that the site loads over HTTPS, content and media appear, forms or transactions behave as expected, administrative access works, background tasks run, and DNS and email records are documented. Record the result, the time required, any missing data, and the corrective action.

Use this short action list before your next change:

1. Define an acceptable RPO and RTO.
2. Inventory the website and its dependencies.
3. Confirm what the current host backup includes and how long it is retained.
4. Create an offsite or downloadable recovery copy.
5. Test a restore and document the exact workflow.
6. Set a calendar reminder for the next test and update it whenever the workflow or tools change.

A backup plan is not finished when a file exists. It is finished when the right person can find a suitable recovery point, restore it on a compatible platform, and confirm that the website works.