WPHammer
Log in
  • Storage providers
  • Backup configuration
  • Incremental backups
  • Scheduled dispatch
  • Retention and pruning
  • Failure notifications
  • Related

    • Backup Overview

    WPHammer provides three independent backup systems, each designed for a different use case. Together, they give you layered protection — from quick rollbacks during deployments to long-term archival storage for disaster recovery.

    Three backup types

    Database backups

    Automated daily database backups managed through the Laravel Forge API. These are the simplest backup type — they capture your WordPress database and store it with your configured storage provider. Ideal for protecting against data corruption or accidental content changes.

    See Database Backups for details.

    Snapshots

    Point-in-time snapshots stored locally on the server. Snapshots are fast because they do not transfer data to external storage — the database export and optional file archive stay on the same server. Best used before risky operations like plugin updates, WP-CLI commands, or staging pushes where you want a quick rollback option.

    See Snapshots for details.

    Time capsules

    Full-site archives uploaded to S3-compatible storage with support for incremental backups. Time capsules capture both the database and files, track changes via file manifests, and can restore to the original site or a completely different server. This is the most comprehensive backup type, designed for disaster recovery and site migration.

    See Time Capsules for details.

    Storage providers

    Database backups and time capsules require an S3-compatible storage provider. WPHammer uses the storage provider configured in Laravel Forge, stored locally as a StorageProviderCredential record. Supported providers include:

    • Amazon S3
    • DigitalOcean Spaces
    • Hetzner Object Storage
    • OVH Object Storage
    • Scaleway Object Storage
    • Custom S3-compatible endpoints

    Each credential stores the provider type, region, bucket, optional base directory, endpoint URL, and encrypted access keys. The server's forge_storage_provider_id links to the credential, and isBackupReady() confirms both the provider ID and matching credentials exist before allowing backup operations.

    Snapshots do not require a storage provider — they are stored directly on the server filesystem.

    Backup configuration

    Each site can have a BackupConfig that controls automated database and file backups:

    Setting Description
    frequency Manual, daily, or weekly scheduling
    preferred_hour UTC hour for scheduled runs (0–23), or auto-staggered
    include_files Whether to include file backups alongside database
    file_excludes Additional paths to exclude from file backups
    retention_count Number of backups to keep before pruning older ones
    is_active Enable or disable automated backups

    When preferred_hour is not set, WPHammer auto-stagers the backup time using a CRC32 hash of the site ID, distributing backups across the 0–5 AM UTC window to avoid all sites backing up simultaneously.

    Incremental backups

    Both file backups and time capsules support incremental mode. The ManifestDiffService compares file manifests (SHA256 hashes of every file) between the current and previous backup. If less than 80% of files have changed, the backup runs in incremental mode — only archiving modified files and recording deletions. This significantly reduces backup time and storage costs for sites with large media libraries.

    Scheduled dispatch

    The DispatchScheduledBackupsCommand runs once per hour and checks which BackupConfig records are due:

    • Daily backups run when the current UTC hour matches the config's effective hour
    • Weekly backups run only on Sundays at the matching hour
    • Backups are skipped if one has already been created today for that config

    See Time Capsules for the separate capsule dispatch system with per-server throttling.

    Retention and pruning

    The PruneExpiredBackupsCommand enforces the retention_count on each config. It keeps the most recent N completed backups and deletes older ones. Deletion includes:

    • Removing the Forge backup instance via API
    • Deleting the BackupFileManifest record
    • Deleting associated RestorePoint records
    • Deleting the Backup record itself

    Failure notifications

    When a backup fails (either the database or file component), WPHammer sends a BackupFailedNotification to the team owner with details about what went wrong.

    Related