SnapCreator4.1 Policies

[SVOLLRAT1]

Hi Everybody

Just installed SC4.1 and discovered the new Policy-Features.

Tried to wrap my head around what they are good for and what the use-case could be, unfortunately with little success so far.

Is there any extended documentation on how to use them and what they are supposed to be good for?

Backup Types right now appears to be totally useless, just a Free-Text-Field for some Info that us usually already encoded in the Configuration-Name.

If it is for the purpose to get rid of that, why not associate it with the Configuration instead of the Policy-Objects. Backup-Types are defined by the stuff you back up, not by the schedules you run.

Policy Objects appear to be a nice way to overcome the limitations the built in Policies have by allowing to create Policies for monthly-Jobs or for jobs that require several different Retention periods.

Unfortunately I only get the Local-Type to work as expected, the Snapvault-Type won't work for me, either with SnapVault-Update enabled in Configuration or without. Relations are configured properly and work in a classic Configuration, don't know how to handle that type properly.

Policy-Schedules look like a nice way to predefine Backup-Times and Reoccurrences. What I don't really get is the Action-Type linked to it. I can have the same Schedule-Time and way different usages, creating one Schedule for each one blows up the list massively.

Finally I don't understand how the Relation Configuration -> Policy-Object -> Policy-Schedule should work in real life.

I tried to build a used case for just four of my Configurations. Since Policy-Object and Schedule are linked fix to each other I have to create multiple Objects when I want to have a specific Retention with multiple Schedules, blowing that List out of the roof or in that case requires a dozen Policy Objects.

Hope you can help me out and show me what errors I make in figuring that stuff out

Thanks in advance Guys

Stefan

[ktenzer]

Hi Stefan,

You bring up some good points and I agree policy objects are a bit confusing. This is a new concept and we aren't done with them and do have some big plans. We invision eventually policy objects being able to replace the local policies at config level, we arent there yet.

I will comment on your observations:

1) The Admin Guide explains how to implement policy objects but it doesnt really get into why? or what the use cases are. We are working on some video content for this and hopefully John Spinks will be posting some stuff soon.

2) Backup Types - yes this is just a label and is rather useless at this time, in fact we even debated removing it but decided to leave it as there could be value. I think your thought is definitely something we need to look into as you are right it has little use today.

3) To get multiple policies to work on config you need to create one policy for each type or retention. In your example you should have one policy for local and one snapvault. Then you need to schedule them and assign them at profile or config level.

4) The relation between a policy object and policy schedule is 1:1. The policy defines the retention and the schedule defines when it runs. A policy can be related to a profile or config. If you assign policy to profile it will overrule any config policy assignments. The current intention is that policy objects are used at profile level which requires organizing all configs according to policies (this is a big difference then how most organize profiles today). You can apply to configs but as I mentioned this can be overwritten by profile assignments. This is an area we are looking to make improvements and provide more flexibility.

5) I agree with your point on action being bound to policy schedules, this is something we need to improve as it requires more policy schedules. The issue is when you run SC there are different workflows and we need to know which workflow to run, backup, clone, etc...primarily you would have backup but other workflows could be used and then you have double the work creating schedules.

For most customers probably they will want to stay with local config policies in 4.1 and ignore policy objects. The current use case we have built is organizing profiles around policies. As i mentioned this requires different thinking and most current SC users are not setup and havent setup their environments to work this way. The main thing policy objects supports in SC 4.1 is Snap Manager for Oracle 7.0 (coming out soon), we plan on improving this feature and making it more usable for SC customers.

If you could provide a consolidated list of the things you would like and use cases you would like to solve this would be tremendously helpful.

I hope this email helped clear things up just a little

Regards,

Keith

[SVOLLRAT1]

Hi Keith

Thanks for the detailed answer, still not sure I understand the intention behind everything but may come to me after reading your post some more times 😉

For me as a Guy coming from the traditional Backup-Corner there are some basic parts that usually play together at a n:m relationship: Objects, Retentions and Schedules.

Objects are represented in SnapCreator as a Configuration, something with specific properties like CIFS-Shares, an Archive-Volume or a Database.

Each Object has one or more Retentions, either represented as Versions or time to keep, those won't need to be unique, f.E. several DBs may share the same Retention for Database Backups or Archivelogs. That is represented quite well in the Policy Objects right now, especially that you can name them to your liking say "backup_30days" or "archive_2days", giving us the chance to let the Retention out of the Snapshotname and still be able to know how long a Snap should be kept on Filer-Level (not every "daily" backup is kept the same amount of days). Depending on which Tools you use that Retention-Policy also has the Mode or Action in SnapCrator-Terms attached.

The most tricky part in the end is the Schedule, I have no Environment I could use the current way the Policy Schedules are intended whatsoever. Backups are always organized around Customers, Environments or Objects, not around their Schedules.

You do have your specific Timeframes or points and repetitions that you can predefine, but they are neither Bound to any Object or Retention directly.

It is more that you will end up being able to consolidate your Retentions and Schedules but will have many individually planned Jobs for each of them combined with the Objects

Hope that explanation makes some sense to you

Maybe an example:

Config	Policy	Schedule
DatabaseA	Backup_30days	daily 20:00
DatabaseA	Archive_2days	hourly 05
DatabaseA	Vault_365days	monthly 1stSunday 20:00
DatabaseB	Backup_30days	daily 20:00
DatabaseB	Archive_2days	hourly 05
DatabaseB	Vault_365days	monthly 1stSunday 20:00
FilerA	Backup_30days	daily 21:00
FilerB	Backup_5days	hourly 05
VMwareA	Backup_30days	daily 20:00
VMwareB	Backup_30days	daily 21:00
VMwareC	Backup_40days	daily 22:00
Archive	Backup_40days	daily 22:00

In this case I have 8 Configs, 5 different Retention-Policies and and 5 Schedule-Times.

This would result in 12 Sheduler entities that can be activated or deactivated as required (in contrast so the "eat everything or nothing" approach in the Policy-Schedules right now).

With Policy Objects I'd need at least 6 or even more Items to cover everything and wouldn't be able to f.E. disable Backup of DatabaseB for one night because of Maintenance.

Hope that helps

Thanks so far

Stefan