Veritas-bu

[Veritas-bu] Re-evaluating policies - the other side

2004-02-24 08:07:33
Subject: [Veritas-bu] Re-evaluating policies - the other side
From: Harry.Schaefer AT turner DOT com (Schaefer, Harry)
Date: Tue, 24 Feb 2004 08:07:33 -0500
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3FAD7.2A9FCFD8
Content-Type: text/plain;
        charset="iso-8859-1"

I may get flamed on here for telling everyone what we do, but we have about 
600+ clients and they all have their own policy. Some clients even have 
multiple policies. There are a few reasons we have for doing this:

- Flexibility. If Server X is down for maintenance, it is a lot easier to 
disable the policy for a night as opposed to deleting the client out of a big 
policy and have to add it back later. We also run a inactive policy report to 
make sure nothing gets left behind.

- Restarts. We have a few Win clients that have multiple drives each over 
200-300 GB. If we have a full backup failure, it is a lot easier to restart a 
policy for one drive letter as opposed to re-running the whole server.

- Administration. Seriously. :-) Each policy is descriptive in regards to the 
client. I see a policy job fail, I know exactly what server had a problem. Once 
the policies are established, they are done. Massive policy changes can be 
achieved through shell scripting (Solaris master/media server).

Harry S.
Atlanta


-----Original Message-----
From: Timothy Arnold [mailto:timothy.arnold AT becta.org DOT uk]
Sent: Tuesday, February 24, 2004 4:53 AM
To: Timothy Arnold; veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] Re-evaluating policies


Thanks to all who replied. To summarise:

The consensus is to have as few policies or volume pools as possible to make 
administration of Netbackup easier. Two possible solutions outlined for my 
environment were:

1. Add all UNIX servers into one policy or perhaps split them into two policies 
with different start/end times [thanks Steven]. 

2. Create multiple policies based on the speed and network performance of the 
servers and group them accordingly.

I have to say I am in favour of grouping the systems based on speed/network 
performance. In my environment we typically have the same hardware in the same 
network segment so I could create four or five policies based on hardware type 
i.e. E3000, V210, E250 etc and add servers accordingly. This will drop my 
current policies from thirty to around five - not bad going! [Thanks to Kate 
for this suggestion]

One other interesting suggestion was different policies if multiplexing is 
enabled or not. To be honest, I have yet to look at multiplexing. Is it worth 
using it for my backups? (I only have a single SDLT drive at the moment).

The other part of this question was specifying the file systems to backup. Some 
systems will have three file systems and others will have to (i.e. just / and 
/var) as these systems were partitioned in a different way. The recommendation 
was to use ALL_LOCAL_DRIVES. The question I have is that I have an A5000 with 
lots of file systems and would prefer to backup these independently but do not 
want to build an exclude list (as I will most likely forget to edit it when I 
add a new file system). What happens if I specify a file system like /usr in a 
policy but is not a separate file system but part of /? (hope I made myself 
clear). 

I guess what I could do is create a separate policy for the servers that are 
connected to the A5000 and manually specify the file systems to backup instead 
of using ALL_LOCAL_DRIVES (as all the other servers will need all the local 
file systems backed up).

Now for application backups. As I said previously, I have a number of file 
systems that will need to be backed up but on different schedules dependent on 
how frequently the file systems change. The other difficulty with this is that 
I use virtual IP addresses for each 'application' as they are in a four node 
cluster and use that interface to backup (as I never know where it is going to 
be on the cluster). What is the best way to define the policies?

While writing this, I am thinking that I could create two policies, one for 
daily backups and one for weekly backups and then define all four 'real' ip 
addresses for each server. I am making the assumption that it will only backup 
the file system that is mounted on one of the nodes but simply skip the file 
system on the other nodes as its not mounted. Would that work? How would I go 
about restoring the file system if I didn't know which server it came from?

The last part was the question about tape rotation. It would appear that 
Netbackup 5 automatically moves tapes to the scratch pool when they expire 
(hurray!). Now the question is how do I import and eject tapes for last nights 
backup? Does anyone have any good systems for automating this and labelling 
tapes etc so they can easily be found... (I admit I might only have sixty tapes 
but is still a big pain!)

Thanks for everyone who has replied and look forward to more responses.

Timothy.

PS: Kate, Is NB5 really that unstable?




-----Original Message-----
From: Timothy Arnold 
Sent: 23 February 2004 18:18
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Re-evaluating policies


Hi Netbackup Guru's!

I am about to embark on upgrading to Netbackup 5. I thought it might be a very 
good time to re-evaluate our policy configurations and see if there is anyway 
to improve the current system and make it more simple and easier to use. I 
would like to ask a few questions to see what you guru's think.

Our configuration is fairly simple. About thirty Unix clients connecting to an 
Sun L25. Four of the servers connect to a couple of A5000 arrays that host 
application data.

With this in mind each system will have its own schedule for system backups 
that run weekly and another schedule for application backups that run daily. We 
have virtual IP addresses for applications so I use the virtual IP in its own 
policy, so in affect I have three 'kinds' of policies.

So my first question is, can I consolidate the system backups into one policy? 
Is this recommended? The systems will always have / and /var but not always 
have /usr - will I need to split the policy dependent on which partitions I 
have? This would reduce the number of polices from thirty to one!

The other question is relating to tape rotation. In NB3.4 figuring out which 
tapes have been written to was a complete nightmare and I eventually wrote a 
shell script to automatically figure out which tapes had been used and emailed 
the operator which was fine, the only issue I had was that new tapes that have 
been used in a volume pool got put back into the same volume pool and was 
unavailable to the other pools unless you moved them using another script - 
seams like a little bit of a fudge to me! Does anyone know if tape rotation has 
been improved in NB5? If not, would anyone like to share any shell script with 
me (as I am sure they are better than my badly written shell scripts)!

I would appreciate any feedback and would be very interested to hear how other 
people have configured and maintained their Netbackup environment.

Thanks,

Timothy.


------_=_NextPart_001_01C3FAD7.2A9FCFD8
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>Re-evaluating policies - the other side</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I may get flamed on here for telling everyone what we =
do, but we have about 600+ clients and they all have their own policy. =
Some clients even have multiple policies. There are a few reasons we =
have for doing this:</FONT></P>

<P><FONT SIZE=3D2>- Flexibility. If Server X is down for maintenance, =
it is a lot easier to disable the policy for a night as opposed to =
deleting the client out of a big policy and have to add it back later. =
We also run a inactive policy report to make sure nothing gets left =
behind.</FONT></P>

<P><FONT SIZE=3D2>- Restarts. We have a few Win clients that have =
multiple drives each over 200-300 GB. If we have a full backup failure, =
it is a lot easier to restart a policy for one drive letter as opposed =
to re-running the whole server.</FONT></P>

<P><FONT SIZE=3D2>- Administration. Seriously. :-) Each policy is =
descriptive in regards to the client. I see a policy job fail, I know =
exactly what server had a problem. Once the policies are established, =
they are done. Massive policy changes can be achieved through shell =
scripting (Solaris master/media server).</FONT></P>

<P><FONT SIZE=3D2>Harry S.</FONT>
<BR><FONT SIZE=3D2>Atlanta</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Timothy Arnold [<A =
HREF=3D"mailto:timothy.arnold AT becta.org DOT uk">mailto:timothy.arnold@becta.=
org.uk</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 24, 2004 4:53 AM</FONT>
<BR><FONT SIZE=3D2>To: Timothy Arnold; =
veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Veritas-bu] Re-evaluating =
policies</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Thanks to all who replied. To summarise:</FONT>
</P>

<P><FONT SIZE=3D2>The consensus is to have as few policies or volume =
pools as possible to make administration of Netbackup easier. Two =
possible solutions outlined for my environment were:</FONT></P>

<P><FONT SIZE=3D2>1. Add all UNIX servers into one policy or perhaps =
split them into two policies with different start/end times [thanks =
Steven]. </FONT></P>

<P><FONT SIZE=3D2>2. Create multiple policies based on the speed and =
network performance of the servers and group them accordingly.</FONT>
</P>

<P><FONT SIZE=3D2>I have to say I am in favour of grouping the systems =
based on speed/network performance. In my environment we typically have =
the same hardware in the same network segment so I could create four or =
five policies based on hardware type i.e. E3000, V210, E250 etc and add =
servers accordingly. This will drop my current policies from thirty to =
around five - not bad going! [Thanks to Kate for this =
suggestion]</FONT></P>

<P><FONT SIZE=3D2>One other interesting suggestion was different =
policies if multiplexing is enabled or not. To be honest, I have yet to =
look at multiplexing. Is it worth using it for my backups? (I only have =
a single SDLT drive at the moment).</FONT></P>

<P><FONT SIZE=3D2>The other part of this question was specifying the =
file systems to backup. Some systems will have three file systems and =
others will have to (i.e. just / and /var) as these systems were =
partitioned in a different way. The recommendation was to use =
ALL_LOCAL_DRIVES. The question I have is that I have an A5000 with lots =
of file systems and would prefer to backup these independently but do =
not want to build an exclude list (as I will most likely forget to edit =
it when I add a new file system). What happens if I specify a file =
system like /usr in a policy but is not a separate file system but part =
of /? (hope I made myself clear). </FONT></P>

<P><FONT SIZE=3D2>I guess what I could do is create a separate policy =
for the servers that are connected to the A5000 and manually specify =
the file systems to backup instead of using ALL_LOCAL_DRIVES (as all =
the other servers will need all the local file systems backed =
up).</FONT></P>

<P><FONT SIZE=3D2>Now for application backups. As I said previously, I =
have a number of file systems that will need to be backed up but on =
different schedules dependent on how frequently the file systems =
change. The other difficulty with this is that I use virtual IP =
addresses for each 'application' as they are in a four node cluster and =
use that interface to backup (as I never know where it is going to be =
on the cluster). What is the best way to define the =
policies?</FONT></P>

<P><FONT SIZE=3D2>While writing this, I am thinking that I could create =
two policies, one for daily backups and one for weekly backups and then =
define all four 'real' ip addresses for each server. I am making the =
assumption that it will only backup the file system that is mounted on =
one of the nodes but simply skip the file system on the other nodes as =
its not mounted. Would that work? How would I go about restoring the =
file system if I didn't know which server it came from?</FONT></P>

<P><FONT SIZE=3D2>The last part was the question about tape rotation. =
It would appear that Netbackup 5 automatically moves tapes to the =
scratch pool when they expire (hurray!). Now the question is how do I =
import and eject tapes for last nights backup? Does anyone have any =
good systems for automating this and labelling tapes etc so they can =
easily be found... (I admit I might only have sixty tapes but is still =
a big pain!)</FONT></P>

<P><FONT SIZE=3D2>Thanks for everyone who has replied and look forward =
to more responses.</FONT>
</P>

<P><FONT SIZE=3D2>Timothy.</FONT>
</P>

<P><FONT SIZE=3D2>PS: Kate, Is NB5 really that unstable?</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Timothy Arnold </FONT>
<BR><FONT SIZE=3D2>Sent: 23 February 2004 18:18</FONT>
<BR><FONT SIZE=3D2>To: veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2>Subject: [Veritas-bu] Re-evaluating policies</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Netbackup Guru's!</FONT>
</P>

<P><FONT SIZE=3D2>I am about to embark on upgrading to Netbackup 5. I =
thought it might be a very good time to re-evaluate our policy =
configurations and see if there is anyway to improve the current system =
and make it more simple and easier to use. I would like to ask a few =
questions to see what you guru's think.</FONT></P>

<P><FONT SIZE=3D2>Our configuration is fairly simple. About thirty Unix =
clients connecting to an Sun L25. Four of the servers connect to a =
couple of A5000 arrays that host application data.</FONT></P>

<P><FONT SIZE=3D2>With this in mind each system will have its own =
schedule for system backups that run weekly and another schedule for =
application backups that run daily. We have virtual IP addresses for =
applications so I use the virtual IP in its own policy, so in affect I =
have three 'kinds' of policies.</FONT></P>

<P><FONT SIZE=3D2>So my first question is, can I consolidate the system =
backups into one policy? Is this recommended? The systems will always =
have / and /var but not always have /usr - will I need to split the =
policy dependent on which partitions I have? This would reduce the =
number of polices from thirty to one!</FONT></P>

<P><FONT SIZE=3D2>The other question is relating to tape rotation. In =
NB3.4 figuring out which tapes have been written to was a complete =
nightmare and I eventually wrote a shell script to automatically figure =
out which tapes had been used and emailed the operator which was fine, =
the only issue I had was that new tapes that have been used in a volume =
pool got put back into the same volume pool and was unavailable to the =
other pools unless you moved them using another script - seams like a =
little bit of a fudge to me! Does anyone know if tape rotation has been =
improved in NB5? If not, would anyone like to share any shell script =
with me (as I am sure they are better than my badly written shell =
scripts)!</FONT></P>

<P><FONT SIZE=3D2>I would appreciate any feedback and would be very =
interested to hear how other people have configured and maintained =
their Netbackup environment.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Timothy.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3FAD7.2A9FCFD8--

<Prev in Thread] Current Thread [Next in Thread>
  • [Veritas-bu] Re-evaluating policies - the other side, Schaefer, Harry <=