Backup Retention Policy for Websites That Works

Published on August 14, 2026

A backup retention policy for websites should give you several recent restore points, a few older recovery options, and at least one copy outside the server that runs the site. If a plugin update breaks checkout at 10:15 a.m., you need a clean version from 10:00 a.m., not a backup from last Tuesday and a hopeful expression.

The right schedule depends on how often your data changes, how much downtime costs, and how quickly your team can identify when a problem started. A static company site and a busy WooCommerce store should not be protected the same way. The service may be online, but if yesterday's orders, form submissions, or customer changes are missing, it is not fully calm again.

What a Website Backup Retention Policy Must Cover

Retention is not simply the number of backups you keep. It is the set of rules that decides which backup copies remain available, where they are stored, how long they remain there, and when they are deleted.

A useful policy accounts for three separate recovery needs. First, you need fast operational recovery for recent mistakes: a bad deployment, deleted files, a failed update, or an accidental configuration change. Second, you need historical recovery when an issue has been sitting quietly for weeks, such as compromised admin access or infected code. Third, you may need records retained for business, contractual, or regulatory reasons.

Those goals can conflict. Keeping every backup forever creates storage cost, slower backup jobs, and a confusing restore list. Keeping too little saves space right until the one backup you need has already expired. The sensible answer is tiered retention, not one long row of identical daily backups.

Start With Recovery Objectives, Not a Storage Number

Before setting retention periods, define two practical targets: recovery point objective and recovery time objective.

Your recovery point objective, often called RPO, answers how much recent data you can afford to lose. An e-commerce store processing orders throughout the day may need hourly database backups or transaction-aware backups. A brochure site updated twice a month may accept a daily backup, provided critical contact form data is handled elsewhere.

Your recovery time objective, or RTO, answers how quickly the site must be restored. A recent backup stored locally or in nearby backup storage can usually be restored faster than a cold archive. But local copies alone are not enough. A server failure, ransomware event, mistaken disk operation, or account-level compromise can affect the site and its local backups together.

For most business websites, define these targets in plain language. For example: “We can lose no more than one hour of orders, and the storefront must be restored within two hours.” This is much more useful than saying “we do backups daily” and discovering later that daily means once every 24 hours.

Check What Actually Changes

Website files and database data do not change at the same rate. WordPress core files may stay untouched for months, while the database receives orders, comments, bookings, membership changes, and form entries all day.

A complete backup should include application files, databases, configuration files, uploaded media, SSL-related configuration where relevant, scheduled task definitions, and any custom application data stored outside the web root. If a database backup succeeds but the upload directory is excluded, the restored site may function while product images or customer documents quietly disappear.

For a larger application, document dependencies as well. Object storage, mail services, payment systems, external databases, and DNS records may not belong inside a server backup. They still belong in the recovery plan.

A Practical Retention Schedule for Most Websites

A common starting point is to retain frequent backups for a short period and less frequent backups for longer. This provides useful restore choices without making storage usage grow like an abandoned garage.

For a typical small business site, agency-managed site, or marketing site, retain daily backups for 14 to 30 days, weekly backups for 8 to 12 weeks, and monthly backups for 6 to 12 months. Take an additional backup before major changes such as a CMS upgrade, redesign launch, migration, plugin replacement, or server configuration work.

For stores, SaaS dashboards, membership sites, booking platforms, and other database-heavy services, add more frequent database protection. Hourly database backups retained for 24 to 72 hours can be appropriate, followed by daily backups for 30 days, weekly backups for 12 weeks, and monthly backups for 12 months. The exact interval depends on transaction volume and whether the application can consistently back up active data.

Agencies should consider client-specific policies rather than applying one schedule to every account. A restaurant menu site does not need the same retention as a client portal handling uploaded documents. Group sites by risk and business impact, then make the policy visible in the client agreement or service scope.

Keep Pre-Change Restore Points Separate

Automated schedules are not a substitute for deliberate backups before risky work. Create a labeled restore point before updates, migrations, database maintenance, template changes, or server-level adjustments.

Keep pre-change backups for at least seven to fourteen days after the work is complete. Some issues only appear after a billing cycle, a background job, or an integration runs. Once the change is confirmed stable, normal retention can take over.

Follow the 3-2-1 Principle, With Realistic Operations

The classic 3-2-1 model remains practical: keep three copies of data, on two different storage types, with one copy offsite. For website operations, this often means the production data, a backup copy in the hosting environment, and an encrypted copy in independent offsite storage.

The key word is independent. A backup stored on the same virtual server is convenient, but it is not protection from server-level failure. A backup stored in the same hosting account may also be exposed if an attacker obtains account credentials or if a broad deletion action is performed.

Offsite copies should be encrypted in transit and at rest. Access should use separate credentials where possible, ideally with multi-factor authentication and limited permissions. Backup deletion permissions deserve special attention. If ransomware or a compromised administrator can erase production data and every recovery point in one session, the retention schedule will look excellent on paper and helpless in practice.

At kodu.cloud, managed backup and monitoring arrangements can reduce the routine work, but ownership of the recovery requirements should still be clear. Your provider can maintain the system; your business should decide how much data loss and downtime it can accept.

Make Retention Aware of Security Incidents

A short retention window can be dangerous when malware is discovered late. A site might be compromised for several weeks before suspicious redirects, spam activity, or unauthorized admin accounts become visible. If every backup is overwritten after seven days, you may only retain infected copies.

This is why weekly and monthly restore points matter. For higher-risk environments, consider immutable or write-protected backup copies for a defined period. Immutability does not make a backup magically correct, but it can prevent an attacker from changing or deleting it after compromise.

Keep logs of backup success, failure, deletion, and restore activity. Alerts should reach a person who can act, not an inbox that has become a small digital museum. Monitoring should also check storage capacity, backup duration, and unusual changes in backup size. A suddenly tiny backup can indicate an excluded database or failed file collection; a suddenly huge one may indicate logs, cache files, or unwanted data entering the backup set.

Test Restores Before You Need One

A backup is only a recovery tool after it has been restored successfully. Backup job status confirms that data was copied. It does not prove that the archive is complete, readable, compatible with the current environment, or usable under time pressure.

Test a restore at least quarterly for a standard business website and more often for revenue-critical applications. Restore into a staging environment or isolated location where it cannot overwrite production. Confirm that the application starts, the database connects, media files load, forms work, scheduled tasks are present, and critical user actions behave normally.

Record how long the restore took and any manual steps required. If recovery depends on one developer remembering a database password, a DNS sequence, and a five-year-old shell command, that is not a plan. It is a folklore artifact.

Document Exceptions and Review the Policy

Your retention policy should fit on a page and answer a few direct questions: what is backed up, how often, where copies are stored, how long each copy is retained, who can request a restore, and how restore testing is documented. Also name systems that are not included, so nobody assumes a backup covers a third-party service it cannot access.

Review the policy after a major site change, new compliance requirement, traffic growth, or recovery incident. More frequent backups may become necessary as an online store grows. On the other hand, storing multi-year daily backups for a low-change site may be cost without useful protection.

Set the retention policy around the moment you will need it most: a rushed Friday deployment, a malicious plugin update, or a disk problem at the wrong hour. Clear restore points, an independent copy, and a tested process give your team something better than confidence. They give you a workable next step.

Andres Saar Customer Care Engineer