| SYSTEM INFORMATION | |
|---|---|
| OS type and version | AlmaLinux 9.3 Linux 5.14.0 on x86_64 in an OpenVZ container |
| Webmin version | 2.105 |
I’ve tried creating a backup archive (.tar.gz) several times, and even when I get a message stating that the backup is successful (see the example email report below), I cannot restore it on another server using the Webmin Filesystem backup restore function.
[...]
tar: Removing leading `/' from member names
tar: Removing leading `/' from hard link targets
Backup succeeded
Most of the backup content seems to get decompressed normally (based on the verbose command output), but somewhere around its end, it fails with an error:
gzip: stdin: invalid compressed data--format violated
This always happens for an ffmpeg binary file in my case.
I’ve tried downloading the archive manually to my local computer and the unarchiving (using macOS’s built-in tool) works without any issue reported. Similarly, if I try to download the file to the same server where the Webmin restore doesn’t work but by using wget instead and running tar -xvzf backup.tar.gz -C dir, it also works without any issue. For some reason, Webmin’s restore doesn’t work even on a brand new AlmaLinux 9.3 OpenVZ container.
In addition to that, there are always problems with creating the .tar.gz archive using Webmin’s filesystem backup function on the system creating the backups which runs AlmaLinux 8.9 OpenVZ Linux 4.18.0-1160.42.2.vz7.184.10 on x86_64, also running the same Webmin version (2.105). No matter, if I set both “Ignore read errors on files” to Yes and “Ignore errors if files change” to Yes, the backup would fail most of the time. The only message that gets reported if I disable those two options is tar: /filepath: file changed as we read it followed by Backup failed!. No more details about the reason for the fail are shown. In such situations when the backup has failed, I’ve confirmed that the backup has indeed failed as I’ve checked the resulting file and found out that it is corrupted and wouldn’t open on my local computer too.
As a side note, I would also like to add that even though the reported Webmin version on both systems (the one doing the backup and the other doing the restore) is the same, I’ve seen that the Webmin module versions displayed for some of the modules differ between the two systems. All system packages are updated to the latest versions on both systems and since both appear to run the same Webmin version, I don’t know why there is a version number difference.