Tag Archives: BLOB

Failing over GRS Azure Storage with Veeam

Whenever using Veeam Backup for Azure, there are two recommended options for creating multiple copies of the backup data. First is a backup copy job from an external repository. The second option is to rely on the native storage redundancy provided by Azure, such as geo-redundant storage (GRS) or read-access geo-redundant storage (RA-GRS). The purpose of this article is to explore this second option by leveraging RA-GRS for achieving backup redundancy across two Azure regions.

As a quick reminder, with RA-GRS and GRS, the data is stored in two separate locations, with one being the primary location and the other being a secondary location. The secondary location is located in a different geographic region than the primary location, ensuring that data is safe even in the event of a regional outage or natural disaster.

For more detail on the different types of Azure storage check out my previous writeup here.

For the purpose of testing, A RA-GRS storage account was provisioned in Australia East from which Azure automatically configured the secondary region to Australia Southeast. This paired secondary region is determined based on the primary region and can’t be changed. Access to the storage account is via public endpoints.

Continue reading →

Veeam Backup Repository / Microsoft Azure Object Storage

4 Replies

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?

Continue reading →

WinHttpWriteData: 12002: The operation timed out

2 Replies

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

Continue reading →

Veeam Cloud Tier

5 Replies

What happened to Archive Tier?

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.

This is fantastic! Bye bye storsimple! #veeamon pic.twitter.com/StVYIxnd7F

— Rhys Hammond (@HammondRhys) May 17, 2017

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.

Continue reading →