Website backups: why they matter, what to copy and how to restore

Why a website needs backups of its own

Most website disasters are ordinary. A plugin with a known vulnerability is exploited and files are changed. An update breaks the checkout. Someone deletes the wrong page, or an import overwrites the product catalogue. A disk fails, or a whole datacenter goes dark. The hosting account is suspended over an unpaid invoice, locked after a compromise, or closed when an agency relationship ends and nobody moves the site. The WordPress handbook is blunt about it: problems will happen, and a backup of the database and files is what lets you put things back.

Each of those failures asks something different of the backup:

The host's own backup handles the middle rows well. The first depends on how far back it reaches, and the last two are the reason to keep a copy of your own.

What a website backup must include

WordPress's documentation splits a site into two parts, the database and the files, and says you need both to restore it. A file backup does not contain the database, because MySQL or MariaDB keeps it outside the WordPress directory, and a database export does not contain a single image. The same split applies to Drupal, Magento, Laravel or any other application with a database behind it. A complete website backup covers six things:

For WordPress, the files that matter most are the wp-content directory (themes, plugins and uploads), wp-config.php, which holds the database connection details, and the .htaccess file. WordPress core can be downloaded again. The handbook also sets the order: back up the database first and the files straight after, so the two form one set, and restore the other way round, files first and then the database.

DNS deserves its own copy. If the records are deleted or edited by mistake, the site and its email disappear while every server is healthy. Export the zone from your DNS host after every change and store it with the backups: Cloudflare, for example, exports all records as a zone file from the dashboard or its API. Where a provider has no export, copy the records by hand. Certificates are the one thing you can skip, since they are reissued rather than restored (see how to renew an SSL certificate).

Finally, write down what the site depends on but does not contain: the payment gateway and its webhooks, the transactional email service, licence keys for premium plugins, and who holds the registrar login. None of it is in a file backup, and all of it is needed to bring the site back.

Host snapshots and off-site copies: why you need both

Almost every host offers backups, and they are worth having: automatic, and usually the fastest way to roll back. What they share with your site is the provider, and often much more. Read your host's documentation for three things: where the copies are stored, how long they are kept, and whether you can take one out. Three examples, as documented in September 2026:

• DigitalOcean Droplet backups are crash-consistent disk images, taken as often as every four hours and stored in the same datacenter as the Droplet. They do not include attached volumes, they are not encrypted at rest, and they cannot be downloaded. DigitalOcean itself suggests application-level backups for busy databases, because a crash-consistent backup saves what is on disk, never what is in memory.
• Kinsta stores each backup on the same host machine as the site, as a snapshot of the files, database, redirects and Nginx configuration. Copies to Amazon S3 or Google Cloud Storage are a separate add-on, weekly or monthly.
• WP Engine keeps backups off the server, on Amazon S3 in the same region as the site, encrypted, for 30 days. There is no automatic export to another service, and WP Engine asks that your own extra backups never sit on the same server as the website.

None of these is careless; each protects well against the failure it was designed for. None of them protects you from losing the account itself, through an unpaid invoice, a stolen hosting login or a dispute with the agency that holds it. And a copy in the same building shares the building's fate. When fire broke out at OVHcloud's Strasbourg site on 10 March 2021, the power was cut to all four datacentres on the site, and the 14,046 servers running in SBG2 were destroyed. Copies kept in the other buildings stayed unreachable until they restarted, gradually, from 17 March.

So keep both. The host's backup is your fast rollback for everyday mistakes. The off-site backup lives with a different provider, in a different account with different credentials, where nothing that happens to your hosting can reach it. The WordPress handbook makes the same point: most hosts back up the whole server, but it is better to back up your own files.

Website backup methods compared

Backup solutions for websites fall into a handful of methods. None covers everything, which is why most sites combine two:

The usual pairing is the host's backup for quick rollbacks, plus either a plugin or a server-level job that sends the database, files and configuration off-site. The WordPress section below covers both.

Apply the 3-2-1 rule to a website

The 3-2-1 rule that CISA publishes is the usual yardstick: keep three copies of important data (one primary and two backups), on two different types of media, with one copy off-site. For a website it translates like this:

1. Copy one is the live site.
2. Copy two is the host's backup, quick to restore from.
3. Copy three is the independent copy, in object storage or on a backup server with another provider: off-site, on different infrastructure, under different credentials.

"Two types of media" is hard to read literally in the cloud. The point behind it is that one failure, whether a storage system, a provider or a compromised account, must not be able to take out both backups. Some teams add a fourth copy: a periodic download to an office NAS, or an immutable copy that cannot be deleted before its retention date. How many copies to keep for everything a business runs, not only the website, is part of planning a data backup strategy.

How often to back up a website: set it by RPO and RTO

How often to back up is a business decision expressed in two numbers, both defined in NIST's contingency planning guide, SP 800-34:

• Recovery point objective (RPO): the point in time to which data can be recovered, given the most recent backup. For a website, it is the orders, form entries, comments and edits you would have to recreate by hand.
• Recovery time objective (RTO): the longest a system can stay unavailable before the impact becomes unacceptable. For a website, how long it can be down.

The WordPress handbook's baseline is weekly backups for small sites and daily ones for busy sites, and always one before an upgrade. Start there and tighten it wherever the site takes in data:

These schedules are examples to adapt, not rules. The pattern behind them is to back up the database more often than the files: it is usually small and changes constantly, while uploads are large and change slowly. The tools reflect that. UpdraftPlus can run every 2, 4, 8 or 12 hours, daily or less often; Jetpack VaultPress Backup adds real-time backups after events such as a published post or an update, and backs up WooCommerce orders in real time; and a cron job on the server can dump the database every hour.

The RTO decides where you restore from. Rolling back to the host's snapshot of last night is usually the quickest route. Rebuilding on a new server from the off-site copy means provisioning the server, restoring the configuration, downloading the uploads, importing the database and changing DNS. Time that rebuild once, in a drill, before you promise anyone an RTO.

How long to keep website backups

Retention decides how far back you can go, and it has to reach past the problem you notice late. Google's guidance for site owners notes that hacks are often invisible to users, and Mandiant's M-Trends 2026 put the global median dwell time at 14 days across its 2025 investigations, up from 11. CISA adds that rolling backups can silently copy corruption or malware from the live files into the backups. If every restore point is newer than the break-in, restoring brings the attacker back with the site.

Compare that with common defaults. DigitalOcean keeps daily backups for seven days and weekly backups for four weeks; Kinsta keeps the backups it takes before automatic updates for three days; WP Engine keeps 30 days. A seven-day window of daily backups cannot reach back past a two-week compromise.

A tiered retention works for most sites: daily restore points for a few weeks, weekly ones for two or three months, and monthly ones for a year. That reaches well past the 14-day median dwell time without storing a year of daily copies. Keep the tiers in the independent copy, where retention is yours to set, and match them to any legal limits on how long you may keep customers' personal data.

Encrypt backups and control who can reach them

A website backup is a complete copy of the business: customer records, password hashes and, in wp-config.php or .env, the credentials for the database and every connected service. Treat it with the same care as the live server.

1. Keep backups out of the web root. An archive left in a public directory can be downloaded by anyone who guesses its name. The OWASP Web Security Testing Guide tests for exactly this (WSTG-CONF-04), because a backup archive can hold every file inside or even outside the web root and hands an attacker the application's source. If a plugin keeps a copy on the web server (BackWPup, for example, lists the website server among its destinations), check where that folder is and that it cannot be downloaded.
2. Encrypt the copies. Host backups are not always encrypted, as DigitalOcean's limits page shows. Encrypt before the data leaves the server: restic requires a password for every repository and warns that losing it means the data is irrecoverably lost, and BorgBackup offers authenticated encryption. Keep that password in a password manager, never only on the server. If you use a plugin, check whether it encrypts at all: BackWPup, for example, lists encryption in its Pro version.
3. Separate the credentials. The backup store should not accept your hosting login, and the web server should hold a credential that can add backups but not delete them. restic's REST server has an append-only mode for exactly this case, so an attacker who takes over the server being backed up cannot wipe its backups. Object storage can go further with a retention lock such as S3 Object Lock, which uses a write-once-read-many model to keep objects from being deleted or overwritten for a set period.
4. Prune from somewhere else. Deleting old snapshots needs full access. With an append-only repository, restic's documentation recommends running forget and prune from a separate, well-secured machine, and using a time-based keep-within policy so an attacker cannot push the good snapshots out by flooding the repository with junk ones.

Making backups survive a determined attacker (immutable and offline copies, separate admin accounts, deletion alerts) is the subject of our secure backup guide. To find what is already exposed, our security scanning checks the sites you put online for exposed files, panels and backups.

WordPress backup options: the host, a plugin or server-level tools

For WordPress there are three routes, and most sites combine two of them.

Your host's backups

Managed WordPress hosts such as Kinsta and WP Engine take daily backups that you restore from their dashboard, and Kinsta also takes one before plugin and theme updates. Use them for rollbacks, and check where the copies live and how long they stay, as above. Some hosts sell an add-on that sends copies to storage you choose; Kinsta's writes to Amazon S3 or Google Cloud Storage, weekly or monthly.

A backup plugin

A plugin backs up from inside WordPress and sends the archive to remote storage. Three examples, each designed differently:

• UpdraftPlus backs up the database and files on a schedule to Dropbox, Google Drive, Amazon S3 or S3-compatible storage, FTP and others in its free version. The premium version adds automatic backups before updates and incremental backups.
• BackWPup backs up the database and files hourly, daily, weekly or monthly, and can send one backup to several destinations in the same job, including S3-compatible storage, Dropbox, FTP and Microsoft Azure. Its Pro version adds encryption and a standalone restore application that works when WordPress itself will not load.
• Jetpack VaultPress Backup is a service rather than a storage connector. It stores backups on WordPress.com's servers, takes a daily full backup plus real-time backups after changes, and records WooCommerce orders as they happen. It does not back up files outside the WordPress directories or database tables that do not belong to WordPress, and it does not support multisite.

The trade-off is that a plugin runs inside the site it protects. It uses the site's PHP time and disk space, it sees only what WordPress sees, and restoring through it normally needs a working WordPress install, which is exactly what you may not have after a hack. BackWPup's standalone restore application exists for that case; with other plugins, check how a restore works when the dashboard is down.

Server-level tools

With shell access (a VPS, a cloud server or a host that allows SSH), one small job run by cron covers the database, the files and the server configuration, with no plugin involved. mysqldump exports the database; with its single-transaction option it dumps InnoDB tables in a consistent state without blocking the site. Put that option and a database user that can read but not change data in an option file that only the backup user can read, rather than on the command line. Option files drop the leading dashes from option names:

# ~/.my.cnf of the backup user, readable by that user only
[client]
user=site_backup
password=REPLACE_WITH_A_LONG_RANDOM_PASSWORD

[mysqldump]
single-transaction

The job itself then dumps the database to a folder outside the web root, readable by the backup user only (that is what the umask 077 line does), and sends it, with the site files and the web server configuration, to an encrypted restic repository. restic reads the repository location and the password file from the RESTIC_REPOSITORY and RESTIC_PASSWORD_FILE environment variables:

#!/bin/sh
set -eu
umask 077
mysqldump wordpress > /var/backups/site/wordpress.sql
restic backup /var/www/example.com /etc/nginx /var/backups/site

WP-CLI's wp db export is the WordPress-aware alternative for the dump: it runs mysqldump with the credentials from wp-config.php and passes mysqldump options through, but it skips MySQL option files unless told to load them. Whichever you use, alert when the job fails or stops running. A backup job that stopped silently looks exactly like one that works, until the day you need it.

How to restore a website after a failed update

A failed update is an everyday reason to restore, and an easy one to make worse. Since WordPress 6.6, released in July 2024, WordPress rolls back failed plugin auto-updates on its own. That is a safety net for plugin auto-updates, not a backup: a theme update, a manual change or an update that breaks the checkout without crashing the site still needs the copy you took just before. The WordPress handbook says to back up the database before every upgrade for exactly this reason.

Then restore as little as possible. A full snapshot rolls everything back: Kinsta's documentation, for example, notes that a restore returns the files, database, redirects, Nginx configuration and domains to the moment of the backup. On a store, that also discards every order placed since.

1. Write down what changed and when, then take a fresh backup of the broken site. It still holds today's orders and form entries.
2. If only code changed, put back the previous version of the plugin or theme from your backup or repository, and leave the database alone.
3. If the update also changed the database, restore the pre-update database on staging first, then carry across the orders, accounts and entries created since the backup, or re-enter them.
4. Try the update again on staging, find what broke, and only then update the live site.

How to restore a website after a hack

After a hack, the restore is one step in a longer job. Google's guide to cleaning a hacked site starts with a check: was the backup created before the site was hacked? If it was, work in this order:

1. Keep the evidence. Take one more backup or disk image of the infected site and label it as infected. The WordPress hacked-site FAQ recommends this even though the copy is infected, in case the cleanup goes wrong.
2. Find the way in: the vulnerable plugin, the stolen password or the exposed panel. A restore without that fix leaves the same door open.
3. Restore the last clean copy, files and database, from before the first sign of compromise, which is not necessarily the newest backup.
4. Update everything: WordPress core, plugins, themes and, if you run the server, the operating system. Remove plugins and themes the site no longer uses.
5. Reset every credential: SFTP, the hosting panel, the database and every WordPress administrator. Generate new secret keys in wp-config.php, which signs out anyone still logged in.
6. Bring back newer content with care. If the clean backup is older than you would like, compare it with the infected copy and carry across only content you have checked, such as specific images or orders, never whole directories.
7. Scan, then close the loop. Scan the restored site, ask Google to recrawl the cleaned pages in Search Console, and change the passwords once more when you are sure the site is clean, as the WordPress FAQ advises.

Test restores on a staging copy, and write the runbook

A backup job that reports success proves that data was copied, not that the site can be rebuilt from it. NIST's guide says backup media should be tested regularly to confirm that files can be retrieved without errors or lost data, and the WordPress handbook recommends checking automated backups with a manual one now and then to confirm the process works. For a website, the test is a full restore onto a staging copy:

1. Set up a staging site on its own hostname, behind a password. Google's documentation notes that password protection keeps content out of its search results, so the copy never competes with the real site.
2. Restore from the independent off-site copy, not the host's snapshot. It is the copy you will depend on in the worst case, and usually the one you have exercised least.
3. Restore the files, then import the database, the order the WordPress handbook recommends.
4. Point the copy at its own address. WP-CLI's search-replace rewrites URLs in the database and handles PHP serialized data correctly; run it in its dry-run mode first.
5. Tell WordPress it is staging with define( 'WP_ENVIRONMENT_TYPE', 'staging' ); in wp-config.php. Plugins and themes can read it and change their behaviour, and hosts are asked to set it on their staging environments. Also stop the copy from acting on real customers: turn off outgoing email and scheduled jobs, and switch payment gateways to test mode.
6. Check it the way a visitor would: the home page, a recent post or order (which shows your real RPO), a sign-in, a form and a test checkout.
7. Time it. The time from starting the restore to a working site is your real RTO. If the plan says two hours and the drill took six, change the method or agree on six.

Write the runbook while you run the drill, so that the next person can repeat it without you. Keep it short:

• where each backup lives, and where the credentials and the encryption password are kept (never the secrets themselves);
• the restore steps and commands, in order, for three cases: a rollback on the same host, a restore after a hack, and a rebuild on a new server;
• the DNS changes a move needs, and who can make them;
• who to call (the host, the DNS provider, the developer) and who decides to take the site offline;
• the date and duration of the last successful drill.

Keep a copy of the runbook outside the hosting account, because the day you need it may be the day the account is gone. Repeat the drill after big changes, and on a calendar: quarterly is a sensible default for a business site.

If you would rather hand this over, our hosting and maintenance service keeps three copies on two kinds of storage, one off-site and immutable, writes down the RPO and RTO for each site, and runs restore drills that measure how long recovery really takes. Backups are the last line of defence; our guide to securing a website covers the updates, admin accounts and firewall that make a restore less likely to be needed.