Comprehensive data protection for all workloads
Post Reply
rjiupat
Novice
Posts: 8
Liked: 1 time
Joined: Feb 22, 2021 12:30 pm
Contact:

Advice on modifying an existing setup

Post by rjiupat »

I am new to working with Veeam, and I would appreciate some advice on my plans to update our backup processes. We are a fairly small environment - we currently have 2 VMWare clusters, one on prem and one at a colo. We are running Veeam B&R v10 on a VM on prem with an offsite proxy on the colo cluster. We are backing up 10 VMware VMs nightly and another 5 weekly. All 15 VMs together are around 7TB. The backup repositories (10 & 15TB) are mounted on the B&R server and the proxy, and we are using Windows deduplication and no encryption. This has been working well for us, but we would like to make a few changes. We are going to be retiring the colo cluster and getting new hardware for the on-prem cluster in the near future.

My plan is to add an immutable Wasabi or Backblaze repository and switch our Backup Copy jobs to that rather than the offsite repository; after that the colo cluster will be going away. When I am adding the S3-compatible SOBR, would it be best to add it to one of my existing local repositories or create a new one and if new, what sizing guidelines would you suggest?

I then plan to move us to v11, and add a local Linux hardened repository on a standalone machine so that we will have immutability local as well. I understand that if I switch to a Linux repository I will lose the Windows deduplication, but that XFS offers some benefits in terms of performance and space saving also. Can anyone speak to how much of a difference I am likely to see in needed space for my repository?

In the past we have not encrypted the backups because of the hit to deduplication. I was considering running LUKS on the disks in the Linux repository, but I'm not sure if that's supported. We are not under any mandatory regulations, but I would like to broadly aim for HIPAA compliance; what are you doing about encryption on local and cloud repositories, if anything?

I would also like to start doing SureBackup checks on some of the VMs, is there anything I should consider in structuring the local repository or my new VMWare configuration to make that work better? Running our Veeam proxy on the VMs rather than on a standalone machine has worked ok for us so far, any compelling reason to stop doing that?

I want to do this the right way, so any suggestions would be appreciated. Is there anything else I'm missing here?

Thanks,
Robert
soncscy
Veteran
Posts: 643
Liked: 312 times
Joined: Aug 04, 2019 2:57 pm
Full Name: Harvey
Contact:

Re: Advice on modifying an existing setup

Post by soncscy »

>In the past we have not encrypted the backups because of the hit to deduplication. I was considering running LUKS on the disks in the Linux repository, but I'm not sure if that's supported

Not ready to comment on the rest, but encrypt at the Veeam storage level and use XFS with fast clone. You get tiny Synthetic full backups and no penalty from encryption as Veeam's encryption is transparent to its own operations.

Storage dedup has some great long-term benefits but it comes at a heavy cost -- you only benefit from it at that storage, nowhere else.

This is true for block cloning (XFS reflinks), but as I understand it, Veeam preserves block cloning benefits with Capacity Tier.

So do away with storage dedup as it just locks you into a black box you need to have a licenses to escape from. At worst with XFS, you just have rehydrated backups that you can't delete unless you're root (assuming immutable)
rjiupat
Novice
Posts: 8
Liked: 1 time
Joined: Feb 22, 2021 12:30 pm
Contact:

Re: Advice on modifying an existing setup

Post by rjiupat »

encrypt at the Veeam storage level and use XFS with fast clone. You get tiny Synthetic full backups and no penalty from encryption as Veeam's encryption is transparent to its own operations.
Thanks! This does seem to be the way we should go.
Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 92 guests