Bộ App Backup Homelab: 3-2-1, Snapshot, Restore An Toàn

31/05/2026 · P T P · Chung

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

Trước khi chọn app, phân loại:

Dữ liệu cực quan trọng

Ví dụ:

– Ảnh gia đình.
– Tài liệu cá nhân.
– Password vault.
– GPG/SSH keys.
– Code riêng.
– Config hạ tầng.

Yêu cầu:

– Mã hóa.
– Offsite.
– Nhiều version.
– Kiểm tra restore định kỳ.

Dữ liệu quan trọng vừa

Ví dụ:

– Media metadata.
– Config app.
– Dashboard.
– Home Assistant history.
– Paperless-ngx documents.

Yêu cầu:

– Backup đều.
– Có snapshot.
– Restore nhanh.

Dữ liệu có thể tải lại

Ví dụ:

– Phim/nhạc public.
– Cache.
– Docker image.
– Torrent incomplete.
– Build artifacts.

Yêu cầu:

– Không nhất thiết backup toàn bộ.
– Có thể chỉ backup metadata/config.

Phân loại đúng → giảm dung lượng, giảm chi phí, tăng độ tin cậy.


Bộ app backup self-hosted nên cân nhắc

1. Restic: nhẹ, mạnh, chuẩn homelab

Restic là lựa chọn rất phổ biến:

– Mã hóa mặc định.
– Deduplication tốt.
– Hỗ trợ nhiều backend: local, SFTP, S3, B2, REST server.
– Dễ script.
– Restore linh hoạt.

Ví dụ backup thư mục Docker volumes:

restic -r s3:s3.example.com/homelab-backup backup /srv/docker /etc /home

Kiểm tra repo:

restic check

Liệt kê snapshot:

restic snapshots

Restore:

restic restore latest --target /tmp/restore-test

Restic hợp với người thích CLI, systemd timer, cron, GitOps.

2. BorgBackup: hiệu quả, mạnh với Linux server

BorgBackup nổi tiếng nhờ:

– Nén tốt.
– Dedup mạnh.
– SSH backend đơn giản.
– Phù hợp backup sang NAS/VPS.

Kết hợp với Borgmatic → config YAML dễ quản lý, hook trước/sau backup, DB dump, retention policy.

Ví dụ use-case:

– Backup /etc, /home, /srv/docker.
– Dump PostgreSQL trước backup.
– Gửi sang NAS qua SSH.
– Prune bản cũ tự động.

Borg/Borgmatic rất hợp nếu offsite là VPS hoặc storage box hỗ trợ SSH.

3. Kopia: GUI + CLI, thân thiện hơn

Kopia có:

– Web UI.
– CLI.
– Snapshot policy.
– Dedup/encryption.
– S3/B2/SFTP/local.
– Docker dễ triển khai.

Kopia phù hợp nếu bạn muốn giao diện quản trị, lịch backup, policy rõ ràng, ít tự viết script.

4. Duplicati: dễ dùng, nhưng cần cẩn trọng

Duplicati có Web UI đẹp, hỗ trợ nhiều cloud. Phù hợp người mới. Nhưng cộng đồng homelab thường cảnh báo về độ ổn định DB metadata ở workload lớn.

Nếu dùng:

– Backup nhỏ-vừa.
– Kiểm tra restore thường xuyên.
– Theo dõi log.
– Không xem “backup success” là đủ.

5. Proxmox Backup Server: nếu dùng Proxmox

Nếu homelab chạy Proxmox, Proxmox Backup Server (PBS) rất đáng dùng:

– Backup VM/LXC incremental.
– Dedup.
– Verify.
– Prune.
– Restore file/VM.
– Tích hợp Proxmox VE tốt.

PBS không thay thế hoàn toàn file-level backup, nhưng cực mạnh cho tầng VM/LXC. Mô hình tốt:

– PBS → backup VM/LXC.
– Restic/Borg → backup app data, DB dump, config quan trọng.
– Offsite sync → bản ngoài nhà.


Snapshot: nhanh, tiện, nhưng không phải backup

Snapshot là ảnh chụp trạng thái filesystem/block tại một thời điểm. ZFS, Btrfs, LVM, Proxmox đều hỗ trợ.

Ưu điểm:

– Tạo gần như tức thì.
– Restore nhanh.
– Chống xóa nhầm ngắn hạn.
– Hữu ích trước khi update app.

Ví dụ ZFS:

zfs snapshot tank/data@before-upgrade

Rollback:

zfs rollback tank/data@before-upgrade

Nhưng snapshot có giới hạn:

– Cùng pool chết → snapshot chết.
– Ransomware có quyền xóa snapshot → mất.
– Không offsite.
– Không thay bản backup mã hóa độc lập.

Cách dùng đúng:

– Snapshot theo giờ/ngày cho restore nhanh.
– Backup snapshot sang nơi khác bằng zfs send.
– Không nhầm snapshot = backup.

Mô hình mạnh:

– ZFS snapshot mỗi giờ, giữ 24h.
– Snapshot ngày, giữ 14 ngày.
– Snapshot tuần, giữ 8 tuần.
– Restic/Borg offsite mỗi ngày.


Backup Docker app: volume, config, DB

Homelab hiện đại thường chạy Docker Compose. Dữ liệu quan trọng nằm ở:

docker-compose.yml
.env
– bind mounts: /srv/app/data
– named volumes
– DB volumes
– reverse proxy config
– certs
– secrets

Khuyến nghị:

– 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.

Ví dụ layout:

/srv/docker/
  nextcloud/
    docker-compose.yml
    .env
    data/
    db/
  vaultwarden/
    docker-compose.yml
    data/
  paperless/
    docker-compose.yml
    consume/
    media/
    db/

DB cần dump, không chỉ copy file

PostgreSQL/MySQL đang chạy → copy thẳng volume có thể tạo backup không nhất quán.

Nên dump trước:

PostgreSQL:

docker exec postgres pg_dumpall -U postgres > /srv/backups/postgres.sql

MySQL/MariaDB:

docker exec mariadb mysqldump -u root -p --all-databases > /srv/backups/mysql.sql

Sau đó backup file dump bằng Restic/Borg.

Với app lớn như Nextcloud:

– Bật maintenance mode.
– Dump DB.
– Backup data/config.
– Tắt maintenance mode.


Lịch backup: ngắn hạn, dài hạn, offsite

Một retention policy thực tế:

– Snapshot local:
– Mỗi giờ, giữ 24 bản.
– Mỗi ngày, giữ 14 bản.
– Backup local:
– Mỗi ngày, giữ 30 ngày.
– Mỗi tuần, giữ 8 tuần.
– Backup offsite:
– Mỗi ngày hoặc mỗi 2 ngày.
– Giữ 3-6 tháng.
– Bản tháng, giữ 1 năm cho dữ liệu quan trọng.

Với Restic:

restic forget --keep-daily 30 --keep-weekly 8 --keep-monthly 12 --prune

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.

Nên có alert:

– Uptime Kuma check script endpoint.
– Healthchecks.io hoặc self-hosted Healthchecks.
– Gotify/ntfy/Telegram báo lỗi.
– Log gửi về Loki/Promtail nếu có.

Mẫu đơn giản:

backup.sh && curl https://healthchecks.example.com/ping/uuid

Nếu script không ping đúng hạn → báo động.


Kết luận: backup tốt là hệ thống có thể diễn tập

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.

#backup #homelab #restore #snapshot #toan
Chia sẻ:
← Trước
Bộ app self-hosted biến homelab dev thành xưởng phần mềm xịn
Sau →
So sánh app self-hosted: chọn stack homelab chuẩn nhất

Bài viết tương tự

Bình luận

Chưa có bình luận. Hãy là người đầu tiên!