Backup Central

Yes….very 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:jlightner < at > water.com]
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


Yes….very 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:jlightner < at > water.com]
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

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 & apps….you can’t read people’s minds.

--stuart


From: Haskins, Steve [mailto:Steve.Haskins < at > bannerhealth.com]
Sent: Wednesday, April 09, 2008 2:17 PM
To: Stuart Liddle; Jeff Lightner; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


Yes….very 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:jlightner < at > water.com]
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

Point 5 is not totally correct (that Ed stated).

to clarify on Point 5

Backup the physical clusters (ie: their local drives where the operating systems resides) and use the Virtual Cluster Name to perform the backup of the Data.
You need to backup the physical cluster names (as in the computers themselves) in order to recover your cluster config. But your Data for the cluster should be backed up with its own virtual server name (VSN).

Also to add; If the Backup/Recovery specialist is backing up a system and streaming physical drives, it is the Server owner or application owner to notify them if any additional drives are being added or removed. It only comes to light when you attempt to restore a drive that NetBackup knows nothing about. Its not the NBU Admin who is to blame.... how do they know what drive drive letters to add?

Finally, I do see status 1 as a problem, and warrants further investigation. Its down to the NBU admin to identify the cause of Status 1. Some companies I have worked with appear to class status 1 as a failure.

Simon

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 8:52 PM
To: VERITAS-BU < at > 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:

<![if !supportLists]>1) <![endif]>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…)
<![if !supportLists]>2) <![endif]>Multiplexing and Multistreaming are not the same thing and both need to be tuned properly in order to optimize your backups.
<![if !supportLists]>3) <![endif]>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!
<![if !supportLists]>4) <![endif]>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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

agreed! as stated, warrants investigation. It will only come back to bite you if you cannot restore it...

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Jeff Lightner
Sent: Wednesday, April 09, 2008 9:31 PM
To: Stuart Liddle; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

Stuart
This is where we differ.... if I was in your boat, I think my attitude to status 1 would be alot different to yours.

Cover your back is my advice to you.

Simon

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 10:41 PM
To: Haskins, Steve; Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: 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 & apps….you can’t read people’s minds.

--stuart


From: Haskins, Steve [mailto:Steve.Haskins < at > bannerhealth.com]
Sent: Wednesday, April 09, 2008 2:17 PM
To: Stuart Liddle; Jeff Lightner; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


Yes….very 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:jlightner < at > water.com]
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

If you're lucky enough to have a configuration management or asset management system, you may be able to find a way to report on all the servers that you aren't backing up, then you can hassle the admins who have created those servers. It's still not foolproof, as you end up with a list of servers with "reasons" why they don't need to be backed up ... and anyway, who maintains the configuration management system (sigh) ... but it is another layer of protection for your back

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: 09 April 2008 22:41
To: Haskins, Steve; Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: 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 & apps….you can’t read people’s minds.

--stuart


From: Haskins, Steve [mailto:Steve.Haskins < at > bannerhealth.com]
Sent: Wednesday, April 09, 2008 2:17 PM
To: Stuart Liddle; Jeff Lightner; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


Yes….very 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:jlightner < at > water.com]
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

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.


From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Weber, Philip
Sent: Thursday, April 10, 2008 7:53 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


If you're lucky enough to have a configuration management or asset management system, you may be able to find a way to report on all the servers that you aren't backing up, then you can hassle the admins who have created those servers. It's still not foolproof, as you end up with a list of servers with "reasons" why they don't need to be backed up ... and anyway, who maintains the configuration management system (sigh) ... but it is another layer of protection for your back


From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: 09 April 2008 22:41
To: Haskins, Steve; Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: 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 & apps….you can’t read people’s minds.

--stuart


From: Haskins, Steve [mailto:Steve.Haskins < at > bannerhealth.com]
Sent: Wednesday, April 09, 2008 2:17 PM
To: Stuart Liddle; Jeff Lightner; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


Yes….very 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:jlightner < at > water.com]
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU < at > 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: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU < at > 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 <cpreston < at > glasshouse.com ([email]cpreston < at > glasshouse.com[/email])> 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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

Stuart
Not at all. In fact I thought I was replying to Steve's post earlier today. Must have pressed the REPLY to the wrong Email

Just sometimes these threads get too big and it was probably overlooked. dont worry about it ok ?? I think the point I was making that the guy that got shot (fired) was SHOT (fired) for all the wrong reasons!! Even when he tried to advise them (the company) of this status 1 SQL problem.

So yes, I agree with everything you said, including the DB related stuff

Simon
P.S. not everyones posts come in at the same time (sometimes there are delays of 4 hours or so). But chill ok My comments too were based on Status 1, and from a quote that Steve stated in an earlier post saying "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."

From: Stuart Liddle [mailto:stuart.liddle < at > glasshouse.com]
Sent: Thursday, April 10, 2008 3:32 PM
To: WEAVER, Simon (external); VERITAS-BU < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Top 20 (or so) misunderstood things about NBU




Simon,

Are you deliberately trying to misunderstand what I am saying? I stated in a previous post that databases are a special case when it comes to a status 1. There are ways to backup SQL databases without having to get the NBU agent.

I also stated in a previous post that you should investigate a status 1 the first time you back up a client and go over the results with the application owner. You can use that information to set up exclude lists and show the application & system owner how this is done and let them manage it. Once you have done that, you have done your due diligence and it’s time to move on.

The best thing that any backup team can do is to put in place a clear charter of their service offerings and include a delineation of responsibilities. The backup team cannot be held responsible for the system administrators forgetting to ask to have a new system added to backups. The backup team cannot be held responsible for backing up a database that they don’t have knowledge of.

Again, databases are a special case in the backup world. My position is that when you get a request to backup a database server you work with the DBA’s and get their backup requirements and then schedule a restore test. It is the responsibility of the DBA’s to ensure that their databases are getting backed correctly up AND that they can be restored correctly. But, they have to work with the backup team to get it done. The backup team should NOT have to work in a vacuum and guess as to what the client wants.

We required that when someone wanted to add a new system or database to the backups, that a request get submitted. We did not add new systems or databases unless we got that request. Everyone knew this and they had no recourse if it turned out their system crashed and they had forgotten to have it added to backups. The responsibility was placed firmly where it belonged….on the system owner.

Finally, the backup team should provide reports to their customers (managers, system owners, application owners, DBA’s) using something like Bocada to provide daily backup status. If you provide them with that information (including systems that get status code 1), they will be able to review and determine on an on-going basis if they have a problem or not.

This is all basic stuff, if you don’t have this in place, then you are asking for trouble. I was basing my comments on status 1’s on the above being in place….YMMV.

-stuart
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:ewilts < at > ewilts.org ([email]ewilts < at > ewilts.org[/email])

----------------------------------
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, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from disclosure.
If you are not the intended recipient, please notify the sender
immediately, do not copy this message or any attachments and do not use it
for any purpose or disclose its content to any person, but delete this
message and any attachments from your system. Astrium disclaims any and all
liability if this email transmission was virus corrupted, altered or
falsified.
---------------------------------------------------------------------
Astrium Limited, Registered in England and Wales No. 2449259
REGISTERED OFFICE:-
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from disclosure.
If you are not the intended recipient, please notify the sender
immediately, do not copy this message or any attachments and do not use it
for any purpose or disclose its content to any person, but delete this
message and any attachments from your system. Astrium disclaims any and all
liability if this email transmission was virus corrupted, altered or
falsified.
---------------------------------------------------------------------
Astrium Limited, Registered in England and Wales No. 2449259
REGISTERED OFFICE:-
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

People need to stop looking at backups as "backups".

People and management need to view data backup as "data protection" and recovery.

If you really think about it....it's really "DATA PROTECTION" and the true test of your Data Protection process is called "Data Recovery". If you can't recover? Then your Data Protection Process is badly broken.

nuff said.

Actually, I would like to refer to NBU as NetRecovery - Its actually a
recovery server, not just a backup server.

Sure... any system can backup... but recovering of that Data is your
assurance the data has been captured correctly.

Simon

-----Original Message-----
From: veritas-bu-bounces < at > mailman.eng.auburn.edu
[mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Dennis
Peacock
Sent: Sunday, April 27, 2008 12:31 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


People need to stop looking at backups as "backups".

People and management need to view data backup as "data protection" and
recovery.

If you really think about it....it's reall DATA PROTECTION and the true
test of your Data Protection process is called "Data Recovery". If you
can't recover? Then your Data Protection Process is badly broken.

nuff said.

+----------------------------------------------------------------------
|This was sent by dpeaco < at > acxiom.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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 < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

This is my list of issues that come up frequently:

1. How do you tell what files were not backed up when a job ends with a status of 1?
2. What can be done to insure that no images are missed when a vault is run for offsite storage.
3. Catalog recovery
4. Recovering data from an expired tape.
5. Sending notifications when a backup job fails.
6. Linking Netbackup with Oracle rman.
7. Notifying admin when backups are taking an excessive amount of time to complete.
8. Using virtual server names for clients.

Selwyn,

I like this one.

7. Notifying admin when backups are taking an excessive amount of time
to complete.

I have experienced jobs that have mounted a tape and then nothing is
written to them and for some reason there is no timeout as there isn't a
mount issue. Canceling the job gets the tape unmounted but as usual
Netbackup wants to use the same tape so I have to freeze it before
restarting the job. Usually I have to manually eject these tapes.

Is there a better way to be notified than manually monitoring the backup
jobs??

Regards

-----Original Message-----
From: veritas-bu-bounces < at > mailman.eng.auburn.edu
[mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of selwyn
Sent: Friday, May 09, 2008 8:38 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


This is my list of issues that come up frequently:

1. How do you tell what files were not backed up when a job ends with a
status of 1?
2. What can be done to insure that no images are missed when a vault is
run for offsite storage.
3. Catalog recovery
4. Recovering data from an expired tape.
5. Sending notifications when a backup job fails.
6. Linking Netbackup with Oracle rman.
7. Notifying admin when backups are taking an excessive amount of time
to complete.
8. Using virtual server names for clients.

+----------------------------------------------------------------------
|This was sent by selwyn_schultz < at > hermanmiller.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Great additions to the list. Thanks!



Curtis Preston  |  VP Data Protection  
GlassHouse Technologies, Inc.
 
T: +1 760 710 2004 | C: +1 760 419 5838 |  F: F: +1 760 710 2009  
cpreston < at > glasshouse.com |  www.glasshouse.com
Infrastructure :: Optimized
-----Original Message-----
From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of selwyn
Sent: Friday, May 09, 2008 8:38 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


This is my list of issues that come up frequently:

1. How do you tell what files were not backed up when a job ends with a status of 1?
2. What can be done to insure that no images are missed when a vault is run for offsite storage.
3. Catalog recovery
4. Recovering data from an expired tape.
5. Sending notifications when a backup job fails.
6. Linking Netbackup with Oracle rman.
7. Notifying admin when backups are taking an excessive amount of time to complete.
8. Using virtual server names for clients.

+----------------------------------------------------------------------
|This was sent by selwyn_schultz < at > hermanmiller.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


_______________________________________________
Veritas-bu maillist - Veritas-bu < at > 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 < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Make sure you cut him in on the royalties

-Jonathan

-----Original Message-----
From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Curtis Preston
Sent: Friday, May 09, 2008 11:56 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

Great additions to the list. Thanks!



Curtis Preston  |  VP Data Protection
GlassHouse Technologies, Inc.
 
T: +1 760 710 2004 | C: +1 760 419 5838 |  F: F: +1 760 710 2009 cpreston < at > glasshouse.com |  www.glasshouse.com Infrastructure :: Optimized -----Original Message-----
From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of selwyn
Sent: Friday, May 09, 2008 8:38 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] Top 20 (or so) misunderstood things about NBU


This is my list of issues that come up frequently:

1. How do you tell what files were not backed up when a job ends with a status of 1?
2. What can be done to insure that no images are missed when a vault is run for offsite storage.
3. Catalog recovery
4. Recovering data from an expired tape.
5. Sending notifications when a backup job fails.
6. Linking Netbackup with Oracle rman.
7. Notifying admin when backups are taking an excessive amount of time to complete.
8. Using virtual server names for clients.

+----------------------------------------------------------------------
|This was sent by selwyn_schultz < at > hermanmiller.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


_______________________________________________
Veritas-bu maillist - Veritas-bu < at > 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 < at > mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu