WPHammer
Log in
  • Restoring from snapshots
  • Restoring from time capsules
  • Safety mechanisms
  • Choosing a restore method
  • Related

    • Restoring Backups

    WPHammer provides restoration procedures for each backup type. Every restore path includes safety mechanisms to protect the current site state, and each follows a deployment pipeline so you can track progress step by step.

    Restoring from database backups

    Database backups create RestorePoint records when they complete. To restore, you initiate a restore from the restore point, which dispatches the RestoreBackupPipeline:

    Pipeline steps

    1. Pre-restore backup — the PreRestoreBackupJob creates a safety backup of the current database before any changes are made. This gives you a rollback path if the restore does not produce the expected result.

    2. Restore database — the RestoreDatabaseJob calls the Forge API to restore the backup instance to the site's database. The restore point status transitions to Restoring.

    3. Download file backup — if the original backup included files, the DownloadFileBackupJob downloads the archive from S3 to a temporary directory on the server.

    4. Apply file restore — the ApplyFileRestoreJob extracts the backup archive to the web directory, handling file permissions and ownership.

    5. Post-restore cleanup — the PostRestoreCleanupJob removes temporary files, flushes WordPress caches (wp cache flush), and updates the restore point status to Restored.

    Restore point lifecycle

    Each RestorePoint tracks its own status via the RestorePointStatus enum:

    • Available — the restore point is ready to use
    • Restoring — a restore is currently in progress
    • Restored — the restore completed successfully
    • Expired — the restore point is no longer available (backing backup was pruned)

    Restoring from snapshots

    Snapshot restores are the fastest option since all data is already on the server. The RestoreSnapshotAction dispatches the RestoreSnapshotPipeline with a single step:

    1. Restore snapshot — the RestoreSnapshotJob imports the database (wp db import) and for full snapshots, extracts the file archive (tar -xzf). WordPress caches are flushed and the snapshot's restored_at timestamp is set.

    Snapshot restores do not create a pre-restore safety backup — they prioritize speed. If you want a safety net, create a second snapshot before restoring.

    Restoring from time capsules

    Time capsule restores are the most comprehensive, handling incremental chain resolution and supporting cross-server restoration.

    Restore to original site

    The RestoreTimeCapsulePipeline runs five steps:

    1. Safety snapshot — creates a snapshot of the current state as a rollback point
    2. Download — resolves the incremental chain (finding the full base capsule and all intermediaries), then downloads the database dump and all file archives
    3. Database restore — imports the database using wp db import
    4. File restore — extracts the full archive first, then each incremental archive in sequence, applying deletions.json removals at each step
    5. Cleanup — removes temporary files, flushes caches, fixes permissions

    Restore to a new site

    The RestoreCapsuleToNewSitePipeline creates a brand new site on a different server:

    1. Create a database and user on the destination server via SSH
    2. Create the WordPress site on Forge
    3. Create a custom domain via the Forge API
    4. Set up configuration directories
    5. Download the capsule to the destination server
    6. Restore the database and files
    7. Clean up and finalize — the new site is marked as ready

    This allows disaster recovery to a different server or site migration across your infrastructure.

    Safety mechanisms

    WPHammer builds safety into the restore process:

    • Pre-restore backups — database backup restores automatically create a safety backup before proceeding
    • Pre-restore snapshots — time capsule restores create a local snapshot before proceeding
    • Status tracking — each restore is a deployment pipeline with step-by-step status, so you can see exactly where it is and catch failures early
    • Failure notifications — if a backup that feeds a restore fails, BackupFailedNotification alerts the team owner

    Choosing a restore method

    Scenario Best option
    Undo a recent content change Database backup restore point
    Rollback a failed plugin update Snapshot (full type)
    Recover after a server failure Time capsule restore to new site
    Migrate a site to a new server Time capsule restore to new site
    Quick rollback during testing Snapshot (database only)
    Restore to a specific date Time capsule from that date

    Related