You have to embed your metadata into the logical file names or the
physical file names. There is no extra annotation beyond those two
entities and the mappings between them. So maybe just using a DB
that has the schema of your choice would be more convenient for this
exercise.
Charles
On Jan 15, 2008, at 4:49 AM, Baas Saab wrote:
Does RLS allow me to associate metadata along with it? For example,
if I have backed up 10 files in one session and 20 files in the
next session, is there some place in RLS where I can store this
info saying the following
Backup 1 --> File1, file2, file3.... File 10 | Date: 15/Jan/2008 |
Time: 16:00 | Client name: host1 | Backup location: host5:/etc/tmp
Backup 2 --> File 1,...... File 20 | Date: 16/Jan/2008 | Time: 2:00
| Client name: host2 | Backup Lcoation: host6:/etc/free
So that, during recovery, I query the RLS to get a list of files
backed up at a particular time, from a particular client. This
boils down to whether a query can be made to the RLS based on the
metadata stored.
~Baas
On 14/01/2008, Charles Bacon <[EMAIL PROTECTED]> wrote: Storing it
in a database is a fine idea. You could also use the
Replica Location Service for this task, I think. RLS make a map
between logical names (like "Files to be backed up on date nn/nn")
and physical file names (like "host1:/path/to/file" and "host2:/path/
to/other/file") that you can query and create with commandline tools.
Charles
On Jan 14, 2008, at 10:45 AM, Baas Saab wrote:
> Hi,
>
> I am trying to implement a storage service. This requires me to
> store an index of the names of files that have been backed up,
> client hostname and the time when it was backed up. During a
> recovery, I want to find out from my index as to where the backed
> up data resides and fetch it from there.
>
> How can I maintain an index of the files backed up along with the
> client name and date/time? Should I just create a database and
> dump these values so that the or is there a better way to do it
> with Globus toolkit? (I want this index of files to reside on
> secondary storage. ).
>
> Regards,
> Baas
