In DRSite, click Check status on the site. Tools \u2192 DRSite then shows when DRSite last reached the site.<\/li>\n<\/ol>\n\nDRSite calls the site's REST API with header X-Drsite-Api-Key<\/code>; every call needs the saved key.<\/p>\n\nExternal services<\/h3>\n\n
This plugin connects the site to DRSite (https:\/\/drsite.app\/), a backup, monitoring and failover service run by Netcetera, the plugin's author. Without a DRSite account and API key the plugin does nothing.<\/p>\n\n
What is sent, and when:<\/p>\n\n
\n- Backups: when DRSite asks for a backup (on the site's schedule, or when the site owner clicks Back up now in DRSite), the plugin creates a ZIP of wp-content, a database dump and a copy of wp-config.php, and uploads it to DRSite's storage with a one-time upload link that DRSite provides. DRSite's storage is S3-compatible object storage (IDrive e2 or Backblaze B2) used by DRSite on the site owner's behalf.<\/li>\n
- Site health: when DRSite checks the site, the plugin returns WordPress, PHP and database versions, Site Health results, disk and database sizes, and its own version.<\/li>\n
- Restores: when the site owner restores from DRSite, DRSite tells the plugin which backup to restore; the plugin restores it from the copy kept on the site. Nothing is sent.<\/li>\n<\/ul>\n\n
Nothing is sent unless DRSite calls the site with the site's own API key. The plugin does not track visitors or send personal data about them, other than any personal data stored in the site's own files and database, which is part of every backup.<\/p>\n\n
DRSite terms of service: https:\/\/drsite.app\/terms\nDRSite privacy policy: https:\/\/drsite.app\/privacy<\/p>\n\n\n
\n- In WordPress, go to Plugins \u2192 Add New, search for DRSite and install it. Or upload the
drsite-backup<\/code> folder to \/wp-content\/plugins\/<\/code>.<\/li>\n- Activate it.<\/li>\n
- Open Tools \u2192 DRSite and save the API key from DRSite.<\/li>\n<\/ol>\n\n\n
\nWhere are backups stored?<\/h3><\/dt>\nIn DRSite's storage. The plugin makes each backup in wp-content\/uploads\/drsite-backups\/<\/code> while DRSite collects it.<\/p><\/dd>\nHow do I restore?<\/h3><\/dt>\nFrom the site in DRSite: Backups \u2192 WordPress.<\/p><\/dd>\n\n<\/dl>\n\n\n
2.1.2<\/h4>\n\n\n- Health check runs WordPress's Site Health tests (they were being skipped) and lists plugins, themes and WordPress core with an update waiting, for DRSite's care report.<\/li>\n<\/ul>\n\n
2.1.1<\/h4>\n\n\n- Uploads to DRSite storage go through the WordPress HTTP API, still streamed from disk so large backups are not held in memory.<\/li>\n<\/ul>\n\n
2.1.0<\/h4>\n\n\n- Incremental backups when DRSite asks for them (Premium and Enterprise): only files changed since the night's full backup, plus the whole database. A restore puts the full back first, then the changes.<\/li>\n
- Keeps only the last two days of backups on this server; DRSite keeps the rest.<\/li>\n<\/ul>\n\n
2.0.2<\/h4>\n\n\n- Updates come from WordPress.org like any other plugin; DRSite no longer installs updates itself.<\/li>\n
- Text domain and readme tidied for the WordPress.org directory, with an External services section.<\/li>\n<\/ul>\n\n
2.0.1<\/h4>\n\n\n- Fixed: a backup requested by DRSite could stop with \"There has been a critical error on this website\" on sites where nothing else loads wp-admin's file functions (wp_tempnam).<\/li>\n<\/ul>\n\n
2.0.0<\/h4>\n\n\n- Slimmed down: Tools \u2192 DRSite only connects the site (API key and connection status). Backups, restores and health checks run from DRSite.<\/li>\n
- Only DRSite keys (drs_ + 48 characters) are accepted; the old sk-live- generator is gone.<\/li>\n<\/ul>\n\n
1.4.3<\/h4>\n\n\n- DRSite can update the plugin from its control panel (Backups \u2192 WordPress \u2192 Update plugin).<\/li>\n<\/ul>\n\n
1.4.2<\/h4>\n\n\n- On Enterprise, a full backup a day also goes straight to the site's DRSite Cold Vault.<\/li>\n<\/ul>\n\n
1.4.1<\/h4>\n\n\n- DRSite's key-protected routes keep working on sites that restrict the REST API to signed-in users (\"REST API restricted to authenticated users\"). Other routes stay restricted.<\/li>\n<\/ul>\n\n
1.4.0<\/h4>\n\n\n- Uploads each backup straight to DRSite's storage with a one-time link, instead of DRSite downloading it from your site. Large backups no longer pass through DRSite's servers.<\/li>\n<\/ul>\n\n
1.3.3<\/h4>\n\n\n- Sanitises the request URI, route and API key header before use.<\/li>\n
- Plural form for the backup count; reviewer notes on intentional raw file and database calls.<\/li>\n<\/ul>\n\n
1.3.2<\/h4>\n\n\n- Text domain matches the plugin slug (drsite-backup), so translations load.<\/li>\n
- Tested with WordPress 7.1.<\/li>\n
- Escapes the settings link in the admin notice; uses wp_delete_file().<\/li>\n<\/ul>\n\n
1.3.1<\/h4>\n\n\n- Backups leave out other plugins' backup folders (UpdraftPlus, All-in-One WP Migration, Duplicator, BackWPup, WPvivid and others), caches, Wordfence logs and debug.log, so they are smaller and faster.<\/li>\n<\/ul>\n\n
1.3.0<\/h4>\n\n\n- New key-protected REST route GET \/drsite\/v1\/download?file=\u2026 streams a backup ZIP, so DRSite can keep a copy off this server and use it for the standby copy.<\/li>\n<\/ul>\n\n
1.2.2<\/h4>\n\n\n- Backup, restore, download, and API key forms post to Tools \u2192 DRSite instead of admin-post.php.<\/li>\n<\/ul>\n\n
1.2.1<\/h4>\n\n\n- A valid X-Drsite-Api-Key is accepted on \/drsite\/v1 even when the REST API is limited to logged-in users.<\/li>\n<\/ul>\n\n
1.2.0<\/h4>\n\n\n- Added REST health endpoint
GET \/drsite\/v1\/health<\/code> with core Site Health checks, DB + disk stats, backup summary; added Site Health snapshot to the Tools \u2192 DRSite page.<\/li>\n<\/ul>\n\n1.1.0<\/h4>\n\n\n- Added REST restore endpoint
POST \/drsite\/v1\/restore<\/code> (requires file<\/code> + \"confirm\": true<\/code>).<\/li>\n<\/ul>\n\n1.0.0<\/h4>\n\n\n- Initial release: API key gate, backup ZIP, restore, REST endpoints.<\/li>\n<\/ul>","raw_excerpt":"Asks for an API key on first run, then creates a restorable ZIP (wp-content + database.sql + manifest).","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/382866","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=382866"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/drsiteapp"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=382866"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=382866"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=382866"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=382866"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=382866"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=382866"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}