Know how recovery works before you need it.

It is a WordPress plugin for creating, storing, importing, transferring, verifying, and restoring site backups. The interface is intended for everyday WordPress users, while long-running work is processed in resumable server batches.

The core plugin is being prepared for free public distribution. The download page will link to the official WordPress.org listing after submission and approval.

No for ordinary manual use. Backups and restores run from WordPress admin. Scheduled backups depend on WordPress Cron or, when it is disabled or unreliable, a hosting control-panel scheduler that requests wp-cron.php.

Multisite restoration is not supported in the current release. The Health page identifies Multisite and blocks unsafe incomplete restore workflows.

Full site is the safest general choice. Files only is useful before changing themes, plugins, or core files. Database only is useful before content or settings changes and is typically much smaller.

Yes. WordPress core is included in files and full backups so packages remain self-contained and can support emergency boot recovery. Plugin-owned backup storage is always excluded.

They can be included in file-based backups. During a normal restore, the destination wp-config.php is preserved so database credentials and environment-specific configuration are not overwritten blindly. A validated backup .htaccess can be restored where appropriate.

The job saves progress between batches. Continuation can use the admin browser, WordPress Cron, and recovery mechanisms. If the browser closes or the server stops, the job is designed to continue or resume from a saved checkpoint rather than restart from zero.

Yes. Retention protection excludes a backup from automatic cleanup until you explicitly remove that protection.

The source package, restore mode, format, disk readiness, WordPress content, URL, prefix, and recovery capability are checked first. If enabled, a protected safety snapshot completes before destructive work begins.

It is a protected full backup of the destination immediately before restore. If restoration fails after changing the database or files, the snapshot provides an automatic rollback source. It is optional, but recommended.

It preserves the destination administrator who starts the restore and imports the source backup’s other users. This helps avoid an unnecessary logout or losing access after restoring a package from another site.

It is a private, job-specific URL that works independently from the ordinary WordPress admin. Once its safety snapshot is ready, it can repair required boot files, request resume, or initiate rollback. Treat it like a temporary password and never share it publicly.

The restore records its phase, offsets, heartbeat, and protected source. A watchdog can recognize an interrupted job and schedule recovery. The status page shows recovery attempts and the current saved position.

It checks database access, destination URLs, table prefix, plugin availability, WordPress core, active theme files, preserved administrator access, source references, recent fatal errors, maintenance cleanup, and HTTP responses for the homepage, login, and admin.

They are stored in plugin-controlled WordPress content directories protected from ordinary web access. The Health page checks whether backup, working, restore, and log directories are writable.

Yes. Choose Connect Google Drive and approve the limited permission shown by Google—no personal Google Cloud credentials are required. The plugin requests access only to files it creates or that you explicitly share with it. Uploads are resumable, and a local safety copy remains until required remote verification completes.

The Import page uploads packages in chunks rather than relying on one large PHP request. The assembled file is validated before it is registered as an imported backup.

No. It deliberately receives only the package. The destination administrator reviews the imported backup and chooses whether and how to restore it.

A key is a short-lived, one-use authorization created by the destination. Expiration and single-use behavior reduce the risk of an old key accepting another package later.

The current release requires PHP 8.0 or newer, WordPress 6.4 or newer, a single-site installation, the PHP ZIP extension for file-based packages, writable protected storage, and sufficient free disk space.

It is designed for those environments, but no plugin can guarantee every hosting configuration. Processing starts on the fast path and reduces batch size and request pacing when interrupted responses indicate a constrained server.

No. Normal servers stay on the native fast path. Compatibility and ultra-compatibility settings are activated only for the affected job after repeated request interruptions.

It is itself a complete protected backup of the current destination. On a slow virtual filesystem, scanning and archiving thousands of small WordPress files can take longer than extracting an existing ZIP during restore.

The backup and restore pipeline normalizes supported identifier styles, including standard backticks and ANSI-style double-quoted identifiers, into a portable protected restore format.

System information, health checks, sanitized plugin settings, recent redacted logs, Cron status, and storage status. It excludes configured secrets such as passwords, authorization headers, tokens, cookies, and client secrets.

First confirm whether the percentage, current step, or elapsed time changes. Do not start another job. Capture the status screen, wait for the recovery state, and generate a new support bundle after the problem occurs.

No. Never place a recovery URL or token in a public post, screenshot, or support bundle. Share only the job number, state, and redacted diagnostics.