Backup VPS: phân biệt snapshot và backup, cách sao lưu và khôi phục an toàn

Tác giả: Đông Tùng · Duyệt kỹ thuật: Nguyễn Văn Phong · Cập nhật: 20/10/2026

Backup VPS là tạo bản sao dữ liệu của máy chủ (database, file website, cấu hình) và lưu ở nơi khác để khôi phục khi VPS hỏng, bị xóa nhầm hoặc bị tấn công. Snapshot chỉ là ảnh chụp ổ đĩa tại một thời điểm, thường nằm cùng hạ tầng với VPS, nên không thay thế được một bản backup lưu ngoài VPS.

Cách làm an toàn cho phần lớn VPS: dump database bằng mysqldump hoặc pg_dump, nén file website và cấu hình, đẩy bản sao ra ngoài bằng rclone hoặc rsync. Sau đó đặt lịch bằng cron và thử khôi phục định kỳ. Đây là bước 6 trong lộ trình cách sử dụng VPS cho người mới.

Snapshot và backup VPS khác nhau thế nào?

Snapshot ghi lại trạng thái toàn bộ ổ đĩa VPS tại một thời điểm để quay về nhanh, còn backup là bản sao dữ liệu được chọn lọc và lưu ở một nơi tách biệt. Snapshot hợp để quay lại sau một lần nâng cấp hỏng; backup hợp để lấy lại dữ liệu khi chính VPS gặp sự cố.

Tìm hiểu thêm các loại snapshot trong bài snapshot là gì. Một điểm hay bị nhầm: ổ cứng RAID (ví dụ RAID-10) chỉ giúp VPS chạy tiếp khi một ổ vật lý hỏng. RAID sao chép ngay mọi thay đổi, kể cả lệnh xóa nhầm hay file bị mã hóa, nên RAID không phải là backup. Xem các loại RAID lưu trữ.

Quy tắc sao lưu 3-2-1 áp dụng cho VPS

Quy tắc 3-2-1 khuyên giữ ba bản dữ liệu, trên hai loại lưu trữ thuộc ít nhất hai thiết bị, trong đó một bản để ở nơi khác (off-site). Đây là cách diễn đạt của Cyber Security Hub thuộc Bộ Giáo dục Anh (Department for Education). Với VPS, ba bản có thể sắp xếp như sau.

• Bản 1, dữ liệu đang chạy trên VPS: kèm một bản dump database gần nhất trong /var/backups/vps để khôi phục nhanh khi chỉ lỡ tay xóa dữ liệu.
• Bản 2, backup hoặc snapshot của nhà cung cấp: dùng khi cần đưa cả VPS về trạng thái cũ.
• Bản 3, ngoài nhà cung cấp: object storage tương thích S3, một VPS ở nơi khác, Google Drive hoặc NAS ở văn phòng. Nên dùng tài khoản riêng mà VPS không có quyền xóa.

Điểm cuối cùng quan trọng với mã độc tống tiền: kẻ tấn công chiếm được quyền root thường xóa luôn bản sao lưu mà VPS truy cập được. Hãy giữ ít nhất một bản mà VPS chỉ ghi được, không xóa được (bật versioning hoặc khóa đối tượng ở object storage, hoặc để máy backup tự kéo dữ liệu về). Xem thêm ransomware là gì.

Cần sao lưu những gì trên VPS?

Bạn không cần sao lưu cả hệ điều hành, vì cài lại một bản Ubuntu mới thường nhanh hơn khôi phục. Thứ cần giữ là những gì không tự sinh lại được. Đó là dữ liệu trong database, file website và file người dùng tải lên, cấu hình dịch vụ, chứng chỉ, và danh sách việc chạy theo lịch.

Cách sao lưu database trên VPS

Database phải được dump bằng chính công cụ của nó để bản sao nhất quán: mysqldump cho MySQL và MariaDB, pg_dump cho PostgreSQL. Chép thẳng thư mục dữ liệu khi database đang ghi có thể cho ra bản sao không khôi phục được.

MySQL, MariaDB: mysqldump

# 1. Tạo user MySQL riêng cho sao lưu, chỉ có quyền đọc cần thiết
sudo mysql -e "CREATE USER 'backup'@'localhost' IDENTIFIED BY 'MAT_KHAU_MANH';
GRANT SELECT, SHOW VIEW, TRIGGER, EVENT, PROCESS, LOCK TABLES ON *.* TO 'backup'@'localhost';"

# 2. Lưu thông tin đăng nhập vào file riêng thay vì gõ mật khẩu trong lệnh
sudo nano /root/.my.cnf
#   [client]
#   user=backup
#   password=MAT_KHAU_MANH
sudo chmod 600 /root/.my.cnf

# 3. Dump tất cả database, nén lại. Cả lệnh chạy bằng root (sudo sh -c) vì /var/backups thuộc root;
#    umask 077 để chỉ root đọc được file dump
sudo mkdir -p /var/backups/vps
sudo sh -c 'umask 077; mysqldump --single-transaction --routines --events --all-databases | gzip > /var/backups/vps/db-$(date +%F).sql.gz'

Theo MySQL 8.4 Reference Manual, mysqldump cần quyền SELECT, SHOW VIEW, TRIGGER, và PROCESS khi không dùng --no-tablespaces; tùy chọn --events cần thêm quyền EVENT. Lệnh sudo mysqldump … > file sẽ báo “Permission denied” khi bạn dùng user sudo, vì phép > chạy bằng user hiện tại chứ không phải root. Vì vậy cả lệnh được bọc trong sudo sh -c.

• --single-transaction cho bản dump nhất quán mà không khóa ứng dụng, nhưng chỉ với bảng InnoDB; bảng MyISAM vẫn có thể thay đổi trong lúc dump (MySQL 8.4 Reference Manual).
• Với --all-databases, MySQL 8.4 không tự kèm stored routine và event, nên cần thêm --routines --events.
• Trên MariaDB, lệnh tương đương là mariadb-dump; tên mysqldump vẫn dùng được trên các bản phổ biến. Trên MariaDB hoặc MySQL cài từ kho Ubuntu, root đăng nhập qua socket, nên có thể bỏ user backup và file .my.cnf, chạy script bằng root.
• MySQL ghi rõ mysqldump không dành cho dữ liệu rất lớn. Database cỡ hàng chục GB nên cân nhắc sao lưu vật lý, ví dụ full backup và restore với Mariabackup.

PostgreSQL: pg_dump

# Dump một database ở định dạng custom (đã nén, khôi phục bằng pg_restore).
# Phép > chạy bằng root nhờ sudo sh -c, nên ghi được vào /var/backups/vps
sudo sh -c 'umask 077; sudo -u postgres pg_dump -Fc tendb > /var/backups/vps/tendb-$(date +%F).dump'

# pg_dump không kèm role (user) và tablespace: sao lưu riêng bằng pg_dumpall --globals-only
sudo sh -c 'umask 077; sudo -u postgres pg_dumpall --globals-only > /var/backups/vps/pg-globals-$(date +%F).sql'

Tài liệu PostgreSQL cho biết pg_dump tạo bản xuất nhất quán ngay cả khi database đang được dùng, và không chặn người đọc, người ghi khác. Mỗi lần lệnh chỉ dump một database; các đối tượng dùng chung như role và tablespace phải lấy bằng pg_dumpall --globals-only (PostgreSQL docs).

Cách đưa bản sao lưu ra ngoài VPS bằng rsync và rclone

Một bản sao lưu chỉ nằm trên chính VPS sẽ mất cùng VPS. Hai công cụ phổ biến để đưa nó ra ngoài là rsync và rclone. rsync chép qua SSH sang một máy chủ khác; rclone chép lên object storage hoặc dịch vụ lưu trữ đám mây như Google Drive, có thể mã hóa trước khi tải lên.

rsync sang máy chủ khác qua SSH

# Cách an toàn hơn: chạy TRÊN MÁY BACKUP để kéo dữ liệu từ VPS về
rsync -az -e ssh backup@IP_VPS:/var/backups/vps/ /backup/vps-tino/

# Hoặc đẩy từ VPS sang máy backup
sudo rsync -az /var/backups/vps/ backup@IP_MAY_BACKUP:/backup/vps-tino/

File sao lưu chỉ root đọc được (umask 077). Nếu muốn máy backup kéo dữ liệu về, hãy tạo trên VPS một user riêng, ví dụ backup, chỉ dùng để đọc bản sao lưu. Cấp quyền đọc thư mục cho user này bằng sudo chown -R root:backup /var/backups/vps và sudo chmod 750 /var/backups/vps, rồi đổi umask 077 thành umask 027 trong script.

Khi máy backup tự kéo dữ liệu về, VPS không cần giữ thông tin đăng nhập vào máy backup, nên dù VPS bị chiếm quyền thì bản sao vẫn an toàn. Kết nối dùng SSH key; xem cách kết nối VPS bằng SSH key. Không dùng tùy chọn --delete cho thư mục backup: file bị xóa hoặc bị mã hóa trên VPS sẽ bị xóa theo ở nơi lưu bản sao.

rclone lên object storage hoặc Google Drive

# Cài và khai báo nơi lưu (chạy theo hướng dẫn tương tác).
# Dùng sudo để cấu hình nằm trong tài khoản root, khớp với cron chạy bằng root ở phần sau
sudo apt install rclone
sudo rclone config

# Chép thư mục backup lên remote tên "kho" (thay bằng tên bạn đặt)
sudo rclone copy /var/backups/vps kho:vps-backup/$(hostname)

Khi rclone config hỏi xác thực Google Drive trên VPS không có trình duyệt, chọn không dùng auto config. Sau đó chạy rclone authorize "drive" trên máy tính của bạn theo hướng dẫn của rclone, rồi dán kết quả vào VPS.

Remote kiểu crypt của rclone tự mã hóa trước khi tải lên và giải mã khi tải về (rclone docs). Hãy lưu mật khẩu mã hóa ở một nơi an toàn ngoài VPS: mất mật khẩu thì không đọc lại được bản sao. Bản Ubuntu có thể cài rclone cũ hơn bản trên trang chủ; nếu cần tính năng mới, cài theo hướng dẫn của rclone.

Đặt lịch sao lưu tự động bằng cron

Sao lưu chỉ có ích khi chạy đều mà không cần nhớ. Gom các lệnh ở trên vào một script và cho cron chạy vào giờ ít truy cập. Script nên ghi log để biết lần chạy nào lỗi, và tự xóa bản cũ trên VPS để không đầy ổ cứng. Script mẫu cho VPS Ubuntu chạy MySQL hoặc MariaDB:

#!/usr/bin/env bash
# /usr/local/bin/backup-vps.sh
set -euo pipefail
umask 077   # chỉ root đọc được bản sao lưu
NGAY=$(date +%F_%H%M)
DICH=/var/backups/vps
mkdir -p "$DICH"

# 1. Database (thông tin đăng nhập lấy từ /root/.my.cnf)
mysqldump --single-transaction --routines --events --all-databases | gzip > "$DICH/db-$NGAY.sql.gz"

# 2. File website, cấu hình, chứng chỉ
# tar trả mã 1 khi file thay đổi lúc đang đọc (website đang có upload): chấp nhận mã này
tar --warning=no-file-changed -czf "$DICH/files-$NGAY.tar.gz" /var/www /etc/nginx /etc/letsencrypt || [ $? -eq 1 ]

# 3. Đẩy ra ngoài VPS
rclone copy "$DICH" kho:vps-backup/$(hostname)

# 4. Xoá bản cũ hơn khoảng 7 ngày trên VPS
find "$DICH" -type f -mtime +7 -delete

# Cấp quyền và thêm lịch chạy lúc 2:30 sáng mỗi ngày
sudo chmod 700 /usr/local/bin/backup-vps.sh
sudo crontab -e

# Thêm dòng sau vào crontab của root
30 2 * * * /usr/local/bin/backup-vps.sh >> /var/log/backup-vps.log 2>&1

Cú pháp năm trường thời gian của cron được giải thích trong bài crontab là gì. Script dùng set -euo pipefail để dừng ngay khi một lệnh lỗi. umask 077 giúp chỉ root đọc được bản sao lưu, vì file chứa toàn bộ dữ liệu và private key SSL. Hãy xem /var/log/backup-vps.log sau vài ngày đầu, hoặc gửi cảnh báo (email, Telegram) khi script kết thúc với lỗi. Thời gian giữ bản sao trên remote nên đặt ở phía nơi lưu (vòng đời đối tượng, versioning), không xóa từ VPS.

Kiểm thử khôi phục định kỳ

Một bản sao lưu chỉ đáng tin khi bạn đã từng khôi phục nó thành công. Định kỳ, ví dụ mỗi tháng và sau mỗi thay đổi lớn, hãy lấy một bản sao từ nơi lưu ngoài VPS. Khôi phục nó vào một VPS thử hoặc một database tạm, rồi kiểm tra website chạy được và dữ liệu đủ.

# Giải nén file vào thư mục tạm để kiểm tra
mkdir -p /tmp/thu-khoi-phuc && tar -xzf files-2026-10-19_0230.tar.gz -C /tmp/thu-khoi-phuc

# MySQL/MariaDB: nạp bản dump vào MÁY THỬ (bản --all-databases sẽ ghi đè database cùng tên)
gunzip < db-2026-10-19_0230.sql.gz | mysql

# PostgreSQL: khôi phục vào database tạm
sudo -u postgres createdb tendb_thu
sudo -u postgres pg_restore -d tendb_thu tendb-2026-10-19.dump

• Ghi lại thời gian khôi phục: đó là thời gian website ngừng hoạt động thực tế khi có sự cố. Nếu quá lâu, cân nhắc giữ sẵn một VPS dự phòng.
• Kiểm tra bằng mắt: mở website qua file hosts trỏ về VPS thử, đăng nhập trang quản trị, xem đơn hàng hoặc bài viết mới nhất có mặt.
• Viết lại các bước khôi phục vào một tài liệu ngắn, để người khác trong nhóm làm được khi bạn không có mặt.

Backup của nhà cung cấp VPS: dùng thế nào, vì sao vẫn nên tự sao lưu

Nhiều nhà cung cấp có sẵn bản sao lưu tự động cho VPS. Các gói VPS NVMe tại Tino có sao lưu tự động; tần suất và số bản giữ lại xem trong mô tả gói hoặc hỏi bộ phận hỗ trợ (kiểm tra ngày 19/10/2026). Bản sao lưu này hữu ích khi cần đưa cả VPS về trạng thái trước đó, nhưng chỉ nên là một trong ba bản của quy tắc 3-2-1.

• Tần suất: bản sao lưu của nhà cung cấp chạy theo lịch cố định. Dữ liệu phát sinh giữa hai kỳ sao lưu (đơn hàng, bình luận, workflow) chỉ an toàn nếu bạn tự dump thêm với tần suất dày hơn.
• Phạm vi khôi phục: bản sao cả VPS thường khôi phục toàn bộ; muốn lấy lại một bảng dữ liệu hay một thư mục, bản dump và file nén của riêng bạn tiện hơn.
• Cùng một nhà cung cấp: bản sao nằm ngoài VPS nhưng vẫn trong hạ tầng của nhà cung cấp. Bản thứ ba ở nơi khác bảo vệ bạn cả khi tài khoản dịch vụ gặp sự cố hoặc dịch vụ hết hạn.
• Trách nhiệm: với VPS không quản lý, việc dữ liệu có nhất quán và khôi phục được hay không là phần việc của bạn.

Tại Tino, bản sao lưu của gói (nếu gói có hỗ trợ) nằm trong tab Backups của trang quản lý dịch vụ: Quản lý dịch vụ → Cloud Computing → chọn VPS. Các bước có ảnh trong bài hướng dẫn truy cập và lấy thông tin VPS. Trước khi cần dùng, hãy xem tab này đang có những bản nào và cách khôi phục, hoặc hỏi bộ phận hỗ trợ kỹ thuật. Bài {a(“backup-va-restore-la-gi”, “backup và restore là gì”)} giải thích thêm về hệ thống sao lưu của Tino.

Cách khôi phục VPS khi gặp sự cố

Khi VPS gặp sự cố, việc đầu tiên là xác định phạm vi: chỉ mất một ít dữ liệu, hỏng cấu hình, hay cả VPS không khởi động được hoặc đã bị xâm nhập. Phạm vi quyết định bạn khôi phục từ bản nào và khôi phục vào đâu, tránh ghi đè nhầm lên dữ liệu còn tốt.

• Mất hoặc sai một phần dữ liệu: khôi phục database hoặc thư mục cần thiết từ bản dump gần nhất, giữ nguyên VPS.
• Hỏng sau khi nâng cấp hoặc sửa cấu hình: quay về snapshot chụp trước đó, hoặc khôi phục file cấu hình từ bản sao.
• VPS hỏng nặng: khôi phục cả VPS từ bản sao lưu của gói nếu có. Nếu không, cài lại hệ điều hành cho VPS (thao tác này xóa sạch dữ liệu hiện có). Sau đó cài lại phần mềm, rồi khôi phục cấu hình, file và database từ bản sao ngoài VPS.
• Bị xâm nhập: không khôi phục đè lên hệ thống đang bị chiếm quyền. Dựng VPS sạch, chọn bản sao từ trước thời điểm bị xâm nhập, đổi toàn bộ mật khẩu, SSH key và API key, rồi rà lại các bước bảo mật VPS.

Khi nào chưa cần tự dựng hệ thống backup?

Không phải VPS nào cũng cần script sao lưu riêng. Nếu mọi thứ trên VPS đều tạo lại được từ nơi khác trong thời gian chấp nhận được, bản sao lưu của nhà cung cấp cộng với mã nguồn trên Git là đủ.

• VPS thử nghiệm, học tập: mất dữ liệu cũng không ảnh hưởng ai.
• Ứng dụng không lưu trạng thái: mã nguồn nằm trên Git, cấu hình dựng bằng script, dữ liệu nằm ở một database đã được sao lưu riêng ở nơi khác.
• Dùng control panel có sẵn sao lưu ra ngoài: khi đó việc cần làm là bật tính năng đó, trỏ về nơi lưu ngoài VPS và thử khôi phục, không cần viết script riêng.

Nếu website hoặc ứng dụng có dữ liệu phát sinh hằng ngày, hãy dựng ít nhất bản dump database hằng ngày ra ngoài VPS. Tìm hiểu thêm về VPS trong bài VPS là gì.

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

Nguồn tham khảo

• Department for Education (UK) Cyber Security Hub: The 3-2-1 backup strategy (truy cập 19/10/2026)
• MySQL 8.4 Reference Manual: mysqldump (truy cập 19/10/2026)
• PostgreSQL documentation: pg_dump (truy cập 19/10/2026)
• rsync manual (truy cập 19/10/2026)
• rclone: Crypt (truy cập 19/10/2026)
• Microsoft Learn: wbadmin (truy cập 19/10/2026)
• Tino: bảng giá VPS NVMe (truy cập 19/10/2026)