Questions about dump/restore to/from DVD media

[Ronald F. Guilmette]

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).

>Using dump + restore
>means to operate on partitions. Make the system one partition - deal
>with one partition. Make many partitions - need to deal with them
>individually.

Good point.

>> (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?

(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.)


Regards,
rfg