01
Define what must be recovered and by when
A website may depend on application files, databases, uploaded media, environment configuration, DNS records, certificates, repositories and external services. Platform exports often omit themes, settings, customer files or integration details. Inventory the full service rather than assuming one download is complete.
Recovery point objective describes how much recent data the business can tolerate losing; recovery time objective describes how quickly service is needed. A static brochure site and a busy shop need different schedules. Define those needs before choosing a provider or retention plan.
- Files and deployed code
- Databases and customer-generated content
- Uploads and media originals
- Configuration and dependency instructions
02
Keep multiple recovery points with separated access
Maintain more than one recovery point so accidental corruption or a long-running compromise does not replace every clean copy. Use retention that reflects how quickly problems are usually discovered, with daily, weekly or longer points chosen from actual data-change and risk needs.
A copy inside the same server or account may disappear with the live site. Use appropriately separate storage and credentials; consider immutable or offline protection where impact warrants it. Separation does not remove the need to protect the backup provider itself with restricted access and MFA.
03
Automate jobs, monitor failures and protect secrets
Automate the agreed schedule and alert a named person when a job fails, storage fills or retention changes. Review completion evidence rather than assuming the presence of a scheduled task means usable copies exist.
Encrypt sensitive backups where appropriate and manage the keys independently. Limit who can read, delete or restore data and record administrative actions. Avoid embedding production secrets in an unprotected archive or sending customer databases through personal file-sharing accounts.
- Use separate backup credentials
- Alert on failures and missed schedules
- Monitor capacity and retention
- Restrict and record restore access
04
Test a clean restore and document the runbook
Restore into an isolated destination, verify files and data, rotate test secrets and check critical journeys such as login, forms, checkout and media. Record the time, provider steps and missing dependencies. A successful archive checksum does not prove that the application will start.
After a compromise, preserve relevant evidence and establish whether the backup predates the incident. Patch the entry point, replace compromised credentials and monitor after return to service. A common mistake is restoring the newest copy immediately and reintroducing the same malicious code or vulnerability.
Practical next steps
Checklist
- 01Inventory files, databases, uploads and configuration
- 02Set acceptable data loss and recovery time
- 03Choose backup frequency and retention from those needs
- 04Keep suitably separated copies and credentials
- 05Protect sensitive archives and recovery keys
- 06Alert a named owner when jobs fail
- 07Run an isolated restore of critical journeys
- 08Document providers, order, timings and rollback
- 09Review the plan after platform changes
Common questions
Questions and answers
How often should a website be backed up?
Match frequency to how often important data changes and how much loss the business can accept. A shop or membership site usually needs more frequent data copies than a static brochure site.
Are hosting-provider backups enough?
They can be one useful layer, but confirm coverage, retention, separation, access and restore terms. Keep an additional route where the business risk justifies it.
Can I restore the newest backup after a hack?
Not automatically. Determine whether it is clean, preserve evidence where appropriate and fix the entry point before returning the service to production.
Does a backup guarantee business continuity?
No. Recovery also depends on people, credentials, providers, documentation, integrations and tested operational decisions.
Need a considered recommendation?
Discuss the website, not just the symptom.
AHANIX reviews each requirement manually. Technical recommendations may depend on access to the website, hosting or DNS configuration.
Continue learning