Skip to main content
commvault.com commvault.com
Solved

Extended Retentions are not adhering to retention rules in place

  • February 18, 2021
  • 7 replies
  • 388 views
T
Byte
Forum|alt.badge.img+6

I'm having some issues with Retention cycles not adhering to the rules we give them. Are normal cycles are inc/diff are 7 days 1 Cycle, Weekly Full 28 days 1 cycle and Monthly Full for 1095+ 1 cycle. The daily retention we have no problems with , but its the weekly and monthly full’s that are not working correctly. The weekly full’s would keep the retention of a monthly full and the monthly full would keep the retention of a weekly full. 

I don't know if the “For Weekly Full Rule the Week Starts on” or the “For Monthly Full Rule the Month starts on “ is causing the issue, or if the “For all rules keep the:” is causing the problem.

I don't know what these three rules technically do so i need help understanding these three to understand if i have them set incorrectly for the rules i am trying to set. 

“For Weekly Full Rule the Week Starts on”

“For Monthly Full Rule the Month starts on “

“For all rules keep the:” 

 

 

Best answer by Mike Struening RETIRED

@TP_Erickson , thanks for the post!

I suspect what you are seeing is due to how the “Last of” is treated.  Let me know if this explains what you are seeing.

At any given time, the most recent full backup is always the “Last of the Week”, and “Last of the Month”, as well as the “Last of X” for almost any time period.

This is because the Data Aging process doesn’t want to assume that next week’s full (that you expect to run) actually will.  For this reason, we will effectively mark the most recent backup as the last of the week AND the last of the month.

Once a newer backup runs, then the previous backup will either lose the Last of the Month (or both) designation.

Extended Retention (and regular retention) is simply doing an inventory of the existing jobs and applying the set of rules you have established.  No matter which Full backups are Scheduled to run, the operation simply looks at what is there, sees which Full is the last backup of the month per subclient, and applies the Extended Retention accordingly.

 

What I usually advise is setting the For all rules keep the: setting to first full backup of the time period.  It’s much easier to see, and there’s no ‘shuffling’ of Extended retention application.

You can make the change now and likely not see much of a change assuming you only have a single backup per month for the past 105 days worth of data.

Let me know if that explains what you are seeing.

View original
Damian Andre
D
2 people like this
  • Damian Andre
    Damian Andre
  • D
    Dheeraj Shetty
Did this answer your question?

7 replies

Mike Struening
Vaulter
Forum|alt.badge.img+23

@TP_Erickson , thanks for the post!

I suspect what you are seeing is due to how the “Last of” is treated.  Let me know if this explains what you are seeing.

At any given time, the most recent full backup is always the “Last of the Week”, and “Last of the Month”, as well as the “Last of X” for almost any time period.

This is because the Data Aging process doesn’t want to assume that next week’s full (that you expect to run) actually will.  For this reason, we will effectively mark the most recent backup as the last of the week AND the last of the month.

Once a newer backup runs, then the previous backup will either lose the Last of the Month (or both) designation.

Extended Retention (and regular retention) is simply doing an inventory of the existing jobs and applying the set of rules you have established.  No matter which Full backups are Scheduled to run, the operation simply looks at what is there, sees which Full is the last backup of the month per subclient, and applies the Extended Retention accordingly.

 

What I usually advise is setting the For all rules keep the: setting to first full backup of the time period.  It’s much easier to see, and there’s no ‘shuffling’ of Extended retention application.

You can make the change now and likely not see much of a change assuming you only have a single backup per month for the past 105 days worth of data.

Let me know if that explains what you are seeing.

https://www.linkedin.com/in/michael-struening
Damian Andre
Chris Hollis
YYZ
3 people like this
  • Damian Andre
    Damian Andre
  • Chris Hollis
    Chris Hollis
  • YYZ
    YYZ
T
Byte
Forum|alt.badge.img+6
  • TP_Erickson
  • Author
  • Byte
  • 23 replies
  • February 22, 2021

Will give this a try. I believe what i am doing wrong here is i have the schedule set to either the second or third week for the monthlies, and when its set for last full backups of time period the storage policies are keeping the last full of the month. If the option is set to last full backup of the month i would want to set it on the last week for the schedule to create a monthly then? Or am i still seeing it wrong?

 

Mike Struening
Vaulter
Forum|alt.badge.img+23

Quick question to make sure I’m answering correctly:

When you are referring to your monthly schedule, or you talking about when the Primary Copy backup runs (from the Client assuming it’s not a synth full), or when the Aux Copy runs?

Extended Retention doesn’t really know about a job being scheduled, or run manually.  It only looks at the jobs you have on that copy for each subclient, then applies the retention accordingly.

Assuming you are referring to the Primary Copy, then whether or not the job runs the 2nd or 3rd week doesn’t matter if it is the only Full for the month (and if it is not, then the next Full within that month will ‘become’ the Last Full for that month).

If you’re referring to when the Aux copy runs, then the aux copy is only collecting jobs from the Primary Copy (if Synchronous, All backups, if Selective, whatever you define).  However, the data the Aux Copy runs doesn’t affect how Extended Retention is applied; it only affects what jobs will be on the copy that CAN get Extended Retention.

All of these concerned become rather moot if you switch to the First Full of the Time Period (assuming you don’t have business requirements that define the need to be the last of the month.

Let me know if that clarifies a bit, and keep me posted!

https://www.linkedin.com/in/michael-struening
Damian Andre
1 person likes this
  • Damian Andre
    Damian Andre
T
Byte
Forum|alt.badge.img+6
  • TP_Erickson
  • Author
  • Byte
  • 23 replies
  • March 15, 2021

Hey Mike, 

     So i am a little sheepish to say that i finally got what it all means now. Just randomly found a YouTube video with a dude who put it so simple i felt ashamed. Basically when we were new to this software, our boss wanted us to align our old schedules we had with Arcserve to Commvault. With the extended retentions set to last full backup of the time period, and monthly cycle starts on day one, when trying to say the second Friday of every month is the monthly, it meant nothing when setting that up in the schedule. So with a new understanding, I reworked the schedules to accommodate either last full backup of the month or first to be the monthly full that i wanted for monthlies, and it fixed my issues. I know i can get fancy down the road and adjust when exactly the Monthly period starts, but for now this will do until i am ready to go to some advanced scheduling. Thanks again for your help though. 

Mike Struening
Vaulter
Forum|alt.badge.img+23

Thanks awesome @TP_Erickson !  Do you mind sharing the video?

https://www.linkedin.com/in/michael-struening
T
Byte
Forum|alt.badge.img+6
  • TP_Erickson
  • Author
  • Byte
  • 23 replies
  • March 15, 2021

It was this video here, should be about the 20 min part where he starts explaining te extended retentions:
 

 

Mike Struening
Vaulter
Forum|alt.badge.img+23

Awesome!  Thanks for sharing.  I bet others will get a nice benefit as well.

https://www.linkedin.com/in/michael-struening

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings