Our environment is not sized to do full backups on all our clients on
one specific night. Full backups (or weekly/monthly backups) are
distributed over the week. I don't believe group schedules would work
in this case.
Also, our browse times always match our retention times. If the data
still exists on a tape, we want our users to be able to restore the data
without having to intervene and run scanner to rebuild the index. So,
our retention time for our daily backups is shorter than our browse time
for monthly backups.
We can meet these requirements with the multiple definitions which
specify the different schedules, groups and retention times.
Thanks.
Teresa
-----Original Message-----
From: Davina Treiber [mailto:Davina.Treiber AT PeeVRo.co DOT uk]
Sent: Wednesday, March 19, 2008 12:50 PM
To: EMC NetWorker discussion; Teresa Biehler
Subject: Re: [Networker] index default browse and retention
Teresa Biehler wrote:
> We have at least 3 client definitions for each client. In fact, in
some
> cases (Exchange, MS SQL), we have more than 3. We do this to get the
> data retention and pool separation that we need for our daily, weekly
> and monthly backups. Initial set-up was not fun, but it is not too
> difficult to manage. You do, however, need good processes including
> scripting common tasks (creating clients, updating groups, etc.).
If you are doing Exchange, MS SQL, and filesystem backups for the same
client, you will need multiple client resources as each of them will
have different save set lists and backup commands.
However if you are backing up the same save sets with the same backup
command and all that changes is the pool and/or retention you can
achieve the same effect without as many client resources. All you need
to do is make the client a member of multiple groups. Each of these
groups can have different schedules (which overrides the schedule set on
the client) and each group can be assigned to a different pool, allowing
the data to be have a different retention (specified on the pool).
One slight snag may occur if the browse period is longer than any of the
retention periods set on the pool - as pointed out by another poster
earlier today. There is no easy solution to this - other than for the
developers to have done the job properly.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
