Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Nov 2012 05:14:47 +0100
From:      Polytropon <>
To:        "Ronald F. Guilmette" <>
Subject:   Re: Questions about dump/restore to/from DVD media
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote:
> In message <>, 
> Polytropon <> 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.


	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.

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

Want to link to this message? Use this URL: <>