SharePoint Backup & Recovery – Von RTO, RPO und RLO zum fertigen Desaster Recovery Plan (2/2)

SharePoint Adventskalender – 24. Türchen

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

————————————————————-

Im zweiten Teil zu unserem Disaster Recovery Plan geht es um

• Überwachung
• Recovery Szenarios
• Dokumentation

Überwachung:
Sind unsere regelmäßigen Backup-Pläne in Abstimmung auf die Unternehmens-SLAs eingerichtet und der benötigte Speicherplatz für die Backupdaten vorbereitet, so kann es nun losgehen. Es würde mich überraschen, wenn alles von Anfang an problemlos läuft.

Es können zum Besipiel plötzlich Ports geschlossen werden oder Datenbanken sind hinzu gekommen oder neue Lösungen wurden ausgerollt etc. Dies müssen wir für die Backup Jobs genau im Auge behalten und gegebenenfalls nachbessern. Denn ein fehlgeschlagenes Backup ist ebenso nutzlos, wie ein erfolgreiches, dass aber entscheidende Komponenten für eine Wiederherstellung nicht berücksichtigt hat. Auch das gestern angesprochene Szenario mit dem mangelnden Backupspeicherplatz führt mich ganz schnell an die Grenzen meiner SLAs. Überwachen Sie daher sehr genau alle Komponenten Ihres Backups und greifen Sie gegebenenfalls pro-aktiv ein.

Recovery Szenarios:
Angenommen, alle Backup Pläne werden stets erfolgreich ausgeführt, sodass wir sichere Backupdaten haben. Was passiert, wenn der Ernstfall eintritt? Wissen Sie sicher, dass die Wiederherstellung aus den Backupdaten reibungslos funktioniert? Wie lange dauert es? Reicht die Zeit aus, um meine RTO einzuhalten?

Um diese Fragen beantworten zu können, müssen Sie sich realistische Wiederherstellungsszenarien schaffen, die Sie auch in regelmäßigen Abständen testen. Ganz wichtig sind dafür standardisierte Prozesse und Verantwortlichkeiten. Beispielhaft möchte ich folgende Szenarien vorschlagen:

1. Monatliche Tests:

• Dokument / Listenelement
• Spalte einer Liste / Dokumentbibliothek
• Komplette Liste / Dokumentbibliothek
• Komplette SharePoint Site (SubSite)
• Eine gesamte Inhaltsdatenbank

• Quartalstests:
• Gesamte Web Application (inkl. Datenbanken, IIS, Authentifizierung, etc.)
• Service Applications (z.B. Search, UPA, MMS, etc.)

• Halbjährliche Tests:
• Web Front End Server
• Application Server
• Index Server

• Jährliche Tests:
• Komplettes Desaster Recovery

Dokumentation:
Dieser Teil ist mit Sicherheit am unbeliebtesten, aber der wichtigste. Denn was bringen all die Bemühungen zuvor, wenn im Ernstfall niemand weiß, wer verantwortlich ist, weil der Administrator krank oder im Urlaub ist, welche Skripte oder Aktionen in welcher Reihenfolge auszuführen sind und was die Endbenutzer erwarten dürfen.

Eine klare Dokumentation – so aufwendig sie auch ist – nimmt diese Ängste und soll im Ernstfall das Handbuch sein, in dem die Antworten auf alle Wiederherstellungsfragen stehen. Im perfektesten Fall sollte man so einen Disaster Recovery Plan einem unbeteiligten in die Hand geben können und dieser weiß dann, was zu tun ist – auch wenn der Administrator im Urlaub ist. Innerhalb der Dokumentation müssen dafür klare und messbare Ziele definiert werden.

Nachfolgend ein paar Vorschläge, was zu den gestern und weiter oben erwähnten Punkten noch Teil eines Disaster Recovery Plans sein sollte:

1. Stakeholder:
   1. Für welche Personen im Unternehmen hat das Dokument Relevanz
   2. Dies können Kunden, Endnutzer, Administratoren und auch das Management sein
2. Aktueller Status:

• Aktuelle Farm Topologie
• Eingespielte Anpassungen und Einstellungen
• Abhängigkeiten

• Richtlinien:
• RTO (in Abhänigkeit der RLO, denn eine Single-Item-Wiederherstellung kann schneller gehen, als ein komplettes Disaster Recovery)
• RPO
• RLO
• SLA

• Verantwortlichkeiten (SharePoint, SQL, Plattform, AD, Netzwerk, etc.):
• Für Backup Pläne
• Für Wiederherstellung

• Backup Strategien:
• Was ist alles Bestandteil (Scope) von konfigurierten Backup-Plänen
• Für welche Komponenten werden native Werkzeuge, für welche Drittanbieter verwendet

• Wiederherstellungsprozesse:
• In welchen Szenarien soll die gesamte Farm wieder hergestellt werden
• In welchen Szenarien ist eine Single-Item-Wiederherstellung zu verwenden
• Für welches Szenario werden native, wann werden Drittanbieterlösungen verwendet
• Schritt-für-Schritt Anleitungen für die wiederherstellung der einzelnen Komponenten
• Gegebenenfalls Skripte und Konfigurationen

• Regelmäßige Tests:
• Idealerweise durchzuführen von Mitarbeitern, die nicht hauptverantwortlich sind und auch nicht den DR-Plan geschrieben haben – so können zusätzlich Ungenauigkeiten aufgedeckt werden
• Festzuhalten sind:
  • Szenario
  • Zeitpunkt
  • Benötigte Zeit
  • Testergebnis
  • Kommentar

Und das wichtigste zum Schluss:

Ein Disaster Recovery Plan mit all den gestern und heute vorgestellten Komponenten ist ein “lebendes Dokument”! Genauso, wie sich Infrastrukturen, Backup- und Test-Szenarien sowie Ansprechpartner ändern, muss sich auch der DR-Plan anpassen, um stets auf dem aktuellen Stand zu sein. Wenn Sie all diese Tipps beherzigen, dann wird Ihnen ein Disaster Recovery keine Kopfschmerzen oder schlaflosen Nächte mehr bescheren.

Apro pros „bescheren“: Ich wünsche allen ein besinnliches Fest im Kreise Ihrer Liebsten, mit lecker Essen, vielen Geschenken und schönen Momenten auch mal ganz ohne SharePoint! 🙂

————————————————————-

Weitere Türchen:

• 1. Türchen: SharePoint Performance Tuning – Cluster Größe der SQL Festplatten
• 2. Türchen: SharePoint Performance Tuning – SQL Speicherzuweisung
• 3. Türchen: SharePoint Performance Tuning – SQL MAXDOP
• 4. Türchen: SharePoint Performance Tuning – SQL AutoGrowth-Einstellungen
• 5. Türchen: SharePoint Performance Tuning – SQL Datenbanken vor konfigurieren
• 6. Türchen: SharePoint Performance Tuning – SQL TempDB Einstellungen
• 7. Türchen: SharePoint Performance Tuning – Der Papierkorb
• 8. Türchen: SharePoint Performance Tuning – Warm Up Skripte
• 9. Türchen: SharePoint Performance Monitoring – Performance Counter für den Prozessor
• 10. Türchen: SharePoint Performance Monitoring – Performance Counter für Speicherlaufwerke
• 11. Türchen: SharePoint Performance Monitoring – Performance Counter für den Arbeitsspeicher
• 12. Türchen: SharePoint Performance Monitoring – Performance Counter für System und Netzwerk
• 13. Türchen: SharePoint Configuration Best Practices – SQL Alias
• 14. Türchen: SharePoint Configuration Best Practices – Benamte SQL Instanzen und dedizierte Ports
• 15. Türchen: SharePoint Configuration Best Practices – Super User und Super Reader
• 16. Türchen: SharePoint Configuration Best Practices – Distributed Cache Service
• 17. Türchen: SharePoint Configuration Best Practices – Request Management Service
• 18. Türchen: SharePoint BLOB Management – BLOB Cache
• 19. Türchen: SharePoint BLOB Management – BLOB Storage (EBS und RBS)
• 20. Türchen: SharePoint BLOB Management – Shredded Storage
• 21. Türchen: SharePoint BLOB Management – Shredded Storage und RBS “Better Together”
• 22. Türchen: SharePoint BLOB Management – Archivierung
• 23. Türchen: SharePoint Backup & Recovery – Von RTO, RPO und RLO zum fertigen Disaster Recovery Plan (1/2)
• 24. Türchen: SharePoint Backup & Recovery – Von RTO, RPO und RLO zum fertigen Desaster Recovery Plan (2/2)