Sitecarry Backup & Migration – Restore, Clone & Cloud Backups

Sitecarry builds a single package containing your site’s files and a full database

export, then lets you download it from the WordPress admin.

Watch the four-minute tutorial: back up, send to Google Drive, prove the backup restores, restore and move a site.

The build runs in short, resumable slices, so it works on shared hosting where a

single PHP request is capped at 30 seconds. If a request times out, the next one

picks up exactly where the last one stopped.

Each package comes with a standalone installer that restores it onto any server —

the same file works for moving a site to new hosting, cloning live to staging, or

rolling a site back.

What it does

• Full site package: files plus a complete SQL export

• Your wp-config.php is never archived, so the database password and the login

keys and salts stay on the server; the restore writes that file itself

• Scheduled backups — hourly, twice daily, daily or weekly, with retention

• Optional incremental file backups, with automatic full backups in between

• Upload to Amazon S3, any S3-compatible storage, FTP or Google Drive — Drive

connects in one click, or with a Google app of your own if you would rather keep

the plugin’s author out of it entirely

• Restore straight from storage when the archives are no longer on the server

• Email or Slack/Discord notification when a backup fails. The email names every

detail of your newest backups — where they are, their checksum and, if you allow

it, the restore passphrase — so you have them even if the site will not open

• Verify that a package is intact, from the admin or WP-CLI

• Rehearse a backup, by hand or every week — import it into scratch tables, check

the row count, prove the result would work as a site, and

confirm serialized data survives a domain change. Then throw the tables away.

Nothing on the site is touched

• WP-CLI commands for backing up, listing, verifying and checking status

• Backups run in the background — start one and close the tab

• Resumable build and resumable restore — both survive short PHP execution limits

• Live progress throughout

• Restore this site with one button — the package’s database is rebuilt in

tables of its own, swapped in atomically, and the files put back afterwards

• Restores from a package that is only in storage: Sitecarry downloads it back

from Google Drive, S3 or FTP first, resuming if the request runs out of time

• Migration links — move a site to another server without downloading and

uploading a gigabyte by hand: create a link on the old site, paste it into the

installer on the new one, and the package travels straight between the two servers

• Standalone installer.php for moving a site to a different server, where there is

no WordPress to press a button in

• Serialization-safe URL rewriting, so page builder content survives the move

• Skips caches, node_modules,.git, and other backup plugins’ folders, which is

usually the difference between a 400MB package and a 40GB one

• Records a manifest describing the origin site (URLs, table prefix, versions)

Why URL rewriting is the hard part

WordPress stores a lot of settings as PHP serialized data, where every string

carries its own byte length. Replacing an old domain with a longer one using a

plain search and replace breaks those lengths, and WordPress can then no longer

read the value — which is how a migration quietly wipes widget settings and page

builder layouts. Sitecarry rewrites the serialized form directly and repairs the

lengths, and it also handles the JSON-escaped form ( https:\/\/ ) that page

builders such as Elementor store their content in.

Security

Packages contain a complete copy of your database. Sitecarry stores them in a

protected folder with an unguessable filename, blocks direct web access via

config, and serves downloads only through an authenticated

admin request — never a public URL.

Every package has its own restore passphrase, shown in the admin and kept out of

the archive. The installer refuses to do anything without it, so an installer

left behind on a server cannot be used by anyone else to overwrite the site. It

also deletes itself and the archive when the restore finishes.

Bundled fonts

The admin screens use Manrope and JetBrains Mono, both under the SIL Open Font

1. They are shipped inside the plugin, in assets/fonts, and nothing is

loaded from Google or any other host to draw them.

External services

Out of the box Sitecarry talks to nothing but your own server. It contacts an

outside service only when you switch one on, and only with what that service needs

to do its job. It never sends usage data, analytics or licence checks anywhere.

Amazon S3, or any S3-compatible storage — used only when you set Storage to S3.

Sitecarry sends your backup archives, and the requests needed to list and delete

com, or

your own for Backblaze B2, Wasabi, DigitalOcean Spaces, MinIO and so on). What is

sent: the archive itself — which contains your site’s files and a full database

export — plus the access key you configured, used to sign each request. Nothing is

sent until you save S3 credentials and run a backup.

For any other S3-compatible provider, the terms are that provider’s own.

• Service: Amazon S3, provided by Amazon Web Services ( amazonaws.com )

• Terms of service: https://aws.amazon.com/service-terms/

• Privacy policy: https://aws.amazon.com/privacy/

FTP / FTPS server — used only when you set Storage to FTP. Sitecarry connects to

the host, port and path you enter and uploads the same archives, authenticating with

the username and password you configured. The server is one you choose, so its terms

are your host’s. Plain FTP sends that password and the whole archive unencrypted;

the settings screen recommends FTP over TLS for this reason.

Google Drive — used only when you set Storage to Google Drive and complete the

connection. com to authorise,

com/token, and uploads, lists and

com/drive/v3 and

com/upload/drive/v3. What is sent: the archives, and an

OAuth token belonging to the Google account you authorise. The connection uses an

OAuth client you create yourself, so the traffic is between your site and Google —

it is not routed through us. file scope is requested, which limits

Sitecarry to files it created itself.

• Service: Google Drive API, provided by Google ( googleapis.com, accounts.google.com )

• Terms of service: https://policies.google.com/terms and https://developers.google.com/terms

• Privacy policy: https://policies.google.com/privacy

com — only if you choose “Connect with Google” — Google Drive needs an

OAuth app, and this is the one Sitecarry lends you so connecting takes a click

instead of ten minutes in the Google console. When you press that button your

com/wp-json/dotance/v1/google/start, on to

Google’s own consent screen, and back; your site then collects the resulting

/google/token for a fresh

access token about once an hour while a backup runs. What is sent: your site’s

address, and the permission Google issued for the Drive you approved. What is

never sent: your backups — they upload from your server straight to Google — and

no credentials of any other kind. Choose “Use my own Google app” instead and

com at all.

• Service: Dotance ( dotance.com ), the plugin’s author

• Terms of service: https://dotance.com/terms/

• Privacy policy: https://dotance.com/privacy-policy/

Slack, Discord, or any incoming webhook — used only when you enter a webhook URL

on the Notifications screen. Sitecarry posts a short message to that URL when a

backup finishes or fails: the site name, the outcome, the step it stopped on and the

error text. No archive and no credentials are sent. The destination is the URL you

com/....

• Service: Slack incoming webhooks ( hooks.slack.com )

• Terms of service: https://slack.com/terms-of-service

• Privacy policy: https://slack.com/trust/privacy/privacy-policy

• Service: Discord webhooks ( discord.com )

• Terms of service: https://discord.com/terms

• Privacy policy: https://discord.com/privacy

Another site, by migration link — used only when you open Restore, choose

Migration link, and paste a link and key that someone gave you (or that you made on

your other site). Sitecarry then sends HTTP requests to the address in that link,

which is a site you name, normally another site running Sitecarry: one request for the

description of the package, then requests for the archive in pieces. What is sent: the

link’s token, which is already part of the address, and a signature made with the

package’s restore passphrase. The passphrase itself is never sent. What comes back is

the package, which holds that site’s files and a full database export, and is saved in

wp-content/uploads/sitecarry/. Requests go through WordPress’s safe HTTP function, so

addresses on a private network are refused. Nothing is sent until you press Check

link. The downloadable installer does the same when you paste a link into it. The

terms are those of the site you name. On the site that made the link, Sitecarry only

answers requests that carry both the token and a valid signature, and contacts no one

itself.

Your own site — Sitecarry sends an HTTP request to your site’s own

php to start and continue a background backup. That is a loopback

request to your server, not a third party.