Hi,
I allow myself to disagree with the "incongruous with" statement.
In fact, since it´s beginings has ADSM/TSM learned
some new functionality going in the direction of higher-level
naming of backups and handling one backup instance as single entity.
Most notably virtualmountpoint, backup sets, UNC naming support.
Up to some extent various improvements in archive/retrieve, introduction of
point-in-time restore
and introduction of backup groups.
This are major paradigm changes compared to adsm v1.x
where in many cases the tsm user had to cope with single "datasets"
(for those who do not know
the old ADSM: this were simply single version of unique files)
I can imagine many various ways how to extend TSM functionality so
to simplifiy handling of file ressources
beeing moved to new locations
and to simplifie organisational issues
with medium-to-long-term backups featuring stuff changes
while keeping the TSM´s file system character.
Just 2 examples of many imaginble:
1)while using existing capabilities of TSM
run backups against shared ressources,
like "dsm incr \\server\\ressource\*".
This way, if the ressource is moved to another location on the same file
server (along with files it contained),
the backup would not notice the change of physical location.
So would not the TSM stuff.
2) new TSM functionality: added description to incremental
backups, analogous to archives:
dsm.opt:
include.file c:\applicaion1DataDirectory\...\*
description="BackupDescription#1"
descriptionValidIn="allNodesInTheCurrentTSMDomain"
This would require manual change of OPT file when moving the DIR1 to another
location,
but it only had to be documented once for all times
for users of application1
how to restore their application data.
The documentation remained valid even after the data had been moved to
another server.
Hmm?
best regards
Juraj Salak
-----Ursprüngliche Nachricht-----
Von: Richard Sims [mailto:rbs AT BU DOT EDU]
Gesendet: Freitag, 27. Februar 2004 14:08
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: Strange RETRIEVE behaviour
>Is there no way to avoid specifying the entire source path?
>
>The reason I want to do this is that I have to be able to retrieve files
>(from several years ago) with an automated procedure, and I don't want to
>get into the hasle by finding out the source path by issueing one or more
>query commands from the client side.
Well, objects have to have some "name" in order to be identified for
selection, and this is fulfilled by the file system path spec for the
file. This is just basic "addressing". I gather that you have files
archived from various places in the file system: if so, then you obviously
have no recourse but to specify the path as part of the Retrieve...to
address the object you want back. If all archived files are from the same
directory, then you can 'cd' into that directory and then retrieve by file
name, where the path is implicit in your current directory. But either
way you are dealing with the realities of file system locationing.
I think what you're looking for is a whole new paradigm in the addressing
of file objects; but that is incongruous with the accommodations of file
system applications such as TSM.
Richard Sims, http://people.bu.edu/rbs
|
