[SunHELP] UFSDUMP

[Martin Frost]

On Sat, 29 Jul 2006, Sunil Rawat wrote:

> While taking th ufsdump we got a following messages,
>  
> Dump Warning- directory at inode XXXXXXX Vanished.

It looks like some other process is changing the filesystem while ufsdump
is running. In this case the change could be easily detected since a
directory that had been mapped disappeared. Other types of changes
(such as changing a file without changing its length) cannot be detected.

This is a problem as the resulting dump may not be a true snapshot of the
filesystem and may have inconsistencies that make it unusable. For some
types of data you may be able to live with minor inconsistencies, and the
risk that restored files may be invalid (if a file changes while being
backed up), or that files may be inconsistent with respect to one another.
For other types of data these risks may be unacceptable. (Would you want
the risk of a large binary database file failing to restore?)

If you understand the risks and are happy with them, ignore this warning.
The particular change that has been detected here is probably not serious
anyway: some directory existed in the mapping phase but had been deleted
by the dumping phase. It won't appear in the backup, as if the whole dump
had run a few minutes later and it hadn't been seen during mapping.

The real risk is that something is changing the filesystem during dumping,
and you don't know what it is. Look for cronjobs running at the same time
as the dump. Depending on the types of services provided by the machine
you may have to look elsewhere (for example, if the machine is a CVS
server look for automated checkout/build systems on other machines).

The way to be 100% sure that a dump is good is to dump the filesystem
while it is either unmounted or mounted readonly. This is often not
practical on production machines, but if possible, it should definitely be
considered.

> And other error messages is 
>  
> XXXX feet into tabel.

This isn't really relevant - it's the tape position when the error
occurred.

Martin