Отказоустойчивый сервер, как?

Если вы держите сервер в hetzner — то можете проходить мимо с такими вопросами. Если у вас есть бюджет порядка 20-30к в месяц на всё это — тогда продолжайте думать.

А можно узнать, что значит «шалить»? А то, вот, у меня там 7 серверов, и я, что-то, шалостей не замечаю.

По делу: синхронизация чего именно в реальном времени? файлов? DB? и того и другого? чего-то еще?
как планируете переключаться с одного сервера на другой, какой механизм?
Или Вы сами пока не знаете?

Готового решения нет. То, что Вы хотите — достаточно дорого и геморно. Если, конечно, хотите «как только падает сервер, резервный сервер все принимает на себя», а не «падает сервер, теоретически через 20 минут, а по факту через час начинает кое-как работать с резерва».
Что Вам нужно:
1) хороший канал между ДЦ. Иначе не получится в иметь актуальную БД (заблокировали на основном сервере, записали на резервном и получили подтверждение, разблокировали на основном), или будет работать очень медленно.
2) единое адресное пространство (значит, BGP) — без этого не получится поднять 1 IP на разных серверах. С единым адресным пространством уже появляются варианты, как рулить переключением — на роутере (если умеет) или через что-то вроде keepalived (опять требования к каналу между ДЦ, хоть и более мягкие чем в пункте 1).

Все другие варианты (ДНС, например) однозначно подводят Вас к тому или иному времени простоя. Причем у части пользователей это время может быть очень большим и независящим от Ваших усилий(не перевелись еще криворукие настраивальщики локальных ДНСов среди провайдеров).

Пользуйте Облако, оно по единичным отказам и призвано защищать.
Есть и Облачные решения которые разнесены по нескольким ДЦ, это уже катастрофоустойчивые решения.

Настраиваем днс. В домене указать два днса. Первый нс на основной сервере, второй на резерве. Самый малый ттл для записей.
На резерве отдаем по днс основную А запись. Стоит мониторинг доступности сервера основного. Раз в минуту пингуем адрес, конектимся к порту 80 или получаем страничку проекта и ищем на ней чекпоинт.
Не сработало что-то из проверок — на резерве скрипт мониторинга заменяет файл зоны с А записью на резерв и релодим днс.
Тут кроется опасность. ТТЛ по хорошему истечет и переспросить должны адрес, но как говорили выше не перевелись криворукие «кешаторы» днс ответов.
Синхронизация файлов по incron через рсинк.
Синхронизация базы? Репликация мастер-мастер или если возможно урезать функционал, то на резерве только на чтении база.