Offsite replication

[Bun-Bun]

I am just getting started with Veeam to replace Unitrends for a client. I have it running on a whitebox tower with Server 2022 using a local ReFS volume with dedup enabled as the backup repository. I'm getting excellent data reduction rates across the board and so far I am happy with the platform.

However, the issues the client had with Unitrends I'm struggling to find a solution for with Veeam. Targeting at least 3 years of retention of weekly backups (They had 6 years of dailies in the Unitrends appliance), how to ensure that the local repository can be recovered in a disaster event? Example, Unitrends local appliance dies (or is destroyed), there was no way to get all that retention back into a replacement local appliance due to not being able to hydrate and then re-dehydrate the data again. The only way to access the data was through the offsite appliance over WAN which was incredibly slow and buggy.

Client is cloud adverse; thus I am trying to build out a solution where I host their offsite backups in my facility. What I'm currently looking at is a way to replicate the local backup repository with and appliance at my location.
What I have been looking at thus far is building out another Windows 2022 ReFS server and then using storage replica. This would be quite expensive as Server 2022 Datacenter is required. I've also been looking at making the backup repositories on a linux host using ZFS for drive raid/resiliency management and then running XFS ontop of a zvol to still be able to use fast cloning. Then ZFS dedup and replication tools could be used to make an offsite replication of the backup repository.

However, a 1:1 replication doesn't satisfy best practice that offsite should be airgapped and immutable, since any changes to the primary repo would be replicated to the offsite repo.

How do I accomplish my goals of hosting offsite backups for the client that ensures I can return dehydrated retention data back onsite in case of DR event? Based on my reading, backup copies are not capable of maintaining reflinked fast clone copies and all of the external repo options are to link to cloud providers. Is there a way to setup my appliance as a "cloud provider" and then in DR event how to I replicate the entire retention back to the local repo? Or am I missing something else entirely?

[david.domask]

Hi Bun-Bun,

Welcome to the Veeam Forums and to Veeam, glad to hear that the first impressions and the backup sizes are to your liking.

Based on my reading, backup copies are not capable of maintaining reflinked fast clone copies and all of the external repo options are to link to cloud providers.

This is not quite correct, but I believe I understand the confusion. The Backup Copy backups will be able to do their own space savings with Fast Clone if the Backup Copy is targeting a fast-clone capable repository, so you will see very similar space savings. Veeam's Backup Copy is kind of a "backup of a backup", and it doesn't just do a simple file copy, it's using the same process the Backup process uses to write data to the target repository, meaning it can start its own fast clone'd chain.

The idea would be to configure:
- Primary backup jobs going to a primary repository
- Backup Copies from those source jobs to your DR site
- In a DR event where all of the production is lost, you still have Backup Copies on the remote site usable for restores

In a complete DR event where all of the production site is lost, you would simply restore the Veeam Configuration and the primary jobs would start new backup chains.

[Bun-Bun]

Thank you for the response!

This is not quite correct, but I believe I understand the confusion. The Backup Copy backups will be able to do their own space savings with Fast Clone if the Backup Copy is targeting a fast-clone capable repository, so you will see very similar space savings.

Okay that is good to know. I will have to test this to make sure I understand how it works. Is it possible to backup copy entire chains after the fact and realize fast-clone savings?

In a DR event where all of the production is lost, you still have Backup Copies on the remote site usable for restores

In a complete DR event where all of the production site is lost, you would simply restore the Veeam Configuration and the primary jobs would start new backup chains.

This is my sticking point that I can't seem to find a solution to. In a complete DR event, yes, the remote site backups are still available, but they are remote and slow. I don't want to start new chains, I want to be able to restore the primary repository entirely in a DR event so that the entire retention chain is available locally again and still following best practice of being in 3 places. Is that possible and how do I accomplish this goal?

[david.domask]

Is it possible to backup copy entire chains after the fact and realize fast-clone savings?

There is a registry value which can be used, see Gostev's post here: post392690.html#p392690

(note: the GFS flags from the original job will not be preserved with this, so I'm not confident this will match what you're hoping for. I think for now the best bet is to simply start the Backup Copies and let them build up over time)

As for your strategy, the idea is clear, and while Veeam does have this ability with our Capacity Tier feature, it requires Scale-out Backup Repository with Capacity/Archive Tier which as I get it is not feasible for your setup.

I would try to just keep it simple and focus on:
1. Use our Hardened Repository whenever possible to allow for immutable backups on local storage: https://helpcenter.veeam.com/docs/backu ... ry&ver=120
2. Create backup copies to your DR site, and likely a local backup copy as well for faster restores in the event of DR; consider rotated drives or Tape out if it's possible for your environment


I know some users are utilizing their storages' native storage replication, and while it may work, please note that such scenarios aren't tested. I understand what you're aiming for with the storage replication, but for now Veeam only supports Catalyst Copy for Storeonce devices.

[tyler.jurgens]

This is my sticking point that I can't seem to find a solution to. In a complete DR event, yes, the remote site backups are still available, but they are remote and slow. I don't want to start new chains, I want to be able to restore the primary repository entirely in a DR event so that the entire retention chain is available locally again and still following best practice of being in 3 places. Is that possible and how do I accomplish this goal?

Offsite backups are not meant to be used unless you lose your entire site, so there should be a lower expectation of them being as fast as on site repositories. Of course, you could always beef up your bandwidth and get lower latency links to your off-site location, but that's not always possible.

The better approach here in a disaster is to look into replication. Restoring from backup, even with instant VM recovery, is always going to be slower than spinning up a replica VM. IMO, you should be doing both.