Hi, >> For example : what happens if you have to shut >> down your machine after half a backup of 50 CDs >> is done. >> Can you do the rest next day ? Without starting >> new (and not getting done until evening again) ? > > If you are doing real reliable backups, you can't because > you cant't have a Filesystem snapshot that survives a reboot.
With the agile system files in a Linux root filesystem one should not do that. But that are at most a few GB. A 100+ GB disk full of digital images, CAD drawings and models, movies, a website plus backup archives of several workstations is well suited for that. With 2x DVD it is hard to do it within a single work day. Even with 4x you have to be very attentive. Of course, checkreading has to be done by a second computer meanwhile. Among 20+ reused DVD-RW i expect to have one or two bloopers. (Not to speak of 100+ reused CD-RWs.) One has to deal with such situations if one wants to backup contemporary hard disks. I believe that it is necessary to separate the system backup from the user data backup. For the hardcore system part i do agree with most of your opinions about backups. For the user data part i am with the majority of ISO-9660 enthusiasts. >> Mmm, if you (as you said) do it at backup time, how do you >> move that information to the restore operation? A move causes the file to appear with all its data and properties under its new name in the next backup level. For old names of files which have been moved or have been deleted, there is a remover script generated at backup time which is to be applied before the backup data of a level >0 are copied to the restore target. This can be done manually by the user. http://scdbackup.webframe.org/examples.html#restore_incr http://scdbackup.webframe.org/beispiele.html#restore_incr Not as convenient as with star's -restore but sufficiently reliable, i think. It's not too bad if you take into account that it is done with vanilla ISO-9660 CDs or DVDs. The script is included in the level backup, of course. Here mkisofs -graft-points comes in very handy. The more secure variant is a remover list with checksums which provides safety against removing files with surprisingly different content. But for that you need scdbackup at restore time. In the normal situation that you populate a previously empty tree, there is not much need for checking before removal, though. My incremental method costs more time and media than yours. An advantage is that i got the old data file under its new name on the younger level's media. So picking moved files manually is much easier than with your method. Actually scdbackup does not know about moves but about: arisal, type change, young timestamp, content change, vanishing. The first four events bring the file object into the level backup. The type change and the vanish event bring the file's address into the remover script. Inspired by star i'm introducing an inode change event now. It will hopefully make the content change test obsolete. (If type change and young timestamp really cover any other significant change.) My theory about star stems from watching the work of level=0 level=1 -restore, from binary peeking into the archives of level 0 and 1, from peeking into star-symtable after restore of level 0 and after restore of level 1. After that i believe to understand why most of the restrictions apply, which are mentioned in star's man page. Ignorantly, i did not analyze any source code. I believe that your younger level does store the name change of the inode but the data of this inode are only on the older level backup. Moves seem to be known only to -restore . Up to now i cannot get them to show up in the traditional table of contents. So up to now i don't see the way to manually retrieve a moved file of which i only know its new name. I will reread the man page for special table-of-content options. I would need something to obtain the backup-side inode number of my lost file and then to scan the previous levels for the data of that inode number. Now i have summarized half of the emerging report about my experiences with star. I'll have to overhaul it. > See star.berlios.de Used as http URL this leads me to " Welcome to http://star.berlios.de We are sorry but this project has not yet uploaded its personal webpage yet. Please check back soon for updates or visit BerliOS Developer Project Homepage. " An attempt to use ftp://star.berlios.de was rejected. It must have fallen victim to some sysadmin. (Sorry guys :) I got my first star-1.4.3 via Google and http://cdrecord.berlios.de/old/private/star.html Ah, there's the mailinglist link again. (I am smart) What ? Certificate ? "pretending to be *.berlios" ? (Mozilla is very worried about my safety. It supposes the sysadmins of berlios.de to be evil or non-skilled.) Who cares, i pretend to be smart. I accept temporarily. For the records, star mailinglist info page: http://lists.berlios.de/mailman/listinfo/star-users Well, later. When i'm done with my inode stuff and explored some other features of star. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
