Весь ваш комментарий наводит на мысль, что вы не админили физические сервера...

Если физические сервер сломался - это равнозначно тому что сломался сервер виртуализации. Вам нужно устранить поломку и восстановиться из бекапа. Молодые люди, почему-то сейчас не понимают, что бекапы снапшотами - это не фича инфраструктуры виртуализации. Это просто снапшоты ФС. NTFS прекрасно поддеживает снапшоты и всю систему можно восстановить из резервной копии. Однако, есть нюанс. Для полностью автоматического восстановления вам нужно:
1. Иметь выделенную сеть/VLAN для управления
2. Настроить DHCP и PXE
3. Ваша инфраструктура бэкапа должна дать вам загрузочный образ, который загрузит его родную LiveOS, подключится к репозиторию бэкапов и восстановит снапшот.

Если у вас был один сервер, а нужно сделать 2, то вы просто берете и ставите второй сервер. Балансировщики нагрузки ставятся всегда отдельно от бэкенд-серверов. Там нет разницы на виртуалки они балансируют или на физические сервера. Сами балансировщики тоже могут быть как виртуальные так и физические аплаянсы. В зависимости от типа сервиса вам может потребоваться:
1. Ничего. Для стейтлесс-сервисов ничего не нужно
2. Сессионная привязка к бэкенду. Для сервисов у которых есть понятия постоянной сессии, когда одно клиентское соединение шлёт зависимые друг от друга последовательные запросы.

Если вам нужно мигрировать сервис с одного сервера на другой, то это часть CI/CD пайплайна. Вы должны были написать скрипты обновления и деплоя своего сервиса.

Если ваш сервис настолько стейтфул что работает напрямую с хранилищем, например файлами на дисках, вам нужна кластеризация. Кластерное хранилище может быть либо средствами SAN/FC, либо програмно определяемое на этом же кластере, составленное из локальных дисков.

Если вам нужно унести сервер в другой ДЦ, вам видней как это лучше организовать. Я только хочу сказать, что даже в случае требований наличия кластерного стораджа, вы можете сделать растянутый кластер, применяющий логическую репликацию нужных сервису данных из одного ДЦ в другой ДЦ.

Это всё стандартные функции.

То есть если у вас есть:
- PXE и у вас настроена шаблонизация и установка образов ОС на физику
- Вы покупаете +/- однотипное серверное оборудование (в больших развертываниях всегда так)
Вы вообще не увидите разницы в вопросах сопровождения. Ну разве что во времени. Клонировать шаблон виртуалки на соседний сервер быстрее, чем накатить этот шаблон на физический сервер по сети.

Вообще виртуализация - это технология уплотнения серверов, не более того. Вот есть у вас стойка, а вам нужно поставить сервер в котором 1 процессор 4 ядра, 32 ГБ RAM и до 500 ГБ места на диске. Это целый юнит. А тем временем этот сервер всё равно будет жрать электричество и занимать порты коммутатора.
Хостинг провайдеры, а теперь и облака давно промывают молодёжи мозги, будто виртуализация это круто. Нет.
Виртуализация позволяет им продать VDS на ушатанном хосте, на котором оверкоммит по процессору 10. То же самое с микросервисами и облаками.

Всё что я писал выше я писал про веб-приложения. С БД всё гораздо мрачнее. В общем случае реляционные СУБД не должны ставиться на виртуальную машину никогда, кроме тех случаев, когда глупый сервер БД не поддерживает работу на физических серверах. Не буду вам писать про кластеризацию СУБД, логическую и бинарную репликацию и балансировку через read-only routing. А то это как-то мимо темы.