Best practices are guidelines you follow when deploying a system and want everything to work smoothly. But what about worst practices, those common mistakes and errors that inexperienced IT admin make when deploying or configuring a system? Here, I’ll discuss worst backup practices and how NOT to configure your virtual infrastructure’s backup solution with Veeam.
Wondering why I’m not writing about best practices? In the IT world, you don’t always have the time, budget or proper knowledge to implement everything perfectly and according to best practices. Today, I’ll explain some VM backup and Veeam Backup & Replication worst practices that most all of us have encountered over the years. I also give you some helpful tips for avoiding similar circumstances.
No planning or sizing
No planning or sizing is a common worst practice. While “it just works” often describes Veeam solutions, it doesn’t mean that you should “just install it.” A typical administrator usually installs Veeam with default settings by pressing the next button and without configuring it to fit infrastructure requirements. Likewise, when configuring the backup repository, IT administrators may just set it up with “some capacity,” which can mean any amount of space. If you create backup jobs with default settings and without considering any specifications of the system, you will most likely be calling Veeam support. You could also be facing issues such as failed backup jobs or under-provisioned repositories.
To avoid such scenarios, it’s recommended that you use Veeam ONE, Veeam’s monitoring and reporting tool, prior to installing Veeam Backup & Replication. With VeeamONE, you can run two very useful reports before configuring your backup jobs:
- VM Configuration Assessment — This report checks the configuration of your virtual machines and determines whether they are prepared to perform backups with Veeam Backup & Replication.
- VM Change Rate Estimation — This report helps you plan repository sizing by calculating the anticipated amount of VMs’ changed blocks, based on the VMs’ historical write rate data.
Veeam also has an online restore point calculator, a very handy tool for planning and sizing your environment. Give it a try!
Job chaining
Job chaining is another worst practice that IT admin may make when configuring backup jobs. With job chaining, each backup ends up being linked, one after another, so that after the first job is finished, the second one starts, and so on. This practice can cause different issues, such as longer backup windows or deferred backup jobs due to errors in job sessions. Chaining backup jobs should be used with prudence and only for specific scenarios when it is considered appropriate. For example, you don’t want to backup two applications together, so instead, you can link the first backup job to the second one, but not for all of your backup jobs.
Unless there is a specific scenario where it is appropriate, the recommendation is to allow Veeam to do the resource scheduling for you. This is because if a single job in the chain fails, the whole job chain will be affected and your backups won’t be successful.
The Veeam Backup & Replication scheduler runs more jobs simultaneously to optimize the backup time window by balancing the load on backup infrastructure components, choosing the transport mode and limiting bandwidth to the repository.
Not verifying backups
Not verifying backups is another worst practice. The reason you backup is to avoid data loss and to restore date them when disasters or other failures occur. But what if your backups have corrupted source data (such as only being visible on a new system boot) and can’t be restored? Then you’d have a huge problem because your data would be compromised. When it comes to business-critical information, this is a risk you don’t want to take! To avoid this problem, make sure that your backups are healthy and ready for restoration.
SureBackup is a Veeam technology that allows you to automatically test VM backups and validate recoverability. This task automatically boots VMs in an isolated Virtual Lab environment, executes health checks for the VM backups and provides a status report to your mailbox on your backups’ readiness. Verifying backups is vital because their failure can impact your SLAs and cost you a lot of money. Test your backups!
Not finalizing Instant VM Recovery
Not finalizing Instant VM Recovery is also a worst practice. An inexperienced IT admin may start a VM with Instant VM Recovery, and then forget about it. Running a VM from the repository for a long time can cause issues, because other sessions, such as backup jobs or SureBackup jobs, can’t run while the restore point is locked by Instant VM Recovery. This occurs because the VM is booted and running right from the backup file in read-only mode, without writing anything to the backup file. The Instant VM Recovery then creates a new separate file to store the changes, located on the C: drive of the Veeam Backup server. So, if you leave a VM running for days, this backup file will increase and consume the space on the Veeam Backup server.
The recommendation is that once the Instant VM Recovery is complete, to migrate the recovered VM to the production environment. You can read more about how to finalize the Instant VM Recovery process in this Veeam User Guide.
Conclusion
Understanding Veeam Backup & Replication worst practices can save you time, money and headaches. Have you identified any other Veeam Backup & Replication worst practices? Share them with me on Twitter at @Veeam.
See More:
- NEW Veeam Backup & Replication Community Edition
- Top 10 Best Practices for VMware Data Availability
- Backup Server placement and configuration: VMware backup best practices
- Best Practices for Hyper-V High Availability
- How to get benefits with Hyper-V virtualization
- Veeam Community Forums: Backup Copy Job does not delete old chain