Sitecarry Backup & Migration – Restore, Clone & Cloud Backups

Description

Sitecarry builds a single package containing your site’s files and a full database
export, then lets you download it from the WordPress admin.

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
• 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
• 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
.htaccess and web.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.

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
them, to the endpoint you enter (by default https://s3.<region>.amazonaws.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. Sitecarry sends you to https://accounts.google.com to authorise,
exchanges the code at https://oauth2.googleapis.com/token, and uploads, lists and
deletes archives through https://www.googleapis.com/drive/v3 and
https://www.googleapis.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. Only the drive.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

dotance.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
browser goes to https://dotance.com/wp-json/dotance/v1/google/start, on to
Google’s own consent screen, and back; your site then collects the resulting
permission from .../google/claim, and asks .../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
nothing touches dotance.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
supply, commonly https://hooks.slack.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

Your own site — Sitecarry sends an HTTP request to your site’s own
admin-ajax.php to start and continue a background backup. That is a loopback
request to your server, not a third party.

Technical details