Backup VPS tự động và khôi phục khi gặp sự cố cần được thiết kế thành một quy trình: chọn dữ liệu, tạo bản sao, kiểm tra và diễn tập phục hồi. Tài liệu restic cung cấp các thao tác này, nhưng công cụ không tự hẹn lịch. Hướng dẫn dưới đây ghép restic với systemd trên Linux, dùng một máy SFTP riêng làm nơi lưu trữ. Đây là cấu hình minh họa, chưa được chạy thử trên hệ thống của người đọc.
1. Xác định dữ liệu và chuẩn bị nơi nhận backup
Trước khi cấu hình, lập danh sách mã nguồn, tệp tải lên, cấu hình dịch vụ và cơ sở dữ liệu cần phục hồi. Ví dụ này giả định dữ liệu ứng dụng nằm ở /srv/app, còn kho backup ở máy khác. Chọn lịch theo mức dữ liệu có thể chấp nhận mất; lịch mỗi ngày trong bài chỉ là phương án minh họa. Ghi riêng cách dựng lại dịch vụ để tránh nhầm bản sao tệp với một máy chủ đã sẵn sàng hoạt động.
Điều kiện thực hành là VPS đã có restic, systemd và tài khoản quản trị; máy nhận có SSH/SFTP cùng thư mục cho phép tài khoản backup ghi dữ liệu. Theo tài liệu restic, xác thực không cần nhập mật khẩu tương tác là điều kiện để tự động hóa SFTP. Chuẩn bị khóa SSH cho đúng tài khoản chạy tác vụ, xác minh khóa máy chủ qua kênh tin cậy và kiểm tra kết nối trước. Không thay đổi cổng, tường lửa hay cơ chế đăng nhập SSH hiện có chỉ để làm bài này.
2. Khởi tạo kho và tách bí mật khỏi cấu hình
Thay backup.example.net bằng máy nhận thực tế. Trong phiên quản trị dùng để chuẩn bị, đặt hai biến dưới đây; tạo trước /root/.config/restic/password chứa mật khẩu kho bằng trình soạn thảo, với quyền chỉ chủ sở hữu đọc được. Không dùng mật khẩu mẫu hoặc đưa bí mật vào mã nguồn.
Cấu hình mẫu cho phiên shell:
export RESTIC_REPOSITORY='sftp:[email protected]:/srv/restic-repo'
export RESTIC_PASSWORD_FILE='/root/.config/restic/password'
Khởi tạo một lần:
restic init
Kiểm tra truy cập:
restic snapshots
Restic hỗ trợ cả biến vị trí kho và tệp mật khẩu như trên. Xác nhận lệnh kiểm tra mở được đúng kho, kể cả khi kho mới chưa có snapshot. Tài liệu dự án cảnh báo mất mật khẩu đồng nghĩa không thể truy cập dữ liệu đã lưu. Vì vậy, đề xuất giữ một bản bí mật phục hồi ở nơi độc lập với VPS; đừng để sự cố mất máy đồng thời lấy đi cách mở bản sao.
3. Tạo bản sao đầu tiên từ dữ liệu phù hợp
Với PostgreSQL, nên chuẩn bị bản xuất logic thay vì coi thư mục cơ sở dữ liệu đang hoạt động là đầu vào của ví dụ này. Tài liệu PostgreSQL mô tả pg_dump tạo bản sao nhất quán của một cơ sở dữ liệu trong khi hệ thống vẫn được sử dụng. Tuy nhiên, pg_dump không bao gồm các đối tượng toàn cụm như vai trò; hãy bổ sung phương án lưu chúng nếu ứng dụng cần.
Ví dụ khi đã cấu hình xác thực PostgreSQL cho tài khoản thực hiện và đã tạo thư mục /srv/backup-staging với quyền hạn chế:
pg_dump -Fc -d appdb -f /srv/backup-staging/appdb.dump
Chỉ sau khi bản xuất thành công, chạy:
restic backup /srv/app /srv/backup-staging
Sau đó đối chiếu snapshot:
restic snapshots
Thay appdb và đường dẫn theo ứng dụng; không đưa thư mục dữ liệu PostgreSQL đang chạy vào /srv/app trong ví dụ này. Theo restic, mã thoát 0 biểu thị backup đầy đủ, còn mã 3 nghĩa là có tệp không đọc được dù snapshot vẫn có thể được tạo. Vì vậy, cần xem lỗi và danh sách đường dẫn, không chỉ thấy snapshot mới là kết luận đủ dữ liệu. Nếu bản xuất thất bại, dừng quy trình để tránh dùng lại tệp dump cũ.
4. Đóng gói tác vụ có thể dừng khi lỗi
Sau khi từng lệnh chạy thủ công thành công, lưu nội dung mẫu sau vào /usr/local/sbin/vps-backup bằng tài khoản quản trị và đặt quyền thực thi, chỉ cho quản trị sửa. Đường dẫn restic và pg_dump phải khớp máy thực tế. Mẫu dùng Bash với set -eu để dừng khi lệnh xuất dữ liệu hoặc backup thất bại.
Nội dung script minh họa:
#!/bin/bash
set -eu
export RESTIC_REPOSITORY='sftp:[email protected]:/srv/restic-repo'
export RESTIC_PASSWORD_FILE='/root/.config/restic/password'
/usr/bin/pg_dump -Fc -d appdb -f /srv/backup-staging/appdb.dump
/usr/bin/restic backup /srv/app /srv/backup-staging
Tạo /etc/systemd/system/vps-backup.service với nội dung:
[Unit]
Description=VPS backup with restic
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/vps-backup
Nạp cấu hình và chạy kiểm tra:
systemctl daemon-reload
systemctl start vps-backup.service
systemctl status vps-backup.service
Đây là ví dụ dịch vụ hệ thống chạy với quyền mặc định của root, nên khóa SSH và xác thực cơ sở dữ liệu phải được chuẩn bị cho ngữ cảnh đó. Với Type=oneshot, dịch vụ có thể trở về trạng thái inactive sau khi hoàn tất; hãy đọc kết quả thoát thay vì đòi trạng thái running. Không chạy thêm bản script thủ công trong lúc tác vụ đang hoạt động.
5. Hẹn lịch và theo dõi lần chạy thực tế
Tạo /etc/systemd/system/vps-backup.timer theo mẫu dưới đây. Theo tài liệu systemd, OnCalendar đặt lịch theo đồng hồ hệ thống; Persistent=true cho phép kích hoạt bù khi timer hoạt động trở lại sau một kỳ bị bỏ lỡ, không tái tạo từng bản sao đã thiếu.
Nội dung timer minh họa:
[Unit]
Description=Daily VPS backup
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
[Install]
WantedBy=timers.target
Kích hoạt và kiểm tra:
systemctl daemon-reload
systemctl enable --now vps-backup.timer
systemctl list-timers --all
Đối chiếu múi giờ máy chủ, thời điểm chạy tiếp theo và snapshot được tạo sau lần hẹn đầu tiên. Đề xuất bổ sung cảnh báo khi tác vụ lỗi hoặc quá lâu chưa có snapshot mới; timer được bật không thay thế việc theo dõi kết quả. Nếu cấu hình sai, quay lui bằng systemctl disable --now vps-backup.timer rồi sửa dịch vụ; giữ nguyên kho backup để điều tra.
6. Kiểm tra tính toàn vẹn của kho
Khi không có tác vụ backup hay bảo trì khác đang chạy, dùng restic check để kiểm tra cấu trúc kho. Tài liệu restic phân biệt phép kiểm tra mặc định với kiểm tra dữ liệu thực bằng --read-data. Lệnh thứ hai đọc toàn bộ các gói dữ liệu, nên cần dự trù thời gian và lưu lượng truyền.
Các lệnh kiểm tra, chạy riêng từng lần với biến kho và mật khẩu đã thiết lập:
restic check
restic check --read-data
Nếu có lỗi, lưu thông tin lỗi và tạm hoãn xóa bản sao cũ. Không coi việc kiểm tra cấu trúc thành công là bằng chứng ứng dụng đã phục hồi được.
7. Diễn tập khôi phục vào nơi tách biệt
Chuẩn bị máy thử hoặc thư mục đích trống đủ dung lượng. Chọn ID cụ thể từ restic snapshots, ưu tiên bản trước thời điểm xảy ra sự cố thay vì mặc định lấy latest. Tài liệu restic cho phép phục hồi theo ID với --target; cây đường dẫn gốc được đặt bên dưới thư mục đích.
Lệnh mẫu, thay SNAPSHOT_ID bằng ID thực tế:
restic restore SNAPSHOT_ID --target /srv/restore-test
Kiểm tra dữ liệu dự kiến tại /srv/restore-test/srv/app và /srv/restore-test/srv/backup-staging. Với bản dump PostgreSQL dạng custom, dùng pg_restore trong môi trường thử đã chuẩn bị; tham số kết nối và cơ sở dữ liệu đích phải được kiểm tra riêng.
Đề xuất kiểm chứng tệp tải lên, đăng nhập và thao tác dữ liệu quan trọng trước khi chuyển ứng dụng sang dữ liệu phục hồi. Giữ bản hiện trạng và cấu hình cũ để quay lui nếu kiểm tra thất bại. Restic cảnh báo phục hồi trực tiếp có thể ghi đè tệp và để lại trạng thái dở dang nếu bị ngắt; vì vậy, bài này không dùng --target / và không sao chép mù toàn bộ /etc lên máy mới.
8. Áp dụng thời hạn giữ bản sao sau diễn tập
Chỉ xem xét dọn kho sau khi đã phục hồi thử. Ví dụ chính sách giữ bản theo ngày, tuần và tháng dưới đây là lựa chọn vận hành, không phải mức bắt buộc. Theo restic, --dry-run chỉ hiển thị hành động; forget loại snapshot theo chính sách, còn prune thu hồi dữ liệu không còn được tham chiếu.
Xem trước chính sách:
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
Đọc kỹ nhóm host, đường dẫn và danh sách giữ/xóa. Chỉ bỏ --dry-run khi danh sách phù hợp và đã có điểm phục hồi cần giữ. Sau khi thực hiện forget, có thể chạy restic prune trong cửa sổ bảo trì riêng, rồi kiểm tra kho lại.
Lưu ID snapshot đã phục hồi thử cùng thời gian diễn tập và kết quả kiểm tra ứng dụng. Nếu phát hiện chính sách chọn nhầm bản cần giữ, dừng trước thao tác xóa; bài này không coi dữ liệu đã prune là có thể quay lui. Mục tiêu vận hành là có một điểm phục hồi được kiểm chứng và hướng dẫn đủ rõ để dùng khi VPS chính không còn truy cập được.
