Request: support for extra repository types

[dr.Koen]

I find it a bit disappointing that Veeam Backup for O365 cannot be integrated with the B&R console, and I saw other treads requesting this feature. But I find it even more disappointing that only a limited amount of repository types can be used. More specifically, I would like to use a CIFS repository but apparently this is not supported. Are there plans to reach the same compatibility level as B&R?

[nielsengelen]

You can use SMB3 as a repository. Since CIFS is a form of SMB, my question to you is, why the request for CIFS specifically? Are you using a specific backup target which doesn't support SMB3 (which is way better vs CIFS)?

[dr.Koen]

This is a NetApp SVM with CIFS sharing. As far as I know there is no possibility to switch that to SMB3. I solved the issue by switching to an iSCSI SVM, something which Veeam O365 can handle. So far so good, but I can use a CIFS share as repository in B&R without issues. It does not seem logical to me that 2 products from the same company differ in specifications like that.

[Polina]

Koen,

These two solutions - VBR and VBO - are very different in terms of the underlying databases, which drives the different repository requirements.

[dr.Koen]

Thank you for the reply, Polina. Being used to VBR it is a bit confusing in the beginneing but in the meantime I managed to get VBO up and running.

[Polina]

Koen,

It's good to know you have it all set now )

On a side note, you can also use VBR to create a secondary copy of VBO data. When backing up a VBO server VM with application-aware processing you can then perform a file-level restore of your Office 365 data directly from a backup file.

[archytype]

I think it would also be helpful to also be able to add a CloudConnect Repository and use this as a Secondary location just like you can do with a VBR or VB Agent for Windows job. There is a need to make backups of O365 in to primary and secondary repository.
Some customers want the data to be stored in different locations such as an Azure blob and a cloudconnect repo.
Additionally, the ability to do a copy job to Tape as well so that backups can be 'air gapped' too.

[Mike Resseler]

@archytype
The problem is that the format of a VM backup (VBK/ VIB...) is not the same as VBO which strips data into different pieces and stores it separately. We would need (some sort of) database replication from the tenant to the service provider (in the case of Jet DB repository) or object storage replication. So even if we have that, then it still would be a problem to recreate those items if the original has been lost.

But it is certainly something which is being discussed regularly