Ein Dienstleister, der bei seinen Kunden mit der Sicherung beginnt, erlebt eine Entwicklung in drei Schritten. Die ersten fünf Kunden: Alles gut, die Berichte werden gelesen. Die nächsten zwanzig: Sie werden überflogen. Danach: Sie werden nicht mehr gelesen — und man erfährt es an dem Tag, an dem ein Kunde eine Wiederherstellung aus einer Sicherung verlangt, die seit sechs Wochen nicht mehr läuft.
Das ist kein Problem der Sorgfalt. Das ist ein Problem des Entwurfs.
Warum der tägliche Bericht per Mail nicht trägt
Das Standardmodell vieler Lösungen: Jede Sicherung schickt einen Bericht, man erhält sie alle, man schaut hinein.
Bei fünfzig Kunden und drei Rechnern je Kunde sind das hundertfünfzig Nachrichten pro Tag. Einige Reflexe entstehen von selbst: Eine Sortierregel legt sie in einen Ordner, dann sieht man sie an, „wenn Zeit ist", dann gar nicht mehr.
Der Konstruktionsfehler liegt hier: Der tägliche Bericht meldet, was geschehen ist, nicht, was nicht stattgefunden hat. Eine Sicherung, die scheitert, schickt eine Fehlermeldung. Eine Sicherung, die überhaupt nicht startet — Rechner ausgeschaltet, Agent beim Gerätetausch entfernt, Dienst gestoppt — schickt nichts. Das Schweigen ist von der Ruhe nicht zu unterscheiden.
Die Warnung, auf die es ankommt: der ausgebliebene Lauf
Die Wende kommt, wenn man die Logik umdreht: Statt auf ein Fehlersignal zu warten, überwacht man das Fehlen eines erwarteten Signals.
Eine nützliche Warnung über einen ausgebliebenen Start hat drei Eigenschaften:
Sie wird je Rechner eingestellt, nicht global. Ein Notebook, das dreimal pro Woche sichert, und ein Server, der jede Nacht sichert, haben nicht dieselbe Schwelle. Eine einzige Schwelle erzeugt entweder Lärm oder blinde Flecken.
Sie berücksichtigt mehrere Server. Wenn Sie replizieren oder mehrere Sicherungsserver haben, darf ein Rechner, der anderswo gesichert hat, keine Warnung auslösen. Eine Lösung, die die anderen Server befragt, bevor sie warnt, erspart Ihnen Fehlalarme — und Fehlalarme sind das, was eine Überwachung tötet, weil man am Ende alle ignoriert.
Sie ist abrufbar, nicht nur versendet. Eine Mail geht verloren. Ein Dashboard, das die laufenden Zustände zeigt, ist morgens in dreißig Sekunden gelesen.
Das Dashboard als Ausgangspunkt
Das Ziel am Morgen ist nicht, alles zu prüfen: Es ist, in einem Bildschirm zu wissen, ob etwas zu tun ist.
Konkret ein Status, der die Lagen unterscheidet: Fehler, Warnung, nicht gestartet, gesperrt, Sicherung läuft, Wiederherstellung läuft, Replikation läuft, Integritätsprüfung, Microsoft-365-Sicherung. Jede verlangt eine andere Handlung — oder keine.
Das Filtern nach Zuständigkeit zählt genauso viel wie die Zustände selbst. Ein Techniker, der zehn Kunden betreut, soll nicht alle fünfzig sehen: Der Lärm macht die Ansicht unbrauchbar.
Rechte je Techniker
Das ist ein Thema, das man aufschiebt und das dann blockiert.
Solange man allein ist, sind alle Administrator. Bei drei Technikern kommen die Fragen: Soll eine erste Ebene eine Sicherung neu starten dürfen? Ja, das ist der Sinn. Eine Aufbewahrungsregel ändern? Nein, das kann Fassungen löschen. Beim Kunden wiederherstellen? Je nach Fall.
Eine feine Abstufung — in der Größenordnung von fünfzig benannten Rechten — erlaubt, diese Fragen einmal zu beantworten und dann einzustellen, ohne die Debatte neu zu eröffnen. Die richtige Frage: Was ist die zerstörerischste Handlung, die dieses Profil auslösen kann?
Die Berichte, die beim Kunden ankommen
Zwei Wirklichkeiten bestehen nebeneinander: was Sie überwachen, und was Ihr Kunde sieht.
Der Kunde braucht nicht die hundertfünfzig täglichen Zeilen. Er braucht in regelmäßigen Abständen eine lesbare Seite, die sagt, was geschützt ist, über welche Tiefe, und ob alles in Ordnung ist. Unter Ihrem Namen, nicht unter dem des Herstellers — Sie erbringen die Leistung.
Es ist auch das Dokument, das Sie im Jahresgespräch hervorholen, wenn man Sie fragt, wozu die Zeile „Sicherung" auf der Rechnung dient.
Der Wiederherstellungstest, als Aufgabe einzuplanen
Alles Vorstehende überwacht, dass die Sicherungen stattfinden. Nichts garantiert, dass sie wiederherstellbar sind.
Der Wiederherstellungstest ist die einzige Prüfung, auf die es ankommt, und er ist auch die erste, die man aus Zeitmangel aufgibt. Zwei Wege, ihn dauerhaft durchzuhalten:
- Die automatische Integritätsprüfung auf Serverseite, die die Daten zurückliest und die Prüfsummen nach jeder Sicherung oder nach einer Regel je Rechner vergleicht. Sie ersetzt keine Wiederherstellung, aber sie entdeckt die stille Beschädigung, ohne jemanden zu binden.
- Eine echte Wiederherstellung je Kunde und Jahr, als Wartungsaufgabe eingeplant. Eine Datei, ein Ordner, und alle zwei oder drei Jahre ein vollständiges System bei den kritischen Kunden.
Der zweite Punkt hat einen oft unterschätzten geschäftlichen Nutzen: Ein datiertes Wiederherstellungsprotokoll ist das stärkste Argument, das Sie gegenüber einem Mitbewerber haben, der keines vorlegen wird.
Eine Organisation, die trägt
| Rhythmus | Was man tut |
|---|---|
| Jeden Morgen | Ein Blick auf das Dashboard, gefiltert auf die Auffälligkeiten |
| Jede Woche | Bearbeitung der schweigenden Rechner und der wiederkehrenden Warnungen |
| Jeden Monat | Durchsicht der Volumina, der Kontingente und des freien Plattenplatzes |
| Jedes Quartal | Eine Kontrollwiederherstellung, dokumentiert |
| Jedes Jahr | Durchsicht des Umfangs mit dem Kunden: was sich in seiner IT geändert hat |
Die letzte Zeile ist die, die sich auszahlt. Ein Kunde, der einen Server, eine Fachanwendung oder eine Freigabe hinzugefügt hat, ohne es Ihnen zu sagen, hat ein Loch in seinem Schutz — und es bei einer Durchsicht zu entdecken statt bei einem Schadensfall ist der Grund, weshalb man sein Dienstleister bleibt.
BeBackup wurde von einem IT-Dienstleister für den eigenen Bestand entworfen: Konsole über viele Kunden, je Rechner berechnete Warnungen über ausgebliebene Starts, feine Rechte und Berichte im White Label. Zur Dienstleisterseite oder eine Demo anfordern.