I did once look into all of our Status 1 results and had several along
the lines of "it's a WINS server and the WINS DB failed" ... sounded
important to me.  Unfortunately, Status 1 is still at the bottom of my
list of things to look at in terms of priority, because there are too
many things above it :-)

-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Jeff
Lightner
Sent: 30 June 2006 12:49
To: WEAVER, Simon; bob944 at attglobal.net;
veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] status 1 (was: Typical success rates?)


Status 1 is not a failure UNLESS it's a database backup.  For
filesystems everywhere I've been we've shown that a status 1 is not a
failure but a warning.  Unfortunately you won't get Veritas to
officially confirm that.

Some things I've seen cause a status 1: 
Open files.
Files changed between the time the list for backup and the actual write
to tape occurred.
Sun "Door" files.

We verified extensively at a job that required FDA Validation that
restores from such backups were indeed complete to the point in time the
backup was started.  At that job we simply had to document that a status
1 was a success for all but database backups.

Note that due to the status 1 scheduling tools Tivoli Work Scheduler
(Maestro) that show abends for non zero exit status need to be massaged.
You basically have to have the Maestro job script check for status 1 and
mark exit the script with status 0 to prevent this.  "exit 0" is all you
have to do in a script to make this work.  It took me a while to get our
schedulers to understand this concept but once they did and I gave them
the syntax they were able to avoid reported abends for this.


-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of WEAVER,
Simon
Sent: Friday, June 30, 2006 4:16 AM
To: 'bob944 at attglobal.net'; veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] status 1 (was: Typical success rates?)


Bob
As the image is stored in the DB, I still see Status 1 as a good backup.

As long as you can get the data that needs to be backed up, and you
identify
the reason for the "1" you have 2 options in my view:

1) exclude the file/files that are causing the status code
2) Investigate and if not relevant, revert to point 1.

Anything higher is what I class a failure.
Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

EADS Astrium Limited, B32AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU

Email: Simon.Weaver at Astrium-eads.net



-----Original Message-----
From: bob944 [mailto:bob944 at attglobal.net] 
Sent: 30 June 2006 08:13
To: veritas-bu at mailman.eng.auburn.edu; WEAVER, Simon
Subject: RE: [Veritas-bu] status 1 (was: Typical success rates?)


> Exclude the "1"'s as I dont class them as failures :-)

Which might be why NetBackup defines stat 1 as "partial success" _and
keeps
the image_.  Final status <= 1 yields a restorable image; status > 1
does
not (archives excluded).  I think we agree that stat 1 beats the heck
out of
stat > 1.

That said, Operations can not accept a stat 1 without investigation.
What is
a status 1--is it one of the 15-odd conditions in the Status 1 section
of
the NetBackup Troubleshooting Guide?  Is it "just another goofy Windows
busy
perfdat file?"  The definition Ops must apply is "of all the files which
were to be backed up, some were and some were not."


Example A:
Files to be backed up (seletion minus excludes plus includes:  1,000,000
Files backed up:  999,999 Files not backed up:  1
Status:  1

Example B:
Files to be backed up (seletion minus excludes plus includes:  1,000,000
Files backed up:  1 Files not backed up:  999,999
Status:  1

Hence the BBP requirement that intelligence, artificial or human, be
applied
to stat 1s every time.


This email is for the intended addressee only.
If you have received it in error then you must not use, retain,
disseminate or otherwise deal with it.
Please notify the sender by return email.
The views of the author may not necessarily constitute the views of EADS
Astrium Limited.
Nothing in this email shall bind EADS Astrium Limited in any contract or
obligation.

EADS 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

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

-----------------------------------------
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: 1 Waterhouse Square, 138-
142 Holborn, London EC1N 2NA.
 

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.