Questions about dump/restore to/from DVD media

[Polytropon]

On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote:
> 
> In message <20121105035233.e3c4ae8a.freebsd at edvax.de>, 
> Polytropon <freebsd at edvax.de> wrote:
> 
> >> But as I said (above) to make this really work right, dump & restore really
> >> need to have -z options, and do the zipping/unzipping internally.  Only
> >> if this were available could dump properly deal with end-of-media on any
> >> given output volume, I think.
> >
> >The problem is that delegating compression to a "sub-task" would
> >imply that dump cannot precisely adjust its output to match the
> >media size (as the limit is now defined by how good the compression
> >works).
> 
> Correct.  We have both just said the exact same thing in different ways.
> 
> In order to have _compression_ of the dump data _and_ still be able to
> divide the (post-compression) data into nice proper 2KB chunks (as required
> for DVD+/-R writing) the compression step itself would need to be integrated
> into the dump program itself (and then, for symmetry, if for no other
> reason, into restore as well).

Chunk size _and_ media size matter (as dump would have to "know"
when the media is expected to be "nearly-full" _with_ compression)
because the operator will be required to deal with multi-volume
media ("next DVD").



> >> (I hate to say it, because in general I loath & despise Windows, but even
> >> Windows has a built-in facility for making a single backup of an _entire_
> >> system, and in a single step, *and*, I presume in a space-efficient manner.)
> >
> >That would be a task for dd. :-)
> 
> Sorry?  I am not following you.
> 
> How could dd ever substitute for the intelligence of dump(8), and specifically
> how could it avoid copying of blocks that are ``in'' the filesystem but which
> are not currently _allocated_ by the filesystem?

It cannot. :-)

With dd, you could copy a disk including all aspects of the
present slices and partitions (including file attributes and
partitioning data, even boot elements), but it would maybe
require a subsequent "read and compare" step to make sure
that everything went well.



> (I am also not persuaded the dd could handle multiple partitions any better
> that dump(8) currently does... which is to say not at all, really.)

It can - depending on what device you're reading from.

Examples:

	dd if=/dev/ad0s1a	-> the root partition
	dd if=/dev/ad0s1	-> the 1st slice
	dd if=/dev/ad0		-> the whole disk

However, dd is very much "bare metal" and cannot handle multiple
volumes and compression natively. It would be neccessary to have
all those functionalities scripted additionally.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...