Browsing and retrieving files is as simple as you would expect with your typical object storage service, files can be browsed via the web interface and file versioning can be easily accessed.

By default, each Backblaze B2 bucket will keep all versions of all files forever, this is not a bad strategy but you may end up paying for storing backup data outside your retention requirements.

Because of the way Backblaze B2 works, when the same file is uploaded more than once to the same bucket, Backblaze B2 automatically keep both versions of the file but will “hide” any older versions from the B2 Web GUI. You can tell if the same file has been uploaded multiple times a (2) or any other number closely follows at the end of the file name when browsing files via the B2 web interface.

Using the B2 lifecycle rule, we can define how long we wish to keep file versions that are not the current version. File versions are be automatically hidden whenever a newer file with the same name is uploaded. These ‘hidden’ files are simply the older version of a file that has been replaced by a newer copy. Using the B2 lifecycle settings we can define our online retention outside of Veeam for how long we wish to keep our backup files in the bucket regardless if they have been overwritten or deleted from the Veeam repository.

• ‘Days Till Hide’ defines how long to keep file versions that are not the current version.
• ‘Days Till Delete’ defines how long to keep that file version until it is deleted.

When a Veeam backup job runs, it creates a backup file based on the following properties, %JOBNAME%,%DATE%,%TIME%. This results in essentially a unique file for each restore point for each job created by that Veeam BnR server. Meaning when we leverage B2 using Cloud Sync, we should find that backup files avoid any versioning, this includes .VBK, VBI and .VBR file extensions. The .VBM file, which only contains the %JOBNAME% in the filename, on the other hand, will be versioned several times as that file is constantly overwritten each time the backup job runs. This means unless we define a lifecycle rule for the .VBM file it could become very cluttered.

So for a file like the .VBM file we can create a lifecycle rule that keeps the old version for 30 days, and then deletes them:  

Regarding our .vbk files and .vbi files, as these are unique file names being uploaded we won’t see any file versioning occur. If no file versioning occurs then by default these files will remain forever in our B2 bucket. If we want to eventually purge the old restore points to keep our data consumption fees lower then we’d need to configure the following based the offsite retention requirements.

For me, I’m happy for 120 days for my incremental and 360 days for my fulls.

Lifecycle rules are applied once a day. Rules will be applied at the next daily run after that number of days has passed.

We have tested and tuned your buckets, congratulations, on to the summary.