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

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



On Wed, 29 Oct 2003 12:52, Paul M Foster wrote:
> 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

Paul,

Have a look at your mkisofs in your original post above. All you are doing is 
re-recoding the contents of your cdrom.

Bob



Reply to: