Re: Setting volume size for dump
Johann Spies wrote:
>
> Thank you for the reactions to my enquiry about efficient backup programs.
>
> I have overlooked dump and am trying it out now. What I do not seem to
> get right is setting the volume size. While using dump like this:
> dump 0uf /dev/nzqft0 / it does a backup, but says it requires 11
> tapes asking every now and then for the next volume.
>
> I tried dump B 1796 0uf /dev/nzqft0 / and dump -s 108700 0uf /dev/nzqft0 /
> but in both cases dump complains and does not accept the parameters.
>
> A dump on /dev/rmt8 results in a large file with the name /dev/rmt8 taking
> all the free space on my hard disk.
>
> My questions :
> 1. How can I tel dump to use all the available capacity on my tape?
The 's' parameter is correct. Your problem is dump's antiquated command
syntax. Like the old tar syntax, all parameters are one-letter and come
all bunched together as the first parameters. Arguments required for
each parameter follow, in order. Here's a dump command-line I use which
incorporates the "size" parameter:
dump 0udsf 28600 100000 /dev/rmt/0n /
In this case, I use the length/density parameters because I'm building
the command in a script which backs up and HP machine as well as a Linux
machine and the HPUX version doesn't like 'B' as a parameter. Your
command above should be:
dump 0uBf 1796 /dev/nzqft0 /
> 2. How can I change dump's default device to /dev/nzqft0?
You can't. The default '/dev/rmt8' is historical and I'm not sure it even
truly exists as a device (although 'ls -l /dev/rmt8' yields a device
with major=12 and minor=6 I can't find it in the kernel sources).
> 3. In setting the volume size, how can I correctly bring the compression
> factor of using zftape into account?
You can't because the compression yields varying results. With the hardware
compression you can get *up to* 50% compression factor. Fortunately, this
may not be a problem. You see, the trouble with old tape drives was that
they didn't *know* when they got to the end of the tape. Modern tape drives
(QIC included, I believe) will report an error when they get to the end
of the tape. NOTE WELL: the dump man page says the the Linux version of
dump can't correctly do multiple volume backups. C'est la vie, right?
My suggestion is to do what I do: I give dump the maxium tape capacity, and
if it gets to the end, it'll say that it got to the end of tape and so
the dump failed. At least I get an email about it.
Now all you need is a good script which will do a full dump and then put
incrementals after it on the same tape, right? Of course! I'm sending you
my perl backup script (which backs up *multiple* machines) via direct email
anyone else who's interested can have it to. My backup script has the
following features: labels tapes with it's own special header so it won't
overwrite tapes you accidentally left in the drive, will put multiple
backups on a single tape, and can recover from "missed" backups (because you
forgot to take that other tape out of the drive), keeps a "directory" of
what backups are on the tape. You'll probably have to modify it because I
take advantage of the "mark" capability of 4mm DAT tapes which aren't available
on QIC. You may find it useful all the same.
--
Jens B. Jorgensen
jjorgens@bdsinc.com
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: