Apologies for digging up a 3 year old post, but this was top search result by a well known search engine that rhymes with "moogle" using the terms "veeam powershell simpleretentionrestorepoints" (as I searched
)
I wanted to update the information in here, as there are now some inaccuracies (based on my recent experiences with v9.5)
Background
I have a customer for whom I have recently performed a massive VMware upgrade, which involved new vCenter and lots of consolidation.
As such, the Veeam backups were pretty much recreated from scratch, with no attempt at mapping VMs back to their old backup files (as jobs consolidated down too).
They had Veeam Backup Copy Jobs with a GFS retention specified running off the original backup jobs, going to a Windows 2012 R2 repository that is running Windows Deduplication. These jobs had 28 normal retentions, plus monthly, quarterly and yearly, and are need to be kept until the new backups reach that age of retentions.
Now, I had configured Windows Deduplication to ignore .VIB files, for performance-reasons when backup merges occurred (because the .VIB file will be untouched for 28 days by the time it merges, and will have been deduplicated), and these .VIB files are consuming a fair amount of space (uncompressed and non-deduped).
The Backup Copy Jobs aren't actively processing any backup data now, so I wanted to wind down the number of retentions that the old Backup Copy Jobs maintained at a rate of 1 per day, as the new Backup Copy Jobs ramped up the recovery points 1 per day (therefore maintaining the same number/days of retention per VM, that exists in both old and new backup jobs .... are you still following me?
)
Doing this manually is tedious, so I looked to write a script to decrement the "restore points to keep" value in the Backup Copy Jobs once per day, so as to trigger a backup merger once a day and remove a .VIB file.
Implementation
I started by researching the Veeam PowerShell commands and attributes/values I would need to alter, and hence I arrived at this thread
Now, initially I tried altering
Code: Select all
$JobOptions.GenerationPolicy.SimpleRetentionRestorePoints
but using PowerShell doesn't cause the backup copy job to restart (unlike the GUI), so it doesn't have an immediate effect.
So I tried letting the job reach the end of its cycle (every day at midnight) to see if it re-read its settings, but it didn't and the change had no effect.
I then determined that I would have to "sandwich" my alteration of the job options in-between Disabling the Backup Copy Job and then enabling it again afterwards.
However, I found out that the code executed too fast most of the time! This meant that the Backup Copy Job didn't disable and stop before the Enable command re-enabled it, so the change didn't take effect [still!]. (I would say about 1 in 10 times the Backup Copy Job did actual stop and restart, but 9 in 10 times it managed to avoid stopping altogether).
I then added code to wait for the Backup Copy Job to actual stop after issuing the Disable command, and then the Backup Copy Job did actually stop, and restart (as expected).
BUT ... it still didn't work, and no backup mergers took place
The value in the GUI had decremented though.
So this is when I looked harder and found that although the SimpleRetentionRestorePoints had decremented, the value of ActualRetentionRestorePoints was still the original value and so was GFSRecentPoints.
I changed the code to decrement both SimpleRetentionRestorePoints AND GFSRecentPoints (to the same value), and voila
ActualRetentionRestorePoints now showed the correct decremented value and a backup merger took place (removing the oldest restore point, as expected).
So, if GFS retention is specified, it is not the value of SimpleRetentionRestorePoints that matters, but the value of GFSRecentPoints. I haven't tried decrementing GFSRecentPoints without decrementing SimpleRetentionRestorePoints, but I now have the strong feeling that the two values should actually be kept the same. The GUI seems to do this.
My code (with no error checking and basic functionality) is
Code: Select all
function ReduceBackupCopyJobRetention
{
param
(
$JobName
)
$CopyJob = Get-VBRJob -Name $JobName
If ($CopyJob.IsIdle)
{
Disable-VBRJob -Job $CopyJob
While (!$CopyJob.IsStopped()) {}
}
$JobOptions = Get-VBRJobOptions -Job $CopyJob
$RestorePoints = $JobOptions.GenerationPolicy.GFSRecentPoints
$RestorePoints -= 1
If ($RestorePoints -le 1)
{
RestorePoints = 2
}
$JobOptions.GenerationPolicy.SimpleRetentionRestorePoints = $RestorePoints
$JobOptions.GenerationPolicy.GFSRecentPoints = $RestorePoints
Set-VBRJobOptions -Job $CopyJob -Options $JobOptions
Enable-VBRJob -Job $CopyJob
}
The GUI doesn't let the number of "restore points to keep" go below 2, so I check and don't let it go smaller than that.
Now the old Backup Copy Jobs should slow reduce their restore points (and .VIB files, and their consumed disk space), and eventually I will delete them and let the .VBK points get full deduplicated and retained until no longer required
I do an "IsIdle" check in case the Backup Copy Job is in the middle of doing a GFS restore point creation, as this can take a very long time (over a day sometimes, depending on how many jobs are trying to copy entire restore points to new VBK files .... yes Windows 2016 and new ReFS looks very interesting
)
[not enough dollars!]
