Re: Perfomance problem backupscript (more details and tests)

Hi,

> > No file is assumed old unless all its parent directories
> > are old or unless its checksum has been verified. The
> > parent directory assumption may be disabled if the user
> > is very mistrusting.
> 
> This forces you to have a persistent and probably big checksum
> database.

Yes. Typically it occupies 1/1000 of the payload size.
A main obstacle is that it has to be loaded to RAM
in order not to disturb the tree crawling by frequent
database file access.
Not to forget the need to read a substantial part of the
backup area's data. If somebody changes a directory near
/ then the computation time increases heavily.

This is eased by the fact that the user is free to shape
the backup area and thus may easily divide a big area
into several smaller ones which do not overextend RAM
or working hours.

The main reason to do incrementals and not complete backups
was the saving of media and the fact that there is no operator
needed for the time of the incremental planning process. 

But now, with inode numbers rather than CRCs this runs
so swiftly that i had to optimize away several other time
wasters which did not become obvious before.


The memory requirement will not be eased in future. It is
intrinsic to my approach and, of course, gives programs
like star a good opportunity to outperform scdbackup.
That's not too bad, since i offer my users to chop any
archive output to media if they don't want to use my own
backup planner and formatters.
I meanwhile recommend to use star level=0 running under 
rescue system RIP to make backups of the shutdowned system
partition. This allows disaster recovery within minutes
after the hardware is up again.

Nevertheless, for a multi-media collection, i deem my
incremental ISO-9660 backups to be very valuable.


Have a nice day :)

Thomas