Vornweg noch ein Wort zu der Vorhaltezeit: Die 4-5 Tage werden im Abschnitt 4.5.4.1 von
RFC 2821 (Simple Mail Transfer Protocoll) gefordert. Daran sollte sich jeder vernünftige MTA halten.
Nun zum Hauptproblem; das sind Deine Mailboxen, die Du in einem normalen Setup mit "normalen" (v)Servern bei einem Hoster
nur auf einem Rechner haben kannst.
Ein Umschalten des DNS A-Records wird aufgrund der Latenzen schwierig (natürlich könntest Du die TTL für deine POP/IMAP-Server auf eine Stunde setzen und damit die Latenz-Zeit reduzieren, in der nicht alle Clients die richtige Adresse bekommen, aber leider halten sich nicht alle Provider an den TTL-Wert: Wie man so liest, cachen die Nameserver der Telekom unabhängig davon deutlich länger...).
Der kanonische Weg hier Redundanz zu schaffen wäre ein Server, der bei einem Ausfall direkt durch einen (identischen) anderen ersetzt wird, und dabei auch dessen IP-Adresse übernimmt. Die Daten/Mailboxen werden dabei nicht auf einer Platte im Server gespeichert, sondern auf einem redundant ausgelegten NAS-System, das entweder leicht umgehängt werden kann, oder schon direkt mit dem Failover-System verbunden ist, so dass letzteres beim Ausfall des Hauptsystems gleich loslegen kann.
Ich habe zwar auch schon mehrere MX-Rechner gleichzeitig betrieben, die ihre Daten in ein Netzwerkdateisystem (OpenAFS) ausgeliefert haben. Da die Rechner alle gleichberechtigt waren und alle parallel Mails angenommen haben, konnte man ohne große Probleme einen davon ausschalten, ohne dass es jemand gemerkt hätte (die Performance ging natürlich in die Knie). In diesem Setup gibt es natürlich leicht Datenkonistenz-Probleme, die nur durch konsequentes Locking gelöst werden können (und man merkt erst im Laufe der Zeit, welche Programme da nicht so richtig mitspielen) und insbesondere die Zusammenarbeit mit IMAP erfordert daher viel Handarbeit. Aus diesem Grund sagen die meisten Fachleute, dass der Aufwand dafür viel zu groß ist, und man lieber in anständige Hardware investieren sollte, die intern entsprechend redundant ausgelegt ist -- und eben für den Fall der Fälle ein Notsystem bereit halten sollte, das man schnell anstelle des ausgefallenen Systems einsetzen kann (und dessen IP-Adresse man dann übernimmt). Das schnelle Switchen wirst Du bei den meisten (billig-)Hostern jedoch nicht bekommen können.
Also muss ich Dich enttäuschen, denn ich kann keine Lösung anbieten, die mit einfachen Mitteln bei den gängigen Providern umsetzbar wäre.
Stattdessen sollte Deine Strategie sein, immer aktuelle Backups vorzuhalten und die Installation Deines Servers zu automatisieren. Ziel ist es, so schnell wie möglich den ursprünglichen Zustand wieder herzustellen, sobald Dir Dein Hoster nach dem Crash ein jungfräuliches System hinstellt. Daher solltest Du alle Schritte, die Du seit der Übergabe des Systems an Dich unternommen hast, dokumentieren -- ich finde da Shell-Scripte sehr hilfreich, in die man alles reinschreibt, da man die dann einfach zur Installation der Reihe nach ausführen kann. Ein zweiter Server ist dabei zum regelmäßigen Testen sehr nützlich. Ein secondary-MX kann Dir ein besseres Gefühl geben, ist aber nicht unbedingt notwendig. Nicht vergessen sollte man auch Redundanz bei der Administration, denn Notfälle passieren natürlich vorzugsweise genau dann, wenn Du im Urlaub bist, oder krank im Bett liegst....
Viele Grüße,
LinuxAdmin
