ASTCO GmbH.  Rechnungsadresse: Hirschstettner Str. 19, Obj. A/1/B2 AT-1220 Vienna / Austria Tel. +43 5 7003 0  /  Fax +43 5 7003 7000 Firmenbuch FN 37895d DVR Nummer 0675539 © 1999 - 2019  Lieferadresse (Abholungen) Add On & ASTCO - LAGER  Hirschstettner Str. 19, Obj. O/EG/Lager 3 AT-1220 Vienna / Austria Impressum Datenschutz
Alle genannten Marken oder Produktnamen sind Warenzeichen oder eingetragene Warenzeichen des jeweiligen Eigentümers. Alle technischen Produktinformationen basieren auf den Angaben des Herstellers, die wir für den österreichischen Markt aufbereiten. Die ASTCO GmbH. übernimmt keine Verantwortung für die Richtigkeit, Vollständigkeit und Aktualität der Informationen und Angaben. Alle Preisangaben (UVP = unverbindlich empfohlener Verkaufspreis) verstehen sich exklusive Mehrwertsteuer, Transportkosten und etwaigen Installationskosten. Aufgrund möglicher Wechselkursschwankungen (JPY <> EUR) ersuchen wir Sie, die Preisangaben als unverbindliche Richtwerte zu betrachten. Für ein verbindliches Produktangebot kontaktieren Sie bitte unseren Verkauf bzw. Ihren bevorzugten Fachhändler. Preise gültig ab 10/2019
NetJapan MailVault main
MAILVAULT FAQ
Home / Backup&DR, Mail-Archiv - NetJapan (News) / Produktübersicht / Mail-Archiv by MailVault / MailVault FAQ

Wozu E-Mail Archivierung .. wir haben doch ein Backup ?

Ein regelmäßiges Backup Ihres Mail-Systems ist einerseits eine absolute Notwendigkeit, um die Wiederherstellung Ihres Betriebes im Fehlerfall zu gewährleisten. Andererseits ist ein Backup-System für die sichere Archivierung von E-Mails über viele Jahre aus mehreren Gründen ungeeignet. Backup, zu Deutsch "Datensicherung" bezeichnet das Kopieren von Daten in der Absicht, diese im Fall eines Datenverlustes zurückkopieren zu können. Somit ist Datensicherung eine elementare Maßnahme zur Datensicherheit. (Quelle: Wikipedia) Diese Definition von Backup ist wohl jedermann bekannt und grundsätzlich natürlich richtig. Im privaten Kontext, wo es beispielsweise darum geht, sich gegen den Verlust von Urlaubserinnerungen zu schützen, ist dieses Definition auch völlig ausreichend und Mann/Frau verbindet damit, beispielsweise die zusätzliche Kopie der eigenen Fotos auf einer externen USB- Festplatte oder DVD. Im betrieblichen Umfeld ist es allerdings unumgänglich, diesem simplifizierten Grundsatz zwei wichtige Kürzel hinzuzufügen, nämlich ´RTO´ (Recovery Time Objective) und ´RPO´ (Recovery Time Objective), die zusammen den Dreh- und Angelpunkt jedes Backups bzw. jeder Betriebskontinuitätsplanung darstellen. Die Bedeutung dieser beiden sperrigen Begriffe lässt sich natürlich auch ins Deutsche übersetzen und verständlich erklären. RTO (Recovery Time Objective) beschreibt den Zeitraum, der notwendig ist ein ausgefallenes System wieder herzustellen. Bei diesem Zeitraum kann es sich um Minuten, Stunden oder sogar Tagen handeln und abhängig von der vorhandenen Infrastruktur ist damit ein teilweiser oder vollständiger Betriebsstillstand verbunden. Obwohl man in erster Linie an eine defekte Hardware als Ursache für einen Systemausfall denkt (defekte Festplatten, Netzteile etc.), sind Software-Probleme (fehlerhaftes Update, zu wenig Speicherplatz etc.) mindestens genauso häufig. Unabhängig von der Fehlerursache bedeutet der RTO-Wert im Falle eines E-Mail-Systems also, „Wie lange ist es für ein Unternehmen gerade noch akzeptabel PER E-MAIL NICHT ERREICHBAR ZU SEIN?“ RPO (Recovery Point Objective) beschreibt den Zeitraum, der hinsichtlich eines Datenverlustes gerade noch akzeptabel ist. Dieser Zeitraum wird ebenfalls in Minuten, Stunden oder sogar Tagen angegeben und hängt unmittelbar mit der Häufigkeit von Backup-Vorgängen zusammen. Mit anderen Worten, wie oft werden Ihre Daten gesichert, alle 30 Minuten, alle 4 Stunden, einmal täglich ? Alle Daten und damit beispielsweise alle E-Mails, die Sie in der Zeit zwischen Ihrem letzten Backup erhalten oder geschrieben haben, sind bei einem Systemausfall unwiederbringlich verloren. Wird beispielsweise 2x täglich ein Backup durchgeführt, können im Fehlerfall alle E-Mails aus einem Zeitraum von >= 12 Stunden verloren gehen. Die nachfolgende Grafik zeigt beispielsweise ein Unternehmen, das 2x täglich ein Backup durchführt, und zwar einmal tagsüber um 12:00 und einmal nach Geschäftsschluss um 22:00. Tritt ein Systemausfall um 11:00 vormittags ein, beträgt der Wert für RPO also 13 Stunden und alle E-Mails, die in diesem Zeitraum gesendet oder empfangen wurden sind damit verloren.

MailVault - Frequently Asked Questions (FAQ)

Mo 22:00 Mail Server Backup Di 22:00 Mail Server Mi 11:00 Mail Server Mi 20:00 alle E-Mails der letzten  13 Stunden verloren kein Zugriff  auf E-Mails RPO = 13h RTO = 9h Di 12:00 E-Mail Archivierung mit [klick] E-Mail Archivierung mit [klick]
Alle Mails der letzten 13 Stunden wären damit verloren !! .. das könnte für viele Unternehmen bereits geschäftsschädigende Auswirkungen haben. Die gute Nachricht - mit einer modernen Backup & DR Lösung wie dem NetJapan Active Image Protector lassen sich die Werte für RPO und RTO deutlich verbessern. In Bezug auf einen funktionierenden E-Mail Verkehr kommt bei vielen Unternehmen dem RPO-Wert eine höhere Bedeutung zu als dem RTO-Wert. Das liegt einfach daran, dass die meisten KMU´s mit einer Unterbrechung der Erreichbarkeit vielfach noch gut zurecht kommen, d.h. einen halben Tag kein E-Mail schreiben bzw. empfangen zu können ist meistens noch irgendwie verkraftbar. Hingegen kann der effektive Verlust von E-Mails, die beispielsweise wichtige Preis- oder Terminzusagen beinhalten, sich in weiterer Folge als äußerst problematisch erweisen. RPO gleich 1 Stunde, 30 Minuten oder weniger Für wichtige Systeme bzw. Anwendungen sind mit dem ActiveImage Protector von NetJapan Backups mit sehr kurzen Intervallen im laufenden Betrieb möglich. Damit kann der RPO Wert auf 1 Stunde, 30 Minuten oder weniger reduziert werden. Die Untergrenze für diese laufenden Backups liegt bei einem Intervall von 15 Minuten. RTO gleich 15 Minuten, 10 Minuten oder weniger Speziell in virtualisierten Serverumgebungen bietet der ActiveImage Protector von NetJapan die Möglichkeit, den Betrieb nach einem Systemausfall (hard- oder softwarebedingt) in kürzester Zeit wieder fortzusetzen. Virtuelle Standby-Systeme können innerhalb von wenigen Minuten mit dem letzten Backup gestartet werden. Darüber hinaus besteht natürlich die Möglichkeit, wichtige Systeme HOCHVERFÜGBAR zu gestalten. Hochverfügbarkeit (HA - High Availability) bietet eine Verfügbarkeit von 99,999% und mit einer Ausfallzeit von maximal 5 Minuten pro Jahr einen RTO-Wert von praktisch 0 (Null). Aufgrund der relativ hohen Investitions- kosten sind HA-Systeme jedoch für kleinere Unternehmen eine, nur schwer finanzierbare Option und können darüber hinaus ein regelmäßiges Backup nicht ersetzen. Backup ist schließlich der einzige Schutz bei Softwarefehlern oder bei Angriffen durch Schadsoftware (Ransoware). Wie diese Gegenüberstellung Jedoch bereits deutlich macht, kann ein E-Mail-Archivierungssystem für sehr viele Betriebe bereits eine wichtige und wertvolle Ergänzung zum Backup darstellen.
Backup-Intervall Restart mit virtueller Standby Maschine
In weiterer Folge erweitern wir diesen Vergleich mit entsprechend langen Zeiträumen, um den verschiedenen Aufbe- wahrungsrichtlinien (3, 5, 7, 10 Jahre) zu entsprechen und befassen uns dabei mit der Frage

Warum sind Backups ungeeignet für eine E-Mail Archivierung über mehrere Jahre ?

Um die Aufgabenstellung bzw. die damit einhergehende Problematik besser zu verstehen, müssen wir uns noch mit zwei weiteren Begriffsdefinitionen beschäftigen, nämlich der Bedeutung von „strukturierten Daten“ und „unstrukturierten Daten“. Unter unstrukturierte Daten fällt alles, was als Einzeldatei vorliegen kann und wohl allen, sowohl aus dem betrieblichen als auch aus dem privaten Umfeld gut bekannt ist. Dazu zählen alle Dokumente, die beispielsweise mit einem Textverarbeitungsprogramm erstellt werden (.doc) genauso wie Kalkulationstabellen (.xls), Präsentationen (.ppt) und natürlich alle Audio-, Video- und Bilddateien (.mp3, .jpg, .mp4, etc.). Unstrukturiert deshalb, weil diese Dateien für sich gesehen bereits den ganzen „Content“ beinhalten und in keiner Abhängigkeit zu anderen Dateien stehen. Unstrukturierte Daten können daher in einfacher Weise mit simplen Kopierbefehlen auf andere Datenträger verschoben und ebenso einfach wieder hergestellt werden. Im Unterschied dazu, handelt es sich bei „strukturierte Daten“ um eine Kombination mehrerer unterschiedlicher Dateien und Dateiformaten (Datenbanken, Konfigurationsdateien, Log-Dateien etc.) die zueinander in Abhängigkeit stehen und nur zusammen den reibungslosen Betrieb garantieren. Bei strukturierten Daten handelt es sich somit um ein, mehr oder weniger geschlossenes System, das die jeweilige Basis für praktisch jede betriebswirtschaftlichen Anwendung darstellt . Egal ob es sich dabei um ein Warenwirtschaftssystem (ERP), ein Kunden-Management-System (CRM) oder um ein Messaging-, sprich E-Mail- System handelt. Die vordringlichste Aufgabe beim Backup solcher Applikationen, wie in diesem Fall beim Backup des E-Mail-Systems, besteht daher darin, ein vollständiges, sprich konsistentes Abbild des kompletten Systems zu erzeugen, das im Fehlerfall eine rasche Wiederherstellung und damit die Wiederaufnahme des Betriebs ermöglicht. Bei solchen vollständigen Systemabbildern (System-Image, Full-Backup) ist das einzelne Mail aber keine separat „physisch angreifbare“ Datei, wie zum Beispiel ein Text-Dokument, sondern steckt als Datensatz irgendwo in den Datenbanken mit Referenzen zu Status- und Log-Files. Diesem Umstand werden wir etwas weiter unten noch mehr Aufmerksamkeit widmen, zuvor jedoch noch ein paar Worte zu üblichen Backup-Strategien und Vorhaltezeiten von Backup-Kopien.

Backup-Strategien und gebräuchliche/sinnvolle Vorhaltezeiten von Backup-Kopien

Wie bereits erläutert kann die Gefahr eines Datenverlustes mit kurzen Backup-Intervallen (siehe RPO) minimiert werden. Da dieses Backup im laufenden Betrieb erfolgen muss, beispielsweise stündlich, werden bei diesem Backup nicht alle Daten, sondern nur die Änderungen der letzten Stunde gesichert. Solche Backups werden als „inkrementelle“ Backups (incremental Backups) bezeichnet und können aufgrund der geringen Datenmenge sehr rasch und praktisch ohne Beeinträchtigung des laufenden Betriebes durchgeführt werden. Obwohl jedes dieser inkrementellen Backups für sich gesehen, also isoliert betrachtet, eigentlich nur Datenfragmente beinhaltet, entsteht gemeinsam mit dem jeweils letzten vollständigen Backup (Full-Back) eine Backup-Kette. Bildlich gesprochen werden die inkrementellen Backups wie die Auflagen eines Sandwichs übereinander gestapelt und bilden damit eine große Anzahl an Wiederherstellungspunkten auf die im Bedarfsfall zurückgesetzt werden kann. Sehr kurze Intervalle mit inkrementellen Backups erzeugen verständliche Weise ein Vielzahl an kleinen Dateien. So generiert das obige Beispiel eines stündlichen Backups bereitd eine Backup-Kette mit einem großen Full-Backup und 50 kleinen inkrementellen Backup-Dateien pro 5-Tage Arbeitswoche. Da die Länge solcher Backup-Ketten den Wiederherstellungsprozess negativ beeinflusst, d.h. verlangsamt, ist eine sogenannte Konsolidierung nach spätestens 150 inkrementellen Backups notwendig. Durch die Konsolidierung entsteht ein neues Full-Backup mit dem Zeitstempel des letzten inkrementellen Backups. Die gebräuchliche Praxis ist daher die Konsolidierung inkrementeller Backups 1x pro Woche zu einem Full-Backup und die Aufbewahrung der wöchentlichen Backups aus den letzten 1 bis max. 3 Monaten. Diese Backup-Strategie ist für die viele Betriebe ausreichend, wenn es sich dabei um das Backup von Systemen mit strukturierten Daten handelt. Zur Erinnerung das sind alle Systeme, die auf mehrere, in Abhängigkeit zueinander stehender Datenbanken zugreifen und transaktionsorientiert sind. In diese Kategorie fallen alle ERP-, CRM- und auch E-Mail-Systeme. Bei transaktionsorientierten Systemen sinkt der Wert einer Backup-Kopie proportional zur Anzahl der verwendeten Datenbanken und Transaktionen. D.h. auch bei einer nur durchschnittlichen Transaktionsfrequenz von wenigen hundert Transaktionen pro Woche, beispiels- weise in einem Warenwirtschaftssystem (ERP), ist das Backup von letzter Woche höchstwahrscheinlich bereits bedeutungslos und wird eigentlich nur für ein absolutes „Worst-Case-Szenario“ aufbewahrt. Verbunden mit der Hoffnung, nie auf das Backup von letzter Woche rücksetzen zu müssen, da das „Nachführen“ aller Transaktionen der letzten 7 Tage, wie z.B. erhaltene Bestellungen, Lagerzugänge, getätigte Lieferungen, durchgeführte Preis-Updates, uvm. praktisch unmöglich wäre. Hochverfügbare Systeme sind daher auch bereits bei vielen mittelständischen Unternehmen im Einsatz, um einen 24x7x365 Betrieb zu gewährleisten. Bei einem E-Mail-System ist die Situation natürlich bei weitem nicht so dramatisch, da sich die möglichen Transaktionen auf GESENDETE und EMPFANGENE NACHRICHTEN beschränken. Trotzdem sollten die bisherigen Ausführungen deutlich gemacht haben, dass beim Backup von Datenbank-basierenden Systemen die möglichst rasche Wiederherstellung des Betriebes als höchste Priorität im Vordergrund steht und daher eine Langzeitarchivierung zwar grundsätzlich nicht unmöglich aber mit erheblichen Aufwand und Kosten verbunden ist. Betrachten wir dazu den Problembereich „gelöschte E-Mails“. Bei der Fülle an E-Mails, erwünschten und unerwünschten, kann es schnell einmal passieren, dass E-Mails irrtümlich gelöscht werden. Sofern nicht gleich mit dem „Endgültigen Löschen“ (Shift+Entf) agiert wurde, befinden sich die gelöschten Mails noch im Ordner „Gelöschte Elemente“ und lassen sich von jedem Benutzer ganz einfach wieder zu den aktuellen Mails verschieben. Sind die E-Mails auch nicht mehr im Ordner „Gelöschte Elemente“ vorhanden, wird die Wiederherstellung bereits komplizierter und kann auch bereits Kosten verursachen, wenn beispielsweise im Unternehmen kein kundiger Administrator zur Verfügung steht. Wie bereits erwähnt, sind ja die einzelnen Mails keine separaten „physisch angreifbare“ Dateien, wie zum Beispiel ein Text- Dokument, sondern stecken als Datensatz irgendwo in den Datenbanken. Verständlicher Weise hat der „einfache User“ nur einen eingeschränkten Zugriff auf diese Datenbanken, nämlich nur Zugriff auf sein eigenes Postfach. Über höhere Berechtigung verfügen eben nur Systemadministratoren oder externe Spezialisten, die nun entsprechende Hilfe leisten müssen. Im günstigen Fall wurde beim E-Mail-System ein Journal-Postfach eingerichtet, das automatisch eine Kopie jeder empfangenen bzw. gesendeten E-Mail unabhängig und zusätzlich zum Benutzerpostfach enthält. Aus diesem Journal-Postfach kann der Administrator die irrtümlich gelöschten E-Mails für den Benutzer dann wieder herstellen. Allerdings handelt es sich bei diesem sogenannten „Journaling“ um eine gesondert zu konfigurierende Option bei E-Mail-Systemen, auf die mangels Kenntnis oder aber auch absichtlich verzichtet wird. Der Grund für den Verzicht auf ein ´aktiviertes Journaling´ ist oftmals die Beeinträchtigung der System-Performance oder knappe Kapazitäten auf kleineren oder älteren E-Mail-Servern. Ohne aktiver Journaling-Funktion ist dann eine Wiederherstellung gelöschter E-Mails nur mehr mit Hilfe eines Backups möglich, was dann bereits mit entsprechend mehr Zeit- und Kostenaufwand verbunden ist. Waren es relativ aktuelle Mails, vom gleichen Tag, von letzter Woche oder letzten Monat, bleibt der Aufwand auch noch in absehbaren Grenzen, da sich der Administrator dann gezielt mit dem Backup von gestern, letzter Woche oder letzten Monat befassen kann.
Wirklich kompliziert kann es allerdings werden, wenn beispielsweise ein Geschäftsfall von vor 2 Jahren rekonstruiert werden muss. Hier ein Beispiel: Angenommen Ihr Kunde erhebt strittige Garantieansprüche die geklärt werden müssen. Nachdem Sie, recht zeitaufwändig Ihrem E-Mail-Server endlich entsprechende Suchergebnisse „abgerungen“ haben, stellen Sie fest, dass die Suchergebnisse anscheinend Lücken aufweisen. Das E-Mail mit den Garantiezusagen, das Ihnen Ihr Kunde als PDF-Datei vorlegt ist in den Suchergebnissen nicht enthalten und führt zu folgenden Fragen 1. Wurden Mails gelöscht? 2. Wann wurden diese Mails gelöscht? 3. Irrtümlich oder absichtlich gelöscht? 4. Kann der komplette (fehlende) E-Mail-Verkehr mit Hilfe eines Backups rekonstruiert werden? 5. Wenn JA, ein Backup von welchem Datum, welches Jahr, welcher Monat? Frage Nr. 1, 2 und 3 können wir an dieser Stelle nicht beantworten. Zu Frage 4 und Frage 5 geben wir Ihnen allerdings gerne folgende Antwort. GRUNDSÄTZLICH JA, ABER NICHT SINNVOLL, WEIL BACKUP EBEN BACKUP UND NICHT ARCHIVIERUNG BEDEUTET. Um für diese Anforderungen ein möglicherweise passendes Backup zu haben, müssten Sie nämlich von allen Monaten ein Backup über viele Jahre hinweg aufbewahren. Bei einem E-Mail-System mit einem fiktiven, d.h. immer gleich bleibenden Speicherbedarf von 3TB bedeutet das für 2 Jahre bereits eine zusätzlich notwendige Speicherkapazität von 72TB (3TBx12x2), bei 5 Jahren bereits 180TB (3TBx12x5) usw. Mit einem E-Mail-Archivierungssystem wie MailVault benötigen Sie dafür hingegen lediglich weniger als ca. 5TB Speicher- kapazität und profitieren zu günstigen Kosten noch von vielen anderen Vorteilen, wie z.B.

Auch beim Ausfall Ihres Mail-Servers gehen keine E-Mails mehr verloren

E-Discovery - findet innerhalb von Sekunden die gewünschten E-Mails vieler Jahre

Kein versehentliches Löschen einer E-Mail möglich

Einfacher Benutzerzugriff per Webbrowser

Jeder Benutzer kann seine eigenen E-Mails wiederherstellen

Stellen Sie E-Mails von einem Mailserver auf einem anderen wieder her

usw.

Das könnte Sie auch noch interessieren:
Warum brauchen wir MailVault mit Office 365 ? (PDF) Warum brauchen wir MailVault mit GSuite ? (PDF) E-Mail Journaling ist keine E-Mail Archivierung  (PDF)
Haben Sie noch Fragen zu Backup und Archivierung ? Wir beraten Sie gerne ! Nehmen Sie einfach und unverbindlich Kontakt mit uns auf.
unstructured data structured data incremental Backup

NetJapan - MailVault FAQ