Maybe someone in here can help out and straighten out the Plans part for me.
The below is going to one stg policy. Several clients schedules attached.
How would that pain out if done in a “Plan”
How many Plans, backup destinations and so on required?
I am not all aboard on plans since I’ve been using the “old” way for the last 10 years.
Thanks for any enlightment
//Henke
Page 1 / 1
Hi @Henke, you may have already seen this, but floating it up in case you have not
It’s an older thread with relevant advice on making the transition to Plans
Hello @Henke
Based off your initial screenshot it looks like you are missing client sap3.
Thank you, Collin
Thanks for the answer @Collin Harper
So given my example above would the below Plans cover it all?
//Henke
Hello @Henke
Unfortunately there is no ta 1 to 1 translation from Storage Policy\Schedule -» Plan.
The short answer to your question would be that you need as many plans as you’d like. Same with Storage Policies. You can back everything up under one Storage Policy\Plan, or you can separate backups into separate Storage Policies\Plans.
Each Plan has an associated RPO (Recovery Point Objective). This determines how often Incrementals are run, how often Fulls are run, and where Backup Windows can be set.
Other Administrative schedules like the Aux Copies, DDB Verifications, DDB Space Reclamations, are built in by default.
At this time there is no way to alter these schedules like you can in Java, but this functionality may come at a later data. We are working to port most functionality from Java into Command Center and not everything is ported over currently. We area always adding new features and functionality.