Start with the work you could afford to lose
A backup schedule is a decision about acceptable loss. Imagine discovering a broken site just before your next backup runs. How much new content, form data or configuration work would you have to recreate? A brochure site that changes once a month may be comfortable with less frequent backups than a site receiving orders or publishing every day. The right interval depends on what changes, not simply on the size of the site.
Make a short list of the site’s moving parts before choosing a schedule. Include uploaded files, images, themes or templates, plugins, settings and, if the site uses one, its database. Some services hold important information outside the website itself, such as form submissions or subscriber lists. Check whether those services provide their own exports. A copy of the visible pages alone may not be enough to rebuild a working site.
Match the schedule to the pace of change
Choose a regular schedule that limits rework to an amount you could realistically manage. For a rarely updated site, a weekly backup may be a reasonable starting point. A site with frequent edits may need daily backups, while a busy site handling important new records may need them more often. Automated backups help because they do not depend on someone remembering a task, but someone should still check that the jobs complete.
Add a separate backup before changes that could affect many parts of the site: a major software update, a redesign, a migration or a bulk content edit. Keep that copy until the change has been checked and a newer, working backup exists. If your host offers backups, find out what they include and how long they remain available. A host’s schedule may not match your editing schedule, and a backup that expires quickly may not help with a problem discovered later.
Store at least one copy away from the website
A backup kept only on the same server as the live site shares some of the site’s risks. A server failure, account lockout or mistaken deletion could affect both. Choose a location you can access independently, such as a separate cloud storage account or an offline drive. The best option is one your team can maintain and retrieve from without relying on the broken website.
Treat backup files as sensitive. They may contain account details, private submissions or other information that should not be publicly accessible. Limit who can open or delete them, use strong account protection, and consider encryption where your backup tool supports it. Write down which account holds the backups and who can access it, but store credentials securely rather than placing them in a shared site document. If one person manages the site, plan how an authorized colleague could find the backups when that person is unavailable.
Keep enough history to catch late discoveries
Keeping only the newest copy can leave you with a backup of a problem. A damaged file or unwanted change might go unnoticed for several backup cycles. Retain a small sequence of recent backups, plus a few older copies if storage allows. For example, you might keep several daily copies and a smaller set of weekly ones. Choose retention based on how quickly someone is likely to notice trouble and how much storage the files use.
Check whether your backup service automatically removes older files, and avoid setting a limit without knowing what it will delete. You also need a plan for outdated backups that contain personal information: keeping every copy forever creates a storage and privacy burden. Record your chosen schedule, storage location and retention period in a brief maintenance note so future site managers can understand the plan.
Test the restore, not just the backup
A successful backup notification confirms that a job ran; it does not prove you can recover the site. Periodically restore a copy to a safe test location, or follow your host’s supported restore procedure without overwriting the live site. Check that pages load, images appear, links behave as expected and essential features work. For a database-driven site, confirm that the restored content reflects the date of the backup.
Finally, write a short recovery checklist: where the files are, which backup to choose, who has access and what to check after restoration. Review it whenever the site changes platform, host or administrator. A modest backup plan that is checked and understood is more useful than an elaborate schedule no one knows how to restore.
