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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
