Sitecarry Backup & Migration – Restore, Clone & Cloud Backups Wordpress Plugin - Rating, Reviews, Demo & Download
Plugin 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.phpis 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
- 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
- Standalone
installer.php: no WordPress needed on the target server - 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
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.
Screenshots
Every package, whether it has been proven to restore, and what has actually happened over the past month — with one line at the top for the only question that matters: is this site protected right now.
When backups run, how many are kept, and the weekly rehearsal that proves the newest one still restores.
Sending finished packages to Google Drive, Amazon S3, anything that speaks the same protocol, or FTP — each with the set-up it honestly takes, and the error you get when you miss a step.
Being told when a backup fails, by email or into Slack or Discord.
