How to change schedule time/days for Synthetic full schedules from Command Center?

Hi Pratik,

We are not aware of any changes in FR21.

Now you can modify the schedules from COmmand Center by following the steps on below link:

https://documentation.commvault.com/11.21/essential/87227_managing_schedules.html

Let us know please

Best Regards,

Seb

I have an FR11.21.15 instance open now and that option isn’t there.
 

Since SP11, viewing/editing all schedules in Command Center is not possible.

So, whilst you can still change a Full or Incremental in Command Center, you’ll need to head to CommCell/Java Console to change any Synthetic Full Schedules created as part of a Plan.

So its clear, we do not have any option to make changes in synthetic full schedules from Command center. The only visible option available is from GUI.

Hello Damien, it’s been a while since we talked on some GO event… (seems like ancient history by now… :-/   )

So support redirected me here, because I had raised a similar question as the OP above.

We were trying to migrate from Weekly Synthfulls for VM’s and Files, 30 days retention, etc..   on an old environment, through the use of a new greenfield commcell…. and using of plans while we’re at it.

Sure enough, 30 days retention, easy to fill out on the plan definition :-)    which does indeed create a Synth full schedule of once every 30 days.

But then we noticed we were using so much more storage space on our libraries than before.  The fact is, with  30 days / 1 cycle on the plan storage policy, and a Synthetic Full scheduled every 30 days… this results in keeping backups longer!  Anywhere from 30 to 61 days at the worst (3rd Synthetic full made) before the oldest cycle (30 days worth of backups) gets aged off, generating this sawtooth like space usage profile.  

And this is different from using weekly synthetic full backus on our old environment. Where you’d have 5 weeks worth of backups max. 

You might say: "Ah it's only a few more incrementals!"      But as an MSP, we’re not responsible for what is the data our customers generate within their VM’s.. that could be dumps, temp files, etc..  For the MSP that we are however, it’s all “data”.  And so incrementals tend to be rather large too, contributing to the space usage problem if we are keeping up to 60 days worth of backups, although we have a retention set of 30 days.

That last part is not easy to explain to product managers that need to sell this to customers. 100% overhead space usage…

I realize that 30 days is a short retention period.  But the longer the retention period you choose, the worse the problem becomes!   180 days retention apparently creates a plan that runs a SF every 90 days (would be nice to have that logic explained somewhere).  Thus retaining 271 days of incremental backups, etc etc.

The BOL says this about RPO scheduling :

Automatic Backup Level

The jobs from the incremental schedule are automatically converted to a full backup job based on the following backup conversion rules:

• For SQL agents:

  • If the last full backup job is older than 30 days and the operation window allows a full backup job, the job is converted to a full backup job.

  • If the last full backup job is within 30 days and the last differential backup job is older than 7 days, job is converted to a differential backup job.

• For other agents: If the last full backup job is older than 7 days and the operation window allows a full backup job, the job is converted to a full backup job.

You’d think that “other agents” would also include VM & Filesystem agents, right?   Well… no, it doesn't. At least not on my environment, the only backups I’m seeing are incrementals, and a Synth Full on VM’s and files every 30 days.

Also, for SQL Server, the BOL is wrong on that one (already why are the rules different for SQL Server?). I’m seeing weekly full backups as well on them (FR21) and differential backups daily somehow. (no conversion fyi).

Anyway, so the question I raised to support:  can we change the schedule policy generated by the plan in the JAVA Console GUI (technically yes, obviously) without impacting things or having it “automatically” reverted later on by the software… and that’s where things aren’t clear. And so they redirected me here to read your post which basically “OK’s” it…     :-)

Sorry for the long post, but I feel like Plans need some maturing still, or a slight overhaul 

@bish , would this be an acceptable CMR to get what @Pratik and @renaatski are looking for?

@Mike Struening from my point of view, it’s certainly worthwhile opening a CMR to investigate.

Cool.  I’ll talk to some devs and get the ball rolling.

@renaatski in discussing a possible CMR, I have some questions for you:

Are you looking to have AT LEAST 30 days of retention (in effect), or no more than 30 days for space?

As you mentioned, the Full will remain until 30 days after the last Inc which is up to 60 days worth of data, but no less than 30.

Want to ensure I’m addressing the root of your concern before suggesting any product changes.

Thanks!

@renaatski following up to keep this alive.  Let me know your root goal and we’ll either get a solution or create a more focused CMR.

Thanks!