Hardened Repository - two mounts for different tiers?
Hi there, is it possible to have two mounts on the same hardware for a hardened repository? For example, mount-1 on an SSD-Raid for the latest 14 days of backups and mount-2 with an HDD-Raid for 3 months or something like this?
Maybe both of them are presented by a Scale-out-backup-repo? Is this a good and solid option?
Our customer want to have very fast restore or instant restore performace within the latest backups (SSDs) but also want an option to have several months immutable (HDDs) - but as mentioned on the same hardware. He has already some other repositories, also on different site, so this should only be an extension for immutablity.
Thanks and best regards Markus
Page 1 / 1
Yes this will work fine for your use case. Just add the same repo twice to Veeam with each mount point. Then configure things as required for your repos and jobs.
Thanks Chris. Glad to hear.
Just take care to not use the same user for multiple connections.
Veeam uses a certificate between VBR and repo and you can face problems with that. In the same hand is not a security best practice.
Just take care to not use the same user for multiple connections.
Veeam uses a certificate between VBR and repo and you can face problems with that. In the same hand is not a security best practice.
Hi Wolff, so you would recommend to establish a connection between VBR to Hardened-Repo-Server-share1 with repo-user1, and to the same Hardened-Repo-Server-share2 with repo-user2? Both of them should be connected by “Single Use Credentials”.
Yeah! Try this way to not hit any security problem.
Other thing to take care is about VBR version. You will need to have the same version on two sides.
Yeah! Try this way to not hit any security problem.
Other thing to take care is about VBR version. You will need to have the same version on two sides.
we have only one VBR in this scenario - so the only versions we have to take care about is on the VBR and the one Repository Server with its two shares.
@Dynamic Also know that if you share this across two different VBR servers both VBR servers must be updated at the same time or one repo won’t work. And truthfully this is really against against best prqctices and should be carefully considered before this is implemented.
And of course not mention that know ypu are doubling the attck vector to the repo and you are putting all of backups in a single repo.
@Dynamic Also know that if you share this across two different VBR servers both VBR servers must be updated at the same time or one repo won’t work. And truthfully this is really against against best prqctices and should be carefully considered before this is implemented.
And of course not mention that know ypu are doubling the attck vector to the repo and you are putting all of backups in a single repo.
Thaks @vmJoe - but we have only one VBR in this scenario :) Also this is not the only repository, the customer has multiple repositories (on different sites) and a Tape-Library.
The whole question was regarding 1 Hardened-Repository but within this system, two types of different RAID sets (SSD/HDD - performance and some slower GFS points).
@Dynamic Also know that if you share this across two different VBR servers both VBR servers must be updated at the same time or one repo won’t work. And truthfully this is really against against best prqctices and should be carefully considered before this is implemented.
And of course not mention that know ypu are doubling the attck vector to the repo and you are putting all of backups in a single repo.
Some really great advice here from Joe. You indicated one VBR server so make sure the Linux one is locked down.
@Dynamic you mentionned SOBR but keep in mind, capacity tier is not supported for hardened repo. You will need to use object storage if you want to achieve it.
You will need two SOBR if you have many repos and you will need to use backup copy jobs.
Unfortunately i think Veeam don’t have mecanism to detect to write on the closest host (the same). I am thinking about this subject for a while and don’t know how to do it. Specially with the release of new Hybrid HPe Apollo (ssd/hdd).
Maybe @HannesK has some suggestions about this subject .
not really. for block cloning, it has to be one file system. so the abstraction of different tiers has to happen at the storage level. I never tried Linux caching / tiering solutions, so I cannot give any advice here.
@Dynamic you mentionned SOBR but keep in mind, capacity tier is not supported for hardened repo. You will need to use object storage if you want to achieve it.
You will need two SOBR if you have many repos and you will need to use backup copy jobs.
Unfortunately i think Veeam don’t have mecanism to detect to write on the closest host (the same). I am thinking about this subject for a while and don’t know how to do it. Specially with the release of new Hybrid HPe Apollo (ssd/hdd).
Maybe @HannesK has some suggestions about this subject .
Thanks @BertrandFR! ...so in total, i think we have to go with two BackupCopy Jobs to achieve this goal. Customer don’t have an object storage, has currently an primary target for the whole jobs and the new target site with immutability (on two tiers) could be a good solution. So in this scenario, the SOBR make no sense and would only increase complexity.
To summarize: Backup Jobs > primary target (in site1) Backup Copy Job 1 > hardened repository (SSD - but same system as HDD) - 14 days of retention Backup Copy Job 2 > hardened repository (HDD - see below) - some days of retention, multiple weeks and months ...and also some Jobs for GFS Tape
example in screenshot
best regards Markus
All in one VBR on the first DC? Or it is just the wrong drawing pick?
I hope the current ReFS repo is full fash :)
I don’t understand why you need flash on hardened repo used for backup copy? Speed in case of DR?
I don’t see any informations about the source storage? It’s ok to have speed on backup repo but are you sure the source storage is able to write as fast as the data sent to it by proxies and the repo?
the VBR is a VM in this scenario - could be also hosted on DC2 (HA/vMotion/DRS). The SAN is also mirrored. Didn’t mentioned that because i thought it has no focus on my whole question. But thanks for further questions on this design, appreciate that :) The main reason for the SSD part in the Hardened-Repository is for performance in case of a needed Instant Recovery.
.