Linux Backup Restore Drill: Runbook Kiểm Tra Khả Năng Khôi Phục Trước Khi Sự Cố Xảy Ra

Linux backup restore drill là bài kiểm tra định kỳ để chứng minh rằng dữ liệu có thể khôi phục được, không chỉ “đã có backup”. Trong production, backup chưa từng restore thành công gần như chưa được xem là backup. Rất nhiều đội IT chỉ phát hiện file backup bị thiếu, sai quyền, thiếu database dump hoặc không có khóa giải mã vào đúng ngày hệ thống hỏng.

Bài viết này là runbook thực chiến cho sysadmin: từ thiết kế mục tiêu RPO/RTO, chuẩn bị môi trường lab, chạy backup bằng rsync hoặc restic, khôi phục thử, kiểm tra checksum, kiểm tra quyền file, xác minh dịch vụ sau restore, đến checklist nghiệm thu và bài tập lab cuối bài.

1. Khái niệm cần chốt trước khi làm backup

RPO và RTO

• RPO (Recovery Point Objective): doanh nghiệp chấp nhận mất tối đa bao nhiêu dữ liệu. Ví dụ RPO 15 phút nghĩa là backup/replication phải đủ gần để mất tối đa 15 phút dữ liệu.
• RTO (Recovery Time Objective): thời gian tối đa để khôi phục dịch vụ. Ví dụ RTO 2 giờ nghĩa là từ lúc sự cố được xác nhận đến lúc dịch vụ chạy lại không quá 2 giờ.

Nếu không có RPO/RTO, backup sẽ dễ bị thiết kế theo cảm tính: lúc thì quá đắt, lúc thì không đủ an toàn.

Backup khác snapshot như thế nào?

Snapshot rất hữu ích để rollback nhanh, nhưng không thay thế backup độc lập. Snapshot cùng nền tảng với máy chủ có thể mất theo tài khoản cloud, storage pool hoặc ransomware. Backup tốt nên có bản sao tách quyền, tách vùng lưu trữ và có cơ chế immutable hoặc retention rõ ràng.

2. Mô hình production/lab mẫu

Giả sử có một máy Linux chạy ứng dụng web nhỏ:

• /etc/nginx/: cấu hình web server.
• /var/www/app/: mã nguồn hoặc artifact deploy.
• /var/lib/app/uploads/: dữ liệu người dùng upload.
• postgresql: database chính.
• /etc/systemd/system/app.service: unit systemd.

Mục tiêu: mỗi ngày có backup đầy đủ, mỗi giờ có backup incremental cho uploads/database dump, và mỗi tháng chạy restore drill vào máy lab cô lập.

3. Inventory: liệt kê thứ thật sự cần backup

Trước khi viết script, hãy tạo file inventory. Ví dụ:

cat > backup-inventory.txt <<'EOF'
/etc/nginx/
/etc/systemd/system/app.service
/var/www/app/
/var/lib/app/uploads/
/opt/app/.env.example
Database: PostgreSQL database appdb, dump bằng pg_dump
Secrets: lưu trong vault, KHÔNG backup plaintext vào repository backup
EOF

Điểm quan trọng: secret production không nên được ném nguyên văn vào backup không mã hóa. Nếu backup chứa secret, repository backup phải được mã hóa và quyền truy cập phải chặt như quyền production.

4. Backup đơn giản bằng rsync

rsync phù hợp cho file backup nội bộ, dễ hiểu và dễ kiểm tra. Ví dụ đồng bộ thư mục quan trọng sang ổ backup đã mount tại /backup/server01:

sudo mkdir -p /backup/server01/{etc-nginx,app,uploads}
sudo rsync -aHAX --delete /etc/nginx/ /backup/server01/etc-nginx/
sudo rsync -aHAX --delete /var/www/app/ /backup/server01/app/
sudo rsync -aHAX --delete /var/lib/app/uploads/ /backup/server01/uploads/

Giải thích:

• -a: giữ quyền, owner, timestamp cơ bản.
• -HAX: giữ hardlink, ACL và extended attributes nếu filesystem hỗ trợ.
• --delete: xóa file ở đích nếu nguồn đã xóa. Dùng cẩn thận; nên có snapshot/retention ở tầng đích.

Output mẫu khi chạy có thay đổi:

sent 42.18M bytes  received 1.20K bytes  28.12M bytes/sec
total size is 420.55M  speedup is 9.97

5. Backup có mã hóa và retention bằng restic

restic phù hợp hơn cho backup dài hạn vì có mã hóa, deduplication, snapshot và retention. Cài đặt trên Ubuntu/Debian:

sudo apt update
sudo apt install -y restic

Khởi tạo repository local để lab:

export RESTIC_REPOSITORY=/backup/restic-server01
export RESTIC_PASSWORD_FILE=/root/.config/restic/server01.pass
sudo mkdir -p /root/.config/restic /backup/restic-server01
sudo chmod 700 /root/.config/restic
openssl rand -base64 32 | sudo tee $RESTIC_PASSWORD_FILE >/dev/null
sudo chmod 600 $RESTIC_PASSWORD_FILE
sudo -E restic init

Output mẫu:

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

Chạy backup:

sudo -E restic backup \
  /etc/nginx \
  /etc/systemd/system/app.service \
  /var/www/app \
  /var/lib/app/uploads \
  --tag server01 --tag production

6. Database backup: đừng quên tính nhất quán

Với PostgreSQL, không nên chỉ copy thư mục data khi database đang chạy nếu bạn không hiểu cơ chế snapshot nhất quán. Cách dễ kiểm soát cho ứng dụng vừa và nhỏ là dump:

sudo -u postgres pg_dump -Fc appdb > /var/backups/appdb-$(date +%F-%H%M).dump
sudo -E restic backup /var/backups/appdb-*.dump --tag postgres --tag appdb

Kiểm tra dump có đọc được metadata không:

pg_restore --list /var/backups/appdb-2026-07-05-1900.dump | head

Output mẫu:

;
; Archive created at 2026-07-05 19:00:01 +07
;     dbname: appdb
;     TOC Entries: 214

7. Restore drill: quy trình kiểm tra khôi phục

Restore drill nên chạy trên máy lab hoặc VM cô lập, không ghi đè production. Các bước chuẩn:

1. Tạo VM lab cùng OS major version với production.
2. Cài package cần thiết: nginx, database client/server, runtime ứng dụng.
3. Restore file từ backup.
4. Restore database vào database lab.
5. Kiểm tra quyền file, systemd unit, cấu hình nginx.
6. Chạy smoke test HTTP/API.
7. Ghi lại thời gian restore để so với RTO.

Restore bằng restic

export RESTIC_REPOSITORY=/backup/restic-server01
export RESTIC_PASSWORD_FILE=/root/.config/restic/server01.pass
sudo -E restic snapshots
sudo -E restic restore latest --target /restore-drill/server01

Output mẫu:

repository f3b8c1d2 opened successfully
restoring  to /restore-drill/server01

Sau đó copy vào đúng vị trí trên VM lab:

sudo rsync -aHAX /restore-drill/server01/etc/nginx/ /etc/nginx/
sudo rsync -aHAX /restore-drill/server01/var/www/app/ /var/www/app/
sudo rsync -aHAX /restore-drill/server01/var/lib/app/uploads/ /var/lib/app/uploads/

Restore database PostgreSQL

sudo -u postgres createdb appdb_restore
sudo -u postgres pg_restore -d appdb_restore /restore-drill/server01/var/backups/appdb-latest.dump

Nếu gặp lỗi role không tồn tại, tạo role lab tương ứng hoặc restore với tùy chọn phù hợp:

sudo -u postgres pg_restore --no-owner --role=appuser_lab -d appdb_restore appdb-latest.dump

8. Kiểm tra sau restore

Đừng dừng ở “lệnh restore không lỗi”. Cần kiểm tra dịch vụ thật sự chạy:

sudo nginx -t
sudo systemctl daemon-reload
sudo systemctl restart app nginx
systemctl --no-pager --failed
curl -I http://127.0.0.1/
curl -s http://127.0.0.1/healthz

Output mong muốn:

nginx: configuration file /etc/nginx/nginx.conf test is successful
HTTP/1.1 200 OK
{"status":"ok","database":"ok"}

Nếu ứng dụng có dữ liệu upload, chọn ngẫu nhiên vài file và kiểm tra checksum:

find /var/lib/app/uploads -type f | shuf -n 10 | xargs -r sha256sum

9. Lỗi thường gặp khi backup/restore Linux

• Backup thiếu file ẩn: script dùng wildcard sai như /var/www/app/* và bỏ sót .env.example hoặc thư mục .well-known.
• Sai owner sau restore: file thuộc root thay vì user chạy ứng dụng, gây lỗi permission denied.
• Không backup systemd unit: restore xong có code nhưng không biết service chạy bằng command nào.
• Database dump không nhất quán: copy file database nóng mà không có snapshot consistent.
• Không lưu khóa giải mã: repository mã hóa nhưng password chỉ nằm trên máy đã hỏng.
• Retention xóa quá mạnh: lệnh forget/prune sai policy làm mất bản backup cần cho điều tra.
• Backup cùng tài khoản bị ransomware: attacker có quyền production cũng xóa được backup.

10. Troubleshooting nhanh

Restic báo wrong password

Fatal: wrong password or no key found

Kiểm tra đúng repository, đúng password file, đúng user chạy lệnh. Nên lưu bản sao password trong vault và có quy trình break-glass.

Restore xong nginx lỗi permission

connect() to unix:/run/app.sock failed (13: Permission denied)

Kiểm tra user/group của socket và cấu hình systemd:

ls -l /run/app.sock
systemctl cat app
ps -eo user,group,cmd | grep app

Database restore chậm hơn RTO

Nếu restore dump mất 4 giờ trong khi RTO là 1 giờ, cần đổi chiến lược: snapshot volume nhất quán, replica nóng, PITR/WAL archive hoặc backup vật lý như pg_basebackup.

11. Checklist nghiệm thu restore drill

• Backup inventory được cập nhật trong 30 ngày gần nhất.
• Backup repository mã hóa và có kiểm soát quyền truy cập.
• Password/key restore nằm trong vault, không chỉ nằm trên server production.
• Restore drill chạy trên môi trường cô lập, không ghi đè production.
• File cấu hình, mã nguồn, uploads và database đều restore được.
• Dịch vụ khởi động bằng systemd không lỗi.
• Smoke test HTTP/API trả về kết quả hợp lệ.
• Thời gian restore thực tế nhỏ hơn hoặc bằng RTO.
• Dữ liệu mất tối đa không vượt RPO.
• Kết quả drill được ghi vào ticket/runbook kèm log và lỗi phát hiện.

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

1. Tạo VM Ubuntu lab, cài nginx và PostgreSQL.
2. Tạo một website tĩnh nhỏ trong /var/www/app và một database appdb.
3. Dùng restic backup /etc/nginx, /var/www/app và dump database.
4. Xóa VM lab hoặc tạo VM mới.
5. Restore từ restic sang VM mới.
6. Đo thời gian từ lúc bắt đầu restore đến khi curl http://127.0.0.1 trả HTTP 200.
7. Viết lại lỗi gặp phải và cập nhật runbook.

Kết luận

Một hệ thống Linux có backup nhưng không có restore drill vẫn là một rủi ro lớn. Restore drill giúp đội sysadmin phát hiện sớm lỗ hổng trong inventory, quyền file, database dump, secret, retention và quy trình vận hành. Hãy bắt đầu nhỏ: mỗi tháng restore một dịch vụ quan trọng vào lab, đo RPO/RTO thực tế, rồi cải tiến dần. Khi sự cố thật xảy ra, đội của bạn sẽ làm theo runbook đã được kiểm chứng thay vì vừa khôi phục vừa đoán.