Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 05 Nov 2012 11:51:04 +1000
From:      Da Rock <freebsd-questions@herveybayaustralia.com.au>
To:        freebsd-questions@freebsd.org
Subject:   Re: Questions about dump/restore to/from DVD media
Message-ID:  <50971B88.40303@herveybayaustralia.com.au>
In-Reply-To: <20121105021817.fc5bff1b.freebsd@edvax.de>
References:  <20880.1352077018@tristatelogic.com> <20121105021817.fc5bff1b.freebsd@edvax.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/05/12 11:18, Polytropon wrote:
> 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=<file>" 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. :-)
>
>
>
Also, you may have considered this already (or not :) ), but you are
using a direct write to backup your system, and then considering
compression on top of that. CD/DVD filesystems incorporate some parity
to allow for defects and scratches, so growisofs might be best to use to
ensure some integrity to your data.

Minimising your space may be good, but a single bit could render all
your efforts for nought- especially given the compression leaves no room
for error ;)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50971B88.40303>