Share via

SharePoint Backup & Recovery - Von RTO, RPO und RLO zum fertigen Disaster Recovery Plan (1/2)

  • Article

SharePoint Adventskalender - 23. Türchen

Performance Tuning - Performance Monitoring - Best-Practices für SP-SQL-Konfigurationen - BLOB Management - Backup & Recovery

-------------------------------------------------------------

Backup kann jeder! Nur bei der Wiederherstelung aus einem Backup wird es interessant. Was alles berücksichtigt werden muss und Best Practices für Backup & Recovery Strategien möchte ich Ihnen in den letzten beiden Türchen unseres SharePoint Adventskalenders mitgeben. Wir schauen uns dafür folgende Kategorien an:

Heute: Service Level Agreement (SLA)

  • Verstehen von RTO, RPO und RLO
  • Komponenten und Backup-Umfang
  • Kapazitätsplanung

Morgen: Disaster Recovery Plan

  • Überwachung
  • Recovery Scenarios
  • Dokumentation

Verstehen von RTO, RPO und RLO:
Wenn wir mit SharePoint arbeiten als Kollaborationsportal arbeiten, so generieren wir darin viel Wissen (Intellectual Property – IP). Da immer mehr das IP den Wettbewerbsvorteil von Unternehmen definiert, muss es geschüzt und gesichert werden. Es sind aber häufig die selben Fragen, die mir bei Kunden begegnen:

  • Haben wir überhaupt ein Backup?
  • Wie lange brauchen wir, um ein einziges Objekt wieder herzustellen?
  • Erfüllen wir immer unsere SLAs?
  • Was ist unser Disaster Recovery Konzept?

All diese Fragen müssen in einem Disaster Recovery Plan beantwortet werden. Den Anfang machen die RTOs, RPOs und RLOs.

Recovery Time Objective (RTO):
Dies ist die Zeit, die benötigt wird, um alle Systeme nach einem Ausfall wieder zum Laufen zu bekommen. Darin fallen alle Verantwortlichkeiten und Prozesse, die durchlaufen werden müssen, um den letzten laufenden Zustand wieder herzustellen.

Recovery Point Objective (RPO):
Dies ist der maximal akzeptable Datenverlust und definiert damit, mit welcher Häufigkeit Backups durchgeführt werden müssen.

Addiert man die RTO und RPO, so erhalten wir die Zeitspanne, für die keine produktive Arbeit mit dem SharePoint möglich ist sowie bereits erledigte Arbeiten verloren gehen.

Recovery Level Objective (RLO) Diese Deifnition wird oft vergessen, aber sie ist eine ganz Entscheidende, da sie die RTO und RPO beeinflusst. Die RLO soll bestimmen, mit welchem Granularitätslevel gesichert und wieder hergestellt werden kann. Sollen beispielsweise auch alle Metadaten, Berechtigungen, Nutzerdaten, etc. gesichert werden, so macht dies den Datenbestand komplexer. Dadurch können sich wiederum die Backupzeiten verlängern und ich muss vielleicht meine Backup-Fenster – das RPO – erweitern. Je komplexer die Daten sind, desto schwieriger wird in der Regel auch die Wiederherstellung. Besonders bei einer Single-Item-Wiederherstellung ist meine RTO unverhältnismäßig groß mit nativen Mitteln.

Somit müssen wir einen geeigneten Konsens finden, der zunächst niedrige RTOs und RPOs ermöglicht, aber idealerweise auch eine kleine Granularität erlaubt. Nähere ich mich diesen Zielen an, so steigen leider die Kosten auf der anderen Seite. Und genau diese Kosten stellen die nächste Variable in unserem Hebel für ein Backup Konzept dar. Eine allgemeingültige Regel über RTO, RPO und RLO, die für alle Unternehmen anwendbar ist, gibt es leider nicht. Die müssen Sie für Ihr Unternehmensrichtlinien selbst bestimmen.

 

Komponenten und Backup-Umfang:

Ein sharePoint besteht nicht nur aus den Inhaltsdatenbanken. Weiterhin sind die Service Applications zu betrachten, Farm-Solutions, InfoPath Formulare, IIS Settings, BLOB Storage und vielleicht noch weitere Anpassungen und Komponenten, wie z.B. Microsoft Project. Exemeplarisch sehen Sie in der Abbilding links die Komponenten einer SharePoint 2013 Farm. Es wird also schnell deutlich, was Ihnen alles fehlt, wenn Sie nur auf die Inhaltsdatenbanken schauen. Dennoch wäre ein nahezu vollständiger Wiederaufbau der Farm nach einem Disaster prinzipiell möglich. Da wir dafür jedoch unzählige (manuelle) Schritte benötigen, läge die RTO weit außerhalb eines akzeptablen Niveaus.

Weiterhin bestehen bei der Wiederherstellung verschiedenste Abhängigkeiten. Einfaches Beispiel: es müssen Farm Solutions ausgerollt werden, bevor die Datenbanken wieder an die Web Application angehängt werden. Wir sehen also, wie komplex so eine Backup Strategie ist. Es gibt Drittanbieter-Lösungen, die Ihnen dabei viel abnehmen, weil sie automatisch verschiedenste Komponenten sichern und wiederherstellen können. Achten Sie dabei besonders darauf, ob diese Lösung SharePoint wirklich „versteht“. Beispielsweise würden wir mit einer Wiederherstellung der Konfigurationsdatenbank einen Zustand erschaffen, der unvorhersehbare Folgen hätte. Zudem würden wir den Support mit Microsoft verlieren. Das Data Protection Modul der Firma AvePoint ist beispielsweise so ein Produkt, dass SharePoint versteht und all die angesprochen Komponenten sichern und wiederherstellen kann. Die Microsoft Support Richtlinien werden dabei nicht verletzt.

Kapazitätsplanung:
Ein Backup von SharePoint benötigt Platz, aber die Speicherlaufwerke haben nur begrenzte Kapazitäten. Daher ist auch die Kapazitätsplanung ein wichtiger Bestandteil von SLAs im Rahmen eines Disaster Recovery Plans. Ist beispielsweise nicht mehr genügend Speicherplatz für ein neues Backup vorhanden, dann befinde ich mich sehr schnell außerhalb der definierten SLAs, weil das RPO nicht mehr eingehalten werden kann. Folgende Punkte müsse für die Kapazitätsplanung berücksichtigt werden:

  1. Wie sichere ich?
    • Full Backup (alles wird zum eingestellten Zeitpunkt gesichert)
    • Differential (nur Änderungen seit dem letzten Full oder Differential werden gesichert)
    • Incremental (nur Änderungen seit dem letzten Full, Differential oder Incremental werden gesichert)
  2. Wie häufig sichere ich?
    • Es ist wichtig zu klären, in welchen Zyklen ich sichere. Ein Zyklus zählt von einem Full Backup zum nächsten. Legen Sie also fest, wie häufig Full Backups durchgeführt werden sollen und welche Art Backups (DIFF oder INCR) Sie dazwischen nutzen möchten.
  3. Wie lange halte ich die Sicherungen vor?
    • Dies hängt von Ihren Unternehmensvorgaben ab, bis zu welchem Zeitpunkt in die Vergangenheit Sie in der Lage sein müssen, Daten wieder herzustellen. Muss es z.B. möglich sein, Dateien wieder auf einen Zustand von vor 45 Tagen zu bringen, dann müssen die dazugehörigen Backups auch mindestens 45 Tage aufbewahrt werden.
  4. Wie hoch ist die Änderungsrate meiner Inhalte?
    • Durchschnittlich kann angenommen werden, dass sich 10% meines Datenbestandes pro Woche ändert. Dies kann aber in Ihrem Szenario auch deutlich mehr oder weniger sein. Auch dies muss für die Kapazitätsplanung geklärt werden.

Basierend auf obigen Annahmen und Erfahrungen bei Kunden kann folgende Allgemein-Regel angwendet werden:

Benötigter Speicherplatz = 1,5 x D x Z + D

D: Datenbestand der gesamten Farm (inkl. Service Datenbanken, etc.)
Z: Anzahl der Backup-Zyklen, die vorgehalten werden sollen

Wenn Sie diese drei Kategorien von heute berherzigen und Sie auf Ihr Unternehmen anwenden, sind Sie bereits sehr gut aufgestellt für das Durchführen von Backups. Damit haben Sie die „halbe Miete“. Noch wichtiger ist jedoch der Wiederherstellungsfall. Dies muss ebenso Teil eines Disaster Recovery Plans sein, was wir uns morgen als finalen Abschluss des SharePoint Adventskalenders genauer anschauen werden.

Viel Spaß beim „SharePointen“!

-------------------------------------------------------------

Weitere Türchen: