Горячая/Прохладная установка почтового сервера
Я видел этикетку на маршрутизаторах Cisco и переключателях, говоря, что "Поверхность может быть горячей" а не коснуться их. Таким образом, я думаю, что Ваш случай не является проблемой. Даже мой маршрутизатор USR (Это - просто маршрутизатор DSL для домашнего использования) становится горячим даже после одного часа, но я никогда не испытывал проблему с этим.:)
Существует три компонента к тому, что Вы спрашиваете здесь: Репликация баз данных, почтовое дублирование и пользовательский доступ.
Репликация баз данных легка, и хорошо охвачена документацией MySQL.
Почтовая репликация обычно так же легка как проверка, что Ваши рекорды MX устанавливаются правильно. Если dubdeuce не будет основной MX, то он перешлет почту к основному MX, после того как основное устройство доступно снова.
Однако Вы явно не заявили это, но Ваше включение roundcube подразумевает, что Вы хотите, чтобы вторая система была полностью операционной насколько MUA идет - Вы хотите, чтобы пользователи смогли прочитать электронную почту. Если это не так - Вы рады за roundcube быть в режиме офлайн, пока dubone не возвратится - затем, вышеупомянутые компоненты сделают задание для Вас.
Еще раз: если все, что Вы хотите, является простой системой, которая будет электронная почта промежуточной буферизации, пока основное устройство не прибудет назад, все, в чем Вы нуждаетесь, репликация баз данных для mysql и использовать вторичный MX. Эта система должна быть живой в любом случае, не только вращался в потребности.
Если Вы хотите полностью избыточную систему, в которой roundcube всегда доступен, то то, что Вы хотите, является общим mailspool между этими двумя системами. Нет никакого реального способа настроить dubduece как основной MX и дать пользователям, способность считать почту из него и иметь его разумно пересылает электронную почту к dubone.
Так, Вам нужен общий mailspool. Это могло быть третьей системой, действующей как файловый сервер, служа mailspool двум основным хостам, однако существует давняя рекомендация против использования NFS для mailspool, из-за блокировки проблем.
Это могло быть сделано с помощью DRBD между этими двумя узлами в активном / режиме резервного копирования - когда один узел перестал работать, Вы используете heartbeat для переключения другого узла на активный. Когда первый узел возвратится онлайн, Вам будет нужен процесс биения для переключения всего назад также. Необходимо будет все еще разработать, как Вы копируете свою базу данных - Вы могли бы хотеть мультиосновную установку теперь.
Наконец, Вы могли сделать то же самое с DRBD, но использовать файловую систему с поддержкой кластеров на нем и иметь оба узла, являющиеся активным в любом случае. Это немного более сложно все же. Вы могли DRBD вся почтовая система между узлами также. И существует много способов увеличиться - больше передовых решений включает SAN и стек VM как Citrix Xenserver или VMware.
За мои деньги я придерживался бы активного/пассивного DRBD mailspool, или мультиосновной mysql, или DRBD активный/пассивный поддержал mysql, и используйте heartbeat для перемещения, включают активные службы на обработку отказа. Альтернатива этому помещает Ваш целый mailserver в VM использование Xen или KVM или независимо от того, что Вы любите, поддерживая VM на систему DRBD, и имея обработку отказа heartbeat DRBD и запускаете VM на втором узле в случае отказа. В этом примере Вы только на самом деле получили "один" mailserver, он просто плавает между Вашими узлами. Оборотная сторона - то, что необходимо ожидать его для начальной загрузки на обработке отказа, которая может требовать времени.
Как примечание стороны, какой бы ни путь Вы делаете вещи, удостоверяются, что Ваш спам / вирус / вредоносное программное обеспечение / и т.д. сканирование настроен тождественно в обеих системах.