Veeam v9 is here and if you have already performed the upgrade you might be a bit anxious to start using some of the new features that came along with it. In my case I’ve already gone ahead and done my due dilligence by enabling and configuring some of the new features on a few test backup/replication jobs and I’m ready to duplicate this to the rest of the environment – problem being I have A LOT of jobs to apply these to. As always I look to automation to solve this issue for me. One, it is way faster and two, it provides a consistent set of configuration (or errors) accross my jobs – making it far more easier to troubleshoot and change if need be. Thanfully Veeam provides a set of PowerShell cmdlets that allows me to automate the configuration of some of these features. So, if you are ready to go let’s have a look at a few of the new features within Veeam v9 and their corresponding PowerShell cmdlets.
Just a note – for each of these examples I’ve just posted the code to handle one object – but you could easily surround the blocks of code with a foreach() if you are looking to apply the configurations to many objects. <- this is what I have done however it’s easier and much easier to read if I just insert code dealing with individual objects.
Enabling Per-VM file chains
First up is the Per-VM Backup File Chain introduced in v9. In previous version of Veeam all of the VMs contained within a single job were also contained within single backup files – In the end we were left with some massive backup files sitting on our repositories. Having a massive file laying around isn’t such a big deal, but when the time came where we were required to manage or move that file in any way it presented a few problems – it took a long time to move and activity surrounding that file need be disabled until we were done. In the end we were left with a lot of waiting and no backups. The v9 Per-VM Backup File chain fixes this – it allows us to store our backup files on a per-vm basis, leaving them much easier to manage, not too mention the headaches that are saved if corruption on our backup files occur. Either way I wanted to enable this on a dozen or so of my repositories…
I say repository since that is where the per-VM Backup Chain is enabled – not on the job, not on the VM, on the actual Veeam Repository. The process of doing so is pretty simple, get our repository, set a flag to true, and call back the saveOptions() function – as follows…
|
1 2 3 4 5 |
$repo = Get-VBRBackupRepository -Name "Name of repository" $repo.Options.OneBackupFilePerVm = $true $repo.saveOptions() |
New Mount Server
In previous versions of Veeam before v9 certain restore operations required mounting backups to a Veeam backup server, which when dealing with remote sites could of resulted in increased bandwidth usage depending on how you had configured your environment. v9 gives us the ability to designated any windows machine as a mount server. The mount server can then be used as a mount point to perform file-level recovery operations, allowing the bandwidth to stay local at the remote site.
As with the Per-VM backup chains, mount servers are enabled on a repository level. In my cases I wanted my repositories and mount servers to be one of the same – in order to do that I simply get the remote repository, then call Set-VBRBackupRepository passing it my mount host name and turning on the vPowerNFS flag as shown below…
|
1 2 3 |
$repo = Get-VBRBackupRepository -Name "Name of repository" $repo | Set-VBRBackupRepository -MountHost (Get-VBRServer "Name of desired Mount Host") -EnableVPowerNFS |
Guest Interaction Proxy
Another new ROBO enhancing feature in v9 is the ability to specify a guest interaction proxy. Previously the Veeam Backup and Replication server handled deploying runtime processes into the VMs to facilitate different parts of the backup and replication jobs – in v9, we can now designate servers that may be onsite to do this – This helps in a couple of ways – first, this helps reduce traffic traversing our WAN and secondly, sometimes backup servers were isolated from the VMs they were backing up, prevening certain actions from even being able to take place. Anyways, the Guest Interaction Proxy is a per-job setting and is setup within the VSS settings of the job. In my cases I just needed to flip the AutoDetect to $true in order to get Veeam to select the proper GIP.
|
1 2 3 4 5 6 7 |
$job = Get-VBRJob -Name "Job Name" $vssoptions = $job.GetVssOptions() $vssoptions.GuestProxyAutoDetect = $True $job.setVssOptions($vssoptions) |
Enable deleted file blocks
Veeam v9 has introduced many data reduction technologies within their application in order to help us save space and more efficiently manage all of our backup capacity. The first technique we will look at is the ability to not backup deleted file blocks. This can be enabled on your existing backup jobs by setting the DirtyBlocksNullingEnabled flag as follows.
|
1 2 3 4 5 6 7 |
$job = Get-VBRJob -Name "Job Name" $joboptions = $job.getOptions() $joboptions.ViSourceOptions.DirtyBlocksNullingEnabled = $True $job.setOptions($jobOptions) |
Exluding certain folders/files
Another space saving feature inside of v9 is the ability to exclude or include certain files or folders contained with the VMs – think about Temp directories – under normal circumstances we don’t need them so why take up all that capacity backing them up. We can set this up by first setting the BackupScope property – this can be set to exclude folders (ExcludeSpecifiedFolders), only include folders(IncludeSpecifiedFolders) or simply backup everything(Everything). Depending on the setting of the BackupScope we then set the GuestFSExcludeOptions or the GuestFSIncludeOptions with an array of strings pointing to the desired folders – finally, saving our job options as follows…
|
1 2 3 4 5 6 7 8 9 10 11 |
$job = Get-VBRJob -Name "Job Name" $jobobject = Get-VBRJobObject -Job $job -Name "VM Name" $vssoptions = Get-VBRJobObjectVssOptions -ObjectInJob $jobobject $vssoptions.GuestFSExcludeOptions.BackupScope = "ExcludeSpecifiedFolders" $vssoptions.GuestFSExcludeOptions.ExcludeList = "C:\folder","D:\folder","c:\test\folder" $jobobject.SetVssOptions($vssoptions) |
Storage-Level Corruption Guard on Production Backup Jobs (not just backup copy)
SureBackup does a great job at ensuring our VMs will boot however they may be certain portions of our data that can become corrupt that can actually pass a SureBackup test. To help alleviate this, Veeam has introduced something called Storage-Level Corruption Guard (SLCG) to periodically identify and fix certain storage issues. SLCG has actually been around in previous versions, but only available for Backup Copy jobs. In v9 it can now be enabled on our production backup jobs, giving us one more piece of mind when the need to restore comes along. This is enabled by first enabling the EnableRechek (yes, it’s spelled like that) flag, then setting a schedule (Daily/Monthly) and few other options and finally saving our options… Below we’ve set a job up to perform SLCG on Fridays.
|
1 2 3 4 5 6 7 8 9 10 11 |
$job = Get-VBRJob -Name "Job Name" $joboptions = $job.getOptions() $joboptions.GenerationPolicy.EnableRechek = $True $joboptions.GenerationPolicy.RecheckScheduleKind = "Daily" $joboptions.GenerationPolicy.RecheckDays = "Friday" $job.setOptions($jobOptions) |
Defragment and compact full backup file – on production backups not just backup copy
Over time our full backup files can become bloated and heavily fragmented – when we delete a VM for example, the full backup might still be holding onto certain data that was in that VM. Normally we could take an active full backup in order to help purge this data, but as we all know that requires us to affect production and use up valuable resources. To help alleviate this v9 has introduced the ability to defragment and compact our full backups on a schedule. This is done very similar to that of SLGC, getting the VSS options of a job and setting the schedule. Below we enable our defrag to run on Fridays.
|
1 2 3 4 5 6 7 8 9 10 11 |
$job = Get-VBRJob -Name "Job Name" $joboptions = $job.getOptions() $joboptions.GenerationPolicy.EnableCompactFull = $True $joboptions.GenerationPolicy.CompactFullBackuScheduleKind = "Daily" $joboptions.GenerationPolicy.CompactFullBackupDays= "Friday" $job.setOptions($jobOptions) |
So there you have it – a little bit of automation for those that may have to update numerious jobs to fully take advantage of some of the features Veeam v9 has introduced. As always please feel free to reach out if any of this isn’t working, or you have any comments, questions, concerns, rants, etc. Thanks for reading!
