A reliable website backup policy defines what is copied, how long it is retained, where it is stored, and how recovery is proved. This guide provides a repeatable way to set retention periods, estimate storage requirements, plan restore tests, and document daily, weekly, monthly, and off-site backups for hosted websites and servers.
Overview
Backups are useful only when they are available, complete, and restorable. A hosting control panel may report a successful job even though the copy is incomplete, inaccessible, or too old to meet the business's recovery needs. A sound website backup retention policy therefore covers both backup creation and recovery verification.
Start with two recovery objectives:
- Recovery point objective (RPO): the maximum acceptable amount of data that could be lost, measured in time. An RPO of 24 hours implies that a daily backup may be acceptable; a transactional application may require more frequent copies.
- Recovery time objective (RTO): the target time for restoring service after an incident. A backup that takes many hours to download, rebuild, and validate may not support a short RTO.
Separate the website into recoverable components. A typical inventory includes application files, uploads, databases, server and web-server configuration, scheduled jobs, certificates, DNS records, deployment settings, and secrets or their secure references. Do not assume that a provider's virtual-machine snapshot includes every item needed to rebuild the service elsewhere.
Retention is a risk and cost decision. Keeping every copy indefinitely can increase storage use and expose more historical data. Keeping only the latest copy reduces cost but leaves fewer recovery points if corruption or compromise goes unnoticed. The right policy balances change frequency, business impact, recovery objectives, storage cost, and contractual or regulatory obligations.
How to estimate
Use a simple capacity model before choosing a backup plan:
Estimated backup storage = protected data × number of retained full copies + daily change volume × number of retained incremental copies + overhead.
This is an estimate rather than a billing formula. Deduplication, compression, database dumps, snapshots, metadata, and provider billing rules can change the final amount. Ask the hosting provider whether storage is charged by logical size, stored size, transfer, requests, or a combination.
1. Measure the protected data set
Record the actual size of files, databases, mailboxes, logs, and configuration exports. Exclude reproducible caches and temporary files only after confirming that they can be recreated. For databases, record both live size and the size of an export because a compressed dump may behave differently from a raw disk copy.
2. Estimate change volume
Measure how much data changes between backup points. A brochure site may change only when content is published, while an ecommerce or membership application may update continuously. Use observed backup reports where possible rather than guessing from total disk capacity.
3. Apply a retention schedule
A practical baseline can be expressed as a rolling schedule:
| Copy type | Typical purpose | Planning question |
|---|---|---|
| Daily | Recent operational recovery | How much recent work can be lost? |
| Weekly | Recovery from issues discovered after several days | How far back are meaningful recovery points needed? |
| Monthly | Longer-term rollback and change history | Do business, contractual, or compliance needs require older copies? |
| Off-site | Protection from host, site, or facility failure | Can the service be recovered if the primary data centre is unavailable? |
For example, a policy might retain the most recent 14 daily copies, eight weekly copies, and 12 monthly copies, with an off-site copy for each selected recovery point. Those numbers are starting assumptions, not universal requirements. Adjust them to the application's RPO, the time required to detect corruption, and the obligations that apply to the organisation.
4. Add operational overhead
Allow for metadata, encryption packaging, temporary restore space, failed jobs, and a second copy during retention transitions. If a backup is encrypted before upload, test whether the encryption process requires local working space. Estimate restore bandwidth and transfer charges separately from storage.
Inputs and assumptions
Document the following inputs in the policy and review them with the people responsible for the application:
- Systems covered: domains, databases, servers, containers, object storage, DNS, and configuration repositories.
- Business impact: the consequence of losing recent orders, customer submissions, content, or configuration.
- RPO and RTO: recovery targets for each workload, rather than one target for an entire hosting account.
- Retention periods: daily, weekly, monthly, and any longer-term copies, with a documented reason for each.
- Locations: primary backup storage, off-site storage, and any restrictions on data residency or cross-border transfer.
- Security controls: encryption in transit and at rest, separate credentials, least-privilege access, multi-factor authentication, and immutable or write-protected copies where supported.
- Ownership: the person or team who receives failure alerts, approves retention changes, and leads a restore.
Keep backup credentials separate from the production server. A compromised administrator account should not automatically grant an attacker the ability to delete every backup. Limit deletion rights, log access, and periodically review users, API keys, service accounts, and recovery keys. Store encryption keys separately from the backup data, while ensuring that authorised recovery staff can access them during an incident.
Include application consistency in the assumptions. A file-level copy taken while a database is writing may not be enough for a clean recovery. Use database-aware dumps, snapshots with documented consistency behaviour, or a backup tool designed for the workload. Back up server configuration and deployment instructions so that a replacement VPS, dedicated server, or cloud instance can be rebuilt rather than merely filled with files.
Restore-test checklist
- Select a recovery point without changing the production system.
- Verify that the backup can be downloaded or mounted by an authorised recovery account.
- Restore into an isolated server, staging environment, or temporary data centre resource.
- Recover databases and confirm table counts, recent records, indexes, and application connectivity.
- Check files, permissions, configuration, scheduled jobs, certificates, DNS settings, and external integrations.
- Run representative user journeys, such as login, checkout, publishing, form submission, or API requests.
- Record elapsed time, missing data, errors, manual steps, and the final result.
- Remove temporary data securely and update the recovery runbook.
Worked examples
Small content website
Assume a site has 20 GB of application files and media, a 2 GB database, and modest daily changes. The owner could choose daily backups for recent recovery, weekly copies for a wider rollback window, and monthly copies for longer-term reference. A second location protects against a failure affecting the primary hosting account. The policy should still include a database-aware restore and a test of the contact form, administrator login, media, and deployment configuration.
The storage estimate should count retained copies rather than simply multiplying total disk capacity by the number of scheduled jobs. If the tool uses incremental copies, use the measured daily change volume and confirm how long incremental chains remain usable.
Transactional application
Assume an application records orders or customer activity throughout the day. Daily backups alone may not meet the chosen RPO. The owner might use more frequent database backups, with daily application and configuration copies, weekly recovery points, and off-site replication or export. The precise schedule depends on transaction volume, acceptable data loss, and the ability to replay or reconcile records.
Test the complete recovery path, not only the database. Confirm that the restored application can connect to required services, that secrets can be supplied safely, and that operators know how to pause traffic, validate data, and change DNS if the original server is unavailable.
When to recalculate
Recalculate storage, retention, and recovery procedures at least quarterly for important systems and whenever a material change occurs. Revisit the policy after a hosting migration, server resize, database upgrade, new application feature, major content import, change in data residency requirements, or change in provider pricing or backup tooling.
Run a documented restore test at least monthly for systems where recovery is business-critical, and schedule a broader recovery review each quarter. A monthly test can validate one recent copy; a quarterly review can test an older retained copy, off-site access, credentials, restore timing, and the runbook. After every failed or incomplete test, record the corrective action and set a due date rather than treating the backup as operationally complete.
Use this compact policy template:
Scope: [systems, databases, files, and configurations covered].
RPO/RTO: [target for each workload].
Schedule: [daily, weekly, monthly, and event-based jobs].
Retention: [number of copies and duration by tier].
Locations: [primary and off-site storage, including residency constraints].
Security: [encryption, access control, MFA, key handling, and deletion protection].
Testing: [monthly restore test, quarterly review, owner, and evidence retained].
Review trigger: [date plus application, hosting, pricing, or compliance changes].
Before approving the policy, perform one end-to-end restore and measure the result against the RPO and RTO. If it fails, change the schedule, tooling, storage location, or recovery procedure until the documented target is achievable. For related availability and infrastructure decisions, see our guides to active-active versus active-passive disaster recovery, hosting uptime SLAs, and data centre due diligence.
