SUMMARY: Multi-level ufsdump of file(s), /etc/dumpdates

From: Andrew J Caines <>
Date: Tue Mar 02 2004 - 18:08:42 EST
Thanks to John Malick, Darren Dunham, Pete Geenhuizen and Rich Kulawiec
for their responses, all of which lead to the same conclusion, which is
that ufsdum will only do incremental dumps of complete filesystems and has
no way of excluding files.

Darren's clever suggestion of dumping a lofs mount didn't fool ufsdump.

So, to incrememntally back up a filesystem to a file on that filesystem
using native tools, some inelegant wheel reinvention is required.

Now to put a "Nodump flag for Solaris UFS and/or -x switch for ufsdump" in
Sun's suggestions box.

Original question:

> Ufsdump nicely handles incremental backups, so I'd like to use it to back
> up my data in /foo/data and keep the dumps in /foo/archive, where /foo is
> a nice big filesystem.
> The problem is that if you give ufsdump a file or directory to back up,
> eg. "ufsdump 0uf /foo/archive/bar.dump /foo/data", then it does not update
> /etc/dumpdates and hence every dump at every level is a full dump, so you
> can't do incrementals.
> Now if you try to be clever and manually add entries to /etc/dumpdates for
> filesystem /foo, then ufsdump ignores it, ie. it not only doesn't write to
> /etc/dumpdates when dumping files, but it doesn't read it either.
> Since ufsdump doesn't have any kind of `exclude' switch, the next obvious
> solution would be to dump /foo but mark /foo/archive as excluded from
> dumps at the filesystem level, but I can find no such support for this in
> Solaris' UFS.
> So, is it possible to do a multi-level ufsdump of files in Solaris, and if
> so then how?
> If not, then suggestions for an _elegant_ solution to incremental backups
> to separate files using native tools would be welcome.

| -Andrew J. Caines-   Unix Systems Engineer  |
| "They that can give up essential liberty to obtain a little temporary |
|  safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 |
sunmanagers mailing list
Received on Tue Mar 2 18:08:38 2004

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:26 EST