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