Sending Veeam backups to object storage such as Azure Blob has become a hot topic in the last few years. According to Veeam’s quarterly report for the end of 2021, Veeam customers moved over 500 PB of backups just into the top 3 cloud object storage vendors alone.
With many organisations starting to dip their Veeam toes into object storage I thought I would write a bit more about the subject. This blog post is aimed at helping backup administrators who wish to better understand from a Veeam perspective working with public cloud object storage, specifically Azure Blob.
Compared to the traditional NAS or disk-based block storage Object Storage is a completely different shift in how data is stored and accessed. For example, in object storage, it’s intended that files are not modified. In fact, there is no way to modify part of an object’s data and any change requires deletion and replacement of the whole object.
In Azure terminology, objects are stored in a ‘Blob’, which can be thought of as similar to a volume on a disk but far more scalable. Blob storage is a pay-per-use service. Charges are monthly for the amount of data stored, accessing that data, and in the case of cool and archive tiers, a minimum required retention period. In case you haven’t realised, Blob storage is Microsoft’s object storage solution.
There are numerous methods we can utilise to leverage Microsoft Azure Blob with Veeam Backup & Replication. For example, Azure Blob can be used as an Archive Tier target within a SOBR (Scale-Out Backup Repository) for long-term retention of backups, an archive repository for Veeam NAS Backups and some readers may even be familiar with the external repositories function.
The most popular method is using Blob as a Veeam Capacity Tier which is configurable within a Veeam Scale-Out Backup Repository.
Why is Azure Blob so popular?
When installing Microsoft SQL Server 2014, you might come across a situation where the setup fails towards the end of the installation with the following error,
“Wait on the Database Engine recovery handle failed. Check the SQL server error log for potential causes.”
If you ignore the error and continue with the installation the following will be displayed.
After scouring the web for a fix I was able to resolve the problem with the below steps. Some answers asked me to both uninstall SQL Server and delete a specific set of SQL registry entries, I did not delete any registry entries. I fixed the error by only uninstalling SQL 2014 using add/remove programs.
After SQL 2014 was uninstalled, I restarted the server then started the installation by right clicking on “setup.exe” and selecting “start as administrator”. Proceed with the installation normally until you get to the Server Configuration section,
On the SQL Server Database Engine service, click the drop down option to select a new user.
Click “Find Now” then browse to “Network Service”, select this user and click OK.
It should now look like the above, now continue with the installation.
You should no longer have the issue.
Workaround to take back DC VM from CSV.
1. At this moment, your cluster is offline and failed due to its inability to connect to a Domain Controller.
2. Go to Cluster Shared Volume, select the Cluster volume which contained the VHD.
3.Offline the resources, right click and select Remove from Cluster Shared Volumes.
4. Once remove, go to Storage and you will see the disk located in Available Storage. Assign a Drive Letter and copy the VHD out.
This is the simple trick to recover the DC VM which is inside the CSV. Hopefully, you can now create the a new VM and point towards the copied VHD then start the Domain Controller. Once the DC is up, then you will be able to start the Hyper-V Failover Cluster.
Just to remind again, you should have at least 1 DC not in CSV or run in the physical server.