RPO and RTO

RPO vs RTO

RPO (Recovery Point Objective):
  Maximum acceptable data loss
  Measured in time: hours, minutes, seconds
  Example: RPO = 1 hour → lose at most 1 hour of data

RTO (Recovery Time Objective):
  Maximum acceptable downtime
  Measured in time: hours, minutes, seconds
  Example: RTO = 4 hours → restore within 4 hours

Business Impact Analysis

Component     | RPO        | RTO        | Cost Impact
──────────────|────────────|────────────|─────────────
Orders        | 0 (no loss)| 1 hour     | Revenue loss
Product data  | 24 hours   | 4 hours    | Reduced sales
Customer data | 1 hour     | 2 hours    | Trust impact
Media files   | 24 hours   | 8 hours    | UX impact
Admin panel   | 24 hours   | 24 hours   | Operational

Recovery Objective Matrix

RPO/RTO     | Solution              | Cost
────────────|───────────────────────|────────
24h/24h     | Daily backup/restore  | $
1h/4h       | Hourly backup + warm  | $$
0/1h        | Replication + standby | $$$
0/0         | Active-active         | $$$$

Backup Frequency Mapping

RPO Target    | Backup Frequency   | Method
──────────────|────────────────────|─────────────────
24 hours      | Daily              | Full dump
1 hour         | Hourly             | Incremental
15 minutes     | Every 15 min       | Binary log
0 (real-time)  | Continuous         | Replication

MySQL Binary Log for Fine RPO

# Enable binary logging
# my.cnf
[mysqld]
log-bin=mysql-bin
binlog-format=ROW
expire-logs-days=7
max-binlog-size=100M

# Point-in-time recovery
mysqlbinlog --start-datetime="2026-01-01 10:00:00" \
            --stop-datetime="2026-01-01 11:00:00" \
            mysql-bin.000001 | mysql -u root -p

Backup Chain Strategy

Sunday: Full backup (base)
Monday: Incremental (changes since Sunday)
Tuesday: Incremental (changes since Monday)
...
Saturday: Differential (changes since Sunday)

RPO = time since last backup
Recovery = Full + Incrementals since

RTO Optimization

Factor                | Impact on RTO
──────────────────────|─────────────────
Backup size           | Larger = longer restore
Restore method        | Parallel = faster
Verification time     | Add to RTO
Application startup   | Cache warm-up
DNS propagation       | 60s - 5min

Fast Recovery Strategies

# 1. Parallel restore
mysql -u root -p magento < full_backup.sql &
mysql -u root -p magento < incremental_1.sql &
mysql -u root -p magento < incremental_2.sql &
wait

# 2. Use compressed backups with fast decompression
lz4 -d backup.sql.lz4 | mysql -u root -p magento

# 3. Pre-warmed standby database
# Keep replica ready for promotion

Recovery Time Breakdown

Phase              | Duration | Optimization
───────────────────|──────────|──────────────────────
Assessment         | 15 min   | Automated detection
Decision           | 5 min    | Pre-approved runbook
Infrastructure     | 10 min   | Infrastructure as code
Database restore   | 60 min   | Parallel restore
Application setup  | 15 min   | Pre-built images
Cache warm-up      | 30 min   | Cache pre-warming
Verification       | 15 min   | Automated tests
───────────────────|──────────|
Total              | ~2.5 hrs | Optimized from 8 hrs

Testing Framework

#!/bin/bash
# recovery_test.sh

# Record start time
START=$(date +%s)

# 1. Restore database
echo "Restoring database..."
zcat /backup/latest.sql.gz | mysql -u root -p magento_test

# 2. Restore files
echo "Restoring files..."
tar -xzf /backup/latest_files.tar.gz -C /var/www/magento_test/

# 3. Verify data
echo "Verifying data..."
ORDERS=$(mysql -u root -p -N -e \
  "SELECT COUNT(*) FROM magento_test.sales_order WHERE created_at > DATE_SUB(NOW(), INTERVAL 24 HOUR);")
echo "Orders in last 24h: $ORDERS"

# 4. Record end time
END=$(date +%s)
DURATION=$((END - START))
echo "Recovery time: ${DURATION} seconds"

# 5. Compare against RTO
if [ $DURATION -gt 14400 ]; then  # 4 hours
    echo "FAIL: Exceeds 4-hour RTO"
else
    echo "PASS: Within RTO target"
fi

Test Results Documentation

Test Date: 2026-01-01
RTO Target: 4 hours
RPO Target: 1 hour

Result: PASS
Recovery Time: 2.5 hours
Data Loss: 45 minutes

Issues Found:
- Cache warm-up took 30 min
- DNS propagation 5 min

Recommendations:
- Implement cache pre-warming
- Reduce DNS TTL