Setting up Daily Off-Site Backups and Automated Restore Tests for Production Sites

Why WordPress Backup Plugins Stored on the Same Disk Fail When Needed

When we onboard a new hosting client and ask about their backup strategy, they often point to a WordPress backup plugin configured by a previous developer. When we inspect the server, we find thirty gigabytes of uncompressed .zip files sitting inside /wp-content/uploads/backups/ on the exact same disk as the live website.

Storing backups on the production server violates basic disaster recovery rules. First, those huge archives fill up disk inodes and slow down the server. Second, if the cloud provider suffers a volume failure or an attacker gains access to the web root, your live site and your backups disappear together.

Implementing the 3-2-1 Backup Rule With Encrypted Object Storage

At Softlimes, we run backups at the infrastructure level outside the web application. We follow a strict 3-2-1 architecture: three copies of your data, stored across two separate cloud providers, with at least one immutable off-site copy in a different geographic region.

Every night (and hourly for high-volume transactional databases), our backup daemon streams compressed, client-side AES-256 encrypted snapshots using Restic to an isolated Amazon S3 or Backblaze B2 bucket configured with Object Lock.

• Use --single-transaction flags on MySQL/MariaDB and pg_dump on PostgreSQL so database dumps are consistent without locking live tables.
• Enforce S3 Object Lock (WORM) retention rules so even a compromised server key cannot delete or overwrite existing backup snapshots.
• Retain hourly database snapshots for 48 hours, daily snapshots for 30 days, weekly for 12 weeks, and monthly for 1 year.
• Monitor backup completion via dead-man switch alerts that page our engineers if a scheduled backup fails to check in on time.

Why an Untested Backup Is Just a Wish

Having green checkmarks in a backup log does not mean you can actually recover your business under pressure. We have audited legacy systems where nightly backups ran for two years, only for the owner to discover during an outage that the SQL dump file was zero bytes due to an expired database user password.

A backup system is only as good as its last verified restore. Our infrastructure pipeline automatically spins up an isolated ephemeral container every week, pulls the latest encrypted off-site snapshot, imports the database, and boots the application.

Measuring Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

Our automated restore test runs a headless check against the restored container to confirm that database tables contain recent rows and the homepage renders HTTP 200, then logs the exact time required to complete the recovery.

Knowing with certainty that we can restore a complete production database and file tree to a fresh server in under twenty minutes gives business owners real peace of mind.

Each weekly restore verification sends a structured pass-or-fail report with database row counts and boot timings to our operations channel. You never have to wonder whether your disaster recovery plan works in practice.