As you mentioned, every situation is different. Retention periods simply refer to "how far back do you need to recover from". If your data is otherwise protected and company policy is being met by that retention period, you might be OK. If you just want MBS to provide the "most recent image" and don't need it for data retention then you can set your retention to be very small.

Typically what you're asking is all about recovery time objective (RTO) and recovery point objective (RPO), here's information on the differences: https://www.msp360.com/resources/blog/rto-vs-rpo-difference/

I wish there was a "standard" answer but it really does depend on each situation. Certain regulations can also dictate retention periods and then there's company policy, especially if you need to do "discovery" for a lawsuit.

I'd also consider if you are running more of a cloud backup, local or hybrid?
What's the size of your instances? If you are running cloud, is your ISP good enough to upload images daily? If not, consider running synthetic full image backup (www.cloudberrylab.com/blog/synthetic-full-backup-with-cloudberry-backup/)
But, as Doug said, consider your RTO/RPO first.

Thank you both for your replies. Those links have really good information, especially the "Block Level Backup and Full Backup Explained" linked in the article that Denis linked.

Our current schedule for backups is:
Backup options:
Compression: enabled
Encryption: disabled
Retention policy:
purge version older than 7 day(s)
keep only 7 versions
Schedule backup:
Occurs every week on Monday, Tuesday, Wednesday, Thursday, Friday at 12:00 AM.
Full backup options:
Full backup schedule:
Occurs every week on Saturday at 12:00 AM.

This was created during a remote session with a support rep and I wanted to confirm that what we are doing is not incorrect. The RTO and RPO are definitely going to be customer specific and that will be something I will have to go over with them. For the time being, I wanted to get the current situation in order. From what I read in the article linked above the "Full Backup" does not reimage the server, but reuploads all the files that had previously been backed up using block level backup. That does make a lot of sense so what I had thought of doing is performing a block level backup two-three times a day and a full backup once a night at midnight. What I wanted to confirm is how many versions we wanted to keep in the cloud. As I had said before with our current local backups we can see the previous versions going back years so to cut costs I would like to have only 1-2 versions available. Storage space is the main deterrent from keeping more versions and I would like to keep the backups as small as possible.

Let me know what you guys think.

The MBS backup is just cloud, we already have a system for local backups. The instance sizes range from around 200gb of data backed up to just over 1tb. Some of our customer's ISPs are very fast while others are not so much. The synthetic backup looks good except we would have to switch over to S3 (currently on B2).

My question is does the versions kept apply to every backup done? or just the files themselves. Like does the backup consist of 7 changes of each file that is purged? If there is any documentation on the retention policy I would be happy to take a look at it.

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/