Sitecarry — backups you can actually restore.

Connecting Drive used to mean creating a Google app of your own — ten minutes in a console most people never spend. Now you press Connect with Google, approve it at Google, and it is done. Your backups still upload from your server straight to Drive; what passes through dotance.com is the approval and a token refresh about once an hour. Making your own Google app is still there for anyone who wants nobody in the middle.

The activity record can now be emptied from a link in that card — useful when a site changes hands, or when the failures in it were all yours from testing. The packages themselves are untouched; only the record of what has happened goes.

On a site large enough that a backup runs in more than one pass, the finished archive could be written with an index length short by its last few entries, and no zip reader would open it. The length now comes from the packer's own running total rather than from the filesystem, whose answer lags behind on some hosts. Verify and rehearse caught this every time; replace any package that fails to verify with a fresh backup.

Listed on the WordPress.org plugin directory. Also fixed on Windows servers: each backup included every earlier package and its passphrase file, so packages doubled in size with every run. Linux and macOS servers were not affected.

The export is MySQL and the installer restores through mysqli, so on SQLite - WordPress Playground, or the SQLite integration plugin - a package would build and could never be restored. Sitecarry now refuses the backup there instead, with the reason on the screen.

The restore installer is assembled in memory and streamed straight to the browser, so the generated file exists only as the download itself and nothing is left behind on the site that made it.

That file holds the database password and the eight keys and salts that sign every login cookie, and a package can be uploaded to storage outside your control, so it is no longer included. A restore writes it instead: onto an existing install it updates the one already there, and into an empty folder it generates a new one with fresh keys. Restoring now starts with Get installer rather than Sitecarry writing a program into your WordPress folder.

Every query that names a table now passes the name through an identifier placeholder, all remote requests inside WordPress go through the HTTP API, and the plugin no longer raises PHP's execution time limit - each step is sized to fit inside the host's limit and resumes in the next request. WordPress 6.2 or later is required.

The status strip no longer wraps, so its five boxes stay the same height. A backup's restore passphrase now sits beside the Restore button that asks for it, instead of at the far end of a mostly empty row. And Settings keeps the first line under each control, folding the reasoning behind it into a short link — so the screen is a list of settings again rather than three paragraphs under each one.

Same controls, same words, laid out like what they are: evidence. One state mark used the same way everywhere, facts in a monospace face and sentences in the admin's own, each package as a row with its state and its two actions, a timeline for recent activity, and settings grouped into cards with a one-line explanation beside each. Nothing loads a font or an image, and accents follow your admin colour scheme.

The status strip no longer wraps its fifth item onto a row of its own — it was built for four, and a fifth arrived with rehearsal reporting. New screenshots too, showing the rehearsal, the activity log and the storage set-up guides; the old ones predated all three.

Progress that keeps moving — "3,200 of 11,077 files" beside the percentage, which on a large site sits still for minutes. Deleting a backup now names it, and says so when it is one that has been proven to restore or the only copy that exists anywhere. The progress bar follows your admin colour scheme, the screen is laid out for narrow ones, and the status strip, progress bar and results now read properly to a screen reader.

The Backups screen now shows what has actually happened — backups, rehearsals and deletions — with a thirty-day summary above it. Every other record lives with its package and disappears when retention prunes it, so on a site keeping five backups nothing older than five days had ever been visible. This log outlives the packages it describes. Each backup also now has one primary action instead of six buttons of equal weight, with Delete set apart from Restore.

A mangled line of JavaScript had left the buttons on the restore installer unresponsive. The archives themselves were never affected. Every build now assembles the installer and runs both a PHP and a JavaScript parser over it, so this cannot return unnoticed.

Google Drive and Amazon S3 both failed to upload because response headers were being read the wrong way — an error that looked like the service refusing. Failures now say what actually came back rather than naming the service.

Sitecarry can now prove your newest full backup every week on its own, and tells you only when it fails. The hour follows your backup hour, so a rehearsal never lands on top of a backup.

Verifying tells you an archive still opens. Rehearsing imports it — into scratch tables of its own, then throws them away — and checks the row count, that serialized data survives a domain change, and that what comes out is a WordPress that would actually work. A backup nobody has tested is a hope, not a backup.

Deleting the plugin now clears its settings and scheduled events, and deliberately leaves your packages alone — deleting a plugin should not destroy the only copy of a site.

Ten fixes, most of them cases where an interrupted backup could resume into a corrupt archive. The database export now pages by primary key, which is both correct and far faster on large tables.

Sitecarry writes the ZIP itself, appending and never rewriting, so build time grows with the size of the site instead of with its square. ZIP64 throughout, and PHP's zip extension is no longer needed.

Two more destinations, both chunked and resumable. Drive uses an OAuth client of your own, so authorisation never routes through anyone else's servers.

When the archive is no longer on the server — pruned, or because the server itself is gone — the installer downloads it from S3. That is the situation a backup exists for.