Website Backup Retention Guide for Small Sites

A backup that exists for one day is not a backup strategy. It is a recent copy that may or may not help when you discover a problem too late. This website backup retention guide is for site owners who need a practical policy, not a sales pitch for expensive managed hosting.

Retention means how long you keep backup copies before deleting them. The right period depends on how often your site changes, how quickly you notice failures, and how much storage you can afford. A static portfolio and a WordPress store should not use the same rules.

What Backup Retention Actually Protects Against

Most people think backups are for server crashes. Server failure matters, but it is only one reason to keep older copies. The more common problems are human mistakes: deleting a directory, overwriting a theme, breaking a migration, installing a bad plugin update, or cleaning a database table that should not have been cleaned.

There is also delayed damage. A compromised plugin or stolen admin account can sit quietly for days. If you retain only the latest backup, that backup may contain the same malware or damaged files as the live site. Older restore points give you options.

Retention is not the same as backup frequency. You might create a database backup every six hours but retain only the most recent seven days of those copies. You might also keep a monthly full backup for a year. Frequency determines how much work you could lose. Retention determines how far back you can go.

Two terms make this easier to reason about. Your recovery point objective, or RPO, is the maximum amount of recent data you can lose. If your store can tolerate losing four hours of orders, your backup schedule needs a restore point at least every four hours. Your recovery time objective, or RTO, is how long you can tolerate being offline while you restore and fix the site.

Set Retention by How Your Site Changes

Start with the data, not a generic rule. A brochure site that changes once a month has low write activity. Its files and database can usually be backed up daily or weekly, provided you take a copy before any update or redesign.

A blog with comments, user registrations, or frequent publishing needs more regular database backups. The database is where posts, comments, settings, accounts, and often e-commerce data live. A daily full backup may be enough for the files, while database dumps should run more often.

Stores, membership sites, booking systems, forums, and Nextcloud instances are different. They generate customer data all day. Losing a day of orders or uploads is not merely inconvenient. Back up the database frequently, and make sure uploaded files are included on a schedule that matches actual use.

For most small self-managed sites, a layered policy works well:

• Keep 7 daily backups for short-term mistakes and failed updates.
• Keep 4 weekly backups for issues noticed later in the month.
• Keep 12 monthly backups for slow-burn problems, audits, and major rollback needs.
• Keep one backup before every significant change, such as a CMS upgrade, migration, or custom code deployment.

That is a starting point, not a law. If a site changes constantly, use more frequent database copies. If it is a small static site, fewer backups may be perfectly reasonable. Do not keep hundreds of identical copies just because a tool makes it easy.

Separate Full Backups From Database Backups

A full website backup generally includes web files, uploads, databases, configuration files, and mail data if your mailbox is hosted with the same account. It is the most useful form of recovery, but it can consume storage quickly.

Database-only backups are usually smaller and faster. They are useful when content, transactions, user accounts, or application settings change frequently. But a database dump alone cannot restore missing uploads, a modified .htaccess file, or a broken application deployment.

Use both when the site has active data. A common arrangement is daily full backups plus database backups every few hours. For a low-activity WordPress site, daily database and file backups may be enough. For a static documentation site built from Git, repository history may cover source changes, while an occasional archive protects the deployed environment and configuration.

Do not confuse version control with a complete backup. Git does not automatically preserve production databases, user uploads, email, server-side secrets, or changes made outside the repository.

Storage Limits Are Part of the Decision

Long retention costs disk space. That is not a hidden industry secret. A 2 GB full backup kept daily for 30 days consumes roughly 60 GB before compression and duplicate handling. On a small hosting plan, storing every backup beside the live site is a bad plan. A disk failure, account issue, or accidental deletion can take both the site and its backups with it.

Keep at least one copy outside the hosting account. This can be object storage, a separate server, a NAS at home, or another provider. The location matters less than independence. If one account is compromised or one storage system fails, the other copy must remain available.

The practical target is the 3-2-1 principle: three copies of your data, on two different types of storage, with one copy offsite. Small projects do not need enterprise machinery to follow the spirit of it. A production copy, local backup archive, and encrypted offsite copy is already much better than trusting one control panel.

Before pushing backups to external storage, encrypt them. Website archives can contain customer information, credentials, database records, and private uploads. Use a backup tool with encryption or encrypt archives before transfer. Store the encryption key separately. An encrypted backup without its key is just a large useless file.

Define What Gets Backed Up

A backup policy should name the data, not merely say “backup the website.” At minimum, include the site files and every database used by the application. Include configuration files, cron definitions where applicable, and uploaded media.

Email needs a separate decision. If your domain mailbox is hosted on the same server, determine whether your backup process includes mailboxes and whether you actually need long-term mail retention. Mail can grow fast, and it may have legal or privacy implications. Do not retain it for years by accident.

Also exclude disposable data when it is safe to recreate. Application caches, temporary sessions, build artifacts, and package caches can inflate archives without improving recovery. Be careful with exclusions. An uploads directory can look like generated content but may be the only copy of customer files.

Write down the answer to one blunt question: if this server disappeared right now, what would you need to rebuild the site? Back up that.

Test Restores Before You Need One

A successful backup job only proves that a file was created. It does not prove that the archive is complete, that credentials work, or that the application will run after restoration.

At least quarterly, restore a backup into a test location. Confirm that files extract, the database imports, media loads, pages render, and you can log in. For a store or app, check a recent order, account, or uploaded file. Time the process. If restoring takes six hours but your business can only tolerate one hour of downtime, your retention policy is not the only problem.

Keep a short recovery note outside the server. Include where backups live, which databases belong to which site, the restore order, DNS details, and where encryption keys are stored. This is not bureaucracy. It prevents you from trying to remember critical details during an outage.

A Simple Policy for a Typical Small Site

For a small WordPress, Drupal, or Laravel project, daily full backups retained for seven days, weekly copies retained for four weeks, and monthly copies retained for 12 months is a sensible baseline. Add database backups every four to six hours if users create valuable data during the day. Take an extra backup before updates, migrations, and cleanup work.

Review the policy after major changes. A site that starts accepting payments, collecting files, or sending email has different recovery needs than the hobby project it used to be. Ular.Host users should be especially realistic about this: low-cost self-managed hosting gives you room to control the stack, but it does not remove your responsibility to keep copies you can restore.

Your best retention policy is not the longest one. It is the one that preserves enough history, fits your storage budget, stays offsite, and has been restored successfully at least once. Set it, document it, then test it before the bad day makes the decision for you.