0

Did anyone run into some issues (probably a debian dist-upgrade) on having all the .gz files no longer being recognized as gzip format?

We had an issue with a DB in one of the servers this morning; after checking that we had 2 kind of backups (virtualmin virtual server full backups & database backups) decided to upgrade the mysql together with the debian distro.

After the upgrade, we noticed that none of the .gz files was being recognized as gzip format.

file alldbbackups.sql.gz
alldbbackups.sql.gz: data

show them as plain data files.

Tried gziprecover with no luck.

strace gunzip alldatabases06062020.sql.gz
execve("/bin/gunzip", ["gunzip", "alldatabases06062020.sql.gz"], [/* 29 vars */]) = 0
brk(NULL)                               = 0x56429a9d4000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=57364, ...}) = 0
mmap(NULL, 57364, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8e8843d000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\4\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689360, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e8843b000
mmap(NULL, 3795296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8e87e8a000
mprotect(0x7f8e8801f000, 2097152, PROT_NONE) = 0
mmap(0x7f8e8821f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7f8e8821f000
mmap(0x7f8e88225000, 14688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8e88225000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7f8e8843c480) = 0
mprotect(0x7f8e8821f000, 16384, PROT_READ) = 0
mprotect(0x564298faf000, 8192, PROT_READ) = 0
mprotect(0x7f8e8844c000, 4096, PROT_READ) = 0
munmap(0x7f8e8843d000, 57364)           = 0
getpid()                                = 3171
rt_sigaction(SIGCHLD, {sa_handler=0x564298da5ef0, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f8e87ebd060}, NULL, 8) = 0
geteuid()                               = 0
brk(NULL)                               = 0x56429a9d4000
brk(0x56429a9f5000)                     = 0x56429a9f5000
getppid()                               = 3169
stat("/home/bckDB/bck", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/bin/gunzip", O_RDONLY)           = 3
fcntl(3, F_DUPFD, 10)                   = 10
close(3)                                = 0
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x564298da5ef0, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f8e87ebd060}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f8e87ebd060}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f8e87ebd060}, NULL, 8) = 0
read(10, "#!/bin/sh\n# Uncompress files.  T"..., 8192) = 2301
execve("/bin/gzip", ["gzip", "-d", "alldatabases06062020.sql.gz"], [/* 29 vars */]) = 0
brk(NULL)                               = 0x5641bfe32000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=57364, ...}) = 0
mmap(NULL, 57364, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f832e5de000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\4\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689360, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f832e5dc000
mmap(NULL, 3795296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f832e02b000
mprotect(0x7f832e1c0000, 2097152, PROT_NONE) = 0
mmap(0x7f832e3c0000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7f832e3c0000
mmap(0x7f832e3c6000, 14688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f832e3c6000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7f832e5dd4c0) = 0
mprotect(0x7f832e3c0000, 16384, PROT_READ) = 0
mprotect(0x5641bec5f000, 4096, PROT_READ) = 0
mprotect(0x7f832e5ed000, 4096, PROT_READ) = 0
munmap(0x7f832e5de000, 57364)           = 0
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGHUP, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGXCPU, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGXFSZ, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x5641bea4c1c0, sa_mask=[HUP INT PIPE TERM XCPU XFSZ], sa_flags=SA_RESTORER, sa_restorer=0x7f832e05e060}, NULL, 8) = 0
rt_sigaction(SIGHUP, {sa_handler=0x5641bea4c1c0, sa_mask=[HUP INT PIPE TERM XCPU XFSZ], sa_flags=SA_RESTORER, sa_restorer=0x7f832e05e060}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=0x5641bea4c1c0, sa_mask=[HUP INT PIPE TERM XCPU XFSZ], sa_flags=SA_RESTORER, sa_restorer=0x7f832e05e060}, NULL, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x5641bea4c1c0, sa_mask=[HUP INT PIPE TERM XCPU XFSZ], sa_flags=SA_RESTORER, sa_restorer=0x7f832e05e060}, NULL, 8) = 0
rt_sigaction(SIGXCPU, {sa_handler=0x5641bea4c1c0, sa_mask=[HUP INT PIPE TERM XCPU XFSZ], sa_flags=SA_RESTORER, sa_restorer=0x7f832e05e060}, NULL, 8) = 0
rt_sigaction(SIGXFSZ, {sa_handler=0x5641bea4c1c0, sa_mask=[HUP INT PIPE TERM XCPU XFSZ], sa_flags=SA_RESTORER, sa_restorer=0x7f832e05e060}, NULL, 8) = 0
open("alldatabases06062020.sql.gz", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=219860290, ...}) = 0
read(3, "\320\215\325\331Q%,\261\10\237h\346UO\26\33\210\22\225\234\357\32\340\0v!=\373/t\220\2"..., 32768) = 32768
write(2, "\ngzip: alldatabases06062020.sql."..., 55
gzip: alldatabases06062020.sql.gz: not in gzip format
) = 55
close(3)                                = 0
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

Trying strace as above, issues a reference to:

access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)

which I am not sure if it is related to the problem. Even trying to decompress the files on different server does not work.

Any one has some hint at this desperate moment?

Armand
  • 115
  • 8
  • 1
    According to https://en.wikipedia.org/wiki/List_of_file_signatures your .gz file isn't a gzip compressed file (it starts with d0 8d instead of 1f 8b). I doubt a system upgrade would change a file unrelated to package contents. – A.B Jun 08 '20 at 16:36
  • As strange as it may seem, the lastmodification date on eaech file is not changed. I have old backups from a few years that have the correct timestamp, and still are corrupt. Pretty sure I have tested and seen those backups in the past – Armand Jun 08 '20 at 16:42
  • 1
    Maybe the backups have been encrypted somehow? Did you check the contents of file using `less`? The files might simply not be compressed... – Tero Kilkanen Jun 08 '20 at 18:13
  • Yep, checked them as well; starting: ^Ci<8E>6W<99>$$CW – Armand Jun 08 '20 at 18:34

0 Answers0