>More generally, in my understanding it is most basic requirement
>for a backup/restore service to (be able to)
>a) backup the original system without changing it, and
>b) restore the original system, w.out either information loss or change.

Then maybe *SM is not the package you should be using...

*SM has thus far been a file-oriented backup package.  As such it cannot
back up ordinary, read-write file systems without changing their attributes
(because the file access timestamp reflects the read operation, in file
I/O).
And it is physically impossible for it to restore objects such that they
are exactly the same as they were in the original file system.
You may not get directories back with the same timestamp, and probably not
the same size (which in itself is a good thing, given directory inflation
over time).  Symbolic links will not have the same creation date - and maybe
not the same owner.  In Unix, none of the files restored will have the same
ctime stamp they did at backup time.  This just reflects the realities of
operating within the rules of a file system.

The kind of restoral you outline calls for a physical image backup of
disks, which is quite a different thing and which precludes retrieval
of individual objects from the backup store (without heroic programming).
There's nothing wrong with such a requirement - it's just not
traditional *SM.

    Richard Sims, BU