A first look at the new Veeam SOSAPI

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×
Veeam Backup & Replication v12 is all about Object storage. Not just because it can write data directly to it, but also because – thanks to the introduction of a new set of API called SOSAPI – Veeam and the storage that supports these new API can better work together.


Veeam has introduced a new set of API, called SOS. It’s not a request for help, it stands for Smart Object Storage.
SOSAPI is the aim from Veeam to extend in a totally transparent way the original AWS S3 API, to enhance the capabilities of Object storage for Veeam operations. I say transparently because to not interfere with the S3 standard, SOSAPI will use different methods to interact with the storage so that it is simple for vendors to implement without having to change potential existing libraries. The way this is done is very clever!
First, the API are enabled at the bucket level: so you can have the same object storage exposing one bucket with “S3-Compatible” API, and another bucket with “S3-Integrated” API. Up to the customers and their needs.
In the bucket you want to use with SOSAPI, the storage system will create in the root folder a subfolder with a specific name:

Veeam SOSAPI folder.

and inside it some specific xml files:

Inside these files, the object storage presents information about its capabilities (not all the SOS API are mandatory) and updates its status, like free space. Veeam Backup & Replication polls these files every few minutes, in order to be always aware of the status of the Object storage. The final result in the UI is a different blue icon and a S3-integrated type:

and also a nice information about the total size of the bucket and the available space. You can see below a regular S3 bucket, where these information are not available.
And since SOS API “it’s just a file”, the rest of the S3 API don’t need to be changed at all. I said it was clever right?

Which additional capabilities SOSAPI add to S3?

I may blog in a following post what’s written inside the XML files, but as a starting point it’s more important to understand what additional capabilities the SOS API bring to the table. These capabilities are designed to optimize the usage of object storage by Veeam software, so think about them in these use cases, not as a general extension of the S3 API.
First, as you have already seen in the above example, is Space Reporting. S3 API don’t have this information, but thanks to SOS API now we can have them. And you can easily realize how vital this information can be: low space warnings can now be issued, and in a Veeam Scale-Out Repository (SOBR) now we can have multiple extends coming from object storage systems, each with their information about free space, so that initial placement and load balancing decisions can be properly taken.
(Note: multiple SOSAPI-enabled buckets per SOBR will be supported in a later version).
There are many more features, some already available like Smart Entities for example, and other planned. Smart Entities will probably require a dedicated post to explore their potential.
For now I want to list one more planned capability, Storage controlled Veeam default settings . Think about it as “storage profiles”: in some situations specific object storage vendors define best practices settings for Veeam product interaction with their storage system. The quickest example that comes to mind is block size: some vendor I talked to suggest to configure Veeam to use 4MB block size instead of the default 1MB:

Instead of configuring every new backup job with this value (and potentially failing to do so) Veeam server can read this setting from the SOSAPI and apply them to every created job that uses the SOSAPI-enabled bucket. Customers can still overwrite the values if they want to, but it’s great to have a “set and forget” policy.
In a following post I will show you SOSAPI running in my lab, so I’ll take a chance to show the content of those xml files.