Having to keep different retentions for different SLA's is not possible with the new backup copy jobs,
as you can only pick entire jobs and not single VM's as in the original backup copy (periodic copy)
We are stuck on having to use the old style of the jobs for some VM's because of a larger retentions,
but we'd like to have the feature to copy the transaction log backups asap.
A workaround for this it to place these VM's in a separate backup job, but it's not as sexy.
Hi, Gert. This is not currently planned. Have you thought about simply moving those "special" VMs into the dedicated primary backup jobs? It seems like they require custom approach anyway, so it makes sense to have a separate "protection policy" for them. Thanks!
I think this will "break" a lot of peoples environment where the short team backup first lands on pure
SSD with a fixed retention and then gets of loaded to slower HDD storage for longer retention periods.
This means that now we have to have more unnecessary backup jobs lying around because the new functionality
can't match the previous type of backup copy jobs and in the end this means more management.
I've just noticed as well that it's still possible to define exclusions of particular VM's,
so the new type of backup copy jobs have the underlying functionality to do this.
One could exclude all other VM's from the backup copy job, but this would be a nightmare to administrate
as when new VM's added to the source backup job would be needed the excluded every time.
So this more seems of an interface functionality that is missing as the underlying system can already do this?
No, it's not just UI for sure. Requiring to specify a whole job as the source for Backup Copy jobs addresses years of bugs and data corruptions that we went through due to this "flexibility" of the original backup job. For example, if you specify a VM that is (accidentally or not) protected by more than one primary backup job.
