VDC 365 Retention / Schedule change

[dhayes16]

Hello All. Happy Holidays!!

So we were planning to onboard several customers over this long break into VDC for 365 (as vcsp with flex licensing) but we hit a little snag and stopped. During the initial onboarding setup for customers we chose not to select the default to backup the entire organization since we wanted to create (3) separate backup policies for (Mail/Archive, Onedrive and then sharepoint/teams) which I assumed was best practice. But during the onboarding we did see the option to change retention period (default to 1 year). But again we selected the option to manually create the policies. We created the (3) separate policies fine however we have the following questions:
#1) We do not see anywhere where we can change or even see what the retention policies are for the jobs. That is a little concerning since we have compliance targets we need to adhere to. Is it defaulted to forever somehow? Is there another place to see this item?
#2) We do not see any ability to schedule individual backup jobs. We just see that the backups run every 24-hours. Do we have any granular control over this? Again for compliance reasons above.
#3) Also, we have a few already deployed and backing up. Is there any way to change (or at least see) the retention policy?

Are these limitations of the flex licensing? And if so how do we change that if we are licensing via the VCSP backend

Thanks for any input

[micoolpaul]

Hi @dhayes16 happy holidays to you as well!

First thing I’d like to say is, don’t worry about the retention, as it can be increased!

We have a per-tenant setting to enable the creation of multiple repositories and to edit retention. I’m on leave until the new year but either work with support or your account team to get this enabled for your customer environments. As the data is service-level immutable, retention can only be increased in the portal once this is enabled.

You should know retention is driven at the backup repository level, not the job level. The relationship between job and retention is choosing the backup repository at the time of backup job creation.

Your main consideration at this point is your single repository means whilst you can change the retention you wouldn’t have multiple retentions so this may need to change for you in some scenarios.

Scheduling can’t be changed, you define the frequency and we schedule the jobs to load balance the workloads as part of this being “as a service”.

Hope this helps!
Michael

[dhayes16]

Thank you very much. We will reach out to support to get this enabled before we proceed.

Question for you. Now we have created a couple customer backups and they are running. If we wanted to assign specific jobs to a specific repo with a different retention is it possible to break those out now? I assume that even though we have 3 separate backup jobs they likely go to the same repo. I assume if immutable this is not possible?

Thanks for responding when you are on vacation.

[micoolpaul]

You’d need to rerun any jobs onto your new repository which is just wasting your time running them now so I’d suggest decide what is mission critical #1 for each customer, or the largest dataset, and have just that job run, and once you’ve got your additional repositories, recreate your additional jobs then!

Any further questions please don’t hesitate to ask!

[dhayes16]

Thanks. I guess I need to determine if separate repos and retention is important. Perhaps larger customers. I think the retention period itself is the most important.

Other than different retention periods what is the benefit of having separate repos? With vdc is it still best practice to have separate backup policies for different objects? Ie mailbox / archive only?

[micoolpaul]

That is the main benefit. I’ve also seen organisations made of different businesses opt to split their data per business unit so that if they sold an arm of the business and needed to have that historical data segmented or purged it’s been split up in that way already.