From owner-freebsd-questions@FreeBSD.ORG Mon Nov 5 01:18:25 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 CAA68609 for ; Mon, 5 Nov 2012 01:18:25 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 723FB8FC08 for ; Mon, 5 Nov 2012 01:18:25 +0000 (UTC) Received: from r56.edvax.de (port-92-195-8-72.dynamic.qsc.de [92.195.8.72]) by mx02.qsc.de (Postfix) with ESMTP id 1141823FA0; Mon, 5 Nov 2012 02:18:17 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id qA51IH6h002033; Mon, 5 Nov 2012 02:18:17 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Mon, 5 Nov 2012 02:18:17 +0100 From: Polytropon To: "Ronald F. Guilmette" Subject: Re: Questions about dump/restore to/from DVD media Message-Id: <20121105021817.fc5bff1b.freebsd@edvax.de> In-Reply-To: <20880.1352077018@tristatelogic.com> References: <20880.1352077018@tristatelogic.com> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 01:18:25 -0000 On Sun, 04 Nov 2012 16:56:58 -0800, Ronald F. Guilmette wrote: > > I would like to make a backup of one of my systems using dump(8) in order > to be sure that I get everything, including all of the obscure file attribute > bits. That eliminates at least some tools. I have been using a similar idea in the past to make a backup of a system using multiple CD-Rs and I think cpio or pax, but only for data files that do not come with the whole range of "special attributes". Oh wait, it was afio, on FreeBSD 4... > I would like to make this backup to a _minimal_ number of DVD+R disks. If you think you can add compression to your files (if it makes sense), it should be incorporated to the command. > What's the proper procedure for this? > > In the dump(8) man page, I see the following example: > > /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u > > There are several problems with this example, as far as I am concerned. > > First I have no particular interest in, or need for _either_ an ISO 9660 > _or_ a UDF file system on my backup media. And in fact, that seems to me > as if it is likely to be an utter waste of (precious) space on the backup > media. Can't I just put the output of the dump command _directly_ onto > the output DVD+R media? I think this command exactly does this. Your idea is correct: There is no need for ISO-9660 or UDF on backup media as it will not be mounted, but processed with the proper restore tool. The command "growisofs -Z /dev/cd0=" will record the file "like an image" to the media. In most cases, that would be an ISO-9660 file system, like "growisofs -Z /dev/cd0=stuff.iso" (with a premastered file stuff.iso). In _this_ case, the input data is read directly from file descriptor 0, stdin. Whatever appears there, it will be written to the media. Here it is dump's output data stream. > If so, how would I do this? Would a command > such as the following work? > > /sbin/dump -0u -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u > > If not, why not? As far as I know, direct device access for writing does not work here. There are some operating systems that support an approach like this (IRIX for example, if I remember correctly), but FreeBSD doesn't. Depending on your OS version, acd0 != cd0 might appear, being different in access method, i. e. ATAPI vs. ATAPICAM ("SCSI over ATA"). > Actually, I just noticed in the dump manpage the -f option. So would this > work in place of the above command line? > > /sbin/dump -0u -L -C16 -B4589840 -f /dev/acd0 /u > > And if THAT works, then can dump properly sense the actual end-of-media on > /dev/acd0, so that the -B option can just be ommitted? I've never tried if /dev/acd0 (or /dev/cd0 for the reason mentioned above) would be able to "start a writing session" by receiving data in that kind of way. The -f option is typically used to send data to files, or to - to hand them to another program or pipeline. It seems that doing so for devices (and causing the _physical_ devices to do something with it) is not possible. > Another issue is that I most definitely want to use an absolute minimum > of DVD+Rs to store the dump. So I am wondering how I might be able to > wedge gzip into this whole process. Could I do something like this? If > not, why not? > > /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u Taking the initial approach of /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u it could be something like this: /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u Not tested, just an idea. Just check how -P interacts with /dev/fd/0 and - for "stdin" _within_ the pipe command. > Lastly, I want to make a backup of one entire _system_... not just one of > the several partitions that compose that system. How exactly can I do > this? At least not with dump. The dump utility operates on file systems, this means "it takes partitions as input". Whatever is _one_ partition can be processed "per step". Maybe you could concatenate runs of dump of all the present partitions; however it will be a bit more complicated to restore them using the restore program, which reads file system dumps and outputs the data to initialized and mounted file systems. > I mean sure, I can back up each partition separately, using dump, > one at a time, but if I do that then the logical implication would seem > to be that on the last DVD+R used to make a backup of each of the partitions, > there could possibly be a lot of unused/wasted space which could have been > used to store the first part of the dump for the next partition in turn. Yes, that is quite possible. In this case, using dd would maybe be better. You would use it to copy the whole disk containing all the partitions, add gzip, break it into "multi-volume parts" and then record it to DVD+R. > Is there any way to effectively deal with _this_ issue? Not per se, but I think all the required parts are in the system, it's just the question of how to efficiently combine them to meet your request. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...