I have a MySQL database backup in a gz file. When trying to uncompress it I get the following:gzip: db_stepup.sql.gz: not in gzip formatI read that sometimes is just a matter of removing the gz extension. So I did that and I'm able to see the file up a point. (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\D8XY\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\F8At this point the file gets scrambled. It looks like a problem of text encoding, is there a way to recover the data in the file?Here's the file if you want to take a look at it
Corrupted gz file
compression;gzip
The file starts out in plain ASCII so it's uncompressed.$ hexdump -C db_stepup.sql.gz | less00000000  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|[...]That goes on for a while until somewhere in the middle it turns binary.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<...|It starts with 1f 8b 08 ... (which for some reason did not show as such in the output you posted), it could be a valid gzip header. The starting point is 000123a3 so let's split it off...$ dd if=db_stepup.sql.gz bs=$((0x000123a3)) skip=1 | gunzip | less,(356, 'bs', 'mo', 'Bosnian'),(357, 'bs', 'mn', 'Bosnian'),(358, 'bs', 'ne', 'Bosnian'),[...]And hey, that seems to be the data where it left off. For some strange reason phpMyAdmin seems to have decided to use gzip in the middle of the output...Stitching it back together:$ 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.sqlIf you're looking for a way to find such offsets automatically (maybe you have more broken files like that), there's this nice little tool called binwalk which can also look for known file headers in the middle of files.$ binwalk db_stepup.sql.gz DECIMAL       HEXADECIMAL     DESCRIPTION--------------------------------------------------------------------------------74659         0x123A3         gzip compressed data, from Unix, NULL date: Thu Jan  1 00:00:00 197092556         0x1698C         gzip compressed data, from Unix, NULL date: Thu Jan  1 00:00:00 1970110522        0x1AFBA         gzip compressed data, from Unix, NULL date: Thu Jan  1 00:00:00 1970[...]As you can see it has the same result (0x123A3 offset). It finds more than one because gzip comes in blocks / chunks (you can even concatenate multiple gzip files) and each block has the same distinct header.