Jeremy Jackson wrote:
Mandy Kirkconnell wrote:
I think when the man page says the inventory file on the tape isn't
used, it means that xfsdump neither looks at it nor depends upon it.
xfsdump only looks at inventory files in /var/lib/xfsdump/inventory
when searching for a specific dump. The inventory file that gets
added to the tape at the end of each dump session is for the user's
benefit only, in order to query the dump sessions on a given tape.
Does this make sense? Perhaps a better explanation in the xfsdump man
page is needed.
Pointing to the xfsrestore man page for a possible use would do the
trick. Also missing from the xfsrestore man page is how to use these
inventory files, and how they are/are not merged into the inventory
database.
Good point. I'll add a better description of the tape inventory files
to the xfsrestore man page. This will include instructions on how (and
why) to merge the tape inventory files into the inventory database
directory. I'll also point the xfsdump man page to this description, as
you suggested.
Is there a way to erase a tape but keep it's media object UUID.
Unforchunately, no. All three of the options above cause a new media
objec UUID to be created when the next (first) dump begins.
It would be ideal to allow this, and prune the inventory of that
media object's UUID automatically. If this is possible, then adding
a counter to how many times that media object has been used would
give it all the features of Veritas. Would be nice.
You can use the 'mobjid=' option with -I to prune out the inventory of
a specific media object's UUID, but (as you mentioned) the media id is
not constant for a given tape. I agree, it would be really nice if
xfsdump could associate a constant media id for each tape, where the
id remained constant accross erases, overwrites, etc.. I'll open an
RFE for this as well.
I'm not all that familiar with the Veritas products, maybe you can
help me out here. Would the purpose of a counter be to keep track of
the life span of each tape? Would it include the number of dumps
(writes) AND the number of restores (reads), or just the dumps?
I have not used Veritas Backup Exec personally. The idea came out of a
discussion with an admin that uses Veritas. We were comparing the
features of xfsdump and Veritas.
You are correct - the count is used to determine when a tape should be
replaced. I'm not sure if it tracks the restores, but as these are
hopefully infrequent tracking the writes should give a reasonable
estimate of the tape's life.
This sounds reasonable if the tapes are ONLY used for xfsdump backups.
However, if the tapes are also available to other applications the
counts would be 1) overwritten and 2) inaccurate. I think people
generally use a fixed group of tapes for a particular application but if
the tapes ever got moved around the counts wouldn't reflect the true
life of the tape.
I'm thinking about making a separate erase utility that can optionally
copy the UUID from the tape and create a dummy media file or stream
terminator after erasing the tape (optional quick erase - just a rewind
and overwrite). It could track tape life separate from inventory
database for now.
Is that a volunteer? I'll make a note of this idea so it doesn't slip
through the cracks. If you'd like to look into it, please feel free ;)
Since tapes must be erased before being reused anyhow
due to the way xfsdump -o works, this seems logical.
Can you elaborate on this? See my comments below about the -o flag.
That actually reminds me of another issue. When appending a dump
session to a tape with other dump sessions, you don't use the -o flag.
But if the session fills the tape, the new tape inserted must not have
any xfsdump sessions, or the dump aborts (can't choose overwrite in
middle of a dump).
You *should* be able to add the -o when you resume the dump on a new
tape. Do you get errors when you try to do this? If so, can you send
me the xfsdump command that you are using to resume on a new tape?
"mt erase" takes 3 hours on this Exabyte drive, so I came up with a
shortcut:
mt rewind ; dd if=/dev/zero of=/dev/tape count=1 bs=245760
(where bs= is the -b size used with xfsdump).
It thinks the tape is a corrupt xfsdump tape or a foreign tape, and
allows overwrite.
I'm not sure what the recomendation for xfsdump is in this scenario...
if there is one perhaps it could go in the manpage.
If you truely can't specify -o when you resume on a new tape, the only
options would be to 1) erase the entire tape (2-3 hours!!) or 2) find
some way to corrupt the first few blocks of the old dump, like you did
with your dd workaround above.
Mandy
--
Mandy Kirkconnell
SGI, Storage Software Engineer
alkirkco@xxxxxxx
|