Хранение двух серверов в синхронизации - вторичный сервер только, чтобы быть загруженным для резервного копирования, или в отключении электричества

Идея, на который в отключении электричества и т.п., мы можем изменить наши настройки DNS для указания на резервный экземпляр просто для уменьшения времени простоя

FFS, я не назвал бы минимальное время простоя 3 часов, минимизируя время простоя.

Обработка отказа к резервному устройству никогда не является хорошим способом реализовать отказоустойчивость. Используйте выравнивание нагрузки для выполнения всех узлов и прямого трафика далеко от провальных узлов.

Не пытайтесь реконфигурировать архитектуру на лету с помощью DNS - это берет Слишком долго.

Простое решение состоит в том, чтобы реализовать циклический DNS веб-серверы и использовать основную основную репликацию на DBMS с настраиваемым соединением дб на каждом узле, таким образом, Вы переключаетесь далеко от неудавшегося DBMS. Вы могли использовать репликацию "главный-подчиненный", синхронизация в реальном времени, необходимость - и автоматизируйте продвижение ведомого устройства.

Быстрый и простой подход должен был бы копировать Вашу базу данных каждый час/, затем rsync (для Windows пробуют Deltacopy rsync), Ваши файлы резервных копий и другие каталоги к серверу резервного копирования. Затем на сервере резервного копирования пишут сценарий для восстановления файла резервного копирования базы данных, который работает каждый час.

rsync передаст только дельты файла и сожмется, поскольку он передает.