As described by Andreas Neufert from Veeam, Virtual Disk Development Kit (VDDK) is provided by VMware which is leveraged by Veeam to perform backups and other functions. In this instance, there appears to be a bug introduced in VDDK after VMware introduced “a faster way to process data over Network NBD mode (async processing)” which is causing certain VMs to fail during backup jobs.
The recommendation from Andreas is to ensure the underlying ESXi hosts and vCenter are updated to the latest builds from VMware or Veeam support can add a registry key on the VBR server which disables the new VMware processing.
Veeam will always recommend calling support to obtain the reg key, this is to ensure you are applying the registry tweak for the right reason. However, if you are confident that you are affected by this issue, the details for the reg tweak have been provided below.
As with most IT enthusiasts, I use a homelab for tinkering, troubleshooting and hopefully a bit of learning. My homelab compute consists of a single server with an i7-3770 CPU / 32GB DDR3 RAM / 1TB SSD connected to an Intel BOXDQ77MK motherboard, basically a glorified PC. While my homelab can’t run dozens of virtual machines concurrently, it’s power-efficient, cheap and importantly quiet.
I built the server back in 2013 and to date, the server has been rock solid. At one point the server even hosted this very blog for over 3 years. The version of ESXi is a bit old and overdue for an upgrade so I thought this would be a good opportunity to document the process for anyone else interested in the ESXi upgrade process. Specifically for my case, I’ll be upgrading from VMware ESXi 6.5.0 (build 5969303) to VMware ESXi 6.7 (build 15160138).
I recently experienced a timeout error while offloading backups to a capacity tier (Azure BLOB). It occurred whenever Veeam offloaded large quantities of backup files simultaneously, typically any more than 6 backup files at a time would result in the offload failing.
This was a problem because the automatic SOBR offload process would process 40+ backup files at a time, most of which would fail until only 6 backup files remained in the queue, at this point the 6 remaining backup files would offload successfully. Typically there would be 250 or so backups in the offload queue, Veeam would offload these backup files for an hour until the timeout error occurred, then Veeam would start the next batch of 40 backups files to be offloaded.
Looking at the Veeam offload job logs (located in the main folder of the Veeam server logs, path ‘C:\ProgramData\Veeam\Backup\SOBR Offload’) we could see the following,
task example [18.08.2019 11:21:23] <176> Info – – – – Response: Archive Backup Chain: b14e8dd9-2351-4236-bd54-a08339859d49_40f33f92-ca5a-45ac-a2ec-d674efd0383d [18.08.2019 12:57:26] <844> Error AP error: WinHttpWriteData: 12002: The operation timed out [18.08.2019 12:57:26] <844> Error –tr:Write task completion error [18.08.2019 12:57:26] <844> Error Shared memory connection was closed
Last December I wrote about the Cloud Tier feature coming in Veeam Backup & Replication (B&R) v9.5 Update 4, specifically the ‘Move Mode’ within Capacity Tier. It’s been one of my most popular writes ups and it still receives quite a lot of traffic even today, so now with the upcoming v10 release bringing more capability to Cloud Tier I thought it would be worth a followup. To clear up any confusion, Cloud Tier is the marketing name while Capacity Tier is the technical name used in the GUI.
Native integration between Veeam and Object Storage has and continues to be one of the most discussed topics across the Veeam community in my opinion. Before B&R v9.5U4 was released, organisations had to rely on third-party solutions to function as gateways to object storage with Veeam jobs tweaked in such a manner to reduce or eliminate any ‘calls’ to backups written to object storage to minimise egress and access fees. Often these solutions didn’t scale well, inefficient and proved cumbersome to manage.
With B&R v9.5U4 came Cloud Tier, a feature that provided native object storage integration within Veeam for Amazon S3, Azure BLOB Storage, IBM Cloud object storage and S3-compatible service providers or on-premises storage supported.
I’ve been fortunate enough to be a member of the Veeam Vanguard program since 2017; an advocacy program run by Veeam consisting of like-minded individuals who are passionate about all things Veeam, many of whom I consider as friends. I always look forward to time spent with the group as the knowledge and experience shared within has always been invaluable to me. Hopefully, I have many more years in the Vanguard program to come, and I urge anyone with a passion for Veeam to apply for the program which is expected to open in late 2019.
One of many excellent perks that come with the program is attending the Vanguard Summit, for the second year in a row the summit was held in Prague. While it takes around 24 hours to travel from my home town of Brisbane to Prague, it’s well worth it. Prague is an amazing location, vastly different in so many ways compared to what this simple Australian is used to back home.
One of the reasons why the Vanguard Summit is held in the Czech Republic is because Veeam’s main Research and Development (R&D) Centre is located in Prague, making it the prime location for getting the Veeam R&D team and Vanguards in the same room. Anton Gostev, Alec King, Dmitry Popov, Pavel Tide, Nikita Skestakov, Oleg Patrakov and Mike Resseler all made appearances and presented on their areas of expertise.
During a recent Veeam ONE deployment I configured Veeam Intelligent Diagnostics (VID), a great feature that was introduced in Veeam ONE v9.5 Update 4. VID allows Veeam ONE to automatically detect known issues in the configuration and performance of Veeam backup infrastructure. It does this by parsing logs from Veeam Backup & Replication servers, analyses the logs against a known list of issue signatures and triggers an alarm with detailed information about what the issue is, and how it can be fixed.
I recently experienced an issue while deploying Veeam ONE, all backup proxy servers were failing to display CPU/Memory statistics with the following error, “Failed to collect performance data for object %servername%. The RPC Server is unavailable. (Exception from HRESULT: 0x800706BA)”.
It’s been a bit quiet on the blog front for the last couple of months because I’ve focussed my attention on a “little” side project which recently reached fruition. This side project was, of course, the VMCE 9.5 Unofficial Study Guide that we released on the 15th of March.
Rose Herden and I started working on the book back in November 2018, the initial framework of the book actually came from a presentation that Rasmus Haslund and I submitted for a VeeamON 2017 session. We had hoped to present but unfortunately, our submission not selected. From the ashes of that presentation, with contributions from Florian Raack plus several peer reviews from fellow Vanguards, VMCT trainers and Veeam employees, a study guide for the VMCE was born. Working closely with Rose on this book has been a fantastic experience, her knowledge and passion around the VMCE is second to none. What Rose has done around developing and assembling this book has been absolutely phenomenal.
Originally, the book was going to cover the basics around studying for the VMCE along with listing resources available such as the unofficial practice exams, write-ups, etc. Once Rose saw the early draft though she suggested we expanded the book by adding module guides, these would include key learning goals/outcomes, key terms, learning suggestions, concept checks and even a practice exam for every module from the VMCE courseware. These module guides quickly became the focus of the book filled with insight, tips and tricks from an experienced VMCT scattered throughout the chapter.
To date, our book has been downloaded over 800 times through our publisher, leanpub.com. We were even fortunate enough to be a featured book on leanpub during the first week of release. At the current rate, there is even chance of reaching over 1000 readers in the coming weeks. It’s a bit of an understatement when I say how this has completely blown us away to see how many readers have downloaded the book, we were aiming for 100-200 readers. More importantly, the feedback received so far from the community has been overwhelmingly positive which is a huge relief.
While the book is available for free, we’ve left the suggested price at $4.99 USD, readers just need to select the $0.00 price during checkout to download for free. Rose and I are very thankful to the readers who have paid for the book with any money raised going towards printing hard copies. We’ve initially planned for just 10 copies to be printed with any money left over to be donated to a charity called TECH GIRLS MOVEMENT.
Archive Tier was announced back at VeeamON 2017 New Orleans alongside a raft of new features scheduled for release with Veeam Backup & Replication v10. Archive Tier would enable Veeam administrators to easily add regular disk-based backup repositories, object-based storage repositories or even tape as an archive extent to a SOBR (Scale-Out Backup Repository) which could then be configured to copy any backup or move sealed backup files from the SOBR across to said archive extent.
The ability to archive backup files to a particular archive extent such as tape or cheaper disk was a great addition, but the significant improvement was the native integration with object storage which has been a highly requested feature for several years now. During VeeamON it was announced that AWS S3, AWS Glacier, Azure BLOB and Swift compatible object storage to be supported.
Copying Veeam backup files to object storage has always been possible through the use of third-party vendor storage gateways, such as the AWS Storage Gateway or Azure StoreSimple but speaking from my own experiences, these tools don’t always deliver what they promise and require additional skills to support.
I was just checking out Poul Preben’s blog and discovered a fix for an issue I encountered during an earlier Veeam deployment. Don’t you love finding answers to those mysterious issues, I certainly do.
The problem arose whenever I tried to add a particular windows server into the Veeam managed backup infrastructure. The server was earmarked to become a Veeam Proxy and Backup Repository. As per best practices we didn’t join this server to the domain and created a dedicated local account on the server for Veeam authentication. Remember if the logins on the machine to-be-backed up and the backup storage are the same, we call that unwanted correlation.
Unfortunately, we ran into the below issue when trying to install the Veeam Deployment Service.
[my.repository.fqdn] Failed to install deployment service.The Network path was not found–tr: Failed to create persistent connection to ADMIN$ shared folder on host [my.repository.fqdn].–tr: Failed to install service [VeeamDeploymentService] was not installed on the host [my.repository.fqdn].
The Veeam binaries are pushed through the ADMIN$ share and it turns out that this share cannot be accessed with a local administrator account by default, due to Remote UAC being enabled. If we had used the local Administrator (SID 500) account however, this issue wouldn’t have occurred.
Poul details the fix on his blog which I’ll link below.