문제가 발생했을 때 데비안에 파티션 저장하기

좋은 오후에요
목요일 저녁이었고 관리자 중 한 명이 KVM 가상 머신 중 하나에서 디스크 크기를 조정해야 했습니다. 아주 사소한 작업처럼 보이지만 데이터가 완전히 손실될 수 있습니다... 그래서... 전체 스토리는 이미 컷 아래에 있습니다.

이미 말했듯이, 목요일 저녁(비가 오지 않는 것 같았음)에 우리 관리자 중 한 명이 오랜 작업을 완료하고 KVM 가상 머신 내부의 파일 크기를 늘리기로 결정했습니다.

이전에는 이미 디스크 자체의 크기를 14GB에서 60GB로 늘렸고 관리자는 가상 머신 내부의 파일 시스템 크기만 늘리면 되었습니다.

밤 12시쯤 관리자가 확장 섹션이 있어야 하는지 기본 섹션이 있어야 하는지 묻는 메시지를 보냅니다... 이에 대한 응답으로 저는 그에게 가상 머신 자체에서 이전과 같은 방식으로 해야 한다고 썼습니다.

시간이 지났는데... 관리자가 오류가 발생해서 파티션을 확장할 수 없다고 하더군요... 마운트가 중단되었습니다... 벌써 새벽 2시가 되었습니다...

나는 그에게 더 이상 아무것도 하지 말고 가상 머신을 그대로 두고 VM 디스크 이미지의 복사본을 직접 만들어 vmname_bad라고 부르도록 그에게 편지를 썼습니다.

관리자가 작업 전에 스냅샷을 찍지 않고 마크업을 복사하지 않았기 때문에 모든 것이 더욱 복잡해졌습니다. 이 정보가 있으면 롤백하고 다시 시도할 수 있습니다.

아침에 새로운 생각으로 동일한 OS(Debian 9)로 가상머신을 설정하고 디스크를 연결합니다. fdisk를 통해 이 디스크가 이미 60GB로 확장되었고 파티션이 실제로 약간 손상되었음을 확인했습니다.

관리자가 제공한 스크린샷을 사용하여 이전 마크업을 찾으려고 노력하고 있지만 아쉽게도 헛된 것입니다. fdisk를 이용해서 값을 찾으려고 하는데 아쉽게도 모든 시도가 실패했습니다.

fdisk는 나를 도울 수 없기 때문에... 나는 parted에 도움을 요청하고 있습니다. parted를 로드합니다. 이전 파티션 rm 2를 삭제하고 대략적인 파티션 값을 알고 구조합니다. 파티션이 있을 수 있는 초기 값과 최종 값을 나타냅니다. 잠시 기다려서 헤어지면 파티션을 찾고 이에 대한 정보를 시스템에 입력하라는 제안을 받습니다. 저는 동의하고 헤어졌습니다.

파티션을 마운트했습니다. 모든 것이 정상입니다. 파일은 제자리에 있고 모든 것이 정상이지만 크기는 여전히 14GB입니다. /dev/sdd1을 마운트 해제하고 resize2fs /dev/sdd1을 수행한 다음 e2fsck /dev/sdd1을 다시 마운트하고 모든 파일이 포함된 이미 확장된 파티션이 살아 있는 것을 확인했습니다.

나와 관리자 모두에게 모든 것이 잘 끝났습니다.

출처 : habr.com