Phục Hồi 2 Máy Ảo MISA Bị Xóa Nhầm Trên VMware ESXi RAID 10 SSD – Kết Quả Là Nhận Về Niềm Vui Trọn Vẹn

Chỉ một thao tác nhầm trên màn hình quản trị VMware ESXi, hai máy ảo chứa toàn bộ phần mềm kế toán MISA của công ty biến mất khỏi danh sách. Không phải hỏng ổ, không phải virus — chúng bị xóa, và không có bản backup nào để quay lại.

Với một server ảo hóa, “xóa máy ảo” nghĩa là cả hệ điều hành, phần mềm và dữ liệu kế toán nằm gọn trong vài file .vmdk — mất file là mất tất cả. Đây là nhật ký cách chúng tôi dựng lại trọn vẹn 2 máy ảo đó từ datastore RAID 10, và điều bạn cần làm ngay khi lỡ tay xóa nhầm trên ESXi.

Tóm Tắt Nhanh

Bối Cảnh và Nhu Cầu Dữ Liệu

Hệ thống máy chủ được tiếp nhận ngày 11/06/2026 lúc 15:18 tại Công ty Khôi Phục Dữ Liệu Võ Nguyễn, 201B Hoàng Văn Thụ, P. Phú Nhuận, TP.HCM. 4 ổ SSD enterprise 2.5″ đến trong khay server (hard drive tray) được đánh số thứ tự 1, 2, 3, 4 để đảm bảo không hoán đổi vị trí.

Đây là hệ thống máy chủ của một doanh nghiệp đang sử dụng phần mềm kế toán MISA — bộ phần mềm quản lý tài chính doanh nghiệp phổ biến tại Việt Nam. Hệ thống được triển khai dưới dạng máy ảo (Virtual Machine) chạy trên VMware ESXi, gồm 2 máy ảo riêng biệt:

• Misa Internal — phục vụ kế toán nội bộ doanh nghiệp
• Misa Tax — phục vụ khai báo và quản lý thuế

Cả hai máy ảo đều đang được sử dụng tích cực trong hoạt động tài chính hàng ngày của doanh nghiệp. Không có bản sao lưu (backup) nào cho cả hai máy ảo này.

Mục tiêu ưu tiên của khách hàng: phục hồi file máy ảo (.vmdk và các file liên quan) đủ để chạy lại được máy ảo — không chỉ trích xuất dữ liệu thô mà cần phục hồi nguyên trạng để máy ảo hoạt động được như trước.

Tình Trạng Ban Đầu

Biểu hiện người dùng quan sát được

• Trong quá trình quản trị hệ thống trên VMware ESXi, 2 máy ảo Misa Internal và Misa Tax bị xóa nhầm khỏi datastore
• Giao diện VMware ESXi không còn hiển thị 2 máy ảo này
• Phần mềm MISA không truy cập được — toàn bộ dữ liệu kế toán không thể sử dụng
• Không có snapshot để rollback, không có backup để restore

Tình trạng kỹ thuật sau khi đánh giá

• RAID 10 trên 4 ổ SSD còn nguyên vẹn, không có sự cố phần cứng
• Datastore VMFS vẫn còn — lỗi xảy ra ở tầng logic (VM bị xóa), không phải tầng vật lý
• Các file VMDK và thư mục VM bị xóa khỏi VMFS nhưng có khả năng không gian lưu trữ chưa bị ghi đè
• Các VM khác trên cùng datastore vẫn hoạt động bình thường

Rủi Ro Nếu Tiếp Tục Xử Lý Sai

Tiếp tục chạy hệ thống VMware ESXi sau khi xóa nhầm: Khi các VM khác trên cùng datastore tiếp tục hoạt động — ghi log, snapshot, swap file — chúng có thể ghi đè lên đúng vùng không gian mà Misa Internal và Misa Tax vừa giải phóng. Mỗi giờ hệ thống tiếp tục chạy sau khi xóa nhầm là một giờ tăng nguy cơ mất vĩnh viễn.

Tự dùng phần mềm phổ thông quét trực tiếp trên datastore: Cài đặt và chạy phần mềm phục hồi ngay trên hệ thống đang sống (live system) tạo thêm hoạt động ghi vào datastore, tăng nguy cơ ghi đè. Với VMFS trên RAID, phần mềm thông thường không hiểu cấu trúc VMFS và có thể trả về kết quả không đáng tin cậy.

Tạo máy ảo mới hoặc datastore mới trên cùng storage: Một số admin phản xạ tạo VM mới để “thử lại từ đầu” — hành động này phân bổ ngay không gian mới trên datastore, có thể ghi đè trực tiếp lên file VMDK đã xóa. Đây là thao tác không thể đảo ngược.

Rebuild RAID hoặc thay đổi cấu hình RAID: Nếu ai đó quyết định rebuild RAID vì lo ngại phần cứng — dù RAID hoàn toàn bình thường — quá trình rebuild ghi lại toàn bộ parity và có thể làm mất cấu trúc dữ liệu đã tồn tại.

Tắt nguồn hệ thống đột ngột không đúng cách: VMware ESXi khi bị tắt nguồn đột ngột có thể kích hoạt quá trình journal replay trên VMFS khi khởi động lại, làm thay đổi metadata và gây khó khăn thêm cho quá trình phục hồi.

Trong ca này: Khách hàng liên hệ ngay khi phát hiện xóa nhầm và không tự thực hiện thêm thao tác nào trên storage — đây là yếu tố then chốt giúp phục hồi thành công 100%.

Nguyên Nhân Sự Cố

Giải thích dễ hiểu

VMware ESXi là hệ thống cho phép chạy nhiều “máy tính ảo” (máy ảo / VM) trên một máy chủ vật lý duy nhất. Mỗi máy ảo được lưu trữ dưới dạng một tập hợp file trong thư mục riêng trên khu vực lưu trữ gọi là datastore.

Khi một quản trị viên thực hiện thao tác “xóa máy ảo” trên giao diện ESXi, hệ thống sẽ xóa thư mục của VM đó khỏi datastore — bao gồm file cài đặt hệ điều hành, dữ liệu và cấu hình máy ảo. Nếu chọn tùy chọn “Delete from Disk” (xóa khỏi ổ cứng), các file thực sự bị đánh dấu xóa trong hệ thống file VMFS.

Tuy nhiên — giống như khi xóa file trong Windows — dữ liệu thực tế không bị xóa ngay lập tức khỏi đĩa vật lý. Không gian chỉ bị “đánh dấu là trống” và sẵn sàng cho dữ liệu mới. Chừng nào dữ liệu mới chưa ghi đè lên vùng đó, cơ hội phục hồi vẫn còn.

Phân tích kỹ thuật

Hệ thống sử dụng RAID 10 (mirror + stripe) trên 4 ổ SSD 2TB — cung cấp 4TB usable với hiệu năng cao và khả năng chịu lỗi tối đa 1 ổ trong mỗi cặp mirror. RAID 10 không phải cơ chế backup — nó bảo vệ khỏi lỗi phần cứng, không bảo vệ khỏi xóa nhầm dữ liệu.

Datastore VMFS (VMware File System) là hệ thống file chuyên dụng của VMware, tối ưu cho môi trường ảo hóa với block size lớn. Khi VM bị xóa trên VMFS, hệ thống cập nhật metadata (xóa directory entry, giải phóng block allocation bitmap) nhưng không zero-fill dữ liệu thực tế.

Cơ hội phục hồi dựa trên:

• VMFS metadata vẫn có thể chứa thông tin về vị trí cũ của các block VMDK
• Các block dữ liệu VMDK chưa bị ghi đè bởi VM khác
• Cấu trúc nội bộ VMDK (geometry, filesystem Windows bên trong) còn nguyên vẹn

Thách thức kỹ thuật:

• VMFS trên RAID 10 yêu cầu hiểu đồng thời cả cấu trúc RAID (disk order, stripe size) và cấu trúc VMFS (block map, metadata)
• VMDK của MISA có thể có nhiều extent (file vmdk lớn chia thành nhiều phần)
• Cần đảm bảo file VMDK phục hồi đủ tính toàn vẹn để khởi động lại máy ảo — không chỉ trích xuất dữ liệu thô

Cây Giả Thuyết Chẩn Đoán

Quy Trình Phân Tích

Giai đoạn 1 – Tiếp nhận, kiểm kê và bảo toàn

4 ổ SSD được tiếp nhận trong khay server, đánh số 1–4 từ trước. Ưu tiên đầu tiên: không cấp nguồn hoặc gắn lại vào hệ thống gốc trước khi đánh giá.

Kiểm kê: xác nhận đủ 4 ổ, số thứ tự nguyên vẹn, không ổ nào bị hoán đổi trong quá trình vận chuyển.

Bước tiếp theo ngay lập tức: tạo image (bản sao bit-for-bit) của từng ổ SSD trước khi bất kỳ thao tác phân tích nào. Mọi công việc phục hồi sau đó thực hiện trên bản image — không bao giờ làm việc trực tiếp trên ổ gốc.

Giai đoạn 2 – Dựng cấu trúc RAID 10 từ 4 ổ SSD

Từ 4 image ổ riêng lẻ, dựng lại cấu trúc RAID 10 virtual:

• Xác định disk order (thứ tự ổ trong mảng RAID)
• Xác định stripe size
• Xác định cặp mirror (2 cặp mirror trong RAID 10)
• Dựng virtual volume 4TB tương đương datastore gốc

Với RAID 10, dữ liệu tồn tại trên 2 cặp mirror — nếu một ổ trong cặp bị lỗi đọc, dữ liệu vẫn đọc được từ ổ còn lại. Đây là lợi thế quan trọng trong quá trình phục hồi.

Giai đoạn 3 – Phân tích VMFS và tìm vị trí VMDK đã xóa

Trên virtual volume RAID 10 đã dựng, phân tích cấu trúc VMFS:

• Đọc VMFS superblock và descriptor
• Phân tích VMFS bitmap (file allocation map) — xác định các block vừa được giải phóng (chưa bị ghi đè)
• Quét metadata còn tồn tại: directory entry, inode, pointer đến data block
• Tìm dấu vết thư mục VM đã xóa: Misa_Internal/ và Misa_Tax/

Giai đoạn 4 – Phục hồi file VMDK và các file liên quan

Từ dữ liệu metadata tìm được, phục hồi toàn bộ thư mục VM bao gồm:

• File .vmdk (virtual disk — chứa hệ điều hành và dữ liệu MISA)
• File -flat.vmdk (actual data extent)
• File .vmx (cấu hình máy ảo)
• File .nvram (firmware state)
• Các file liên quan khác của VM

Kiểm tra tính toàn vẹn từng file sau phục hồi: so sánh header, kiểm tra cấu trúc nội bộ VMDK, đảm bảo file không bị fragmentated hoặc thiếu block.

Giai đoạn 5 – Kiểm tra và bàn giao

Kiểm tra kỹ trước khi bàn giao:

• Mount thử VMDK để xem có đọc được filesystem bên trong không
• Xác nhận dữ liệu MISA bên trong máy ảo còn nguyên
• Đóng gói và bàn giao file VM cho khách

Khách nhận file VM, tự thực hiện restore vào hệ thống ESXi và xác nhận chạy lại được hoàn toàn.

Bảng Bằng Chứng Kỹ Thuật

Quy Trình Xử Lý Theo Thời Gian

Ngày 1 – 11/06/2026 (Thứ Năm): Tiếp nhận và bảo toàn

Công việc: Tiếp nhận 4 ổ SSD lúc 15:18. Kiểm kê số thứ tự 1–4. Đánh giá sơ bộ: RAID 10, không có lỗi phần cứng, lỗi logic do xóa nhầm VM. Bước đầu tiên và bắt buộc: tạo image toàn bộ 4 ổ SSD trước khi làm bất cứ điều gì.

Phát hiện: 4 ổ SSD trong trạng thái tốt, không có dấu hiệu lỗi vật lý. Cấu hình RAID 10 nhất quán với mô tả của khách hàng.

Quyết định: Imaging song song nếu có thể để tiết kiệm thời gian. Không phân tích VMFS cho đến khi có đủ 4 image hoàn chỉnh.

Ngày 2–4 – 12–14/06/2026: Imaging và dựng RAID virtual

Công việc: Hoàn thành imaging 4 ổ SSD. Dựng virtual RAID 10 từ 4 image. Xác định disk order, stripe size, cặp mirror. Xác nhận virtual volume 4TB đọc được bình thường.

Phát hiện: Cấu trúc RAID 10 được dựng lại thành công. Virtual volume cho thấy VMFS superblock còn nguyên vẹn.

Quyết định: Tiến hành phân tích sâu VMFS metadata.

Ngày 5–7 – 15–17/06/2026: Phân tích VMFS và tìm vị trí VM đã xóa

Công việc: Phân tích VMFS bitmap, metadata, directory entry. Xác định vị trí block của thư mục Misa Internal và Misa Tax trước khi xóa. Đánh giá mức độ ghi đè — xác định block nào còn nguyên vẹn, block nào đã bị ghi đè một phần.

Phát hiện: Phần lớn block dữ liệu VMDK của cả 2 VM còn nguyên. Metadata VMFS còn đủ thông tin để dựng lại cấu trúc thư mục VM.

Quyết định: Tiến hành phục hồi toàn bộ file VM.

Ngày 8–9 – 18–19/06/2026: Phục hồi file VM và kiểm tra

Công việc: Phục hồi toàn bộ file trong thư mục Misa Internal và Misa Tax (.vmdk, -flat.vmdk, .vmx, .nvram và các file liên quan). Kiểm tra cấu trúc nội bộ từng file. Mount thử để xác nhận filesystem bên trong còn đọc được.

Phát hiện: Cả 2 file VM phục hồi thành công, cấu trúc VMDK nguyên vẹn, filesystem bên trong đọc được, dữ liệu MISA còn đủ.

Quyết định: Thông báo hoàn thành và chuẩn bị bàn giao.

Ngày hoàn thành – 20/06/2026 (Thứ Sáu): Bàn giao và xác nhận

Công việc: Bàn giao 2 file VM cho khách. Kỹ thuật viên xác nhận: “xong 2 file rồi anh ạ” lúc 09:08.

Kết quả: Khách nhận file, tự restore vào ESXi, xác nhận lúc 09:43: “mình restore đủ rồi nhé anh”. Khách hàng chuyển khoản 8,500,000 VNĐ lúc 08:48 — thanh toán sau khi đã xác nhận kết quả.

Phương Án Được Lựa Chọn

Kết Quả Phục Hồi

Giới Hạn và Dữ Liệu Không Thể Phục Hồi

Trong ca này: không có dữ liệu nào không phục hồi được.

Cả 2 file VM (Misa Internal và Misa Tax) được phục hồi hoàn chỉnh. Khách hàng tự thực hiện restore vào hệ thống ESXi và xác nhận chạy được hoàn toàn vào sáng 20/06/2026.

Điều kiện cho kết quả 100% trong ca này:

• Khách hàng dừng hệ thống hoặc ngưng sử dụng datastore ngay sau khi phát hiện xóa nhầm
• RAID 10 cung cấp dữ liệu redundancy, không có ổ nào lỗi vật lý
• Thời gian từ khi xóa đến khi tiếp nhận đủ ngắn để dữ liệu chưa bị ghi đè nghiêm trọng

Nhận Xét Chuyên Gia – Võ Ngọt

CEO, Chuyên gia khôi phục dữ liệu – Công ty Khôi Phục Dữ Liệu Võ Nguyễn

Ca này có một đặc điểm đáng chú ý: đây không phải lỗi phần cứng, không phải ransomware, không phải bad sector — mà là lỗi người dùng đơn thuần. Một thao tác xóa nhầm trên giao diện VMware ESXi. Và đó là lý do tại sao ca này lại nguy hiểm hơn mức người ta nghĩ.

Với lỗi phần cứng, bạn còn có cảnh báo — SMART, tiếng kêu, hệ thống báo degraded. Với xóa nhầm, không có cảnh báo nào. Mọi thứ diễn ra trong vòng vài giây và chỉ nhận ra sau khi hệ thống không còn thấy VM nữa.

Điểm quyết định thành công của ca này là phản ứng nhanh của người quản trị. Sau khi nhận ra xóa nhầm, họ không cố tự khắc phục, không chạy thêm phần mềm, không tạo VM mới — mà liên hệ chuyên gia ngay. Thời gian giữa thao tác xóa nhầm và thời điểm hệ thống được ngưng ghi thêm vào datastore là yếu tố quyết định khả năng phục hồi.

Một điểm kỹ thuật đáng lưu ý: với RAID 10, mỗi block dữ liệu tồn tại trên 2 ổ mirror. Nghĩa là ngay cả khi quá trình phục hồi gặp vùng khó đọc, cặp mirror còn lại có thể cung cấp dữ liệu. Đây là lợi thế thực sự của RAID 10 trong phục hồi dữ liệu so với RAID 5 hay RAID 0.

Bài học lớn nhất từ ca này không phải về kỹ thuật — mà là về quy trình vận hành. Hệ thống chạy 2 máy ảo MISA phục vụ toàn bộ kế toán doanh nghiệp mà không có bất kỳ bản backup nào. Chi phí phục hồi 8,500,000 VNĐ và 9 ngày gián đoạn là cái giá của sự thiếu hụt đó. Một giải pháp backup tự động hàng đêm (Veeam, Acronis hoặc đơn giản hơn là VMware snapshot định kỳ) có chi phí thấp hơn rất nhiều.

Dấu Hiệu Nhận Biết Rủi Ro Trước Khi Sự Cố Xảy Ra

Không như lỗi phần cứng, xóa nhầm không có dấu hiệu báo trước. Nhưng những yếu tố sau làm tăng nguy cơ xảy ra và mức độ thiệt hại:

• Không có backup cho VM quan trọng — rủi ro tích lũy mỗi ngày không có backup là một ngày gần hơn đến thảm họa dữ liệu
• Nhiều admin có quyền xóa VM mà không có quy trình xác nhận
• Tên VM không rõ ràng — khó phân biệt VM quan trọng với VM thử nghiệm khi nhìn danh sách
• Không có quy trình đánh dấu VM quan trọng trong vCenter (tag, folder phân cấp)
• Không có cảnh báo tự động khi VM bị xóa hoặc datastore thay đổi đột ngột dung lượng lớn
• Hệ thống chạy 24/7 không giám sát — xóa nhầm không được phát hiện trong nhiều giờ, datastore tiếp tục bị ghi vào

Khi phát hiện xóa nhầm VM — tắt hoặc suspend tất cả VM còn lại trên datastore ngay lập tức, ghi lại thời điểm xóa, và liên hệ chuyên gia trước khi làm bất cứ điều gì khác.

Khuyến Nghị Phòng Ngừa

• Triển khai ngay giải pháp backup VM: Veeam Community Edition (miễn phí cho đến 10 VM), Acronis Cyber Protect, hoặc VMware vSphere Data Protection. Lịch backup tối thiểu: hàng đêm, giữ 7 điểm phục hồi.
• Backup theo nguyên tắc 3-2-1: 3 bản sao, 2 loại storage khác nhau (local + NAS/cloud), 1 bản off-site. Không lưu tất cả backup trên cùng datastore với VM gốc.
• Snapshot trước mọi thao tác quản trị: Tạo snapshot tức thời trước khi cài đặt, cập nhật, hoặc thay đổi cấu hình VM. Xóa snapshot sau khi xác nhận hệ thống ổn định.
• Phân quyền VMware chặt chẽ: Chỉ tài khoản admin cấp cao mới có quyền “Remove from Inventory” và “Delete from Disk”. Tài khoản vận hành hàng ngày không cần quyền này.
• Đặt tên VM theo quy ước rõ ràng: Prefix môi trường và mức độ quan trọng — ví dụ PROD-Misa-Internal, PROD-Misa-Tax. Tên rõ ràng giảm đáng kể nguy cơ xóa nhầm.
• Giám sát datastore tự động: Cấu hình cảnh báo khi dung lượng datastore thay đổi đột ngột (>10% trong <5 phút) — dấu hiệu có thể là VM bị xóa hoặc sự cố bất thường.
• Kiểm tra restore định kỳ: Backup không có giá trị nếu không restore được. Test restore mỗi quý một lần — xác nhận file VM backup có thể khởi động lại được.
• Tham khảo cấu hình RAID phù hợp cho hệ thống server để hiểu RAID bảo vệ chống lỗi phần cứng nhưng không bảo vệ chống xóa nhầm.

FAQ – Câu Hỏi Thường Gặp

Xóa nhầm máy ảo trên VMware ESXi có phục hồi được không?

Có thể, nếu phát hiện và dừng hệ thống kịp thời. Khi VM bị xóa trên VMFS, dữ liệu thực tế không bị xóa ngay — chỉ bị đánh dấu là vùng trống. Khả năng phục hồi phụ thuộc vào lượng dữ liệu mới đã ghi vào vùng đó sau khi xóa. Trong ca này, phục hồi 100% nhờ phản ứng nhanh. Liên hệ ngay để được đánh giá và tham khảo bảng giá cứu dữ liệu server.

Phải làm gì ngay khi phát hiện xóa nhầm máy ảo?

Ngay lập tức: tắt hoặc suspend tất cả VM khác trên cùng datastore để ngăn ghi thêm dữ liệu. Ghi lại thời điểm xóa. Không tạo VM mới, không chạy phần mềm phục hồi, không rebuild RAID. Liên hệ chuyên gia. Mỗi phút hệ thống tiếp tục ghi là một phút giảm khả năng phục hồi.

RAID 10 có giúp phục hồi dữ liệu bị xóa nhầm không?

RAID 10 không bảo vệ chống xóa nhầm — khi VM bị xóa, dữ liệu bị đánh dấu xóa trên cả 2 ổ mirror đồng thời. Tuy nhiên RAID 10 có lợi thế trong quá trình phục hồi: mỗi block dữ liệu tồn tại trên 2 ổ mirror, nên nếu một vùng khó đọc, dữ liệu vẫn có thể lấy từ ổ mirror còn lại. Xem thêm về cấu hình RAID phổ biến.

Snapshot VMware có phải là backup không?

Không. Snapshot lưu trạng thái VM tại một thời điểm nhưng nằm trên cùng datastore với VM gốc. Nếu VM bị xóa cùng với snapshot (hoặc datastore bị lỗi), cả VM lẫn snapshot đều mất. Backup thực sự phải lưu ở vị trí lưu trữ khác (NAS riêng, tape, cloud).

Mất bao lâu để phục hồi máy ảo bị xóa trên VMware ESXi RAID?

Tùy thuộc vào dung lượng VM, cấu trúc RAID, và mức độ ghi đè. Ca 2 VM MISA trên RAID 10 SSD 4TB này mất ~9 ngày làm việc — bao gồm imaging 4 ổ, dựng RAID virtual, phân tích VMFS, phục hồi file VM và kiểm tra.

Chi phí phục hồi máy ảo VMware bị xóa là bao nhiêu?

Chi phí phụ thuộc vào số lượng VM, dung lượng, cấu hình RAID và mức độ phức tạp. Ca 2 VM MISA trên RAID 10 SSD này: 8,500,000 VNĐ. Không phục hồi được thì không tính phí. Tham khảo bảng giá cứu dữ liệu server VMware.

Tại sao không nên chạy phần mềm phục hồi trên live VMware system?

Phần mềm phục hồi chạy trên hệ thống đang hoạt động tạo I/O liên tục vào datastore. Với VMFS, các VM khác đang chạy cũng liên tục ghi vào datastore. Kết hợp lại, rủi ro ghi đè lên đúng vùng chứa VM đã xóa rất cao. Phương pháp đúng là tắt hệ thống → image ổ → làm việc trên bản image.

Có thể phục hồi máy ảo chỉ bằng dữ liệu bên trong VMDK mà không cần file VMDK hoàn chỉnh không?

Không lý tưởng. Nếu chỉ trích xuất dữ liệu thô từ bên trong VMDK (file và thư mục trong Windows/Linux của VM) thì có thể không cần file VMDK hoàn chỉnh. Nhưng nếu yêu cầu là “chạy lại máy ảo” như ca này, cần toàn bộ file VM (.vmdk, -flat.vmdk, .vmx…) để register lại vào ESXi. Khách hàng Misa yêu cầu chạy lại hoàn toàn — nên phục hồi toàn bộ file VM là yêu cầu bắt buộc.

Làm sao để biết backup VM đang hoạt động đúng?

Test restore định kỳ. Backup không kiểm tra restore thực tế là backup không tin cậy. Mỗi quý một lần, restore một VM từ backup vào môi trường test và xác nhận nó khởi động và chạy được. Đây là cách duy nhất để biết chắc backup có giá trị.

MISA chạy trên VM có rủi ro gì đặc biệt không?

Phần mềm kế toán như MISA thường lưu database SQL bên trong VM — mất VM đồng nghĩa mất toàn bộ dữ liệu tài chính. Với VM chứa phần mềm kế toán, yêu cầu backup phải cao hơn: backup hàng đêm tối thiểu, test restore hàng quý, và lý tưởng là có thêm bản backup của database SQL độc lập với backup VM.

Có phục hồi được nếu đã tạo VM mới sau khi xóa nhầm không?

Có thể, nhưng khó hơn đáng kể. Tạo VM mới phân bổ không gian mới trên datastore — nếu không gian đó trùng với vùng dữ liệu VM cũ, phần bị ghi đè mất vĩnh viễn. Phần còn lại vẫn có thể phục hồi được. Đây là lý do quan trọng để không làm bất cứ thao tác nào trên datastore sau khi phát hiện xóa nhầm.

Kết Luận

Ca phục hồi 2 máy ảo MISA trên VMware ESXi RAID 10 SSD này thể hiện rõ một nguyên tắc quan trọng: phản ứng đúng trong những phút đầu tiên sau sự cố quyết định kết quả cuối cùng.

Lỗi xóa nhầm xảy ra — đó là thực tế không thể tránh khỏi hoàn toàn trong môi trường vận hành hệ thống. Điều quan trọng là sau khi xảy ra, người quản trị không tự xử lý mà dừng lại và gọi chuyên gia. Quyết định đó là lý do kết quả đạt 100%.

Tuy nhiên, bài học quan trọng hơn là phòng ngừa: 9 ngày gián đoạn phần mềm kế toán và 8,500,000 VNĐ chi phí phục hồi là hậu quả của việc không có backup. Một giải pháp backup VM tự động hàng đêm có chi phí và công sức thiết lập thấp hơn nhiều so với hậu quả khi sự cố xảy ra.

Để được hỗ trợ đánh giá sự cố mất dữ liệu trên VMware ESXi, server hoặc hệ thống RAID, liên hệ Cứu Dữ Liệu 24H qua hotline 0888 711 775 / 0917 756 775 hoặc đến trực tiếp tại 201B Hoàng Văn Thụ, P. Phú Nhuận, TP.HCM. Miễn phí kiểm tra và báo giá — không phục hồi được thì không tính phí.