Re: [Veritas-bu] Changing the retention period

[nbuser]

bpexpdate -recalculate switch changes existing backup images as per new
policy settings.

On Thu, Jun 30, 2011 at 2:29 AM, Howard Graylin
wrote:

>  Folks,
>
> The only way to change the retention period on backups that have already
> run is to use the BPEXPDATE command, correct?  If I change the retention
> period on the policy, it has no effect on existing backup images…right?  One
> of the admin’s here said that if you changed the retention time in a
> specific policy in Tivoli, it would retroactively change the expiration date
> on existing backups.  I’m 99% sure NBU doesn’t do that, but just wanted to
> make sure.
>
> Thanks,
> Howard
>
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Changing the retention period

[Rusty Major]

This is correct. The same logic applies for SLP (Storage Lifecycle
Policies). These are smarter retention policies, but changing an SLP will
not retroactively change a backup that has already completed, or any other
step in the SLP process.



-Rusty



*From:* veritas-bu-boun...@mailman.eng.auburn.edu [mailto:
veritas-bu-boun...@mailman.eng.auburn.edu] *On Behalf Of *Howard Graylin
*Sent:* Wednesday, June 29, 2011 4:00 PM
*To:* veritas-bu@mailman.eng.auburn.edu
*Subject:* [Veritas-bu] Changing the retention period



Folks,



The only way to change the retention period on backups that have already run
is to use the BPEXPDATE command, correct?  If I change the retention period
on the policy, it has no effect on existing backup images…right?  One of the
admin’s here said that if you changed the retention time in a specific
policy in Tivoli, it would retroactively change the expiration date on
existing backups.  I’m 99% sure NBU doesn’t do that, but just wanted to make
sure.



Thanks,

Howard
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Changing the retention period

[Martin, Jonathan]

If you change a retention level to another value the expiration on
images assigned that retention level will not automatically change. You
have to run bpexpdate with the recalculate option to update the catalog
with the new retention based on the original backup date and the new
retention value.

 

-Jonathan

 

From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Howard
Graylin
Sent: Wednesday, June 29, 2011 5:00 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Changing the retention period

 

Folks,

 

The only way to change the retention period on backups that have already
run is to use the BPEXPDATE command, correct?  If I change the retention
period on the policy, it has no effect on existing backup
images...right?  One of the admin's here said that if you changed the
retention time in a specific policy in Tivoli, it would retroactively
change the expiration date on existing backups.  I'm 99% sure NBU
doesn't do that, but just wanted to make sure.

 

Thanks,

Howard

 

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Changing the retention period

[Howard Graylin]

Folks,

The only way to change the retention period on backups that have already run is 
to use the BPEXPDATE command, correct?  If I change the retention period on the 
policy, it has no effect on existing backup images...right?  One of the admin's 
here said that if you changed the retention time in a specific policy in 
Tivoli, it would retroactively change the expiration date on existing backups.  
I'm 99% sure NBU doesn't do that, but just wanted to make sure.

Thanks,
Howard

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Strange behaviour on 6.5.6 - Fixed

[nbuser]

Thanks Patrick for the resolution.

On Wed, Jun 29, 2011 at 7:06 PM, Patrick
wrote:

> In case anyone is interested. We basically fixed the problem by rebooting
> one of the media servers. It appears that it was having intermittent
> difficult, or perhaps one way, communication with the master server. The
> master server was unable to empty it queue (forgotten the name) L so it
> looked like everything was hung.
>
> We found the problem from two different angles by two different people.***
> *
>
> On the media server we saw very slow responses to vmoprcmd and tpconfig
> (among others). The most interesting thing was that the media server could
> ping the physical master server but not the virtual (it’s clustered, both on
> same subnet). However the master server could ping the media server and
> other media servers had no problem pinging both. After the reboot, the
> medias server was able to ping both. L
>
> From another angle but in parallel someone ran some analysis tools on the
> master server and determined the above queue problem. After rebooting the
> medias server (it had been up for 45 days (Linux)) everything worked find.
> We went from a success rate of 65% to 80% (on a good day) to 95% the first
> night of the fix and 99% last night.
>
> This was all because of one errant media server out of 60. L
>
> ** **
>
> Regards,
>
>  
>
> Patrick Whelan
>
> VERITAS Certified NetBackup Support Engineer for UNIX.
>
> VERITAS Certified NetBackup Support Engineer for Windows.
>
> ** **
>
> netbac...@whelan-consulting.co.uk
>
> ** **
>
> ** **
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Strange behaviour on 6.5.6 - Fixed

[Patrick]

In case anyone is interested. We basically fixed the problem by rebooting
one of the media servers. It appears that it was having intermittent
difficult, or perhaps one way, communication with the master server. The
master server was unable to empty it queue (forgotten the name) L so it
looked like everything was hung.

We found the problem from two different angles by two different people.

On the media server we saw very slow responses to vmoprcmd and tpconfig
(among others). The most interesting thing was that the media server could
ping the physical master server but not the virtual (it's clustered, both on
same subnet). However the master server could ping the media server and
other media servers had no problem pinging both. After the reboot, the
medias server was able to ping both. L

>From another angle but in parallel someone ran some analysis tools on the
master server and determined the above queue problem. After rebooting the
medias server (it had been up for 45 days (Linux)) everything worked find.
We went from a success rate of 65% to 80% (on a good day) to 95% the first
night of the fix and 99% last night.

This was all because of one errant media server out of 60. L

 

Regards,

 

Patrick Whelan

VERITAS Certified NetBackup Support Engineer for UNIX.

VERITAS Certified NetBackup Support Engineer for Windows.

 

 
netbac...@whelan-consulting.co.uk

 

 

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu