Adds one-button restore: put this site back to any package from the Backups screen,\nwith a safety backup taken first. wp-config.php, your packages and Sitecarry itself\nare never touched.<\/p>","1.15.0":"
Housekeeping and a proper uninstall. Deleting the plugin now clears its settings and\nschedules; your backup packages are left where they are.<\/p>","1.14.0":"
Fixes ten bugs, most of them cases where an interrupted backup could resume into a\ncorrupt archive. Worth taking.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3706208,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3706208,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3706208,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3706208,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.31.0","1.31.1","1.31.2","1.32.0","1.33.0","1.34.0"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3706223,"resolution":"1","location":"assets","locale":"","width":1280,"height":1200},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3706223,"resolution":"2","location":"assets","locale":"","width":1280,"height":1382},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3706223,"resolution":"3","location":"assets","locale":"","width":1280,"height":1753},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3706223,"resolution":"4","location":"assets","locale":"","width":1280,"height":653}},"screenshots":{"1":"Every package, whether it has been proven to restore, and what has actually happened over the past month \u2014 with one line at the top for the only question that matters: is this site protected right now.","2":"When backups run, how many are kept, and the weekly rehearsal that proves the newest one still restores.","3":"Sending finished packages to Google Drive, Amazon S3, anything that speaks the same protocol, or FTP \u2014 each with the set-up it honestly takes, and the error you get when you miss a step.","4":"Being told when a backup fails, by email or into Slack or Discord."}},"plugin_section":[],"plugin_tags":[151,10698,10718,152,23756],"plugin_category":[59],"plugin_contributors":[280364],"plugin_business_model":[],"class_list":["post-368952","plugin","type-plugin","status-publish","hentry","plugin_tags-backup","plugin_tags-cloud-backup","plugin_tags-database-backup","plugin_tags-restore","plugin_tags-site-migration","plugin_category-utilities-and-tools","plugin_contributors-dotance","plugin_committers-dotance"],"banners":{"banner":"https:\/\/ps.w.org\/sitecarry\/assets\/banner-772x250.png?rev=3706208","banner_2x":"https:\/\/ps.w.org\/sitecarry\/assets\/banner-1544x500.png?rev=3706208","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/sitecarry\/assets\/icon-128x128.png?rev=3706208","icon_2x":"https:\/\/ps.w.org\/sitecarry\/assets\/icon-256x256.png?rev=3706208","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/sitecarry\/assets\/screenshot-1.png?rev=3706223","caption":"Every package, whether it has been proven to restore, and what has actually happened over the past month \u2014 with one line at the top for the only question that matters: is this site protected right now."},{"src":"https:\/\/ps.w.org\/sitecarry\/assets\/screenshot-2.png?rev=3706223","caption":"When backups run, how many are kept, and the weekly rehearsal that proves the newest one still restores."},{"src":"https:\/\/ps.w.org\/sitecarry\/assets\/screenshot-3.png?rev=3706223","caption":"Sending finished packages to Google Drive, Amazon S3, anything that speaks the same protocol, or FTP \u2014 each with the set-up it honestly takes, and the error you get when you miss a step."},{"src":"https:\/\/ps.w.org\/sitecarry\/assets\/screenshot-4.png?rev=3706223","caption":"Being told when a backup fails, by email or into Slack or Discord."}],"raw_content":"\n
Sitecarry builds a single package containing your site's files and a full database\nexport, then lets you download it from the WordPress admin.<\/p>\n\n
The build runs in short, resumable slices, so it works on shared hosting where a\nsingle PHP request is capped at 30 seconds. If a request times out, the next one\npicks up exactly where the last one stopped.<\/p>\n\n
Each package comes with a standalone installer that restores it onto any server \u2014\nthe same file works for moving a site to new hosting, cloning live to staging, or\nrolling a site back.<\/p>\n\n
What it does<\/strong><\/p>\n\n Why URL rewriting is the hard part<\/strong><\/p>\n\n WordPress stores a lot of settings as PHP serialized data, where every string\ncarries its own byte length. Replacing an old domain with a longer one using a\nplain search and replace breaks those lengths, and WordPress can then no longer\nread the value \u2014 which is how a migration quietly wipes widget settings and page\nbuilder layouts. Sitecarry rewrites the serialized form directly and repairs the\nlengths, and it also handles the JSON-escaped form ( Security<\/strong><\/p>\n\n Packages contain a complete copy of your database. Sitecarry stores them in a\nprotected folder with an unguessable filename, blocks direct web access via\n .htaccess and Every package has its own restore passphrase, shown in the admin and kept out of\nthe archive. The installer refuses to do anything without it, so an installer\nleft behind on a server cannot be used by anyone else to overwrite the site. It\nalso deletes itself and the archive when the restore finishes.<\/p>\n\n Out of the box Sitecarry talks to nothing but your own server. It contacts an\noutside service only when you switch one on, and only with what that service needs\nto do its job. It never sends usage data, analytics or licence checks anywhere.<\/p>\n\n Amazon S3, or any S3-compatible storage<\/strong> \u2014 used only when you set Storage to S3.\nSitecarry sends your backup archives, and the requests needed to list and delete\nthem, to the endpoint you enter (by default FTP \/ FTPS server<\/strong> \u2014 used only when you set Storage to FTP. Sitecarry connects to\nthe host, port and path you enter and uploads the same archives, authenticating with\nthe username and password you configured. The server is one you choose, so its terms\nare your host's. Plain FTP sends that password and the whole archive unencrypted;\nthe settings screen recommends FTP over TLS for this reason.<\/p>\n\n Google Drive<\/strong> \u2014 used only when you set Storage to Google Drive and complete the\nconnection. Sitecarry sends you to dotance.com \u2014 only if you choose \"Connect with Google\"<\/strong> \u2014 Google Drive needs an\nOAuth app, and this is the one Sitecarry lends you so connecting takes a click\ninstead of ten minutes in the Google console. When you press that button your\nbrowser goes to Slack, Discord, or any incoming webhook<\/strong> \u2014 used only when you enter a webhook URL\non the Notifications screen. Sitecarry posts a short message to that URL when a\nbackup finishes or fails: the site name, the outcome, the step it stopped on and the\nerror text. No archive and no credentials are sent. The destination is the URL you\nsupply, commonly Your own site<\/strong> \u2014 Sitecarry sends an HTTP request to your site's own\n admin-ajax.php to start and continue a background backup. That is a loopback\nrequest to your server, not a third party.<\/p>\n\n\n In Sitecarry removes its settings and its scheduled events from the database, and stops\nscheduling anything. Your packages in Background backups need the site to be able to send an HTTP request to itself. Some\nhosts block that. When Sitecarry detects it cannot, it falls back to running the\nbackup from your browser instead, which works everywhere but needs the tab left\nopen. Ask your host to allow loopback requests if you want unattended backups.<\/p><\/dd>\n Press Restore this site<\/strong> next to the package and confirm. Sitecarry offers to take\na backup of the site as it is first, then rebuilds the package's database in tables of\nits own, swaps them in, and puts the files back. Nothing is uploaded by hand and no\npassphrase is needed \u2014 you are already signed in as an administrator.<\/p>\n\n What it does not touch: Moving a site to a different server<\/strong> is the other case, and it still uses the\ndownloadable installer \u2014 there is no WordPress there yet to press a button in.<\/p><\/dd>\n While a backup is running there is a Stop backup<\/strong> button under the progress bar,\nand it will tell you if that backup has stopped making progress. Stopping clears\naway the half-built package. From the command line, Nothing is lost by stopping: a partial package cannot be restored from anyway.<\/p><\/dd>\n Yes. No, and nothing short of restoring it does. Verifying proves the archive is the one\nthat was written, still opens, and holds the files a restore starts from. That\ncatches truncated uploads, disks that filled mid-write and silent corruption. It\ncannot tell you the database inside will import cleanly on a different server.<\/p>\n\n That last gap is exactly what rehearsing closes \u2014 see the next two questions.<\/p><\/dd>\n Verifying reads the archive: it confirms the file is the one that was written, that\nit still opens, and that the two files a restore cannot start without are inside. It\ntakes seconds and it cannot tell you the database will import.<\/p>\n\n Rehearsing imports it. The whole database export is run into tables of the plugin's\nown, the row count is compared against what was recorded at backup time, and the\ntables are then dropped. Nothing on your site is written to at any point.<\/p>\n\n That is the difference between \"this file is intact\" and \"this backup works\".<\/p><\/dd>\n Yes. Turn on Rehearse weekly<\/strong> in Settings and Sitecarry proves the newest full\nbackup once a week, on Sunday, three hours after your backup hour. You hear from it\nonly when it fails \u2014 the same failures-only rule backups use, for the same reason: a\nweekly all-clear stops being read within a month and takes the important one with it.<\/p>\n\n The hour is not a setting on purpose. It follows the backup hour so the two cannot be\npointed at each other, and a rehearsal stands aside if it finds a backup running.<\/p>\n\n What gets rehearsed is the newest package that stands on its own. With incremental\nbackups on, the newest package is usually a difference, so it walks back to the most\nrecent full one rather than skipping that week.<\/p><\/dd>\n Yes, and it is built to be. Every table it creates carries a prefix of its own, every\nstatement is checked to be acting on one of those tables before it runs, and the\ntables are dropped whether the rehearsal passes, fails or is interrupted. Anything a\ncrash leaves behind is swept away within a day.<\/p>\n\n It does use processor time and, briefly, database space roughly the size of your\ndatabase. It will not start while a backup is running.<\/p><\/dd>\n Six things, in order, and it stops at the first that fails:<\/p>\n\n The fifth is the one worth explaining. Widget settings, theme options and every\npage-builder layout are stored as serialized data, where each string records its own\nbyte length. Move to a longer address without repairing those lengths and WordPress\ncan no longer read the value: the site loads, looks right, and the layouts are gone.\nSo a rehearsal rewrites the imported rows to a deliberately longer address and checks\nWordPress can still read every one of them back.<\/p>\n\n The sixth catches the other silent one. WordPress stores roles in an option named\nafter the table prefix, and each user's capabilities under a meta key named after it\ntoo. Restore under a different prefix and rename only the tables, and you get a site\nthat loads perfectly and locks everybody out. A rehearsal moves the prefix in the\ndata as a real restore would, then checks a user is still left holding a role that\nexists.<\/p>\n\n To be plain about what step six is: it reads what WordPress reads on its way up. It\ndoes not execute WordPress against the scratch tables. Booting a second WordPress\nwould mean either a second PHP process \u2014 Nothing is written to your site at any point. The rows are tested in memory, and the\nscratch tables are dropped when it finishes.<\/p><\/dd>\n It guarantees more than anything else short of doing it, and less than everything.\nIt proves the package restores onto this server<\/strong> \u2014 this PHP, this MySQL. The\nserver you would actually use in a disaster is a different one, and nothing but a\nreal restore proves that.<\/p>\n\n What it does catch is the whole class of failures that make a backup useless without\nannouncing itself: a truncated dump, a corrupt entry in the middle of the archive, a\ndatabase export that is short of rows.\nThat last gap is what rehearsing<\/strong> closes \u2014 see below.<\/p><\/dd>\n Upload Every archive from the last full backup up to the one you are restoring. The\nSitecarry screen tells you how many that is, and the installer refuses to start\nwhile any of them is missing rather than restoring half a site. If that sounds\nfragile, leave incremental off \u2014 every package is then complete on its own.<\/p><\/dd>\n Download both the Archive and the Installer from the Sitecarry screen, upload them\ninto the target folder on the other server, create an empty database there, then\nopen No, and it tells you rather than pretending. The database export is MySQL, and the\nrestore installer connects through mysqli, so a package taken on SQLite could not be\nrestored. On such a site \u2014 WordPress Playground, or the SQLite database integration\nplugin \u2014 the Backups screen says so and the button is disabled.<\/p><\/dd>\n Google asks whether you allow Sitecarry to keep files in your Drive, and the\npermission it issues is handed to your site through dotance.com, which is where\nthe Google app being borrowed lives. After that your backups upload from your\nserver straight to Google; dotance.com only turns that permission into a fresh\naccess token roughly once an hour, because only it holds the app's secret.<\/p>\n\n If you would rather have nobody in the middle, open \"Use my own Google app\" on\nthe Storage screen and create an OAuth client of your own \u2014 about ten minutes,\nonce, and then the plugin talks only to Google.<\/p>\n\n Sitecarry asks for the narrowest Drive scope that exists: it can see the files it\ncreated itself and nothing else in your Drive.<\/p><\/dd>\n No, and deliberately. It holds your database password and the eight authentication\nkeys and salts that sign every login cookie on the site \u2014 secrets that should never\nleave the server, least of all inside an archive that gets uploaded to cloud storage.<\/p>\n\n A restore does not need it. Onto an existing WordPress install the installer keeps\nthat site's own Yes, and visitors see a short \"being restored\" page while it runs \u2014 no file is\nwritten into your site root to do that, and scheduled tasks are held back so nothing\nwrites into tables that are about to be replaced. Keep the tab open; if it closes,\nreopening the Backups screen picks the restore up where it stopped.<\/p>\n\n If a restore stops halfway through putting files back, the database is already the\npackage's and the files are part old, part new. The screen says so and offers both\nways out: carry on, or restore the safety backup it took at the start.<\/p><\/dd>\n Because it replaces the very files WordPress is running from. Anything doing that\nfrom inside WordPress would be pulling the floor out from under itself partway\nthrough. The installer is a standalone program that never loads WordPress.<\/p><\/dd>\n Only if it uses the same table prefix, and it will replace those tables. Changing\nthe table prefix during a restore is not supported yet \u2014 use an empty database.<\/p><\/dd>\n Comfortably into the tens of gigabytes. Sitecarry writes its own archive format\nrather than using PHP's zip extension, appending each file to the end and never\nrewriting what is already there \u2014 so the work grows with the size of the site\ninstead of with the square of it. ZIP64 is used automatically, so neither the\narchive nor any file in it is capped at 4GB.<\/p>\n\n You still need free disk space for the package, and enough for the database export\nwhile it is being written.<\/p><\/dd>\n Three things matter, in order.<\/p>\n\n Compression is the big one, and Sitecarry already avoids most of the cost: images,\nvideo, audio, fonts and archives are stored as they are, whatever level you pick,\nbecause compressing them again is pure waste. If the server is slow and disk is\ncheap, set compression to None.<\/p>\n\n Second, exclude what you do not need. A folder of raw video in uploads will\ndominate everything else.<\/p>\n\n Third, let it run in the background rather than from a browser tab, or use\n wp sitecarry backup, which has no execution limit at all.<\/p><\/dd>\n\n
wp-config.php<\/code> is never archived, so the database password and the login\nkeys and salts stay on the server; the restore writes that file itself<\/li>\ninstaller.php<\/code> for moving a site to a different server, where there is\nno WordPress to press a button in<\/li>\nnode_modules<\/code>, .git<\/code>, and other backup plugins' folders, which is\nusually the difference between a 400MB package and a 40GB one<\/li>\nhttps:\\\/\\\/<\/code>) that page\nbuilders such as Elementor store their content in.<\/p>\n\nweb.config<\/code>, and serves downloads only through an authenticated\nadmin request \u2014 never a public URL.<\/p>\n\nExternal services<\/h3>\n\n
https:\/\/s3.<region>.amazonaws.com<\/code>, or\nyour own for Backblaze B2, Wasabi, DigitalOcean Spaces, MinIO and so on). What is\nsent: the archive itself \u2014 which contains your site's files and a full database\nexport \u2014 plus the access key you configured, used to sign each request. Nothing is\nsent until you save S3 credentials and run a backup.\nFor any other S3-compatible provider, the terms are that provider's own.<\/p>\n\n\n
amazonaws.com<\/code>)<\/li>\nhttps:\/\/accounts.google.com<\/code> to authorise,\nexchanges the code at https:\/\/oauth2.googleapis.com\/token<\/code>, and uploads, lists and\ndeletes archives through https:\/\/www.googleapis.com\/drive\/v3<\/code> and\n https:\/\/www.googleapis.com\/upload\/drive\/v3. What is sent: the archives, and an\nOAuth token belonging to the Google account you authorise. The connection uses an\nOAuth client you create yourself, so the traffic is between your site and Google \u2014\nit is not routed through us. Only the drive.file<\/code> scope is requested, which limits\nSitecarry to files it created itself.<\/p>\n\n\n
googleapis.com<\/code>, accounts.google.com<\/code>)<\/li>\nhttps:\/\/dotance.com\/wp-json\/dotance\/v1\/google\/start<\/code>, on to\nGoogle's own consent screen, and back; your site then collects the resulting\npermission from ...\/google\/claim<\/code>, and asks ...\/google\/token<\/code> for a fresh\naccess token about once an hour while a backup runs. What is sent: your site's\naddress, and the permission Google issued for the Drive you approved. What is\nnever sent: your backups \u2014 they upload from your server straight to Google \u2014 and\nno credentials of any other kind. Choose \"Use my own Google app\" instead and\nnothing touches dotance.com at all.<\/p>\n\n\n
dotance.com<\/code>), the plugin's author<\/li>\nhttps:\/\/hooks.slack.com\/...<\/code>.<\/p>\n\n\n
hooks.slack.com<\/code>)<\/li>\ndiscord.com<\/code>)<\/li>\n\n
\/wp-content\/plugins\/<\/code>.<\/li>\n\n
Where are packages stored?<\/h3><\/dt>\n
wp-content\/uploads\/sitecarry\/<\/code>, protected from direct web access.<\/p><\/dd>\nWhat happens if I delete the plugin?<\/h3><\/dt>\n
wp-content\/uploads\/sitecarry\/<\/code> are left\nexactly where they are, on purpose \u2014 deleting a plugin should never be the thing\nthat destroys your last copy of the site. Delete that folder yourself once you are\nsure you no longer need what is in it.<\/p><\/dd>\nIt says to keep the tab open. Why?<\/h3><\/dt>\n
How do I roll this site back to a package?<\/h3><\/dt>\n
wp-config.php<\/code>, your stored packages, and Sitecarry itself.\nThe tables it replaced are kept for two days, so a change of mind is quick.<\/p>\n\nA backup seems stuck. What do I do?<\/h3><\/dt>\n
wp sitecarry stop<\/code> does the\nsame \u2014 useful if the admin screen is not loading.<\/p>\n\nCan I run backups from the command line?<\/h3><\/dt>\n
wp sitecarry backup<\/code> builds one and waits for it, with no execution limit and\nnothing to keep open. wp sitecarry verify --all<\/code> checks every package and exits\nnon-zero if any fails, so it works in a monitoring script. wp sitecarry status<\/code>\nprints how the site is protected.<\/p><\/dd>\nDoes verifying prove the backup will restore?<\/h3><\/dt>\n
What is the difference between verifying and rehearsing?<\/h3><\/dt>\n
Can it rehearse on its own?<\/h3><\/dt>\n
Is rehearsing safe to run on a live site?<\/h3><\/dt>\n
What does rehearsing actually check?<\/h3><\/dt>\n
\n
proc_open<\/code> and exec<\/code> are disabled on most\nshared hosting \u2014 or writing a web-reachable bootstrap into your document root on a\nschedule, which is a worse thing to own than the gap it closes.<\/p>\n\nDoes a passing rehearsal guarantee the restore will work?<\/h3><\/dt>\n
The server is gone. How do I restore?<\/h3><\/dt>\n
installer.php<\/code> into the target folder on the new server, open it, and enter\nthe package passphrase. If it cannot find the archives it will offer to download\nthem from your storage \u2014 enter a read-only key for that bucket when it asks. Keep a\ncopy of installer.php<\/code> somewhere other than the site it protects; it is small, and\nwithout it you would have only the archives.<\/p><\/dd>\nWhat do I need to restore an incremental backup?<\/h3><\/dt>\n
How do I move a site to a different server?<\/h3><\/dt>\n
installer.php<\/code> in a browser and enter the package's restore passphrase.<\/p><\/dd>\nDoes it work on SQLite?<\/h3><\/dt>\n
What happens when I press \"Connect with Google\"?<\/h3><\/dt>\n
Is wp-config.php inside the package?<\/h3><\/dt>\n
wp-config.php<\/code> and rewrites the database settings in it; into an\nempty folder it writes a fresh one from what you type in, with newly generated keys.\nOn a multisite, add the multisite constants back by hand after restoring into an\nempty folder.<\/p><\/dd>\nCan I restore while the site is live?<\/h3><\/dt>\n
Why does moving to another server not run inside WordPress?<\/h3><\/dt>\n
Can it restore into a database that already has a WordPress install?<\/h3><\/dt>\n
How large a site can it handle?<\/h3><\/dt>\n
Can I make backups faster?<\/h3><\/dt>\n
Where can I see what is inside before installing?<\/h3><\/dt>\n