Data Protection by the 3-2-1 Rule: Automation and Restoration Guarantee

Once, a client lost 3 months of data due to a RAID array failure. The backup was stored on the same physical server — both copies were lost. Recovery was only possible from a six-month-old copy on a developer's laptop. According to statistics, 30% of companies do not check backups, and 50% store them on the same hosting as the main site. Data loss costs businesses an average of 2 million rubles. It's a direct path to irreparable losses that amount to tens and hundreds of thousands of rubles in downtime. We have been doing backups for 10 years and have serviced over 200 projects.

Unlike many companies, we don't just set up scripts — we design a backup architecture that withstands hardware failure, human error, and even targeted attacks. Our engineers are certified in AWS and PostgreSQL, which ensures correct configuration of S3 Lifecycle and pg_dump with atomicity and consistency checks.

The 3-2-1 rule is the gold standard for backup that eliminates such risks. Source: Wikipedia. We configure automatic backups that comply with this rule, using S3 storage and smart rotation. The result is a guaranteed ability to roll back to any point in the last 90 days. Data is safe even in case of hardware failure.

Why Backup Is Not an Option but a Necessity?

Backup on the same server is false security. If RAID fails, both copies are lost. We move backups to S3 and configure Lifecycle — now data is duplicated in another region. Storage cost for 10 GB on S3 is less than 5 rubles per month, while data loss can cost millions. It's an investment that pays off at the first accident. For example, monthly cost for storing 50 GB of backups is about 25 rubles. And data recovery after a failure can cost hundreds of thousands of rubles. The savings are obvious. Custom scripts are 10x more flexible than ready plugins, especially for complex rotation policies.

Which Data We Back Up First

The database is the main source of changes. For WordPress with 10k+ daily visitors, we set up DB backups every 6 hours. Upload files (uploads/, storage/) — once a day. Configuration files (.env, nginx.conf) — after every change. Code is in Git, but a backup copy of the repository on a separate server wouldn't hurt.

Setting Up Automatic Backup in 2–4 Hours

We use bash, pg_dump, rsync, and S3. Below is a typical scenario.

Automatic DB Backup to S3

#!/bin/bash # /opt/scripts/backup-db.sh set -euo pipefail DATE=$(date +%Y%m%d_%H%M%S) DB_NAME="mysite_prod" BACKUP_DIR="/tmp/backups" S3_BUCKET="s3://my-backups/database" mkdir -p "$BACKUP_DIR" # PostgreSQL pg_dump -U postgres -d "$DB_NAME" -F custom \ | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz" # Upload to S3 aws s3 cp "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz" \ "${S3_BUCKET}/${DB_NAME}_${DATE}.dump.gz" \ --storage-class STANDARD_IA # Clean local rm "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz" # Remove old (30 days) aws s3 ls "${S3_BUCKET}/" \ | awk '{print $4}' \ | while read key; do date=$(echo "$key" | grep -oP '\d{8}') if [[ $(date -d "$date" +%s) -lt $(date -d "30 days ago" +%s) ]]; then aws s3 rm "${S3_BUCKET}/${key}" fi done echo "Backup completed: ${DB_NAME}_${DATE}.dump.gz" 

Crontab: every 6 hours

0 */6 * * * /opt/scripts/backup-db.sh >> /var/log/backup.log 2>&1 

S3 Lifecycle Policies for Automatic Rotation

{ "Rules": [{ "ID": "BackupRetention", "Filter": { "Prefix": "database/" }, "Status": "Enabled", "Transitions": [ { "Days": 7, "StorageClass": "STANDARD_IA" }, { "Days": 30, "StorageClass": "GLACIER" } ], "Expiration": { "Days": 90 } }] } 

File Backup via rsync + S3

# Syn uploads/ to S3 aws s3 sync /var/www/mysite/storage/app/public/ \ s3://my-backups/files/ \ --storage-class STANDARD_IA \ --delete # Without --delete (safer, but grows) aws s3 sync /var/www/mysite/uploads/ s3://my-backups/uploads/ 

Backup Setup Stages

1. Data volume assessment: determine DB size, files, and growth rate.
2. Strategy selection: backup frequency, retention depth, S3 storage classes.
3. Script writing: pg_dump, rsync, aws cli.
4. Crontab configuration: for DB — every 6 hours, for files — once a day.
5. S3 Lifecycle configuration: automatic rotation and deletion of old copies.
6. Test recovery: simulate a failure and verify restore.

Backup Verification Procedure

A backup without recovery verification is an illusion of security. Run a test recovery monthly in an isolated environment:

# Monthly restore test aws s3 cp s3://my-backups/database/latest.dump.gz /tmp/test-restore.dump.gz createdb mysite_restore_test gunzip < /tmp/test-restore.dump.gz | pg_restore -d mysite_restore_test psql -d mysite_restore_test -c "SELECT COUNT(*) FROM users;" dropdb mysite_restore_test 

If recovery is successful — the backup works. On error, an alert is sent to Telegram. This approach guarantees that data will be available at a critical moment. We perform checksum verification and I/O throughput measurement to ensure WORM compliance.

Backup Service Composition

• Development of backup scripts (DB, files, configs)
• Crontab and S3 Lifecycle configuration
• Test recovery in an isolated environment
• Monitoring with daily healthcheck and alerts
• Documentation with full scheme and instructions
• Delivery of all scripts, access to S3 bucket, and a 1-month post-deployment support period
• Team training session on manual recovery procedures

Before project delivery, we verify that crontab is configured for DB and files, S3 Lifecycle policy is created, test recovery was performed, monitoring with alerts is set up, and documentation is handed over to the client.

Custom Script or Ready Plugin: What to Choose?

Custom script is justified for custom scenarios: rotation, multiple DBs, monitoring integration. For simple sites, ready plugins are faster, but we recommend a hybrid approach.

Recommended Retention Policy

Our engineers are certified in AWS and PostgreSQL. We guarantee restoration from backup. Order a consultation — we will select the optimal strategy for your project. Want to secure your project? Contact us — we will assess your infrastructure in one day and offer the best strategy.