Data recovery in virtulised system

데이터복구 업체중에 Ontrack 이라는 회사가 있습니다. 

VMware KB 에서도 소개되어있는 업체중 하나이기도 하죠. 왠만하면 연락하고 싶지 않은 그런 회사들입니다만… 비용도 어마무시할꺼고요.

https://kb.vmware.com/s/article/1015413

이곳에서 한번 읽어두면 괜찮을듯한 자료를 내놨습니다. 제목은 Data recovery in virtulised system입니다.

https://assets.krollontrack.com/hv3/PDF/fi/ibas-ontrack-fi-data-recovery-in-virtualised-systems-20190705.pdf

문서의 내용은 가상화 환경에서의 데이터복구에 대한 이야기를 담고 있습니다. 뭐 복구를 어떻게 한다 이런 방법에 대한게 아니라 일종의 통계자료? 같은 느낌입니다.

바쁘신분들을 위해서 제가 내용을 간추려 보면..

• 2018년을 기준으로 글로벌 기업들이 다루는 평균 데이터양은 9.7PB 정도로 2016년 대비해서 569% 정도 증가한 수치라고 합니다.
• 평균적으로 2.5TB 정도의 Data loss 가 발생하였으며, 이를 복구하는데 들어간 비용은 1M USD 정도가 된다고 합니다.

기타 마케팅 적인 내용은 제외하고

• Data loss 가 발생하는 90% 의 원인은 디스크이며 10% 정도가 소프트웨어 이슈로 인해 발생한다. 
• 데이터복구 과정에서 가장 시간이 오래 걸리는 부분은 Initial search 이다. 대부분 오토매이션을 할려고 하지만 사람의 힘이 필요한 경우가 많다.
• 지난 12개월간  통계적으로 봤을때 40% 의 가상화된 환경에서 data loss 가 발생하였으며 오직 1/3 의 회사만이 100% 데이터 복구에 성공했다. 이러한 data loss 의 경우 디스크 폴트나, 가상디스크/스냅샷등의 삭제/(실수) 가 root cause 인 경우가 72% 이다. 이러한 통계값을 봤을 때 data loss 에서 완벽하게 안전한 비지니스는 존재하지 않는다.

기타 Data loss 상황이 발생했을때의 조언입니다.

• Data loss 발생했다고 생각될 경우, 뭔가 조치할려는 노력을 중단하라. (If you think you might have lost data STOP what you are doing) 이러한 노력들이 더 많은 Damage 를 만든다.
• 집에서 데이터 복구를 시도하지 말아라! 유튜브등에서 데이터복구를 하는 방법에 쉽게 찾을 수 있지만, 이걸보고 따라가는 경우 영구적인(permanent) data loss 로 이어진다. 데이터복구를 위한 트레이닝을 받지 않은 사람에게 의뢰하는 일이 없도록 할것.
• 또한 데이터복구를 가능하게 해준다는 프리 소프트웨어들은 일반적으로 더 큰 데미지를 입게하며, 이러한 소프트들이 바이러스로 인식되는 경우가 많다.

가장 많이 발생하는 문제 유형은 아래와 같습니다. 가상 디스크 삭제가 가장 많은것으로 봐서 Human error 가 가장 큰 부분을 차지하는 것으로 이해해도 무방할듯 합니다. 휴먼 에러로부터 안전해질 수는 지금까지도 없었고 앞으로도 없을것이라고… ㅎㅎ 

• 가상 디스크의 삭제 (40%) 
• 하드웨어 결함 (30%)
• 마이그레이션 에러 (10%)
• 스냅샷 문제 (10%)
• 기타 (10%) 

대체로 휴먼에러가 발생하는 경우는 운영자가 과부하가 걸렸을 때나 업무를 빨리 끝내려고 할 때, 본인이 하는 액션에 대한 이해없이 진행하는 경우가 많다고 합니다. 그리고 data loss 가 확인되었을 때 더 많은 실수를 하게 된다고 합니다. Ontrack 의 자체조사에 의하면 77% 의 IT 운영자가 본인의 업무가 과도하다고 생각하며, 84% 의 회사들이 겪지 않아도 될 Data loss 를 경험했다고 하네요. 피할 수 있는 오류의 종류는 다음과 같다고 합니다.

• 부족한 시간 – IT 운영자에게 충분한 시간을 부여할 것
• Data loss 가 발생한 시스템에서 뭔가 다른 액션을 하는 것. 데이터가 overwritten 되기 시작하면 data loss 는 대체로 되돌리기 어려움. Data loss 가 발생한 시스템은 반드시 lock 되어야 하며, Database 들도 Freeze 해야함
• 오래된 백업 – 백업을 자주하지 않는 경우

문제 유형

• • VMDK 삭제나 VMDK 가 없어진 경우 –
    • 삭제되었을 경우 해당 디스크의 크기/Thin or Thick Provisining 여부, 가상머신 이름, Guest OS 파일시스템, 데이터 유형들이 대한 기록을 해둘 것
    • Dataloss 가 발생한 영역(Datastore)에 Read / Write 를 최소화 할것. Thin provisioned 된 VM 이라면 가능한한 빨리 Power off 를 할 것 
    • Data 손상이 발생한 VM 들을 다른 호스트나 볼륨으로 임의로 마이그레이션 하지 말것 
    • 만약 스냅샷이 삭제되거나 없어졌다면 Power on 하지 말것, Power on 되어있다면 VM 을 빨리 Power off 할 것 
  • VMFS 메타데이터의 속상 또는 datastore  접근이 불가능 한 경우 
    • Datastore 를 새로 생성하지 말것
    • 해당 LUN 에 대해서 조사한다면, Read only 상태에서 조사할 것
  • RAID/Storage 이슈인 경우 
    • 다른 RAID 시스템에서 사용된적이 있는 디스크를 교체용으로 사용하지 말것
    • 교체용 디스크 파트는 Zeroing 을 할 것
    • 교체용 디스크 파트에서 소음이 발생할 경우 사용하지 말것. 파트 불량일 경우 데미지가 더 커질 수 있으며 복구를 어렵게 함.
    • 만약 시스템에서 디스크들을 다 분리한다면 해당 디스크가 어떤 슬롯/베이에 꼽혀있었는지 기록해둘것. 
    • 디스크 교체후 Rebuild 과정에서 Rebuild 가 Failed 되었다면 재시도 하지 말것 
    • 해당 RAID 시스템에 있었던 VM 들을 다른곳으로 마이그레이션 하지 말것. 
    • 만약 RAID 시스템의 Power off 가 필요한 경우, VM 과 호스트의 Power off 를 먼저 할 것
  • Guest OS 내부의 손상
    • CHKDSK 등이나 defragment 툴들을 사용하지 말것
    • 만약 1개 이상의 VM 에서 Guest OS 데이터 손상이 발생했다면 스토리지 문제일 가능성이 큼. 

Golden Rule

• • 운영자에게 데이터를 백업할 수 있는 충분한 시간을 부여할 것
  • Dataloss 가 발생한 시스템에서는 더 이상 작업을 하지 말 것
  • 백업을 주기적으로 할 것. Data loss 에 대한 Plan 을 미루 세워둘 것.

가상화 환경에서 데이터복구가 쉽지 않는 이유는 VMware 를 예를 들면 VMDK 가 여러개의 Physical disk 에 분산되어 쓰여지기 때문입니다. 만약 VMDK 가 삭제되었다고 하면, 삭제되기 전에 위치에 대한 추적이 매우 중요합니다. 자체적으로 데이터 복구를 시도한다고 이것저것 소프트웨어를 다운받아서 시도하는 경우가 많은데 이러한 액션들은 기존의 파일들에 대한 위치추적을 거의 불가능하게 합니다.

문서 자체의 순서가 좀 뒤죽박죽인데 제가 임의로 내용 순서를 좀 바꾼 부분도 있습니다. 기타 본인들 자랑에 해당하는 내용은 제외했습니다.

그럴일은 없어야 겠지만,한번쯤 마음속에 되새겨볼 필요는 있을 내용인듯 합니다.

위의 KB 에도 유사한 내용들이 언급되어있습니다.

• Do not install recovery software on the volume from which you are trying to recover.
• Do not write any recovered data or anything else to the volume from which you are trying to recover data.
• Do not allow any usage of the volume from which you are trying to recover and take it offline (unmount).
• Do not work with the only copy of your data/volume/VMDK file. Always take a backup/image and keep it safe in case of further escalation.
• Do not re-initialize or reformat the problematic volume. This does not bring the data back and will only increase the severity of data loss.
• Do not rebuild the problematic RAID system unless you have all member drives imaged for further escalation or you have a backup.
• Do not force fail RAID member drives online until you have all member drives imaged for further escalation.

마지막으로..

그럼 즐거운 하루 되세요.