Disclaimer: Ghi chú mang tính chất giải trí. Mật độ cụ thể của thông tin hữu ích trong đó thấp. Nó được viết “cho chính tôi.”
Lời giới thiệu
Kết xuất tệp trong tổ chức của chúng tôi chạy trên máy ảo VMware ESXi 6 chạy Windows Server 2016. Và đây không chỉ là một bãi chứa rác. Đây là một máy chủ trao đổi tập tin giữa các bộ phận cấu trúc: có sự cộng tác, tài liệu dự án và các thư mục từ máy quét mạng. Nói chung mọi hoạt động sản xuất đều ở đây.
Và thùng chứa toàn bộ sự sống sản xuất này bắt đầu bị treo. Hơn nữa, vị khách có thể lặng lẽ treo cổ tự tử mà không ảnh hưởng đến người khác. Anh ta có thể hạ gục toàn bộ máy chủ và theo đó là tất cả các máy khách khác. Tôi có thể treo cổ tự tử và treo các dịch vụ máy khách vSphere: nghĩa là các quy trình của khách khác vẫn hoạt động, máy hoạt động bình thường và phản hồi, nhưng không có trình rửa tệp và vSphere Client không bám vào máy chủ. Nói chung, không có hệ thống nào có thể được xác định. Tình trạng đóng băng có thể xảy ra vào ban ngày khi tải thấp. Họ có thể làm điều đó vào ban đêm khi không tải. Có thể vào ban đêm trong quá trình sao lưu vi sai và tải trung bình. Có thể vào cuối tuần trong thời gian sao lưu đầy đủ và tải cao. Và có một sự xuống cấp rõ ràng của tình hình. Lúc đầu là mỗi năm một lần, sau đó là sáu tháng một lần. Hết sức kiên nhẫn của tôi - hai lần một tuần.
Tôi gặp vấn đề về trí nhớ. Nhưng họ không cho phép tôi dừng đống rác ngay cả vào cuối tuần và chạy Memtest. Chúng tôi đã chờ đợi những ngày nghỉ tháng Năm. Trong kỳ nghỉ tháng XNUMX, tôi chạy Memtest và... không tìm thấy lỗi nào.
Tôi rất ngạc nhiên và quyết định đi nghỉ. Trong khi tôi đang đi nghỉ, không có một lần cúp máy nào ở bãi rác. Và khi tôi quay lại làm việc vào ngày đầu tiên vào thứ Hai, ở đó có một đống rác. Tôi đã phải chịu đựng một bản sao lưu đầy đủ và bị treo ngay sau khi hoàn thành. Sự chào đón nồng nhiệt như vậy từ kỳ nghỉ đã đẩy tôi đến quyết định kéo các đĩa có máy khách sang máy chủ khác.
Và, mặc dù từ lâu người ta đã biết rằng bạn không thể làm bất cứ điều gì nghiêm túc vào ngày đầu tiên sau kỳ nghỉ, mặc dù tôi đã chuẩn bị tinh thần để không làm việc suốt chặng đường đi làm, nhưng sự phẫn nộ của tôi tại một đợt đóng băng khác đã đánh gục cả tâm trạng và tâm trạng của tôi. lời thề thốt ra khỏi đầu tôi...
Đĩa vật lý đã được chuyển sang máy chủ khác. Kết nối nóng. Trong cài đặt lưu trữ trên tab Ổ đĩa đĩa xuất hiện. Trên tab Kho dữ liệu Không có bộ nhớ trên các đĩa này. Refresh - không xuất hiện. Tất nhiên, sự thôi thúc đầu tiên - Thêm bộ nhớ. Thuật sĩ Thêm giải thích những gì nó hỗ trợ. Tất nhiên nó cũng hỗ trợ VMFS. Tôi không nghi ngờ gì về điều đó. Xem nhanh thông báo của trình hướng dẫn ở mỗi bước: Tiếp theo, Tiếp theo, Tiếp theo, Kết thúc. Mắt thậm chí còn không đến gần để bắt được vòng tròn nhỏ màu vàng có dấu chấm than ở cuối cửa sổ của một trong những bậc thang của chủ nhân.
Khi kết thúc trình hướng dẫn, Kho dữ liệu mới xuất hiện trong danh sách... và cùng với đó là Kho dữ liệu từ các đĩa vật lý còn lại.
Tôi chuyển sang điều hướng qua Kho dữ liệu mới được thêm vào và nó... trống rỗng. Tất nhiên, tôi lại rơi vào sự kinh ngạc. Bây giờ là 8 giờ sáng, 15 phút đầu tiên đi làm sau kỳ nghỉ, tôi thậm chí còn chưa khuấy đường vào cà phê. Và nó đây. Ý nghĩ đầu tiên là tôi đã lấy nhầm đĩa từ máy chủ "gốc". Tôi đã xem liệu Kho dữ liệu được yêu cầu có trong máy chủ "gốc" hay không: không, nó không có. Ý nghĩ thứ hai là: "chết tiệt!" Tôi không chắc lắm, nhưng đối với tôi, có vẻ như suy nghĩ thứ ba, thứ tư và ít nhất là thứ năm đều giống nhau.
Để xua tan nghi ngờ, tôi nhanh chóng cài đặt một ESXi mới để thử nghiệm, lấy đĩa bên trái và đọc nó rồi thực hiện các bước của trình hướng dẫn. Đúng. Khi bạn thêm Kho dữ liệu bằng trình hướng dẫn, tất cả dữ liệu trên đĩa sẽ bị mất mà không có khả năng khôi phục thao tác và khôi phục dữ liệu. Sau này tôi đọc trên một trong các diễn đàn một đánh giá về thiết kế này của một bậc thầy: tào lao. Và tôi thực sự đã đồng ý.
Bắt đầu từ ngày thứ sáu, những suy nghĩ đã chảy theo hướng mang tính xây dựng hơn. ĐƯỢC RỒI. Quá trình khởi tạo chỉ mất vài giây ngay cả đối với đĩa 3Tb. Vì vậy, đây là định dạng cấp cao. Điều này có nghĩa là bảng phân vùng đã được viết lại đơn giản. Vì vậy, dữ liệu vẫn còn đó. Vì vậy, bây giờ chúng ta sẽ tìm kiếm một số định dạng chưa được định dạng và thì đấy.
Tôi khởi động máy từ hình ảnh khởi động Strelec... Và tôi phát hiện ra rằng các chương trình khôi phục phân vùng biết mọi thứ ngoại trừ VMFS. Ví dụ: họ biết cách bố trí phân vùng của Synology nhưng không biết VMFS.
Việc tìm kiếm thông qua các chương trình không làm bạn yên tâm: tốt nhất, GetDataBack và R.Saver tìm thấy các phân vùng NTFS có cấu trúc thư mục trực tiếp và tên tệp trực tiếp. Nhưng điều này không phù hợp với tôi. Tôi cần hai tệp vmdk: với đĩa hệ thống và đĩa tệp rác.
Và sau đó tôi hiểu rằng có vẻ như bây giờ tôi sẽ cài đặt Windows và triển khai từ bản sao lưu tệp. Và đồng thời tôi nhớ rằng tôi đã có root DFS ở đó. Và cũng là một hệ thống quyền truy cập vào các thư mục của bộ phận hoàn toàn có phạm vi và sự phân nhánh. Không phải là một lựa chọn. Tùy chọn duy nhất có thể chấp nhận được theo thời gian là khôi phục trạng thái của hệ thống và đĩa bằng dữ liệu và tất cả các quyền.
Một lần nữa Google, các diễn đàn, KB'shki và một lần nữa Yaroslavna lại khóc: VMware ESXi không cung cấp cơ chế khôi phục dữ liệu. Tất cả các chủ đề thảo luận đều có hai kết thúc: ai đó đã được khôi phục bằng cách sử dụng DiskInternals VMFS Recovery đắt tiền hoặc ai đó được chuyên gia phần mềm giúp đỡ tích cực quảng bá dịch vụ của mình công cụ vmfs и dd. Tùy chọn mua giấy phép DiskInternals VMFS Recovery với giá 700 USD không phải là một tùy chọn. Cho phép người ngoài từ “lãnh thổ của kẻ thù tiềm tàng” truy cập vào dữ liệu của công ty cũng không phải là một lựa chọn. Nhưng người ta đã tìm thấy trên Google rằng UFS Explorer cũng có thể đọc được các phân vùng VMFS.
Phục hồi VMFS DiskInternals
Phiên bản dùng thử đã được tải xuống và cài đặt. Chương trình đã nhìn thấy thành công phân vùng VMFS trống:
Trong chế độ Phục hồi (Quét nhanh) Tôi cũng tìm thấy một Kho dữ liệu tồi tàn với các thư mục máy ảo có đĩa bên trong:
Bản xem trước cho thấy các tập tin vẫn còn sống:
Việc gắn phân vùng vào hệ thống đã thành công nhưng không hiểu vì lý do gì mà cả ba thư mục đều chứa cùng một máy ảo. Tất nhiên, theo luật, sự hèn hạ không phải là điều bắt buộc.
Ba dòng xấu hổNỗ lực khóa phần mềm một cách trơ tráo đã kết thúc trong thất bại. Nhưng UFS Explorer đã bị khóa.
Tôi có thái độ cực kỳ tiêu cực đối với hành vi trộm cắp phần mềm. Tôi không bao giờ khuyến khích việc sử dụng các phương tiện để vượt qua sự bảo vệ chống lại việc sử dụng trái phép.
Tôi đang ở trong một tình thế thảm khốc và không hề tự hào về những biện pháp mà mình đã áp dụng.
Trình khám phá UFS
Quét đĩa cho thấy sự hiện diện của 7 nút. Số lượng nút “ngạc nhiên” lại trùng khớp với số lượng tệp *-flat.vmdk được VMFS Recovery phát hiện:
Việc so sánh kích thước tệp và kích thước nút cũng cho thấy sự trùng khớp đến từng byte. Đồng thời, tên của các tệp *-flat.vmdk và theo đó, tên của chúng thuộc về các máy ảo đã được khôi phục.
Nói chung, các đĩa vmdk theo quan điểm ESXi bao gồm hai tệp: một tệp dữ liệu (<tên máy>-flat.vmdk) và một tệp bố cục đĩa "vật lý" (<tên máy>.vmdk). Nếu bạn tải tệp *-flat.vmdk lên Kho dữ liệu từ máy cục bộ, ESXi sẽ không nhận dạng tệp đó là tệp đĩa hợp lệ. Cơ sở tri thức VMware có một bài viết về cách tạo tệp mô tả đĩa theo cách thủ công: , nhưng tôi không phải làm điều này, tôi chỉ cần sao chép nội dung của các tệp tương ứng từ vùng xem trước nội dung tệp trong DiskInternals VMFS Recovery:
Sau 4 giờ dỡ nút 2,5 TB khỏi UFS Explorer và 20 giờ tải vào Kho dữ liệu của trình ảo hóa, các tệp đĩa bị lỗi đã được kết nối với máy ảo mới tạo. Các đĩa đã được chọn. Không có mất dữ liệu đã được quan sát.
Nguồn: www.habr.com