Lowering / Reduce retention for existing backups

[dasfliege]

I wanted to know what happens if i lower / decrease the snapshot based retention period for existing M365 backups
For example: i started performing backups for a customer with a retention period of 1 year. After 2 years, the customer decides to store only 180 days of backups, because they have a too high change rate, which causes extensive storage consumption.
- Will VBM365 delete every restore point older then 180 days immediately?
- Or will the restore points created with 1 year retention only be deleted after 365 days, even though the retention on the repository has been lowered?

[Mildur]

Hello Florin

- Will VBM365 delete every restore point older then 180 days immediately?

This. There is a retention job (default: daily 12:00 AM) which takes care of applying the retention to the restore points.
The retention job will remove all restore points outside of the specified retention period.

Please note, jet database based repositories won't get smaller. But the already occupied space on the volume can be reused for new backups.

Best,
Fabian

[dasfliege]

Thanks Mildur. This explains why the repository size is not shrinking in our case
If we "Move-VBOEntityData" to a new repository, will it release the unused space?

[Mildur]

The Move-VBOEntityData function does not release unused space. Jet databases cannot be shrunk, although it may be possible with eseutil, it is a lengthy process and not supported. I do not recommend using it.

However, you can use the move command to transfer any remaining restore points to a new repository and then delete the old repository. Backup jobs will not run during this migration to a new repository.
Instead of performing this migration, I suggest waiting until version 8 is released and then considering a migration to object storage. The benefits of our upcoming version should make the migration to object storage worthwhile.

Best regards,
Fabian

[dasfliege]

Yes, we definately will move to Object Storage within the next few months. Hardware is ordered already.
However, i have to find a workaroud for the current problem we're experiencing with one specific customer, who has >20TB of data beeing backed up and we charge for used space, so 180 days makes quite a huge difference.

One more question:
In the storage consumption report from VBM365, we see negative values in the daily grow column since we reduced to 180 days retention. Is the report showing the actual size of the backupdata, or does it also contain the "unreleased" data? As we have a difference between the value in the report and the value of the windows drive, i would assume that the report is more acurate?

[Mildur]

Hi Florin

The report should show you the real size of the restore points and not the size of the *.adb files.
Does the report show the same data as the GET-VBOUsageData command?

Get-VBOUsageData -Repository <VBORepository> -Organization <VBOOrganization>

Code: Select all

$repository = Get-VBORepository -Name "Repository1"
$organization = Get-VBOOrganization -Name "Organization1"
Get-VBOUsageData -Repository $repository -Organization $organization

Best,
Fabian

[dasfliege]

Almost:

Get-VBOUsageData: 18.5TB
Report: 19TB
Windows Drive: 21.9TB

If we can rely on the value on the report, this is just fine, as this is the amount that we charge our customers for.

[kshaeta]

The Move-VBOEntityData function does not release unused space. Jet databases cannot be shrunk, although it may be possible with eseutil, it is a lengthy process and not supported. I do not recommend using it.

However, you can use the move command to transfer any remaining restore points to a new repository and then delete the old repository. Backup jobs will not run during this migration to a new repository.
Instead of performing this migration, I suggest waiting until version 8 is released and then considering a migration to object storage. The benefits of our upcoming version should make the migration to object storage worthwhile.

Best regards,
Fabian

What are the features in the version 8 release of object storage that will fix this issue? We are facing a similar issue, we had a retention of 3 years (why, because when we started, I wasn't thinking about "the future"), that I reduced 2 two years to help decrease the space used, but as noted, this didn't do anything because as you mentioned above the JETDB doesn't relinquish it's territory. When is the expected release date of 8, and can you point to the "New & Improved" features that would aid with this issue?

Also, when I calculate our data in M365, it only comes to about 1.5TB, but in the JETDB, it says it's 3.9TB... this is from running the script you provided above. Soooooooooo.... what does that mean? Does that mean that there is 2.4TB of backup data that is just backup copies of the primary data objects, or snapshots, or whatever the correct term is?

[Mike Resseler]

Hey,

There are no new features in v8 when it comes to Jet DB. Object Storage is a different type of repository (our preferred one). If you have reduced your retention to 2 years, it means that the databases should start to be removed at the end of the year (we have a minimum of 1 JetDB per year, and when the retention for that year is gone, it will remove it fully).

Concerning the data size: The 1.5 TB is (I presume) the data in production. However, you constantly receive / edit / delete ... data which means that we keep copies of those while they are not in production anymore, hence the 3.9 TB of backup data.