September 11, 2026
10 min read
By Kokil Thapa | Last reviewed: September 2026
You will eventually lose data. A disk fails, a deploy goes wrong, or someone runs the wrong SQL. To survive that moment, you must design a backup strategy that works before panic sets in. That means defining recovery targets, choosing backup types, storing copies off-site, and proving restores on a schedule—not just adding a cron job and calling it done. This guide walks through the same decisions I apply on production Linux servers for client projects in Nepal and abroad, from Laravel apps on Ubuntu to WooCommerce stores on shared hosting.
Quick answer: To design a backup strategy that works, set RPO and RTO targets, follow the 3-2-1 rule with automated full and incremental backups, store encrypted copies off-site, document restore steps, and test recovery monthly on staging hardware.
How Do You Design a Backup Strategy That Works for Production Web Apps?
Start with two numbers every stakeholder can understand. Recovery Point Objective (RPO) is how much data you can afford to lose. Recovery Time Objective (RTO) is how fast you must be back online.
A law-firm portal with daily document uploads might need an RPO of one hour and an RTO of four hours. A brochure site might tolerate 24 hours and a same-day rebuild. Write these down first. Every tool choice flows from them.
Next, inventory what actually matters:
- Application code (usually in Git, but verify tags and env files)
- Database dumps (MySQL 9.7, MariaDB 12.3, or PostgreSQL 18)
- User uploads (
storage/appon Laravel,wp-content/uploadson WordPress 7.1) - Configuration (
.env, Nginx/Apache vhosts, SSL keys outside the repo) - Queue and cache state (often rebuilt, not restored)
On sister legal-tech sites I maintain with Deployer 7 and GitLab CI, code is safe in Git. The real risk is uploaded PDFs, client records, and the database. Your inventory should reflect that split. See our database backup strategies for small servers for schema-specific notes.
The PostgreSQL backup documentation and MySQL 9.7 backup guide both stress the same point: method follows objective. A strategy without RPO/RTO is just file copying.
What Backup Types Belong in a Strategy That Actually Works?
Most production stacks need a layered mix—not a single tool. Think in three layers: full, incremental, and logical exports.
Full filesystem and database dumps
A nightly full dump is your baseline. For MySQL on a Laravel 13.x app:
#!/bin/bash
set -euo pipefail
BACKUP_DIR="/var/backups/mysql"
STAMP=$(date +%F_%H%M)
mkdir -p "$BACKUP_DIR"
mysqldump --single-transaction --routines --triggers \
-u backup_user -p"$MYSQL_PWD" myapp_production \
| gzip > "$BACKUP_DIR/myapp_${STAMP}.sql.gz"
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +14 -delete
Use --single-transaction on InnoDB so reads stay consistent without locking every table. Store credentials in a root-only file, not in the script body.
Incremental and binary log backups
Full dumps alone miss data written between runs. Enable binary logging for point-in-time recovery on MySQL. Our MySQL binary logs guide covers retention and replay.
For file uploads, rsync with hard links saves space:
rsync -a --delete --link-dest=/backups/latest \
/var/www/myapp/storage/app/ /backups/snapshots/$(date +%F)/
ln -sfn /backups/snapshots/$(date +%F) /backups/latest
Compare sync tools in rsync vs rclone for server backups when off-site targets are object storage.
Application-level packages
On Laravel, Spatie Laravel Backup can orchestrate DB dumps, zip storage, and push to S3 in one Artisan command. That fits teams already living in the framework. WordPress shops often use WP-CLI cron jobs—see WordPress automated backups with WP-CLI.
| Backup type | Best for | Typical frequency | Restore speed |
|---|---|---|---|
| Full SQL dump | Small/medium DBs, simple DR | Daily | Moderate |
| Binary log / WAL | Point-in-time recovery | Continuous | Slower, precise |
| Filesystem snapshot | Large upload directories | Daily + incremental | Fast |
| Git + artefact | Application code | Every deploy | Fast (redeploy) |
| Managed snapshot | Cloud VMs, RDS | Hourly/daily | Fast at infra level |
Where Should Off-Site Storage Fit When You Design a Backup Strategy That Works?
Local backups help with quick restores. They do not help when the server is stolen, encrypted, or burned. Off-site storage is non-negotiable.
Common patterns I use:
- S3-compatible object storage — cheap, durable, API-driven. See automate off-site backups to S3.
- Second VPS in another region — rsync over SSH nightly; good for Nepal teams using Indian or Singapore regions.
- Managed backup add-ons — hosting panels often charge Rs 500–2,000/month (~USD 4–15) for remote retention.
Encrypt before upload when data leaves your network:
gpg --symmetric --cipher-algo AES256 \
-o /backups/myapp_$(date +%F).sql.gz.gpg \
/backups/myapp_$(date +%F).sql.gz
Store the GPG passphrase in your password manager. Generate strong passphrases with our password generator if needed. Never commit keys to Git.
For eCommerce sites like Quick And Easy Nepalese Grocery, order tables and payment logs need the same off-site path as catalog data. A partial backup that omits the orders table is worse than no backup—you will trust a broken restore.
Cloud-native teams should read backup and disaster recovery strategy on the cloud and multi-cloud disaster recovery strategy before assuming one provider snapshot is enough.
How Do You Automate a Backup Strategy Without Silent Failures?
A backup job that stops emailing errors is a liability. Automation must be observable.
Cron with logging and alerts
0 2 * * * /usr/local/bin/backup-myapp.sh >> /var/log/backup-myapp.log 2>&1 \
|| mail -s "BACKUP FAILED: myapp" ops@example.com
Better: push metrics to your monitoring stack or use a dead-man switch. If no successful backup file lands in S3 within 26 hours, page someone.
Full setup walkthroughs live in automated server backups complete setup and automate server backups with rsync and cron. Laravel teams should also read Laravel Spatie backup automated database backups.
CI/CD integration
On Deployer-based pipelines, run a pre-deploy DB dump so you can roll back schema changes. Keep at least three releases on disk via symlinked deployments. That is not a substitute for off-site DB backups, but it shortens RTO for bad migrations.
Retention and cost control
A common retention ladder:
- Daily backups kept 14 days
- Weekly backups kept 8 weeks
- Monthly backups kept 12 months
Adjust for compliance. Legal-tech portals may need longer retention for audit trails. Match policy to actual disk and cloud bills—Rs 1,000–5,000/month (~USD 7–37) is typical for a small VPS plus object storage.
How Do You Test Restores So Your Backup Strategy Actually Works?
Backups are inventory. Restores are proof. Schedule a drill at least monthly.
- Provision a throwaway staging VM or local Docker host.
- Download last night's encrypted backup from off-site storage.
- Decrypt, import the database, rsync uploads, copy
.env. - Run smoke tests: login, place test order, download a sample document.
- Record elapsed time—that is your real RTO, not the number on paper.
I've seen teams discover broken grants, missing views, or charset mismatches only during drills. Fix the script, not the panic playbook. After incidents, run a blameless postmortem and update the runbook.
Document every step in a one-page runbook stored outside the server—password manager secure note, Git wiki, or printed copy in the office. Include:
- Where backups live (paths, bucket names, regions)
- Encryption passphrase location
- Restore commands with exact PHP and MySQL versions
- DNS cutover steps if the primary server is gone
- Contact list for hosting and domain registrar
On Adventure Third Pole Trek, booking data and supplier CRM records share one database. A restore test proves both modules come back together. Partial testing gives false confidence.
What Should a Small Business Budget for a Backup Strategy That Works?
Cost scales with data size and RPO, not headline server specs.
| Component | Typical monthly cost (Nepal SMB) | Notes |
|---|---|---|
| Object storage (50–200 GB) | Rs 300–1,500 (~USD 2–11) | S3/B2/Wasabi pricing varies by region |
| Second VPS for rsync target | Rs 800–3,000 (~USD 6–22) | Smallest plan in another region |
| Managed panel backup add-on | Rs 500–2,000 (~USD 4–15) | Easy setup, check retention limits |
| Engineer time (setup + drills) | Rs 5,000–15,000 one-time (~USD 37–111) | Often the best money spent |
Cheaper than rebuilding a lost client portal from scratch. Ongoing support and maintenance contracts often include backup monitoring and quarterly restore tests.
If you host on domain registration and hosting packages, verify whether "daily backup" means off-site or just another folder on the same machine. Ask for retention days and restore SLA in writing.
For larger Laravel or Symfony builds, fold backup design into architecture reviews under enterprise application development. Redis 8.10 caches and queue workers rebuild after restore; plan for warm-up time in your RTO.
Related deep dives: Ubuntu server backup strategies, automate database backups on Linux, and database backup strategies for small servers. The home page lists current service offerings if you need hands-on help.
Key Takeaways
- Define RPO and RTO before choosing tools—every schedule and storage tier follows those numbers.
- Follow 3-2-1: three copies, two media types, one off-site, with encryption on anything leaving the server.
- Backup code (Git), database (mysqldump or WAL), uploads, and
.envtogether—partial coverage fails in real incidents. - Automate with logging and alerts; silent cron failures are the most common production gap.
- Run monthly restore drills on staging and record actual RTO—untested backups are assumptions, not assets.
- Keep a one-page runbook outside the server with paths, passphrases, and DNS cutover steps.
People Also Ask
What is the 3-2-1 backup rule?
Keep three copies of your data on two different types of storage, with at least one copy off-site. It protects against disk failure, operator error, and site-level disasters without requiring exotic hardware.
How often should I back up a production database?
Match frequency to RPO. Daily full dumps suit many SMB sites. Hourly binlogs or managed snapshots suit eCommerce and booking apps where losing a morning of orders is unacceptable.
Are server snapshots enough for disaster recovery?
Snapshots help with fast VM rollback, but they often live in the same cloud account and region. Pair them with logical SQL exports stored off-site so you can recover from account lockout, corruption, or ransomware.
How long should I keep backups?
A 14-day daily, 8-week weekly, and 12-month monthly ladder works for many web apps. Extend retention when contracts or regulations require audit history—common on legal-tech and financial workflows.
Build Your Backup Strategy Before You Need It
Data loss is a when, not an if. When you design a backup strategy that works, you trade a few hours of setup and a monthly restore drill for the ability to recover orders, documents, and client trust in hours—not days. Start with RPO/RTO, implement 3-2-1 with encrypted off-site copies, automate with monitoring, and prove restores on staging. Need help auditing an existing Laravel, WordPress, or custom PHP stack? Contact us for a backup review, or explore Notary Nepal and other portfolio projects where production reliability is non-negotiable.
Frequently Asked Questions
RPO is how much data you can afford to lose; RTO is how fast you must be back online. Define both before choosing tools or schedules.
Keep three copies of your data on two different storage types, with at least one copy off-site. It covers disk failure, operator error, and site-level disasters without exotic hardware.
Expect Rs 300–5,000/month (~USD 2–37) for storage and add-ons, plus Rs 5,000–15,000 one-time (~USD 37–111) for setup and restore drills—far cheaper than rebuilding a lost portal.
Start by writing RPO and RTO targets stakeholders understand—a law-firm portal with hourly document uploads might need one-hour RPO and four-hour RTO, while a brochure site may tolerate 24 hours. Inventory what actually matters: Git for code, database dumps for MySQL 9.7, MariaDB 12.3, or PostgreSQL 18, user uploads in storage/app or wp-content/uploads, and .env plus SSL keys outside the repo. Queue and cache state usually rebuilds. On legal-tech sites I maintain with Deployer 7 and GitLab CI, uploaded PDFs and client records are the real risk, not application code.
Use a layered mix, not one tool. Nightly full SQL dumps are your baseline—mysqldump with --single-transaction on InnoDB keeps reads consistent without locking every table. Enable binary logging for point-in-time recovery between dumps. For uploads, rsync with hard links saves disk on incremental filesystem snapshots. Git covers application code on every deploy. Laravel teams can orchestrate dumps, storage zips, and S3 pushes via Spatie Laravel Backup; WordPress shops often cron WP-CLI jobs. Managed cloud snapshots add fast VM rollback but should not replace logical exports stored off-site.
Back up four things together: application code (verify Git tags and env files exist), database dumps, user uploads, and configuration including .env, web server vhosts, and SSL keys kept outside the repo. Partial coverage fails in real incidents—for eCommerce sites like Quick And Easy Nepalese Grocery, omitting order tables is worse than having no backup because you will trust a broken restore. Redis 8.10 caches and queue workers rebuild after recovery; plan warm-up time inside your RTO rather than trying to snapshot ephemeral state.
Wrap mysqldump in a bash script with set -euo pipefail, store credentials in a root-only file rather than the script body, gzip output to a dated path, and prune files older than your retention window. Schedule via cron with stdout and stderr logged, and alert on failure—mail ops or use a dead-man switch that pages if no successful backup lands in off-site storage within 26 hours. A cron job that stops emailing errors is a liability. On Deployer-based pipelines, also run a pre-deploy DB dump so bad migrations can roll back quickly, though that never replaces encrypted off-site copies.
Match frequency to RPO, not habit. Daily full dumps suit many SMB sites. Hourly binary logs or managed snapshots suit eCommerce and booking apps where losing a morning of orders is unacceptable.
Local backups help quick restores but fail when the server is stolen, encrypted, or destroyed—off-site storage is non-negotiable. Common patterns: S3-compatible object storage for cheap durable retention, a second VPS in another region synced nightly via rsync over SSH, or managed panel add-ons at Rs 500–2,000/month (~USD 4–15). Encrypt before upload with gpg symmetric AES256, store the passphrase in your password manager, and never commit keys to Git. Pipeline: dump, compress, encrypt, upload, then verify with a staging restore drill—not just upload and forget.
After compressing your dump, run gpg with symmetric AES256 encryption so data is protected before it leaves your network. Store the passphrase in a password manager, not on the server or in Git. Generate a strong passphrase if needed and document its location in your runbook alongside bucket names and restore commands. This step matters especially for legal-tech portals holding client documents and for any database containing order or payment records. Encryption without tested decryption during monthly drills is pointless—prove you can decrypt and import on staging hardware.
Snapshots help fast VM rollback but often live in the same cloud account and region as production. Pair them with logical SQL exports stored off-site so you can recover from account lockout, database corruption, or ransomware that encrypts the whole environment. Snapshots alone cannot restore a single table cleanly or move data to a different provider. For production web apps, treat managed snapshots as one layer in a 3-2-1 strategy alongside nightly mysqldump files, encrypted object storage, and documented restore steps—not as the entire plan.
A practical retention ladder for many web apps: daily backups kept 14 days, weekly kept 8 weeks, monthly kept 12 months. Adjust upward when contracts or regulations require longer audit history—common on legal-tech and financial workflows. Match policy to actual disk and cloud bills rather than hoarding indefinitely. Hosting panel "daily backup" offers may cap retention days or keep copies on the same machine; ask for off-site confirmation and restore SLA in writing before relying on them.
The most common gap is automation without observability—a cron job runs until it does not, and nobody notices until data is gone. Missing error alerts, full disks, changed database passwords, broken S3 credentials, and scripts that swallow failures all cause silent gaps. Mitigate with logged cron output, failure notifications, dead-man switches, and monthly restore drills that catch broken grants, missing views, or charset mismatches before an incident. Retention scripts that delete too aggressively or partial backups that skip critical tables also fail quietly until you attempt a real recovery.
Schedule a drill at least monthly on a throwaway staging VM or local Docker host. Download last night's encrypted backup from off-site storage, decrypt, import the database, rsync uploads, copy .env, then run smoke tests—login, place a test order, download a sample document. Record elapsed time; that is your real RTO, not the number on paper. On Adventure Third Pole Trek, booking and supplier CRM data share one database, so partial testing gives false confidence. Fix broken scripts during drills, not during panic. Document steps in a one-page runbook stored outside the server.
Keep a one-page runbook outside the server—in a password manager secure note, wiki, or printed office copy. Include where backups live with exact paths, bucket names, and regions; encryption passphrase location; restore commands matching your PHP and MySQL versions; DNS cutover steps if the primary server is gone; and contact details for hosting and domain registrar. After any incident, run a blameless postmortem and update the runbook. Untested backups stored only on the production box are assumptions, not assets—a runbook nobody can reach during an outage wastes the effort you spent automating dumps.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
