For those of you that are seriously interested, here is the actual format
taking advantage of policy and schedule names that made our life easier. I
should also state that we stood up extremely well to 5 audits over the past 4
years (BCP/vaulting audit, internal audit regarding records retention, backup
audit, internal SOX, and external SOX audit).
Policy name example:
Sybase-alderaan-PDS_SY24-model-DB ... Which tells me this is a sybase DB on
physical host alderaan on database server PDS_SY24 for the model database
instance and that this policy is a DB backup (vs. a log).
Our audit requirements are for 30 and 90 day retentions and we send all
databases less than 25 GB to a D2D pool. To accomplish this, we use the
schedule name.
Schedule name example (There are 2 automatic backup schedules and 4 application
backup schedules per policy):
Automatic Backup Name: PDS_SY24+model+30day+DB+tape+1 and
PDS_SY24+model+90day+DB+tape+1 ... Which tells me database/instance, the
retention, that it's a DB backup, destined for tape with 1 stripe.
The key here is that we have a single script to maintain for the whole
environment, because it has all of the information to parse. The DB team is
required to keep a table of all databases and whether they are active or not
and how big they are. We activate/deactive/create policies based on their
table and the script determines whether they should go to disk or tape based on
the size.
Application Backup Name: There are 4 of them, 30day-tape, 30day-disk,
90day-tape, and 90day-disk.
I would also add that rerunning failed backups is one thing, but what about a
backup that never runs? It doesn't show up on a failed rerun script. Part of
the summary reports show databases that haven't had a backup in "X" number of
days so we catch those too. Now the onus of the audit is on the database teams
to keep their table current and it is a very well documented, specific, and
verifiable process. I wrote my own SLA's at a 95% backup success rate and 100%
restore success rate and haven't missed them for 2 years now.
-----Original Message-----
From: Curtis Preston [mailto:cpreston AT glasshouse DOT com]
Sent: Tuesday, July 24, 2007 1:01 AM
To: Justin Piszcz; Liddle, Stuart
Cc: enyamada AT gmail DOT com; simon.weaver AT astrium.eads DOT net; DIVEN,
BRIAN; Veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] Maximum number of policies
If you have a policy naming convention (and you'd better for that many
policies), configuring things like exclude lists is no more difficult with
700000 than with 7. I'd actually argue that it's the other way around.
I blogged about this a while back, and was surprised at the positive support I
got:
http://www.backupcentral.com/content/view/51/47/
For exclude lists, I use a script anyway, as I like to push out a standard from
the master, so 10 policies, 10000 policies, whatever. ;)
---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Justin
Piszcz
Sent: Monday, July 23, 2007 4:03 PM
To: Liddle, Stuart
Cc: enyamada AT gmail DOT com; simon.weaver AT astrium.eads DOT net; briandiven
AT northwesternmutual DOT com; Veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Maximum number of policies
For example utilize include/exclude lists on the lists or find _some_ way
to group the clients together, no?
On Mon, 23 Jul 2007, Justin Piszcz wrote:
> I retract my statement. Some environments could have a good use for that
> many polices I suppose..
>
> On Mon, 23 Jul 2007, Liddle, Stuart wrote:
>
>> Ah....I see.
>>
>> So, Justin, you have some "special" insight about everyone's backup
>> environment and business requirements that allows you to come up with a
>> blanket statement like that?
>>
>>
>>
>> -----Original Message-----
>> From: Justin Piszcz [mailto:jpiszcz AT lucidpixels DOT com]
>> Sent: Monday, July 23, 2007 1:52 PM
>> To: briandiven AT northwesternmutual DOT com
>> Cc: liddles AT amgen DOT com; simon.weaver AT astrium.eads DOT net; enyamada
>> AT gmail DOT com;
>> Veritas-bu AT mailman.eng.auburn DOT edu
>> Subject: Re: [Veritas-bu] Maximum number of policies
>>
>> Whoever has that many polices has some mental issues.
>>
>> On Mon, 23 Jul 2007, briandiven AT northwesternmutual DOT com wrote:
>>
>>> I thought this pic would be appropriate for us ...
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
>> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
>> Liddle,
>> Stuart
>>> Sent: Monday, July 23, 2007 2:48 PM
>>> To: WEAVER, Simon (external); Liddle, Stuart; 'Edson Noboru Yamada';
>> Veritas-bu AT mailman.eng.auburn DOT edu
>>> Subject: Re: [Veritas-bu] Maximum number of policies
>>>
>>>
>>>
>>> yes just over 1100 policies....it's not quite 1 client per policy as
>> Curtis Preston suggests. What we have done is to have a policy for a given
>> dataset. For example, we have two exchange policies one has 13 exchange
>> servers in it and the other has 10. The reason we have two is because they
>> are in different datacenters and we have a media server in each datacenter.
>>>
>>>
>>>
>>> Most of our policies actually do have only one client per policy, but
>> because we are creating policies by dataset, we will have some that have
>> more than one client.
>>>
>>>
>>>
>>> --stuart
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: WEAVER, Simon (external) [mailto:simon.weaver AT astrium.eads DOT net]
>>> Sent: Sunday, July 22, 2007 11:20 PM
>>> To: 'Liddle, Stuart'; 'Edson Noboru Yamada';
>> Veritas-bu AT mailman.eng.auburn DOT edu
>>> Subject: RE: [Veritas-bu] Maximum number of policies
>>>
>>>
>>>
>>> 1,100 policies!!!!!!
>>>
>>>
>>>
>>>
>>>
>>> Regards
>>>
>>> Simon Weaver
>>> 3rd Line Technical Support
>>> Windows Domain Administrator
>>>
>>> EADS Astrium Limited, B23AA IM (DCS)
>>> Anchorage Road, Portsmouth, PO3 5PU
>>>
>>> Email: Simon.Weaver AT Astrium.eads DOT net
>> <mailto:Simon.Weaver AT Astrium.eads DOT net>
>>>
>>> -----Original Message-----
>>> From: Liddle, Stuart [mailto:liddles AT amgen DOT com]
>>> Sent: Friday, July 20, 2007 2:59 PM
>>> To: WEAVER, Simon (external); 'Edson Noboru Yamada';
>> Veritas-bu AT mailman.eng.auburn DOT edu
>>> Subject: RE: [Veritas-bu] Maximum number of policies
>>>
>>> Hi,
>>>
>>>
>>>
>>> we are running NB 5.1 MP6 with around 1100 policies and over 1600
>> clients. We have been having problems with the scheduler not starting
>> things when they are supposed to start. The one thing that is very
>> important is to have the proper settings in the /etc/system file for shared
>> memory. If you don't have this set correctly, you WILL have problems with
>> the scheduler.
>>>
>>>
>>>
>>> We had a case open with Symantec/Veritas about this and basically we
>> were told that it would be best to upgrade to 6.x because the scheduler has
>> been completely re-written and is much more efficient. We hope to upgrade
>> to 6.5 later this year. In the mean time we have to figure out creative
>> ways to deal with the problems of the scheduler getting bogged down.
>>>
>>>
>>>
>>> I believe that you should not have problems with only 100 policies
>> if you have your memory settings correct in /etc/system.
>>>
>>>
>>>
>>> good luck.
>>>
>>>
>>>
>>> --stuart
>>>
>>>
>>>
>>>
>>> ________________________________
>>>
>>>
>>> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
>> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
>> WEAVER,
>> Simon (external)
>>> Sent: Friday, July 20, 2007 6:42 AM
>>> To: 'Edson Noboru Yamada'; Veritas-bu AT mailman.eng.auburn DOT edu
>>> Subject: Re: [Veritas-bu] Maximum number of policies
>>>
>>>
>>>
>>> Hi
>>>
>>> Well I know of a site that had 120 policies, but never reported an
>> issue. Although its alot, I am not personally aware of any recommendation
>> that states what the limit should be.
>>>
>>>
>>>
>>> Are you sure the frequency is right and the policy is enabled
>> correctly ?
>>>
>>>
>>>
>>> If at all possible, can you consolidate any of your existing
>> policies and merge them ?
>>>
>>>
>>>
>>>
>>>
>>> Regards
>>>
>>> Simon Weaver
>>> 3rd Line Technical Support
>>> Windows Domain Administrator
>>>
>>> EADS Astrium Limited, B23AA IM (DCS)
>>> Anchorage Road, Portsmouth, PO3 5PU
>>>
>>> Email: Simon.Weaver AT Astrium.eads DOT net
>> <mailto:Simon.Weaver AT Astrium.eads DOT net>
>>>
>>> -----Original Message-----
>>> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
>> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Edson
>> Noboru
>> Yamada
>>> Sent: Friday, July 20, 2007 11:43 AM
>>> To: Veritas-bu AT mailman.eng.auburn DOT edu
>>> Subject: [Veritas-bu] Maximum number of policies
>>>
>>>
>>> Hi
>>>
>>> I have an NBU 5.1 installation with one master server
>> (Solaris 9) and 6 media servers (RHEL4, Windows 2003).
>>>
>>> I´ve just created the 101st policy. The problem I´m running
>> into is that apparently the scheduler is simply ignoring
>>> the backup window configured (it was supposed to start at
>> 8pm but the job only is added to the queue around 2am).
>>>
>>> My question is: NBU 5.1 may have some kind of 100 policies
>> limitation? Has anyone here with more than 100 policies/classes in place?
>>>
>>> Thank you
>>>
>>> This email (including any attachments) may contain confidential and/or
>> privileged information or information otherwise protected from disclosure.
>> If you are not the intended recipient, please notify the sender
>> immediately,
>> do not copy this message or any attachments and do not use it for any
>> purpose or disclose its content to any person, but delete this message and
>> any attachments from your system. Astrium disclaims any and all liability
>> if
>> this email transmission was virus corrupted, altered or falsified.
>>> ---------------------------------------------------------------------
>>> Astrium Limited, Registered in England and Wales No. 2449259
>>> Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
>> England
>>>
>>>
>>>
>>> This email (including any attachments) may contain confidential and/or
>> privileged information or information otherwise protected from disclosure.
>> If you are not the intended recipient, please notify the sender
>> immediately,
>> do not copy this message or any attachments and do not use it for any
>> purpose or disclose its content to any person, but delete this message and
>> any attachments from your system. Astrium disclaims any and all liability
>> if
>> this email transmission was virus corrupted, altered or falsified.
>>> ---------------------------------------------------------------------
>>> Astrium Limited, Registered in England and Wales No. 2449259
>>> Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
>> England
>>>
>>> </pre><font face=Arial>This e-mail and any attachments may contain
>> confidential information of Northwestern Mutual. If you are not the
>> intended
>> recipient of this message, be aware that any disclosure, copying,
>> distribution or use of this e-mail and any attachments is prohibited. If
>> you
>> have received this e-mail in error, please notify Northwestern Mutual
>> immediately by returning it to the sender and delete all copies from your
>> system. Please be advised that communications received via the Northwestern
>> Mutual Secure Message Center are secure. Communications that are not
>> received via the Northwestern Mutual Secure Message Center may not be
>> secure
>> and could be observed by a third party. Thank you for your
>> cooperation.</font><pre>
>>>
>
This e-mail and any attachments may contain confidential information of
Northwestern Mutual. If you are not the intended recipient of this message, be
aware that any disclosure, copying, distribution or use of this e-mail and any
attachments is prohibited. If you have received this e-mail in error, please
notify Northwestern Mutual immediately by returning it to the sender and delete
all copies from your system. Please be advised that communications received via
the Northwestern Mutual Secure Message Center are secure. Communications that
are not received via the Northwestern Mutual Secure Message Center may not be
secure and could be observed by a third party. Thank you for your cooperation.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
