The site that started this is a karate club’s: about 3.4 GB of database and uploads, sitting on a shared cPanel account. No SSH. No WP-CLI. wp-admin and File Manager, and not much free disk. It needed a verified offsite backup and a way to move a redesign onto it without losing anything.
Why the usual backup fails
Most backup plugins build one archive of the whole site on the server, then hand it to you. On a big site with a small account, every step of that is a problem:
- The archive needs free disk roughly the size of the site, which is exactly what the account doesn’t have.
- Building it is one long request, and shared hosts stop those after 30 seconds or so.
- Restoring means uploading a multi-gigabyte file through a browser form.
- If the restore dies halfway, the site is half-replaced, with no way back.
Pull instead of push
The fix was to move the work to a machine that isn’t rationed. The live site only answers questions; a second WordPress install — a laptop, a staging site, anywhere with room — asks for the site in small, signed, encrypted pieces and assembles the backup at its end. Nothing large is ever written on the live server.
That one decision solves the rest. Each piece is small enough to arrive inside a 30-second limit. Every piece is saved before the next is asked for, so an interrupted backup carries on where it stopped instead of starting again. Every database chunk and file is checked with SHA-256. Files that haven’t changed since the last backup are shared with it rather than downloaded again, so the second backup of a 3.4 GB site moves a few megabytes.
Restores you can undo
A restore that can’t be reversed is a gamble, so this one never touches the live tables until the end. The backup is imported into temporary tables while the site keeps serving visitors, row counts are checked, and only then does one short step swap the new tables in and move the files across. The old ones are kept until you choose Keep, so Roll back puts the site back exactly as it was.
Addresses and paths are rewritten on the way in. That part is where most tools quietly corrupt a site: WordPress stores serialized arrays with byte lengths baked in, so a plain search-replace breaks them. Here the replacer walks the serialized format as bytes and fixes the lengths as it goes, and never calls unserialize(), which also means a backup can’t be made to instantiate objects on your server.
Offsite, without the disk
Scheduled backups to Google Drive or S3-compatible storage work the same way. The backup is packed into parts of about 50 MB; each part is uploaded, checked against its checksum and deleted before the next one is made, so peak disk use is one part rather than a copy of the site. The job runs in the background and continues after timeouts or a hiccup at the other end, and emails you when something fails.
What it took to trust it
126 unit tests, most of them about the boring parts that eat sites: SQL splitting across chunk boundaries, serialized data with emoji and nested arrays, zero dates, generated columns, collation differences between MySQL and MariaDB. Then a synthetic 1.9 GB site with deliberately awful filenames, a fake host that injects 500s, truncated responses and firewall pages at random, and finally the real 3.4 GB site. A full backup to Google Drive and back came out byte-identical.
It’s free, and it’s being submitted to the WordPress plugin directory. The project page has the details: Site Replica by AccessNow.