Cindy,
(Richard, look at the bottom)
Is it the "last modification" time what your customers need?
It looks so, because, as Richards correctly states,
in unix restored files (and dirs) will never
have "creation time" stamp they did at backup time,
and as your customers seems to be happy with
time stamps on the files you restored,
they cannot have checked creation dates.
In fact, all - although there are not many -
apps I know that check time stamps
of dirs, do check "last modification" stamps.
Check it, and, if the application of your
customers really uses "last modification"
or "last access" (the later is improbable),
we have a good chance to either
set or at least to approximate
this times and so serve your customers.
( If this is not the case, and the application
does use the "creation time" stamps,
then we have no simple chance to recreate
original state. In that case we would have
to blame the application,
because it had not not reflected the "ever"
existing features of OS. )
First, we try to find the correct times out,
second, to set them in the directories.
First A) try to restore the directory tree (directories only)
with correct time stamps to another location.
I cannot test it for you in unix now, but I remeber it works
in OS2 and NT. The syntax would be approximately:
dsmc restore /Your/Path/Of/Interest /Temporary/Path/For/DirsRestore/
-dirsonly -subdir=yes -pittime=... -pitdate=...
Be better superuser while doing that.
Should it not work under unix at all,
which I do not believe, goto (First B).
Should it not work, because your backuped directories
have been already expired - all chances lost,
phone your customers about it and have a drink.
First B) Well, we failed to obtain the original
times through restore.
Let us try to get approximate times at least:
dsmc restore /Your/Path/Of/Interest
-dirsonly -subdir=yes -pittime=...
-pitdate=... -pick > pick.lst
will list backup times of the directories.
This is not exactly what you need, the time error
can be as large as the interval between your backups,
but it could hopefully be good enough for the application.
Second:
Now use the "touch -am" command to change time stamps
on your directory tree.
( A) touch -am -r ...
( B) touch -am -t ...
Let yourself help by an unix guru in
creating an appropriate script.
Do begin at lowest directories, e.g.
touch ... /dir1/dir2/dir3/dirA
touch ... /dir1/dir2/dir4/dirB
touch ... /dirX/dir2/dir4/dirB
and work yourself through higher and higher diretcories
up to the root of your interest:
touch ... /dir1
touch ... /dirX
Good luck!
Richard,
we seem to have different attitude to our roles.
You stated some good examples where
the exact restoration is either not possible
or not meaningfull by a file-oriented backup system.
You are right in your examples, although you
chose requirements I particulary did not have at all.
But you did not argue is
why I should not do a best attempt
in restoring as exact as possible copy
and why I should not require the same
from the backup software.
That means, all data, metadata and attributes
which can be set and changed by users and applications
through regular, common API´s
should be candidates to backup and restore.
This includes all time stamps one can trimm with touch command.
Excluded are data/attributes beeing set
and used/meaningfull by/for OS itself only.
This is my understanding of my role
against my customers, who can be blamed
neither for using the regular features of an OS
nor for requiring stability/reproduceability
of their computing environment,
and are definitely worth of each help
I can supply. Even if I "knew better".
And, there is an inconsistency in your argumentation.
You argue that my requirement, while not wrong,
is not for traditional *SM (meaning ADSM).
But ADSM/OS2 and ADSM/NT do fulfill my requirement
to best possible extent, so what?
ADSM/unix is traditional *SM and ADSM/OS2 not?
Sorry, differencies remain.
Salak Juraj
KEBA AG
Linz
Österreich
Tel. ++43/732/7090-7461
Fax ++43/732/730910
e-mail: sal AT keba.co DOT at
www.keba.co.at
|
