Retention Policies
This was created during a remote session with a support rep and I wanted to confirm that what we are doing is not incorrect. — Tom's Help Desk
I would not say, that it is not correct. The schedule looks just fine.
does not reimage the server, but reuploads all the files that had previously been backed up using block level backup. — Tom's Help Desk
If you are running full backup while running image-based - it will actually creates a newer image. If you are running file level backup - then new full backup creates new full version of each file and after that a new sequence of block-levels begins.
My question is does the versions kept apply to every backup done? — Tom's Help Desk
You can set different versioning for each backup you perform. This is done from the given backup plan wizard.
In case of a file level backup - if the given file was not changed, we don't create the new version. In other words, we don't re-backup all files, only changed ones.
Regarding the retention, I think you may find these articles helpful:
1. General article on retention policies in CloudBerry:
https://www.msp360.com/resources/blog/backup-retention-policies/
2. Steve, one of our MSP clients, overview the "delay purge" feature (this is a retention setting, that you may found interesting, while creating a flexible policy):
https://www.msp360.com/resources/blog/tips-from-steve-delay-purge-what-is-it-and-should-i-use-it/
3. And another article by Steve, on the real-life DR scenario. While it's not entirely about the retention, it can tell you a lot about how CloudBerry can be used in the wild:
https://www.msp360.com/resources/blog/disaster-recovery-scenario-example/