How to back up your website (and restore it when something breaks)

Back up the files, data and settings you'd need to recover your website. Keep copies off the live site, on an automated schedule matched to what you can afford to lose. Then test a restore, because a success email alone doesn't prove your site can come back.

Site already broken? Skip to the recovery section below. Preserve what's there and get the right help before you overwrite anything. A plugin installed today can't recover history it never captured.

What a backup has to do

A useful backup rests on four foundations:

• complete coverage of what you'd need to recover

• a schedule that runs without anyone remembering

• protected copies kept apart from the live site

• a tested way to restore the site and its data

Testing proves recovery for the scope and date you tested. Retest when either one changes.

Backups reduce recovery risk. They can't prevent every incident or promise zero data loss. Restoring a website also won't undo stolen data, a payment already taken or emails another system already sent.

Sites usually need a restore after one of these:

• an update that breaks the site

• content or files deleted by mistake

• a hack or malware infection on the site

• a failure at the hosting company

• a move to a new host or platform that goes wrong

• a broken integration with another system

What the backup must include

A self hosted WordPress site needs two matching parts. WordPress's own guidance names them as the database and the files. You need both for a full restore.

Files mean your uploads, the site's software and its configuration. The software side includes themes, plugins and any custom code. Some of it can be reinstalled from verified sources instead of being backed up. Write down anything you leave out.

The WordPress export tool is different. It saves your written content, like posts and pages, as an XML file. Your design and settings aren't part of it. It's a content transfer tool, not a full backup.

Ask your developer or host which database tables and storage hold your forms, orders and bookings. A common mistake is trusting a generic "all files" tick. It doesn't prove cloud stored media or custom tables were captured.

List everything the business relies on:

Add a named owner to each row when you build your own. DNS settings are the records that point your domain at your website and email. A website plugin won't protect data held in those other services.

Record access details securely, outside the website. Configuration files can hold secret keys, so protect them like business data.

A complete recovery set may be several related files, or pieces that each hold only recent changes. The restore process has to find and check every piece it needs.

Build a resilient backup strategy

Start with the 3-2-1 rule. ASD's ACSC recommends it: three copies of your data, on two different media, with one copy offsite. Your live site's data counts as one of the three. Media here means storage types, like disk and tape.

Two copies on the same disk go down together. Two cloud brands alone don't prove two media types either. Use the rule as a starting point. The real goal is copies that can't all fail at once.

Offsite and separate access are different things. If a stolen login for the live site can erase every backup, distance won't save you.

ASD's Essential Eight is a staged government security framework. Even its entry level calls for ordinary user accounts to be blocked from changing or deleting backups. It also expects tested restores that bring every part back to the same point in time. Use it as a guide in proportion to your risk. It isn't a legal rule for every small business.

Here, agency means your host or developer, whoever manages hosting for you. The map shows who does what. It isn't proof of two media types.

An offline or immutable copy suits some risks. Immutable means locked against changes or deletion for a set period under its settings. That doesn't make the copy private, clean or permanent. For ransomware, the same ACSC advisory recommends daily backups kept offline and encrypted.

Use separate recovery logins with multi factor authentication (MFA) and tightly scoped access. Keep a protected way to recover encryption keys. The plan has to work even if the hosting account, WordPress login or usual inbox is down. Keep a second contact route for your host and backup provider too.

Cloud sync isn't automatically a backup with history. It can copy a deletion or corruption straight across. A snapshot, meaning a point in time copy of the server, may sit in the same account. Ask what survives if you lose that account.

Set up WordPress backups

Here's one documented route, using UpdraftPlus as an example rather than the only option. First confirm you have permission and the plugin supports your versions. Check your storage needs, and whether your host already runs backups.

UpdraftPlus's own setup steps worked like this when we checked in October 2026:

1. Go to Settings, then UpdraftPlus Backups, then the Settings tab.

2. Turn on email reporting.

3. Choose your remote storage and connect it.

4. Set the file and database schedules, and how many copies to keep.

5. Review what's included in the file backup. Save your settings.

6. On the Backup / Restore tab, choose Backup Now. Select files, database and remote storage.

Wait for the job to finish. Read any warnings. Then confirm you can actually retrieve the backup set from the remote storage. A common mistake is treating a started job or an empty folder as a finished backup.

Check the default exclusions against your inventory. Watch for these, which can fall outside them:

• configuration files that hold site settings

• folders outside the usual WordPress structure

• media files kept in outside cloud storage

• custom database tables added by plugins

Next, run a test restore in isolation, as described below. UpdraftPlus's own documentation has the current restore steps. When we checked in October 2026, its FAQ warned that a restore overwrites your present data. If you restore parts one at a time, do the database last. Never roll back the live site as a test.

Take a fresh, labelled backup before any big change, like a major update or migration. Make sure it finishes before the change starts. Keep those special copies only as long as you have a reason to.

Host backups and tool choices

Your host may already back up your site. Ask exactly what it covers before you rely on it:

Get the answers in writing. A feature label isn't a recovery promise. Also ask how outside services are handled, and who takes over if a restore fails.

Each type of backup protects something different:

In October 2026, UpdraftPlus came in a free version and a paid Premium edition. Premium adds incremental backups, plus automatic backups before updates. Incremental backups copy only what's changed since the last run. Check the edition you choose supports your storage and the features you need.

Jetpack VaultPress Backup is a paid managed service with real time backups. Check its storage, history and support for your setup. Ask whether restores need server access details from your host. Its WooCommerce feature comes up in the recovery section below.

Don't stack backup plugins without a reason. If you run more than one, coordinate their schedules and storage. One independent recovery route beats three copies of the same weakness.

Free tools still need setting up, monitoring and testing. Paid tools still need acceptance checks. A promise of instant recovery on a sales page isn't a restore time anyone has agreed to.

Choose frequency and retention

Start with two plain questions. How much recent data could you lose? How long could the site be down? Those answers are your recovery point objective (RPO) and recovery time objective (RTO). They're targets to test, not guarantees that come with a plan.

Different sites need different schedules:

Where your records live and how much loss you can accept should set the schedule. Treat the table as a starting point.

A daily backup can expose nearly a day of changes. If a job fails, it exposes more.

An incremental backup copies only changed data. Real time describes how often copies happen. Neither one guarantees zero lost orders. Test capture delays, coverage and dependencies either way.

Frequency and retention are separate decisions. Several historical copies help when a problem is found late. A common example is seven daily, four weekly and three monthly copies. That's an example, not a rule or a legal minimum.

Base retention on four things:

• how long problems take to notice

• how long you need to keep business records

• how sensitive the personal data is

• what the extra storage will cost you

Confirm which copies survive when old ones are deleted on schedule. Incremental copies can depend on an older full copy. If that copy goes, they may not restore.

Watch the age of your newest usable copy, not just success emails. Protection can fail silently through:

• a schedule that quietly stopped running

• an expired login to your storage

• a storage quota that filled up

• a database left out of the job

• an upload to storage that never finished

Name someone to act when the newest copy gets too old or a report doesn't arrive. A job that never starts may never send a failure email.

Backups on hosted platforms

Hosted platforms keep their own systems running to protect the service. Your accidental edits are another matter.

None of them covers every asset on every platform. CMS below means the platform's content system, where items like blog posts live. Here's how four popular platforms compare:

For each one, note what depends on the account, what you can get elsewhere and what you'd rebuild.

Shopify

On Shopify, export CSV files and download your theme. Shopify also points to backup apps from its App Store. Check app data, media and licences separately.

Shopify notes that apps need reinstalling and settings need reconfiguring by hand. Discount codes and issued gift cards can't be transferred. Orders can't be imported through the admin. Apps or the API can do it. Shopify doesn't support that route, though.

Webflow

Webflow creates restore points on every 50th auto save. It doesn't offer scheduled backups. Paid Site plans keep unlimited backups. Free Starter sites can restore one of the two most recent.

After a restore, CMS items scheduled to publish later go to the publishing queue. Bot protection is turned off, and inventory can reset. Check those, plus your integrations.

A Webflow code export gives you the site's code and assets. It needs a paid Workspace plan, separate from a Site plan. CMS content, ecommerce and form processing stop working once exported. CSV exports of CMS collections help too. Images in them stay as links to the original site, so keep it or download the files.

Wix

On Wix, site history restores pages and design. Content in apps like Stores and Bookings doesn't revert. Nor do contacts or CMS collection data.

CMS collections have their own backups. Wix makes a weekly automatic backup when collections change, keeping the last three. You can save up to three manual backups too. Restoring one permanently deletes later changes, visitor submissions included. Test the exact recovery task you'd need.

Squarespace

Squarespace's XML export holds selected content for importing into WordPress. It leaves out many page types, style settings and custom CSS. It won't import into another Squarespace site. If you're weighing a move, see moving from Squarespace to WordPress.

Deleted pages and blog posts can be restored for 30 days. Deleted blocks can't be recovered once you close the editor. There's no revision history while you edit. Keep your own originals of images and copy.

Budget for tools and recovery

Backup costs come in several parts. Providers charge for each one differently:

Two checked prices give a sense of scale. In October 2026, UpdraftPlus Premium Personal showed $70 a year for up to two sites. The page didn't state its currency, and subscriptions renew automatically.

Jetpack VaultPress Backup showed $9.95 a month, billed yearly, after a cheaper first year. No currency was named. Confirm currency, tax and renewal before you budget.

Here's a separate example, in Australian dollars on a consistent tax basis. It isn't a quote, a benchmark or a full maintenance package:

The recurring total is $120 plus $60 plus $300, or $480 a year. Adding $200 for setup gives $680 in year one. Incident work and staff monitoring time are left out, so price them separately.

Storage can be estimated simply. Fourteen full copies of an unchanged 5 GB backup set need about 70 GB before overhead. Storage that keeps only changes, or compresses files, will bill differently. Check how your provider counts capacity and transfer charges.

Don't treat website revenue as the cost of downtime. Some sales are only delayed. Count the sales genuinely lost. Add recovery labour and other effects on top. For the wider budget, see website maintenance costs.

Test a restore safely

A test should prove recovery without touching the live business. Before you start, agree four things:

• where the test copy will run

• what data it's allowed to hold

• which recovery point you'll restore

• who does the work and signs it off

Lock down the test copy before you restore into it. A noindex tag asks search engines to skip a page. It doesn't stop people seeing customer data. Then switch off anything that reaches the outside world:

• outbound email, redirected to a test inbox

• live payments and recurring subscription billing

• order fulfilment and shipping updates

• webhooks, the automatic messages sent to other systems

• scheduled tasks and email campaign sends

Use test versions of integrations, often called sandboxes, where they exist. A restored copy shouldn't email old campaigns or charge anyone.

Retrieve the backup and any keys through the documented route. Restore the matching files and database, or the platform's supported equivalent. If the website admin is down, follow the host's or tool's external recovery process. Don't assume a plugin screen will be reachable during an outage.

Then check the restored copy:

• pages, posts, media and templates

• key settings and important business records

• a test enquiry, all the way to the inbox

• logins, plus any authorised booking or checkout test

• privacy choices, analytics and integrations, as far as the test copy allows

Record what you tested and what's still unproven. A test copy won't show how live DNS, email or payments behave when you switch over. Plan those checks separately.

Our ecommerce launch checks suit checkout testing. For other customer tasks, use a broader website audit.

Retest after risky changes, like a host move, a major platform change or new business critical integrations. Quarterly can be a cadence you choose. It isn't a universal safety line.

A common mistake is restoring a test copy that then emails real customers.

Record the result and protect old data

Record more than a green restore button. Write down how long the whole recovery took and what you actually tested. Extracting the files is only one step.

In this example, the latest usable recovery point is 9 am. The incident starts at 11.30 am. The service is accepted at 2 pm.

The potential data gap is 2.5 hours, and so is the outage. A one hour RPO target is missed, even though a four hour RTO target is met. They're two different tests.

If you're unsure when the incident really began, or when the last complete copy was taken, say so. Don't calculate a precise data loss from the planned schedule alone. Real recovery time runs from noticing the problem to finishing the checks. Access, file transfers and the restore itself all sit in between.

Protect personal data in old copies

Old backups can hold personal information you've since removed, and restoring can bring it back. Record deletions, corrections and unsubscribes to reapply after a restore. Restrict access to old copies. Keep them only as long as you can justify.

The OAIC's APP 11 guidelines apply to businesses the Privacy Act covers. When those businesses no longer need personal information, they must take reasonable steps to destroy it. Removing what identifies people is the other option. The guidelines say this reaches archived and backup copies too. Lawful retention requirements can change the answer.

Where electronic destruction isn't possible, the guidelines allow putting information beyond use. That means locked down, never used or shared, and destroyed once possible. The OAIC expects that only in very limited circumstances. It doesn't mean every backup must go immediately. Keeping backups isn't a blanket exception either.

Delete test copies and unneeded exports securely once the exercise is done. Don't email full customer databases around just because a tool can attach them. Australian privacy requirements explains who's covered. For what your notices should say, see website privacy information.

Recover a broken or compromised site

Slow down before you restore anything. Work through it in this order:

Some problems need a provider, not a restore. A domain, DNS or billing issue is one example. So is an outage at an outside service.

For a suspected compromise, preserve evidence and logs. Isolate affected systems. Then get qualified help. A backup from before the visible symptoms isn't automatically clean.

ASD's ACSC takes reports through ReportCyber. Its hotline is 1300 CYBER1 (1300 292 371).

Never overwrite the only copy of current business data. On a store or booking site, preserve everything that changed after your chosen point:

• new orders, payments and refunds

• stock levels after recent sales

• new bookings, memberships and subscriptions

• changes customers made to their accounts

Use a recovery method built for your system. Copying selected database tables by hand can break the links between records.

In October 2026, Jetpack's documentation said its WooCommerce feature keeps orders placed after the restore point. Stock levels, images in product descriptions and custom events triggered by a purchase aren't protected the same way. Subscriptions may need reactivating. Data that didn't reach Jetpack in real time isn't protected either. You'll need to check and match those records yourself.

Reconnecting outside systems can double up orders, payments or emails. Check for repeats. Restoring a database doesn't reverse a payment a provider has already processed. Confirm which system holds the true record before normal trading resumes.

After a compromise, deal with these before the site goes back to normal exposure:

• fix the entry point the attacker used

• review who has access, and remove old accounts

• change affected passwords and keys

The ACSC notes that backups don't reduce the risk once sensitive data has been taken and released. Possible data theft and any notification duties need separate decisions. The privacy guide linked above explains who's covered. For prevention and response, see securing a WordPress website.

If no usable backup exists, preserve what survives and get your provider or a specialist involved. Recovery may be partial, or impossible. Public caches, old revisions and new tools can't rebuild all private records.

A common mistake is restoring last week's backup over a store that has taken orders since.

Assign ownership and review the checklist

Every responsibility needs a name, even when one person holds several:

A care plan should spell out:

• the systems and data covered

• schedule, retention and independent storage

• who handles alerts, and how often restores are tested

• response hours and restore scope

• incident fees and exit arrangements

A support response target isn't the same as an RTO. If you're switching providers, changing web developers walks through access and handover. Ask about backups when choosing website hosting too.

Take a manual backup before any of these:

• updates to WordPress, plugins, themes or server software

• redesigns and migrations to a new host

• bulk imports and database cleanups

• changes to page addresses (URLs)

• changes to checkout or booking flows

Our website redesign checklist and website migration checks build this into the project. The website launch checklist supports pre launch checks. It can't prove a backup works.

Then review your setup against this list:

• every required file, database and connected record is covered

• a copy can be retrieved independently of the host

• recovery logins use MFA, and keys can be recovered

• enough historical copies are kept to catch late problems

• the newest copy is recent and complete

• a named person receives alerts and acts on them

• a dated restore test exists, with its results

• newer records can be preserved during a restore

Don't give yourself a pass if any critical item is missing.

A common mistake is ticking "backups: yes" because a backup plugin is installed.

What we recommend at Elev8d

Frequently asked questions

Next steps

Pick the step that fits where you are.

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.