How many backups should you keep? How far back should they go? Should you keep daily snapshots for a week, a month, or a year? These are not trivial questions — the answers directly affect how much data you can recover after an incident, how much storage you need, and how quickly you can get back online. A well-designed backup retention policy balances data protection against storage costs, and it should be based on your specific business needs rather than arbitrary defaults.
This guide walks you through the principles of backup retention for hosted websites, helps you design a policy that fits your situation, and explains how different hosting environments handle retention. If you are on MassiveGRID's high-availability cPanel hosting, you already have automated backups with configurable retention — but understanding the "why" behind retention policies helps you make smarter choices.
What Is a Backup Retention Policy?
A backup retention policy defines three things:
- How often backups are created (frequency)
- How long each backup is kept (retention period)
- Which backups are pruned and when (rotation schedule)
Without a defined policy, you either accumulate backups indefinitely (consuming ever-growing storage) or you have too few backups and cannot recover to the point in time you need. A good policy gives you multiple recovery points spanning different time horizons while keeping storage usage predictable and manageable.
Understanding RPO: Recovery Point Objective
The key metric that drives your retention policy is your Recovery Point Objective (RPO) — the maximum amount of data loss you can tolerate, measured in time. If your RPO is 24 hours, you can afford to lose up to 24 hours of data. If your RPO is 1 hour, you need backups at least every hour.
| Website Type | Typical RPO | Minimum Backup Frequency | Rationale |
|---|---|---|---|
| Personal blog | 7 days | Weekly | Content changes infrequently; losing a week's posts is annoying but not catastrophic |
| Business website (brochure) | 24 hours | Daily | Content changes occasionally; daily backups cover most scenarios |
| Active blog / content site | 12-24 hours | Daily | Regular content updates; losing more than a day's work is significant |
| eCommerce store | 1-4 hours | Every 4-6 hours or continuous | Orders, customer data, and inventory change constantly; every hour of lost data represents lost revenue |
| SaaS application | Minutes to 1 hour | Hourly + database replication | User data changes continuously; data loss directly impacts customers |
| Financial / compliance-regulated | Near-zero | Continuous replication + periodic snapshots | Regulatory requirements mandate minimal data loss and long retention |
Your RPO is a business decision, not a technical one. It should be defined by the people who understand the cost of data loss — the business owner, the operations manager, or whoever is responsible for the website's revenue and reputation.
The Grandfather-Father-Son (GFS) Rotation Scheme
The most widely used backup retention scheme is Grandfather-Father-Son (GFS), also known as the daily-weekly-monthly rotation. It provides a good balance of granularity (recent backups) and history (older backups) without requiring excessive storage.
Here is how it works:
- Son (daily) — A backup is created every day. You keep the last 7 daily backups. These provide fine-grained recovery points for recent incidents.
- Father (weekly) — One backup per week is promoted to "weekly" status (typically the Sunday backup). You keep the last 4 weekly backups. These cover the previous month at weekly granularity.
- Grandfather (monthly) — One backup per month is promoted to "monthly" status (typically the first-of-month backup). You keep the last 3-12 monthly backups. These provide long-term recovery points for issues that are not discovered immediately.
GFS Example: Standard Website
| Tier | Frequency | Retention | Total Copies | Recovery Window |
|---|---|---|---|---|
| Daily | Every day | 7 days | 7 | Any day in the past week |
| Weekly | Every Sunday | 4 weeks | 4 | Any week in the past month |
| Monthly | 1st of month | 3 months | 3 | Any month in the past quarter |
| Total backup copies at any time | 14 | Up to 3 months back | ||
With this scheme, you have 14 backup copies providing up to 3 months of history. If your average cPanel backup is 5 GB, that is 70 GB of backup storage — very manageable.
GFS Example: eCommerce Store
| Tier | Frequency | Retention | Total Copies |
|---|---|---|---|
| Hourly (database only) | Every 4 hours | 48 hours | 12 |
| Daily (full) | Every day | 14 days | 14 |
| Weekly | Every Sunday | 8 weeks | 8 |
| Monthly | 1st of month | 12 months | 12 |
| Total backup copies | 46 | ||
This more aggressive policy provides 4-hour granularity for recent data (covering the critical "I just noticed something is wrong" scenario) and 12 months of monthly snapshots for long-term recovery or compliance needs.
Why You Need More Than "Just Yesterday's Backup"
Many site owners think that keeping only the most recent backup is sufficient. It is not, and here is why:
Delayed Discovery of Problems
Not all issues are discovered immediately. A security breach might go undetected for days or weeks. Malware may be injected into your site and remain dormant. A database corruption issue might only become apparent when a specific query runs. If your only backup is from yesterday, and the problem has been present for a week, your backup is already infected or corrupted.
Having weekly and monthly backups gives you clean recovery points that predate the problem. You may lose more recent data, but you can at least recover to a known-good state.
Accidental Content Deletion
A team member accidentally deletes an important page, product, or database table. If they do not notice until a week later, yesterday's backup will not help — the deletion is already reflected in recent backups. A monthly backup from before the deletion contains the lost content.
Regulatory and Compliance Requirements
Some industries require data retention for specific periods. Healthcare, finance, and government websites may be legally required to maintain backup archives for months or years. Your backup retention policy must comply with applicable regulations. If you are unsure about your regulatory requirements, consult with a compliance professional.
Incremental vs. Full Backups and Retention
Your choice between incremental and full backups directly affects how much storage your retention policy requires:
- Full backups are complete copies of everything. Each backup is self-contained and can be restored independently. Storage use scales linearly with the number of copies.
- Incremental backups store only the changes since the last backup. They use much less storage but depend on a chain of previous backups for a full restore. If any link in the chain is corrupted, all subsequent backups may be unusable.
A common hybrid approach: use incremental backups for daily snapshots (keeping storage costs low) and full backups for weekly and monthly retention points (ensuring reliable, self-contained restore points).
Storage Cost Estimation
To estimate your backup storage needs, multiply your account size by the number of retained copies, with adjustments for incremental backups:
- Full backups only: Account size (GB) x number of copies = total storage needed
- Incremental dailies + full weeklies/monthlies: (Account size x number of full copies) + (daily change rate x account size x number of incremental copies)
For a 10 GB website with a typical 5% daily change rate:
- 7 incremental dailies: 7 x 0.5 GB = 3.5 GB
- 4 full weeklies: 4 x 10 GB = 40 GB
- 3 full monthlies: 3 x 10 GB = 30 GB
- Total: approximately 73.5 GB
Cloud storage costs for this volume range from $1.50-$3.00/month depending on the provider and storage class. This is a trivial cost compared to the value of the data being protected.
Setting Up Retention in cPanel/WHM
If you have WHM access, you can configure retention directly:
- Navigate to WHM > Backup Configuration
- Under Scheduling and Retention, set:
- Daily backups: Enable, retain for X days
- Weekly backups: Enable, retain for X weeks
- Monthly backups: Enable, retain for X months
- Configure off-site backup destinations for each tier if desired
- Enable email notifications for backup completion and failures
If you are on shared hosting without WHM access, your retention is determined by your hosting provider's configuration. On MassiveGRID's high-availability cPanel hosting, automated backups run with retention policies designed to provide multiple recovery points across different time horizons.
Retention Policy for WordPress Sites
WordPress sites benefit from a layered backup approach:
- Server-level backups (cPanel) — follow the GFS schedule above; this is your safety net for complete disasters
- Application-level backups (UpdraftPlus, BlogVault, etc.) — can run more frequently (every 4-12 hours for the database) and store backups in your own cloud storage; these are faster to restore for CMS-specific issues
- Version control for custom code — if you develop custom themes or plugins, keep them in a Git repository; this is not a "backup" in the traditional sense, but it ensures code is never lost
The combination of server-level and application-level backups gives you two independent backup chains with different retention schedules, different storage locations, and different restore procedures — dramatically reducing the risk of total data loss.
Retention for Compliance: How Long Is Long Enough?
Regulatory requirements may mandate minimum retention periods:
| Regulation / Standard | Typical Data Retention Requirement | Notes |
|---|---|---|
| GDPR (EU) | As long as necessary for purpose; no longer | Retention must be justified; holding data longer than needed is a violation |
| HIPAA (US Healthcare) | 6 years minimum | Applies to protected health information (PHI) |
| SOX (US Financial) | 7 years | Financial records and audit trails |
| PCI DSS (Payment Card) | 1 year of audit logs; backup retention at merchant discretion | Backups containing cardholder data must be encrypted |
| ISO 27001 | Defined by organization's ISMS | Must document and follow retention policy |
Note that GDPR can actually conflict with long retention periods — you must not keep personal data longer than necessary. If your backups contain user data, your retention policy must balance recovery needs against data minimization requirements. This is a complex area where legal and technical teams need to align.
Testing Your Retention Policy
A retention policy is only as good as the backups it produces. Regular testing should include:
- Verify backup existence — check that backups for each retention tier actually exist (daily, weekly, monthly)
- Verify backup completeness — download a backup and confirm it contains all expected data
- Test restoration — restore a backup to a staging environment at least quarterly; verify the site is fully functional
- Verify oldest backup integrity — specifically test the oldest retained backup; storage degradation can corrupt older backups over time
- Document the test results — as part of your disaster recovery plan, keep a log of backup verification tests
Frequently Asked Questions
Is keeping 7 daily backups enough for a small business website?
For most small business websites with daily backups, 7 daily + 4 weekly + 3 monthly copies provide adequate coverage. This gives you fine-grained recovery for the past week and broader coverage for the past three months. If your site handles eCommerce transactions or user-generated data, consider a more aggressive policy with longer retention or more frequent database-only backups.
Should I keep backups forever?
Generally no. Indefinite retention increases storage costs, increases the surface area for data breaches (old backups contain old data that may include former customers' personal information), and may violate data protection regulations. Define a maximum retention period based on your business needs and regulatory requirements, and enforce it through automated pruning.
What is the difference between backup retention and backup frequency?
Frequency is how often backups are created. Retention is how long they are kept. You might create daily backups (frequency) but only keep them for 7 days (retention). The two are independent settings that together define your backup policy. Higher frequency gives you more recovery points; longer retention gives you a longer recovery window.
How do I know if my host's backup retention is adequate?
Ask your host these questions: How often are backups created? How many copies are retained? Are backups stored off-site? Can you restore to any retained backup point? Are backups monitored for integrity? If the answers are vague or unsatisfying, supplement with your own backup strategy or consider a host with transparent backup policies like MassiveGRID.
Can I have different retention policies for files and databases?
Yes, and this is often a smart approach. Database backups are typically small relative to file backups, so you can afford to keep more of them. A common strategy is hourly or 4-hourly database backups retained for 48 hours, daily full backups retained for 7 days, and weekly full backups retained for a month. This gives you fine-grained database recovery (where most critical data lives) without the storage cost of full account backups at the same frequency.