From: Gautier HUSSON <g.husson@liberasys.com>
To: pve-user@lists.proxmox.com
Subject: Re: Question about Disaster Recovery Architecture Between Two Datacenters
Date: Mon, 6 Jul 2026 17:37:09 +0200 [thread overview]
Message-ID: <4a9e2158-1865-4d82-8904-9d7ab76bf108@liberasys.com> (raw)
In-Reply-To: <DU0PR03MB92537C52578027E0513C139DCDE32@DU0PR03MB9253.eurprd03.prod.outlook.com>
Hello,
My answers hereunder. I respond quick because it is a non paid service.
I invite you to contact an official partner to build the infrastructure
that suits your need (as I am).
BR
Gautier Husson.
Le 18/06/2026 à 11:38, Iván Méndez Cairós a écrit :
> Hello,
>
> We would like to know whether the following Disaster Recovery scenario can be implemented with Proxmox VE and what would be the recommended architecture.
>
> Our environment consists of:
>
>
> * A primary datacenter with more than three Proxmox VE hosts connected to a SAN storage array.
> * A secondary datacenter with equivalent infrastructure (Proxmox VE hosts and a storage array).
> * Storage replication from the primary array to the secondary array.
> * Both datacenters are connected through a LAN network with very low latency and sufficient bandwidth, so network performance is not a concern.
>
> Our objective is to ensure business continuity in the event of a complete failure of the primary datacenter.
>
> In such a scenario, we would like the virtual machines to be started in the secondary datacenter with as much automation as possible and with minimal manual intervention.
>
> We would appreciate your guidance regarding the following points:
>
>
> 1. Does Proxmox VE officially support this type of architecture?
yes
> 2. Would you recommend a stretched cluster across both datacenters, or two independent Proxmox clusters?
stretched (QDevice on a 3rd site + primary and secondary datacenter have
their own path to connect the QDevice) ==> HA will be automatic
> 3. What are the requirements regarding quorum, fencing, HA, networking, and storage?
- same number of nodes both sides
- a QDevice in a 3rd location (can be > 5ms away)
- HA enabled on VMs + Node affinity for the 1st site
- ping < 5ms between ALL Proxmox nodes (QDevice does not matters)
- storage : SYNCHRONOUS replication
> 4. Is it possible for Proxmox HA to automatically start the virtual machines in the secondary datacenter if the primary datacenter becomes completely unavailable?
yes
> 5. What are the main limitations or considerations for this design?
None if all is respected. If a node is out of order for long time, you
should rebalance vote numbers between DC 1 and 2.
> 6. What would be the recommended Proxmox architecture and best practices to achieve an automated Disaster Recovery solution in this scenario?
>
> Any recommendations, documentation, or real-world deployment examples would be greatly appreciated.
Official Proxmox Training of course :-)
prev parent reply other threads:[~2026-07-06 16:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 9:38 Question about Disaster Recovery Architecture Between Two Datacenters Iván Méndez Cairós
2026-06-18 10:09 ` Andrei Boros
2026-07-06 15:37 ` Gautier HUSSON [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a9e2158-1865-4d82-8904-9d7ab76bf108@liberasys.com \
--to=g.husson@liberasys.com \
--cc=pve-user@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.