Skip to main content

Disaster Recovery Workflow

Disaster recovery is a process, not a command. This page gives you a repeatable workflow for restoring WordPress after VPS loss, compromise, or major corruption.

Quick Summary
  • Pick a restore point (timestamped backups).
  • Rebuild a clean server.
  • Restore database first, then files.
  • Validate in staging before switching traffic.
  • Rotate secrets after recovery.

Preparation (before an incident)​

  • Document where backups live (local + offsite paths).
  • Document how to decrypt backups (keys/passphrases).
  • Reduce DNS TTL so cutovers are faster.
  • Practice a monthly restore drill.

During an incident​

Decide what you are recovering from​

  • Accidental deletion: local restore may be enough.
  • Corruption: choose a snapshot from before the corruption.
  • Compromise: rebuild on a new server and assume secrets are leaked.

Freeze writes​

If the server is still alive, reduce new writes:

  • Enable maintenance mode.
  • Stop cron.
  • Stop services if needed.
stop-services-for-controlled-restore.sh
sudo systemctl stop nginx || true
sudo systemctl stop apache2 || true
sudo systemctl stop php8.2-fpm || true
warning

Stopping services causes downtime. Do it only when you have decided to restore and you need a stable filesystem/database state.

  1. Provision a clean VPS (same or newer OS).
  2. Install the stack (web server, PHP, database).
  3. Pull backups from offsite.
  4. Restore database.
  5. Restore files.
  6. Fix permissions.
  7. Validate and then re-enable traffic.

Restore database (staging first)​

restore-db-to-staging.sh
zstd -dc /backups/wp-db-2026-03-01.sql.zst | mysql wordpress

Restore files to a staging directory​

restore-files-to-staging.sh
sudo rm -rf /tmp/restore-test
sudo mkdir -p /tmp/restore-test

sudo tar --use-compress-program=zstd -xf /backups/wp-files-2026-03-01.tar.zst -C /tmp/restore-test
sudo find /tmp/restore-test -maxdepth 3 -type f -name wp-config.php -print

Fix ownership and permissions​

fix-wordpress-permissions.sh
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;

Post-restore steps​

  • Rotate database passwords, salts, API keys, and SSH keys.
  • Review plugin/theme integrity.
  • Re-enable cron.
  • Update monitoring/alerts.

Next steps​

  • Practical runbook: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/empty-2.mdx.
  • RPO/RTO planning: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/rpo-vs-rto.mdx.