[Veritas-bu] Retentions
Guys im being asked by management a bit of a stupid question but i don't know for 100% so thought id check here. If i have a retention set to 6 months i assume it is 6 months e.g from 02/01/07 to 02/07/07 and not 6 * 4 weeks or a certain number of days? I know you can edit retentions but im just questioning the standard ones. Cheers ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Retentions
I just checked a 3 month backup from last night (I don't have any 6 month). It started @ 1197958489 (12/18/07 00:14:49) It says that it expires @ 1205993689 (3/20/08 01:14:49) A difference of 8035200 seconds; or 133920 minutes; or 2232 hours; or 93 days I have seen it documented somewhere that a month in NB was 31 days just to make sure. Use bpimagelist on a backup in your 6month retention policy to see the backup time and the expiration time of the backup id. Bobby Williams 2205 Peterson Drive Chattanooga, Tennessee 37421 423-296-8200 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Markham Sent: Tuesday, December 18, 2007 5:07 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Retentions Guys im being asked by management a bit of a stupid question but i don't know for 100% so thought id check here. If i have a retention set to 6 months i assume it is 6 months e.g from 02/01/07 to 02/07/07 and not 6 * 4 weeks or a certain number of days? I know you can edit retentions but im just questioning the standard ones. Cheers ___ 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] Retentions
Bingo, it will start from the utime of the originating backup and add 86,400*NrOfRetentionDays and add that to the originating utime to get to the expiration. I believe in the old days it was 28 days, but I believe Bobby is right, 31 days is a month in NB. I have it documented somewhere...if I can find it, I'll post it here. Chapa -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bobby Williams Sent: Tuesday, December 18, 2007 4:02 AM To: [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Retentions I just checked a 3 month backup from last night (I don't have any 6 month). It started @ 1197958489 (12/18/07 00:14:49) It says that it expires @ 1205993689 (3/20/08 01:14:49) A difference of 8035200 seconds; or 133920 minutes; or 2232 hours; or 93 days I have seen it documented somewhere that a month in NB was 31 days just to make sure. Use bpimagelist on a backup in your 6month retention policy to see the backup time and the expiration time of the backup id. Bobby Williams 2205 Peterson Drive Chattanooga, Tennessee 37421 423-296-8200 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Markham Sent: Tuesday, December 18, 2007 5:07 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Retentions Guys im being asked by management a bit of a stupid question but i don't know for 100% so thought id check here. If i have a retention set to 6 months i assume it is 6 months e.g from 02/01/07 to 02/07/07 and not 6 * 4 weeks or a certain number of days? I know you can edit retentions but im just questioning the standard ones. Cheers ___ 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 --- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Retentions
bpretlevel will show you how many seconds/days they are all set to. # ./bpretlevel -L Retention Equivalent Retention Retention Level days (seconds) Period - --- -- 0 7 ( 604800) 1 week 1 14 ( 1209600) 2 weeks 2 21 ( 1814400) 3 weeks 3 31 ( 2678400) 1 month 4 62 ( 5356800) 2 months 5 93 ( 8035200) 3 months 6 186 ( 16070400) 6 months 7 279 ( 24105600) 9 months 8 365 ( 31536000) 1 year 9 24855 (2147483647) infinity [snip] or if you want days instead of seconds # ./bpretlevel -U Level Days Label 0 7 1 week 1 14 2 weeks 2 21 3 weeks 3 31 1 month 4 62 2 months 5 93 3 months 6 186 6 months 7 279 9 months 8 365 1 year 9 24855 infinity [snip] - Original Message - From: Bobby Williams [EMAIL PROTECTED] To: dave markham [EMAIL PROTECTED], veritas-bu@mailman.eng.auburn.edu Sent: Tuesday, December 18, 2007 5:01:56 AM (GMT-0600) America/Chicago Subject: Re: [Veritas-bu] Retentions I just checked a 3 month backup from last night (I don't have any 6 month). It started @ 1197958489 (12/18/07 00:14:49) It says that it expires @ 1205993689 (3/20/08 01:14:49) A difference of 8035200 seconds; or 133920 minutes; or 2232 hours; or 93 days I have seen it documented somewhere that a month in NB was 31 days just to make sure. Use bpimagelist on a backup in your 6month retention policy to see the backup time and the expiration time of the backup id. Bobby Williams 2205 Peterson Drive Chattanooga, Tennessee 37421 423-296-8200 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Markham Sent: Tuesday, December 18, 2007 5:07 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Retentions Guys im being asked by management a bit of a stupid question but i don't know for 100% so thought id check here. If i have a retention set to 6 months i assume it is 6 months e.g from 02/01/07 to 02/07/07 and not 6 * 4 weeks or a certain number of days? I know you can edit retentions but im just questioning the standard ones. Cheers ___ 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] Retentions
Kristofer, That command is not documented in VERITAS NetBackup 6.0 Commands for UNIX and Linux, is there another document out there that documents all of the commands MISSING in that PDF? Justin. On Tue, 18 Dec 2007, Kristofer wrote: bpretlevel will show you how many seconds/days they are all set to. # ./bpretlevel -L Retention Equivalent Retention Retention Level days (seconds) Period - --- -- 0 7 ( 604800) 1 week 1 14 ( 1209600) 2 weeks 2 21 ( 1814400) 3 weeks 3 31 ( 2678400) 1 month 4 62 ( 5356800) 2 months 5 93 ( 8035200) 3 months 6 186 ( 16070400) 6 months 7 279 ( 24105600) 9 months 8 365 ( 31536000) 1 year 9 24855 (2147483647) infinity [snip] or if you want days instead of seconds # ./bpretlevel -U Level Days Label 0 7 1 week 1 14 2 weeks 2 21 3 weeks 3 31 1 month 4 62 2 months 5 93 3 months 6 186 6 months 7 279 9 months 8 365 1 year 9 24855 infinity [snip] - Original Message - From: Bobby Williams [EMAIL PROTECTED] To: dave markham [EMAIL PROTECTED], veritas-bu@mailman.eng.auburn.edu Sent: Tuesday, December 18, 2007 5:01:56 AM (GMT-0600) America/Chicago Subject: Re: [Veritas-bu] Retentions I just checked a 3 month backup from last night (I don't have any 6 month). It started @ 1197958489 (12/18/07 00:14:49) It says that it expires @ 1205993689 (3/20/08 01:14:49) A difference of 8035200 seconds; or 133920 minutes; or 2232 hours; or 93 days I have seen it documented somewhere that a month in NB was 31 days just to make sure. Use bpimagelist on a backup in your 6month retention policy to see the backup time and the expiration time of the backup id. Bobby Williams 2205 Peterson Drive Chattanooga, Tennessee 37421 423-296-8200 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Markham Sent: Tuesday, December 18, 2007 5:07 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Retentions Guys im being asked by management a bit of a stupid question but i don't know for 100% so thought id check here. If i have a retention set to 6 months i assume it is 6 months e.g from 02/01/07 to 02/07/07 and not 6 * 4 weeks or a certain number of days? I know you can edit retentions but im just questioning the standard ones. Cheers ___ 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] retentions
Ed, I 100% agree with what you've said below. For my traditional and small environment (only about 550 servers), what I've outlined is extremely useful, especially since it works for both Netbackup and Backup Exec clients in a similar manner. And no, a single report will never be able to get you all the information you need (for example, there a second NBU specific report that gets at least a little closer to giving accurate results on what you describe below in interpreting schedules and report on backup success, believe they call it client_sla_summary_report or something). These reports don't replace one of my major functions, which is to follow-up and design a lot of those said one-offs. I certainly wouldn't want to be without the reports though, now that I know the value of them. My single biggest concern is the interpretation of these reports, and being able to explain without a doubt why an entry is or isn't in them. Thanks for the comments Ed. Cheers, Jon -Original Message- From: Ed Wilts [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 5:19 PM To: Dyck, Jonathan; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] retentions This doesn't really address all of the issues. In order for this to work, you have to know what the schedule of the jobs are supposed to be. We've got a ton of backups that only run monthly and another ton that only run semi-annually. Unless I sit down with a calendar, telling when the last full backup was and comparing that to what it should be is not going to be trivial. What's important to know is not when the last backup was, but when the last backup was *supposed to be*. To do that, you need to dig into the scheduler and that is where it gets tough. For one client having a weekly full is supposed to be normal. For another, I may not try to back it for 6 months and that's perfectly normal. Reports like this are great if you have a simple environment and everybody does your standard daily/weekly/monthly style backups. Not everybody does their weekly fulls on a weekend and incremental during the week and calls it a day. Any backup software can do that. I've got similar issues with Aptare's projections for tape consumption. In our environment it's absolutely useless since it's based on the day of the week and not on the NetBackup schedules. If it really wanted to a fantastic job (hint, hint), dig into the policies and schedules, its own historical database, and realize that the 2TB backup I did 6 months ago will be done again. I've got about 100TB of storage on a semi-annual backup schedule. To be able to get accurate estimates of those jobs coming up would be sweet... Again, there's no point in telling me when the last backup was. What I want to know is if the backups are getting done when they're supposed to be done. This gets even more complicated when you've got multiple policies for the same client - something that in some cases you *have* to do. Backup reporting and auditing is hard. StorageConsole does a good job at what it's attempted to bite off but it could still get better. And yes, I realize that our environment is non-traditional and that sometimes we're just not going to get a solution unless we write it ourselves. .../Ed -- Ed Wilts, Mounds View, MN, USA mailto:[EMAIL PROTECTED] I GoodSearch for Bundles Of Love: http://www.goodsearch.com/?charityid=821118 -Original Message- From: [EMAIL PROTECTED] [mailto:veritas-bu- [EMAIL PROTECTED] On Behalf Of Dyck, Jonathan Sent: Tuesday, July 24, 2007 2:37 PM To: Wayne T Smith; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions Just to chime in on the Aptare reports... They have an automated report (out of the box, but not really) you can cron/windows schedule to run that will give you the following details on full backups... (hope your screens large enough to make out the headings...). Great way to stop sys admins bugging you about last successful backups. LATEST FULL BACKUP LAST 60 DAYS CLIENT SERVER LAST FULL MBYTES FILES AVG MBYTES AVG FILES -- -- - -- - -- - With a little fiddling, you can get something that looks like the following all in one email... 1) Missing Backups (from last window any scheduled backup that has yet to run or has failed) 2) Last successful full backup attempt 3) Any skipped files during last backup Get the right person on a DL for an email, and you're laughing. Cheers, Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wayne T Smith Sent: Friday, July 20, 2007 12:29 PM To: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions I, too, agree the 2-week retention should
Re: [Veritas-bu] retentions
Just to chime in on the Aptare reports... They have an automated report (out of the box, but not really) you can cron/windows schedule to run that will give you the following details on full backups... (hope your screens large enough to make out the headings...). Great way to stop sys admins bugging you about last successful backups. LATEST FULL BACKUP LAST 60 DAYS CLIENT SERVER LAST FULL MBYTES FILES AVG MBYTES AVG FILES -- -- - -- - -- - With a little fiddling, you can get something that looks like the following all in one email... 1) Missing Backups (from last window any scheduled backup that has yet to run or has failed) 2) Last successful full backup attempt 3) Any skipped files during last backup Get the right person on a DL for an email, and you're laughing. Cheers, Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wayne T Smith Sent: Friday, July 20, 2007 12:29 PM To: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions I, too, agree the 2-week retention should be addressed ... quite risky. A few thoughts ... I recently tested Aptare StorageConsole and one of its out-of-the-box displays is close what you're looking for, I think. When we obtain a license, I'll be discarding many scripts ... one of which sort of applies here. The script looks at all full images for all clients and reports the most recent full backup for each client, ordered by oldest first. Look at the top of the list for clients in distress. This is simple and works great for clients with one image holding everything. It isn't nearly good enough for clients using multiple streams or clients that also have Exchange/Oracle/etc images in addition to file system images. I've started more than once to approximate proof we are successfully backing up at least what we intend. So far I have a bunch of failed attempts that would have worked for simple cases, but failed miserably in multitudes of ways. The best answer for us has always seemed to be getting accurate, succinct information in front of the eyes of someone who understands it and cares. But even that is not enough sometimes. Your idea of keeping the last full has promise, but you'll need a process to get rid of the images once you really don't want them ... plus, if your data is on tape, you'll probably require more media, as tape occupancy goes down due to the retention-extended images living alone. cheers, wayne Brandon Zermeno wrote, in part, on 2007-07-19 6:50 PM: We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
This doesn't really address all of the issues. In order for this to work, you have to know what the schedule of the jobs are supposed to be. We've got a ton of backups that only run monthly and another ton that only run semi-annually. Unless I sit down with a calendar, telling when the last full backup was and comparing that to what it should be is not going to be trivial. What's important to know is not when the last backup was, but when the last backup was *supposed to be*. To do that, you need to dig into the scheduler and that is where it gets tough. For one client having a weekly full is supposed to be normal. For another, I may not try to back it for 6 months and that's perfectly normal. Reports like this are great if you have a simple environment and everybody does your standard daily/weekly/monthly style backups. Not everybody does their weekly fulls on a weekend and incremental during the week and calls it a day. Any backup software can do that. I've got similar issues with Aptare's projections for tape consumption. In our environment it's absolutely useless since it's based on the day of the week and not on the NetBackup schedules. If it really wanted to a fantastic job (hint, hint), dig into the policies and schedules, its own historical database, and realize that the 2TB backup I did 6 months ago will be done again. I've got about 100TB of storage on a semi-annual backup schedule. To be able to get accurate estimates of those jobs coming up would be sweet... Again, there's no point in telling me when the last backup was. What I want to know is if the backups are getting done when they're supposed to be done. This gets even more complicated when you've got multiple policies for the same client - something that in some cases you *have* to do. Backup reporting and auditing is hard. StorageConsole does a good job at what it's attempted to bite off but it could still get better. And yes, I realize that our environment is non-traditional and that sometimes we're just not going to get a solution unless we write it ourselves. .../Ed -- Ed Wilts, Mounds View, MN, USA mailto:[EMAIL PROTECTED] I GoodSearch for Bundles Of Love: http://www.goodsearch.com/?charityid=821118 -Original Message- From: [EMAIL PROTECTED] [mailto:veritas-bu- [EMAIL PROTECTED] On Behalf Of Dyck, Jonathan Sent: Tuesday, July 24, 2007 2:37 PM To: Wayne T Smith; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions Just to chime in on the Aptare reports... They have an automated report (out of the box, but not really) you can cron/windows schedule to run that will give you the following details on full backups... (hope your screens large enough to make out the headings...). Great way to stop sys admins bugging you about last successful backups. LATEST FULL BACKUP LAST 60 DAYS CLIENT SERVER LAST FULL MBYTES FILES AVG MBYTES AVG FILES -- -- - -- - -- - With a little fiddling, you can get something that looks like the following all in one email... 1) Missing Backups (from last window any scheduled backup that has yet to run or has failed) 2) Last successful full backup attempt 3) Any skipped files during last backup Get the right person on a DL for an email, and you're laughing. Cheers, Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wayne T Smith Sent: Friday, July 20, 2007 12:29 PM To: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions I, too, agree the 2-week retention should be addressed ... quite risky. A few thoughts ... I recently tested Aptare StorageConsole and one of its out-of-the-box displays is close what you're looking for, I think. When we obtain a license, I'll be discarding many scripts ... one of which sort of applies here. The script looks at all full images for all clients and reports the most recent full backup for each client, ordered by oldest first. Look at the top of the list for clients in distress. This is simple and works great for clients with one image holding everything. It isn't nearly good enough for clients using multiple streams or clients that also have Exchange/Oracle/etc images in addition to file system images. I've started more than once to approximate proof we are successfully backing up at least what we intend. So far I have a bunch of failed attempts that would have worked for simple cases, but failed miserably in multitudes of ways. The best answer for us has always seemed to be getting accurate, succinct information in front of the eyes of someone who understands it and cares. But even that is not enough sometimes. Your idea of keeping the last full has promise, but you'll
Re: [Veritas-bu] retentions
Hi, The quickest way to solve this would be to get all the details of Images/tapes, then you can write a simple shell script with inputs of bexpdate, Images/Tapes and extention period. Pavan --- Brandon Zermeno [EMAIL PROTECTED] wrote: There are certain environments here that require only a 2 week retention, no matter what. In this environment we run full backups everyday and when the data set is in the 80 TB range, well that just more then I need to deal with. We have been running this way for years with no major issues. Leave it up to Oracle to take 2 weeks 4 hours to try and fix RAC. From: Curtis Preston [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 9:10 PM To: Brandon Zermeno; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] retentions How about setting a longer retention period and _expiring_ backups if the conditions you're looking for have happened? As long as I'm at it, I think a two week retention period is crazy. You should always have AT LEAST three full cycles. (IOW, if you're doing a full backup every week, I think you should have at least a three week retention period.) My preference would be at least a month for database backups and 90 days for filesystem backups. As to what other products do... NetWorker won't expire a full backup if there are incremental backups based on it. In your case, they would/could have expired too and the oldest full might have expired. TSM doesn't expiration like this. It keeps versions, and does not think the way these products think unless you force it to. I therefore think that TSM wouldn't have done what NetWorker did. Did I mention that a two week retention period is too short? ;) --- W. Curtis Preston Backup Blog @ www.backupcentral.com VP Data Protection, GlassHouse Technologies From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Zermeno Sent: Thursday, July 19, 2007 3:51 PM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] retentions We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
Do you not keep month end backups for 12 months? I do not know of a way of doing this, other than importing the tapes that may have been used for this job (assuming you know what they are). I dont think NBU behavior works like this - its a fixed retention period (that I can see). You could either do month end backups like I mentioned with a longer retention (and store these tapes in a safe or off site), or increase the level of retention for the future. For now, thats all I can see that can be accomplished (other than an import). 2 weeks without a server sounds daft probably a development box that no one cared about, until it was too late :-) Regards Simon Weaver 3rd Line Technical Support Windows Domain Administrator EADS Astrium Limited, B23AA IM (DCS) Anchorage Road, Portsmouth, PO3 5PU Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Zermeno Sent: Thursday, July 19, 2007 11:51 PM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] retentions We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. 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___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts Sent: 20 July 2007 01:29 To: 'Brandon Zermeno'; Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions What we have actually done here is to push the failures back on to the server admins. *EVERY* day that a backup fails, they get a ticket generated by our Help Desk that they have to do something with. So your job is to Now I'm jealous! I still haven't managed to swing this - we (storage/backup support) still get all these tickets. On top of this, we generate an overdue report every day. It's not 100% accurate (it is really, really hard to duplicate the scheduler's calculations!), but it gives us a good idea as to what's going on. If we see that a full backup is overdue for too long, we investigate. I'd like to do this as well. We've got good reporting on failures/successes but nothing clever yet that categorises the failures in terms of overdueness or jeopardy. cheers, Phil - Egg is a trading name of the Egg group of companies which includes: Egg plc (reg no 2448340), Egg Financial Intermediation Ltd (reg no 3828289), and Egg Banking plc (reg no 2999842). Egg Banking plc and Egg Financial Intermediation Ltd are authorised and regulated by the Financial Services Authority (FSA) and are entered in the FSA register under numbers 205621 and 309551 respectively. These members of the Egg group are registered in England and Wales. Registered office: Citigroup Centre, Canada Square, London E14 5LB. This e-mail is confidential and for use by the addressee only. If you are not the intended recipient of this e-mail and have received it in error, please return the message to the sender by replying to it and then delete it from your mailbox. Internet e-mails are not necessarily secure. The Egg group of companies do not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the Egg group of companies in this regard and the recipient should carry out such virus and other checks as it considers appropriate. This communication does not create or modify any contract. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
Aptare also has a built in report that shows you all hosts in your environment that have had multiple successive backup failures. Would be had to miss a red this server has not backed up for the last 10 days warning. ...Whether the server is down, or just not backing up for another reason. Paul -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts Sent: July 19, 2007 8:29 PM To: 'Brandon Zermeno'; Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions Aptare StorageConsole absolutely does this. Bring up a Mission Control report and it will quickly when the last successful backups was (a blue dot) vs a warning (a yellow dot) vs a failure (red dot). You will get this per file system. The default home page for StorageConsole shows you all failures in the last 48 (I think) hours. With StorageConsole, there's no excuse for you not to know about your successes/failures. What we have actually done here is to push the failures back on to the server admins. *EVERY* day that a backup fails, they get a ticket generated by our Help Desk that they have to do something with. So your job is to make sure that NetBackup attempts the job every day and every day it fails, you notify the admin. If the admin chooses to ignore the ticket, then the ticket needs to be automatically escalated to the group manager. If the server is down for more than 2 weeks and they've had 14 help desk tickets generated and ignored them all, it's not exactly your fault that the data is not recoverable. On top of this, we generate an overdue report every day. It's not 100% accurate (it is really, really hard to duplicate the scheduler's calculations!), but it gives us a good idea as to what's going on. If we see that a full backup is overdue for too long, we investigate. I have worked with other backup products that do solve your problems differently by utilizing a user-defined number of generations. Rather than expiring images by date, they expire by the number of generations so you would always have, for example, 2 generations to restore from. You could be down for 5 years and still have 2 copies of your weeklies. There are downsides to that approach, too, of course - no method is without its drawbacks. .../Ed -- 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. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
I, too, agree the 2-week retention should be addressed ... quite risky. A few thoughts ... I recently tested Aptare StorageConsole and one of its out-of-the-box displays is close what you're looking for, I think. When we obtain a license, I'll be discarding many scripts ... one of which sort of applies here. The script looks at all full images for all clients and reports the most recent full backup for each client, ordered by oldest first. Look at the top of the list for clients in distress. This is simple and works great for clients with one image holding everything. It isn't nearly good enough for clients using multiple streams or clients that also have Exchange/Oracle/etc images in addition to file system images. I've started more than once to approximate proof we are successfully backing up at least what we intend. So far I have a bunch of failed attempts that would have worked for simple cases, but failed miserably in multitudes of ways. The best answer for us has always seemed to be getting accurate, succinct information in front of the eyes of someone who understands it and cares. But even that is not enough sometimes. Your idea of keeping the last full has promise, but you'll need a process to get rid of the images once you really don't want them ... plus, if your data is on tape, you'll probably require more media, as tape occupancy goes down due to the retention-extended images living alone. cheers, wayne Brandon Zermeno wrote, in part, on 2007-07-19 6:50 PM: We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
There are certain environments here that require only a 2 week retention, no matter what. In this environment we run full backups everyday and when the data set is in the 80 TB range, well that just more then I need to deal with. We have been running this way for years with no major issues. Leave it up to Oracle to take 2 weeks 4 hours to try and fix RAC. From: Curtis Preston [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 9:10 PM To: Brandon Zermeno; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] retentions How about setting a longer retention period and _expiring_ backups if the conditions you're looking for have happened? As long as I'm at it, I think a two week retention period is crazy. You should always have AT LEAST three full cycles. (IOW, if you're doing a full backup every week, I think you should have at least a three week retention period.) My preference would be at least a month for database backups and 90 days for filesystem backups. As to what other products do... NetWorker won't expire a full backup if there are incremental backups based on it. In your case, they would/could have expired too and the oldest full might have expired. TSM doesn't expiration like this. It keeps versions, and does not think the way these products think unless you force it to. I therefore think that TSM wouldn't have done what NetWorker did. Did I mention that a two week retention period is too short? ;) --- W. Curtis Preston Backup Blog @ www.backupcentral.com VP Data Protection, GlassHouse Technologies From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Zermeno Sent: Thursday, July 19, 2007 3:51 PM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] retentions We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] retentions
We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
As far as I know once images expire they are deleted from the Netbackup catalog - as a result (and as you state) it is not possible to unexpire images within the catalog via bpexpdate. The only option is to manually import the images off the tapes, assuming you know what tapes have the images you need and they haven't yet been overwritten. If you are able to do the import then you can assign whatever retention you want. It's not hard to find existing images for current clients, but if the image has expired it doesn't exist in the catalog anymore. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Zermeno Sent: Thursday, July 19, 2007 15:51 To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] retentions We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
* Brandon Zermeno [EMAIL PROTECTED] [2007-07-19 15:50]: We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. If the policy was a two week retention, and the app guys knew that, it sounds like they are out of luck. Would the response have been any different if they were trying to get an old file? At a minimum, a review of your retentions for that system (and probably the rest of them, too) is in order. You _could_ do it with some scripting, but you are asking for headaches. There are a lot of questions you need to answer in order to pull this off, like; are you comparing against a flat timespan, or will it change per policy/client/whatever? how soon do you want to extend the retentions, immediately following a failure, 1 day, 1 week, etc? How far do you extend it? What about notifications? Is blindly doing this going to deplete your tapes, causing more issues than it fixes? There is no substitute for a person actually looking at what's going on in the environment. It sounds like what you really need is to look into better ways of reporting on what's happening, and not just the backup admins. The managers and admins of the systems being backed up should be watching, too. That can be homegrown or third-party. The data is there, it just depends on how much effort you want to (or can) put into it. -- David Rock [EMAIL PROTECTED] ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
This is what I am looking for. We have had nothing but useless junk from Command Central and Advanced Reporter and I have no faith in the latest version Backup Reporting. Does Aptare manage to show you when the last backup was run successfully? In this case we overwrote the tape so importing was not an option. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Dunham Sent: Thursday, July 19, 2007 4:38 PM To: Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions As far as I know once images expire they are deleted from the Netbackup catalog - as a result (and as you state) it is not possible to unexpire images within the catalog via bpexpdate. The only option is to manually import the images off the tapes, assuming you know what tapes have the images you need and they haven't yet been overwritten. If you are able to do the import then you can assign whatever retention you want. Yes. I think he's looking for something like the default behavior of EMC Networker, where the image's expiration is suspended if there haven't been any later successful backups. So not recover (via import) after the fact, but prevent the last backup from being expired at all. I can think of how using some scheduled scripts could get pretty close. Examine the catalog for the last full backup of all the machine/filesystem. If it's approaching expiration, push the expiration date back. As long as the script runs (successfully) at least once within the pushback period, it'll prevent the expiration. Finding the image corresponding to a particular filesystem isn't necessarily trivial though. And you really need to track by filesystem. If the machine has done recent successful full backups, but one filesystem failed each time, you'd like to delay that filesystem's expiration. -- 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 CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
This is what I am looking for. We have had nothing but useless junk from Command Central and Advanced Reporter and I have no faith in the latest version Backup Reporting. Does Aptare manage to show you when the last backup was run successfully? Aptare StorageConsole absolutely does this. Bring up a Mission Control report and it will quickly when the last successful backups was (a blue dot) vs a warning (a yellow dot) vs a failure (red dot). You will get this per file system. The default home page for StorageConsole shows you all failures in the last 48 (I think) hours. With StorageConsole, there's no excuse for you not to know about your successes/failures. What we have actually done here is to push the failures back on to the server admins. *EVERY* day that a backup fails, they get a ticket generated by our Help Desk that they have to do something with. So your job is to make sure that NetBackup attempts the job every day and every day it fails, you notify the admin. If the admin chooses to ignore the ticket, then the ticket needs to be automatically escalated to the group manager. If the server is down for more than 2 weeks and they've had 14 help desk tickets generated and ignored them all, it's not exactly your fault that the data is not recoverable. On top of this, we generate an overdue report every day. It's not 100% accurate (it is really, really hard to duplicate the scheduler's calculations!), but it gives us a good idea as to what's going on. If we see that a full backup is overdue for too long, we investigate. I have worked with other backup products that do solve your problems differently by utilizing a user-defined number of generations. Rather than expiring images by date, they expire by the number of generations so you would always have, for example, 2 generations to restore from. You could be down for 5 years and still have 2 copies of your weeklies. There are downsides to that approach, too, of course - no method is without its drawbacks. .../Ed -- Ed Wilts, Mounds View, MN, USA mailto:[EMAIL PROTECTED] I GoodSearch for Bundles Of Love: http://www.goodsearch.com/?charityid=821118 ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] retentions
I've got an excel pivot table I use for a peek at this type of information, I'll send it your way. Basically it looks at amount of data backed up in jobs marked as fulls on a week by week basis. If your report looks something like Server 1 - 50GB, 50GB, 0GB Server 2 - 75GB, 75GB, 75GB Server 3 - 60GB, 60GB, 60GB You know Server 1 has an issue. I use it more to track weekly data totals, looking for file servers and application servers whose data is growing by greater than 1-2% per week, but it can also do what you are asking for here. Because its excel its not ideal, and it requires a cut and paste of data from the client report, but its better than nothing. If I were to script this I would write something in perl to go server by policy and look for instances of no full backup in the last 7 or 8 days assuming you run weeklies. You could get more advanced and compare this week's weekly versus last weeks weekly in regards to KBs written to tape etc.. but thats a sticky wicket. -Jonathan From: [EMAIL PROTECTED] on behalf of Brandon Zermeno Sent: Thu 7/19/2007 7:59 PM To: Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions This is what I am looking for. We have had nothing but useless junk from Command Central and Advanced Reporter and I have no faith in the latest version Backup Reporting. Does Aptare manage to show you when the last backup was run successfully? In this case we overwrote the tape so importing was not an option. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Dunham Sent: Thursday, July 19, 2007 4:38 PM To: Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] retentions As far as I know once images expire they are deleted from the Netbackup catalog - as a result (and as you state) it is not possible to unexpire images within the catalog via bpexpdate. The only option is to manually import the images off the tapes, assuming you know what tapes have the images you need and they haven't yet been overwritten. If you are able to do the import then you can assign whatever retention you want. Yes. I think he's looking for something like the default behavior of EMC Networker, where the image's expiration is suspended if there haven't been any later successful backups. So not recover (via import) after the fact, but prevent the last backup from being expired at all. I can think of how using some scheduled scripts could get pretty close. Examine the catalog for the last full backup of all the machine/filesystem. If it's approaching expiration, push the expiration date back. As long as the script runs (successfully) at least once within the pushback period, it'll prevent the expiration. Finding the image corresponding to a particular filesystem isn't necessarily trivial though. And you really need to track by filesystem. If the machine has done recent successful full backups, but one filesystem failed each time, you'd like to delay that filesystem's expiration. -- 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 CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank 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] retentions
How about setting a longer retention period and _expiring_ backups if the conditions you're looking for have happened? As long as I'm at it, I think a two week retention period is crazy. You should always have AT LEAST three full cycles. (IOW, if you're doing a full backup every week, I think you should have at least a three week retention period.) My preference would be at least a month for database backups and 90 days for filesystem backups. As to what other products do... NetWorker won't expire a full backup if there are incremental backups based on it. In your case, they would/could have expired too and the oldest full might have expired. TSM doesn't expiration like this. It keeps versions, and does not think the way these products think unless you force it to. I therefore think that TSM wouldn't have done what NetWorker did. Did I mention that a two week retention period is too short? ;) --- W. Curtis Preston Backup Blog @ www.backupcentral.com VP Data Protection, GlassHouse Technologies From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Zermeno Sent: Thursday, July 19, 2007 3:51 PM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] retentions We had an issue where was server was down for over 2 weeks and the last full backups expired. The retention for this environment is 2 weeks. After the tapes expired the App team decided they wanted to restore. Now management wants Veritas to extend the retention period automatically if a full is not successfully run. I do not know of any company that has this capability so I am looking for ideas. I do not think it would be possible for a person to manually track all the servers and their last full and then manually bpexpdate the images. I have pushed back with the question of why was this server allowed to be down for 2 weeks but nobody is answering. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
