Just a small write up regarding the some of the most common Veeam B&R mistakes that I’ve seen lately.
1.Backing up the Veeam B&R Server
It may come as a bit of shock but you shouldn’t actually back up the Veeam B&R server using a backup job in Veeam. In most cases, Veeam won’t be bothered by this but on occasion, Veeam can experience the following symptoms.
- Disconnection from the configuration database.
- Disconnection from remote Veeam Backup & Replication agents.
- Disconnection from network storages (for example, storages presented via iSCSI) and so on
This is caused by the freezing caused during snapshot creation and committing so instead, you should rely on Veeams built in ‘Configuration Backup’ function.
2.Veeam Configuration Backup not setup properly
This is by far the most common mistake but the easiest to fix. By default the Veeam B&R server will backup it’s configuration up at 10:00 AM every day to the default backup repository. Often I see this is left in its default state and the backup files are neither copied offsite or encrypted. Getting this configuration backup files offsite is simple and easy so in my mind, there is no reason not to do this.
- If you have an offsite site you can configure a file copy job
- If you are using tapes you can use the file to tape job
- Alternatively, I’ve seen customers use dropbox or google drive to get the configuration backup files offsite.
Why do we care about getting the configuration file offsite? Well, partly because you should always use the configuration backup functionality to back up and restore the configuration of the Veeam B&R server. Secondly, its a lot faster to restore using the configuration backup compared to manually reconfiguring Veeam from scratch.
Enabling encryption for the backup configuration is also critical. If you don’t enable encryption for the Veeam configuration backup this means all those credentials used for the application aware processing will be lost in the event of restoring the configuration backup to a fresh Veeam B&R server. I’ve only migrated one Veeam B&R instances with no encryption for the configuration backup enabled, I learnt pretty quick to always enable it after spending hours reconfiguring it.
3. 1-Click Failover not setup properly
1-Click failover is an awesome feature that reduces the complexity of managing failovers. It’s basically a failover plan which handles the startup order, the delay between startups and automates the running of scripts in a single operation. You could initiate a failover plan using a mobile phone in bed at 3 o’clock in the morning without ever getting out of bed if you really wanted to.
So utilising 1-click failover plans through Veeam Enterprise Manager (VEM) during a disaster means VEM can’t be down. It’s important to note that we can initiate a failover plan through the Veeam B&R console without VEM and it’s really only a minor issue if VEM is offline but I’ve seen customers first hand specifically plan to use the web portal to start their failover plans. Well, that’s great except if VEM is running from the production site.
In this instance, it was managing/federated with the B&R server at DR which was handling the replication but in the event of a total production site loss, this customer would lose access to VEM and the web portal. Luckily it’s not a big deal since the customer could still access failover plans through the DR B&R server. At best a minor inconvenience which delays failover.
I’ve also seen lately customers with a limited budget having a single vCenter managing both production ESXi hosts and the hosts in DR. If Veeam is configured to replicate through the production vCenter to the managed DR ESXi hosts you are going to have a bad day during failover.In this scenario, you can either run up a second vCenter in DR, configure Veeam to replicate directly to a standalone host which introduces its own headaches (SureReplica) or plan to manually power on the vCenter replica first at DR. If your only vCenter at production is a physical server it might be time to consider virtualising it.
4. No Backup Verification
I usually don’t raise an eyebrow when customers choose not to test their replicas but not verifying your backups never has a valid excuse in my book. What’s the point of backing up if you don’t know that you can recover?
Now backups are the always the first thing that comes to my mind when disaster strikes and while it’s a good thing that Veeam replicas can still function as a kind of backup with their guest os file level restores and more but their recovery points are much more limited. I like to consider backups are all about RPOs and retention while replicas are focused on RTOs, Instant VM Recovery tends to blur the lines a bit, though.
If you don’t have the correct licensing for SureBackup, it doesn’t matter. Run up an Instant VMRecovery and test in an isolated network.
What about just using SureReplica but no SureBackup, well I certainly would feel more comfortable knowing I could at least restore recent copies of data from the replica but anything outside of the replica restore points retention will be an unknown regarding recoverability.
6. MS Dedup Backup Repository setup incorrectly
Microsoft DeDupe can be a great for reducing the size of your backup files in the backup repository. Unfortunately, there are few key settings that need to be set at the time of the volume creation as it’s not possible to apply the settings after the volume is created.
For a better explanation of how DeDupe should be configured, check out this awesome article over at kool-aid
Other worthy contenders would be
- Not excluding Veeam from the A/V
- Job Chaining instead of scheduling
- Not following the 3-2-1 backup rule
- Not using vSphere Tags
- Backup Jobs using guest indexing when you aren’t not using 1-click restores.