Backup 'tưởng có mà không có': Khi thảm họa xảy ra mới biết backup hỏng

Backup không hoạt động là tình huống tồi tệ hơn cả không có backup — vì bạn tin rằng mình an toàn, nhưng thực tế không phải vậy. Theo báo cáo của Unitrends (2025), 34% doanh nghiệp đã gặp lỗi khi cố gắng restore từ backup. Và 58% chỉ phát hiện backup hỏng khi thực sự cần restore — tức là đúng lúc thảm họa xảy ra.

Bài viết này chia sẻ câu chuyện thực tế và 5 lý do phổ biến nhất khiến backup “tưởng có mà không có”.

Câu chuyện: Ransomware tấn công, backup hỏng

Timeline sự cố

Thứ 2, 7:30 AM:

Nhân viên kế toán công ty T. (ngành xây dựng, TP.HCM) mở máy tính và thấy tất cả file Excel, Word trên desktop có đuôi .locked. Một file README.txt hiển thị:

“Your files have been encrypted. Pay 2 BTC (~1.2 tỉ VND) to decrypt.”

7:45 AM — Kiểm tra server:

IT manager SSH vào server → thấy toàn bộ database và website files cũng bị mã hóa. Ransomware đã lan từ máy nhân viên lên server qua shared folder.

8:00 AM — Tìm backup:

IT manager mở thư mục /opt/backup/ trên server → Tất cả file backup cũng bị mã hóa (vì backup nằm trên cùng server).

8:15 AM — Kiểm tra backup trên Google Drive:

Mở Google Drive → thấy backup files. Nhưng khi download và thử restore:

• Database backup file: 0 bytes (file rỗng)
• Website files backup: corrupt, không giải nén được

8:30 AM — Nhận ra sự thật:

Backup script đã chạy hàng ngày trong 6 tháng qua — nhưng đã bị lỗi từ tháng thứ 2. Không ai kiểm tra vì “backup tự động rồi mà”.

Thiệt hại

Chi phí nếu backup hoạt động đúng: ~5 triệu VND (thuê chuyên gia restore + 4 giờ downtime).

5 lý do backup “tưởng có mà không có”

Lý do 1: Backup script lỗi im lặng (Silent failure)

Vấn đề:

# Script backup — lỗi nhưng không ai biết
mysqldump -u root -p'wrong_password' database > backup.sql
# Exit code = 1 (lỗi), nhưng tạo file backup.sql rỗng (0 bytes)
# Cron job vẫn chạy "thành công" mỗi ngày
# 6 tháng sau mới phát hiện tất cả backup đều rỗng

Nguyên nhân phổ biến:

• Password MySQL thay đổi nhưng quên update backup script
• Disk hết dung lượng → ghi file rỗng
• Permission thay đổi → script không đọc được database
• MySQL service restart → script chạy lúc MySQL đang khởi động lại

Cách phòng tránh:

# Kiểm tra exit code
mysqldump ... > backup.sql
if [ $? -ne 0 ]; then
    echo "BACKUP FAILED!" | send_telegram_alert
    exit 1
fi

# Kiểm tra file size
FILESIZE=$(stat -c%s backup.sql.gz)
if [ $FILESIZE -lt 1000 ]; then  # < 1KB = có vấn đề
    echo "BACKUP FILE TOO SMALL: ${FILESIZE} bytes" | send_telegram_alert
    exit 1
fi

Lý do 2: Backup nằm trên cùng server

Vấn đề: Backup lưu trong /opt/backup/ trên cùng VPS production. Khi:

• Server bị hack → hacker xóa cả backup
• Ransomware → mã hóa cả backup
• Ổ cứng hỏng → mất cả data và backup
• Nhà cung cấp VPS terminate server → mất tất cả

Thống kê: 71% ransomware attack nhắm đến cả backup files trên cùng hệ thống.

Cách phòng tránh: Luôn có offsite backup — nơi mà ransomware không thể truy cập:

# Sync backup lên cloud (khác server)
rclone sync /opt/backup/ gdrive:server-backup/

# Hoặc dùng Backblaze B2 với Object Lock (immutable)
rclone sync /opt/backup/ b2:backup-bucket/ --b2-hard-delete=false

Lý do 3: Không test restore

Vấn đề:

Backup file tồn tại, kích thước đúng, nhưng:

• File bị corrupt (bad sectors trên ổ cứng)
• Charset không khớp (UTF-8 vs Latin-1) → tiếng Việt thành ký tự lạ
• Schema thay đổi nhưng backup script dùng version cũ
• Backup thiếu stored procedures, triggers, views

Thống kê: 30% backup files có ít nhất 1 vấn đề khi restore — nhưng chỉ phát hiện khi thực sự restore.

Cách phòng tránh:

# Test restore hàng tuần (tự động)
# 1. Tạo temp database
mysql -e "CREATE DATABASE backup_test;"

# 2. Restore backup
gunzip -c latest_backup.sql.gz | mysql backup_test

# 3. Verify record count
RECORDS=$(mysql -N -e "SELECT COUNT(*) FROM backup_test.orders;")
if [ $RECORDS -lt 1000 ]; then
    echo "RESTORE TEST FAILED: Only $RECORDS records (expected > 1000)"
fi

# 4. Cleanup
mysql -e "DROP DATABASE backup_test;"

Lý do 4: Retention quá ngắn

Vấn đề: Backup giữ 7 ngày. Ransomware xâm nhập và nằm im 10 ngày trước khi kích hoạt. Khi phát hiện, tất cả 7 bản backup đều đã chứa ransomware.

Kịch bản khác: Nhân viên xóa nhầm dữ liệu quan trọng nhưng sau 2 tuần mới phát hiện. Backup chỉ giữ 7 ngày → dữ liệu đã bị xóa khỏi tất cả backup.

Cách phòng tránh:

Lý do 5: Không backup đủ thành phần

Vấn đề: Chỉ backup database, quên backup:

Checklist backup đầy đủ:

Checklist kiểm tra backup hàng tháng

Phòng chống ransomware cho backup

Immutable backups

Backup không thể bị sửa hoặc xóa trong thời gian retention:

# AWS S3 Object Lock
aws s3api put-object-lock-configuration \
    --bucket backup-bucket \
    --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Air-gapped backups

Backup offline — không kết nối internet, ransomware không thể truy cập:

• Ổ cứng USB rời, cắm backup rồi rút
• Tape backup (vẫn được dùng trong enterprise)
• Cloud backup với credentials tách biệt (không lưu trên server)

Backup account separation

Không dùng cùng credentials cho production và backup:

# Sai: Dùng root access cho cả production và backup
# Nếu server bị hack, hacker có quyền xóa backup trên cloud

# Đúng: Tạo backup-only account trên cloud
# Account này chỉ có quyền WRITE (không DELETE)
# Ransomware không thể xóa backup cũ

FAQ — Câu hỏi thường gặp

Backup bao nhiêu lần/ngày là đủ?

Phụ thuộc vào RPO (Recovery Point Objective) — bạn chấp nhận mất bao nhiêu dữ liệu? Nếu chấp nhận mất 24 giờ → backup 1 lần/ngày. Nếu chấp nhận mất 1 giờ → backup mỗi giờ. E-commerce lớn: backup database mỗi giờ, files mỗi ngày.

Chi phí immutable backup bao nhiêu?

AWS S3 Object Lock: giá S3 thông thường + ~10% cho versioning. Backblaze B2 với Object Lock: ~130 VND/GB/tháng. Cho 10GB backup: ~1.300 VND/tháng. Rẻ hơn nhiều so với thiệt hại ransomware.

Backup mã hóa (encrypted) có cần thiết không?

Có, đặc biệt cho backup offsite. Backup không mã hóa trên cloud = ai có access vào cloud storage đọc được toàn bộ dữ liệu khách hàng. Dùng rclone với --crypt hoặc encrypt trước khi upload: gpg --symmetric backup.sql.gz.

Kết luận

“Backup tưởng có mà không có” là thảm họa tồi tệ hơn không có backup — vì nó tạo cảm giác an toàn giả. 5 lý do trong bài viết này chiếm 90% nguyên nhân backup thất bại. Khắc phục bằng: test restore hàng tháng, offsite backup, và monitoring backup status.

Nếu bạn cần audit backup hiện tại hoặc setup hệ thống backup chuyên nghiệp cho doanh nghiệp, hãy liên hệ Trinh Digital.