Bộ app self-hosted backup dữ liệu homelab: chiến lược 3-2-1, snapshot, restore thử nghiệm
Homelab vui nhất lúc mọi thứ chạy mượt: Plex/Jellyfin phát phim, Nextcloud đồng bộ ảnh, Home Assistant tự động hóa nhà, Vaultwarden giữ mật khẩu, Gitea lưu code, PostgreSQL/MySQL nuôi app. Nhưng chỉ cần một ổ đĩa chết, một lệnh rm -rf sai, một container ghi đè volume, hoặc ransomware lan qua share SMB → toàn bộ “ngôi nhà số” có thể biến mất.
Backup không phải việc “để sau”. Với homelab, backup là hạ tầng sống còn. Mục tiêu không phải chỉ “có bản sao”, mà là: restore được, đúng dữ liệu, đúng thời điểm, trong thời gian chấp nhận được.
Bài này đi vào bộ app self-hosted thực tế: chiến lược 3-2-1, snapshot, backup app/container/DB, lưu offsite, mã hóa, tự động hóa, kiểm tra restore.
Tư duy nền: 3-2-1 không lỗi thời
Chiến lược 3-2-1:
– 3 bản dữ liệu: dữ liệu chính + 2 bản backup.
– 2 loại media khác nhau: ví dụ NAS + ổ USB / local disk + cloud object storage.
– 1 bản offsite: ngoài nhà, ngoài máy chính, ngoài rủi ro cháy/nước/trộm/ransomware.
Trong homelab, mô hình thực dụng:
– Primary: server chạy Docker/VM.
– Local backup: NAS, ZFS pool phụ, ổ USB, máy mini khác.
– Offsite backup: Backblaze B2, Wasabi, Hetzner Storage Box, S3-compatible, VPS ở nơi khác, nhà người thân.
Điểm quan trọng: RAID không phải backup. RAID giúp sống sót khi hỏng disk, nhưng không cứu được:
– Xóa nhầm.
– App bug ghi hỏng DB.
– Ransomware mã hóa file.
– Snapshot bị xóa cùng pool.
– Cháy/nước/mất trộm.
RAID → uptime. Backup → recovery.
Phân loại dữ liệu: không phải thứ gì cũng backup giống nhau
– Dùng bind mount thay vì named volume mơ hồ.
– Đặt app trong /srv/docker/.
– Commit compose/config vào private Git.
– Backup /srv/docker, trừ cache lớn.
Quan trọng: retention dài hơn → chống phát hiện trễ. Nếu ransomware mã hóa file hôm nay nhưng 2 tuần sau mới biết, bạn cần bản sạch cũ hơn 2 tuần.
Mã hóa, quyền truy cập, chống ransomware
Backup offsite phải mã hóa. Restic/Borg/Kopia đều hỗ trợ.
Nguyên tắc:
– Backup repo password lưu trong password manager.
– Không lưu secret plaintext trong repo Git public.
– Offsite credential dùng quyền tối thiểu.
– Nếu dùng S3/B2: bật object lock/versioning nếu có.
– Backup target nên append-only nếu backend hỗ trợ.
– Server chính không nên có quyền xóa mọi bản backup dài hạn.
Ransomware risk: nếu server có quyền đọc/ghi/xóa backup → kẻ tấn công cũng có quyền đó.
Giảm rủi ro:
– Tài khoản backup chỉ write, không delete.
– Có bản offline: ổ USB cắm định kỳ, xong rút.
– NAS backup user không có quyền xóa snapshot.
– Giám sát backup failure.
Restore thử nghiệm: phần bị bỏ quên nhất
Backup chưa test = giả định, không phải bảo hiểm.
Nên có lịch:
– Hàng tuần: restic check hoặc borg check.
– Hàng tháng: restore thử 1 app nhỏ.
– Hàng quý: diễn tập restore app quan trọng.
– Sau thay đổi lớn: test lại.
Checklist restore app Docker:
1. Tạo VM/container test.
2. Cài Docker/Compose.
3. Restore /srv/docker/.
4. Restore DB dump.
5. Chạy docker compose up -d.
6. Kiểm tra login, dữ liệu, file, log.
7. Ghi lại thời gian restore.
8. Cập nhật runbook.
Ví dụ restore Restic:
restic restore latest --target /tmp/restore
Sau đó so sánh:
ls -lah /tmp/restore/srv/docker
Với dữ liệu cực quan trọng như Vaultwarden, Paperless, Nextcloud: restore thử không phải tùy chọn. Đây là bắt buộc.
Giám sát backup: im lặng là nguy hiểm
Backup thường hỏng âm thầm:
– Disk đầy.
– Token cloud hết hạn.
– Repo lock.
– Network fail.
– DB dump lỗi.
– Cron không chạy.
– Retention prune nhầm.
Bộ backup homelab đáng tin không cần quá phức tạp. Công thức thực tế:
– Snapshot local → restore nhanh.
– Restic/Borg/Kopia → backup mã hóa, dedup, version.
– PBS nếu dùng Proxmox → bảo vệ VM/LXC.
– DB dump trước backup → tránh dữ liệu hỏng.
– Offsite theo 3-2-1 → sống sót khi mất máy/mất nhà.
– Restore thử định kỳ → xác nhận mọi thứ thật sự dùng được.
Đừng hỏi “backup có chạy không?”. Hãy hỏi: “Nếu server chết ngay bây giờ, mình restore mất bao lâu, mất bao nhiêu dữ liệu?”
Nếu trả lời được bằng runbook, lệnh restore, bản backup đã test → homelab của bạn không chỉ đẹp, mà còn bền.