There is a lot of stuff to consider. Anyone who hasn't done it before is going to oversimplify it, they can't help it. If you want to know more about it, you should come up with a solution that works for you. What works for you is unlikely to work for everyone and that's why it isn't implemented. Just speaking as someone who has implemented rolling snapshots on a number of platforms.
First, you have to be aware of how much free space is available on all the production storage and set a threshold beyong which it will abort. Your snapshot length needs to work within the amount of free space you have. You have to check to see if the VM is on or off, or if the guest agent is available to be able to handle the freeze and thaw processes, etc.
Second, you have to be aware of any passthrough hardware because that will cause problems during a machine snapshot. If you are passing in physical hardware, it technically is no longer a VM. You may want to pursue storage snapshots only or come up with a way of dismounting your passthrough hardware during the snapshot (not always possible).
Third, by having an automated process taking custody of snapshot chains, and understanding how dangerous "permanent" snapshots can be if people forget to eventually merge them and clean them up, you will eventually come up with a janitor process to keep the chain clean, whether a snapshot was orphaned or fell out of the rotation or was missed for some reason, snapshots exceeding a certain age should be deleted regardless of their purpose.
Your script may start out as "del snapshot .... create snapshot..." but it snowballs quickly.
Finally, some people may want to exclude certain disks from their rolling snapshot scheme. Unfortunately only VMware provides that kind of distinction with its persistent/dependent disk option. Hyper-V and qemu do not do that. I wish other platforms provided this.
corsinvest is great. look at their "BARC" solution for ceph backups. it was easily adapted for our needs.
