Hướng dẫn tạo Snapshot VPS chuẩn chỉnh, giữ tính nhất quán dữ liệu Database, thực chiến Restore A-B-A trên CloudFly và phân biệt rõ với Backup độc lập.
localhost.vnBiên tập kỹ thuật · localhost.vn
Bảo mật & Sao lưu // localhost.vn
Snapshot chưa bao giờ là chiếc đũa thần nếu bạn chưa từng thử Restore: luôn tắt dịch vụ ghi đĩa hoặc tắt máy trước khi chụp để giữ Database nhất quán, và đừng quên kết hợp Backup độc lập ngoài VPS.
Snapshot VPS giống như nút “Quick Save” trước khi bước vào trận đánh trùm trong game: nó lưu lại trạng thái ổ đĩa của Cloud Server để bạn có đường lùi nếu lỡ tay gõ nhầm lệnh hoặc nâng cấp cấu hình bị lỗi. Nhưng có một sự thật hơi phũ phàng mà dân kỹ thuật từng trải đều thấm: nhìn thấy dòng chữ ACTIVE xanh mướt trên danh sách Snapshot chưa có nghĩa là bạn sẽ khôi phục (Restore) thành công đúng thứ mình cần. Trước khi bấm nút tạo bản Snapshot đầu tiên, anh em cần nắm rõ phạm vi dữ liệu được chụp, cách đảm bảo tính nhất quán (Data Consistency) của Database và những tác động thực tế khi chạy lệnh phục hồi.
Bài viết này kết hợp tài liệu chính thức của CloudFly, hình ảnh thực tế khi tạo Snapshot trên máy chủ thử nghiệm LAB-CF-02 ngày 30/09/2026, cùng màn diễn tập Restore Snapshot mới vào ngày 02/10/2026. Trong đợt diễn tập ngày 02/10, chúng tôi đã chủ động thay đổi cả file lẫn bài viết WordPress từ trạng thái A sang trạng thái B, sau đó chạy Restore để chứng minh hệ thống thực sự đưa toàn bộ dữ liệu về lại mốc A ban đầu. Máy chủ LAB-CF-01 ở các bài trước không tạo Snapshot; hai mốc thời gian của LAB-CF-02 được ghi chép tách bạch để bạn không nhầm lẫn giữa ảnh chụp bản Snapshot cũ với bản thực sự được mang ra phục hồi.
Sơ đồ tư duy kỹ thuật do localhost.vn biên soạn nhằm minh họa quy trình vận hành chuẩn.
Có một lỗi kinh điển mà nhiều anh em mới quản trị VPS hay mắc phải: cứ thế bấm chụp Snapshot ngay khi MySQL/MariaDB đang hì hục ghi dữ liệu. Chụp nóng kiểu đó rất dễ biến Database thành một bức ảnh bị nhòe vì hiệu ứng “half-written transactions”. Để loại bỏ rủi ro dữ liệu đang ghi dở dang xuống đĩa, trước khi bấm tạo Snapshot, đội ngũ localhost.vn đã chủ động dừng cả ba dịch vụ NGINX, PHP-FPM và MariaDB trên VPS lab, sau đó gõ lệnh sync để ép toàn bộ bộ đệm (buffer cache) trong RAM xả hết xuống ổ cứng. Tại thời điểm mở biểu mẫu Snapshots → Thêm mới, giao diện hiển thị mức phí là 0đ/GB/giờ. Tuy nhiên, đây chỉ là con số ghi nhận trên tài khoản tại đúng thời điểm thực nghiệm; nguyên tắc sống còn liên quan đến Billing là mỗi lần bấm tạo tài nguyên, bạn đều phải nhìn lại bảng giá hiện hành.
Bản Snapshot được khởi tạo lúc 21:35 ngày 30/09/2026 với tên bắt đầu bằng localhost-lab-cf02-before-change. Ảnh chụp màn hình thực tế này xác nhận hệ thống đã tạo ảnh đĩa thành công (dung lượng 3.04 GB trên ổ tối thiểu 40 GB), nhưng ở thời điểm đó chưa thực hiện bước Restore. Các thông số gốc được giữ nguyên và chỉ đóng dấu logo ở chân ảnh.
Ngay khi bảng điều khiển (Panel) chuyển trạng thái bản chụp sang ACTIVE, chúng tôi khởi động lại ba dịch vụ web/database và kiểm tra phản hồi HTTPS trên trang lab thấy trả về mã HTTP 200 ngon lành. Bản chụp ngày 30/09 này được giữ nguyên làm mốc tham chiếu, còn màn thử nghiệm khôi phục dữ liệu vào ngày 02/10 bên dưới sẽ sử dụng một bản Snapshot mới tinh. Một lưu ý cực kỳ quan trọng khi quản lý chi phí Cloud Server: bạn bắt buộc phải ghi tên các bản Snapshot vào danh sách tài nguyên cần dọn dẹp, bởi vì việc xóa VPS hoàn toàn không đồng nghĩa với việc hệ thống tự động xóa luôn các bản Snapshot đi kèm.
Trước khi tạo một bản chụp, hãy viết rõ ra giấy (hoặc vào file ghi chú vận hành) mục tiêu của bạn: bạn muốn đưa máy chủ về lại trạng thái nào? Ví dụ điển hình nhất là lưu lại trạng thái VPS ổn định ngay trước khi nâng cấp phiên bản PHP, chỉnh sửa cấu hình NGINX phức tạp hoặc cài đặt một plugin WordPress có nguy cơ xung đột cao. Hãy ghi kèm phiên bản hệ điều hành (OS), phiên bản ứng dụng và trạng thái dữ liệu hiện có. Nếu không xác định rõ cột mốc cần bảo vệ, lúc xảy ra sự cố bạn sẽ không biết bản Snapshot đó có chứa đủ những mảnh ghép mình cần khôi phục hay không.
Đừng ngại đặt câu hỏi với nhà cung cấp Cloud Server: Snapshot của họ bao gồm những ổ đĩa nào (chỉ ổ cài hệ điều hành hay cả ổ Block Storage gắn thêm)? Có lưu trạng thái RAM không? Dung lượng tính phí Billing được đo lường ra sao và bản chụp có bị phụ thuộc vào vòng đời của Instance gốc hay không? Đừng bao giờ mặc định rằng mọi nhà cung cấp đều chụp trọn gói toàn bộ trạng thái đang chạy của máy chủ. Các phân vùng ổ đĩa gắn ngoài, dịch vụ Object Storage (như S3) hoặc cụm Database nằm ở một server độc lập luôn cần phương án sao lưu riêng biệt.
Đối với một website WordPress, thư mục mã nguồn (wp-content) và cơ sở dữ liệu MariaDB/MySQL phải khớp nhau ở cùng một tích tắc thời gian. Chụp ảnh đĩa (Disk Snapshot) khi hệ thống vẫn đang mở cho khách truy cập đặt hàng hoặc bình luận có thể gây lệch pha giữa file trên đĩa và các bảng trong Database. Một website vẫn mở lên được trang chủ sau khi Restore chưa đủ để chứng minh rằng các bảng dữ liệu bên trong hoàn toàn nhất quán và không bị lỗi hỏng ngầm (corruption).
Nếu bạn là người mới đang từng bước làm quen với hạ tầng máy chủ, hãy bám sát lộ trình cài đặt WordPress trên VPS từ A đến Z để chuẩn bị một môi trường lab tách biệt và thiết lập kết nối SSH chuẩn chỉnh trước khi bắt đầu nghịch tính năng Snapshot.
Hãy chọn đúng chiếc VPS thử nghiệm không chứa bất kỳ dữ liệu khách hàng thật nào, ghi chép lại tên Instance, ID định danh và hạn mức ngân sách cho phép. Tiếp theo, hãy rà soát quyền hạn của tài khoản trên Panel (quyền tạo Snapshot, quyền chạy Restore), biểu phí lưu trữ theo GB cũng như quy định xóa bản chụp. Nếu quy trình Restore của bạn là khởi tạo một Cloud Server mới từ bản Snapshot thay vì ghi đè lên máy cũ, đừng quên cộng thêm chi phí thuê chiếc VPS mới đó vào hóa đơn. Việc giao diện Cloud cung cấp một nút bấm cực kỳ tiện lợi không có nghĩa là ngân sách dự án của bạn tự động được phép phình to.
Hãy chuẩn bị sẵn phương án truy cập độc lập và bộ dữ liệu mẫu không nhạy cảm. Khi tạo file đánh dấu để kiểm chứng, hãy viết nội dung thật rõ ràng kèm theo mã băm (checksum SHA-256) để lát nữa đối chiếu một phát ăn ngay. Nếu thử nghiệm trên ứng dụng web như WordPress, chỉ sử dụng dữ liệu mẫu và nhớ ngắt toàn bộ các kết nối gửi ra bên ngoài như SMTP gửi email thật, cổng thanh toán hay Webhook để tránh việc sau khi Restore, hệ thống lại tự động bắn thông báo nhầm cho người dùng.
Trong trường hợp quy trình đảm bảo tính nhất quán dữ liệu yêu cầu phải dừng dịch vụ web hoặc tắt hẳn VPS (Stop Instance), hãy lên lịch thời gian bảo trì đàng hoàng. Các thao tác trong bài viết này được thực hiện trên môi trường lab độc lập; với hệ thống Production đang chạy thật, tuyệt đối không làm theo kiểu hứng lên là gõ lệnh tắt máy giữa ban ngày khi chưa thông báo cửa sổ bảo trì (Maintenance Window).
Hướng dẫn sử dụng Snapshots thủ công của CloudFly mô tả rất rõ luồng đi: truy cập vào trang quản lý máy chủ, chuyển sang tab Snapshots, chọn tạo bản chụp mới, đặt tên định danh dễ nhớ rồi bấm lưu. Tài liệu này cũng hướng dẫn hai cách sử dụng bản chụp: hoặc khôi phục đè trực tiếp lên máy chủ hiện tại từ danh sách, hoặc dùng bản chụp đó như một Image để khởi tạo một VPS mới tinh. Đặc biệt, chính nhà cung cấp cũng nhấn mạnh phạm vi phục hồi là toàn bộ ổ đĩa máy chủ và khuyến nghị người dùng nên tắt máy (Stop VPS) trước khi chụp Snapshot thủ công để dữ liệu an toàn nhất.
Một kinh nghiệm xương máu khi đọc tài liệu kỹ thuật: giao diện bảng điều khiển năm 2026 bạn đang nhìn thấy có thể đã đổi tên vài nút bấm so với bài hướng dẫn viết từ năm 2023. Vì vậy, trước khi click chuột, hãy luôn đối chiếu kỹ tên Instance, đơn giá hiển thị và đọc từng dòng chữ cảnh báo màu đỏ trên màn hình. Nếu thấy giao diện khác lạ hoặc chưa hiểu rõ điều kiện ghi đè, hãy dừng tay ngay lập tức để hỏi bộ phận hỗ trợ, tuyệt đối không chơi trò “bấm thử xem sao” trên máy chủ Production.
Ngoài ra, trong các tài liệu cũ có nhắc tới tính năng tự động sao lưu hàng tuần, nhưng thông tin đó không đủ để bạn mặc định rằng gói cước mình đang thuê đã bao gồm sẵn Auto Backup miễn phí. Thực tế trên biểu mẫu khởi tạo máy chủ LAB-CF-01 ngày 30/09/2026 đã hiển thị rõ tùy chọn Backup tự động là một dịch vụ cộng thêm có tính phí riêng. Hãy luôn phân biệt rạch ròi giữa Snapshot thủ công và gói Backup tự động theo đúng cấu hình bạn đăng ký.
Đừng bao giờ đặt tên Snapshot kiểu test1, backup-final hay truoc-khi-sua-ok-chac-chan. Lúc 2 giờ sáng web sập, nhìn vào một rừng những cái tên vô hồn đó bạn sẽ toát mồ hôi hột. Hãy đặt tên theo cấu trúc thể hiện rõ: tên máy chủ nguồn + cột mốc thời gian + thay đổi chuẩn bị thực hiện (ví dụ: lab-cf02-before-php83-upgrade-261002). Tuyệt đối không nhét mật khẩu, API Token hay thông tin nhạy cảm của khách hàng vào chuỗi tên Snapshot. Thời gian chi tiết kèm múi giờ (như UTC+7) nên được ghi vào sổ tay vận hành để tra cứu chéo.
Sau khi bấm gửi yêu cầu tạo Snapshot, đừng vội tắt trình duyệt đi pha cà phê ngay. Hãy kiên nhẫn chờ giao diện chuyển trạng thái từ đang xử lý sang hoàn tất (ACTIVE), sau đó ghi lại ID của bản chụp, thời điểm hoàn thành, dung lượng thực tế (GB) và chi phí dự kiến. Hệ thống báo “Đã tiếp nhận yêu cầu” hoàn toàn chưa đồng nghĩa với việc bản chụp đã tạo xong, giống hệt như lúc mới bấm nút tạo VPS thì phải đợi một lúc máy mới thực sự ACTIVE vậy.
Sơ đồ tư duy kỹ thuật do localhost.vn biên soạn nhằm minh họa sự khác biệt giữa tạo bản chụp và nghiệm thu phục hồi.
Trong giới SysAdmin có một câu châm ngôn bất hủ: “Một bản sao lưu chưa từng được thử phục hồi thì coi như chưa hề có bản sao lưu nào cả”. Trên môi trường lab, cách kiểm chứng thuyết phục nhất là thiết lập dữ liệu ở Mốc A trước khi chụp Snapshot, sau đó cố tình chỉnh sửa dữ liệu sang Mốc B, rồi kích hoạt lệnh Restore để xem toàn bộ máy chủ có quay về đúng trạng thái Mốc A hay không. Tất nhiên, bất kỳ file hay bài viết nào phát sinh sau thời điểm bấm chụp (tức thuộc về Mốc B) sẽ bị xóa sổ hoàn toàn khi quay về Mốc A. Bài tập thực hành này giúp bạn cảm nhận cực kỳ rõ rệt bản chất lưu trạng thái theo thời điểm (Point-in-time) của Snapshot khác với cơ chế đồng bộ liên tục (Replication) như thế nào.
Nếu dịch vụ Cloud hỗ trợ tạo VPS mới từ Snapshot và ngân sách thực hành cho phép, bạn nên khôi phục ra một Cloud Server độc lập để dễ dàng giữ lại máy gốc làm đối chứng. Còn nếu chọn phương án Restore đè trực tiếp lên chính chiếc VPS hiện tại, hãy nhớ xuất (Export) toàn bộ những dữ liệu phát sinh sau thời điểm chụp mà bạn vẫn còn cần dùng ra máy cá nhân trước khi bấm nút.
Khi quá trình Restore hoàn tất và máy chủ khởi động lại, đừng chỉ nhìn mỗi đèn xanh trên Panel. Hãy SSH vào kiểm tra phiên bản OS, nội dung file mẫu, phân quyền chmod/chown và trạng thái hoạt động của ứng dụng web. Máy chủ ping thông hoặc mở được cổng SSH chưa đảm bảo rằng dịch vụ MariaDB bên trong đã khởi chạy trơn tru mà không gặp lỗi bảng dữ liệu. Hãy bấm giờ và ghi chép riêng hai khoảng thời gian: thời gian chờ hạ tầng Cloud ghi đè ổ đĩa và thời gian bạn kiểm tra, đưa ứng dụng web hoạt động trở lại bình thường — tổng hai con số đó mới là thời gian gián đoạn thực tế (RTO).
Một chi tiết bảo mật cực kỳ quan trọng trước khi mở máy chủ vừa Restore ra Internet: hãy rà soát lại các khóa bí mật (SSH Key, API Token) và các tác vụ hẹn giờ (Cronjob) đi kèm trong bản chụp. Rất có thể ở thời điểm chụp Mốc A, bạn đang bật một Cronjob gửi email hàng loạt hoặc chứa một tài khoản tạm thời mà sau đó ở Mốc B bạn đã xóa đi; khi Restore về lại Mốc A, những thứ đó sẽ “sống dậy” nguyên xi!
Vào ngày 02/10/2026, đội ngũ localhost.vn đã tiến hành diễn tập khôi phục trực tiếp ngay trên chiếc VPS LAB-CF-02 mà không cần khởi tạo máy chủ thứ hai. Để đảm bảo an toàn tuyệt đối trước khi thực hiện thao tác ghi đè toàn bộ ổ đĩa, chúng tôi đã sao lưu trọn bộ mã nguồn và bản dump SQL của hai trang WordPress thử nghiệm về một thư mục bảo mật riêng trên máy Mac quản trị. Cả ba file nén (tổng dung lượng chính xác 252.814.012 byte) đều được đối chiếu mã băm SHA-256 khớp 100% giữa đầu gửi và đầu nhận; bên trong bản nén bao gồm cả file nhạy cảm wp-config.php. Vì gói dữ liệu này chứa thông tin xác thực của môi trường lab nên được lưu trữ nội bộ nghiêm ngặt, tuyệt đối không đưa lên thư mục công khai hay kho mã nguồn Git.
Đầu tiên, chúng tôi đăng một bài viết mới lên trang WordPress của lab với nội dung rõ ràng: “Mốc A — dữ liệu trước snapshot”, đồng thời tạo một file kiểm chứng nằm ngoài thư mục webroot cũng chứa đúng dòng chữ đó. Chúng tôi ghi nhận lại Post ID của bài viết, mã hash SHA-256 của file kiểm chứng và thiết lập phân quyền file ở mức 640. Trước khi tắt máy chủ, truy cập thử qua trình duyệt xác nhận trang WordPress trả về phản hồi HTTPS 200 mượt mà.
Ảnh chụp trình duyệt Chromium thực tế lúc 11:55:04 (giờ Việt Nam) ngay trước khi chụp Snapshot; giữ nguyên độ phân giải gốc và đính kèm logo localhost.vn. Bạn có thể bấm vào ảnh để phóng to từng chi tiết.
Đúng 11:55:29, chúng tôi thực hiện tắt máy chủ LAB02 một cách an toàn, sau đó bấm nút đồng bộ trạng thái trên bảng điều khiển CloudFly và đợi đến khi trạng thái chuyển hẳn sang STOPPED. Tiếp theo, vào mục Snapshots → Thêm mới, đặt một cái tên định danh riêng biệt và rà soát lại biểu phí trước khi bấm lưu. Ở thời điểm thực hành này, biểu mẫu vẫn hiển thị mức phí là 0đ/GB/giờ (như đã lưu ý, đây là mức giá quan sát thực tế lúc làm lab, anh em luôn phải tự xem lại bảng giá tại thời điểm mình sử dụng).
Bản Snapshot mới được đặt tên là localhost-lab-cf02-restore-proof-261002 (tên định danh nội bộ trên hệ thống kết thúc bằng đuôi 1790916969), ghi nhận thời gian khởi tạo lúc 11:56 ngày 02/10. Sau vài phút chờ hệ thống chuyển trạng thái từ queued / image uploading sang ACTIVE, bản chụp hoàn tất với dung lượng 6,44 GB trên yêu cầu ổ đĩa tối thiểu 40 GB. Xin lưu ý: đây là bản Snapshot mới hoàn toàn, tách biệt với bản chụp 3,04 GB ngày 30/09 ở phần đầu bài viết.
Sau khi bản Snapshot mới đã báo ACTIVE, chúng tôi bật lại máy chủ LAB02. Khi đã kết nối SSH thành công (với Host Fingerprint khớp chuẩn), xác nhận các dịch vụ chạy tốt và trang web trả về HTTPS bình thường, chúng tôi tiến hành sửa trực tiếp cùng bài viết WordPress đó và cùng file kiểm chứng đó sang nội dung mới: “Mốc B — thay đổi sau snapshot”. Bước này cực kỳ quan trọng trong mọi kịch bản diễn tập: nếu bạn không tạo ra một sự thay đổi rõ ràng sau khi chụp, thì lát nữa Restore xong thấy trang web vẫn như cũ, bạn sẽ chẳng thể nào biết được là lệnh Restore thực sự có tác dụng hay hệ thống chẳng làm gì cả!
Ảnh chụp thực tế lúc 11:59:56 (giờ Việt Nam) từ một phiên trình duyệt sạch (Incognito context mới tinh để tránh cache), phản hồi HTTPS 200. Nội dung đã chuyển sang Mốc B trên đúng Post ID và đường dẫn URL cũ.
Quay lại giao diện quản lý của CloudFly, tìm đến đúng dòng của bản Snapshot mới (localhost-lab-cf02-restore-proof-261002), mở menu thao tác và chọn Khôi phục máy chủ. Giao diện bảo vệ của CloudFly rất cẩn thận khi thiết kế quy trình xác nhận gồm 2 bước rõ ràng:
Chúng tôi chỉ gửi duy nhất một yêu cầu khôi phục vào lúc khoảng 12:01 (giờ Việt Nam), ngay sau đó trạng thái máy chủ trên Panel chuyển sang rebuild_spawning. Một lời khuyên chân thành cho anh em khi làm việc với hạ tầng Cloud: lúc hệ thống đang hì hục ghi đè ảnh đĩa mà thấy chưa SSH vào được ngay thì cứ bình tĩnh uống ngụm nước chờ đợi; đừng bao giờ sốt ruột bấm nút Restore liên tục nhiều lần kẻo gây treo tiến trình. Trong trường hợp hy hữu nếu quá trình phục hồi báo lỗi, hãy giữ nguyên hiện trạng bản Snapshot và các file backup ngoài máy để nhờ kỹ thuật nhà cung cấp kiểm tra, tuyệt đối không xóa bừa theo quán tính.
Đến đúng 12:03:14 (giờ Việt Nam) — tức chỉ hơn 2 phút sau khi bấm nút — cổng SSH đã mở trở lại và khớp hoàn toàn với khóa Host Key đã ghim từ trước; thông số boot_id mới tinh xác nhận máy chủ vừa thực hiện một chu kỳ khởi động lại thực sự. Khi mở file kiểm chứng ngoài webroot, nội dung đã quay trở về đúng chữ Mốc A cùng phân quyền mode 640 chuẩn chỉ; kiểm tra trong Database của bài viết WordPress cũng thấy nội dung đã lùi về Mốc A, xóa sạch dấu vết của Mốc B. Toàn bộ cấu hình hệ thống và danh sách tài khoản Linux đối chiếu đều nguyên vẹn. Các dịch vụ NGINX, PHP-FPM, MariaDB và SSH socket đều báo active; truy cập trang web qua HTTPS trả về mã 200 với chứng chỉ SSL/TLS hợp lệ. Một chi tiết rất thực tế: ngay giây đầu tiên vừa SSH vào được, dịch vụ MariaDB vẫn đang ở trạng thái activating (khởi chạy); người vận hành có kinh nghiệm sẽ luôn đợi thêm vài giây cho Database ổn định hoàn toàn rồi mới đưa ra kết luận nghiệm thu.
Ảnh chụp trình duyệt Chromium thực tế lúc 12:05:01 (giờ Việt Nam) sau khi hoàn tất Restore. Bài viết đã quay trở về đúng nội dung Mốc A như kỳ vọng. Đây là ảnh chụp mới hoàn toàn trên một phiên trình duyệt sạch không dính cache, tuyệt đối không dùng lại tấm ảnh lúc 11:55.
Ảnh chụp thực tế cùng đợt nghiệm thu ở kích thước màn hình di động (viewport 390px), hiển thị rõ ràng và không bị vỡ khung ngang.
Chưa dừng lại ở giao diện trang ngoài (Frontend), chúng tôi tiếp tục sử dụng tài khoản quản trị viên (Administrator) sẵn có của trang lab để đăng nhập vào /wp-admin/, mở trang tổng quan Dashboard kiểm tra rồi bấm đăng xuất (Logout). Thử truy cập lại đường dẫn /wp-admin/ ngay sau đó thấy hệ thống chuyển hướng chuẩn xác về màn hình yêu cầu đăng nhập, chứng tỏ cơ chế phiên làm việc (Session/Cookie) và Database hoạt động hoàn hảo sau khi Restore.
Ảnh chụp thực tế hộp thông tin (Widget) trong trang quản trị WordPress sau khi đăng nhập thành công: hiển thị đủ 3 bài viết (gồm bài diễn tập Snapshot và 2 bài lab có sẵn). Dòng chữ “Công cụ tìm kiếm bị chặn” là cấu hình chủ đích để tránh Google lập chỉ mục nhầm máy chủ thử nghiệm.
Sau khi hoàn tất mọi bước nghiệm thu, chúng tôi nạp lại bản SQL baseline ban đầu để xóa bài viết thử nghiệm, gỡ bỏ file đánh dấu ngoài webroot, đồng thời rà soát lại toàn bộ cấu hình và dịch vụ để trả chiếc VPS lab về trạng thái sạch sẽ như trước. Ba file nén backup tạm thời trên VPS và trên máy Mac quản trị cũng được xóa bỏ an toàn sau khi đã hoàn thành sứ mệnh bảo hiểm. Đặc biệt, bản Snapshot mới (6,44 GB) tạo ra trong ngày 02/10 đã được bấm xóa ngay trên Panel CloudFly; danh sách lúc này chỉ còn giữ lại bản chụp cũ ngày 30/09 (3,04 GB) và được ghi vào sổ theo dõi để xóa nốt khi kết thúc toàn bộ chuỗi bài học trên LAB-CF-02.
Màn thực chiến này đã chứng minh rõ ràng quy trình khôi phục thành công cả hệ thống file, cơ sở dữ liệu MariaDB lẫn hoạt động thực tế của ứng dụng WordPress trên một VPS lab. Tuy nhiên, với tư duy kỹ thuật trung thực, kết quả này không dùng để suy diễn rằng mọi loại ổ đĩa gắn ngoài, cơ sở dữ liệu tách rời hay mọi plugin phức tạp đều sẽ tự động chạy trơn tru 100% ở mọi hoàn cảnh. Các mốc thời gian vài phút ghi nhận ở trên là số liệu thực tế trên một VPS lab dung lượng nhỏ, không phải là cam kết SLA, RPO hay RTO cố định cho các hệ thống lớn hàng trăm Gigabyte.
Có không ít chủ website nghĩ rằng cứ bật Snapshot trên Cloud là kê cao gối ngủ ngon, chẳng cần thiết lập lịch sao lưu (Backup) ra ngoài làm gì cho tốn công. Đây là một sự nhầm lẫn cực kỳ nguy hiểm! Trước hết, Snapshot hoàn toàn không chứa bất kỳ dữ liệu nào phát sinh sau thời điểm bạn bấm chụp. Nếu website thương mại điện tử của bạn chụp Snapshot lúc nửa đêm, đến 11 giờ trưa hôm sau bị lỗi phải Restore về bản nửa đêm đó, thì toàn bộ đơn hàng của khách đặt trong suốt buổi sáng sẽ bốc hơi sạch sẽ.
Thứ hai, hãy nghĩ đến rủi ro tập trung (Single Point of Failure): nếu bản Snapshot nằm chung trong cùng một tài khoản quản trị hoặc cùng một cụm hạ tầng của nhà cung cấp với chiếc VPS gốc, chuyện gì sẽ xảy ra nếu bạn bị lộ mật khẩu tài khoản Cloud hoặc tài khoản bị khóa vì sự cố thanh toán? Lúc đó bạn mất quyền truy cập vào cả VPS lẫn bản Snapshot! Một bản Backup độc lập (Off-site Backup) — chẳng hạn nén file mã nguồn cộng file .sql rồi đẩy tự động sang một kho lưu trữ Object Storage khác nhà cung cấp hoặc tải về NAS nội bộ — mới là chiếc phao cứu sinh thực sự trước những thảm họa cấp độ tài khoản.
Cuối cùng, hãy luôn nhớ nguyên tắc quản lý vòng đời tài nguyên: khi bạn xóa một chiếc VPS (Instance), hãy lập tức kiểm tra tab Snapshots xem các bản chụp cũ có còn nằm lại đó và âm thầm trừ tiền hàng tháng hay không, hoặc ngược lại, có bị xóa chùm theo máy chủ làm mất đi bản lưu bạn định giữ lại hay không.
Sơ đồ tư duy kỹ thuật do localhost.vn biên soạn giúp phân biệt phạm vi bảo vệ của Snapshot và Backup độc lập.
| Hạng mục | Nội dung cần ghi chép rõ ràng |
|---|---|
| Máy chủ nguồn | Tên/ID của VPS lab và phạm vi ổ đĩa được chụp |
| Mốc dữ liệu (Mốc A) | Nội dung file mẫu, mã băm SHA-256 và bài viết WordPress trước khi chụp |
| Thông tin Snapshot | Tên bản chụp, ID hệ thống, thời điểm chuyển sang ACTIVE và dung lượng |
| Quá trình Restore | Môi trường đích (ghi đè hay tạo máy mới), giờ bấm nút và giờ hoàn tất |
| Kết quả nghiệm thu | Trạng thái file, Database, đăng nhập wp-admin, các dịch vụ hệ thống |
| Dọn dẹp (Cleanup) | Bản Snapshot tạm và các file sao lưu đã xóa, theo dõi Billing còn lại |
Hãy dùng chính những con số thực tế trên máy chủ của bạn để điền vào bảng nghiệm thu này (kịch bản A → B → A trên LAB-CF-02 ở trên chính là một mẫu tham khảo chuẩn). Nếu trong lúc diễn tập mà bước Restore gặp thất bại, hãy chụp lại màn hình thông báo lỗi và log hệ thống để mổ xẻ nguyên nhân. Nhớ kỹ nhé: mới chỉ tạo xong bản Snapshot thì chưa được phép tích xanh vào ô “Đã sẵn sàng khôi phục sau thảm họa” đâu!
Có cần phải chụp Snapshot trước mọi thay đổi nhỏ nhặt không? Không nhất thiết. Hãy cân nhắc dựa trên mức độ rủi ro của thao tác (ví dụ sửa một dòng CSS thì không cần, nhưng nâng cấp MariaDB hoặc chạy script sửa hàng loạt bảng dữ liệu thì bắt buộc phải chụp). Đồng thời hãy luôn theo dõi chi phí lưu trữ và đặt lịch xóa các bản chụp cũ (Retention Policy), tránh thói quen chụp vô tội vạ rồi bỏ quên.
Đã có Snapshot trên Cloud rồi thì có được tắt tính năng Backup ra ngoài máy chủ không? Tuyệt đối không nên, trừ khi bạn đã chứng minh được kế hoạch bảo vệ dữ liệu hiện tại đáp ứng đủ mọi kịch bản rủi ro (bao gồm cả rủi ro mất quyền truy cập tài khoản Cloud hoặc cần trích xuất lẻ một bảng dữ liệu mà không muốn quay ngược thời gian toàn bộ máy chủ).
Bài viết này đã thực sự chạy Restore Snapshot trên CloudFly chưa? Đã thực hiện đầy đủ! Chúng tôi đã tạo bản chụp đầu tiên vào ngày 30/09/2026 và thực hiện trọn vẹn quy trình tạo mới kèm Restore kịch bản A → B → A vào ngày 02/10/2026 ngay trên VPS LAB-CF-02. Cả file hệ thống lẫn bài viết WordPress đều quay về đúng Mốc A, các dịch vụ NGINX/PHP-FPM/MariaDB, chứng chỉ TLS và chức năng đăng nhập quản trị đều hoạt động chuẩn xác.
Ở bài tiếp theo trong chuỗi cẩm nang này, chúng ta sẽ cùng tìm hiểu cách kiểm tra cấu hình phần cứng VPS bằng công cụ dòng lệnh (Linux CLI). Và khi hoàn tất toàn bộ quá trình học tập, bạn đừng quên áp dụng bảng danh sách rà soát xóa máy chủ thử nghiệm để dọn sạch cả Snapshot lẫn các tài nguyên phụ đi kèm nhé.
Bài viết đã đối chiếu trực tiếp với hướng dẫn sử dụng Snapshots thủ công chính thức của CloudFly vào ngày 02/10/2026. Do tài liệu gốc được xuất bản từ năm 2023, toàn bộ tên nút bấm, quy trình cảnh báo xác nhận 2 bước và mức giá hiển thị trong đợt diễn tập ngày 02/10 đều được chúng tôi ghi nhận trực tiếp trên giao diện Panel thực tế của máy chủ lab, kết hợp kiểm chứng độc lập qua SSH và trình duyệt Chromium.
Mọi hướng dẫn đều dựa trên số liệu đo đạc, log thực tế và nguyên tắc "luôn có đường lùi (Snapshot/Backup) trước khi gõ lệnh".
Nguyên tắc biên tập & Minh bạch ↗Bấm update plugin xong giao diện vỡ toang? Bình tĩnh khoanh vùng sự cố, bảo toàn đơn hàng mới và chọn đúng giữa Rollback hay tung bản Hotfix tại chỗ.
Checklist nhận bàn giao VPS WordPress: rà soát user sudoers, đối chiếu SSH Key trong authorized_keys, kiểm tra Port và thu hồi khóa cũ an toàn.
Quy trình cập nhật WordPress Core, Plugin, Theme và Ubuntu OS theo từng bước cô lập: kiểm tra tương thích, chốt Backup và xử lý Rollback an toàn.
Chào bạn! Web đang dính mã độc, tự nhảy trang lạ hay chạy ì ạch? Chọn nhanh triệu chứng bên dưới — hệ thống sẽ tự động chép sẵn phiếu khám và mở thẳng khung chat Zalo kỹ thuật cho bạn.
Nếu bạn đang ngồi máy tính chưa cài Zalo PC, hãy mở ứng dụng Zalo trên điện thoại và quét mã này để chat trực tiếp với kỹ thuật viên.
Hoặc mở zalo.me/0985840593
