DEVOPS

Home › Glossary › Devops· 51 ·

Backup Strategy

/bak-up strat-uh-jee/noun

Filed underDevopsSecurity

In brief · quick answer

A backup strategy defines what data you protect, how often you back it up, where you store backups, and how you restore them. A good strategy follows the 3-2-1 rule: three copies, two different media, one offsite.

§ 1 Definition

A backup strategy is your plan for protecting data against loss from hardware failure, human error, security breaches, natural disasters, or software bugs. It covers what gets backed up (files, databases, configurations, emails), how frequently (hourly, daily, weekly), where backups are stored (local, cloud, offsite), how long they are retained, and most importantly, how restoration works. Many teams discover their backups don't work when they try to restore. A valid backup is one you have actually tested by restoring from it. The 3-2-1 rule (three total copies, two different formats, one offsite) remains the gold standard.

§ 2 What to Back Up

Website files: HTML, CSS, JavaScript, images, uploads, themes, plugins. Databases: MySQL, PostgreSQL, or any other data stores. Your database changes more frequently than your files and requires more frequent backups. Configuration files: Server configuration, environment variables, deployment scripts. Email if your hosting includes email services. Application state if your application has any persistent state that isn't in the database. Exclude temporary files, caches, and build artifacts that can be regenerated.

§ 3 Backup Frequency and Retention

Frequency depends on how much data you can afford to lose. If you run daily backups, your recovery point objective (RPO) is 24 hours. For an ecommerce site processing orders every minute, you need continuous or hourly backups. Retention determines how far back you can restore. Common patterns: daily backups for 30 days, weekly backups for 3 months, monthly backups for a year. Some regulated industries require longer retention.

§ 4 Testing Backups

An untested backup is not a backup. It is a hope. Restore your backup to a test environment at least monthly. Verify that files are intact, databases contain recent data, and the restored site functions correctly. Automated backup verification tools can check checksums and database integrity without manual restoration. Schedule a full restore drill quarterly, especially after major site changes.

§ 5 Note

Automatic backups are not enough if they stay on the same server as your production data. A server failure takes out both your site and your backups. Always have offsite backups (another provider, different cloud region, or cold storage).

§ 6 In code

```bash
# Automated database backup script
#!/bin/bash
DB_NAME="my_database"
DB_USER="db_user"
DB_PASS="db_password"
BACKUP_DIR="/backups/database"
DATE=$(date +%Y-%m-%d_%H%M%S)

# Dump database
export MYSQL_PWD="$DB_PASS"
mysqldump -u "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# Delete backups older than 30 days
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +30 -delete

# Verify backup integrity
gunzip -t "$BACKUP_DIR/db_$DATE.sql.gz"
echo "Backup completed: db_$DATE.sql.gz"
```

§ 7 Common questions

Q. How often should I test my backups?: A. Monthly verification at minimum. Quarterly full restoration drills. After any major infrastructure or application change. The worst time to discover a bad backup is during an actual emergency.
Q. Is cloud storage enough for offsite backups?: A. Yes, but use a different provider than your primary hosting. AWS backups stored on AWS are still in the same ecosystem. Use a different cloud provider or a dedicated backup service like Backblaze.

Key takeaways

A backup strategy defines what, how often, where, and how to restore. Test restores are mandatory.
Follow the 3-2-1 rule: three copies, two formats, one offsite.
Store backups offsite and on different infrastructure from production.
An untested backup is not a backup. Verify your restores monthly.

How Atomic Glue helps

All our WordPress Maintenance plans include automated daily backups with offsite storage and monthly restore testing. Get in touch to ensure your data is protected.

Get in touch

# Backup Strategy

Category: Devops (also: Security)

Author: Atomic Glue Editorial Team

## Definition

## What to Back Up

**Website files**: HTML, CSS, JavaScript, images, uploads, themes, plugins. **Databases**: MySQL, PostgreSQL, or any other data stores. Your database changes more frequently than your files and requires more frequent backups. **Configuration files**: Server configuration, environment variables, deployment scripts. **Email** if your hosting includes email services. **Application state** if your application has any persistent state that isn't in the database. Exclude temporary files, caches, and build artifacts that can be regenerated.

## Backup Frequency and Retention

## Testing Backups

## Note

## In code

## Common questions
Q: How often should I test my backups?
A: Monthly verification at minimum. Quarterly full restoration drills. After any major infrastructure or application change. The worst time to discover a bad backup is during an actual emergency.
Q: Is cloud storage enough for offsite backups?
A: Yes, but use a different provider than your primary hosting. AWS backups stored on AWS are still in the same ecosystem. Use a different cloud provider or a dedicated backup service like Backblaze.

## Key takeaways

A backup strategy defines what, how often, where, and how to restore. Test restores are mandatory.
Follow the 3-2-1 rule: three copies, two formats, one offsite.
Store backups offsite and on different infrastructure from production.
An untested backup is not a backup. Verify your restores monthly.

## Related entries

Last updated July 2026. Permalink: atomicglue.co/glossary/backup-strategy