Where are packages stored?
In wp-content/uploads/sitecarry/ , protected from direct web access.
What happens if I delete the plugin?
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.
It says to keep the tab open. Why?
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.
How do I roll this site back to a package?
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.
A backup seems stuck. What do I do?
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.
Can I run backups from the command line?
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.
Does verifying prove the backup will restore?
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.
What is the difference between verifying and rehearsing?
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”.
Can it rehearse on its own?
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.
Is rehearsing safe to run on a live site?
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.
What does rehearsing actually check?
Six things, in order, and it stops at the first that fails:
- 01The archive is the one that was written, and still opens.
- 02Every file in it decompresses to the size it claims.
- 03The whole database export imports, into tables of the plugin’s own.
- 04The number of rows matches what was recorded when the backup was taken — which catches a dump that imported without error and is simply short.
- 05Serialized data survives a domain change.
- 06What 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.
The fifth is the one worth explaining. Widget settings, theme options and every page-builder layout are stored as serialized data, where each string records its own byte length. Move to a longer address without repairing those lengths and WordPress can no longer read the value: the site loads, looks right, and the layouts are gone. So a rehearsal rewrites the imported rows to a deliberately longer address and checks WordPress can still read every one of them back.
The sixth catches the other silent one. WordPress stores roles in an option named after the table prefix, and each user’s capabilities under a meta key named after it too. Restore under a different prefix and rename only the tables, and you get a site that loads perfectly and locks everybody out. A rehearsal moves the prefix in the data as a real restore would, then checks a user is still left holding a role that exists.
To be plain about what step six is: it reads what WordPress reads on its way up. It does not execute WordPress against the scratch tables. Booting a second WordPress would mean either a second PHP process — proc_open and exec are disabled on most shared hosting — or writing a web-reachable bootstrap into your document root on a schedule, which is a worse thing to own than the gap it closes.
Nothing is written to your site at any point. The rows are tested in memory, and the scratch tables are dropped when it finishes.
Does a passing rehearsal guarantee the restore will work?
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.
The server is gone. How do I restore?
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.
What do I need to restore an incremental backup?
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.
How do I move a site to a different server?
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.
Does it work on SQLite?
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.
What happens when I press “Connect with Google”?
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.
Is wp-config.php inside the package?
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