Linux Backup Và Restore Drill: Thiết Kế Sao Lưu Có Thể Khôi Phục Cho Production

Linux backup restore drill là phần thường bị bỏ quên trong vận hành Linux production. Rất nhiều hệ thống có cron sao lưu hằng ngày, có file nén trong thư mục backup, có log “completed”, nhưng đến lúc cần khôi phục thì mới phát hiện thiếu database dump, quyền file sai, không có khóa mã hóa, hoặc bản backup chưa từng được kiểm tra.

Nguyên tắc thực tế rất đơn giản: backup chưa restore thử thì chưa được xem là backup. Bài viết này hướng dẫn cách thiết kế chiến lược sao lưu Linux có thể khôi phục, xây dựng restore drill định kỳ, kiểm tra dữ liệu sau khôi phục và tạo checklist nghiệm thu phù hợp cho sysadmin quản trị server production.

1. Xác định mục tiêu: RPO, RTO và phạm vi dữ liệu

Trước khi chọn công cụ, hãy trả lời ba câu hỏi vận hành:

RPO: chấp nhận mất tối đa bao nhiêu dữ liệu? 5 phút, 1 giờ hay 24 giờ?
RTO: cần khôi phục dịch vụ trong bao lâu?
Phạm vi: cần backup file cấu hình, dữ liệu ứng dụng, database, object storage, chứng chỉ TLS, cron, systemd unit hay toàn bộ VM?

Ví dụ với một web server WordPress hoặc ứng dụng PHP nhỏ, phạm vi tối thiểu thường gồm: /etc/nginx, /etc/php, /var/www, database dump, crontab, file cấu hình systemd custom, chứng chỉ TLS nếu không thể cấp lại nhanh, và tài liệu mô tả cách dựng lại server.

2. Chiến lược 3-2-1 cho Linux production

Mô hình 3-2-1 vẫn là nền tảng tốt:

3 bản sao: dữ liệu chính và ít nhất hai bản backup.
2 loại lưu trữ: ví dụ local disk + S3 compatible storage.
1 bản offsite: nằm ngoài server hoặc ngoài datacenter chính.

Đừng để backup chỉ nằm trên cùng ổ đĩa với production. Nếu disk hỏng, ransomware mã hóa, hoặc thao tác nhầm rm, bản backup local có thể đi cùng hệ thống chính.

3. Ví dụ backup bằng restic

restic phù hợp vì hỗ trợ mã hóa, deduplication, nhiều backend lưu trữ và kiểm tra snapshot khá tiện. Cài đặt trên Ubuntu/Debian:

sudo apt update
sudo apt install -y restic

Khởi tạo repository backup, ví dụ dùng thư mục lab local trước khi chuyển sang S3:

export RESTIC_REPOSITORY=/backup/restic-repo
export RESTIC_PASSWORD_FILE=/root/.config/restic/password
sudo mkdir -p /backup/restic-repo /root/.config/restic
sudo chmod 700 /root/.config/restic
sudo sh -c 'openssl rand -base64 32 > /root/.config/restic/password'
restic init

Output mẫu:

created restic repository b4d9c6f7 at /backup/restic-repo
Please note that knowledge of your password is required to access the repository.

Chạy backup các thư mục quan trọng:

restic backup /etc /var/www /home --exclude='*.cache' --exclude='/home/*/.cache'

Với database, nên dump nhất quán trước khi backup file dump:

sudo mkdir -p /var/backups/mysql
mysqldump --single-transaction --routines --triggers --all-databases | gzip > /var/backups/mysql/all-$(date +%F-%H%M).sql.gz
restic backup /var/backups/mysql

4. Chính sách retention và kiểm tra snapshot

Backup không có retention sẽ phình dung lượng. Backup retention quá ngắn lại không chống được lỗi âm thầm kéo dài nhiều ngày. Một chính sách phổ biến:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Kiểm tra danh sách snapshot:

restic snapshots
restic stats

Định kỳ kiểm tra repository:

restic check
# Kiểm tra sâu hơn, tốn thời gian hơn
restic check --read-data-subset=5%

restic check không thay thế restore drill, nhưng giúp phát hiện metadata hỏng, pack thiếu hoặc vấn đề đọc dữ liệu từ backend.

5. Restore drill: bài kiểm tra quan trọng nhất

Restore drill là buổi diễn tập khôi phục. Không chạy trên server production đang phục vụ người dùng. Hãy dùng VM lab, staging hoặc một thư mục tạm để kiểm tra.

5.1. Khôi phục vào thư mục tạm

mkdir -p /tmp/restore-drill
restic restore latest --target /tmp/restore-drill

Kiểm tra file quan trọng:

ls -lah /tmp/restore-drill/etc/nginx
ls -lah /tmp/restore-drill/var/www
find /tmp/restore-drill/var/backups/mysql -type f -name '*.sql.gz' | tail

5.2. Kiểm tra checksum và quyền file

stat /tmp/restore-drill/var/www/html
find /tmp/restore-drill/var/www -type f -name 'wp-config.php' -exec ls -l {} \;
sha256sum /tmp/restore-drill/etc/nginx/nginx.conf

Lỗi thường gặp là file restore ra đúng nội dung nhưng sai owner/permission khiến ứng dụng không đọc được.

5.3. Restore database vào môi trường lab

gunzip -c /tmp/restore-drill/var/backups/mysql/all-2026-06-12-1900.sql.gz | mysql -u root -p

Sau đó kiểm tra database, số bảng và một vài record quan trọng:

mysql -u root -p -e "SHOW DATABASES;"
mysql -u root -p -e "SELECT COUNT(*) FROM wordpress.wp_posts;"

6. Tự động hóa backup bằng systemd timer

Thay vì chỉ dùng cron, systemd timer giúp xem trạng thái rõ hơn. Tạo service:

sudo tee /etc/systemd/system/restic-backup.service >/dev/null <<'EOF'
[Unit]
Description=Restic backup for production data

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=/backup/restic-repo
Environment=RESTIC_PASSWORD_FILE=/root/.config/restic/password
ExecStart=/usr/local/sbin/run-restic-backup.sh
EOF

Script backup:

sudo tee /usr/local/sbin/run-restic-backup.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
mkdir -p /var/backups/mysql
mysqldump --single-transaction --routines --triggers --all-databases | gzip > /var/backups/mysql/all-$(date +%F-%H%M).sql.gz
restic backup /etc /var/www /home /var/backups/mysql
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check
EOF
sudo chmod 700 /usr/local/sbin/run-restic-backup.sh

Tạo timer chạy 02:30 hằng ngày:

sudo tee /etc/systemd/system/restic-backup.timer >/dev/null <<'EOF'
[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

7. Monitoring và cảnh báo backup

Backup thất bại âm thầm là rủi ro lớn. Tối thiểu hãy theo dõi:

Backup job gần nhất thành công lúc nào.
Dung lượng repository tăng/giảm bất thường.
Số snapshot mới trong 24 giờ.
Kết quả restic check.
Restore drill gần nhất đã chạy khi nào và kết quả ra sao.

Có thể ghi một file trạng thái đơn giản sau mỗi lần chạy:

date -Is > /var/lib/backup-last-success.txt

Rồi dùng monitoring đọc file này và cảnh báo nếu quá 26 giờ không cập nhật.

8. Lỗi thường gặp khi làm backup Linux

8.1. Chỉ backup file, quên database

Với WordPress, Laravel, GitLab hoặc hầu hết ứng dụng web, database là phần quan trọng nhất. Copy thư mục web mà không dump database thường không đủ để khôi phục.

8.2. Không lưu khóa mã hóa

Nếu dùng restic hoặc backup được encrypt, mất password đồng nghĩa mất backup. Hãy lưu khóa ở password manager hoặc quy trình break-glass an toàn.

8.3. Không kiểm tra restore sau nâng cấp

Thay đổi phiên bản database, plugin, schema hoặc đường dẫn lưu trữ có thể làm quy trình restore cũ không còn đúng.

8.4. Backup kéo sập production

Backup I/O quá mạnh có thể làm latency tăng. Hãy dùng nice/ionice, snapshot, hoặc chạy vào khung giờ thấp điểm:

ionice -c2 -n7 nice -n 10 restic backup /var/www

9. Checklist nghiệm thu

Đã xác định RPO/RTO cho từng service.
Backup có ít nhất một bản offsite.
Database được dump nhất quán hoặc backup bằng cơ chế native.
Backup được mã hóa và khóa được lưu an toàn.
Có retention rõ ràng, không để repository tăng vô hạn.
Có monitoring khi backup thất bại hoặc không chạy.
Restore drill chạy định kỳ trên môi trường lab/staging.
Đã kiểm tra quyền file, checksum, database và khả năng boot service.
Có tài liệu từng bước để người trực có thể khôi phục khi incident xảy ra.

10. Bài tập lab cuối bài

Dựng một VM Ubuntu nhỏ, cài Nginx và MariaDB, tạo vài file demo trong /var/www. Sau đó:

Cài restic và tạo repository local.
Backup /etc, /var/www và database dump.
Xóa hoặc đổi tên một file demo.
Restore snapshot mới nhất vào /tmp/restore-drill.
So sánh nội dung file và restore database vào database lab.
Viết lại checklist thao tác trong một runbook ngắn.

Khi lab chạy ổn, hãy lặp lại với S3 compatible storage hoặc một server offsite để mô phỏng tình huống server chính mất hoàn toàn.

Kết luận

Một hệ thống backup tốt không được đo bằng số file nén tạo ra mỗi ngày, mà bằng khả năng khôi phục dịch vụ đúng RPO/RTO khi có sự cố. Với Linux production, hãy kết hợp chiến lược 3-2-1, công cụ có mã hóa như restic, monitoring rõ ràng và restore drill định kỳ. Khi bạn đã restore thử thành công, backup mới thật sự trở thành một phần đáng tin cậy của vận hành.