Newbie Alert! Hello Everyone I am new to Commvault I took over an environment which has more than 200 storage policies. These policies were created as a result of plans created using command center. We have more than 2000 VMs and 200+ filesystem clients and Databases. I was wondering how should I approach the cleanup. Is it a good idea to use plans for larger environments, because as a result of single plan there are multiple configurations created automatically. Thank You

Each plan should have a corresponding storage policy in the Java UIso there shouldnt be a 1 to many ratio, unless many plans have been deleted, or you are using region based plans.Lets ignore what we see in Java UI for a minute.A server plan is an encapsulation of; Name,Storage Target , Retention, backup frequency, schedule, content to backup (for FS) and options, snapshot options, and database options, all rolled into 1 “container”.Lets break each aspect down, ill colorize some of the words to draw attention to them as they are either labels in the UI or terms that need focus. We will start from top to bottom on the create server plan window. Plan name is the friendly name of the plan. I always recommend using a name that is descriptive to talk about what its for, what storage, and maybe frequency. Something like Daily_FSVM_Netapp_MCSS_30_90, so I know that its my daily FS/VM plan, that writes to my netapp, secondary to MCSS (Metallic cloud storage service), primary retention is for 30 days and MCSS copy for 90.The storage target and retention are part of the “Backup Destination” section in the plan. This is where you tell the backups were to go and how long to keep them. You can also enable extended retention rules here if you need to keep certain aspects longer. The retentionalso has as role in the schedule, we will get to that in a minute.The next part is RPO, this is your “schedule”. This is the incremental backup frequency in minutes/hours/days/weeks/months/years, along with the start time. This allows you to control how often and when backups can run. This can be further isolated to days and times via the “Backup window”. A “backupwindow”controls when the backups can run on a plan level. Similar to a “Blackout Window”which can be applied on the cell, company, server group, level. Under “RPO”, you can also schedule traditional Full backups, with corresponding options, and windows. Remember when i mentioned that theretention has a role in the schedule, this is where the automatic synthetic full gets its schedule from. In order for a cycle to close and for pruning to remove older backups based on theretentionthe cycle, we must runfull or synthetic full (as a cycle is considered Full to Full). So when you create the plan and set the retention, the synthetic full backup schedule is aligned to that timeframe. This is how we close cycles in the event you never run traditional fulls.The collapsed “Folders to backup” is yourcontent to backup for file systems. This by default is everything, but also allows you to filter files, folders, patters, and control system state options and other components. Say you wanted to specifically run a backup for a single folder that exists across your entire file server estate. You can control this from a single plan using this method.The backup “snapshot options”section allows you to control recovery points, their retention and enable backup copy operations and runtime. I would recommend you venture into BOL for more details on that, as I dont think it will pertain to the summary of this post.Finally, the database option which allows you to control log backup RPO and you want to use the disk caching feature. For databases instead of using the regular RPO option, translogs usually have more aggressive protection needs, so this option controls when translogs get protected. With the understanding of these foundational aspects, when looking to consolidate,start with least restricted needs of machines that need to go to a storage target. That should be one plan. As requirements for run time, backup type, or storage targets change, those would require an additional plans. This should help narrow down the scope of what needs to stay, and what may be overlap.

Backup Plans vs Storage Policies

Userlevel 6

+12

MFasulo
Vaulter
175 replies
2 years ago
10 June 2021

Adding to this thread….

Let’s say a customer has been using old school policies since the beginning, has 5000+ VMs and at least 70-80 storage policies in place. Now such customer cannot take advantage of features available only from Command Center - e.g. VM snapshot indexing for Azure.

Does Commvault plan to introduce some kind of workflow\upgrade process that would automatically convert old school storage policies \ schedule policies etc into plans? I think that would be very useful for customers like me who find it difficult to redesign everything from scratch (e.g. new policy equals a need to make new full baseline backup, which in cloud for 5PB of data costs A LOT) :)

I believe there is one app in Commvault store that does the job. Converts the old school policies to plan.

https://documentation.commvault.com/commvault/v11/article?p=130123.htm

The link to the 11.23 version of this article is https://documentation.commvault.com/11.23/essential/130121_converting_commcell_console_storage_policies_to_command_center_server_plans.html

But I cannot seem to find an equivalent ”expert” link. This is frustrating about the new way of organizing the essential/expert documentation, if you are in the essential thread, there is no immediate way to hop over to expert.

An “expert” equivalent doesn't always exist. The article numbers and classification are different.

I hear what you are saying, if you are deep into “vmware” and got through the basic, and want to deep dive, bring me to the “vmware expert” docs. I’ll figure out some way for this.

M

+1

Adding to this thread….

Let’s say a customer has been using old school policies since the beginning, has 5000+ VMs and at least 70-80 storage policies in place. Now such customer cannot take advantage of features available only from Command Center - e.g. VM snapshot indexing for Azure.

Does Commvault plan to introduce some kind of workflow\upgrade process that would automatically convert old school storage policies \ schedule policies etc into plans? I think that would be very useful for customers like me who find it difficult to redesign everything from scratch (e.g. new policy equals a need to make new full baseline backup, which in cloud for 5PB of data costs A LOT) :)

A

Userlevel 2

+4

Abdul Wajid
Author
Byte
15 replies
3 years ago
27 January 2021

Hi Jordan

Thank you for the reply.
Currently we have around 200 plans configured and more than 50 are not being associated with any clients. That’s where we have to do the cleanup.
My question is is it a good idea to start configuring plans instead of traditional way of configuring backups using storage policies and scheduling them by manually creating schedules if we have, in our case more than 2000 VMs. We cannot configure a single plan to backup all the VMs so we will create multiple plans and each plan creates separate storage policy. This will eventually create redundant storage policies with similar retention rules. I hope I was able to explain my point.

Thank you

M

Userlevel 1

+7

In addition to the extensive and detailed explication from @MFasulo regarding plan, I would definitely recommend to adhere to plans instead of going back to the old school. Plans are the future!

You also see this back in the functionality that has been added to the solution over the last few months as they do not support regular old school storage policies anymore e.g. when configuring it through Command Center.

Onno I could hug you for this (when the world opens back up, come to NJ, all the scotch you can drink is on me). Plans will continue to evolve and there will be features that you will only take advantage of when leveraging plans. As we continue to look into incorporating ML based logic into plans for things like RPO adherence and prioritization, plans becomes an essential part of the future of Command Center.

Deal ;-) I'm a big fan of the idea behind it, because the concept is easier to understand for a larger audience and everyone in the field is implementing the same thinking so it becomes are more commonly used "standard". I do however hope that at some point in time some of the recent changes are reworked because to me the idea behind plans it is to pick the data, algorithms and use compute power to calculate best run time for the jobs taking into account:

Run time
Last job result
RPO
Performance impact on client computer when using agent level backup to automatically start throttling resource usage to make sure application performance remains acceptable. If RPO is impacted it will send alert to inform admin to increase system resources.
Run backup related process with low system process priority but run restore related processed with normal priority
RTO (stream calculation and or possible chopping of the data into multiple smaller sets)
Adhere to blackout window but to show alert when blackout window is blocking the RPO from being met.

To summarize…… AUTOMAGIC PLAN :-)

PS:I still need to write you a mail regarding another topic. Hope i can make some time for it to outline my ideas.

Hi Onna,

It is great catch for me about plans. As of now I though that the plans are just combining Storage Policy/Schedule Policy/ Subclient policy.

But, today I got some great magic behind it. Can you share any resource to more details about full advantage of Plans.

Thanks,

Mani

Backup Plans vs Storage Policies

29 replies

Reply

Reply

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded