Backup and Restore

Why backups fail when they are needed

Having a backup and being able to restore from it are different things. A copy can turn out to contain only the database and not the uploads folder, or it sits inside the same hosting account the attacker had access to, or the newest clean copy can be older than anyone realised because the backups quietly stopped.

The WordPress hardening guide puts it simply: back up your data regularly, including your databases, keep regular snapshots of both files and database, and protect those backups, for example with encryption, hash records or read-only storage ^[1]. The Australian Cyber Security Centre's small business guide gives the same message in one line: create and implement a plan to regularly back up your information ^[2], and Business Queensland lists "back up your information" among its basic steps ^[3].

What we set up

• Complete copies. The database plus the wp-content folder, configuration files and anything else the site needs to run. WordPress core files can be downloaded again, but we include them where it makes restores simpler.
• A schedule that fits. Database copies as often as the site takes new orders, bookings or posts, and file copies at least weekly.
• Storage away from the site. A storage account in your name, separate from the hosting account, with credentials the website itself cannot use to delete copies.
• Retention. Enough history to reach back past a slow-moving break-in. Thirty days of daily copies plus monthly copies for a year is a reasonable starting point for most small sites.
• Protection. Encrypted copies where the tool supports it, and alerts when a backup fails or shrinks unexpectedly.

The test restore

A backup is a theory until it has been restored. After setting up the schedule, we restore the newest copy to a private test location and check that pages load, logins work, images appear and forms submit. We then write down the exact steps in a one-page restore guide, so that you or another developer can follow them under pressure.

We recommend repeating the test at least twice a year, and after any big change to the site, such as a new theme or a move to a different host. It is included in our maintenance plans.

Backups after a hack

When a site has been hacked, the most recent backup is often the worst one to use, because it contains the attacker's changes. The first job in a recovery is working out when the break-in started, so we can pick the newest copy from before that date. Longer retention gives us more room to do that.

Gaps we look for in existing backups

If you already have a backup tool, we start by checking it rather than replacing it. The gaps that matter most are simple to describe:

• Half a site. The database is copied but the uploads folder is excluded to save space, so a restore brings back pages without their images.
• Silent failure. The schedule stopped after a plugin update or a full storage quota, and nobody was told.
• Same-account storage. Copies sit in a folder inside the hosting account, where anyone who controls the site can reach them.
• Short memory. Only the last few days are kept, which is not enough to reach back past a break-in that went unnoticed for weeks.
• No instructions. The only person who knows how to restore is a former developer.

Each gap has a straightforward fix, and the report lists which ones applied to your site.

What stays in your hands

A backup arrangement should never leave you dependent on one person to get your own website back. As part of this service, we make sure you can reach your backups without us. That means at least one copy sits in a storage account owned by your business, under an email address you control, with access you can grant or remove yourself.

We also walk you through a download of the latest backup, so you know where it is and what it looks like. It takes a few minutes, and it means that if we are unreachable, or you change providers, the copies are still yours.

A few things we ask you to keep up after the setup:

• read the alert emails when they arrive, rather than filtering them away;
• tell us, or whoever looks after the site, when you add a shop, booking system or members area, since those change how often backups should run;
• keep the one-page restore guide we write with your other business records, and check it still matches the site once a year.

Backups only help if someone notices when they stop. Most backup failures are quiet: a full storage account, an expired password or a plugin that was switched off during an update. Keeping an eye on the alerts is the single most useful thing you can do between our checks.

What you receive

• A working backup schedule with copies stored in an account you control.
• A record of the first successful test restore, including date and what was checked.
• A one-page restore guide written for your site and your host.
• Alerts set up for failed or unusually small backups.

For the reasoning behind each choice, read our guide on backups that actually restore.