Veritas-bu

[Veritas-bu] Veritas-bu Digest, Vol 4, Issue 150

2006-08-30 02:41:12
Subject: [Veritas-bu] Veritas-bu Digest, Vol 4, Issue 150
From: Bart.WALLEBROEK at swift.com (WALLEBROEK Bart)
Date: Wed, 30 Aug 2006 08:41:12 +0200
Jonathan,

We have thested this as well a couple of weeks ago.

NetBackup uses indeed some kind of 'policy based archive bit'.  Therefore you 
should never put a client in two different policies
where policy1 backs up the client with a full schedule and policy2 backs up the 
client with an incremental schedule.  Allways put the
schedules of a client in the same policy.

Best regards,
Bart Wallebroek
Backup Administrator
Swift

Message: 4
Date: Tue, 29 Aug 2006 17:15:36 -0400
From: "Martin, Jonathan \(Contractor\)" <JMARTI05 at intersil.com>
Subject: Re: [Veritas-bu] Clarification - Policies
To: "Darren Dunham" <ddunham at taos.com>,
        <Veritas-bu at mailman.eng.auburn.edu>
Message-ID:
        <13E204E614D8E04FAF594C9AA9ED0BB704035CAF at PBCOMX02.intersil.corp>
Content-Type: text/plain;       charset="US-ASCII"

I setup two identical policies on my master server TEST1 and TEST2 and
pointed them at one of my Linux servers, at a specific test directory
/test.  I then touched two files, test1 and test2 in that directory and
fired off TEST1 w/ a FULL.  It backed up both files.  The, without
modifying these files I fired off the TEST2 policy with the same
selection list but an incremental.  Theoretically if it was using the
same date/time stamp for the last "full" it shouldn't backup these two
files again.  Unfortunately it did, so it would appear that the
date/time stamp method used by NBU is policy specific?

Can anyone confirm?

-Jonathan





>-----Original Message-----
>From: veritas-bu-bounces at mailman.eng.auburn.edu
>[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf
>Of veritas-bu-request at mailman.eng.auburn.edu
>Sent: Wednesday, August 30, 2006 1:58 AM
>To: veritas-bu at mailman.eng.auburn.edu
>Subject: Veritas-bu Digest, Vol 4, Issue 150
>
>Send Veritas-bu mailing list submissions to
>       veritas-bu at mailman.eng.auburn.edu
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>or, via email, send a message with subject or body 'help' to
>       veritas-bu-request at mailman.eng.auburn.edu
>
>You can reach the person managing the list at
>       veritas-bu-owner at mailman.eng.auburn.edu
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Veritas-bu digest..."
>
>
>Today's Topics:
>
>   1. Re: Clarification - Policies (Veritas Netbackup)
>   2. Re: Clarification - Policies (Darren Dunham)
>   3. Re: Clarification - Policies (Martin, Jonathan (Contractor))
>   4. Re: Clarification - Policies (Martin, Jonathan (Contractor))
>   5. Re: Clarification - Policies (Darren Dunham)
>   6. "Cannot register shared drives for host (media server)   on
>      host (master server)" (Haskins, Steve)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 30 Aug 2006 00:12:54 +0530
>From: "Veritas Netbackup" <backupicici at gmail.com>
>Subject: Re: [Veritas-bu] Clarification - Policies
>To: "WEAVER, Simon" <simon.weaver at astrium.eads.net>
>Cc: veritas-bu at mailman.eng.auburn.edu
>Message-ID:
>       <a26938e40608291142j4335f341k86397f0dda40874c at mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Simon,
>
>If you remember I had posted a problem, where my cum incremental backup
>would be as close as the FULL backup on SUN. The daily update
>as per the app
>admin was arnd 4 GB.
>
>With the help of multiple responses I zeroed in on the problem
>and found
>that the FULL and INCR policies were different. Since then we
>have combined
>both into one and the backups really matching the calculations.
>
>Regards,
>PP BIJU KRISHNAN
>
>On 8/29/06, WEAVER, Simon <simon.weaver at astrium.eads.net> wrote:
>>
>>  *All*
>> *I just wanted clarification on this, to be 100% sure I
>understand what is
>> happening.*
>> **
>> *NBU 5.1 MP2 Win2k3 + 2 SAN Media Servers + thousands of clients*
>> **
>> *Scenario: Have a Policy that does Incr & Full for CLIENT1 -
>Policy is
>> called "Backup_Client1"*
>> *I have have a 2nd Policy, that is deactivated called
>> "Manual_Backup_Client1"*
>> **
>> *now, lets assume the full backup for Client1 failed. If I
>turn on the
>> Manual_Backup_Client1 policy, it performs and completes the
>backup without
>> any problems.*
>> **
>> *But am I right in thinking the archive bit would be set
>correctly, so
>> that when the Policy "Backup_Client1" runs, it is "aware" a
>full backup was
>> completed successfully?*
>> **
>> *My thinking is, the policy WONT have a clue, as the Policy
>that performed
>> the backup is different, and therefore may not share this info!*
>> **
>> *Clarification?*
>> **
>> *Thanks*
>>
>> *Regards*
>>
>> *Simon Weaver
>> 3rd Line Technical Support
>> Windows Domain Administrator*
>>
>> *EADS Astrium Limited, B23AA IM (DCS)*
>> *Anchorage Road, Portsmouth, PO3 5PU*
>>
>> *Email: **Simon.Weaver at Astrium-eads.net*
><Simon.Weaver at Astrium-eads.net>
>>
>> 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
>> Astrium Limited.
>> Nothing in this email shall bind Astrium Limited in any contract or
>> obligation.
>>
>> 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
>>
>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
>http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/
>20060830/319f9241/attachment-0001.html
>
>------------------------------
>
>Message: 2
>Date: Tue, 29 Aug 2006 12:38:38 -0700 (PDT)
>From: Darren Dunham <ddunham at taos.com>
>Subject: Re: [Veritas-bu] Clarification - Policies
>To: Veritas-bu at mailman.eng.auburn.edu
>Message-ID: <200608291938.MAA17381 at redwood.taos.com>
>Content-Type: text/plain; charset=us-ascii
>
>> The archive bit which the full and differential backups clear is a
>> facility of the file system.  Whether you are running NTFS
>or EXT3 the
>> archive bit is kept per file at the file system level.
>
>I have never heard of ext3 (or any unix filesystem) with an archive
>bit.  Did you mean NTFS and FAT?
>
>> It doesn't
>> matter WHAT backup software you use to clear the archive bit,
>> incremental backups will only backup files with the archive
>bit set and
>> fulls will backup EVERYTHING.  The only difference is that full and
>> differential backup RESET the archive bit if it is set.  Essentially,
>> anytime you change a file (open it, save it) the archive bit
>gets set to
>> "1" or "please back me up."  When a full or differential backup comes
>> along it backs up the file and clears the archive bit.  This
>really has
>> nothing to do with Netbackup or policies.  You can run simple backups
>> via windows backup and it still uses the same archive bit.
>At one point
>> I was using WinZip to clear archive bits and rub remote
>backups while a
>> tape library was down.
>
>Or you can ask netbackup to not use the archive bit.
>
>-- 
>Darren Dunham
>ddunham at taos.com
>Senior Technical Consultant         TAOS
>http://www.taos.com/
>Got some Dr Pepper?                           San Francisco,
>CA bay area
>         < This line left intentionally blank to confuse you. >
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 29 Aug 2006 16:44:42 -0400
>From: "Martin, Jonathan \(Contractor\)" <JMARTI05 at intersil.com>
>Subject: Re: [Veritas-bu] Clarification - Policies
>To: "Darren Dunham" <ddunham at taos.com>,
>       <Veritas-bu at mailman.eng.auburn.edu>
>Message-ID:
>
><13E204E614D8E04FAF594C9AA9ED0BB704035C87 at PBCOMX02.intersil.corp>
>Content-Type: text/plain;      charset="US-ASCII"
>
>Terribly sorry, I wrote that rather hastily - we're in DR mode
>here with
>the coming tropical Storm / Hurricane.  I probably DID mean NTFS-FAT,
>and you are 100% correct that EXT2-3 do not support any sort of archive
>bit.  That was definitely a slip on my part.
>
>That's said, I know EXT2-3 (Unix / Linux) backups are
>preformed based on
>the last backup time the modified / created time/date stamp on the
>individual files.  I guess the real question is whether or not the
>information about the last Full / Differential time/date is stored per
>policy, per client or per directory structure-selection list
>item.  That
>is a VERY good question, and I'll see about doing some testing to find
>out.
>
>Sorry again for the original slip-up.
>
>-Jonathan
>
>-----Original Message-----
>From: veritas-bu-bounces at mailman.eng.auburn.edu
>[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Darren
>Dunham
>Sent: Tuesday, August 29, 2006 3:39 PM
>To: Veritas-bu at mailman.eng.auburn.edu
>Subject: Re: [Veritas-bu] Clarification - Policies
>
>> The archive bit which the full and differential backups clear is a
>> facility of the file system.  Whether you are running NTFS
>or EXT3 the
>
>> archive bit is kept per file at the file system level.
>
>I have never heard of ext3 (or any unix filesystem) with an
>archive bit.
>Did you mean NTFS and FAT?
>
>> It doesn't
>> matter WHAT backup software you use to clear the archive bit,
>> incremental backups will only backup files with the archive bit set
>> and fulls will backup EVERYTHING.  The only difference is that full
>> and differential backup RESET the archive bit if it is set.
>> Essentially, anytime you change a file (open it, save it)
>the archive
>> bit gets set to "1" or "please back me up."  When a full or
>> differential backup comes along it backs up the file and clears the
>> archive bit.  This really has nothing to do with Netbackup or
>> policies.  You can run simple backups via windows backup and
>it still
>> uses the same archive bit.  At one point I was using WinZip to clear
>> archive bits and rub remote backups while a tape library was down.
>
>Or you can ask netbackup to not use the archive bit.
>
>-- 
>Darren Dunham
>ddunham at taos.com
>Senior Technical Consultant         TAOS
>http://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 at mailman.eng.auburn.edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 29 Aug 2006 17:15:36 -0400
>From: "Martin, Jonathan \(Contractor\)" <JMARTI05 at intersil.com>
>Subject: Re: [Veritas-bu] Clarification - Policies
>To: "Darren Dunham" <ddunham at taos.com>,
>       <Veritas-bu at mailman.eng.auburn.edu>
>Message-ID:
>
><13E204E614D8E04FAF594C9AA9ED0BB704035CAF at PBCOMX02.intersil.corp>
>Content-Type: text/plain;      charset="US-ASCII"
>
>I setup two identical policies on my master server TEST1 and TEST2 and
>pointed them at one of my Linux servers, at a specific test directory
>/test.  I then touched two files, test1 and test2 in that directory and
>fired off TEST1 w/ a FULL.  It backed up both files.  The, without
>modifying these files I fired off the TEST2 policy with the same
>selection list but an incremental.  Theoretically if it was using the
>same date/time stamp for the last "full" it shouldn't backup these two
>files again.  Unfortunately it did, so it would appear that the
>date/time stamp method used by NBU is policy specific?
>
>Can anyone confirm?
>
>-Jonathan
>
>-----Original Message-----
>From: veritas-bu-bounces at mailman.eng.auburn.edu
>[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Darren
>Dunham
>Sent: Tuesday, August 29, 2006 3:39 PM
>To: Veritas-bu at mailman.eng.auburn.edu
>Subject: Re: [Veritas-bu] Clarification - Policies
>
>> The archive bit which the full and differential backups clear is a
>> facility of the file system.  Whether you are running NTFS
>or EXT3 the
>
>> archive bit is kept per file at the file system level.
>
>I have never heard of ext3 (or any unix filesystem) with an
>archive bit.
>Did you mean NTFS and FAT?
>
>> It doesn't
>> matter WHAT backup software you use to clear the archive bit,
>> incremental backups will only backup files with the archive bit set
>> and fulls will backup EVERYTHING.  The only difference is that full
>> and differential backup RESET the archive bit if it is set.
>> Essentially, anytime you change a file (open it, save it)
>the archive
>> bit gets set to "1" or "please back me up."  When a full or
>> differential backup comes along it backs up the file and clears the
>> archive bit.  This really has nothing to do with Netbackup or
>> policies.  You can run simple backups via windows backup and
>it still
>> uses the same archive bit.  At one point I was using WinZip to clear
>> archive bits and rub remote backups while a tape library was down.
>
>Or you can ask netbackup to not use the archive bit.
>
>-- 
>Darren Dunham
>ddunham at taos.com
>Senior Technical Consultant         TAOS
>http://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 at mailman.eng.auburn.edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 29 Aug 2006 15:00:16 -0700 (PDT)
>From: Darren Dunham <ddunham at taos.com>
>Subject: Re: [Veritas-bu] Clarification - Policies
>To: Veritas-bu at mailman.eng.auburn.edu
>Message-ID: <200608292200.PAA18210 at redwood.taos.com>
>Content-Type: text/plain; charset=us-ascii
>
>> I setup two identical policies on my master server TEST1 and
>TEST2 and
>> pointed them at one of my Linux servers, at a specific test directory
>> /test.  I then touched two files, test1 and test2 in that
>directory and
>> fired off TEST1 w/ a FULL.  It backed up both files.  The, without
>> modifying these files I fired off the TEST2 policy with the same
>> selection list but an incremental.  Theoretically if it was using the
>> same date/time stamp for the last "full" it shouldn't backup
>these two
>> files again.  Unfortunately it did, so it would appear that the
>> date/time stamp method used by NBU is policy specific?
>
>Yes, they're policy specific.
>
>>From your "Unfortunately", I take it that you don't want that behavior
>(or at least don't expect it).  Can I ask if that's true?
>
>As an aside, Networker doesn't do this and it can certainly cause
>problems in some situations.
>
>-- 
>Darren Dunham
>ddunham at taos.com
>Senior Technical Consultant         TAOS
>http://www.taos.com/
>Got some Dr Pepper?                           San Francisco,
>CA bay area
>         < This line left intentionally blank to confuse you. >
>
>
>------------------------------
>
>Message: 6
>Date: Tue, 29 Aug 2006 16:58:13 -0700
>From: "Haskins, Steve" <Steve.Haskins at bannerhealth.com>
>Subject: [Veritas-bu] "Cannot register shared drives for host (media
>       server) on host (master server)"
>To: <veritas-bu at mailman.eng.auburn.edu>
>Message-ID:
>
><5A5A59FDAFF12744A1DF88A54D26868883D4ED at PHX01106.bhs.bannerhealth.com>
>Content-Type: text/plain; charset="us-ascii"
>
>Has anyone experienced this application event log entry? I have a W2K3
>media server, the master is W2K. NB Enterprise 5.1 MP5. The
>media server
>is a HP Storageworks 5026 with twp SDLT 160/320 tape drives with the NB
>SSO option. The message doesn't reoccur from backup activity, cycling
>the device manger or reboots of either server. It seems random.
>Application Event ID: 2626.
>
>
>
>Thank you,
>
>Steve Haskins
>
>
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
>http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/
>20060829/75bcd4e8/attachment.html
>
>------------------------------
>
>_______________________________________________
>Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>End of Veritas-bu Digest, Vol 4, Issue 150
>******************************************
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4723 bytes
Desc: not available
Url : 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060830/0e3ac4b6/smime.bin

<Prev in Thread] Current Thread [Next in Thread>
  • [Veritas-bu] Veritas-bu Digest, Vol 4, Issue 150, WALLEBROEK Bart <=