Dump and exabytes - are you as safe as you think ?

[Neil Todd]

This warning may save you a small amount of grief. You should certainly
read it if you intend to put multiple dumps on a massively caching dump
device - e.g. an exabyte.

There is a problem with BSD style dump, it decides that it has finished
successfully before doing the final close() on the output device, worse
still it ignores that value returned by close().

So, you get the dumpdates file updated, a "Dump is Done" and an exit
status of zero before it is 100% sure that the close() (and presumably
pending writes) worked.

An example helps, suppose that you are putting a series of over night
incremental dumps onto one Exabyte tape, and the last dump is just a
little too big for the tape. Because of caching by the machine and the
Exabyte all the data, as far as dump is concerned, gets written away.
Your operator checks the dump logs the next morning, all seems fine.
Nobody notices some scsi sense errors on the console or in the messages
file - or if they do, they fail to think that anything is wrong with the
dump - after all the log said that is finished ok.

You only discover your problem when you come to restore, and by then it
may be too late....

We picked it up very quickly here because we do a "restore -vt" of each
dump as part of the dumping script. The message 'Not a dump' came out for
the final dump on the tape. 

This problem with dump stems from an error in the original BSD dump, can
can be fixed by reordering about three lines of code + checking the return
value for the final close (look in dumpmain.c, I think).

Neil Todd			| ..In general, it is best to assume that the
PSI%234237100122::neil		| network is filled with malevolent entities
neil at gid.co.uk			| that will send in packets designed to have
Group-ID Ltd			| the worst possible effect...