[prev in list] [next in list] [prev in thread] [next in thread]
List: veritas-bu
Subject: Re: [Veritas-bu] Veritas-bu Digest, Vol 4, Issue 150
From: "WALLEBROEK Bart" <Bart.WALLEBROEK () swift ! com>
Date: 2006-08-30 6:41:12
Message-ID: 94278A04FDCF844CB4EBC13F1C1AD92FC21A7F () BE-EXCHANGE-03 ! swift ! corp
[Download RAW message or body]
--===============1825334281==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; micalg=SHA1;
protocol="application/x-pkcs7-signature";
boundary="----=_NextPart_000_011D_01C6CC10.0C103690"
This is a multi-part message in MIME format.
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@intersil.com>
Subject: Re: [Veritas-bu] Clarification - Policies
To: "Darren Dunham" <ddunham@taos.com>,
<Veritas-bu@mailman.eng.auburn.edu>
Message-ID:
<13E204E614D8E04FAF594C9AA9ED0BB704035CAF@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@mailman.eng.auburn.edu
> [mailto:veritas-bu-bounces@mailman.eng.auburn.edu] On Behalf
> Of veritas-bu-request@mailman.eng.auburn.edu
> Sent: Wednesday, August 30, 2006 1:58 AM
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: Veritas-bu Digest, Vol 4, Issue 150
>
> Send Veritas-bu mailing list submissions to
> veritas-bu@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@mailman.eng.auburn.edu
>
> You can reach the person managing the list at
> veritas-bu-owner@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@gmail.com>
> Subject: Re: [Veritas-bu] Clarification - Policies
> To: "WEAVER, Simon" <simon.weaver@astrium.eads.net>
> Cc: veritas-bu@mailman.eng.auburn.edu
> Message-ID:
> <a26938e40608291142j4335f341k86397f0dda40874c@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@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@Astrium-eads.net*
> <Simon.Weaver@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@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@taos.com>
> Subject: Re: [Veritas-bu] Clarification - Policies
> To: Veritas-bu@mailman.eng.auburn.edu
> Message-ID: <200608291938.MAA17381@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@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@intersil.com>
> Subject: Re: [Veritas-bu] Clarification - Policies
> To: "Darren Dunham" <ddunham@taos.com>,
> <Veritas-bu@mailman.eng.auburn.edu>
> Message-ID:
>
> <13E204E614D8E04FAF594C9AA9ED0BB704035C87@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@mailman.eng.auburn.edu
> [mailto:veritas-bu-bounces@mailman.eng.auburn.edu] On Behalf Of Darren
> Dunham
> Sent: Tuesday, August 29, 2006 3:39 PM
> To: Veritas-bu@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@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@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@intersil.com>
> Subject: Re: [Veritas-bu] Clarification - Policies
> To: "Darren Dunham" <ddunham@taos.com>,
> <Veritas-bu@mailman.eng.auburn.edu>
> Message-ID:
>
> <13E204E614D8E04FAF594C9AA9ED0BB704035CAF@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@mailman.eng.auburn.edu
> [mailto:veritas-bu-bounces@mailman.eng.auburn.edu] On Behalf Of Darren
> Dunham
> Sent: Tuesday, August 29, 2006 3:39 PM
> To: Veritas-bu@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@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@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@taos.com>
> Subject: Re: [Veritas-bu] Clarification - Policies
> To: Veritas-bu@mailman.eng.auburn.edu
> Message-ID: <200608292200.PAA18210@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@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@bannerhealth.com>
> Subject: [Veritas-bu] "Cannot register shared drives for host (media
> server) on host (master server)"
> To: <veritas-bu@mailman.eng.auburn.edu>
> Message-ID:
>
> <5A5A59FDAFF12744A1DF88A54D26868883D4ED@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@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
> End of Veritas-bu Digest, Vol 4, Issue 150
> ******************************************
>
["smime.p7s" (application/x-pkcs7-signature)]
_______________________________________________
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--===============1825334281==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic