[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DEB-USER] Re: Incremental CDR backups



On Wed, Oct 29, 2003 at 02:44:16AM +1100, bob parker wrote:

> On Mon, 27 Oct 2003 11:08, Paul M Foster wrote:
> > I'm having difficulty burning incremental CDR backups. (Using Debian
> > 3.0r1/testing.) They burn fine, but when I mount the CD after the second
> > and subsequent backups, all I can see is the original session.
> >
> > Here are the commands I give Linux:
> >
> > (First burn)
> >
> > mkisofs -r -o /tmp/cdimage /home/paulf/cdrom
> > cdrecord -v -multi speed=4 dev=0,0,0 -data /tmp/cdimage
> >
> > (Second burn, after creating a new bunch of stuff to backup)
> >
> > NEXTTRACK=`cdrecord -msinfo dev=0,0,0`
> > mkisofs -r -o /tmp/cdimage -C $NEXTTRACK -M /dev/cdrom /home/paulf/cdrom
> > cdrecord -v -multi speed=4 dev=0,0,0 -data /tmp/cdimage
> >
> > According to the CD-Writing-HOWTO and the README.multi doc file from the
> > cdrecord disto, this should do it. But all I see is the original session
> > when I mount the CD. (And no, I don't want to do this with a GUI,
> > thanks.)
> 
> Paul,
> You need a way to select files to backup that are newer than the previous
> backup. So:
> 
> cp -p /var/backup/control /tmp/control
> where /var/backup/control was 'touched' at the time of the previous backup.
> followed by:
> touch /var/backup/control
> 
> Also, you need to give a unique file name for each backup.
> Something like:
> OFN="backup_incr-"$(date -I)".tgz"
> then:
> tar --create --gzip --file $OFN \
> --newer /tmp/control \
> --exclude *.iso \
> --exclude *.wav \
>  /home/paulf/
> 
> After that:
> touch /var/backup/control
> 
> You can use as many --exclude options as you want to avoid backing up such
> stuff as your browser cache and so on.
> 
> If you don't want to tar and zip your backup you can use the -graft-points
> option of mkisofs to create a dir on the cdrom based on the date of backup or
> similar. See the man page.
> 
> Then the iso for the first burn
> mkisofs -r -o /tmp/cdimage $OFN
> burn it
> 
> subsequent burns
> mkisofs -r -o /tmp/cdimage -C $NEXTTRACK -M /dev/cdrom $OFN
> and burn it.
> 
> And I agree with you, leave the GUI stuff out of this, it adds complication
> for no real gain.

There must be something I don't understand about this. For the sake of
brevity, here's an example. First burn is /home/paulf/docs. It contains
the files alfa, bravo, charlie and delta. I make an ISO of this, stored
in /tmp/cdimage. I burn it to CDR and delete the /tmp/cdimage file. A
week later, I've updated the bravo file and added an echo file. Now I
make an ISO of the /home/paulf/docs directory, and burn that to the CDR. 
Now when I look on the CDR, what I see is the _original_ burn. All this
is using the commands I mentioned above (normally I'd snip email,
but...).

Now, my original thought was that mkisofs/cdrecord process would simply
add the new echo file, and show an updated version of the bravo file,
while leaving the rest alone. Sort of like the way it works on a hard
drive, except that the space taken up by the old versions of files (like
bravo) would still be "used". This appears to be the way my wife's
software on Windows works. But I can't seem to make this work on my 
Linux box.

Any pointers to help me understand this would be appreciated.

Paul



Reply to: