DDevArchive
Đăng nhập

Backup & Disaster Recovery: khi mọi thứ sụp đổ

Database bay. Server bị hack. Deploy lỗi xoá sạch data. Chuyện này XẢY RA THẬT. Câu hỏi không phải "có xảy ra không?" mà "khi xảy ra, bạn recovery trong bao lâu?". Bài này dạy backup tự động, test restore, và disaster playbook.

Backup: 3-2-1 rule

3 bản copy, trên 2 loại storage khác nhau, 1 bản off-site. Ví dụ: database + S3 bucket + backup trên cloud khác.

// File: backup.sh
#!/bin/bash
# Backup PostgreSQL hàng ngày → S3

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="backup_${TIMESTAMP}.sql.gz"

# Dump database + nén
pg_dump $DATABASE_URL | gzip > /tmp/$BACKUP_FILE

# Upload lên S3/R2
aws s3 cp /tmp/$BACKUP_FILE s3://my-backups/$BACKUP_FILE

# Xoá backup local
rm /tmp/$BACKUP_FILE

# Xoá backup cũ hơn 30 ngày
aws s3 ls s3://my-backups/ | awk '{print $4}' | sort | head -n -30 | \
  xargs -I {} aws s3 rm s3://my-backups/{}

echo "Backup completed: $BACKUP_FILE"

Test restore: backup không có test = không có backup

Nhiều người backup hàng ngày nhưng chưa bao giờ thử restore. Đến khi cần mới phát hiện backup bị lỗi. Mỗi tháng, thử restore từ backup vào database test — đảm bảo data đầy đủ và đúng.

Disaster Recovery Playbook

Tình huốngRTO (Recovery Time)Hành động
Database corrupt< 1 giờRestore từ backup gần nhất
Server bị hack< 2 giờTắt server, rotate credentials, restore from backup, audit logs
Deploy lỗi< 5 phútRollback deploy (git revert + redeploy)
Cloud region down< 4 giờFailover sang region khác (nếu có multi-region)
Ransomware< 24 giờWipe, restore from OFFLINE backup, rotate tất cả credentials
Câu chuyện thật

GitLab (2017) mất 300GB data production vì admin chạy rm -rf trên sai server. Họ thử 5 phương pháp backup — 4 cái đều hỏng. Chỉ 1 bản snapshot 6 giờ trước cứu được. Test backup THƯỜNG XUYÊN.

❓ Quy tắc backup 3-2-1 là gì?

  • Setup automated daily backup cho database
  • Test restore từ backup mỗi tháng
  • Viết disaster recovery playbook
  • Lưu backup off-site (khác cloud provider)