On Tue, Feb 06, 2007 at 10:33:31AM -0500, Josh Grosse wrote:
> On Tue, Feb 06, 2007 at 12:38:02PM +0100, Joachim Schipper wrote:
> > ISTR that there was a piece of software called 'shunt' that would pipe a
> > specified amount of data into certain commands, then close and re-open
> > the pipe. This is basically what split does, but writing to a pipe
> > instead of files.
>
> Good memory: http://www.serice.net/shunt/
>
> It's not in the ports tree, but I will look into what it can do, if it works
> for me I will report back, and then port it. :)
Always good!
> > Otherwise, try:
> >
> > #!/bin/sh
> >
> > dump ... | {
> > i=0;
> > while dd bs=$BIGNUM count=$BIGNUM2 | \
> > mkisofs -stream-media-size $SIZE ... | \
> > cdrecord ...; do
> > echo "Burned CD $i - press return to continue";
> > read </dev/tty;
> > i=$((i+1))
> > done
> > }
> >
> > Or some variant on the above that actually works (dd might or might not
> > be necessary, for example).
> >
> > You'd have to try a couple shells to figure out whether you can get by
> > with /bin/sh, or if you really need ksh.
> >
> > Of course, the only way to restore is piping all STREAM.IMG on all those
> > DVDs into a similar script.
>
> AFAIK, STREAM.IMG is limited to 4.0GB, if I go one kilobyte over, the
> STREAM.IMG
> created by -stream-media-size will be invalid -- the filesize wraps.
> So I still need two iso files per disc, as I have now.
>
> -stream-media-size cannot be used in any multisession .iso file. I would need
> to concatenate two separate .isos for burning, then split them for restores.
> would have to find a way to concatenate two .i
Yes, you are right - or were at some time at the past, but I don't
suppose this has changed. Sorry!
(Obviously, when I was looking into this, I was burning CDs; such a
limit is pretty irrelevant there.)
There are also some backup packages that do pretty much the above, but
without constructing a ISO9660 filesystem in between. Since the
resulting dump can only be read with specialized software [1], anyway,
breaking interoperability further may not be that big an issue.
If you are trying to get fancy, add checksums and/or redundancy. Note
that gzip-compressed data is very vulnerable to read errors, which is
one reason why I've seen people recommend bzip2 (the increased
interoperability of gzip is nice, though, and bzip2 is supposedly very
slow - though my PC has always been able to keep up with its burner,
which is sufficiently fast as far as I'm concerned).
Joachim
[1] Such as the above ten-line shell script, but still. Reading this on
Windows isn't as trivial as one would like.
