Description
Site Replica copies a whole WordPress site (database and wp-content) to another WordPress install. It was built for large sites on restrictive shared hosting, where the usual “make one big ZIP” approach fails because of time limits, memory limits or missing disk space.
Pull backups (direct download). On the live site, turn on “This site as a source” and generate a connection key. Paste the key into Site Replica on another site (for example a local development copy). That site pulls the live site in small encrypted pieces. Nothing large is ever written on the live server.
- Resumable: every piece is saved before moving on, and interrupted jobs continue where they stopped.
- Adapts to slow or strict hosts: smaller pieces after timeouts, automatic retries with back-off.
- Incremental: unchanged files are shared with the previous backup, so later backups only download what changed.
- Verified: every database chunk and file is checked with SHA-256.
Clone and restore, safely.
- The database is imported into temporary tables while the site keeps running. The site is switched in one short step at the end.
- Search-replace that is safe for serialized data, without ever unserializing it (no object injection). It handles JSON-escaped and URL-encoded addresses, and never touches look-alike domains.
- Roll back: after a restore you choose Keep or Roll back. Roll back puts the previous site back exactly.
- Keeps you logged in, keeps this site’s own Site Replica settings, and on local copies discourages search engines and blocks outgoing email (or lets it through to a local mail catcher such as Mailpit, when one is set up).
- Copes with MySQL/MariaDB differences (collations, engines, defaults).
- Back up the site you are on, and restore it from the Backups page if something goes wrong.
Scheduled backups to Google Drive or S3-compatible storage (Amazon S3, Backblaze B2, Cloudflare R2, Wasabi and others). Daily or weekly, database and files or database only, with the number of backups to keep and an e-mail when a backup fails.
- Made for hosts with little free disk: the backup is packed into parts of about 50 MB, and each part is uploaded, checked and deleted before the next is made.
- Runs on the server in the background, continuing where it stopped after timeouts or Google Drive hiccups.
- The parts are ordinary ZIP files. Any site with Site Replica connected to the same Google account can download a backup and restore it.
- Uses Google’s drive.file access: Site Replica can only see the files it created in your Drive.
- S3 uploads are signed (Signature Version 4) and every piece carries its MD5, so the storage rejects damaged data.
Security
- Pulling is off until you turn it on. Keys can expire, be limited to IP addresses and be revoked.
- A key can only read the site: nothing can be uploaded to it.
- Every request is signed (HMAC-SHA256) with replay protection. Responses are encrypted (AES-256-GCM).
- HTTPS is required (except for local development sites).
- Site Replica’s own secrets and settings are never included in backups.
- Before a restore, the table, view and trigger definitions in the backup are checked: only plain definitions of the backup’s own tables are run, so a tampered backup can’t reach other tables, files or servers.
- Backups are stored in a randomly named folder inside wp-content, never in the uploads folder, with deny rules for Apache and IIS. On a server that ignores those rules, the plugin notices and refuses to back up until the folder is protected.
External services
Site Replica only contacts other services that you set up yourself.
Other WordPress sites you connect. When you pull a backup, this site exchanges signed, encrypted requests with the other WordPress site whose connection key you entered. The data is the site’s database and wp-content files. Nothing goes to AccessNow or any other third party.
Google Drive (Google LLC). Used only when you choose Google Drive under Cloud Backups and connect your Google account.
* What is sent, and when: when you connect, the OAuth authorization is exchanged at accounts.google.com and oauth2.googleapis.com. When a backup runs, or when you list, download or delete backups, requests go to www.googleapis.com (Drive API). They carry the backup: this site’s database and files, packed in ZIP parts, plus their names and checksums.
* Access: Site Replica asks only for access to the files it creates (the drive.file scope).
* Terms and privacy: Google Terms of Service, Google Privacy Policy, Google API Services User Data Policy.
S3-compatible storage. Used only when you choose it under Cloud Backups. The same backup data goes, when a backup runs or when you list, download or delete backups, to the storage endpoint you enter. The terms and privacy policy of the provider you choose apply, for example:
* Amazon S3: service terms, privacy
* Backblaze B2: terms, privacy
* Cloudflare R2: terms, privacy
* Wasabi: terms, privacy
Screenshots
Installation
- Install and activate Site Replica on each site involved (Plugins Add New, or upload the ZIP).
- To copy a live site to another site: on the live site open Site Replica This Site as a Source, generate a connection key and paste it into Site Replica Pull & Clone on the other site.
- For scheduled cloud backups: open Site Replica Cloud Backups, choose Google Drive or S3-compatible storage, set it up and choose a schedule.
Backups are stored in a private folder inside wp-content. Nothing is written until you start a backup.
FAQ
-
Where do I get help?
-
Step-by-step help articles, with screenshots, are at https://support.accessnow.com.au/help/workspace-accessnow/accessnow-site-replica. The plugin’s own screens link to the article for each one, under the Help tab at the top right. To ask a question, post in the support forum at https://wordpress.org/support/plugin/accessnow-site-replica/.
-
Where are backups stored?
-
In a randomly named folder inside wp-content, for example
wp-content/accessnow-replica-a1b2c3d4e5f6g7h8, created the first time you use the plugin. A backup is a complete copy of a site, so it does not belong in the uploads folder, which is served to visitors by design; wp-content is where a backup plugin’s own storage belongs. The folder carries deny rules for Apache and IIS, and the plugin checks whether this server serves it anyway — if it does, it says so and refuses to write backups there until it is fixed.Set
ACCESSNOW_REPLICA_STORAGE_DIRin wp-config.php if you would rather keep backups somewhere else. -
What does the plugin write, and where?
-
- Backups, job files and logs: in the storage folder above. Nothing else is written there, and no PHP file is ever created. A backup stores each file once under its checksum, with no file name or extension, and script files compressed, so the folder never holds runnable copies of your site’s code; the list of real names is kept alongside, and a restore puts each file back under its own name.
- During a restore only:
wp-content/mu-plugins/accessnow-replica-compat.php, so that a plugin being replaced cannot interrupt the restore half way through. It is removed when the restore finishes, and it stops doing anything after a day even if the restore never finishes. - If you ask for it when restoring:
wp-content/mu-plugins/accessnow-replica-mail-guard.php, which stops a copied site emailing the original site’s customers. It stays until you delete it, the plugin tells you it is there, and uninstalling the plugin removes it. - For a few seconds during the switch-over: WordPress’s own
.maintenancefile, as core does during an update.
Nothing is written into WordPress core folders, into other plugins’ or themes’ folders, or outside the WordPress installation.
-
Does a backup include WordPress core and wp-config.php?
-
No. Backups contain the database and wp-content. A restore never replaces the destination’s wp-config.php or its drop-ins.
-
Can I restore multisite networks?
-
Not yet. Multisite sites can be backed up, but restoring them is not supported in this version.
-
How do I connect Google Drive?
-
Site Replica Cloud Backups shows the steps: create a Google Cloud project with the Drive API, an OAuth consent screen (published “In production”, otherwise Google ends the access after 7 days) and an OAuth client of type “Web application” with the redirect address shown on the page. Paste the client ID and secret, then click Connect Google Drive. Sites that used the old WP Replica plugin can reuse its Google app with one click.
-
Which S3 storage works?
-
Any storage with the S3 API: Amazon S3, Backblaze B2, Cloudflare R2, Wasabi, MinIO and others. Create a bucket and an access key limited to it, then enter them under Cloud Backups (choose “Other” and enter the endpoint for providers that are not listed).
-
Scheduled backups don’t run on my quiet site.
-
WordPress runs scheduled tasks only when someone visits. Add the cron job shown on the Cloud Backups page in your hosting control panel (every 5 minutes).
-
My host’s firewall blocks the requests.
-
Site Replica tries several request addresses automatically. If the host still blocks it (for example Imunify360 or ModSecurity), the error names the firewall. Ask the host to allow requests containing
accessnow_replica_apifrom the IP address of the site making the backup.
Reviews
There are no reviews for this plugin.
Contributors & Developers
“AccessNow Site Replica” is open source software. The following people have contributed to this plugin.
Contributors
Translate “AccessNow Site Replica” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.0.4
- Sites with many large database values (big posts, page-builder data, serialized options) back up much faster: those values now travel many to a request instead of one at a time. Older versions on either site keep working with the one-at-a-time way.
- The progress panel’s “since the last update” no longer climbs while large database values are being fetched.
- Get support now goes to the wordpress.org support forum, and the Plugins screen has a Rate it link.
- When Site Replica Pro is installed beside this plugin, this copy steps aside instead of stopping the site, and deleting either copy keeps the backups and settings they share.
- The key label’s example text no longer names a person.
1.0.3
- Backups no longer keep a copy of your site’s folders. Each file is stored once, under its checksum, with script files compressed, so the backup folder never holds runnable copies of your site’s code. Backups made by earlier versions still restore.
- All database access goes through WordPress’s own database layer.
- A full restore now keeps media and must-use plugins that exist only on the site being restored to. The restore plan lists the plugins that will be removed.
- Fix: on hosts with a short time limit, cloud backups and downloads could stall without moving.
- The progress panel names the large file being copied, shows the speed, and says when it is waiting.
- New: Help articles and Get support links on the Plugins screen, and a Help tab on each of the plugin’s screens.
- Job files are plain JSON.
1.0.2
- A pull only writes files inside its own backup folder, whatever file names the other site sends.
- Another WordPress installation that shares the database under a longer table prefix (for example wp_dev_ beside wp_) is no longer included in backups, and a restore leaves its tables alone.
- Table definitions in a backup are checked more strictly before a restore runs them.
- Driving a running job now needs an administrator’s login and a nonce as well as the job’s own key. When a restore leaves nobody logged in, it finishes in the background and asks you to log in to the restored site to keep it or roll it back.
- The other site’s addresses come from that site itself, so sites with a moved wp-admin or REST prefix connect too. Connections made with older keys pick them up on their next backup.
- Database queries go through WordPress’s database layer, with prepared statements.
- Opening Site Replica’s pages writes nothing: the private storage folder is made when the first backup starts, as the readme says.
- The loopback that runs background backups also carries a nonce.
- A restore finished in the background is no longer reported as a backup, and a scheduled-backup event carried over from the backup’s source site no longer runs on a site without a schedule.
1.0.1
- Backups are stored inside wp-content rather than above the WordPress installation, and the folder no longer contains a PHP file. Existing installs keep the folder they already use.
- Activating the plugin does nothing and creates nothing; the storage folder is made the first time it is needed.
- A pull or a download now refuses to start if this server hands out the backup folder over HTTP, instead of only warning.
- The temporary restore helper in mu-plugins expires by itself if a restore never finishes, and the optional mail guard no longer writes blocked recipients to the error log.
- The endpoints that drive a running job are registered only while a job is running.
1.0.0
- First release: pull backups, incremental backups, clone and restore with rollback.
- Back up the site you are on.
- Scheduled backups to Google Drive or S3-compatible storage in ZIP parts (low disk use), with retention, e-mail notices and download back into any site.