Skip to main content

Offsite and Local Redundancy

Redundancy is not just "multiple copies". It is multiple copies in different failure domains: different disks, different servers, or different accounts. For WordPress, that usually means a local copy for fast restores and an offsite copy that survives VPS loss.

Quick Summary
  • Local backups improve RTO (restore speed).
  • Offsite backups improve survivability.
  • Isolation matters: separate credentials and permissions.
  • Verify both copies and practice restores.

Failure domains to think about​

  • Same disk: fastest, least safe.
  • Same VPS (different directory): not a real safety boundary.
  • Same provider (different server): better.
  • Different provider or object storage: best survivability.

A simple redundancy model​

Example:

  • Local: /backups/ on the VPS (fast restore)
  • Offsite: remote:wp-backups/site-a/ (durable)

Workflow:

  1. Create local artifacts
  2. Verify
  3. Copy offsite
  4. Verify remote
local-to-offsite-copy-and-verify.sh
rclone copy /backups remote:wp-backups/site-a
rclone lsf remote:wp-backups/site-a | sed -n '1,60p'

Isolation against compromised VPS​

If an attacker gains root on the VPS and has your remote credentials, they may delete remote backups.

Mitigations:

  • Use remote storage features like bucket versioning/immutability where available.
  • Use separate credentials for read vs write.
  • Store encryption keys outside the VPS.
  • Avoid long-lived root tokens.
warning

Offsite storage is not automatically safe. If the VPS can delete remote backups, a compromise can become total data loss.

Next steps​

  • 3-2-1 model: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/321-backup-strategy-for-wp.mdx.
  • Retention: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/rotation--retention-policies.mdx.