We have two locations. Location A is our production facility with several core servers, while Location B has a separate network and its own server stack for disaster recovery. We want backups from Location A stored in immutable cloud storage, currently Wasabi, while also being usable at Location B so we can boot the workloads there quickly if the primary site fails.
Our original setup used Veeam to back up to a Synology NAS, Hyper Backup to copy that backup data to Wasabi, and then a second Synology at Location B to download and open the data with Veeam. It worked, but required manual intervention and we later found that Hyper Backup does not provide the immutability we need.
Veeam can write directly to Wasabi with immutability enabled, but we have struggled to get the Veeam installation at Location B to use the same bucket for restores. Downloading the files to the Synology at Location B has not worked either.
What is the recommended design for immutable backups that can also support rapid recovery at a second physical location? We are open to using replication, another backup platform, or a different storage arrangement, but we would prefer to keep the secondary site available as a warm recovery location rather than relying entirely on spinning everything up in a provider's cloud.
5 Answers
If the workloads are virtual machines, check whether the virtualization platform already supports site replication. Hyper-V Replica, VMware replication features, or similar platform-level tools can provide usable copies at Location B without treating Wasabi as an intermediary. Keep the immutable cloud backups separately for point-in-time recovery.
A common design is to separate backup and disaster recovery. Use Veeam or your hypervisor to replicate the production VMs directly from Location A to Location B on the schedule and bandwidth you can support. That gives you standby machines at the recovery site, while the immutable Wasabi repository remains your protection against deletion, corruption, or ransomware. Replication alone should not replace backups, since a bad change can be replicated too.
Some organizations solve this with dedicated backup appliances at both locations. Each appliance keeps immutable local backups and replicates backup data to the other site. That avoids making one cloud bucket the only recovery path, but it involves additional hardware and licensing. It may be worth comparing that cost and simplicity against maintaining the current Synology-based workflow.
The current chain of NAS to backup software to cloud to another NAS adds a lot of operational complexity and creates more places for recovery to fail. A managed backup and disaster-recovery service could back up directly from production to immutable cloud storage and provide cloud failover, but that is a different model from maintaining your own warm site and can be expensive. If the physical recovery site is a firm requirement, direct VM replication plus independent immutable backups is likely a better fit.
That distinction is important for us. We need a warm secondary site with our own servers, not just the option to start machines in a provider’s cloud, so we will keep evaluating direct replication alongside immutable backups.
The Veeam server at Location B should generally be able to add the Wasabi bucket as a repository and use it for restore operations, even if it is configured as read-only from that site. You may not need to download the backup files to the Synology first. Check that the object storage credentials, bucket settings, region or endpoint, repository configuration, and Veeam version match, and make sure the account has permission to list and read the objects while immutability prevents deletion or modification.
The safest approach is usually to replicate the production workloads between sites and also maintain an independent backup copy. That covers both rapid failover and longer-term recovery scenarios.