Skip to main content

Background: We have added new storage arrays and are trying to clean up all the commvault data of the old ones. I know you can choose a mount point and ‘delete all data” but I would rather not force delete things this way if not necessary.  I would like to get a process in place where our subclients clean up data properly (or at least on purpose, as we want it to occur) as it appears we have quite a few subclients with incremental backups that the system will not auto clean up because they (per Data Forecast and Compliance Report) are not being cleaned up due to BASIC_CYCLES. Per my understanding, these are sticking around because the client was shut down before we could get another last “Full” backup (or similar, some of the subclients were descheduled or disabled, both of which are not allowing some cleanup to occur). In some cases we have some of these incremental backups only on primary storage ,some on primary and secondary, and some on both + tapes.

Some of these subclients are part of NDMP/NAS backups where we have several subclients on the same client performing backups today, so I cannot just decommission/delicense the client.

Also: our tape retention is ‘infinite”, and most things write certain Fulls to tape.

My question is: Is there a ‘standard” way of handling turning off (turning down) backups of subclients so there are no lingering incremental backups?

I feel that the most proper way would be to manually take 1 last Full backup, then deschedule, but I do not control who or when servers are decommissioned so I usually find out after it has been shut down so I cannot take a “last Full”.

I have been eyeing this setting in control panel>Media Management Configuration>Data Aging (“Ignore cycle retention on backup activity disabled subclients” via Data Aging on disabled clients or subclients based on days only retention | Community (commvault.com) and have been wondering ifI could set this, then just disable any subclient that I want it to clean up the data, but I see this statement “Now, the danger/risk here is that you can easily find yourself with NO backups….so be sure you have the jobs somewhere for as long as you require.” s oI feel as long as we use the mantra “disable nothing  (just deschedule) and only disable something to force that subclient to delete its data as a way to clean up” it would work.. but if someone disables something on a client/subclinet ( which is natural way to think ‘harmlessly shutting off”) it might delete all backups by accident.  It seems that having this setting ‘not the default” is hinting that a better, more proper method is available, I just can’t see it.

“Ignore cycle retention on backup activity disabled subclients” only applies when you disable the subclient or unlicense.

 

  1. Enable “Ignore cycle retention on backup activity disabled subclients”
  2. Disable the subclient(s),  and immediately run data aging. Your subclients will now meet the criteria for “Ignore cycle retention on backup activity disabled subclients”
  3. , After Data Aging has run then reenable the subclient. 

 

Just double checking: “or unlicense”?  Can this be confirmed or some docs pointed to?

I ask because I see 2 settings that are similar in Media management -> Data Aging:

  1. “Ignore cycle retention on backup activity disabled subclients”
  2. “Ignore cycle retention on De-Configured Clients”.  

I was under teh impression “releasing the license” was thee same as “deconfiguring”, but i note that option 1 only says it works on subclients, and option 2 indicates clients only.  If de-configuring= delicensing = release license, then why have option #2 if option #1 handled unlicensed?  

 

I can see how ‘activity disabled” could mean “no backups are taken” and not literally “you have unchecked the “activity→ Enable backup” flag at the subclient… but if it can mean “no scheduled activity”, why would this not apply to a subclient that simply had no schedule (backup “activity” is disabled)

 

@tigger2 , all that setting will do is ignore the CYCLES requirement for your Basic Retention; you’ll still need to ensure the Incrementals are old enough by BASIC DAYS.

As an example, if you have 7 days and 1 cycle for BASIC RETENTION and run a Full on Sunday, and Incrementals daily until Saturday, you start counting BASIC DAYS from the last Inc (on Saturday).  

That means the Full and its Incs will age off 7 days after Saturday’s Incremental as long as there is at least ONE newer Full to satisfy the CYCLE requirement.

The setting you are referring to simply says “forget the newer Full(s).  Once DAYS have passed, age the job(s) off”.

For those jobs in your Report, you COULD set Cycles to 0, rerun the report, see if it looks like you’ll drop the desired jobs and not the wrong ones, then run Data Aging.  Ideally, you should run new fulls but if you can’t for some reason, 0 cycles (or just manually pruning) is the way to go.

Just make sure you have an Aux copy so at worst, you’ll only lose jobs from THIS copy, not from the whole CommCell.

Let me know if that helps!

it helps somewhat, I guess i‘m a bit confused as to what “backup activity disabled subclients” actually means… like, is it literally ONLY set/activated by going into the subclient and unchecking the  “itab] Activity → Enable backup” flag at the subclient (or setting this same setting at the client or other level so effectively the subclient backup is disabled) OR is it “anything that turns off a subclient from trying to take backups”, like deconfiguring/delicensing, or descheduling, or anything else?

Calling it ‘backup activity disabled” seems like it can mean more than you have actively set that specific “disabled” flag and there's a little red arrow on the client/instance/subclient level to indicate its disabled.

 

I hope I’m just being too pedantic, but since the “Ignore cycle retention on backup activity disabled subclients” flag is global I didn’t want to open a can of worms (even though I can set it and then run a report, unset it, and then sift through the report...) I just wanted clarity on how it works

It’s the latter.  Anything that disables backup activity.

The purpose of the setting is for larger environments that deconfigure clients en masse, and know there will never be another full coming along.

You do 100% have the right idea in that last line.  No harm in setting an option, then running the report.  Just be sure Data Aging is not set to run any time soon.

YEARS ago I had a case where that exact thing happened.  Customer lowered retention, they ran the report, Data Aging ran without their knowledge, and they set the retention back to the higher amount and wondered where the jobs went.

Thanks!

Any time!

Reply


Terms & ConditionsCookie settings