Backup and Disaster Recovery for PHP Websites: A Practical Guide

Every PHP website sits on a stack of moving parts: a web server, PHP runtime, MySQL or PostgreSQL database, configuration files, uploaded assets, and often a hundred small cron jobs. Any one of those pieces can fail — a corrupted table, a rogue rm -rf, a ransomware locker — and if you only have a single backup of the database from last week, you’re in trouble. At DigiForge, we’ve recovered more PHP sites than we care to count, and the difference between a four-hour recovery and a four-day nightmare always comes down to one thing: a properly engineered backup and disaster recovery strategy.

Why Backup Alone Isn’t Enough

Many teams conflate backup with disaster recovery. A backup is a periodic copy of data. Disaster recovery is the entire process of getting your application back online — restoring data, reconfiguring services, redirecting traffic, and validating that everything works. As one IT resilience report put it, "protecting your data with backups is no longer sufficient to survive" (source). A backup without a tested recovery plan is just insurance you haven’t read yet.

In a PHP context, the difference is stark. Your database backup might be perfectly intact, but if you don’t know how to point Apache or Nginx at the restored database, change the .env credentials, or rebuild the PHP opcache, you’re still offline. And downtime, as we all know, costs money and trust. A comprehensive disaster recovery (DR) plan must cover every layer of your server stack, not just the data.

The Backup and Recovery Stack for PHP Sites

We break a PHP application’s backup into five distinct layers. Missing any one can render the others useless:

1. Code and version control (Git repositories, including tags and branches).
2. Database dumps (MySQL, PostgreSQL, or MariaDB).
3. Web server configuration (Nginx/Apache virtual hosts, SSL certificates, PHP-FPM pools).
4. Application configuration (.env, config files, hard-coded credentials).
5. User-uploaded content (images, PDFs, any files stored outside the database).

Let’s walk through each layer with practical recommendations.

1. Code and Version Control

Your application code should live in a Git repository — no exceptions. But a Git push is not a backup. We’ve seen teams rely on a single remote branch and lose weeks of work when a force push or corrupted repo strikes. Use a Git hosting provider (GitHub, GitLab, Bitbucket) and set up automated mirrors to a second location. For production deployments, tag every release. That way, if you need to roll back to a known good state, you’re not guessing which commit was live.

2. Database Backups

Database backups are the most critical and most neglected. A daily mysqldump to a local directory is better than nothing, but we’ve seen those fills up a disk and stop running silently. Automate your dumps with a script that rotates old backups, compresses them, and ships them offsite — to S3, Backblaze, or a separate server. Use mysqldump --single-transaction for InnoDB tables to avoid locking reads, and test your restore periodically. A backup that can’t be restored is worthless.

3. Server and Web Server Configuration

Your PHP site runs on more than code and data. Nginx or Apache configuration files, PHP-FPM pool settings, SSL certificates, and cron job definitions are all unique to your server. We store these in a separate Git repository (or as part of the application repo under a deploy/ directory) and back them up alongside the rest. Services like Certbot auto-renew Let’s Encrypt certificates, but if your server dies, those certificates are gone. Back up /etc/letsencrypt/ or switch to DNS-based validation that survives a rebuild.

4. Environment and Application Configuration

PHP applications often have a .env file with database credentials, API keys, and secrets. These must never be in version control. We use a secrets manager (like HashiCorp Vault or envkey) for production, but at minimum, encrypt and store a copy of .env in your backup system. If you lose this file, you’re not restoring your site — you’re rebuilding it.

5. User Uploads and Media

Images, PDFs, and other uploads are often stored in a public/uploads directory. They grow fast and can bloat database backups if stored as BLOBs. Best practice: keep uploads on a separate volume or object store (S3, DigitalOcean Spaces). If they’re on the server’s filesystem, include that directory in your offsite backup. Use rsync or rclone to sync to cloud storage daily.

Automating and Testing Your Recovery Plan

A backup strategy is only as good as its recovery. We’ve walked into too many post-mortems where the client said, “We have backups,” but never tried to use them. Disaster recovery is a process, not a product. You need to write down — and, more importantly, rehearse — how you’ll bring your PHP site back.

• Write a runbook. Document every step: where backups are stored, how to restore the database, which commands rebuild the web server, how to update DNS if your IP changes.
• Automate restores. Use scripts or orchestration tools (Ansible, Puppet, or even a simple Bash script) to provision a new server and restore your application from backups. If you can’t spin up a clone in under an hour, your DR plan is too slow.
• Test quarterly. Restore your entire PHP stack on a fresh server (a new VPS or local VM) and verify the site works. Test DNS propagation, SSL, database connections, cron jobs, and every user flow. Fix anything that breaks.

In our experience, the most common failures during a recovery drill are credential mismatches (hardcoded database passwords that don’t match the restored .env), missing PHP extensions, and incomplete uploads. Each failure is a gift — it reveals a gap you can fix before a real disaster.

“A backup without a tested recovery plan is just a hope.” — DigiForge engineering principle

Choosing Storage Locations and Formats

The old 3-2-1 rule still holds: three copies of your data, on two different media, with one copy offsite. For PHP websites, a common setup is: (1) the live server’s local backup script, (2) an offsite cloud bucket, and (3) a cold storage archive (e.g., Glacier) for monthly snapshots. Encrypt backups with GPG or client-side encryption before uploading to any third party.

Incremental backups save bandwidth and storage, but they increase restore complexity. For a medium-traffic PHP site, a daily full database dump plus hourly binary logs (if needed) strikes a good balance. Filesystem backups can be incremental via rsync — just make sure your tooling can rebuild a consistent state from incrementals.

When Disaster Strikes: The Recovery Runbook

Let’s simulate a worst-case: a ransomware attack encrypts your PHP web root and database. Here’s the high-level recovery flow we use at DigiForge:

1. Isolate the infected server — kill all external access, snapshot for forensics if needed.
2. Provision a clean server — a fresh VPS with the same OS and PHP version.
3. Restore code from Git — clone the tagged release that was running before the attack.
4. Restore configuration — copy .env, web server configs, SSL certificates (or reissue them).
5. Restore database — import the latest clean dump, then replay binlogs up to the point of infection (if available).
6. Restore uploads — rsync from backup storage to the new server’s uploads directory.
7. Test everything — run health checks, verify database connections, check that cron jobs execute.
8. Switch DNS — point your domain to the new server’s IP (lower TTL beforehand).
9. Monitor — watch logs and uptime for 24 hours. Declare recovery only after sustained green.

This entire process can take 2–4 hours if your backups are well-organized and you’ve practiced. Without practice, it can stretch into days.

Building a Culture of Recovery

Disaster recovery isn’t a one-time project — it’s an ongoing practice. Every time you update your PHP version, add a new cron job, or change a web server directive, update your runbook and retest. We’ve seen too many teams treat backups as a checkbox item. A true DR strategy is woven into your deployment pipeline, your monitoring, and your team’s muscle memory.

If you’re responsible for a PHP website, start today. Review your backup coverage for all five layers, automate what you can, and schedule your first recovery drill. And if you’d like a second set of eyes on your strategy, get in touch with DigiForge. We’ve built and recovered enough PHP sites to know what works — and what doesn’t.