WE are deciding on new storage and it was brought up that we should just buy a SAN. I thought that was a bit overkill but i could see the argument.
Is anyone using a SAN to do their backups exclusively? I know pure has protection groups and safe mode array snapshots that help protect against malware/ransomware.
This looks promising but also seems like it might have some issues.
Id be curious to know if anyone is running windows refs here and iscsi for a their repo and how they like it?
How do you avoid overlap with your snapshot schedule and your backup windows?
Are you still running a SOBR in this configuration? This seems tough to do as you would need to restore your safemode snapshots from all disks i would think before rescanning veeam. Seem like it would be better to not have a SOBR or perhaps have one but only put one LUN in it so you can migrate to different storage in the future easily by just putting.
Or if you are not running windows, are you still running a Linux Hardened Repo on it in the same way to get that file level immutability? I suspect the same concern about the SOBR would exist.
Also, in either of these situations, if you had to restore a storage snapshot, remount and rescan with VBR, will your VBR db grow like mad or be confused as it sees the drive show up potentially from days old data?
I guess im trying to sort out the pros and cons here of using a SAN vs just a JBOD or storage server. I know veeam works closely with Pure storage. I could probably just reach out to them and ask.
-
- Service Provider
- Posts: 200
- Liked: 22 times
- Joined: Feb 01, 2016 10:09 pm
- Contact:
-
- Enthusiast
- Posts: 83
- Liked: 11 times
- Joined: May 09, 2012 12:52 pm
- Full Name: Stefan Holzwarth
- Contact:
Re: SAN as repo?
In my opinion and experience, there is nothing wrong with a SAN-connected central storage for backup.
(it should be of course dedicated and not shared with production storage)
We have been using this approach for years for about 900 vms. When we last refreshed our backup infrastructure, we again opted for central storage that was tailored precisely to our backup needs. We were also able to use pure flash-based storage for economic reasons and we switched from FC to iSCSI as the connection protocol. There is no need to go for premium storage...
Important advantages that have resulted:
- fast sure backups to check the quality of the backups (automated)
- fast restores
- effective storage resources with large volumes in sobr's using thin provisioning and hardware compression in storage (1:1,2 - better then nothing)
- low energy footprint
- secured backups on primary backup storage (also on long-term versioned secondary storage)
- easy replacement of the "frontend" proxy servers that only have OS storage (with the storage refresh, we also switched to Linux with XFS as file system)
- some backup storage reserved for emergency situations where primary storage isn't available since e.g. legal rules after ransomware attack for restart with core infrastructure onprem
One more advice: do not use the same vendor for backupstorage and production storage for security reasons - (also not the same admins...)
(it should be of course dedicated and not shared with production storage)
We have been using this approach for years for about 900 vms. When we last refreshed our backup infrastructure, we again opted for central storage that was tailored precisely to our backup needs. We were also able to use pure flash-based storage for economic reasons and we switched from FC to iSCSI as the connection protocol. There is no need to go for premium storage...
Important advantages that have resulted:
- fast sure backups to check the quality of the backups (automated)
- fast restores
- effective storage resources with large volumes in sobr's using thin provisioning and hardware compression in storage (1:1,2 - better then nothing)
- low energy footprint
- secured backups on primary backup storage (also on long-term versioned secondary storage)
- easy replacement of the "frontend" proxy servers that only have OS storage (with the storage refresh, we also switched to Linux with XFS as file system)
- some backup storage reserved for emergency situations where primary storage isn't available since e.g. legal rules after ransomware attack for restart with core infrastructure onprem
One more advice: do not use the same vendor for backupstorage and production storage for security reasons - (also not the same admins...)
-
- Service Provider
- Posts: 200
- Liked: 22 times
- Joined: Feb 01, 2016 10:09 pm
- Contact:
Re: SAN as repo?
Interesting....so the dedupe and compression takes a pretty good hit going this route from what you have seen? I guess this makes sense.
Are you doing a linux hardened repo on the array or did you just allow the array to use safemode snap shots for the data protection? You mention switching to linux and xfs so i assume you are running the LHR.
I'm still curious on if restoring a snapshot on the array and rescanning with veeam confuses the database or causes it to grow oddly. Im still on the fence about recommending this. It seems to add another layer of complexity but I can see benefits and drawbacks. Id like to just find a nice supported storage server that we could hook up to a OS vm or run the OS internally to itself as the repo. Thats probably what most places do. That would help keep things cheaper and likely less complicated.
Are you doing a linux hardened repo on the array or did you just allow the array to use safemode snap shots for the data protection? You mention switching to linux and xfs so i assume you are running the LHR.
I'm still curious on if restoring a snapshot on the array and rescanning with veeam confuses the database or causes it to grow oddly. Im still on the fence about recommending this. It seems to add another layer of complexity but I can see benefits and drawbacks. Id like to just find a nice supported storage server that we could hook up to a OS vm or run the OS internally to itself as the repo. Thats probably what most places do. That would help keep things cheaper and likely less complicated.
-
- Service Provider
- Posts: 45
- Liked: 15 times
- Joined: Jan 26, 2018 2:27 pm
- Contact:
Re: SAN as repo?
Well you can instruct Veeam to decompress data before writing it to the storage so that the storage does dedupe/compression. If storage supports dedupe/compression that is. We are looking at IBM Flashsystem with FCM modules that have hardware compression and data reduction pools to deduplicate. Another storage we are looking at is Dell PowerStore that also has inline dedupe/compression.
-
- Enthusiast
- Posts: 83
- Liked: 11 times
- Joined: May 09, 2012 12:52 pm
- Full Name: Stefan Holzwarth
- Contact:
Re: SAN as repo?
Indeed we are using IBM Flashsystem with FCM modules (35 TB) with HW compression. We get 1:1,2 ratio without turning veeam compression off.
We use recommended settings for veeam compression, blocksize,.... Also we use safe snapshots (invisble to veeam till needed) for 7 days backward.
The meaning of LHR is unknow to me. We use xfs with reflink=1 and discard as mount option. Works very well.
Also I woulnd restore a veeam repo volume from snapshot if not total destroyed. Instead I would mount that snapshot(s) and offer them as additional repos to import.
We use recommended settings for veeam compression, blocksize,.... Also we use safe snapshots (invisble to veeam till needed) for 7 days backward.
The meaning of LHR is unknow to me. We use xfs with reflink=1 and discard as mount option. Works very well.
Also I woulnd restore a veeam repo volume from snapshot if not total destroyed. Instead I would mount that snapshot(s) and offer them as additional repos to import.
Who is online
Users browsing this forum: No registered users and 14 guests