Hello all, I've logged with support (00682599) but would appreciate any real world advice...
I'm going through the testing/design/learning stage with Veeam in our environment on old "tin" before we purchase the hardware to underpin a full deployment. We intend to follow best practice and have a very fast low retention space in our production data center with slower archive repository at our DR site using copy jobs.
My question today is about how to isolate the second repository in terms of Security at the application (Veeam) layer from the production site. The Veeam infrastructure at our main site will be joined to the domain (management, repository,proxies, etc). Obviously the account which runs the Veeam service needs "delete" permissions on the storage so it can manage retention etc. The domain\veeam.backup service account created would have the power to delete all data on both repositories if compromised if I used the production Veeam server to push the data to the DR site.
The only way I can think to do this is use a separate Veeam server at the DR site (not domain joined) that has READ access to the production repository and configure the Backup Copy jobs on there to pull the data rather than have those jobs on the production Veeam server.
Does anyone have any advice, best practice or comments over trying to achieve secure offsite backups without resorting to tape?
I can see how it would be so much easier to give it domain admin to gain best use of all the functionality but what do other people do for permissions on their Veeam service account in the real world?
Cheers
Zac
-
- Influencer
- Posts: 24
- Liked: 1 time
- Joined: Nov 14, 2014 11:03 am
- Full Name: Zac
- Contact:
-
- Influencer
- Posts: 24
- Liked: 1 time
- Joined: Nov 14, 2014 11:03 am
- Full Name: Zac
- Contact:
Re: Deployment design for secure/isolated offsite repository
Well support have replied that this is basically not possible because Veeam is designed a singular backup solution.
The idea of using a second backup server is not possible because those jobs would appear "imported" to the second server and imported jobs are not available for backup copy jobs.
Has anyone else had thoughts on mitigating this without resorting to tape?
The idea of using a second backup server is not possible because those jobs would appear "imported" to the second server and imported jobs are not available for backup copy jobs.
Has anyone else had thoughts on mitigating this without resorting to tape?
-
- Expert
- Posts: 131
- Liked: 22 times
- Joined: Nov 21, 2014 10:50 pm
- Full Name: Nick Fisk
- Contact:
Re: Deployment design for secure/isolated offsite repository
I do something similar but our offsite repository is a Linux machine and we use LVM to take snapshots of the disk for both extra retentions and data security. I'm sure something similar could be done with Shadow Copies on Windows.
-
- VP, Product Management
- Posts: 27377
- Liked: 2802 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Deployment design for secure/isolated offsite repository
Hi Zac,
Can you please tell me where this requirement comes from? If you want to isolate it on the security level, then you can use file copy jobs or robocopy scipts to transfer the entire folder of the main server.
Thanks!
Can you please tell me where this requirement comes from? If you want to isolate it on the security level, then you can use file copy jobs or robocopy scipts to transfer the entire folder of the main server.
Thanks!
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
- Contact:
Re: Deployment design for secure/isolated offsite repository
In general, whatever technology is used, the main concept is to create an additional copy of the offsite backup files using a second system that is NOT accessible by the Veeam console. In this way, any compromise of the console itself cannot allow the intruder/malware to get also access to the second copy.
Solutions like those listed here are all effective, as long as they do not use the tools available in the Veeam console, because for these Veeam itself need to access the second system again...
Solutions like those listed here are all effective, as long as they do not use the tools available in the Veeam console, because for these Veeam itself need to access the second system again...
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Who is online
Users browsing this forum: Baidu [Spider], Semrush [Bot] and 55 guests