How often should I back up a website, and where should backups be stored?

Business Tech & Tools

How often should I back up a website, and where should backups be stored?

The short answer

Back up often enough that you can afford to lose everything since the last copy. A site that changes monthly may need weekly backups. A store, membership site, booking system, or busy publication may need daily or more frequent database backups.

Keep at least one independent copy outside the live hosting account, retain several restore points, and test that you can restore them. A host backup is useful, but it should not be your only plan.

Set frequency by acceptable loss

Ask, “If the site failed at 4 p.m., how much work or customer activity could we recreate?”

Site activity Reasonable starting point to evaluate
Rarely changed brochure site Weekly and before every change
Weekly articles and forms Daily database, weekly full backup
Daily content or inquiries stored in WordPress Daily or more frequent database backup
Store, membership, booking, or course site Frequent database backups based on transaction volume, plus daily full backup
Major update or migration Fresh manual recovery point immediately before the change

These are starting points, not laws. The right schedule depends on how quickly the data changes and how costly reconstruction would be.

Back up both halves of WordPress

The database contains posts, pages, settings, users, orders, and other structured information. Files include WordPress code, themes, plugins, uploads, and configuration. You may need both to reproduce the site.

WordPress’s backup handbook explains that a WordPress site consists of database content and files and provides separate backup and restore guidance for them. See WordPress’s official backup documentation.

Also inventory anything outside WordPress, such as DNS records, domain ownership information, email-platform forms, payment settings, and custom code repositories.

Use three kinds of separation

Account separation

Keep a copy outside the hosting account. If the hosting login is compromised, suspended, or inaccessible, a backup stored only there may be unreachable too.

Time separation

Retain multiple dates. A broken plugin, infection, or bad edit may go unnoticed long enough to be included in the newest backup.

Access separation

Limit who can delete backups, protect the storage account with two-factor authentication, and monitor failed jobs. If one administrator account can erase both site and every backup, the plan has a single point of failure.

Record what “successful” means

A green “backup complete” message does not prove the archive includes what you need. For every backup job, document:

  • files and databases included.
  • schedule and timezone.
  • retention period.
  • destination.
  • encryption or access controls.
  • failure alerts and who receives them.
  • restore steps.
  • last restore test.

Check storage capacity and billing. Automated jobs can quietly stop when a destination is full, a token expires, or a payment method fails.

Test a restore

At least periodically, restore a copy into a safe nonproduction location. Confirm that pages, media, forms, users, and critical functions return. Note how long the process takes and what credentials or provider help it requires.

Do not overwrite the live site merely to prove a backup works. Use staging or a temporary environment unless you are recovering from a real incident.

Sources and further reading

A free next step

Not sure which business fits you yet?

The free Freedom Path Assessment can help you compare your strengths, schedule, income goals, and preferred way of working before you commit to a business direction.

Take the Freedom Path Assessment Free

Related Questions

Related WAHMN resource

If you want to turn this website task into a service or build a stronger process for your own site, this system walks through the work in more depth. See Website & Landing Page Build System.

← All questions