-
- Influencer
- Posts: 17
- Liked: 1 time
- Joined: Feb 21, 2018 11:31 am
- Contact:
Use non-domain joined repository for VBO356
As per the official docs:
https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=30
And a forum thread from last year:
veeam-backup-for-microsoft-office-365-f ... 48704.html
It seems VBO365 does not support using workgroup-joined backup servers as proxies (and therefore, repositories). This is a problem for us as I've just recently migrated our main backup repositories off of the domain as per Veeam's guidance for Hardening Veeam Infrastructure:
https://bp.veeam.expert/infrastructure_ ... ry_windows
We'd like to continue to have the backups for VBR and VBO365 all in one place, and I suppose I could concoct some sort of copy job within VBR or even robocopy to achieve this, it would be a bit janky and just not as clean as backing up to the correct location using the native tooling.
Can anyone speak to the reasons behind this limitation and whether it is likely to be lifted in the near future?
Many thanks,
Tom
https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=30
And a forum thread from last year:
veeam-backup-for-microsoft-office-365-f ... 48704.html
It seems VBO365 does not support using workgroup-joined backup servers as proxies (and therefore, repositories). This is a problem for us as I've just recently migrated our main backup repositories off of the domain as per Veeam's guidance for Hardening Veeam Infrastructure:
https://bp.veeam.expert/infrastructure_ ... ry_windows
We'd like to continue to have the backups for VBR and VBO365 all in one place, and I suppose I could concoct some sort of copy job within VBR or even robocopy to achieve this, it would be a bit janky and just not as clean as backing up to the correct location using the native tooling.
Can anyone speak to the reasons behind this limitation and whether it is likely to be lifted in the near future?
Many thanks,
Tom
-
- Product Manager
- Posts: 8044
- Liked: 1263 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Use non-domain joined repository for VBO356
Hi Tom,
Reasons: It is on the roadmap but simply isn't implemented yet. The reason is the communication between VBO server and proxies. In a domain, that is arranged, in a workgroup we need to work with certificates and it is a bit more difficult to implement... I can't say at this moment when we will implement it to be honest
Reasons: It is on the roadmap but simply isn't implemented yet. The reason is the communication between VBO server and proxies. In a domain, that is arranged, in a workgroup we need to work with certificates and it is a bit more difficult to implement... I can't say at this moment when we will implement it to be honest
-
- Influencer
- Posts: 17
- Liked: 1 time
- Joined: Feb 21, 2018 11:31 am
- Contact:
Re: Use non-domain joined repository for VBO356
Thanks Mike, I appreciate the response.
I'll set up a Veeam file-copy job in the meantime.
I'll set up a Veeam file-copy job in the meantime.
-
- Service Provider
- Posts: 29
- Liked: 25 times
- Joined: Aug 07, 2017 11:51 am
- Full Name: William
- Location: Zurich, Switzerland
- Contact:
Re: Use non-domain joined repository for VBO356
Hi Mike
The last Post was from July 2019. Now we have end of April 2020 and it is still "Domain only" at the moment. At least this is written in the documentation and in my test lab it doesn't work with the workgroup.
This is very disappointing as tohhmas said, the hardening of the infrastructure points exactly to the setup without the domain.
There are other reasons to not use a domain for this (not only for the hardening part)
- SMBs that just want to have a VM for the backup. A lot of them do not have an AD. Some even just rent a VM in the cloud and setup the service there. This works with a standalone VM, but not if you need more then one.
- Standalone VMs in a different cloud where you don't want any connection to your AD
- You do everything with Linux. Just for Veeam you need Windows so you setup some Windows VMs for your project. Now you also need a Domain just for a standalone Office 365 backup. Here it is a potential point to stop the project.
If it was on the roadmap in July 2019: what is the status now? I have a customer that is testing O365 backup from Veeam with exactly the situation with "Linux only", where this is likely a reason against the solution.
Best regards
William
The last Post was from July 2019. Now we have end of April 2020 and it is still "Domain only" at the moment. At least this is written in the documentation and in my test lab it doesn't work with the workgroup.
This is very disappointing as tohhmas said, the hardening of the infrastructure points exactly to the setup without the domain.
There are other reasons to not use a domain for this (not only for the hardening part)
- SMBs that just want to have a VM for the backup. A lot of them do not have an AD. Some even just rent a VM in the cloud and setup the service there. This works with a standalone VM, but not if you need more then one.
- Standalone VMs in a different cloud where you don't want any connection to your AD
- You do everything with Linux. Just for Veeam you need Windows so you setup some Windows VMs for your project. Now you also need a Domain just for a standalone Office 365 backup. Here it is a potential point to stop the project.
If it was on the roadmap in July 2019: what is the status now? I have a customer that is testing O365 backup from Veeam with exactly the situation with "Linux only", where this is likely a reason against the solution.
Best regards
William
-
- Product Manager
- Posts: 5619
- Liked: 1177 times
- Joined: Jul 15, 2013 11:09 am
- Full Name: Niels Engelen
- Contact:
Re: Use non-domain joined repository for VBO356
This is still on the roadmap but no ETA for now.
Personal blog: https://foonet.be
GitHub: https://github.com/nielsengelen
GitHub: https://github.com/nielsengelen
-
- Enthusiast
- Posts: 76
- Liked: 45 times
- Joined: Dec 10, 2019 3:59 pm
- Full Name: Ryan Walker
- Contact:
Re: Use non-domain joined repository for VBO356
My recommendation is to use Object Storage for the repository. Keeps the Proxy on the Domain for ease of implementation, but allows hardening of the data itself by locking it out.
Obviously the Scale on this is difficult to judge, but if - in example - your VBR runs to a specific Storage (SAN,Hypervisor Storage, etc) you can at least put the VBO backups on the same storage utilizing a Virtual Object Storage, move to a capacity Object Storage for VBR and use it for VBO as well, or even run a windows based Object Storage on the same Windows VM/Server that the VBR Repository is on.
At least until non-domain joined JetDB Repos are supported.
Obviously the Scale on this is difficult to judge, but if - in example - your VBR runs to a specific Storage (SAN,Hypervisor Storage, etc) you can at least put the VBO backups on the same storage utilizing a Virtual Object Storage, move to a capacity Object Storage for VBR and use it for VBO as well, or even run a windows based Object Storage on the same Windows VM/Server that the VBR Repository is on.
At least until non-domain joined JetDB Repos are supported.
Who is online
Users browsing this forum: No registered users and 18 guests