Zwei Fragen an ein Backup
Lief die Sicherung? Und wo steht, dass sie laufen musste, wie lange aufbewahrt wird und ob jemand die Kopien noch ändern kann? Das sind zwei Fragen an zwei Adressaten. Was der Cohesity-Konnektor deshalb an zwei getrennte Stellen schreibt, und wo er bewusst gar nichts schreibt.
In einem Audit fragt selten jemand, ob das Backup gestern gelaufen ist. Gefragt wird, wo festgelegt ist, dass es laufen muss, wie lange die Kopien aufbewahrt werden und ob sie in dieser Zeit noch veränderbar sind. Das sind zwei verschiedene Fragen. Die erste ist Betrieb, die zweite ist Nachweis. Ein Backup-System kann beide beantworten, aber die Antworten gehören an verschiedene Stellen.
Genau so ist der Cohesity-Konnektor gebaut. Im Code heißen die beiden Wege Ebene A und Ebene B, und der Unterschied ist keine Kosmetik.
Ebene A: was tatsächlich gesichert wurde
Die geschützten Objekte aus dem Cluster landen als Backup-Status an den IT-Systemen, die es in der Bestandsführung schon gibt: die Objekt-Kennung, der Zeitpunkt der letzten Sicherung, das Ergebnis. Damit steht am System selbst, wann es zuletzt gesichert wurde, und nicht nur in einer Konsole daneben.
Ebene B: was gesichert werden soll
Aus jeder Protection Policy wird ein Backup-Plan im Notfallmanagement, mit Frequenz und Aufbewahrungsdauer. Ist im Cluster eine DataLock-Sperre gesetzt, kommt sie als WORM-Kennzeichen mit. Das ist die Angabe, nach der bei Ransomware-Fragen zuerst gesucht wird: ob die Kopien im Aufbewahrungszeitraum überhaupt noch überschrieben werden können.
Ein kleines Detail an dieser Stelle entscheidet, ob die Zahl später etwas wert ist. Die übernommene Aufbewahrungsdauer trägt ihre Herkunft im Text: „90 Tage (aus Cohesity Protection Policy)". Wer in zwei Jahren fragt, woher der Wert stammt, sieht es am Wert selbst, statt es zu rekonstruieren.
Interessanter ist, wo der Konnektor nichts tut
Drei Grenzen sind ausdrücklich gezogen, und sie sagen mehr über die Bauart als jede Funktionsliste.
Von Hand gepflegte Backup-Pläne werden nie angefasst. Der Abgleich greift ausschließlich auf Einträge, die als aus Cohesity stammend gekennzeichnet sind. Wer einen Plan selbst geschrieben hat, behält ihn, auch wenn im Cluster etwas Ähnliches existiert. Eine Synchronisation, die fremde Handarbeit überschreibt, wird genau einmal benutzt.
Neue IT-Systeme legt der Konnektor keine an. Geschützte Objekte sind meist virtuelle Maschinen und Datenbanken, und die würden die Bestandsführung mit reinen Backup-Objekten fluten. Findet sich kein passendes System, wird der Eintrag übersprungen. Das Anlegen bleibt dem Inventarisierungs-Scan, der dafür da ist.
Und wenn das Notfallmanagement gar nicht installiert ist, überspringt der Konnektor den Plan-Teil, statt den gesamten Abgleich abzubrechen. Der Betriebsteil läuft weiter. Eine fehlende Ausbaustufe ist kein Fehler.
Ergebnisse werden nicht neu geschrieben
Die einzelnen Sicherungsläufe kommen mit Start, Ende, Status und gelesenen wie geschriebenen Datenmengen herein. Ein bereits bekannter Lauf wird nicht erneut angelegt, denn ein abgeschlossener Lauf ist ein unveränderliches Ergebnis. Was einmal passiert ist, bleibt so stehen, wie es passiert ist. Für eine Nachweiskette ist das die halbe Miete.
Mehr auf der Seite zum Cohesity-Konnektor. Wohin die Backup-Pläne laufen, zeigt das Notfallmanagement.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.