Website Backups: How to Set Up Backups and Restores in 2026

A backup exists to return a website to service, not merely to produce a “job completed” notification. A damaged archive, a copy stored beside production, or a process nobody can execute provides little protection. A reliable system covers files, databases, configuration, independent storage, monitoring, and regular recovery tests.

Short answer

Most business websites should have automated daily copies of both files and databases, at least one copy outside the production server, and alerts for failed jobs. An ecommerce website or service receiving frequent orders may need database copies every 15–60 minutes. The correct frequency depends on how much new data the business can afford to lose, not simply on the CMS.

The practical baseline is the 3-2-1 rule: three copies of important data, two different storage types or environments, and one copy offsite. CISA recommends securing and testing backups rather than merely creating them.

What a complete website backup includes

• Website files: application code, themes, plugins, uploaded images, documents, and media.
• Database: pages, products, orders, users, CMS settings, and some integration data.
• Configuration: PHP version, environment variables, web-server rules, cron jobs, and cache settings.
• DNS and SSL: current DNS records, certificate renewal steps, and registrar access.
• Email: mailboxes and messages when they share the hosting account.
• Integrations: essential CRM, payment, delivery, analytics, and webhook configuration without exposing secrets in plain text.

A file-only copy cannot restore current orders, while a database-only copy cannot restore media or code. For a dynamic website, files and database copies should represent a consistent point in time.

RPO and RTO: decide before choosing tools

Google Cloud defines RPO as the maximum acceptable period of data loss and RTO as the maximum acceptable time that an application can be unavailable.

If an online store has a 30-minute RPO, one daily database backup is insufficient: almost a day of orders could disappear. If its RTO is two hours, downloading a large archive from slow storage and rebuilding a server manually might miss that target.

Website type	Starting RPO	Starting RTO	Practical schedule
Rarely changed landing page	24 hours	4–8 hours	Daily and before changes
Company website or blog	12–24 hours	2–4 hours	Daily, with longer weekly retention
Ecommerce website	15–60 minutes for database	1–2 hours	Frequent database copies, daily files, pre-update copy
Online service or customer portal	Business-defined, sometimes minutes	SLA-defined	Replication, transaction logs, and a dedicated DR plan

These are starting points, not universal standards. Lower RPO and RTO targets usually require more complex and costly infrastructure.

Applying the 3-2-1 rule to a website

The first copy is the production website. The second can be an automated backup in the hosting provider’s backup platform. The third should be an encrypted copy in independent cloud storage or on another server.

The offsite copy should not depend on the same account and disk. When production and every archive share one server, a storage failure, account deletion, or compromised credential can affect all of them. CISA also recommends protected offline backups and regular recovery testing in its ransomware guide.

A sensible retention policy

One latest archive cannot protect against a problem discovered a week later. A small business can start with:

• 7 daily copies;
• 4–5 weekly copies;
• 6–12 monthly copies for important systems;
• a separate restore point before CMS, plugin, design, or large import changes.

Retention must reflect data volume, storage cost, contracts, and privacy duties. Deleted personal data may still exist in older archives; WordPress specifically warns administrators to consider this when restoring data.

A recovery test validates the archive, the complete website, and its integrations.

What should be automated

1. Create file and database copies at the required frequency.
2. Encrypt archives in transit and at rest.
3. Send a copy to independent storage.
4. Verify completion, archive size, and checksum.
5. Remove expired versions according to retention rules.
6. Alert the responsible person when a job fails.

Monitoring should also detect a missing result. If the scheduled job never starts, the absence of a backup must trigger an alert.

Why a hosting backup does not remove owner responsibility

Ask the provider to confirm in writing:

• whether it copies files, databases, email, or the whole account;
• frequency and retention;
• whether copies reside in another physical location;
• who can start a restore and how long it usually takes;
• whether restoration costs extra;
• what happens when the hosting account is suspended or closed.

When choosing website hosting, inspect the full backup policy rather than the presence of one feature label. An independent copy also preserves recovery options during a dispute over access or a hosting migration.

Responsibility	Hosting provider	Website owner or technical team
Server platform	Maintains infrastructure under the plan terms	Confirms that the plan can meet RPO and RTO
Provider backups	Creates and retains copies under its policy	Verifies frequency, retention, and restore access
Independent offsite copy	Might not provide one	Configures it separately and protects access
Website after restoration	Usually supports the server only	Tests CMS, forms, payments, CRM, and integrations
Recovery plan and test	Provides tools or support	Names owners, runs the test, and records results

How to test website recovery

An archive is proven only after a successful restore. NIST includes testing in the contingency-planning lifecycle, while Google Cloud recommends validating restored data together with the complete application stack.

Use an isolated technical domain or staging environment rather than overwriting production.

1. Select a specific restore point and record the start time.
2. Restore files, database, and required configuration.
3. Check main pages, sign-in, search, and mobile behaviour.
4. For ecommerce, place a test order and verify cart, payment, email, inventory, and CRM.
5. Test forms, webhooks, scheduled tasks, and analytics.
6. Review logs and measure the actual recovery time.
7. Document the result, problems, owner, and required process changes.

Run a full test at least quarterly for an active business website and after a significant infrastructure change. Increase the frequency when downtime is particularly costly.

Common backup mistakes

• Production and backups share the same server.
• Only files or only the database are copied.
• There is no version history.
• Nobody reviews failure alerts.
• Restoration has never been tested.
• Website and backup storage reuse credentials.
• Configuration and a current recovery runbook are missing.

A one-day implementation plan

Step 1: Inventory

Record the CMS, file and database size, order or content frequency, integrations, owners, and existing backups.

Step 2: Recovery targets

Agree on acceptable data loss (RPO) and downtime (RTO). Do not demand zero loss and zero downtime without pricing the required architecture.

Step 3: Two independent paths

Keep provider backups and add external storage with separate access. Enable encryption and multi-factor authentication.

Step 4: Monitoring and ownership

Name the person receiving errors, the person authorised to restore the site, and the location of the current runbook without placing secret keys inside it.

Step 5: Recovery test

Restore to staging, complete the checklist, and compare the measured recovery time with the RTO. Improve the process, not only the archive.

Website owner checklist

• Are files, database, and critical configuration all covered?
• Is one copy outside the production server and account?
• What RPO and RTO apply?
• How many daily, weekly, and monthly versions are retained?
• Who receives failed-job alerts?
• When was the last full recovery test?
• Were forms, cart, payment, email, CRM, and scheduled tasks checked?
• Is storage protected with encryption, unique credentials, and MFA?
• Is there a current runbook and a backup owner?

Conclusion

A reliable backup is not an archive; it is a tested ability to return the website to service within agreed RPO and RTO targets. A strong baseline for small and mid-sized businesses combines automation, the 3-2-1 rule, independent storage, version history, alerts, and regular recovery tests.

BB STUDIO can audit an existing backup setup, configure independent copies, and run a controlled recovery test. Learn about our hosting with daily backups or contact us for a website-specific technical plan.

Frequently asked questions

How often should a website be backed up?

A static landing page may need one daily copy plus a restore point before changes. An online store may need database copies every 15–60 minutes and daily file copies.

Are hosting-provider backups enough?

They are a valuable first layer, but should not be the only copy. Keep another version in independent storage and confirm the provider’s retention and restore terms.

Should I back up WordPress before an update?

Yes. WordPress documentation points administrators toward scheduled automated backups. Create an additional restore point before updating core, a theme, or a plugin.

What is the difference between a backup and a snapshot?

A snapshot quickly captures a disk or server state. If it remains inside the same infrastructure, it does not replace an independent offsite backup.

How do I know whether a backup works?

Restore it to a test environment, validate the complete website, and measure the recovery time. A successful archive job alone is not proof of recoverability.

---

Prepared by the BB STUDIO team. This article draws on practical experience in website hosting, technical support, and business-site recovery, together with official guidance from CISA, NIST, WordPress, and Google Cloud.