George,
Now I'm not sure if I'm missing a complication here, but in the
"pools" window (using the GUI), you can choose, for any Pool, which
groups write to it, and, under the "Save Sets" window, you can name
savesets. In my setup, I have "bootstrap" and "index:*"
Looking at my Index.xxx volumes, I have entries like:
tapes.dfci.harvard.edu 09/29/03 9 recoverable
index:ressrv10
tapes.dfci.harvard.edu 09/29/03 full recoverable
bootstrap
Is there something beyond this sort of thing you want to accomplish?
Matt
On Tuesday, Sep 30, 2003, at 14:36 US/Eastern, Davina Treiber wrote:
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
========================================================
Matthew Temple Tel: 617/632-2597
Director, Research Computing Fax: 617/632-4012
Dana-Farber Cancer Inst mht AT research.dfci.harvard DOT edu
44 Binney Street, M L105 http://research.dfci.harvard.edu
Boston, MA 02115 Choice is the Choice!
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
