From owner-freebsd-questions@FreeBSD.ORG Mon Nov 5 05:42:50 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9252A9D5 for ; Mon, 5 Nov 2012 05:42:50 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9478FC08 for ; Mon, 5 Nov 2012 05:42:50 +0000 (UTC) Received: from laptop3.herveybayaustralia.com.au (unknown [192.168.0.149]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id B98D95C29 for ; Mon, 5 Nov 2012 15:58:47 +1000 (EST) Message-ID: <509751D5.7060902@herveybayaustralia.com.au> Date: Mon, 05 Nov 2012 15:42:45 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Questions about dump/restore to/from DVD media References: <20121105035233.e3c4ae8a.freebsd@edvax.de> <22095.1352087364@tristatelogic.com> <20121105051447.6eef32ef.freebsd@edvax.de> In-Reply-To: <20121105051447.6eef32ef.freebsd@edvax.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 05:42:50 -0000 On 11/05/12 14:14, Polytropon wrote: > On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote: >> In message <20121105035233.e3c4ae8a.freebsd@edvax.de>, >> 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. > > 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. For reference, if one did backup the whole slice/disk using dd and then compressed the data, would that effectively compress all those 'unallocated' nodes?