Data loss is one of the most devastating things that can happen to a business. A misconfigured update, a hardware failure, a ransomware attack, or even an accidental rm -rf can wipe out months or years of work in seconds. A solid backup strategy is your insurance policy against all of it.
Why Backups Matter More Than You Think
Most people understand backups are important in theory, but many do not implement them until after a disaster. Consider these scenarios:
- Your database becomes corrupted during a failed migration.
- A disgruntled employee deletes critical files.
- Ransomware encrypts your entire server.
- Your hosting provider has a data center failure.
- You push a bad code deployment that overwrites production data.
In every case, a recent, tested backup is the difference between a minor inconvenience and a business-ending event.
Types of Backups
Full Backup
A complete copy of everything. Every file, every database, every configuration. Full backups are the simplest to restore from but take the most time and storage space to create.
Best for: Weekly or monthly baseline backups.
Incremental Backup
Copies only the data that has changed since the last backup (full or incremental). Much faster and smaller than full backups, but restoration requires the last full backup plus every incremental backup in sequence.
Best for: Daily backups between full backups.
Differential Backup
Copies all data that has changed since the last full backup. Larger than incremental backups but faster to restore since you only need the last full backup plus the latest differential.
Best for: A middle ground when you want simpler restoration than incremental backups provide.
A Practical Schedule
A common approach combines all three:
- Weekly: Full backup (Sunday night)
- Daily: Incremental backup (Monday through Saturday)
- Monthly: Full backup archived for long-term retention
This gives you daily granularity with manageable storage requirements.
What to Back Up
Databases
Your database is almost certainly the most critical asset on your server. For PostgreSQL:
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%Y%m%d).dumpFor MySQL/MariaDB:
mysqldump -u root -p --all-databases > /backups/all_dbs_$(date +%Y%m%d).sqlBack up databases separately from file system backups. Database dumps are portable, consistent, and can be restored independently.
Application Files
Your application code, uploaded media, configuration files, and any generated content. If you use version control for your code (and you should), the repository itself is a form of backup for application code. But media uploads, user-generated content, and configuration files need separate backup.
Server Configuration
Document and back up your server configuration:
- Nginx or Apache config files (
/etc/nginx/,/etc/apache2/) - Crontab entries (
crontab -l > /backups/crontab.txt) - Environment files and secrets
- Firewall rules
- SSL certificates and keys
- System service configurations
Losing your server configuration means hours of reconfiguration. Having a backup means you can rebuild a server in minutes.
Email Data
If you run a mail server, back up mail queues, user mailboxes, and DKIM keys. Losing DKIM private keys means regenerating keys and updating DNS, which temporarily impacts deliverability.
Storage: Where to Keep Backups
The most important rule of backups is the 3-2-1 rule:
- 3 copies of your data
- 2 different storage media
- 1 copy offsite
Local Storage
The fastest option for backup and restoration. Keep recent backups on the same server or a local network drive for quick recovery. But local backups alone are not sufficient because they are vulnerable to the same disasters as your primary data.
Remote Server
Copy backups to a separate server in a different data center. Use rsync over SSH for efficient incremental transfers:
rsync -avz --delete /backups/ user@remote-server:/backups/primary-server/Cloud Storage
Services like AWS S3, Backblaze B2, or Wasabi provide cheap, durable, offsite storage. Cloud storage is ideal for long-term retention and disaster recovery. Most support lifecycle policies that automatically move older backups to cheaper storage tiers.
Off-site Physical Storage
For the most critical data, consider encrypted physical media stored in a separate location. This protects against scenarios where both your primary and cloud infrastructure are compromised.
Automating Backups
Manual backups are forgotten backups. Automate everything using cron jobs or systemd timers.
A simple cron-based backup script:
#!/bin/bashchr(10)BACKUP_DIR="/backups/$(date +%Y%m%d)"chr(10)mkdir -p $BACKUP_DIRchr(10)chr(10)# Databasechr(10)pg_dump -U postgres -Fc mydb > $BACKUP_DIR/mydb.dumpchr(10)chr(10)# Fileschr(10)tar -czf $BACKUP_DIR/app_files.tar.gz /var/www/myapp/chr(10)chr(10)# Upload to remotechr(10)rsync -avz $BACKUP_DIR/ user@backup-server:/backups/chr(10)chr(10)# Clean up local backups older than 7 dayschr(10)find /backups/ -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;Schedule it with cron:
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1Testing Your Backups
An untested backup is not a backup. This is the most commonly ignored step. Schedule regular restoration tests:
- Monthly: Restore a database backup to a test server and verify data integrity.
- Quarterly: Perform a full server restoration to verify you can rebuild from backups.
- After any backup system change: Test immediately when you modify your backup process.
Verify not just that the backup file exists, but that it contains valid, complete, restorable data. A corrupted backup file gives you a false sense of security.
Retention Policies
How long should you keep backups? It depends on your business requirements, compliance obligations, and storage budget. A common retention policy:
- Daily backups: Keep for 7 to 14 days
- Weekly backups: Keep for 4 to 8 weeks
- Monthly backups: Keep for 6 to 12 months
- Annual backups: Keep for 3 to 7 years (if required by compliance)
Automate retention by deleting old backups as part of your backup script. Never rely on manual cleanup, as storage fills up faster than you expect.
Security Considerations
- Encrypt backups: Use GPG or AES-256 encryption for backups, especially offsite copies. Unencrypted backups are a data breach waiting to happen.
- Restrict access: Only authorized personnel should have access to backup files and the systems that create them.
- Secure transfer: Always transfer backups over encrypted channels (SSH, TLS).
- Separate credentials: Use dedicated backup user accounts with minimal permissions.
Your backup system is part of your security infrastructure. Treat it with the same rigor as your production systems.
