Versitygw as a backup target

[TonioRoffo]

Hello,

I've been doing some small tests to versitygw running as a S3 gateway.

It seems to be working (at least in smaller tests) and is very efficient on a single target machine - actually near native speed is achieved)
Object locking/versioning seems to be a step too far, it just locks up - without it, it seems to run fine (backups, mounting, deleting, all okay)

Still a bit confused about the underlying way versityg3 stores objects. I created a bucket, but on the filesystem itself, the veeam backup data seems to be stored in a different folder. When completely deleting from veeam point of view, the data is gone, but all the objects remain in this folder, taking up space still. (even with versioning disabled)

Did anyone else on the forum attempt to use versitygw? I'd love to discuss.

[TonioRoffo]

Well I guess it's far from veeam ready. Deleting the backups, including GFS, throws an error

"7/11/2025 10:50:09 Error [testtoberemoved_2025-11-07T095122] Failed to delete backup Error: Failed to copy checkpoint
Agent failed to process method {Cloud.DeleteBackup}."

[sfirmes]

@TonioRoffo ,

At this time, Versity isn't listed as a compatible S3 solution for use with our software.

I see that you reference GFS backups. Are you trying to use Versity's S3 Gateway with VBR's Archive Tier feature? If so, Versity isn't listed as a compatible solution for this feature either.

Please refer to our Veeam Ready page to find a list of the products that have passed our testing and are compatible with our software.

If/when they participate in Veeam Ready and pass the tests, I will update this thread.

Hope this helps.

[TonioRoffo]

Hello,

Thank you. I am aware that versitygw is not on the list. However I do love to tinker and see what is possible and open possibilities for the future. I was merely checking if others on the forum tried this way as well. I will send the veeam logs to the versitygw github and hope it is something that might be fixed in the future. The speed, even on silly hardware, was near perfect and backup/restore works flawlessly over quite a period of time. Only deleting data seem to throw an error at this point.

I have not used it as an archive or capacity tier at this point. Just a normal backup direct to S3 with keeping weeklies & monthlies turned on. When wanting to delete the whole repository I got the question if I wanted to keep the weekly and monthly full backups as well, that was what I was referring to.

The project is backed by large entities like CERN so it has a healthy future.

[sfirmes]

@TonioRoffo thanks for the clarifcation. Are you using their gateway to move the backup objects from the s3 store to tape or another storage target?

[TonioRoffo]

Towards a POSIX file system. Looking for a safer and more efficient way to use common NAS hardware.

[sfirmes]

@TonioRoffo I have a meeting with Versity coming up and will post any updates that come from it. If you have any specific questions that you would like me to ask, please post them or message me directly.

Thanks

Steve

[TonioRoffo]

@sfirmes - There is two relevant entries on their github page:

[Bug] - Delete S3 repository backup jobs in Veeam throws errors
#1637 In versity/versitygw

Veeam Ready program - list versitygw as a working and compatible Veeam backup repository system.
enhancement
#1633 In versity/versitygw

Thank you

[hilto]

Hi Veeam team and community,

I wanted to raise something that I think is becoming increasingly relevant for a lot of small-to-medium deployments: the state of self-hosted S3-compatible object storage, and specifically what should be considered as supported targets going forward.

As many of you will be aware, MinIO's licensing and project direction has shifted significantly over the past couple of years. What was once a go-to, open-source, drop-in S3-compatible backend for SMB and homelab environments is now effectively off the table for a large chunk of the community, either through licensing restrictions, the AGPL implications for self-hosted integrations, or simply the project pivoting away from the small-to-medium use case it once served so well.

This leaves a real gap, and I'd like to put two projects on the radar:


Versity S3 Gateway

Another option worth keeping an eye on is the Versity S3 Gateway. While perhaps not as immediately prominent as RustFS right now, it represents another avenue for teams looking for MinIO alternatives, particularly those who may want gateway-style S3 compatibility layered over existing storage infrastructure. Worth tracking for future consideration.

---

The MinIO situation has been brewing for a while, but we're now at the point where real-world deployments are being affected and admins are actively looking for alternatives. Getting ahead of this, even just with a community-curated compatibility note or a "tested by the community" acknowledgement, would be genuinely useful. It would help Veeam users make informed decisions and reduce the friction of building reliable backup infrastructure on modern, open-source object storage.

I don't think this requires a massive engineering lift, it's more about getting it on the radar, doing some compatibility testing, and adding it to the conversation. If others in the community have tested RustFS with Veeam, I'd love to hear how it went.

Thanks for reading, curious to hear what the Veeam team and community think.

Hilton.

[lmendel]

Hi @sfirmes

Any updates on after speaking with Versity? I saw the github #1633 and it looks like they are lacking some APIs.

Anyone using Versity ass their Veeam storage?

Thanks

[Mildur]

Hello @hilto,

I split your requests into two topics (one here and the other one here).
Please see my colleague @sfirmes’s earlier comments in this topic. I’ll ask him if we can provide any updates.

When it comes to “supported” object storage, we rely on specific AWS S3 endpoints. Any vendor that implemented these APIs is, in that sense, automatically supported by us. But it seems, Versity S3 GW has some missing APIs today.

Best regards,
Fabian

[sfirmes]

Folks,

Versity is aware of what they need to do to become compatible with our software. The last update was the modifications have been identified and are on their roadmap. I will try to get an update from them and see if we can get a timeframe for the delivery of these changes.

Thanks