THE CONNECTIONS BEHIND YOUR BUSINESS
How to Back Up and Restore a Website
Build a practical recovery plan for website files, databases and configuration, then verify that the backup can be restored.
A useful website backup is one you can restore. Plan the files, databases and account settings you need, then verify your recovery copy before you rely on it.
Start here: what would you need to recover?
A static website needs its deployed files and server configuration. WordPress and similar applications also need a matching database, uploads, plugins, themes and application configuration. Email may be stored on this account or at a separate provider.
A backup is useful only if you know what it contains, can access it independently, and have a workable restore method. Downloading a ZIP is not the same as testing recovery.
1. Define the recovery point
List the websites, databases, mailboxes and scheduled jobs in scope. Record the time and time zone, software versions, document roots, DNS settings and relevant Apache configuration. Protect any secrets separately.
For an active store or application, a files-and-database copy taken at different times can be inconsistent. Ask the host or application specialist about a supported consistent backup and a brief approved write pause if needed. Do not run improvised database locks or assume every table supports transaction snapshots.
2. Create supported backups
Use cPanel’s Backup or Backup Wizard, where your provider makes them available. Review full-account versus partial file/database options. Confirm available disk space first and keep generated archives outside public access.
A full cPanel backup generally requires the hosting provider or WHM for a full-account restoration; the ordinary cPanel interface does not automatically restore the entire account. Confirm that procedure before relying on it for a time-critical rollback.
An application backup can supplement this, but verify that it includes the database and required files rather than only selected uploads. A WordPress content XML export is useful editorial recovery material, not a complete website or database backup.
3. Download and verify
Store a copy outside the hosting account with access restricted. On Windows, calculate a checksum:
Get-FileHash -Algorithm SHA256 -LiteralPath 'C:\Backups\your-site-backup.zip'Record the resulting hash with the filename, size and backup time. A matching hash after transfer proves the bytes match that reference; it does not prove the contents are complete or the database is consistent.
Test archive integrity with a trusted archive tool. Inspect the file listing for configuration, uploads and database exports without exposing secrets. Use an isolated restore environment for a meaningful recovery test.
4. Restore with a boundary
Before restoring, preserve the current state if it contains new orders, forms or mail. Obtain approval for downtime and agree which data will be overwritten. Restore only the intended account or application, using the provider’s supported process.
Test the home page, internal pages, HTTPS, login, database-backed reads and authorized test writes. Check email and scheduled jobs separately. Prevent a restored test copy from sending customer mail, taking payments or running production jobs.
Keep the plan usable
Document who can restore, where credentials are held, expected recovery time and when the last restore test passed. Retain more than one recovery point: an immediately recent backup can faithfully preserve an already broken or compromised site.
Official references
Documentation checked 2026-10-18. Examples use reserved names and addresses; replace placeholders only for systems you are authorized to manage. Interfaces and included features depend on your provider and account.