손상된 우분투 이미지 복구

다음 명령을 사용하여 가상 서버(Ubuntu 18.04) 중 하나의 디스크 이미지에 대한 .gz 아카이브를 만들었습니다.

dd if=/dev/sdb | gzip -1 - | pv | ssh user@ip dd of=/home/user/sdb.gz

아카이브의 압축을 푸는 동안 다음 오류가 발생했습니다. gzip: sdb.gz: unexpected end of file

이 파일을 내 unraid 컴퓨터에서 가상 컴퓨터로 실행하려고 하면 .imggrub에 빠지게 됩니다. 그래서 이미지에 문제가 있을 수 있다는 것을 알고 있습니다. ls를 사용하면 가장 중요한 파일이 거기에 있는 것 같습니다.

서버에는 15GB 디스크가 있는데 어쨌든 압축되었기 때문에 그 일부가 누락되었다는 사실을 깨닫지 못했습니다. 결과 이미지 파일은 4.3GB에 불과합니다.

그 이후로 내 VPS 공급자는 내 가상 서버를 제거했습니다. 이제 수신 컴퓨터의 디스크 크기 제한에 도달했기 때문에 아카이브가 불완전하다는 것을 깨달았습니다.

기본 파일 구조를 사용할 수 있고 처음 4GB에 시스템을 복원하려는 모든 VM이 포함되어 있다고 순진하게 믿었습니다. IMHO 데이터는 중요하지 않지만 유용하고 시도해 볼 가치가 있는 것 같습니다. 파티션 정보에 문제가 있고 어떤 이유로 시스템이 올바른 시작 경로를 찾을 수 없는 것 같습니다.

나는 다음 단계를 시도했습니다이 튜토리얼에서는 Grub에서 부팅하기그리고이 문제.

을(를 ) 실행할 때 linux /boot/vmlinuz-4.15.0-135-generic root=/dev/sda1오류가 발생합니다: error: attempt to read or write outside of hd1.

나에게 올바른 파일 시스템은 (hd1,1).

그래서 나는 set root=(hd1,1) 미리 and 를 사용했습니다.set prefix=(hd1,1)/boot/grub

다음 명령을 실행하십시오.

insmod linux
insmod normal
normal

아무 일도 일어나지 않은 것 같습니다.

시스템을 다시 시작하려면 어떤 단계를 수행해야 합니까? 우분투 ISO를 사용하여 문제를 해결할 수 있나요?

추가 정보(편집하다):

앞서 언급했듯이 원래 VPS의 크기는 15GB였으며 손상된 .gz 아카이브에서 추출한 .img 파일의 크기는 약 4.3GB였습니다. 이 크기를 늘리려면 gparted 또는 유사한 도구가 필요합니까/사용할 수 있습니까? (저는 4TB가 넘는 공간을 갖춘 비레이드 컴퓨터에서 이것을 실행하고 있지만 @Bodo가 의미하는 바는 아닌 것 같습니다.)

또한 개별 파일을 추출하는 것은 나에게 제한된 가치입니다. 정말로 중요한 모든 것들은 오래 전에 백업되었으며, 이 이미지의 목적은 임대 가상 서버에서 내 소프트웨어가 실행되고 있는 정확한(또는 가능한 한 가까운) 환경을 부팅할 수 있도록 하는 것이었습니다.

고팟(편집 2):

방금 gparted 경로를 살펴보았습니다. 다음과 같은 오류 메시지가 표시되었습니다.

Invalid argument during seek for read on /dev/sdb

빠른 Google 검색결과이 페이지의 항목이것이 나에게 말해준다

파티션 테이블은 디스크 끝에 있습니다.

이것이 파티션 정보가 손실되는 이유입니다.

.img 파일이 너무 작기 때문에 "w" 명령을 사용하여 위 변경 사항을 쓸 수 없습니다.같은 페이지에서. 현재 이 파일을 확장하는 중입니다.