Partendo sempre dallo schema con il nodo PBS (Proxmox Backup Server), il Nodo A e Nodo B.
Supponendo che uno dei tre nodi venga meno.
Non succede assolutamente nulla a livello di cluster, perché devi pensare al cluster a due nodi come se fosse un cluster a 3 nodi dal punto di vista del quorum.
Ad esempio se il Proxmox Backup Server cade improvvisamente, non succede assolutamente nulla, l’importante è mantenere almeno due nodi live su 3, esattamente come da specifiche Proxmox.
Inoltre, si può migrare agevolmente una macchina virtuale dal Nodo A al Nodo B e dal Nodo B al Nodo A con la modalità live, ovvero senza spegnere la risorsa.
Ad esempio, una VM in running si può migrare live dal Nodo A al Nodo B, indipendentemente dalle repliche che siano schedulato o no.
Se le repliche sono schedulate, quando si segue la migrazione di una macchina virtuale dal Nodo A al Nodo B, il task di replica automaticamente verrà invertito, quindi sarà dal Nodo B al Nodo A.

Supponiamo di avere 6 macchine virtuali sul Cluster: 3 VM sul Nodo A e 3 VM sul Nodo B, e che ogni macchina virtuale (per semplicità) sia a 100 GB.
Complessivamente sullo storage del Nodo A ci saranno allocati circa 300 GB. Stessa cosa per il nodo B. Supponendo di schedulare le repliche di tutte le VM, dal Nodo A al Nodo B, e viceversa. Si devono considerare su ogni nodo 300GB per le VM e 300 GB per le repliche.
L’occupazione totale di ogni nodo sarà quindi di 600 GB.
Il file system cercherà di ottimizzare lo spazio, per cui non saranno 600 GB ma sarà un po’ meno. Nelle valutazioni, stiamo un pochettino più larghi per sicurezza, quindi consideriamo 600 GB.
Ovviamente non è obbligatorio avere le repliche di tutte le risorse (VM o CT) dal Nodo A al Nodo B.
Ad esempio, se una delle macchine virtuali sul Nodo A è una macchina con servizi poco importanti e per questo non si vuole replicare sul Nodo B, (il Nodo B potrebbe forse essere considerato come puramente un nodo di backup).
In tal caso non si crea il Task di replica della risorsa, e conseguentemente alle repliche si devono togliere 100GB. Quindi complessivamente sul Nodo B (host destinazione) non ci saranno più 600GB ma ci saranno 500GB occupati.
Dipende quindi da come è imposto il Cluster ed in particolare le repliche: se si vuole che tutto sia ridondato dal Nodo A al Nodo B e viceversa.
Un calcolo spanno-metricamente potrebbe essere considerare sempre il doppio dello storage allocato.

Il tempo impiegato per ripristinare un backup da Proxmox Backup Server verso i nodi dipende dall’hardware utilizzato ed in particolare dagli switch, dalle schede di rete e soprattutto dai tipi di dischi implementati per lo storage del PBS.
Tuttavia, un ordine di grandezza molto spannometrico, può andare dal minuto a 20 minuti.

Per ripristinare una macchina da un attacco ransomware, sarà sufficiente ripristinare una delle versioni disponibili sul PBS ottenute grazie alle schedulazioni impostate sul sistema.
Ad esempio, se un CryptoLocker cifra una macchina virtuale io posso tornare al tempo T-1, andando a selezionare una versione delle versioni precedenti.
Mentre si fa il restore della macchina virtuale con Proxmox Backup Server, si può mandarla in running e in tal modo già controllare se quella versione è compromessa o no, senza aspettare tutto il restore della macchina virtuale .