When using SSH with the Filesystem Backup module, the destination host must have rmt installed, and must also have bzip2 installed if it is used for compression. However, Linux distros like RHEL/CentOS are often installed with a "minimal" image now, which does not include either of these by default. Webmin does not check for them, which causes confusion when attempting to run a backup for the first time.
In the case of missing rmt, both dump and tar appear to be working, and they consume resources on the host, but they are not able to write any data. There is no error displayed in Webmin. It would be much more user friendly if the backup script could check for this before running the backup.
In the case of missing bzip2, the backup appears to complete, but it is not able to use compression. This is confusing especially when the filename has a bz2 extension but cannot be read by bzip2. It also causes this error when verifying with the Webmin module:
. complete. Now verifying backup ..
bzip2: (stdin): trailing garbage after EOF ignored
.. backup complete.
INTERFACE/HELP UPDATES:
1) After performing a backup with TAR, the link at the bottom indicates: "Return to dump". This should say "Return to backup".
2) In .../help.cgi/fsdump/dest - Backup to ... For backups to a remote host to work, it must support the rsh protocol, which is not usually turned on by default for security reasons.
This is not correct. There is no mention of SSH here, which is the preferred replacement for RSH.
3) In .../help.cgi/fsdump/rsh - Remote backup command ... SSH will only work if the root user's SSH configuration allows passwordless logins from this system to the remote server.
This is not correct. SSH will work fine if a username and password are entered.
These are just a few examples. I'm sure there are other similar cases, but I didn't check them all....
Thanks, Alan
Comments
Submitted by ADobkin on Thu, 04/02/2015 - 04:52 Comment #1
Further testing with dump.... (Tar appears to be working now.)
When set up with SSH using a password, dump output states that it successfully connected to the destination host, but this does not appear to be the case. There is no SSH connection logged, and no file is created. The dump process remains open indefinitely on the source host and must be killed manually, even on a small filesystem like /boot.
It appears that the dump backup script creates two processes, one for an SSH "tunnel" to run /etc/rmt, plus a child dump process using this "file" to redirect to the remote host.
If I manually launch the same SSH process and enter the password, the file is touched on the remote host, but it remains zero bytes. Running dump afterward displays the following output until the browser eventually times out. The process never completes.
Performing backup of /boot to 192.168.x.x:Backups/%Y%m%d/Host1-Full.dump ..
DUMP: Connection to 192.168.x.x established. DUMP: Date of this level 0 dump: Thu Apr 2 05:46:30 2015 DUMP: Dumping /dev/sda1 (/boot) to Backups/20150402/Host1-Full.dump on host host1@192.168.x.x host1@192.168.x.x's password: ********
DUMP: Label: Host1-Full DUMP: Writing 10 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 63675 blocks.
Submitted by ADobkin on Thu, 04/02/2015 - 06:07 Comment #2
It looks like part of the problem with dump is that the command is not parsed correctly. The colon separating the host and file name is removed and replaced with a space. It probably needs to be escaped as it appears to be with the tar backup. The running process appears like this:
dump -0 -f host1@192.168.x.x Backups/20150402/Host1-Full.dump.bz2 ...
The other part of the problem is that the password doesn't appear to be entered when the SSH command is called by the dump RSH environment variable, so the SSH connection never completes. Tar doesn't have this problem.
Separate issue: When backing up to a variable directory like %Y%m%d, both dump and tar fail to create the destination directory. The user could create it themselves in the custom command section, but this should not be necessary. There should be an option similar to the Virtualmin backups to automatically create it.
Is anyone actually using this feature? It seems like it hasn't been tested, and dump is unusable over SSH with a password.
Submitted by ADobkin on Thu, 04/02/2015 - 06:14 Comment #3
Also, what causes the "trailing garbage" in this error?
bzip2: (stdin): trailing garbage after EOF ignored
It appears even in successful tar backups, even after the missing bzip2 problem was resolved. The backups are able to be restored, but tar complains about this trailing garbage then too.
Submitted by JamieCameron on Thu, 04/02/2015 - 23:16 Comment #4
Thanks for pointing out these documentation errors - I'll fix them up.
Regarding the dump command, when Webmin calls it the host and path are definitely passed separated by a colon. But possibly dump spawns another command with a different parameter format?