Sitecarry Backup & Migration – Restore, Clone & Cloud Backups

In wp-content/uploads/sitecarry/, protected from direct web access.

Sitecarry removes its settings and its scheduled events from the database, and stops scheduling anything. Your packages in wp-content/uploads/sitecarry/ are left exactly where they are, on purpose — deleting a plugin should never be the thing that destroys your last copy of the site. Delete that folder yourself once you are sure you no longer need what is in it.

Background backups need the site to be able to send an HTTP request to itself. Some hosts block that. When Sitecarry detects it cannot, it falls back to running the backup from your browser instead, which works everywhere but needs the tab left open. Ask your host to allow loopback requests if you want unattended backups.

Press Restore this site next to the package and confirm. Sitecarry offers to take a backup of the site as it is first, then rebuilds the package's database in tables of its own, swaps them in, and puts the files back. Nothing is uploaded by hand and no passphrase is needed — you are already signed in as an administrator. What it does not touch: wp-config.php, your stored packages, and Sitecarry itself. The tables it replaced are kept for two days, so a change of mind is quick. If the archive is no longer on this server — a host clean-up, a file deleted by hand — the same button still works: the package is downloaded back from Google Drive, S3 or FTP first, verified, and only then restored. Nothing on the site is touched until it is here and proven. Moving a site to a different server is the other case, and it still uses the downloadable installer — there is no WordPress there yet to press a button in.

While a backup is running there is a Stop backup button under the progress bar, and it will tell you if that backup has stopped making progress. Stopping clears away the half-built package. From the command line, wp sitecarry stop does the same — useful if the admin screen is not loading. Nothing is lost by stopping: a partial package cannot be restored from anyway.

Yes. wp sitecarry backup builds one and waits for it, with no execution limit and nothing to keep open. wp sitecarry verify --all checks every package and exits non-zero if any fails, so it works in a monitoring script. wp sitecarry status prints how the site is protected.

No, and nothing short of restoring it does. Verifying proves the archive is the one that was written, still opens, and holds the files a restore starts from. That catches truncated uploads, disks that filled mid-write and silent corruption. It cannot tell you the database inside will import cleanly on a different server. That last gap is exactly what rehearsing closes — see the next two questions.

Verifying reads the archive: it confirms the file is the one that was written, that it still opens, and that the two files a restore cannot start without are inside. It takes seconds and it cannot tell you the database will import. Rehearsing imports it. The whole database export is run into tables of the plugin's own, the row count is compared against what was recorded at backup time, and the tables are then dropped. Nothing on your site is written to at any point. That is the difference between "this file is intact" and "this backup works".

Yes. Turn on Rehearse weekly in Settings and Sitecarry proves the newest full backup once a week, on Sunday, three hours after your backup hour. You hear from it only when it fails — the same failures-only rule backups use, for the same reason: a weekly all-clear stops being read within a month and takes the important one with it. The hour is not a setting on purpose. It follows the backup hour so the two cannot be pointed at each other, and a rehearsal stands aside if it finds a backup running. What gets rehearsed is the newest package that stands on its own. With incremental backups on, the newest package is usually a difference, so it walks back to the most recent full one rather than skipping that week.

Yes, and it is built to be. Every table it creates carries a prefix of its own, every statement is checked to be acting on one of those tables before it runs, and the tables are dropped whether the rehearsal passes, fails or is interrupted. Anything a crash leaves behind is swept away within a day. It does use processor time and, briefly, database space roughly the size of your database. It will not start while a backup is running.

Six things, in order, and it stops at the first that fails:

1. The archive is the one that was written, and still opens.
2. Every file in it decompresses to the size it claims.
3. The whole database export imports, into tables of the plugin's own.
4. The number of rows matches what was recorded when the backup was taken — which catches a dump that imported without error and is simply short.
5. Serialized data survives a domain change.
6. What imported is a WordPress that would work: it knows its own address, it has roles, and at least one user holds a role that still exists.

It guarantees more than anything else short of doing it, and less than everything. It proves the package restores onto this server — this PHP, this MySQL. The server you would actually use in a disaster is a different one, and nothing but a real restore proves that. What it does catch is the whole class of failures that make a backup useless without announcing itself: a truncated dump, a corrupt entry in the middle of the archive, a database export that is short of rows. That last gap is what rehearsing closes — see below.

Upload installer.php into the target folder on the new server, open it, and enter the package passphrase. If it cannot find the archives it will offer to download them from your storage — enter a read-only key for that bucket when it asks. Keep a copy of installer.php somewhere other than the site it protects; it is small, and without it you would have only the archives.

Every archive from the last full backup up to the one you are restoring. The Sitecarry screen tells you how many that is, and the installer refuses to start while any of them is missing rather than restoring half a site. If that sounds fragile, leave incremental off — every package is then complete on its own.

Download both the Archive and the Installer from the Sitecarry screen, upload them into the target folder on the other server, create an empty database there, then open installer.php in a browser and enter the package's restore passphrase.

No, and it tells you rather than pretending. The database export is MySQL, and the restore installer connects through mysqli, so a package taken on SQLite could not be restored. On such a site — WordPress Playground, or the SQLite database integration plugin — the Backups screen says so and the button is disabled.

Google asks whether you allow Sitecarry to keep files in your Drive, and the permission it issues is handed to your site through dotance.com, which is where the Google app being borrowed lives. After that your backups upload from your server straight to Google; dotance.com only turns that permission into a fresh access token roughly once an hour, because only it holds the app's secret. If you would rather have nobody in the middle, open "Use my own Google app" on the Storage screen and create an OAuth client of your own — about ten minutes, once, and then the plugin talks only to Google. Sitecarry asks for the narrowest Drive scope that exists: it can see the files it created itself and nothing else in your Drive.

No, and deliberately. It holds your database password and the eight authentication keys and salts that sign every login cookie on the site — secrets that should never leave the server, least of all inside an archive that gets uploaded to cloud storage. A restore does not need it. Onto an existing WordPress install the installer keeps that site's own wp-config.php and rewrites the database settings in it; into an empty folder it writes a fresh one from what you type in, with newly generated keys. On a multisite, add the multisite constants back by hand after restoring into an empty folder.

Update Sitecarry to 1.35.0 or later — through Plugins if you can still reach it, otherwise by uploading the new version over the old one with FTP or your host's file manager. The first page load afterwards puts the user roles back by itself; then log in as usual. Your content was restored correctly and nothing was lost: only the names of the role entries were wrong.

Yes by default, and you can turn it off under Sitecarry, Notifications. The passphrase lives only on your server and is not inside the archive, so a server that is lost takes it along; the email is the one copy that is not on it. It is never sent to Slack or Discord. The installer itself is never attached: it is made on the Backups screen and is never written to disk.

Yes, if the new site already has WordPress and Sitecarry. Open Sitecarry, Restore and choose how the package reaches the site: upload the zip, paste a migration link and its key, or pick a package already in wp-content/uploads/sitecarry/. Enter the key, check what the screen says about the package and this site, and press Restore this site. A package made on another address has its addresses changed to this site's. Because its users come with it, you are signed out when the database is swapped in; log in again with the old site's administrator. The installer is only needed when there is no WordPress to run Sitecarry on.

On the old site, open the More menu of a full backup and choose Create migration link. You get a link and a key (the package's restore passphrase). On the new server, upload only installer.php, open it, enter the key, and paste the link where it says the archive is missing. The installer downloads the package from the old site itself, a piece at a time, and then restores it. Nothing goes through your own computer. The link names one package, works for one download and stops after the time you chose (an hour, a day or a week). You can revoke it at any time. It is not enough on its own: every request must carry a signature made with the key, and the key itself is never sent anywhere. Send the link and the key by different routes. A package holds your whole database.

Yes, and visitors see a short "being restored" page while it runs — no file is written into your site root to do that, and scheduled tasks are held back so nothing writes into tables that are about to be replaced. Keep the tab open; if it closes, reopening the Backups screen picks the restore up where it stopped. If a restore stops halfway through putting files back, the database is already the package's and the files are part old, part new. The screen says so and offers both ways out: carry on, or restore the safety backup it took at the start.

Because it replaces the very files WordPress is running from. Anything doing that from inside WordPress would be pulling the floor out from under itself partway through. The installer is a standalone program that never loads WordPress.

Only if it uses the same table prefix, and it will replace those tables. Changing the table prefix during a restore is not supported yet — use an empty database.

Comfortably into the tens of gigabytes. Sitecarry writes its own archive format rather than using PHP's zip extension, appending each file to the end and never rewriting what is already there — so the work grows with the size of the site instead of with the square of it. ZIP64 is used automatically, so neither the archive nor any file in it is capped at 4GB. You still need free disk space for the package, and enough for the database export while it is being written.

Three things matter, in order. Compression is the big one, and Sitecarry already avoids most of the cost: images, video, audio, fonts and archives are stored as they are, whatever level you pick, because compressing them again is pure waste. If the server is slow and disk is cheap, set compression to None. Second, exclude what you do not need. A folder of raw video in uploads will dominate everything else. Third, let it run in the background rather than from a browser tab, or use wp sitecarry backup, which has no execution limit at all.

Screenshots, what is inside, the release history and answers to setup questions are on the Sitecarry page at dotance.com.