內容簡介
Sitecarry Backup & Migration 是一款強大的備份與遷移外掛，能夠輕鬆地將網站的檔案和資料庫完整打包，並支持從多種儲存服務恢復。無論是備份還是克隆，這款外掛都能確保您的網站資料安全可靠。
【主要功能】
• 完整網站打包：檔案與完整 SQL 匯出
• 支援定時備份：每小時、每日或每週
• 增量檔案備份選項，並自動進行完整備份
• 多種儲存選擇：Amazon S3、FTP、Google Drive
• 備份失敗通知：透過 Email 或 Slack/Discord
• WP-CLI 命令支援，方便管理備份
外掛標籤
開發者團隊
② 後台搜尋「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.
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
.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.
Bundled fonts
The admin screens use Manrope and JetBrains Mono, both under the SIL Open Font
License 1.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
them, to the endpoint you enter (by default https://s3.
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
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
admin-ajax.php to start and continue a background backup. That is a loopback
request to your server, not a third party.
