Hello.
We had an excellent scheme:
1. A couple of Hyper-V servers with production VMs
2. Dedicated Hyper-V server with Veeam VM to backup them
3. Remote Hyper-V with Ubuntu VM in read-only mode to replicate backup there
So far, so good.
However, we have to sacrifice machine "2" due to funds shortage (this is a physical machine that does nothing 90% of time)
My inner perfectionist is in a panic!
We can move Veeam VM either to:
1. ..one of our production servers (machine 1)
2. ..remote Hyper-V (machine 3)
So, we either store backups on the same physical Hyper-V we make backups for (separate RAID-1, but still hacked/broken machine will destroy backups leaving only remote copy) or store backups on remote machine only (hence, backups are only stored in one physical locations).
Which approach is less worse, that do you think?
If you believe that both of them are unacceptable, please also say so)
Thank you in advance.
-
- Lurker
- Posts: 1
- Liked: never
- Joined: Mar 31, 2024 3:29 pm
- Full Name: Ilya. K.
- Contact:
-
- Veeam Software
- Posts: 2359
- Liked: 558 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Choosing backup scheme with 2 servers
Hi @IlyaK,
Just for my clarification, do I get it right that with the current setup your repositories are all virtualized on the 2nd machine that is being removed? That is, all the repository storage is actually the same as the Hyper V VM storage?
All things being considered, 2 is probably preferred but I'm not quite getting the topology of the configuration -- if the remote server (3) has to cross WAN or other non-ideal network conditions, obviously that will impact your backup times, so that might not be great.
I'm glad you're considering 3-2-1 as you're going through your (forced
) redesign, and I think if we follow the letter and spirit of 3-2-1 AND your repositories are directly attached to the VBR VM, then yes machine 3 is the correct answer, and you can further do backup copies to machine 1 (though ideally a storage that is not on your production hypervisor is better since you don't want to lose your backups also when you lose production)
Given you seem to have a carefully considered setup, am I correct to assume you have secondary copies on archival locations like Tape or Object Storage (AWS S3, Azure Blob, etc)? While naturally this means costs are involved, I think such archival (secondary) targets would help you rest easier knowing you have fast access to such backups regardless of what happens to the production environment.
Just for my clarification, do I get it right that with the current setup your repositories are all virtualized on the 2nd machine that is being removed? That is, all the repository storage is actually the same as the Hyper V VM storage?
All things being considered, 2 is probably preferred but I'm not quite getting the topology of the configuration -- if the remote server (3) has to cross WAN or other non-ideal network conditions, obviously that will impact your backup times, so that might not be great.
I'm glad you're considering 3-2-1 as you're going through your (forced

Given you seem to have a carefully considered setup, am I correct to assume you have secondary copies on archival locations like Tape or Object Storage (AWS S3, Azure Blob, etc)? While naturally this means costs are involved, I think such archival (secondary) targets would help you rest easier knowing you have fast access to such backups regardless of what happens to the production environment.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Bing [Bot], Google [Bot], Regnor and 95 guests