backing up 37GB of data using File System Backup, backup to tape
QUANTUM DLT TAPE DRIVE, USING 20GB NATIVE TAPE
backup format: unix tar /dev/st0 is the tape drive (single tape drive, not autoloader or library)
tape size: 20000000kb (it also still fails when set to (work out automatically) prompt for new tape if needed: Set to YES
Keep getting failed backups, tape full no space left on tape, I tried using EXT3 filesystem backup, same deal
However it used to prompt me for a new tape before the latest webmin/virtualmin upgrade was done.
NOTE: in filesystem backup module under webmin, if you click on the words (prompt for new tape if needed) should launch the help/definition of it, but i get this error: Failed to read help file /usr/libexec/webmin/fsdump/help/notape.html and the file is there.
Please help, i can attach screen shots if needed, thanks>
tar: Removing leading /' from member names
tar:
/etc/webmin/fsdump/notape.pl 136761330803000' command failed
tar: Error is not recoverable: exiting now
Backup failed!
Comments
Submitted by JamieCameron on Sat, 03/03/2012 - 19:59 Comment #1
A screenshot would be useful..
Did you enable gzip compression for your backup? That doesn't work with tape backups.
Also, is the data being backed up bigger than 20 GB?
Submitted by jayant236 on Sat, 03/03/2012 - 23:03 Comment #2
screenshot attached:
no, no compression enabled.
and Yes 20GB tapes , 37GB needed to be backed up, thus the notape.pl should launch and ask for another tape, it used to do this before the latest webmin update/upgrade to the latest version
centos 5.7 fully patched.
Submitted by JamieCameron on Sun, 03/04/2012 - 00:19 Comment #3
Are you running the backup job in the foreground (so that progress output is shown) or in the background so that it appears on the main page of the Filesystem Backup module?
Submitted by JamieCameron on Sun, 03/04/2012 - 00:21 Comment #4
Also, on the Module Config page, do you have "Prompt for new tape if full?" set to "Yes" ?
Submitted by jayant236 on Sun, 03/04/2012 - 00:28 Comment #5
Yes, unfortunately i made sure these were on too, in module config, run in background (i know it will fail for sure in foreground) and prompt for new tape, as shown in this pic attachment.
Submitted by JamieCameron on Mon, 03/05/2012 - 00:02 Comment #6
Could you run
ps auxwwwww | grep tar
when the backup is running to see the full command line to tar, and post it here?Submitted by jayant236 on Mon, 03/05/2012 - 00:16 Comment #7
grep tar mailman 2823 0.0 0.2 13984 5216 ? Ss Feb16 0:00 /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start root 3157 0.0 0.1 12964 4236 ? S Feb16 0:00 /usr/bin/python /usr/sbin/xend start root 3158 0.0 0.2 64184 5192 ? Sl Feb16 0:00 /usr/bin/python /usr/sbin/xend start root 15746 1.7 0.0 2980 936 pts/1 Ds+ 01:13 0:00 tar -c -f /dev/st0 -V tl -F /etc/webmin/fsdump/notape.pl 156881330928009 /home/atozmicro/public_html root 15764 0.0 0.0 4156 708 pts/0 S+ 01:14 0:00 grep tar
Submitted by JamieCameron on Mon, 03/05/2012 - 15:30 Comment #8
Ok, so the problem is that the
-F
flag is using thenotape.pl
command, which stops tape changing from working..Which Webmin version are you using there?
Submitted by jayant236 on Mon, 03/05/2012 - 15:48 Comment #9
3.90.gpl
Submitted by JamieCameron on Mon, 03/05/2012 - 17:37 Comment #10
How about the Webmin version? You can get that with the command
rpm -q webmin
Submitted by jayant236 on Mon, 03/05/2012 - 18:18 Comment #11
sorry about that, Webmin 1.580
Submitted by JamieCameron on Wed, 03/07/2012 - 13:01 Comment #12
Any chance I could login to your system to take a look at this? The current behavior of Webmin isn't making sense to me ..
Submitted by jayant236 on Wed, 03/07/2012 - 17:27 Comment #13
Hi Jamie, can you email me? first: a@nowatm.info Jay
Submitted by JamieCameron on Fri, 03/09/2012 - 10:54 Comment #14
For anyone else reading this - the cause was the option to control prompting for new tape on the Module Config page having its labels reversed. This will be fixed in the next webmin release.
Submitted by Issues on Fri, 03/23/2012 - 12:18 Comment #15
Automatically closed -- issue fixed for 2 weeks with no activity.