On Thu, Feb 18, 2010 at 10:54:55PM +0100, Jean-Francois wrote:
quoted text
> Is it possible to clarify what resides behind the concept of levels regarding 
> dump(8) ?
> For me the level 0 is understood to be a complete dump of all files on at a 
> given mount point and all subdirectories. But I can't figure out what upper 
> levels are.

A dump at level N includes everything modified since the last dump
at N-1 or lower.

Thus, for example, if on Monday we do a level 0 dump of /foo, and then
on Tuesday, we do a level 1 dump of /foo, that second dump will contain
everything that's changed in the last day.

If on Wednesday, we do a level 3 dump of /foo (note that I skipped level
2 on purpose) then we will have everything that changed since Tuesday,
since 3 > 1.

If on Thursday, we NOW do a level 2 dump of /foo, we will have everything
that changed since the level 1 on Tuesday -- two days' worth of changes.

This all works as planned provided you give "u" flag to dump, which
instructs it keep track (in /etc/dumpdates) of which filesystems it
has dumped and when.  Note (a) that filesystems are tracked by device,
so that if you umount /foo and remount it as /bar, the right thing
happens and (b) the timestamp used is the time that the dump BEGINS,
but it is not written into the file until the dump ENDS.  (This is
part of the set of mechanisms which deal with changes that take place
while dump is running.)

Dump's various levels provide a lot of ways to minimize one or more
of (1) dump run time (2) dump output size (3) number of dumps required
to restore a failed filesystem.  For example, if you did level 0 dumps
every day, you would maximize (1) and (2) but minimize (3), since it would
always be 1.  For another example, if you did level 0 dumps on Sunday
and 1-6 Monday-Saturday, then you would cut down (1) and (2) considerably
six days a week, but you might need to restore as many as 7 dumps
which means you've pushed (3) fairly high.  So choosing which scheme
is appropriate for you requires having knowledge of your environment
and answering questions like:

	- how much backup space do you have?
	- do you lose entire disks often?
	- do your users screw up and require restores often?
	- do you have an open or limited backup window?
	- what are you backing up?
	- does the data you're backup up compress well?

among many others.  None of the schemes thus derived are really
"right" or "wrong" per se, as long as data can be retrieved;
they're just more or less optimal given the environment.

---Rsk