We use Veeam in a Hyper-V environment, writing backups to local storage and sending copy jobs to the cloud. We also have replication to a disaster recovery site. I'd like to make better use of our older Veeam host hardware by adding another layer of backup protection, following the 3-2-1 approach. The concern is that if the Veeam server or repository has a hardware or disk failure, new backup and replication jobs stop. We recently lost about a week of protection because of drive corruption on the Veeam server. What would you recommend: a second backup product, another repository, or a different architecture? Our servers are business-critical and change frequently, so losing a week of data would be unacceptable. We currently test backups monthly.
5 Answers
For frequent file-level mistakes, shadow copies on file servers can provide a fast additional recovery option for recently deleted or moved files. They are not a replacement for backups, since they usually live on the same system, but they can handle common restores without requiring a full backup recovery.
A separate backup application may add more complexity than protection, especially if both products are backing up the same Hyper-V hosts. I’d first make Veeam itself resilient: keep configuration backups, have a standby VM or spare server ready, and replicate the repository to separate hardware or another site. You can reinstall Veeam on almost any suitable machine and restore its configuration if the primary server fails.
The cleaner form of redundancy is usually another independent repository rather than another backup product. Consider an offline or immutable repository on separate hardware, plus offsite replication. Make sure the repository cannot be damaged by ransomware or by a failure of the primary backup server. Also practice rebuilding the Veeam server and restoring its configuration, not just restoring protected workloads.
If you specifically want a second vendor, products such as Acronis, Datto, or a managed disaster-recovery service can provide an independent path. Use separate storage and schedules, and verify that the product supports Hyper-V, immutable retention, and test boot or recovery. I’d choose this only if you have a clearly defined gap that Veeam cannot cover, rather than simply duplicating every job.
Before adding software, identify whether the real issue is repository availability, the backup server, or the backup chain. A second product can mean two management systems, separate support contracts, and possible contention for snapshots or changed-block tracking. Weekly restore verification and regular recovery tests may provide more value than installing a competing tool.
I already have local, cloud, and disaster-recovery copies, but when the initial backup jobs fail, the copy and replication jobs stop too. I’m mainly trying to avoid that gap for systems with constant data changes.