George Sinclair wrote:
>
> I'm not sure how to explain what I'd like to do, but I'll try my best.
> We have two main pools we use: FUL, ATL. The FUL pool is used for only
> full savesets and the ATL pool is used for all incrementals and levels
> (5, 4, 3, 2, etc.) except 0. Client indexes go to one of the two pools
> depending on the level of the backup.
>
> I'd like to create a new pool (ARC) for some special data so it will be
> on its own set of tapes. My plan is to have this data get backed up to
> this pool and only this pool regardless of level. The problem with
> having this data go to the other pools is that I never want to recycle
> it, so it makes it difficult to extricate the data when I want to
> recycle tapes in the FUL and ATL pools. I would end up having to cloan
> the special data savesets before I could recycle the affected tapes,
> and I want to avoid that.
>
> Getting the desired data to go to the new pool, and only the new pool,
> should not be too hard since I can set up a group and place only that
> group in that pool, but how would I get the index for that client to
> write to that pool? The problem is that there is other data on the
> client that would be fine to go to the other pools, but I guess there's
> no such thing as multiple client index instances? I mean, each client
> has one and only one index, so I'm thinking that I can't have the index
> for the special data go to the ARC pool and the rest of the index go to
> the other pools as usual? I guess not as there's one and only one index
> per client. Regardless, if I did want to send that client's index to the
> ARC pool, how can I do it? I'm thinking that this may not be possible,
> so I might have to manually clone the indexes to a clone pool like
> ARC_clone? Isn't it true that client indexes go to whatever server is
> listed first in the storage node servers field for the primary server
> client?
>
> If I do this, how would I recover them (or merge older versions in:
> nsrck -L7 -t date) from this pool and not have NetWorker use the indexes
> it had backed up to the other pools?
George,
I've been giving this some thought and have run a few tests. I'm not
sure I've totally got my head round what you are trying to accomplish.
First of all, where do your indices go to for a given client? The answer
is: to the index, on disk. This might sound a bit stupid, but what I'm
pointing out is that your index is your index, and that a tape backup of
your index is just a backup. If you run a client in two different groups
with pools associated, generally you will also backup your index to the
same pool as your data save sets, unless you have configured it
otherwise. The index backup that you run after backing up the data is
the current and freshest index. It will contain all currently available
data for the client.
So, without doing anything out of the ordinary, you have backed up the
index to the correct pool. If you are retaining different pools for
different periods, you will still have the most appropriate index
backups in each pool, even if you recycle volumes from other pools. What
could be simpler?
The only (very minor) thing wrong with the above scenario is that your
backup of the index contains all the index data for this client at this
time. This might not be all that relevant in 5 years time when you
decide you would like to recover this index using nsrck -L7. However,
what has it cost you? Just a small amount of tape. Probably not worth
doing anything differently IMHO.
If you do wish to split up the index for a particular client you can in
fact do it. Shelley might be pleasantly surprised to find out that she's
wrong. The key lies in the -c option to save. By putting "save -c
otherclient" in the backup command you can redirect some of your index
data to a different index. The different index has to relate to a client
resource, which you will need to create for this purpose, thus costing
you a client licence. The extra client resource has to have a name which
resolves correctly, requiring a DNS or hosts file entry, even though a
physical machine with this name is not required. If the backup is not a
standard filesystem backup, then most of the Enterprise modules can
cope, but I won't go into detail here.
Personally I think this scenario is not worth the trouble, but if you
are determined you can make it work.
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
