Cách sao lưu và thử phục hồi dữ liệu trên VPS Debian

Để sao lưu VPS Debian có thể dùng khi xảy ra sự cố, bạn cần lưu đủ tệp ứng dụng, cơ sở dữ liệu và cấu hình, sau đó thử khôi phục ở môi trường riêng. Một tệp nén tạo thành công chưa chứng minh website có thể chạy lại. Hướng dẫn này giúp bạn tạo bản sao, chuyển ra ngoài VPS và kiểm tra việc phục hồi mà không ghi đè hệ thống đang hoạt động.

Các lệnh dưới đây là ví dụ minh họa, giả định bạn có quyền quản trị và website dùng MariaDB hoặc MySQL. Hãy thay đường dẫn, tên database và tài khoản theo hệ thống thực tế.

Xác định dữ liệu và thời điểm cần sao lưu

Trước tiên, lập danh sách thành phần cần khôi phục. Với website thông thường, danh sách gồm mã nguồn, tệp người dùng tải lên, cơ sở dữ liệu, cấu hình web server, tác vụ định kỳ và thông tin phiên bản phần mềm.

• Tệp ứng dụng: ví dụ /var/www/example, bao gồm tệp cấu hình ẩn nếu ứng dụng sử dụng.
• Cơ sở dữ liệu: xuất bằng công cụ phù hợp; không sao chép trực tiếp thư mục dữ liệu của database đang chạy.
• Cấu hình hệ thống: chỉ chọn phần cần thiết, chẳng hạn cấu hình Nginx, PHP và dịch vụ ứng dụng.
• Bí mật: mật khẩu, khóa API và khóa mã hóa phải được bảo vệ bằng mã hóa và giới hạn truy cập.

Chọn lịch dựa trên lượng dữ liệu có thể chấp nhận mất. Nếu chỉ sao lưu mỗi đêm, bạn có thể mất thay đổi kể từ lần sao lưu gần nhất. Website nhận đơn thường xuyên cần phương án sao lưu và phục hồi chi tiết hơn. Kiểm tra trước dung lượng trống, kích thước dữ liệu và tải CPU, đĩa trong khung giờ dự kiến.

Tạo bản sao nhất quán cho website Debian

Chuẩn bị thư mục lưu tạm

Ví dụ sau chạy trong shell quản trị. Thư mục sao lưu nằm ngoài thư mục website để tránh bị tải xuống qua web và không bị đưa ngược vào tệp nén.

sudo -i
umask 077
BACKUP_DIR="/var/backups/site-$(date +%F-%H%M%S)"
mkdir -p "$BACKUP_DIR"
chmod 700 "$BACKUP_DIR"
df -h /var/backups

Hãy giữ cùng phiên shell khi dùng biến BACKUP_DIR. Kiểm tra đủ chỗ cho cả bản xuất database và tệp nén; nếu thiếu, đổi sang ổ lưu trữ phù hợp trước khi tiếp tục.

Xuất cơ sở dữ liệu

Với MariaDB, có thể dùng lệnh sau nếu tài khoản quản trị cục bộ được cấu hình xác thực qua Unix socket. Nếu không, sử dụng tài khoản sao lưu được cấp quyền phù hợp và nhập mật khẩu theo cách an toàn.

mariadb-dump --single-transaction --routines --events --triggers \
  --databases appdb > "$BACKUP_DIR/database.sql"

Với MySQL, công cụ tương ứng thường là mysqldump; cần đối chiếu tùy chọn với phiên bản đang dùng. --single-transaction phù hợp với bảng hỗ trợ giao dịch như InnoDB, không bảo đảm tính nhất quán cho mọi loại bảng. Tránh thay đổi cấu trúc bảng khi xuất dữ liệu. Kiểm tra mã thoát của lệnh và thông báo lỗi ngay sau khi chạy.

Lưu tệp và cấu hình

Để dữ liệu trong database khớp với tệp tải lên, nên tạm dừng các thao tác ghi trong khoảng xuất database và sao lưu tệp. Chế độ bảo trì phải chặn cả worker, cron hoặc tiến trình nền có thể ghi dữ liệu, không chỉ giao diện website.

tar --acls --xattrs -czpf "$BACKUP_DIR/site-files.tar.gz" \
  -C / var/www/example

tar --acls --xattrs -czpf "$BACKUP_DIR/nginx-config.tar.gz" \
  -C / etc/nginx

Chỉ chạy lệnh lưu cấu hình Nginx nếu VPS thực sự sử dụng Nginx. Ghi thêm phiên bản Debian, PHP, database và các bước triển khai vào tệp hướng dẫn phục hồi. Sau khi sao lưu hoàn tất và kiểm tra không có lỗi, mở lại chức năng ghi.

Kiểm tra tệp và giữ bản sao ngoài VPS

Tạo checksum giúp phát hiện tệp bị thay đổi hoặc hỏng khi truyền. Nó không chứng minh dữ liệu nghiệp vụ đầy đủ, cũng không thay thế bước phục hồi thử.

cd "$BACKUP_DIR"
sha256sum database.sql site-files.tar.gz nginx-config.tar.gz > SHA256SUMS
sha256sum -c SHA256SUMS
tar -tzf site-files.tar.gz > /dev/null

Bỏ tên tệp cấu hình khỏi lệnh nếu bạn không tạo bản đó. Kiểm tra bản SQL không rỗng và xem lại lỗi xuất dữ liệu. Sau đó chuyển bản sao qua kênh được mã hóa đến máy lưu trữ khác hoặc kho lưu trữ phù hợp.

• Không chỉ giữ backup trên cùng ổ đĩa với website.
• Mã hóa bản sao có chứa dữ liệu cá nhân hoặc bí mật; giữ khóa giải mã riêng và kiểm tra khả năng sử dụng khóa.
• Giới hạn quyền xóa trên nơi nhận để giảm nguy cơ máy nguồn bị xâm nhập rồi xóa cả backup.
• Thiết lập thời hạn lưu theo dung lượng và nhu cầu quay lại nhiều mốc thời gian.

Chỉ xóa bản cũ sau khi xác nhận bản mới đã được chuyển đầy đủ. Snapshot của nhà cung cấp có thể bổ sung khả năng quay lui, nhưng không nên mặc định snapshot khi database đang chạy là bản sao nhất quán của ứng dụng.

Thử phục hồi trên một VPS hoặc môi trường riêng

Chuẩn bị máy thử có phiên bản phần mềm tương thích. Không trỏ tên miền thật vào máy thử. Chặn gửi email, thanh toán và các kết nối gây tác động ra hệ thống thật; thay thông tin tích hợp trước khi khởi chạy ứng dụng.

1. Tải bản sao về máy thử, giải mã nếu có và kiểm tra checksum.
2. Giải nén vào thư mục tạm để xem cấu trúc, thay vì ghi ngay vào thư mục hệ thống.
3. Tạo database riêng và nhập bản SQL bằng tài khoản quản trị của môi trường thử.
4. Cấu hình ứng dụng dùng database thử, kiểm tra quyền tệp rồi mới bật dịch vụ.

mkdir -p /srv/restore-check
tar --acls --xattrs -xzpf site-files.tar.gz -C /srv/restore-check
mariadb < database.sql

Lệnh nhập database chỉ chạy trên máy thử đã được cô lập. Vì ví dụ xuất dùng --databases appdb, bản SQL có thể chứa lệnh tạo và chọn database mang tên gốc. Không nhập vào máy đang chứa database sản xuất cùng tên.

Không chép đè toàn bộ cấu hình Nginx lên máy mới. Đối chiếu đường dẫn, phiên bản, chứng chỉ và địa chỉ lắng nghe; kiểm tra cấu hình bằng nginx -t trước khi nạp lại. Quyền sở hữu tệp cũng cần khớp với tài khoản chạy ứng dụng trên máy đích.

Xác nhận kết quả và xử lý lỗi thường gặp

Ví dụ giả định website có một đơn thử và một ảnh tải lên được tạo trước thời điểm sao lưu. Khi phục hồi, hãy mở đúng đơn, kiểm tra trạng thái và tải ảnh tương ứng. Cách này xác nhận mối liên hệ giữa database và tệp, thay vì chỉ kiểm tra trang chủ có hiển thị.

• Thiếu ảnh hoặc tài liệu: kiểm tra đường dẫn lưu thực tế, ổ đĩa gắn ngoài và đích của symbolic link. Tệp nén không tự chứa mọi dữ liệu bên ngoài thư mục đã chọn.
• Lỗi kết nối database: kiểm tra tài khoản, quyền truy cập và cấu hình môi trường; không mặc định bản xuất đã bao gồm người dùng database.
• Ứng dụng báo lỗi sau phục hồi: đối chiếu phiên bản runtime, extension, thư viện và log ứng dụng.
• Backup tự động thất bại: kiểm tra dung lượng, quyền ghi, đường dẫn công cụ và môi trường chạy cron.

Ghi thời gian từ lúc bắt đầu tải backup đến khi ứng dụng dùng được. Nếu quá lâu so với thời gian ngừng dịch vụ chấp nhận được, cần điều chỉnh dung lượng máy phục hồi, đường truyền hoặc phương pháp sao lưu.

Câu hỏi thường gặp

Có cần tắt toàn bộ VPS khi sao lưu không?

Không nhất thiết. Điều quan trọng là kiểm soát nguồn ghi và dùng phương pháp nhất quán cho database. Với hệ thống nhiều thành phần, cần quy trình phối hợp riêng thay vì chỉ nén thư mục.

Nên tự động hóa bằng cron ngay không?

Nên chạy thủ công và phục hồi thử thành công trước. Khi đưa vào cron, dùng đường dẫn tuyệt đối, khóa chống chạy chồng, kiểm tra mã thoát và gửi cảnh báo khi lỗi. Log không được chứa mật khẩu hay nội dung nhạy cảm.

Máy phục hồi cần cấu hình giống máy gốc không?

Không bắt buộc giống hoàn toàn, nhưng cần đủ RAM, CPU, dung lượng và phiên bản phần mềm tương thích. Hãy thử với kích thước dữ liệu thực tế, không chỉ một database mẫu nhỏ.

Lên lịch một lần diễn tập phục hồi

Hãy chọn một bản sao, phục hồi trên môi trường riêng và ghi lại các bước còn thiếu. Sau đó đặt lịch diễn tập định kỳ và sau những thay đổi lớn của ứng dụng. Nếu cần VPS thử hoặc nơi lưu trữ bổ sung, bạn có thể tham khảo danh mục liên quan tại sieuthicode.com; xác nhận tài nguyên, lưu trữ, bảo mật, giấy phép phần mềm và phạm vi hỗ trợ trước khi mua, rồi kiểm thử bằng quy trình trên.