Blog

Veeam Policies from Tags or Attributes

last updated on 2018-07-14

Following on from the blog post on Veeam Backup as Code, there are several large customers who use VMware Tags or Attributes to help define backup job creation. This matters, because by doing so it reduces individual job maintenance, and in an ideal scenario allows Veeam Backup & Replication to 'manage itself', and your backups 'automagically' appear on disk.

This is a pretty cool concept that does not involve any user interface changes. Instead of manually creating jobs associated with specific VMware tags, we create a scheduled task that calls a PowerShell script. This script dynamically creates jobs from templates, and adds virtual machines based on their tags or attributes. Existing job object count and overall disk size are used as part of this calculation, so that no single job becomes 'too big' to manage individually. Of course, the reverse experience needs to managed too. Once a machine no longer requires this association, it is automatically removed from a job.

There are two example scripts you can download for this. Either BR-UpdateJobByTag or BR-UpdateJobByAttribute scripts, which will have to be run as a scheduled task with elevated rights. To update the job by tag a category should be used, and each tag value should have a similarly named template job. For attributes, the attribute name is set, and each value is associated with a template.

There are additional things that can be done around scheduling. And understandably, this is not a user-interface driven thing. But feedback is always welcome.

Veeam Backup as Code

last updated on 2018-05-22

Large Veeam Backup & Replication deployments require quite a bit of guidance. That's why we as Solution Architects have a job. For the last few years at VeeamON, I've been part of a session on Best Practices and Configuration, together with Preben Berg @poulpreben and @tdewin. For the session this year I discussed something a little bit different: 'Policy and Configuration Management'.

In reverse order, I discussed how you can automate Veeam best practices. In large deployments with 100s of jobs protecting 10K+ virtual machines, the more you can automate the better. Instead of worrying about having to interpret the Veeam Best Practice Guide you can use tools like the Environment Assessment Toolkit and Restore Point Simulator. But what if we took this a step further still? I demoed three PowerShell commandlets: Import-, Export- and Compare-VHMVBRJob, that come as part of VeeamHubModule.psm1. I also discussed a future tool that could take some of these concepts and create a dedicated user interface for them.

The concept is simple. You can use the Export-VHMVBRJob commandlet to export the existing job to JSON (BCX file) and store it in version control (git) and then use it to see changes over time. You can use the Import-VHMVBRJob commandlet to overwrite changes or create a new job based on this existing configuration, and use the Compare-VHMVBRJob commandlet to selectively compare configuration with jobs in production.

Another way to get close to a policy model in Veeam Backup & Replication is to use Veeam ONE to automatically generate tags, and use these tags in combination with template jobs to automatically generate jobs with the correct retention settings for your environment. The benefit of using PowerShell is that this allows this process to scale, and you can use commandlets like Find-VBRViEntity and Find-VBRHvEntity to automatically populate the jobs you create and or modify.

The Import-, Export- and Compare- commandlets still have a way to go, and this isn't the first project to help address editing Veeam jobs at scale. Code contributions or feedback are always welcome!

Re-IP Linux Replicas in Veeam Failover Plan

last updated on 2018-04-25

Veeam has a cool feature that allows you to change the IP Address of a virtual machine that is replicated, the only issue is that by default this works for Windows only. Every once in a while we get questions about how you would do this on Linux. To address this I wrote some example PowerShell scripts for Veeam to trigger Re-IP behavior on CentOs and Red Hat virtual machines, this concept can be extended to support all OS flavors. BR-UpdateReplicaIP consists of three parts:

  • BR-WatchFailover which is added as a pre-failover script to a Failover Plan.
  • BR-UpdateReplicaIp which watches the Failover Plan while it executes and Re-Ips the virtual machines as they fail over.
  • BR-UpdateReplicaIpModule which contains all the dependencies required.

BR-WatchFailover is run as a pre-failover script. This triggers BR-UpdateReplicaIp which stays running in the background. By default all scripts expect to be run from a static path (C:\Scripts\BR-UpdateReplicaIp) on the backup server. BR-UpdateReplicaIp uses VeeamPSSnapin, VMware.PowerCli and BR-UpdateReplicaIpModule.

For Re-IP to work Re-IP rules (ReIpRulesOptions) and Guest OS credentials (VssOptions.LinCreds or VssOptions.WinCreds) have to be set in the source Replication Job. Although those have to be configured, application consistency itself can be disabled. Note that these scripts all run in a different user space associated with the Veeam service account, which means certain defaults have to be set correctly. To allow successful connectivity this script sets PowerCLI to ignore invalid SSL certificates in this user space. If there are other defaults that need to be set in this user space be sure to address this as well.

Manually Extracting Veeam Backups

last updated on 2018-04-13

One of the cool things about Veeam Backup & Replication backup data is that you don't need Veeam to be installed to restore it. Normally people would use the Extract Utility, but you don't need to use this if you already have the Veeam Data Mover (VeeamAgent) installed. The Veeam Data Mover consists of a server and client relationship, one that actually can be controlled manually.

First the Data Mover server instance has to be started, and session credentials have to be specified. Then we can instruct the Data Mover client instance to connect to the local port associated with the server instance (using shared memory in our case), using the credentials we set previously. Once the connection is established we can start issuing restore commands. This allows you to restore the data directly from the backup chain without any other Veeam components available. If you look at an example Backup Data Extractor script, you'll see how this works in detail. This script was written to help with restore from Agent backups where we had little information about the source systems, and we needed the internal XML data inside the backup files. If this is useful, if you want to contribute, or have other feedback let me know.

An Update From the Void

last updated on 2018-03-30

While working, I often spend time on projects that I find I have little time to share about afterwards. I used to blog a little bit in my spare time. It was mostly an experiment back then, but this time around I want to take it a little more seriously.