Re: mkisofs aborts but exit value is 0
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
Reply to: