Re: [Veritas-bu] bocada software for monitoring
I don't know how long ago you did that, but there IS a web interface for BocadaI was using it at my last job. Stuart Liddle | Senior Consultant GlassHouse Technologies, Inc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts Sent: Monday, December 01, 2008 5:20 PM To: [EMAIL PROTECTED] Cc: veritas-bu@mailman.eng.auburn.edu; [EMAIL PROTECTED] Subject: Re: [Veritas-bu] bocada software for monitoring On Mon, Dec 1, 2008 at 4:57 PM, [EMAIL PROTECTED] wrote: Take the products for a test drive for a couple of weeks and see which one suits you the best. I know that both Aptare and VBR will offer this service, not sure about Bocada, but I bet they do. Bocada used to because we had a test drive here. It only took their tech support folks and me about a half-day to install the client on my desktop after the server was configured. Back then, and I don't know if it still is, the client was very fat and very ugly. Definitely NOT something you'd want management to have to install. Aptare, on the other hand, just requires a web browser (unfortunately the current requirements are nothing my own tech support folks will support, but that's not Aptare's fault). .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE [EMAIL PROTECTED] This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Tracking Policy Changes
I have mentioned at other times in this list that the using the
following command:
bppllist -allpolicies -U
does a great job of capturing all of the policy information. This can
be saved into a file and a diff can be done with the current version and
the previous version to determine if any changes have been made.
We did this and put it into subversion to track changes over time.
-stuart
Stuart Liddle | Senior Consultant
GlassHouse Technologies, Inc.
C: +1 805 822 9273 |
[EMAIL PROTECTED] l www.glasshouse.com
Infrastructure :: Optimized
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harpreet
SINGH
Sent: Tuesday, September 16, 2008 5:16 AM
To: [EMAIL PROTECTED]
Cc: VERITAS-BU@mailman.eng.auburn.edu;
[EMAIL PROTECTED]
Subject: Re: [Veritas-bu] Tracking Policy Changes
Hi,
We did the same on linux box. Put a cron job and use the diff command
for
any changes. Once any changes done in policy it will send out the mail.
Example
DateTime=`date +%d%m%y-%HH%MM%SS`
SCRIPT_PATH=/root/jmon
SUBJ=Backup Plolicy job has been changed`hostname`
## mv $SCRIPT_PATH/master_policy_list
$SCRIPT_PATH/master_policy_list.$DateTime
#ls -l /usr/openv/netbackup/db/class/*/* /$SCRIPT_PATH/policy.list
#ls -l /usr/openv/netbackup/db/class/*/*/* /$SCRIPT_PATH/policy.list
more /usr/openv/netbackup/db/class/*/* /$SCRIPT_PATH/policy.list_1
more /usr/openv/netbackup/db/class/*/*/* /$SCRIPT_PATH/policy.list_1
diff $SCRIPT_PATH/master_policy_list $SCRIPT_PATH/policy.list
policy.change
cnt=`cat $SCRIPT_PATH/policy.change| wc -l`
echo $cnt
var=1
if [[ $cnt -ge $var ]] then
echo Crontab enrties are not normal...
(
cat !
To : ${TO}
Subject : ${SUBJ}
!
cat $SCRIPT_PATH/policy.change
echo
***
echo *** Some one has modified the backup policy
With Warm Regards
=-=-=-=-=-=-=-=-=-=-=-=-=-
Harpreet Singh Chana
Phone : (O) 6895 - 4326
Fax :(O) 6895 - 4991
=-=-=-=-=-=-=-=-=-=-=-=-=-
Notice
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.
[EMAIL PROTECTED]
om
Sent by:
To
veritas-bu-bounce VERITAS-BU@mailman.eng.auburn.edu
[EMAIL PROTECTED]
cc
urn.edu
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
rn.edu
09/15/2008 08:44
Subject
PMRe: [Veritas-bu] Tracking Policy
Changes
Aptare has a policy change tracking feature.
--
Carl Stehman
Distributed Services
Pepcoholdings, Inc.
701 Ninth St NW
Washington DC 20068
202-331-6619
NBU
[EMAIL PROTECTED]
Sent by:
To
[EMAIL PROTECTED]
[EMAIL PROTECTED]
edu burn.edu
cc
09/13/2008 02:24 AM
Subject
[Veritas-bu] Tracking
Policy Changes
Please respond to
VERITAS-BU@mailman.eng.auburn.edu
Hi Forum,
Any logs / file which is created when we do any changes in backup
policy.
Can we see the earlier policy enteries and the new one.
Thanks In Advance
+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to
copyright
belonging to Pepco Holdings, Inc. or its affiliates (PHI). This Email
is
intended solely for the use of the person(s) to which it is addressed.
If
you are not an intended recipient, or the employee or agent responsible
for
delivery of this Email to the intended recipient(s), you are hereby
notified that any dissemination, distribution or copying of this Email
is
strictly prohibited. If you have received this message in error, please
immediately notify the sender and permanently delete this Email and any
copies. PHI policies expressly prohibit employees from making
Re: [Veritas-bu] DB Backup failing
Simon, The article you attached is actually a very good idea for those sites that have a large amount of catalog data. We used this method successfully until we migrated to LTO-3 drives which gave us the breathing room to allow for all of the catalog data on a single tape. -stuart Stuart Liddle | Senior Consultant GlassHouse Technologies, Inc. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] l www.glasshouse.com http://www.glasshouse.com/ Infrastructure :: Optimized From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WEAVER, Simon (external) Sent: Thursday, August 14, 2008 4:44 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] DB Backup failing further to my original reply (about trying to perform backup to a disk) , not sure if this is worth a read? http://seer.entsupport.symantec.com/docs/267772.htm Thanks, Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, August 13, 2008 11:29 PM To: [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] DB Backup failing Vanessa, Based on this thread, it looks like this is not the 1st time that this has happened in your environment. http://www.adsm.org/forum/showthread.php?t=13467 Does the Catalog backup fail immediately or after running for a while (as in previous thread)? What type of media is this being written to? Based on the size of your catalog (240GB), it's possible that your catalog is too large to fit on a single tape (via bpbackupdb) and that may be causing this error. If you are still running NBU 5.x you may have to implement the multi-tape catalog backup method ( or catalog archiving) until the environment is upgraded to 6.x for hot catalog backups. http://www.backupcentral.com/components/com_mambowiki/index.php/How_do_I _back_up_a_Netbackup_Catalog_Database_that_is_too_large_to_fit_on_a_sing le_tape%3F HTH Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vanessa Oliveira Sent: Wednesday, August 13, 2008 3:48 PM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] DB Backup failing Hello All, I'm facing an issue with DB backup for a couple days. It's failing with 84 , but I've changed lots of different tapes and the problem persists. It doesn't seem to be a tape problem. I've found the following at logs: 1218619015 1 2 16 ott-nb3.cisco.com 628290 0 0 *NULL* bpbackupdb cannot write image to /tmp/sync_B25284, Error 0 1218619017 1 2 16 ott-nb3.cisco.com 628290 0 0 *NULL* bpbackupdb NB database backup to media id B25284 FAILED Could be something related to DataBase size ? It's size is aprox. 240Gb (usr/openv/netbackup/db) Does anyone have an idea on what can be done to fix this issue ? Thanks 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. 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 and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http
Re: [Veritas-bu] Netbackup verify at write time
The moral of the story here is that if you want to be sure that your backup data is gooddo a restore test. Don't trust the bpverify function. Stuart Liddle | Senior Consultant GlassHouse Technologies, Inc. C: +1 805 822 9273 | [EMAIL PROTECTED] l www.glasshouse.com Infrastructure :: Optimized -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis Preston Sent: Tuesday, July 29, 2008 11:21 PM To: Justin Piszcz; VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Netbackup verify at write time Bpverify verifies far less than you think it does. The more I learned about it, the less interested I was in it. Curtis Preston | VP Data Protection GlassHouse Technologies, Inc. T: +1 760 710 2004 | C: +1 760 419 5838 | F: F: +1 760 710 2009 [EMAIL PROTECTED] | www.glasshouse.com Infrastructure :: Optimized -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Piszcz Sent: Tuesday, July 29, 2008 11:18 AM To: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Netbackup verify at write time If you use bpverify, it reads the media and compares the contents of the media to the catalog. It does not verify the data itself, only the contents of the catalog as you said. I have seen restores fail and bpverify says the tape is ok. Justin. On Tue, 29 Jul 2008, Jim H wrote: If you use bpverify, it reads the media and compares the contents of the media to the catalog. It is faster than a restore but Ed is right, it will not tell you if you are backing up the right things. It should not be affected by changing files on the client though. +-- |This was sent by [EMAIL PROTECTED] via Backup Central. |Forward SPAM to [EMAIL PROTECTED] +-- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Removing Retired backup clients.....
Uactually, the command is: bpplclients policyname -delete clientname the naming of the CLI commands was changed to reflect the change from Class to Policy. So, all of the bpclxxx commands are now bpplxxx, but both versions were available to use up until 5.1, I think. I have not seen whether the bpclxxx version is available in 6.x, but Symantec did tell everyone that the old versions were going away. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shyam Hazari Sent: Friday, June 20, 2008 12:32 PM To: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Removing Retired backup clients. I am assuming removing from the backup policy. Here is the command line version bpclclients policy name -delete client Name -Shyam On Fri, Jun 20, 2008 at 2:09 PM, Dennis Peacock [EMAIL PROTECTED] wrote: Backup environment is Netbackup 5.1 MP5 Master server and all clients are media servers. 2 of the 4 clients have been retired and now I can't seem to find a way to remove them from Netbackup without the GUI hanging. Any ideas on how I can remove 2 client/media servers? +-- |This was sent by [EMAIL PROTECTED] via Backup Central. |Forward SPAM to [EMAIL PROTECTED] +-- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Policy Information Migration
Paul, This is precisely the same type of thing that I discussed a while back. Symantec SHOULD have something like this, but they don't. What they do have is the ability to do the migration through the use of their command line, but it would have to be scripted by you to do it. You mention a few of the commands that are needed for this. In fact, at my previous job we had a couple of scripts that would do this. Now, before you ask for a copy, please realize that those scripts were the Intellectual Property of my former employer and I do not have copies to share. Basically, you would need one script to do an export of the policy information into a csv file. This csv file could be then used to move the policies to another NBU system where another script would be used to import that file to create the new policies. If desired, the csv file could be modified to change any aspects of the policies that are being migrated. I can tell you that the following NBU commands are used for the scripts: bpplclients bppllist vmpool bpstulist bppolicynew bpplsched bpplschedrep bpplinclude bpplclients bpgetconfig bppllist We had a limitation with our scripts that only allowed the use of frequency-based schedules and not calendar-based. Other than that, we used this method to migrate policies between backup systems. Not much more to say about it except that this is something that Symantec SHOULD have available for their customers, but they don't. However, all of the tools are there for anyone to put something together in a couple of scripts like we did. I won't say it's easy, but it can be done. -stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Demilde Sent: Friday, June 13, 2008 5:33 AM To: Esson, Paul Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Policy Information Migration Paul, Actually it could be a problem if you had already existing policies otherwise you can save policy information using bpplinfo ... and then use that information to create the policies. Greg Esson, Paul a écrit : Shyam, I have been told I cannot do this by Symantec. I thought it would be possible as this information is text based but I placed a call with support outlining what I was proposing and was told no. Regards, Paul Esson From: Shyam Hazari [mailto:[EMAIL PROTECTED] Sent: 13 June 2008 12:38 To: Esson, Paul Subject: Re: [Veritas-bu] Policy Information Migration Instead of creating policies from scratch, I would suggest copying the entire db/class folders to the new netbackup server and modify it. -Shyam On Fri, Jun 13, 2008 at 5:16 AM, Esson, Paul [EMAIL PROTECTED] wrote: Folks, I am looking at having to migrate policy information between two NetBackup Domains (Windows 2000/5.1 MP6 to Solaris 10/6.5.2) My intention is to capture the existing information via a script or series of scripts and to use that same data as source information in creating the new policies. Somewhere along the line I will need to substitute in the new storage unit and volume pool information. As a starting point I have identified the following sequence and commands. Am I on the right lines here? * List and capture policy and schedule attributes in the 5.1 Domain bppllist bpplsched * Add the policies and schedules to the 6.5 Domain bppolicynew bpplinfo -set bpplsched -add * Update the policy attributes, including client and pathname Information bpplclients [policy_name] -add [host_name] bpplinclude [policy_name] -add [pathname] Regards, Paul Esson Redstor Limited Direct: +44 (0) 1224 595381 Mobile: +44 (0) 7766 906514 E-Mail: [EMAIL PROTECTED] Web:www.redstor.com REDSTOR LIMITED Torridon House 73-75 Regent Quay Aberdeen UK AB11 5AR Disclaimer: The information included in this e-mail is of a confidential nature and is intended only for the addressee. If you are not the intended addressee, any disclosure, copying or distribution by you is prohibited and may be unlawful. Disclosure to any party other than the addressee, whether inadvertent or otherwise is not intended to waive privilege or confidentiality. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[Veritas-bu] Status 1's and exclude lists (was Top 20 (or so) misunderstood things about NBU)
I think that Jeff has the right idea here. Building an exclude list for things that cause a status 1 can be very helpful to you if you are in a S-OX environment. I guess I'd have to modify my review it once and ignore them after that... position. If you review the status 1's on a regular basis and check with the application owners to ensure that the files are NOT critical to a restore of the application (like some error log files or such) and place these files into the exclude list, then you are covered. This will switch the system getting status 1's to status zero. That way IF things change (like someone adding a new application or the application starts to behave differently, you will notice it because you start seeing status 1's. Definitely agree with having an exclude list for the database stuff if you are handling the database backups separately as a special form of backup. -stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Lightner Sent: Thursday, April 10, 2008 6:13 AM To: Weber, Philip; VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU I'll have to disagree with the idea of not using exclude lists. A couple of reasons to use them: 1) Separate OS and application/database backups. You do not want to have a policy that backs up from / on a system that has GBs or TBs of database on it when you have a separate policy for the database backups. In multi-tier environments it is even more important that you backup the DB from one server along with middle tier or other levels from other servers as part of an environment backup rather than a server backup. 2) Not having excluded the known items that can't be backed up (e.g. /proc on Linux, door files on Solaris) you have no idea whether the status 1 you just got was only for those known items or for other items that WERE critical to you ability to recover. In at least one Federally regulated industry I was expected to explain every file that caused a status 1. If I did that in the official backup documentation (required by those same regulations) I could put it in the exclude lists and NOT have to explain it each day. For those of us that know and love S-OX this might be a good pre-emptive measure for overzealous S-OX audits. -- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Auburn vs Netbackup forums- Was: sniff...bpgpisgone from 6.5
I don't care what it looks like as long as it is documented and it can be manipulated. It could be an xml file for all I care. How it looks is not as important as being able to do the export/manipulation/import of a policy or group of policies. We had something like that at my last job, but we scripted it ourselves and we had to make it conform to a strict set of rules that we defined up front. Plus it was limited in what we could do with it (no calendar-based policies for example). And the way we made it work was using a set of the NBU CLI's underneath. If we can get something like that to work in a limited fashion, then why can't Symantec get something that is full-blown, feature-full, documented script or program to do the same kind of thing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A Darren Dunham Sent: Thursday, April 10, 2008 4:57 PM To: Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Auburn vs Netbackup forums- Was: sniff...bpgpisgone from 6.5 On Thu, Apr 10, 2008 at 06:30:55PM -0400, Stuart Liddle wrote: I (and others) are looking for something that will Export a policy or policies to something like a csv file. Then manipulate that file if necessary and Import back into the system. You know, tweak the storage unit here and the schedule there... If you can do it for one policy, then you can easily use it to make new ones or move them from one system to another or make bulk changes. How would you want it to look? Right now there's a single text file for all the simple items in the policy (backup type, Pool, STU, ...), there's a single file for the clients, there's a single file for the include list, and then there's a directory with files for each schedule. The only one of those that seems incredibly cryptic is the Calendar file within the schedule (assuming you're using Calendar backups). The others have pretty good variable names. I don't think having a single CSV would be nice to work with due to the multiple client, backuplist, and schedules possible in a policy. If you do that, you end up with something like the output of 'bpdbjobs -all_columns' and parsing it becomes very difficult. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU
I think I would agree with all of what Ed has stated here. However, I think that these points would apply to ANY backup product and not just NBU. Since the question was about the top 20 (or so) misunderstood things about NBU, I'd have to add the following: 1) Yes, there is a command line interface! The GUI is NOT the only way to do things with NBU. (yeah, this might be generic, but...) 2) Multiplexing and Multistreaming are not the same thing and both need to be tuned properly in order to optimize your backups. 3) A return code of 1 on a backup does NOT mean that the backup has failed. Nor does it mean that the files that could not be backed up are essential to the recovery of the system. (This DOES mean that the backup admin needs to have a discussion with the system admins and application support folks about what files can be safely ignored on backups. Building exclude lists helps.) I had to explain to a manager once why we treated a return code 1 (partial success) the same as return code zero (successful). His thought was that he wanted everything to be zero return code! 4) Yes, NBU includes reporting, but it is no substitute for a 3rd party reporting tool like Bocada. (another item that could be about any backup tool). I'll have to think up some other NBU specific items and add to this list later. -stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts Sent: Tuesday, April 01, 2008 8:11 AM To: Curtis Preston Cc: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU On Mon, Mar 31, 2008 at 4:48 PM, Curtis Preston [EMAIL PROTECTED] wrote: What are the top 5/20/30 things about NBU that you think people get wrong? 1. People think that you're working on a backup system. You're not - you're working on a *recovery* system. If you can't recover, backups are useless. 2. File system backups are not a replacement for bare metal restore. It is usually not acceptable to just do a fresh install, restore files, and expect to be back to where they're started 3. Error messages really are important. Check them every day or you'll eventually discover that failures were missed in the noise and backups haven't run in a long time. When you do a restore is not the time to check to see if backups actually ran. 4. Audits are important. The larger the environment, the more likely it is that file systems are missed. This is especially true of clusters. Sometimes it's not the failures that get you but the lack of attempts. 5. Backing up clusters by physical host names will cause you grief. 6. Application owners are responsible for ensuring the application is recoverable. A backup admin, working in a vacuum, can not help you. 7. Test your restores regularly. There are lots more but this is a start... -- Ed Wilts, Mounds View, MN, USA mailto:[EMAIL PROTECTED] ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU
Yesvery true. What I recommend doing is to check all backups against a new client the first few times and see what is causing the partial success. Checking with the application support people on what files are OK to skip is always a good idea and will definitely eliminate problems in the future. Then use this information to build an exclude list for the client. I used to treat databases as a special case for backups since they are so temperamental. I would do SQL databases by having the SQL DBA's do their own backup of the db to the local filesystem (or a network share). Then we would have the DBA's put together an exclude list for their SQL servers to exclude the active DB files. Then we would schedule our backup jobs for a time AFTER the SQL local backups. Never had to worry about restoring SQL DB's after that. But, testing database restores is very critical to ensuring that you are backing up the right thing(s). And you definitely need the assistance of the DBA's for this. -stuart From: Jeff Lightner [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 1:31 PM To: Stuart Liddle; VERITAS-BU@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Top 20 (or so) misunderstood things about NBU I'd amend point 3 to say does NOT ALWAYS mean. There are many OS and filesystem level backups that are complete despite status 1. However, having a status 1 on a database backup can be a real killer... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Liddle Sent: Wednesday, April 09, 2008 3:52 PM To: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU I think I would agree with all of what Ed has stated here. However, I think that these points would apply to ANY backup product and not just NBU. Since the question was about the top 20 (or so) misunderstood things about NBU, I'd have to add the following: 1) Yes, there is a command line interface! The GUI is NOT the only way to do things with NBU. (yeah, this might be generic, but...) 2) Multiplexing and Multistreaming are not the same thing and both need to be tuned properly in order to optimize your backups. 3) A return code of 1 on a backup does NOT mean that the backup has failed. Nor does it mean that the files that could not be backed up are essential to the recovery of the system. (This DOES mean that the backup admin needs to have a discussion with the system admins and application support folks about what files can be safely ignored on backups. Building exclude lists helps.) I had to explain to a manager once why we treated a return code 1 (partial success) the same as return code zero (successful). His thought was that he wanted everything to be zero return code! 4) Yes, NBU includes reporting, but it is no substitute for a 3rd party reporting tool like Bocada. (another item that could be about any backup tool). I'll have to think up some other NBU specific items and add to this list later. -stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts Sent: Tuesday, April 01, 2008 8:11 AM To: Curtis Preston Cc: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU On Mon, Mar 31, 2008 at 4:48 PM, Curtis Preston [EMAIL PROTECTED] wrote: What are the top 5/20/30 things about NBU that you think people get wrong? 1. People think that you're working on a backup system. You're not - you're working on a *recovery* system. If you can't recover, backups are useless. 2. File system backups are not a replacement for bare metal restore. It is usually not acceptable to just do a fresh install, restore files, and expect to be back to where they're started 3. Error messages really are important. Check them every day or you'll eventually discover that failures were missed in the noise and backups haven't run in a long time. When you do a restore is not the time to check to see if backups actually ran. 4. Audits are important. The larger the environment, the more likely it is that file systems are missed. This is especially true of clusters. Sometimes it's not the failures that get you but the lack of attempts. 5. Backing up clusters by physical host names will cause you grief. 6. Application owners are responsible for ensuring the application is recoverable. A backup admin, working in a vacuum, can not help you. 7. Test your restores regularly. There are lots more but this is a start... -- Ed Wilts, Mounds View, MN, USA mailto:[EMAIL PROTECTED] -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution
Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU
I think it all depends upon what you want to achieve. I personally don't have a problem with seeing status code 1's and ignoring them, but some people don't like to see them which is why I suggested the exclude lists. BUT, it must be understood that the people responsible for those servers are responsible for the exclude lists that are on them. If admins outside of the backup/restore group know this, then they are the ones that are responsible for whether or not a file is getting backed up. Take that a step further...yes, you are responsible for recovery. But, if you are NOT told about a new server being added and given a specific request to back it up (and what to back up on that server), then how can YOU be responsible for its recovery? Ultimately, the recovery depends upon what the backup/restore team is TOLD about by the people who administer the servers appsyou can't read people's minds. --stuart From: Haskins, Steve [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 2:17 PM To: Stuart Liddle; Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Top 20 (or so) misunderstood things about NBU I agree with verifying with the application support techs on what files are being skipped and how to address them as they are responsible for their applications but as the backup and operating system administrator I am held accountable for recovery. I don't like exclude lists especially if it is just to make the reports look good for status 0. I have found that in too many cases an exclude list in created and then another administrator or application support tech will make a change and now important files are being skipped that shouldn't be. If coordinated correctly with procedures and documentation this should not be the case but there is still the reliance upon human intervention to follow procedures and to document. Regards From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Liddle Sent: Wednesday, April 09, 2008 1:40 PM To: Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU Yesvery true. What I recommend doing is to check all backups against a new client the first few times and see what is causing the partial success. Checking with the application support people on what files are OK to skip is always a good idea and will definitely eliminate problems in the future. Then use this information to build an exclude list for the client. I used to treat databases as a special case for backups since they are so temperamental. I would do SQL databases by having the SQL DBA's do their own backup of the db to the local filesystem (or a network share). Then we would have the DBA's put together an exclude list for their SQL servers to exclude the active DB files. Then we would schedule our backup jobs for a time AFTER the SQL local backups. Never had to worry about restoring SQL DB's after that. But, testing database restores is very critical to ensuring that you are backing up the right thing(s). And you definitely need the assistance of the DBA's for this. -stuart From: Jeff Lightner [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 1:31 PM To: Stuart Liddle; VERITAS-BU@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Top 20 (or so) misunderstood things about NBU I'd amend point 3 to say does NOT ALWAYS mean. There are many OS and filesystem level backups that are complete despite status 1. However, having a status 1 on a database backup can be a real killer... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Liddle Sent: Wednesday, April 09, 2008 3:52 PM To: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU I think I would agree with all of what Ed has stated here. However, I think that these points would apply to ANY backup product and not just NBU. Since the question was about the top 20 (or so) misunderstood things about NBU, I'd have to add the following: 1) Yes, there is a command line interface! The GUI is NOT the only way to do things with NBU. (yeah, this might be generic, but...) 2) Multiplexing and Multistreaming are not the same thing and both need to be tuned properly in order to optimize your backups. 3) A return code of 1 on a backup does NOT mean that the backup has failed. Nor does it mean that the files that could not be backed up are essential to the recovery of the system. (This DOES mean that the backup admin needs to have a discussion with the system admins and application support folks about what files can be safely ignored on backups. Building exclude lists helps.) I had to explain to a manager once why we treated a return code 1 (partial success
Re: [Veritas-bu] VTL NetBackup Best Practice
OKsince I did not hear from any of my former co-workers at my previous job on this subject, I will chime in. We were using VTL's and we did do multiplexing. We kept the number of drives per VTL down to 8 and we had 6 VTL's. All of the VTL's were connected to one ADIC i2000 tape library with LTO-3 tape drives. The physical library was split up into partitions, one for each VTL. At first we were using Vault to go to physical tape and we had set up our virtual tapes to be smaller than physical tape. This did not work very well (it was slow and it did not scale) and we ended up switching to a method where we did the copy to physical tape off of the back end of the VTL (NetApp, in case you were wondering). This Direct Tape Copy method has worked very well and we were getting tape drive speeds around 50MB/sec as opposed to Vault which was around 10MB/sec avg. (BTW, at last count, we were doing over 1PB per month to our VTL's or somewhere around 300TB/week.) As another poster stated, you do need to over-subscribe, but that's really not a problem. Restores from VTL are very quick if the tapes have not expired off. If they have expired off, all you need to do is to start the import of the physical tape (the barcodes of the virtual tapes are the same as the physical tapes that they get copied off to) and as soon as the import has started you can begin the restore. I set up a script to check for available tapes per VTL and then assigned new tapes as they were available in the physical library. -Stuart Liddle From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Ferlote Sent: Wednesday, March 05, 2008 5:35 PM To: Kevin Whittaker; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] VTL NetBackup Best Practice Thanks for all the replies... Good feedback (I wasn't looking for a right or wrong answer). I have looked into the Disk staging units (i.e. openstorage APIs etc..) but don't feel that this paradigm is mature or ready for production. I am also unclear about the API (and overall using NDMP for a new purpose) and the vendor support when it will come to using some of these disk features on 6.5. Anyways, that is a whole discussion on its own. Also I feel the API will lock us into a single solution... so I am with Curtis on that one. I am testing a couple vendors, both NetApp and EMC. Currently on the EMC one but the message is fairly consistent from both vendors. For your first issue they now support libraries that can have 100+ drives... Also if you use the fact that they put a Media Server on their EDL then you don't have to use your Master server to clone everything and that would drastically clean up your solution. I think if the price is correct and I architect this correctly then the VTL solution is worth every dollar... especially with the dedup roadmaps for these products that will uncover a lot of potential! Thanks. - Original Message From: Kevin Whittaker [EMAIL PROTECTED] To: Mike Ferlote [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu Sent: Wednesday, March 5, 2008 1:54:42 PM Subject: RE: [Veritas-bu] VTL NetBackup Best Practice Mike, Last January, I implemented a VTL (EMC CDL720) with 35 usable TB. We did much study on the multiplex issue in most instances the backup did perform faster when it was not multiplexed, but with out a doubt the restore AND duplications speed is around 4 times as fast. So, I am working towards having enough tape drives to stop all multiplexing in my environment. Here are my 2 issues I have a heavily clustered environment with 27 Media Servers. Well, an ORACLE DB could fail over from one server at any time. Well, when I originally setup the servers with 1 or 2 drives each, there was not enough on a robot with 20 drives to have the same robot on each media server. Well, what happens when the server A goes down that points to robot 1, and the DB fails over to server B and it only sees robot 2?!? I would have to scramble to make robot 1 visible on server B. I did see something in the VTL that might allow me to transfer the tape over from one robot to another and then I guess I would inventory the robot but alas I am unsure. Issue 2 I do all my vaulting on my master server. Since my media servers are also production servers, I do not want to hit them with so much IO for duplication. So the master server needed to have tape drives on each robot. So, I after much thought and upgrading to 6.5 I realized that SSO is not so bad. In fact it is wonderful! Media servers and join the SSO and pull out of it with no need to shutdown netbackup on the master server! Configuring tape drives is one step away by typing tpautoconf -a. Also, now I share the robots with in the VCS clusters and make sure that each server in the cluster can see all the robots. So, I can do restores with out any issues. Lastly, I don't have
Re: [Veritas-bu] NetBackup changes
We used to use subversion (SVN) a version control system to track our changes. We would first do a list of all of the policies using the following command: bppllist -allpolicies -U policylistfile This file was then checked into subversion along with a change control request number (we did not make changes without first getting a request from someone). This system was very useful in finding out when what changes to the backup policies were made. So, if we needed to find out who made the change to the path for a given policy, we could look it up and find out that there was a request to do so by a given user.very helpful indeed! --stuart -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 15, 2008 8:56 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] NetBackup changes We do use tripwire. It gives us the what but not the who. One problem for auditing we've found is that the while the java gui can log the command strings, there's always the command line to circumvent. If you don't hand out root and only use the GUI, then you can add the -lc option to the jnbSA command line and log the commands it runs in the background. So, write a wrapper script to jnbSA, add the -lc option and a specific log file location like this and you're got something that might work. example: cat jnb /usr/openv/netbackup/bin/jnbSA -l /usr/openv/netbackup/logs/gui_logs/$USER.`date +%y%m%d%H%M%S` -lc ... It's not much but it keeps our auditors happy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Sent: Friday, February 15, 2008 9:34 AM To: 'Jimmy Stewpot'; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] NetBackup changes You don't mention what OS, but perhaps tripwire or big brother would be of help. Regards, Patrick Whelan Whelan Consulting Limited VERITAS Certified NetBackup Support Engineer for UNIX. VERITAS Certified NetBackup Support Engineer for Microsoft Windows. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jimmy Stewpot Sent: 15 February 2008 15:37 To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Netbackup changes Hello, I am interested to know if anyone has or knows of any software which can easily track the changes made in netbackup. We have a fairly large install and would like to be able to track who makes changes to what and when for obvious reasons. I have had a look at the documentation but its not clear if its possible in the standard product. Does anyone have any advice that they can provide me? Regards, Jimmy ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] NBU 5.1 MP5 all jobs hanging
In my previous job, we had this problem (and they probably still do). We were running on a Solaris-9 master server. We had over 1600 clients and over 1300 policies. The jobs were running 7x24. We upped the values in the /etc/system file to the maximum for what Paul pointed out below. All of this was of limited use as it would still hang up about once a week or so. The solution is to go to 6.x because of the new scheduler. --stuart liddle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Piszcz Sent: Wednesday, December 19, 2007 10:15 AM To: Paul Keating Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] NBU 5.1 MP5 all jobs hanging Ahh yes he is using Solaris 8--definitely make sure you tune appropriately, with 10, most of the parameters are not needed. Justin. On Wed, 19 Dec 2007, Paul Keating wrote: There used to be a technote that no logner exists. http://seer.support.veritas.com/docs/268122.htm : Message Queue parameters: On some UNIX platforms with NetBackup configurations, it can be necessary to increase the system's message queue resources to avoid bpsched hangs. For example, the following changes may need to be made to the /etc/system file: set msgsys:msginfo_msgmap=500 set msgsys:msginfo_msgmnb=65536 set msgsys:msginfo_msgssz=16 set msgsys:msginfo_msgseg=8192 set msgsys:msginfo_msgtql=500 Also, the below technote may be of interest. http://seer.support.veritas.com/docs/274544.htm -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Piszcz Sent: December 19, 2007 12:50 PM To: Hudson, Steve Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] NBU 5.1 MP5 all jobs hanging I have not seen that before but I have only used 5.1MP4 and 5.1MP6 in production, not 5.1MP5. If you open a case with Symantec one of the first things they may ask you to do is upgrade to 5.1MP6, is that possible? Justin. On Wed, 19 Dec 2007, Hudson, Steve wrote: We have seen at least 4 times in the last week where all Jobs Hang and it looks like BPSCHED goes away. We must then use the Kill -9 command on the Solaris 8 host to kill everything as the bp.kill_all and netbackup stop commands are ineffective. Anyone else seen this behavior in 5.1 MP5 ??? Steven R. Hudson Sysadmin - Enterprise Storage Iron Mountain 745 Atlantic Avenue Boston MA 02111 Phone: (617) 535-2849 [EMAIL PROTECTED] The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not he intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or coping or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu
