☰

gz 파일이 손상되었습니다

tag-icon • tag-icon compression gzip
gz 파일이 손상되었습니다

gz 파일에 MySQL 데이터베이스 백업이 있습니다. 압축을 풀려고 하면 다음과 같은 내용이 나옵니다.

gzip: db_stepup.sql.gz: not in gzip format

때로는 gz 확장자를 제거하는 것만으로도 효과가 있다는 것을 읽었습니다. 그래서 그렇게 했더니 파일을 볼 수 있었어요.

(352, 'bs', 'lv', 'Bosnian'),
(353, 'bs', 'lt', 'Bosnian'),
(354, 'bs', 'mk', 'Bosnian'),
(355, 'bs', 'mt', 'Bosnian')\8B\00\00\00\00\00\00}\9Dۓו\EE\DF\CF_\C1    \DBx"<\95\F7\CC8O3c\CF\D8\C7c\8F\E3\D8s&Γ]MWW\95*\B3\AA\AB2\AB\DDO@\83\84A\B2el\A1;\81$\8B\ABԒ<\B4\F4
\AD' \CEI6\D2\FFp2\F7\DA{\FB\B2 <nk\F4\ADܙ\F5[;\F7\FAv\DE\F6\F7\FF    \C7\F7\A2$\FD\FE\BEX\A9\FF\A1\FD[ͺ\BF\FF2\AB\A7\E3\FE\F4\FE\F1\FB\9D\9AA\9D\FAj\AE\D5\E9\C0W\A8\A5V\EB\FD#\92\D3\E4o\E34\D0\EAz\DFWC\A8\A2\E9\95\D9\AF\B4\F2\FE\C9XDh\FEi\BD-\EC^i\9B\98ɀ\D8XY\F8\89\98/\FD\00\B5\85Am\FF\E7\DBR\B7\85\D8z\EF\F7{7\BE<\B8\F7\D9\DE\CE\DE\C7\ED\FF~\D2\FD\AFĺ\F4w\88\B5\9F\9E빯\82a\BD\F0U0\AC7\90\9EI_\CA \D8\F8

이 시점에서 파일이 뒤섞였습니다. 텍스트 인코딩 문제인 것 같습니다. 파일의 데이터를 복구할 수 있는 방법이 있습니까?

확인하고 싶다면 파일이 있습니다.

답변1

파일은 일반 ASCII로 시작하므로 압축되지 않습니다.

$ hexdump -C db_stepup.sql.gz | less
00000000  2d 2d 20 70 68 70 4d 79  41 64 6d 69 6e 20 53 51  |-- phpMyAdmin SQ|
00000010  4c 20 44 75 6d 70 0a 2d  2d 20 76 65 72 73 69 6f  |L Dump.-- versio|
00000020  6e 20 34 2e 31 2e 31 34  2e 38 0a 2d 2d 20 68 74  |n 4.1.14.8.-- ht|
[...]

이것은 중간 어딘가에서 바이너리가 될 때까지 잠시 동안 계속됩니다.

00012390  27 2c 20 27 6d 74 27 2c  20 27 42 6f 73 6e 69 61  |', 'mt', 'Bosnia|
000123a0  6e 27 29 1f 8b 08 00 00  00 00 00 00 03 7d 9d db  |n')..........}..|
000123b0  93 14 d7 95 ee df cf 5f  c1 db 78 22 3c 11 95 f7  |......._..x"<...|

그것은 다음으로 시작합니다. 1f 8b 08(어떤 이유로 게시한 출력에 표시되지 않음) 이는 아마도 유효한 gzip 헤더일 것입니다. 출발점은 000123a3이렇으니 분해해 보겠습니다.

$ dd if=db_stepup.sql.gz bs=$((0x000123a3)) skip=1 | gunzip | less
,
(356, 'bs', 'mo', 'Bosnian'),
(357, 'bs', 'mn', 'Bosnian'),
(358, 'bs', 'ne', 'Bosnian'),
[...]

아, 이게 멈춘 데이터인 것 같네요. 이상한 이유로 phpMyAdmin이 출력 중간에 gzip을 사용하기로 결정한 것 같습니다.

다시 꿰매세요:

$ dd if=db_stepup.sql.gz bs=$((0x000123a3)) count=1 > db_stepup.stitch.sql
$ dd if=db_stepup.sql.gz bs=$((0x000123a3)) skip=1 | gunzip >> db_stepup.stitch.sql

이러한 오프셋을 자동으로 찾는 방법을 찾고 있다면(이와 같이 손상된 파일이 더 많을 수도 있음) binwalk파일 중간에서 알려진 파일 헤더를 찾을 수도 있는 멋진 작은 도구가 있습니다.

$ binwalk db_stepup.sql.gz 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
74659         0x123A3         gzip compressed data, from Unix, NULL date: Thu Jan  1 00:00:00 1970
92556         0x1698C         gzip compressed data, from Unix, NULL date: Thu Jan  1 00:00:00 1970
110522        0x1AFBA         gzip compressed data, from Unix, NULL date: Thu Jan  1 00:00:00 1970
[...]

보시다시피 동일한 결과( 0x123A3오프셋)가 있습니다. gzip은 청크/청크로 제공되고(여러 gzip 파일을 연결할 수도 있음) 각 청크에는 동일한 헤더가 있기 때문에 여러 파일을 찾을 수 있습니다.

관련 정보