Thuê VPS theo tháng: rủi ro dữ liệu và cách tự bảo vệ

Bạn SSH vào VPS của mình, chạy lệnh systemctl status nginx và thấy “Unit nginx.service not found”. VPS đã bị khởi tạo lại từ đầu vì quá hạn thanh toán mà bạn quên gia hạn. Dữ liệu web, database, cấu hình, toàn bộ biến mất. Đây không phải chuyện hiếm với người dùng thuê VPS theo tháng. Bài này sẽ chỉ ra các rủi ro thực tế và hướng dẫn bạn cách tự bảo vệ, không phụ thuộc vào nhà cung cấp.

Tóm tắt nhanh

• Snapshot là bản sao nội bộ, không thay thế backup, nó biến mất khi VPS bị xoá.
• Backup ra ngoài server (dùng rsync, restic) là cách riêng biệt chống lại rủi ro mất dữ liệu khi quên gia hạn.
• Kiểm tra restore định kỳ ít nhất mỗi tháng một lần để đảm bảo backup khả dụng.
• Dịch vụ thuê VPS theo tháng như thueVPS có uptime 99.9%, nhưng bạn vẫn phải tự lo backup ra bên ngoài.

Vì sao dữ liệu trên VPS dễ bị mất?

Bạn nghĩ rằng dữ liệu trên VPS là an toàn, vì nhà cung cấp có hạ tầng ổn định, có snapshot. Nhưng thực tế có ba kịch bản rủi ro chính mà bất kỳ ai thuê VPS theo tháng đều có thể gặp.

1. Quên gia hạn thanh toán

Đây là lỗi phổ biến nhất. Bạn thuê VPS theo tháng và thanh toán hàng tháng. Nếu bạn lỡ quên một kỳ, nhiều nhà cung cấp sẽ tạm dừng dịch vụ sau 3-7 ngày và xoá hoàn toàn VPS sau 14-30 ngày. Dữ liệu trên ổ cứng NVMe sẽ bị giải phóng. Không có snapshot nào cứu được vì snapshot nằm trên cùng hệ thống lưu trữ đó.

2. Snapshot không phải là backup

Nhiều người nhầm lẫn giữa snapshot và backup. Snapshot là bản sao lưu trạng thái ổ đĩa tại một thời điểm, nhưng nó nằm trên cùng hạ tầng với VPS. Khi VPS bị xoá, snapshot cũng bị xoá theo. Một snapshot chỉ hữu ích để rollback nhanh trong thời gian ngắn (ví dụ trước khi cập nhật phần mềm). Nó không thể thay thế một bản backup thực sự được lưu ở một vị trí khác.

3. Khoá tài khoản không mong muốn

Vi phạm điều khoản sử dụng (gửi spam, chạy tool không được phép), bị tấn công DDoS, hoặc bị báo cáo lạm dụng, đều có thể dẫn đến khoá tài khoản đột ngột. Khi đó, bạn mất toàn bộ quyền truy cập vào VPS. Nếu không có backup ra ngoài, dữ liệu coi như mất.

Cơ chế hoạt động của snapshot và backup, sự khác biệt quyết định

Hiểu rõ cơ chế giúp bạn không ảo tưởng. Snapshot là tính năng của hypervisor (ví dụ KVM): nó chụp nhanh trạng thái ổ đĩa của VPS và lưu dưới dạng “cow” (copy-on-write) trên cùng volume lưu trữ. Do đó, snapshot có đặc điểm:

• Nhanh: tạo trong vài giây.
• Phụ thuộc: tồn tại song song với VPS; nếu VPS bị xoá, snapshot cũng bị xoá.
• Không di động: không thể mang sang server khác hay restore lên một VPS mới ở nhà cung cấp khác.

Ngược lại, backup là bản sao dữ liệu thực (file, database dump) được lưu ở một vị trí khác, có thể là VPS khác, máy tính local, hoặc dịch vụ lưu trữ đám mây (Google Drive, S3). Backup đúng nghĩa cho phép bạn restore lại toàn bộ dữ liệu, kể cả khi VPS cũ đã bị xoá hoàn toàn.

Khi nào cần backup ra ngoài server?

Câu trả lời là: thường xuyên, nếu dữ liệu có giá trị. Không có ngoại lệ. Nếu bạn chỉ chạy một blog cá nhân, mất data cũng không sao, thì snapshot là đủ. Nhưng nếu VPS chạy website bán hàng, database khách hàng, project GitLab, workflow n8n tự động hoá, bạn cần backup ra ngoài server ngay từ ngày đầu tiên.

Các tình huống cụ thể cần backup ra ngoài:

• Bạn dùng VPS cho hệ thống quản lý doanh nghiệp, lưu trữ dữ liệu giao dịch.
• Bạn có nhiều hơn một VPS và muốn đồng bộ hoặc dự phòng chéo.
• Bạn chạy các ứng dụng self-hosted (GitLab, n8n, WordPress) mà không muốn mất lịch sử dữ liệu.
• Bạn muốn có thể chuyển nhà cung cấp mà không bị phụ thuộc.

Bước 1 - Thiết lập backup database tự động ra ngoài

Database là phần dữ liệu quan trọng nhất. Dưới đây là cách dùng mysqldump (MySQL/MariaDB) kết hợp với rsync để backup ra một VPS khác hoặc máy local.

Giả sử bạn đang thuê VPS theo tháng chạy Ubuntu 24.04, với MariaDB. Tạo script backup tại /usr/local/bin/backup-db.sh:

#!/bin/bash
# Backup all databases
BACKUP_DIR="/backup/db"
DATE=$(date +%Y-%m-%d)
DB_USER="root"
DB_PASS="your_mysql_root_password"

mkdir -p $BACKUP_DIR
mysqldump -u $DB_USER -p$DB_PASS --all-databases --single-transaction --quick | gzip > $BACKUP_DIR/alldb_$DATE.sql.gz

# Sync to remote server (rsync over SSH)
rsync -avz -e "ssh -i /root/.ssh/backup_key" $BACKUP_DIR user@remote-backup-vps:/backup/db/

# Keep only last 7 days local
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +7 -delete

Phân tích script:

• --single-transaction: đảm bảo dump nhất quán (InnoDB), không lock table.
• gzip: nén dump để giảm dung lượng. Một database 1 GB thường nén còn 200-300 MB.
• rsync: đồng bộ lên VPS backup qua SSH key. Đây là cách đơn giản, miễn phí, không phụ thuộc bên thứ ba.
• mtime +7: xoá bản backup cũ hơn 7 ngày trên local để tiết kiệm dung lượng NVMe.

Dùng cron job chạy hàng ngày: crontab -e thêm dòng:

0 2 * * * /usr/local/bin/backup-db.sh

Verify: kiểm tra trên server backup sau 1-2 ngày.

ssh user@remote-backup-vps "ls -lh /backup/db/"

Bước 2 - Backup toàn bộ thư mục web và cấu hình

Backup thư mục /var/www, /etc/nginx, /etc/ssl và các cấu hình quan trọng khác.

#!/bin/bash
BACKUP_DIR="/backup/files"
DATE=$(date +%Y-%m-%d)
SITES_DIR="/var/www"
CONFIG_DIRS="/etc/nginx /etc/ssl /etc/php"

tar czf $BACKUP_DIR/sites_$DATE.tar.gz $SITES_DIR
tar czf $BACKUP_DIR/config_$DATE.tar.gz $CONFIG_DIRS

rsync -avz -e "ssh -i /root/.ssh/backup_key" $BACKUP_DIR user@remote-backup-vps:/backup/files/

find $BACKUP_DIR -type f -name "*.tar.gz" -mtime +14 -delete

Bước 3 - Kiểm tra restore định kỳ, bước dễ bỏ qua nhất

Backup mà không kiểm tra restore thì vô dụng. Bạn cần xác nhận rằng file backup còn nguyên vẹn và có thể restore được. Thiết lập lịch kiểm tra restore mỗi tháng một lần, trên một VPS thử nghiệm (có thể là VPS nhỏ như gói VNLite 1 vCPU / 2 GB).

Dưới đây là kịch bản kiểm tra restore tự động:

#!/bin/bash
# Restore test script - run on a test VPS
# Step 1: Download latest backup
rsync -avz -e "ssh -i /root/.ssh/backup_key" user@production-vps:/backup/ /tmp/restore_test/

# Step 2: Restore database
gunzip < /tmp/restore_test/db/alldb_$(ls -1 /tmp/restore_test/db/ | tail -1) | mysql -u root -p$DB_PASS

# Step 3: Extract files
tar xzf /tmp/restore_test/files/sites_$(ls -1 /tmp/restore_test/files/ | grep sites | tail -1).tar.gz -C /
tar xzf /tmp/restore_test/files/config_$(ls -1 /tmp/restore_test/files/ | grep config | tail -1).tar.gz -C /

# Step 4: Check database tables exist
mysql -u root -p$DB_PASS -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema');" || echo "RESTORE FAILED!"

Chạy script này trên cron mỗi tháng gửi kết quả qua email hoặc Telegram. Nếu bước cuối báo “RESTORE FAILED!”, bạn cần kiểm tra lại.

Đánh đổi của các phương án backup

Với hầu hết người dùng, rsync sang một VPS Linux thứ hai là giải pháp cân bằng nhất. Bạn có thể mua thêm một gói VPS nhỏ (gói VNLite chỉ từ 189.000đ/tháng) làm backup target.

Xử lý lỗi thường gặp

Lỗi 1: Rsync “Permission denied (publickey)”

Nguyên nhân: SSH key không được thêm vào authorized_keys trên máy đích. Giải pháp: chạy ssh-copy-id -i /path/to/key user@remote-vps một lần để xác thực.

Lỗi 2: Dump database quá lớn gây nghẽn I/O

Giải pháp: dùng --single-transaction và chạy lúc ít truy cập (2h sáng). Với database rất lớn, chia nhỏ thành từng database riêng.

Lỗi 3: Hết dung lượng NVMe trên máy backup

Giải pháp: giữ số ngày backup ít hơn (3-5 ngày) và kiểm tra dung lượng còn trống định kỳ bằng df -h.

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

Bài viết liên quan

• Cấu hình Swap và tối ưu bộ nhớ cho VPS RAM thấp
• Benchmark hiệu năng VPS với FIO, sysbench, iperf3
• Cách cài Docker trên VPS Ubuntu chi tiết từ A đến Z