Best Practices für Sicherungsrichtlinien

Wenn Sie diese Best Practices befolgen, können Sie einige der häufigsten Fehler vermeiden, die Nutzer beim Erstellen und Ändern von Richtlinienvorlagen machen.

Sie müssen die Richtlinienvorlagen entsprechend Ihren Recovery Point Objectives (RPOs) und Recovery Time Objectives (RTOs) konfigurieren. Im Laufe der Zeit werden Sie möglicherweise feststellen, dass Sie Änderungen an diesen Vorlagen vornehmen müssen.

Erste Datensicherung

Wenn eine Richtlinie in einer Richtlinienvorlage zum ersten Mal eine Sicherung der Daten einer Anwendung erstellt, werden die Daten vollständig gesichert. Nachfolgende Sicherungen sind inkrementell.

Wenn Sie mehrere Anwendungen mit einer Richtlinienvorlage schützen möchten, wenden Sie die Richtlinienvorlage nur auf einige der Anwendungen an. Nachdem die erste vollständige Datenerfassung abgeschlossen ist, wenden Sie die Richtlinienvorlage auf weitere Anwendungen an. Wiederholen Sie den Vorgang, bis die Richtlinienvorlage auf alle Anwendungen angewendet wurde.

Größe von Volumes anpassen

Wenn Sie die Größe eines Volumes ändern, das geschützte Daten enthält, wird bei einigen Anwendungstypen beim nächsten Ausführen der Snapshot-Richtlinie für dieses Volume möglicherweise eine vollständige Sicherung durchgeführt, unabhängig davon, wie oft die Daten dieses Volumes in der Vergangenheit gesichert wurden. Dazu gehören VMWare VMDKs, die neu dimensioniert wurden, sowie agentbasierte Sicherungen von Microsoft Windows- und Linux-Anwendungen, die sich nicht auf LVM befinden.

Wenn Sie die Größe eines Volumes für diese betroffenen Anwendungstypen ändern müssen, berücksichtigen Sie die Auswirkungen, die das Erfassen aller Daten auf die Anwendungsserver, das Netzwerk und die Sicherungs-/Wiederherstellungs-Appliance hat.

Jobnebenläufigkeit

Eine Sicherungs-/Wiederherstellungs-Appliance kann standardmäßig sechs Snapshot-Jobs gleichzeitig ausführen. Wenn für denselben Zeitraum mehr Jobs als die zulässige Anzahl geplant sind, startet der Richtlinien-Scheduler so viele Jobs wie zulässig und stellt die anderen Jobs in die Warteschlange.

Da sich das Netzwerkdesign, das Datenlayout und die Speicherklassen der einzelnen Nutzer unterscheiden, sollten Sie mit der Parallelverarbeitung experimentieren, bis die optimale Anzahl paralleler Jobs erreicht ist.

Richtlinienzeitpläne

In der Verwaltungskonsole gibt es zwei Methoden, um beim Konfigurieren einer Richtlinie einen Zeitplan anzugeben:

  • Fenster Hiermit wird ein diskreter Zeitplan für die Snapshot-Sicherung mit einer bestimmten Häufigkeit und einem bestimmten Zeitfenster definiert (z. B. alle 30 Minuten, täglich von 09:00 bis 17:00 Uhr UTC). Sie können die Sicherungs-/Wiederherstellungs-Appliance anweisen, mehrere Sicherungsjobs in einem bestimmten Häufigkeitsintervall oder einmal in einem bestimmten Zeitfenster auszuführen.
  • Kontinuierlich. Hiermit wird ein kontinuierlicher Snapshot-Sicherungszeitplan definiert, z. B. alle acht Stunden einen Sicherungsjob ausführen, beginnend mit dem ersten Job um 01:00 UTC. Bei diesem Richtlinienzeitplan werden Jobs im angegebenen Zeitintervall kontinuierlich (rund um die Uhr) ausgeführt.

Berechnung der Häufigkeit

Der Zeitraum ist die Zeit zwischen den geplanten Ausführungen und die Häufigkeit ist die Anzahl der Jobs, die pro Zeiteinheit ausgeführt werden. Wenn in einem Zeitplan beispielsweise festgelegt ist, dass Jobs alle 4 Stunden ausgeführt werden sollen, beträgt der Zeitraum 4 Stunden und die erwartete Häufigkeit ist 6-mal pro Tag. Wenn ein Job eine Stunde in Anspruch nimmt und die Richtlinie eine Häufigkeit von 12 Stunden hat, wird der Job der Richtlinie 11 Stunden nach Abschluss des vorherigen Jobs noch einmal ausgeführt.

Wählen Sie eine Häufigkeit aus, die die erforderlichen Recovery Point Objectives (RPOs) erfüllt und ausreichend Zeit für die Ausführung eines Jobs lässt.

  • Die empfohlene Mindesthäufigkeit für eine Snapshot-Richtlinie beträgt 1 Stunde (lokaler RPO).
  • Eine StreamSnap-Richtlinie kann auf eine beliebige Snapshot-Richtlinie mit einer Häufigkeit von mindestens einer Stunde verweisen (Remote-RPO).

Schutz von Datenbankprotokollen in einer Richtlinie für Sicherungspläne

Wenn Sie eine Snapshot-Richtlinie für eine Datenbank erstellen, haben Sie die Möglichkeit, auch die Protokolldateien mit einer bestimmten Häufigkeit zu erfassen. Die Häufigkeit, mit der Datenbankprotokolle erfasst werden, wird unabhängig von der Datenbank definiert. Beispielsweise kann eine Datenbank jeden Tag und die zugehörigen Protokolle jede Stunde erfasst werden.

Die Häufigkeit der Datenbankprotokollsicherung wird in Minuten festgelegt. Die Häufigkeit, mit der Protokolle erfasst werden, darf nicht höher sein als die Häufigkeit, mit der die zugehörige Datenbank erfasst wird. Wenn die Erfassungshäufigkeit einer Datenbank beispielsweise alle 24 Stunden erfolgt, muss die Erfassungshäufigkeit der Protokolldatei kürzer als 24 Stunden sein.

Häufigkeit und Aufbewahrung werden in den erweiterten Einstellungen der Snapshot-Richtlinie der Datenbank definiert. Die Erfassung von Protokollen erfolgt unabhängig von Tagesgrenzen, Zeitfenstern oder der Häufigkeit, mit der die zugehörige Datenbank erfasst wird.

Sie aktivieren die Funktion „Protokollschutz“ über die erweiterten Einstellungen Datenbankprotokollsicherung aktivieren in einer Snapshot-Richtlinie für einen Sicherungsplan. Häufigkeit und Aufbewahrungsdauer werden auch in den erweiterten Einstellungen für eine Sicherungsplanrichtlinie definiert.

Der physische Speicherplatz, der für die Datenbankprotokolle erforderlich ist, wird automatisch von der Verwaltungskonsole verwaltet. In der Admin-Konsole werden mindestens die typischen Protokollgrößen und ihre Aufbewahrungsdauer ausgewertet und bei Bedarf Speicherplatz hinzugefügt.

In dieser Tabelle finden Sie Informationen zum Aktivieren der Protokollsicherung und zur effizienteren Verwaltung der Speicheranforderungen für Datenbankprotokolle.

Einstellung Eingabe
Protokoll nach der Sicherung kürzen oder löschen Muss auf „Ja“ gesetzt werden, um das Produktionsprotokoll zu löschen. Wählen Sie diese Option aus, um das Löschen von Protokollen zu verwalten. Dadurch wird am Ende jeder Protokollsicherung die Protokollbereinigung ausgeführt. Die Standardeinstellung ist „Nicht abschneiden“.

Wenn für eine Richtlinie Datenbankprotokollsicherung aktivieren auf Nein und Protokoll nach Sicherung kürzen oder löschen auf Ja festgelegt ist, wird am Ende jeder Datenbanksicherung eine Protokollbereinigung ausgeführt, bei der alle Protokolle gelöscht werden.
Aufbewahrungsdauer für Protokollsicherungen Die Protokollsicherung auf dem Staging-Laufwerk für Sicherung und Notfallwiederherstellung wird gemäß dem hier festgelegten Wert aufbewahrt. Die Aufbewahrungsdauer von Sicherungsprotokollen kann von der Aufbewahrungsdauer von Snapshots abweichen.
Größe des Staging-Laufwerks für Protokolle Legen Sie einen Prozentsatz fest, um bei Bedarf das Staging-Laufwerk für die Protokollsicherung zu vergrößern.
Geschätzte Änderungsrate Schätzen Sie den Prozentsatz, um den sich die Datenbankdaten täglich ändern.
Datenbankprotokollsicherung komprimieren Hiermit können Sie die Sicherung von Datenbankprotokollen mit der Datenbank-API auf App-Ebene im Komprimierungsmodus ausführen.
Datenbankprotokollsicherung aktivieren Mit der Option Datenbankprotokollsicherung aktivieren kann die Sicherungsrichtlinie eine Datenbank und alle zugehörigen Protokolldateien sichern. Die Protokolle werden gesichert, wenn der Job zum Sichern von Protokollen ausgeführt wird. Die Optionen sind Ja oder Nein. Wenn „Ja“ ausgewählt ist, werden die zugehörigen Optionen aktiviert.
RPO Wenn „Datenbankprotokollsicherung aktivieren“ auf „Ja“ gesetzt ist, wird die Häufigkeit der Datenbankprotokollsicherung durch RPO definiert. Die Häufigkeit wird in Minuten angegeben und darf das Intervall für die Datenbanksicherung nicht überschreiten.
Protokolle replizieren (Verwendet die StreamSnap-Technologie) Wenn „Datenbankprotokollsicherung aktivieren“ auf „Aktivieren“ gesetzt ist, können mit der erweiterten Einstellung „Protokolle replizieren“ Datenbankprotokollsicherungen auf eine Remote-Sicherungs-/Wiederherstellungs-Appliance repliziert werden. Damit ein Job zum Replizieren von Protokollsicherungen ausgeführt werden kann, muss die Vorlage eine StreamSnap-Replikationsrichtlinie sowie ein Ressourcenprofil enthalten, das eine Remote-Sicherungs-/Wiederherstellungsanwendung angibt. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen worden sein. Sie können die Protokollsicherung dann an der Remote-Site für jedes Datenbank-Image innerhalb des Aufbewahrungszeitraums der replizierten Protokollsicherung verwenden. Diese Funktion ist standardmäßig aktiviert.

Bei der Protokollreplikation wird die Replikation zwischen der lokalen und der Remote-Sicherungs-/Wiederherstellungs-Appliance mit der StreamSnap-Technologie durchgeführt. Die Protokollreplikation erfolgt direkt vom lokalen Snapshot-Pool zum Snapshot-Pool auf der Remote-Appliance.

Hinweis: Die Protokollreplikation erfolgt erst, wenn die Datenbank geschützt und das Sicherungs-Image der Datenbank auf die Remote-Sicherungs-/Wiederherstellungs-Appliance repliziert wurde.
Logs an den OnVault-Pool senden Wenn Sie „Ja“ auswählen, werden Protokolle in einem oder mehreren OnVault-Speicherpools repliziert, sodass Point-in-Time-Wiederherstellungen aus einem OnVault-Pool an einem anderen Standort möglich sind.

Jobpriorität und -planung

Alle Aktivitäten werden als Jobs ausgeführt. Jobs werden gemäß den Zeitplänen ausgeführt, die beim Erstellen der Richtlinien konfiguriert wurden.

Manche Jobs dauern viel länger als andere. Ablaufjobs sind schnell. Snapshot-Jobs hängen von Variablen wie der Größe der Anwendung oder VM und davon ab, wie viele Daten sich seit dem letzten Snapshot geändert haben. Der erste Snapshot einer Anwendung oder VM enthält nur neue Daten, sodass dies sehr lange dauern kann.

Der Richtlinienplaner ermittelt, wann eine oder mehrere auf Anwendungen angewendete Richtlinien ausgeführt werden sollen, und startet dann einen Job, der die Richtlinie in eine Warteschlange stellt, wenn die geplante Startzeit erreicht wird. Für jeden Richtlinientyp gibt es einen Taktmechanismus, der dafür sorgt, dass das System nicht durch ausgeführte Jobs überlastet wird. Bei diesem Taktmechanismus werden Job-Slots verwendet, um diesen stabilen Zustand zu erreichen. Das bedeutet, dass ein Job auch dann erst ausgeführt wird, wenn ein Job-Slot verfügbar ist, selbst wenn er zu einer bestimmten Zeit gestartet werden soll.

Wenn mehrere Anwendungen zur gleichen Zeit mit derselben Jobpriorität geplant sind, wird die auszuführende Anwendung zufällig ausgewählt, um für alle Anwendungen mit derselben Priorität Fairness zu gewährleisten.

Jobwiederholungen

Wenn ein Job fehlschlägt, versucht der Planer automatisch, den Job noch einmal auszuführen. Wenn der Job zum ersten Mal fehlschlägt, wartet der Scheduler 4 Minuten, bevor er ihn für einen neuen Versuch verfügbar macht. Nach drei fehlgeschlagenen Jobversuchen wird der Job als fehlgeschlagen markiert und nicht mehr wiederholt. Der nächste Job wird gemäß dem Zeitplan der Richtlinie ausgeführt.

Der Scheduler behandelt einen Job-Wiederholungsversuch wie jeden anderen verfügbaren Job. Wenn mehr Jobs verfügbar sind als Slots, werden Jobs in die Warteschlange gestellt. Dies kann dazu führen, dass ein erneuter Versuch nicht innerhalb des Zeitfensters gestartet wird und der Job als fehlgeschlagen markiert wird.

Jobwiederholungen werden im Monitor erfasst. Um Jobwiederholungen zu identifizieren, hängt der Monitor dem Namen jedes Jobs, der wiederholt wird, zuerst „a“, dann „b“ und schließlich „c“ an.

Nächste Schritte