잘못 초기화된 데이터 저장소에서 가상 머신을 복원합니다. 해피엔딩으로 끝나는 한 멍청이의 이야기

부인 성명: 이 메모는 오락용입니다. 유용한 정보의 밀도가 낮습니다. “나 자신을 위해”라고 쓰여 있었습니다.

서정적 소개

우리 조직의 파일 덤프는 Windows Server 6을 실행하는 VMware ESXi 2016 가상 머신에서 실행됩니다. 그리고 이것은 단순한 가비지 덤프가 아닙니다. 이것은 구조적 부서 간의 파일 교환 서버입니다. 협업, 프로젝트 문서 및 네트워크 스캐너의 폴더가 있습니다. 일반적으로 모든 생산 수명이 여기에 있습니다.

그리고 모든 생산 수명의 이 컨테이너가 매달리기 시작했습니다. 게다가 손님은 다른 사람에게 영향을 주지 않고 조용히 목을 매는 것도 가능했다. 그는 전체 호스트를 종료할 수 있으며 그에 따라 다른 모든 게스트 시스템도 종료할 수 있습니다. 스스로 목을 매고 vSphere 클라이언트 서비스를 중단할 수 있습니다. 즉, 다른 게스트의 프로세스가 살아 있고 시스템이 제대로 작동하고 응답하지만 파일 워셔가 없고 vSphere 클라이언트가 호스트에 달라붙지 않습니다. 일반적으로 시스템을 식별할 수 없습니다. 부하가 적은 낮에는 동결이 발생할 수 있습니다. 부하가 없는 밤에도 할 수 있었습니다. 밤에는 차등 백업 및 평균 로드가 발생할 수 있습니다. 주말에는 전체 백업이 진행되고 부하가 높을 수 있습니다. 그리고 상황은 명백히 악화되었습니다. 처음에는 XNUMX년에 한 번, 그 다음에는 XNUMX개월에 한 번이었습니다. 인내심이 끝나면 일주일에 두 번.
메모리 문제가 있었습니다. 그런데 주말에도 쓰레기 더미를 멈추고 Memtest를 실행하는 것을 허락하지 않았습니다. 우리는 XNUMX월 연휴를 기다리고 있었습니다. XNUMX월 연휴 동안 Memtest를 실행했는데... 오류는 발견되지 않았습니다.

나는 놀랐고 휴가를 가기로 결정했습니다. 제가 휴가를 가는 동안 쓰레기 처리장에서는 단 한 번도 끊김 현상이 없었습니다. 그리고 월요일 첫 출근을 하러 가보니 쓰레기 더미가 쌓여 있었습니다. 전체 백업을 견뎌내고 완료되자마자 바로 멈췄습니다. 휴가로부터의 따뜻한 환영 덕분에 저는 게스트 머신이 있는 디스크를 다른 호스트로 물리적으로 드래그하기로 결정했습니다.

그리고 휴가 후 첫날에는 진지한 일을 할 수 없다는 것이 오래 전부터 알려져 있었지만 출근하지 않을 준비를하고 있었지만 또 다른 얼어 붙은 분노로 기분과 마음이 모두 무너졌습니다. 내 머리 속에서 맹세해...

물리적 디스크가 다른 호스트로 이동되었습니다. 핫 연결. 탭의 저장소 설정에서 드라이브 디스크가 나타납니다. 탭에서 데이터 저장소 이 디스크에는 스토리지가 없습니다. 새로 고침 - 나타나지 않습니다. 물론, 첫 번째 충동은 - 스토리지 추가. 추가 마법사가 지원하는 기능을 설명합니다. 물론 VMFS도 지원합니다. 나는 그것을 의심하지 않았습니다. 각 단계(다음, 다음, 다음, 완료)에서 마법사의 메시지를 간략하게 살펴보세요. 주인의 계단 중 하나의 창문 바닥에 느낌표가 있는 작은 노란색 원이 눈에 들어오지도 않았습니다.

마법사가 끝나면 새로운 데이터 저장소가 목록에 나타납니다. 그리고 그와 함께 나머지 물리적 디스크의 데이터 저장소도 나타납니다.

새로 추가된 Datastore를 탐색해 보았는데... 비어 있습니다. 물론 나는 다시 놀라움에 빠졌다. 오전 8시, 휴가를 마치고 출근한 첫 15분 동안 나는 아직 커피에 설탕도 섞지 않았습니다. 그리고 여기 있습니다. 첫 번째 생각은 "기본" 호스트에서 잘못된 디스크를 가져왔다는 것이었습니다. 필요한 데이터 저장소가 "기본" 호스트에 있는지 확인했습니다. 아니요, 존재하지 않았습니다. 두 번째 생각은 "젠장!"이었습니다. 잘 모르겠지만 세 번째, 네 번째, 적어도 다섯 번째 생각은 같았던 것 같아요.

의심을 없애기 위해 테스트를 위해 새로운 ESXi를 신속하게 설치하고 왼쪽 디스크를 가져와 이미 읽은 후 마법사의 단계를 진행했습니다. 예. 마법사를 사용하여 데이터 저장소를 추가하면 작업을 롤백하고 데이터를 복원하는 기능 없이 디스크의 모든 데이터가 손실됩니다. 나중에 나는 포럼 중 하나에서 이 디자인에 대한 마스터의 평가를 읽었습니다. 그리고 나는 정말로 동의했습니다.

3회부터 생각은 좀 더 건설적인 방향으로 흘러갔다. 좋아요. XNUMXTb 디스크의 경우에도 초기화에는 몇 초 정도 걸립니다. 이것이 바로 고급 형식입니다. 이는 파티션 테이블이 단순히 다시 작성되었음을 의미합니다. 따라서 데이터는 여전히 존재합니다. 이제 우리는 unformat과 voila를 찾아보겠습니다.

Strelec 부팅 이미지에서 머신을 부팅합니다... 그리고 파티션 복구 프로그램이 VMFS를 제외한 모든 것을 알고 있다는 것을 알게 되었습니다. 예를 들어 Synology의 파티션 레이아웃은 알고 있지만 VMFS는 모릅니다.

프로그램을 검색하는 것은 안심할 수 없습니다. 기껏해야 GetDataBack 및 R.Saver는 라이브 디렉터리 구조와 라이브 파일 이름이 있는 NTFS 파티션을 찾습니다. 그러나 이것은 나에게 적합하지 않습니다. 시스템 디스크와 휴지통 파일 디스크가 포함된 두 개의 vmdk 파일이 필요합니다.

그리고 이제 Windows를 설치하고 파일 백업에서 롤아웃할 것 같다는 것을 이해합니다. 그리고 동시에 거기에 DFS 루트가 있다는 것을 기억합니다. 또한 범위와 결과가 매우 광범위한 부서 폴더에 대한 액세스 권한 시스템도 있습니다. 옵션이 아닙니다. 시간이 허락하는 유일한 옵션은 데이터와 모든 권한을 포함하여 시스템과 디스크의 상태를 복원하는 것입니다.

다시 Google, 포럼, KB'shki 및 Yaroslavna의 울부짖음: VMware ESXi는 데이터 복구 메커니즘을 제공하지 않습니다. 모든 토론 스레드에는 두 가지 결말이 있습니다. 누군가는 값비싼 DiskInternals VMFS Recovery를 사용하여 복구했거나 누군가는 자신의 서비스를 적극적으로 홍보하는 소프트웨어 전문가의 도움을 받았습니다. vmfs-도구 и dd. $700에 DiskInternals VMFS 복구 라이센스를 구매하는 옵션은 옵션이 아닙니다. "잠재적인 적의 영역"에 있는 외부인이 회사 데이터에 액세스하도록 허용하는 것도 선택 사항이 아닙니다. 그러나 UFS Explorer에서도 VMFS 파티션을 읽을 수 있다는 것이 검색되었습니다.

DiskInternals VMFS 복구

평가판이 다운로드되어 설치되었습니다. 프로그램은 빈 VMFS 파티션을 성공적으로 확인했습니다.

모드에서 삭제 취소(빠른 스캔) 또한 내부에 디스크가 있는 가상 머신 폴더가 있는 허름한 데이터 저장소도 발견했습니다.

미리보기에서는 파일이 살아 있는 것으로 나타났습니다.

시스템에 파티션을 성공적으로 마운트했지만 알 수 없는 이유로 세 폴더 모두 동일한 가상 머신을 포함했습니다. 물론 법에 따르면 비열한 것이 요구되는 것은 아닙니다.

세 줄의 부끄러움뻔뻔하게 소프트웨어를 잠그려는 시도는 실패로 끝났습니다. 그러나 UFS Explorer가 잠겨 있습니다.

나는 소프트웨어 도난에 대해 매우 부정적인 태도를 가지고 있습니다. 나는 어떠한 경우에도 무단 사용에 대한 보호를 우회하는 수단의 사용을 권장하지 않습니다.

나는 재앙적인 상황에 처해 있었고 내가 취한 조치가 전혀 자랑스럽지 않았습니다.

UFS 탐색기

디스크 스캔 결과 7개의 노드가 있는 것으로 나타났습니다. "놀랍게도" 노드 수가 VMFS 복구에서 감지된 *-plat.vmdk 파일 수와 일치했습니다.

파일 크기와 노드 크기를 비교한 결과 바이트 단위까지 일치하는 것으로 나타났습니다. 동시에 *-plat.vmdk 파일의 이름과 그에 따른 가상 머신에 속한 파일이 복원되었습니다.

일반적으로 ESXi 관점에서 vmdk 디스크는 데이터 파일(<머신 이름>-plat.vmdk)과 "물리적" 디스크 레이아웃 파일(<머신 이름>.vmdk)이라는 두 개의 파일로 구성됩니다. *-Flat.vmdk 파일을 로컬 시스템에서 데이터스토어로 업로드하는 경우 ESXi는 해당 파일을 유효한 디스크 파일로 인식하지 않습니다. VMware 기술 자료에는 디스크 설명자 파일을 수동으로 생성하는 방법에 대한 문서가 있습니다. kb.vmware.com/s/article/1002511, 하지만 이 작업을 수행할 필요는 없었고 DiskInternals VMFS Recovery의 파일 콘텐츠 미리 보기 영역에서 해당 파일의 콘텐츠를 복사하기만 하면 됩니다.

UFS Explorer에서 4TB 노드를 언로드한 후 2,5시간, 하이퍼바이저의 데이터 저장소로 로드한 후 20시간 후에 충돌이 발생한 디스크 파일이 새로 생성된 가상 머신에 연결되었습니다. 디스크가 픽업되었습니다. 데이터 손실은 관찰되지 않았습니다.

출처 : habr.com