Willkommen, Leser unseres Blogs! Wir kennen uns teilweise bereits – meine englischsprachigen Beiträge wurden hier von meiner lieben Kollegin übersetzt. . Diesmal wollte ich direkt die russischsprachige Öffentlichkeit ansprechen.
Für mein Debüt wollte ich ein Thema finden, das für ein möglichst breites Publikum interessant ist und einer detaillierten Betrachtung bedarf. Daniel Defoe behauptete, dass jedem Menschen der Tod und die Steuern bevorstehen. Von meiner Seite kann ich sagen, dass jedem Support-Techniker Fragen zu den Richtlinien für die Aufbewahrung von Wiederherstellungspunkten (oder einfacher gesagt – Retention) bevorstehen. Wie Retention funktioniert, begann ich vor 4 Jahren zu erklären, als ich ein Junior Level 1 Engineer war, und ich erkläre es weiterhin jetzt, da ich Teamleiter für das spanisch- und italienischsprachige Team bin. Ich bin mir sicher, dass auch meine Kollegen aus dem zweiten und sogar dritten Support-Level regelmäßig die gleichen Fragen beantworten.
In diesem Zusammenhang wollte ich einen abschließenden, möglichst detaillierten Beitrag schreiben, auf den sich russischsprachige Nutzer immer wieder als Nachschlagewerk zurückziehen können. Der Zeitpunkt ist passend – die kürzlich veröffentlichte zehnte Jubiläums-Version hat neue Möglichkeiten zum grundlegenden Funktionsumfang hinzugefügt, der über Jahre hinweg unverändert blieb. Mein Beitrag konzentriert sich in erster Linie auf diese Version – obwohl ein Großteil des Geschriebenen auch für frühere Versionen zutrifft, werden Sie einige der beschriebenen Funktionen dort einfach nicht finden. Schließlich, mit einem Blick in die Zukunft, möchte ich erwähnen, dass in der nächsten Version einige Änderungen zu erwarten sind, aber darüber werden wir sprechen, wenn die Zeit gekommen ist. Lassen Sie uns also beginnen.
Backup-Job
Lassen Sie uns zunächst den Teil betrachten, der in Version 10 unverändert geblieben ist. Die Aufbewahrungspolitik wird durch mehrere Parameter bestimmt. Öffnen Sie das Fenster zur Erstellung eines neuen Auftrags und wechseln Sie zur Registerkarte Speicher. Hier sehen wir den Parameter, der die gewünschte Anzahl von Wiederherstellungspunkten festlegt:
Das ist jedoch nur ein Teil des Gesamtbildes. Die tatsächliche Anzahl der Wiederherstellungspunkte wird auch durch den für den Auftrag festgelegten Sicherungsmodus bestimmt. Um diese Einstellung auszuwählen, klicken Sie auf die Schaltfläche "Erweitert" im selben Tab. Dadurch öffnet sich ein neues Fenster mit vielen Optionen. Lassen Sie uns diese nummerieren und nacheinander betrachten:
Wenn Sie nur Option 1 aktivieren, arbeitet der Auftrag im "unendlich inkrementellen" Modus (forever forward incremental). Hier gibt es keine Komplikationen – der Auftrag speichert die festgelegte Anzahl von Wiederherstellungspunkten vom vollständigen Backup (Datei mit der Erweiterung VBK) bis zum letzten Inkrement (Datei mit der Erweiterung VIB). Wenn die Anzahl der Punkte den festgelegten Wert überschreitet, wird das älteste Inkrement mit dem vollständigen Backup zusammengeführt. Anders ausgedrückt, wenn der Auftrag eingestellt ist, 3 Punkte zu speichern, gibt es nach der nächsten Sitzung im Repository 4 Punkte, nach denen das vollständige Backup mit dem ältesten Inkrement zusammengeführt wird, sodass die Gesamtzahl der Punkte wieder auf 3 zurückgeht.
Die Handhabung der Aufbewahrung für den "reverse incremental" Modus (Option 2) ist ebenso einfach. In diesem Fall wird der neueste Punkt ein vollständiges Backup sein, gefolgt von einer Kette von sogenannten Rollbacks (Dateien mit der Endung VRB). Um die Aufbewahrung anzuwenden, reicht es aus, einfach das älteste Backup zu löschen. Die Situation bleibt gleich: Unmittelbar nach der Sitzung wird die Anzahl der Punkte um 1 über dem festgelegten Wert liegen, bevor sie wieder auf den gewünschten Wert zurückkehrt.
Bitte beachten Sie, dass im reverse-incremental Modus auch ein periodisches vollständiges Backup (Option 4) aktiviert werden kann, was jedoch nichts an der Sache ändert. Ja, es werden vollständige Wiederherstellungspunkte in der Kette vorhanden sein, aber wir werden auch weiterhin die ältesten Punkte einzeln löschen.
Nun kommen wir zu einem interessanten Teil. Wenn Sie ein inkrementelles Backup aktivieren und zusätzlich die Optionen 3 oder 4 (oder auch beide gleichzeitig) einschalten, beginnt der Auftrag, regelmäßige vollständige Backups entweder "aktiv" oder mit der synthetischen Methode zu erstellen. Die Methode zur Erstellung des vollständigen Backups ist unwichtig – es wird dieselben Daten enthalten, und die inkrementelle Kette wird in "Unterketten" aufgeteilt. Diese Methode nennt man forward incremental und sie wirft eine beträchtliche Anzahl von Fragen bei unseren Kunden auf.
Retention wird hier durch die Löschung des ältesten Teils der Kette (vom vollständigen Backup bis zum Inkrement) angewendet. Dabei löschen wir nicht nur das leere Backup oder nur Teile der Inkremente. Die gesamte "Unterkette" wird auf einmal vollständig gelöscht. Auch der Sinn der Einstellung der Anzahl der Punkte ändert sich – während es bei anderen Methoden die maximal zulässige Anzahl ist, nach der eine Retention angewendet werden muss, bestimmt diese Einstellung hier die minimale Anzahl. Mit anderen Worten, nachdem die älteste "Unterkette" gelöscht wurde, sollte die Anzahl der Punkte im verbleibenden Teil nicht unter dieses Minimum fallen.
Ich werde versuchen, dieses Konzept grafisch darzustellen. Angenommen, der Retention-Wert ist auf 3 Punkte gesetzt, und der Task läuft jeden Tag mit einem vollständigen Backup am Montag. In diesem Fall wird die Retention angewendet, wenn die Gesamtanzahl der Punkte 10 erreicht.
Warum gerade 10, wenn nur 3 gesetzt wurden? Am Montag wurde ein vollständiges Backup erstellt. Von Dienstag bis Sonntag hat der Task Inkremente erstellt. Schließlich wird am nächsten Montag erneut ein vollständiges Backup erstellt, und erst wenn 2 Inkremente erstellt wurden, kann der gesamte alte Teil der Kette gelöscht werden, da die verbleibende Anzahl an Punkten nicht unter die festgelegten 3 fallen wird.
Wenn das Konzept klar ist, schlage ich vor, dass Sie versuchen, die Retention selbst zu berechnen. Nehmen wir folgende Bedingungen an: Der Task wird zum ersten Mal am Donnerstag gestartet (selbstverständlich wird ein vollständiges Backup erstellt). Der Task ist auf die Erstellung vollständiger Backups jeden Mittwoch und Sonntag eingestellt und soll 8 Wiederherstellungspunkte speichern. Wann wird die Retention zum ersten Mal angewendet?
Um diese Frage zu beantworten, empfehle ich Ihnen, ein Blatt Papier zu nehmen, es nach Wochentagen zu unterteilen und aufzuschreiben, welcher Punkt an welchem Tag erstellt wird. Die Antwort wird offensichtlich sein.
Antwort
Erläuterung: Um die Frage zu beantworten, genügt es, sich zu fragen, „wann wird die Retention angewendet?“ Die Antwort lautet: wenn wir die ersten 3 Punkte (VBK, VIB, VIB) entfernen können und die restliche Kette nicht unter 8 Punkte fällt. Es wird klar, dass wir dies tun können, wenn wir insgesamt 11 Punkte haben, also am Sonntag der zweiten Woche.
Einige Leser könnten einwenden: „Warum das alles, wenn es ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Schließlich haben wir die Option „Vorherige Sicherungsketten in Rollbacks umwandeln“ (mit der Nummer 5 gekennzeichnet) noch nicht besprochen. Diese Option verwirrt manchmal Kunden, die sie automatisch aktivieren, weil sie einfach ein synthetisches Backup einschalten möchten. Tatsächlich aktiviert diese Option jedoch einen ganz besonderen Backup-Modus. Ohne ins Detail zu gehen, möchte ich sofort klarstellen, dass die Funktion „Vorherige Sicherungsketten in Rollbacks umwandeln“ in der aktuellen Produktentwicklung als veraltet gilt und ich kein Szenario finde, in dem sie sinnvoll wäre. Ihr Wert ist so fragwürdig, dass Anton Gostev eine Zeit lang über das Forum nach Beispielen für ihre nützliche Nutzung fragte (wenn Sie welche haben, lassen Sie es mich in den Kommentaren wissen, ich bin sehr interessiert). Wenn es keine findet (ich denke, das wird so sein), wird die Option in zukünftigen Versionen entfernt.
Der Task erstellt Inkremente (VIB) bis zu dem Tag, an dem ein synthetisches vollständiges Backup geplant ist. An diesem Tag wird tatsächlich eine VBK erstellt, aber alle Punkte bis zu diesem VBK werden in Rollbacks (VRB) umgewandelt. Danach wird der Task weiterhin Inkremente für das vollständige Backup bis zum nächsten synthetischen Backup erstellen. Am Ende entsteht eine Mischung aus VBK-, VBR- und VIB-Dateien. Die Aufbewahrungsrichtlinie wird ganz einfach durch das Löschen des letzten VBR angewendet:
Die Probleme
Neben dem grundlegenden Verständnis, wie das funktioniert, hängen die meisten Probleme, die beim Einsatz des inkrementellen Modus auftreten, in der Regel mit dem vollständigen Backup zusammen. Ein regelmäßiges vollständiges Backup ist für diesen Modus notwendig, andernfalls wird das Repository Punkte anhäufen, bis es überläuft.
Ein vollständiges Backup könnte beispielsweise zu selten erstellt werden. Angenommen, die Aufgabe ist eingerichtet, um 10 Punkte zu speichern, während ein vollständiges Backup nur einmal im Monat erstellt wird. Es ist offensichtlich, dass die tatsächliche Anzahl der Punkte hier deutlich höher sein wird als die Vorgabe. Oder die Aufgabe ist sogar so konfiguriert, dass sie im unendlich inkrementellen Modus arbeitet und 50 Punkte speichert. Wenn dann jemand versehentlich ein vollständiges Backup erstellt, wird die Aufgabe fortan warten, bis der vollständige Punkt 49 Inkremente angesammelt hat, bevor die Retention angewendet wird und sie in den unendlich vollen Modus zurückkehrt.
In anderen Fällen wird ein vollständiges Backup regelmäßig erstellt, aber aus irgendeinem Grund funktioniert das nicht. Hier beschreibe ich die häufigste Ursache. Einige Kunden ziehen es vor, die Option „run after“ zu nutzen und die Aufträge in einer Kette zu konfigurieren. Nehmen wir folgendes Beispiel: Es gibt 3 Aufträge, die jeden Tag laufen und am Sonntag ein vollständiges Backup erstellen. Der erste Auftrag beginnt um 22:30 Uhr, die anderen starten in der Kette. Das inkrementelle Backup dauert 10 Minuten, sodass um 23:00 Uhr alle Aufträge abgeschlossen sind. Das vollständige Backup hingegen benötigt eine Stunde, weshalb am Sonntag Folgendes passiert: Der erste Auftrag läuft von 22:30 bis 23:30 Uhr. Der nächste von 23:30 bis 00:30 Uhr. Der dritte Auftrag startet erst am Montag. Das vollständige Backup ist für den Sonntag eingestellt, weshalb es in diesem Fall schlichtweg nicht stattfinden wird. Der Auftrag wird auf das vollständige Backup warten, um die Retention anzuwenden. Seien Sie also vorsichtig bei der Verwendung der Option „run after“ oder vermeiden Sie sie ganz – stellen Sie einfach sicher, dass die Aufträge zur gleichen Zeit starten und lassen Sie den Ressourcenplaner seine Arbeit machen.
Die komplexe Option „Entfernen gelöschter Elemente“
Wenn Sie zu den Einstellungen des Auftrags Speicher – Erweitert – Wartung navigieren, stoßen Sie auf die Option „gelöschte Elemente nach“ zu entfernen, die in Tagen gemessen wird.
Einige Kunden erwarten, dass dies die Aufbewahrung ist. In Wirklichkeit handelt es sich um eine völlig separate Option, deren Unverständnis zu unerwarteten Konsequenzen führen kann. Zunächst muss jedoch erklärt werden, wie B&R auf Situationen reagiert, wenn während einer Sitzung nur einige Maschinen erfolgreich gesichert werden.
Stellen Sie sich folgendes Szenario vor: ein unendlich inkrementelles Auftragsprofil, das 6 Punkte speichern soll. Im Auftragsprofil befinden sich 2 Maschinen, eine davon wird immer erfolgreich gesichert, die andere weist gelegentlich Fehler auf. Infolgedessen ergibt sich bei der siebten Sicherungssitzung folgende Situation:
Es ist Zeit, die Aufbewahrung anzuwenden, aber bei einer Maschine gibt es 7 Punkte, während die andere nur 4 hat. Wird hier die Aufbewahrung angewendet? Die Antwort lautet – ja, wird sie. Wenn auch nur ein Objekt gesichert wurde, betrachtet B&R, dass der Punkt erstellt wurde.
Eine ähnliche Situation kann auftreten, wenn eine Maschine während einer bestimmten Sitzung nicht in den Auftrag einbezogen wurde. Dies passiert beispielsweise, wenn Maschinen nicht einzeln, sondern in Containern (Ordnern, Speicher) hinzugefügt werden und eine Maschine vorübergehend in einen anderen Container migriert. In einem solchen Fall wird der Auftrag als erfolgreich betrachtet, aber in der Statistik finden Sie eine Nachricht, die darauf hinweist, dass eine bestimmte Maschine nicht mehr vom Auftrag verarbeitet wird.
Was passiert, wenn man darauf keine Rücksicht nimmt? Bei unendlich-incrementalen oder rückwärts-incrementalen Modus wird die Anzahl der Wiederherstellungspunkte der „problematischen“ Maschine mit jeder Sitzung abnehmen, bis sie 1 erreicht, die in der VBK gespeichert ist. Mit anderen Worten, selbst wenn die Maschine lange Zeit nicht gesichert wird, bleibt immerhin ein Wiederherstellungspunkt erhalten. Anders verhält es sich, wenn vollständige periodische Backups aktiviert sind. Wenn man die Signale von B&R ignoriert, kann letztendlich der letzte Punkt zusammen mit dem alten Teil der Kette gelöscht werden.
Nachdem diese Details geklärt sind, können wir endlich die Option „Daten gelöschter Elemente nach dem Löschen entfernen“ in Betracht ziehen. Diese Option entfernt alle Punkte für eine bestimmte Maschine, wenn diese Maschine innerhalb von X Tagen nicht gesichert wird. Beachten Sie, dass diese Einstellung nicht auf Fehler reagiert (Versucht – hat nicht funktioniert). Es sollte nicht einmal ein Versuch zur Sicherung der Maschine unternommen werden. Man könnte meinen, diese Option sei nützlich und sollte immer aktiviert sein. Wenn der Administrator die Maschine aus dem Auftrag entfernt hat, ist es logisch, nach einer gewissen Zeit die unnötigen Daten und die Kette zu bereinigen. Allerdings erfordert die Einstellung Disziplin und Aufmerksamkeit.
Ich gebe ein praktisches Beispiel: In den Aufgaben wurden mehrere Container hinzugefügt, deren Zusammensetzung recht dynamisch war. Aufgrund des fehlenden Arbeitsspeichers hatte der B&R-Server Probleme, die unbemerkt blieben. Die Aufgabe wurde gestartet und versuchte, Backups der Maschinen zu erstellen, mit Ausnahme einer, die zu diesem Zeitpunkt nicht im Container vorhanden war. Da viele Maschinen Fehler ausgaben, sollte B&R standardmäßig 3 zusätzliche Versuche unternehmen, um die "problematischen" Maschinen zu sichern. Wegen der ständigen Probleme mit dem Arbeitsspeicher zogen sich diese Versuche über mehrere Tage. Ein weiterer Versuch, das Backup der fehlenden VM zu erstellen, fand nicht statt (das Fehlen der VM ist kein Fehler). Schließlich wurde während eines der Wiederholungsversuche die Bedingung "Gelöschte Elemente entfernen" ausgeführt und alle Punkte der Maschine wurden gelöscht.
Dazu kann ich Folgendes sagen: Wenn Sie Benachrichtigungen über die Ergebnisse der Aufgaben eingerichtet haben, und noch besser – die Integration mit Veeam ONE verwenden, dann wird Ihnen so etwas höchstwahrscheinlich nicht passieren. Wenn Sie jedoch einmal pro Woche auf den B&R-Server schauen, um zu überprüfen, ob alles funktioniert, sollten Sie besser auf Optionen verzichten, die potenziell zu einer Löschung von Backups führen könnten.
Was in v.10 neu hinzugekommen ist
Das, worüber wir zuvor gesprochen haben, gab es in B&R über viele Versionen hinweg. Nachdem wir diese Funktionsprinzipien verstanden haben, schauen wir uns nun an, was in der Jubiläumsausgabe „Zehn“ hinzugekommen ist.
Tägliche Aufbewahrung
Oben haben wir die „klassische“ Aufbewahrungsrichtlinie betrachtet, die auf der Anzahl der Wiederherstellungspunkte basiert. Ein alternativer Ansatz besteht darin, im selben Menü „Tage“ anstelle von „Wiederherstellungspunkten“ anzuzeigen.
Die Idee ist aus dem Namen klar – die Retention wird eine festgelegte Anzahl von Tagen aufbewahren, wobei die Anzahl der Punkte pro Tag keine Rolle spielt. Dabei muss Folgendes beachtet werden:
- Der aktuelle Tag wird bei der Berechnung der Retention nicht berücksichtigt.
- Tage, an denen der Job überhaupt nicht lief, zählen ebenfalls. Dies sollte berücksichtigt werden, um nicht versehentlich die Punkte von Aufgaben zu verlieren, die unregelmäßig arbeiten.
- Ein Wiederherstellungspunkt wird ab dem Tag gezählt, an dem seine Erstellung begann (d. h. wenn der Job am Montag begann und am Dienstag endete, dann ist dies ein Punkt, der von Montag zählt).
Die Prinzipien der Anwendung des Retentionsmanagements werden nach wie vor durch die gewählte Backup-Methode bestimmt. Lassen Sie uns eine weitere Aufgabe zur Berechnung versuchen, wobei wir dieselbe inkrementelle Methode verwenden. Angenommen, die Retention ist auf 8 Tage festgelegt, die Aufgabe läuft alle 6 Stunden mit einem vollständigen Backup am Mittwoch. Dabei wird die Aufgabe am Sonntag nicht ausgeführt. Die Aufgabe wird erstmals am Montag gestartet. Wann wird die Retention angewendet?
Antwort
Wie üblich ist es am besten, eine Tabelle zu zeichnen. Ich erlaube mir, die Aufgabe zu vereinfachen und werde nicht alle Punkte, die an jedem Tag erstellt werden, zu zeichnen, da die Anzahl der Punkte pro Tag hier nicht von Bedeutung ist. Wichtig ist nur, dass am ersten Montag und an den Mittwochen der erste Punkt ein vollständiges Backup sein wird, während an den übrigen Tagen die Aufgabe einfach 4 inkrementelle Punkte erstellt.
Wir klären für uns, dass die Retention angewendet wird, indem das vollständige Backup vom Montag und dessen Inkrement entfernt werden. Wann wird dies geschehen? Wenn der verbleibende Teil der Kette 8 Tage enthält. Dabei zählen wir den aktuellen Tag nicht, jedoch das Sonntag bereits. Daher lautet die Antwort – am Donnerstag der zweiten Woche.
GFS-Archivierung für reguläre Aufgaben
Bis Version 10 war die Grandfather-Father-Son (GFS)-Speichermethode nur für Aufgaben zur Erstellung von Sicherungskopien (Backup) und für Aufgaben zum Kopieren auf Magnetband verfügbar. Jetzt steht sie auch für reguläre Backups zur Verfügung.
Obwohl dies nicht direkt zum aktuellen Thema gehört, möchte ich erwähnen, dass die neue Funktionalität nicht von der 3-2-1-Strategie abweicht. Die Anwesenheit von Archivpunkten im Hauptrepository hat keinen Einfluss auf dessen Zuverlässigkeit. Es wird davon ausgegangen, dass GFS in Verbindung mit einem skalierbaren (Scale-out) Repository verwendet wird, um diese Punkte in S3 und ähnlichen Speichern abzulegen. Wenn Sie diese nicht verwenden, ist es besser, primäre und Archivpunkte in verschiedenen Repositories zu speichern.
Jetzt betrachten wir die Prinzipien der Erstellung von GFS-Punkten. In den Einstellungen der Aufgabe gibt es im Schritt "Speicher" eine spezielle Schaltfläche, die folgendes Menü öffnet:
Die Essenz von GFS lässt sich in mehreren Punkten zusammenfassen (bitte beachten Sie, dass GFS in anderen Aufgabentypen anders funktioniert, aber dazu später mehr):
- Der Task erstellt kein separates vollständiges Backup für den GFS-Punkt. Stattdessen wird das am besten geeignete vollständige Backup aus den verfügbaren verwendet. Daher sollte der Task im inkrementellen Modus mit periodischen vollständigen Backups funktionieren, oder das vollständige Backup muss manuell vom Benutzer erstellt werden.
- Wenn nur ein Zeitraum aktiviert ist (z. B. wöchentlich), beginnt der Task zu Beginn des GFS-Zeitraums einfach mit dem Warten auf ein vollständiges Backup und markiert das erste passende als GFS.
Beispiel: Der Task ist so eingestellt, dass er ein wöchentliches GFS speichert und das Backup am Mittwoch verwendet. Der Task läuft jeden Tag, aber das vollständige Backup ist für Freitag angesetzt. In diesem Fall beginnt am Mittwoch der GFS-Zeitraum, und der Task beginnt, auf einen passenden Punkt zu warten. Dieser wird am Freitag verfügbar sein und als GFS markiert.
- Wenn mehrere Zeiträume gleichzeitig aktiviert sind (z. B. wöchentlich und monatlich), wird B&R eine Methode anwenden, die es ermöglicht, denselben Punkt als GFS für mehrere Intervalle zu verwenden (um Speicherplatz zu sparen). Die Flags werden nacheinander vergeben, beginnend mit dem jüngeren.
Beispiel: Das wöchentliche GFS ist auf Mittwoch festgelegt, während das monatliche auf die letzte Woche des Monats. Der Job läuft täglich und erstellt vollständige Backups montags und freitags.
Zur Vereinfachung beginnen wir mit der vorletzten Woche des Monats. In dieser Woche wird am Montag ein vollständiges Backup erstellt, aber es wird ignoriert, da der wöchentliche GFS-Intervall am Mittwoch beginnt. Das vollständige Backup am Freitag passt dagegen perfekt zum GFS-Punkt. Dieses System ist uns bereits bekannt.
Schauen wir uns nun an, was in der letzten Woche des Monats passieren wird. Der monatliche GFS-Intervall beginnt am Montag, aber das montägliche VBK wird nicht als GFS markiert, da der Job bestrebt ist, ein VBK sowohl als monatlichen als auch als wöchentlichen GFS-Punkt zu kennzeichnen. Dabei wird die Suche explizit mit dem wöchentlichen Punkt begonnen, da dieser definitionsgemäß auch der monatliche sein kann.
Wenn nur die wöchentlichen und jährlichen Intervalle aktiviert sind, agieren sie unabhängig voneinander und können 2 separate VBK als entsprechende GFS-Intervalle markieren.
Backup-Kopie Erstellung Jobs
Eine weitere Art von Aufgaben, die häufig Klarstellungen zur Funktionsweise erfordern. Lassen Sie uns zunächst die „klassische“ Arbeitsmethode ohne Innovationen in v.10 betrachten.
Einfache Methode zur Datenrückhaltung.
Standardmäßig laufen solche Aufgaben im unendlich inkrementellen Modus. Die Erstellung von Punkten wird durch zwei Parameter bestimmt – das Kopierintervall und die gewünschte Anzahl an Wiederherstellungspunkten (hier gibt es keine Rückhaltung nach Tagen). Das Kopierintervall wird im ersten Tab Job bei der Erstellung der Aufgabe festgelegt:
Die Anzahl der Punkte wird etwas weiter unten im Tab Target definiert.
Die Aufgabe erstellt 1 neuen Punkt für jedes Intervall (wie viele Punkte ursprünglich durch die Aufgaben für die VM erstellt wurden, spielt dabei keine Rolle). Am Ende des Intervalls wird der neue Punkt finalisiert und, falls erforderlich, wird die Rückhaltung durch das Zusammenführen von VBK und dem ältesten Inkrement angewendet. Dieser Mechanismus ist uns bereits bekannt.
Die Methode der Rückhaltung mit GFS.
BCJ kann auch Archivpunkte speichern. Dies wird im gleichen Tab Target konfiguriert, etwas unterhalb der Einstellungen zur Anzahl der Wiederherstellungspunkte:
GFS-Punkte können auf zwei Arten erstellt werden – synthetisch, indem Daten von einem sekundären Repository verwendet werden, oder indem ein vollständiges Backup imitiert wird, wobei alle Daten aus dem primären Repository gelesen werden (aktiviert durch die Option, die mit der Zahl 3 gekennzeichnet ist). Die Retention wird in beiden Fällen erheblich unterschiedlich sein, daher betrachten wir sie separat.
Synthetischer GFS
In diesem Fall wird der GFS-Punkt nicht genau am festgelegten Tag erstellt. Stattdessen wird der GFS-Punkt erstellt, wenn das VIB des entsprechenden Tages mit dem vollständigen Backup zusammengeführt wird. Dies kann manchmal zu Missverständnissen führen, da die Zeit vergeht und der GFS-Punkt noch nicht vorhanden ist. Nur ein mächtiger Meister der technischen Unterstützung kann vorhersagen, an welchem Tag der Punkt tatsächlich erscheinen wird. Tatsächlich ist keine Magie erforderlich – es genügt, die Anzahl der ausgegebenen Punkte und das Synchronisationsintervall zu betrachten (wie viele Punkte täglich erstellt werden). Versuchen Sie, es selbst an folgendem Beispiel zu berechnen: die Aufgabe sieht vor, 7 Punkte zu speichern, das Synchronisationsintervall beträgt 12 Stunden (d.h. 2 Punkte pro Tag). Momentan sind bereits 7 Punkte in der Kette, heute ist Montag und für diesen Tag ist die Erstellung des GFS-Punkts angesetzt. An welchem Tag wird er erstellt?
Antwort
Hier wäre es besser, zu beschreiben, wie sich die Kette dynamisch über die Tage ändern wird:
Am Montag wird das letzte Inkrement in der Kette als GFS markiert, jedoch gibt es keine weiteren sichtbaren Änderungen. Täglich erstellt der Auftrag 2 neue Punkte, und die Retention treibt die Kette unaufhaltsam voran. Schließlich kommt am Donnerstag die Zeit, die Retention auf das besagte Inkrement anzuwenden. Diese Sitzung wird länger dauern als üblich – denn der Auftrag wird die benötigten Blöcke aus der Kette „extrahieren“ und einen neuen vollständigen Punkt erstellen. Ab diesem Zeitpunkt wird die Kette bereits 8 Punkte haben – 7 in der Hauptkette + GFS.
Erstellung von GFS-Punkten mit der Option „Gesamten Punkt lesen“
Wie bereits erwähnt, arbeitet BCJ im unendlich-incrementalen Modus. Jetzt betrachten wir die einzige Ausnahme von dieser Regel. Wenn die Option „Read entire point“ aktiviert ist, wird der GFS-Punkt genau am geplanten Tag erstellt. Die Aufgabe selbst läuft jedoch im inkrementellen Modus mit regelmäßigen vollständigen Backups, die wir zuvor besprochen haben. Die Retention wird auch durch das Entfernen des ältesten Teils der Kette angewendet. In diesem Fall werden jedoch nur die Inkremente gelöscht, während das vollständige Backup als GFS-Punkt erhalten bleibt. Dementsprechend werden beim Berechnen der Retention die Punkte, die mit GFS-Flags markiert sind, nicht berücksichtigt.
Nehmen wir an, die Aufgabe ist so konfiguriert, dass 7 Punkte gespeichert werden und jeden Montag ein wöchentliches GFS-Punkt erstellt wird. In diesem Fall wird die Aufgabe jeden Montag tatsächlich ein vollständiges Backup erstellen und es als GFS kennzeichnen. Die Retention wird angewendet, wenn nach dem Löschen der Inkremente aus dem ältesten Teil die Anzahl der verbleibenden Inkremente nicht unter 7 fällt. So sieht das in der Grafik aus:
Am Ende der zweiten Woche haben wir insgesamt 14 Punkte in der Kette. Während der zweiten Woche wurden 7 Punkte erstellt. Wäre es sich um eine einfache Aufgabe, wäre der Retention bereits angewendet worden. Aber da es sich hier um BCJ mit GFS-Retention handelt, zählen wir die GFS-Punkte nicht, sodass wir nur 6 haben. Somit können wir die Retention noch nicht anwenden. In der dritten Woche erstellen wir erneut ein vollständiges Backup mit dem GFS-Flag. 15 Punkte, aber dieses zählen wir wieder nicht. Und schließlich, am Dienstag der dritten Woche, erstellen wir ein Inkrement. Wenn wir jetzt die Inkremente der ersten Woche entfernen, wird die Gesamtzahl der Inkremente den festgelegten Retentionsrichtlinien genügen.
Wie bereits oben erwähnt, ist es in dieser Methode sehr wichtig, dass vollständige Backups regelmäßig erstellt werden. Angenommen, wir setzen die Hauptretention auf 7 Tage, aber nur 1 jährlichen Punkt, dann ist es leicht vorstellbar, dass sich die Inkremente deutlich auf mehr als 7 anhäufen. In solchen Fällen ist es besser, die synthetische Methode zur Erstellung von GFS zu nutzen.
Und wieder "Gelöschte Elemente entfernen"
Diese Option ist auch für BCJ vorhanden:
Die Logik dieser Option funktioniert hier genau wie bei den herkömmlichen Backup-Jobs – wenn die Maschine nicht für die angegebene Anzahl von Tagen bearbeitet wird, werden ihre Daten aus der Kette entfernt. Für BCJ ist jedoch der Nutzen dieser Option objektiv höher, und das hat seine Gründe.
Im normalen Modus arbeitet BCJ in einem unendlich inkrementellen Modus. Wenn zu einem bestimmten Zeitpunkt die Maschine aus dem Job entfernt wird, wird die Aufbewahrung allmählich alle Wiederherstellungspunkte löschen, bis nur noch einer übrig bleibt – im VBK. Stellen wir uns jetzt vor, dass der Job außerdem so konfiguriert ist, dass synthetische GFS-Punkte erstellt werden. Wenn die Zeit kommt, muss der Job GFS für alle Maschinen in der Kette erstellen. Wenn es für eine Maschine überhaupt keine neuen Punkte gibt, na ja, dann müssen wir den nehmen, den wir haben. Und bei jedem Mal wird es so sein. Am Ende könnte folgende Situation entstehen:
Beachten Sie den Abschnitt Dateien: Wir haben das Haupt-VBK und 2 wöchentliche GFS-Punkte. Schauen wir uns nun den Abschnitt Wiederherstellungspunkte an – in diesen Dateien befindet sich tatsächlich dasselbe Abbild der Maschine. Es ist offensichtlich, dass solche GFS-Punkte keinen Sinn machen, sie nehmen nur Platz in Anspruch.
Diese Situation kann nur bei der Verwendung von synthetischen GFS auftreten. Um dies zu vermeiden, nutzen Sie die Option „Entfernen Sie gelöschte Elemente“. Vergessen Sie nicht, diese auf eine angemessene Anzahl von Tagen einzustellen. Der Support hat Fälle gesehen, in denen die Option auf weniger Tage als das Synchronisationsintervall eingestellt wurde – BCJ begann dann zu schäumen und löschte Punkte, bevor sie erstellt wurden.
Bitte beachten Sie auch, dass diese Option bereits erstellte GFS-Punkte nicht beeinflusst. Wenn Sie Archive bereinigen möchten, muss dies manuell erfolgen – klicken Sie mit der rechten Maustaste auf die Maschine und wählen Sie „Vom Datenträger löschen“ (denken Sie daran, im erscheinenden Fenster das Kästchen „Vollständige GFS-Sicherung entfernen“ zu aktivieren):
Neuheit v.10 – sofortige Kopie (immediate copy)
Nachdem wir uns mit der „klassischen“ Funktionalität befasst haben, wenden wir uns dem Neuen zu. Es gibt eine neue, aber sehr wichtige Funktion. Dies ist der neue Arbeitsmodus.
Es gibt kein so etwas wie einen "Synchronisationsintervall"; der Auftrag wird kontinuierlich überprüfen, ob neue Punkte vorhanden sind, und diese alle kopieren, egal wie viele es sind. Der Auftrag bleibt jedoch inkrementell, das heißt, auch wenn der Hauptauftrag VBK oder VRB erstellt, werden diese Punkte als VIB kopiert. Ansonsten gibt es in diesem Modus keine Überraschungen – sowohl der Standard- als auch der GFS-Retention funktionieren nach den oben beschriebenen Regeln (es ist jedoch nur synthetisches GFS verfügbar).
Die Disks rotieren. Besonderheiten von Repositories mit rotierten Disks.
Die ständige Bedrohung durch Ransomware hat es de facto zum Sicherheitsstandard gemacht, eine Kopie der Daten auf einem Medium zu haben, auf das der Virus nicht zugreifen kann. Eine Möglichkeit ist die Verwendung von Repositories mit rotierten Disketten, bei denen die Disks abwechselnd genutzt werden: Während eine Disk angeschlossen und verfügbar zum Schreiben ist, werden die anderen an einem sicheren Ort aufbewahrt.
Um B&R für die Arbeit mit solchen Repositories zu konfigurieren, müssen Sie in den Repositories-Einstellungen, Schritt Repository, auf die Schaltfläche Erweiterte Optionen klicken und die entsprechende Option auswählen:
Nach diesem Punkt wird VBR erwarten, dass regelmäßig bestehende Ketten aus dem Repository verschwinden, was eine Diskrotation bedeutet. Je nach Art des Repositories und der Art der Aufgabe wird sich B&R unterschiedlich verhalten. Dies lässt sich in folgender Tabelle darstellen:
Betrachten wir jede Option.
Normale Aufgabe und Windows-Repository
Also haben wir eine Aufgabe, die Ketten auf der ersten Disk speichert. Bei der Rotation verschwindet die erstellte Kette tatsächlich, und die Aufgabe muss mit diesem Verlust umgehen. Der Trost liegt in der Erstellung eines vollständigen Backups. So bedeutet jede Rotation ein vollständiges Backup. Aber was passiert mit den Punkten auf der abgeschalteten Disk? Diese werden gespeichert und bei der Berechnung der Retention berücksichtigt. Daher ist die angegebene Anzahl von Punkten in der Aufgabe die Anzahl der Punkte, die auf allen Disks gehalten werden müssen. Lassen Sie uns ein Beispiel anführen:
Die Aufgabe läuft im unendlich inkrementellen Modus und ist so konfiguriert, dass sie 3 Wiederherstellungspunkte speichert. Aber wir haben eine zweite Disk, und wir führen einmal pro Woche eine Rotation durch (es können auch mehr Disks sein, das ändert nichts an der Sache).
In der ersten Woche wird die Aufgabe Punkte auf der ersten Festplatte erstellen und überflüssige zusammenführen. Somit wird die Gesamtzahl der Punkte drei betragen:
Dann verbinden wir die zweite Festplatte. Bei der Ausführung wird B&R feststellen, dass die Festplatte gewechselt wurde. Die Kette auf der ersten Festplatte wird aus der Benutzeroberfläche verschwinden, aber die Informationen darüber bleiben in der Datenbank. Jetzt wird die Aufgabe 3 Punkte auf der zweiten Festplatte halten. Die Gesamtsituation wird also so aussehen:
Schließlich verbinden wir erneut die erste Festplatte. Bevor ein neuer Punkt erstellt wird, überprüft die Aufgabe, wie es um den Retention-Plan steht. Der Retention-Plan, wie ich erinnere, ist so eingestellt, dass er 3 Punkte speichert. Unterdessen haben wir 3 Punkte auf Festplatte 2 (aber sie ist abgeschaltet und an einem sicheren Ort aufbewahrt, den B&R nicht erreichen kann) und 3 Punkte auf Festplatte 1 (und diese ist jetzt angeschlossen). Das bedeutet, wir können 3 Punkte von Festplatte 1 problemlos löschen, da sie die Retention überschreiten. Danach erstellt die Aufgabe erneut ein vollständiges Backup, und unsere Kette wird so aussehen:
Wenn die Retention so eingestellt ist, dass anstelle der Anzahl der Punkte Tage gespeichert werden, bleibt die Logik unverändert. Zudem wird GFS-Retention bei der Nutzung von Repositories mit Festplattentausch überhaupt nicht unterstützt.
Gewöhnliche Aufgabe und Linux Repository für Netzwerkspeicher
Diese Option ist ebenfalls möglich, wird jedoch insgesamt weniger empfohlen aufgrund der auferlegten Einschränkungen. Bei der Rotierung der Festplatte und dem Verschwinden der Kette reagiert der Auftrag ebenfalls mit der Erstellung eines vollständigen Backups. Die Einschränkung hängt mit dem verkürzten Retention-Mechanismus zusammen.
Hierbei wird bei der Rotierung die gesamte Kette auf der abgeschalteten Festplatte einfach aus der B&R-Datenbank gelöscht. Beachten Sie – aus der Datenbank, die Dateien bleiben dabei jedoch auf der Festplatte. Sie können importiert und zur Wiederherstellung verwendet werden, aber es ist einfach einzusehen, dass solche vergessenen Ketten früher oder später das gesamte Repository füllen werden.
Die Lösung besteht darin, DWORD ForceDeleteBackupFiles hinzuzufügen, wie auf dieser Seite angegeben: . Danach wird der Auftrag beginnen, einfach den gesamten Inhalt des Auftragsordners oder des Repository-Ordners (abhängig vom Wert) bei jeder Rotierung zu löschen.
Dies ist jedoch keine elegante Retention, sondern vielmehr eine Säuberung des gesamten Inhalts. Leider hat der Support Fälle gesehen, in denen das Repository einfach das Wurzelverzeichnis der Festplatte war, wo neben Backups auch andere Daten abgelegt waren. All dies wurde bei der Rotierung gelöscht.
Darüber hinaus funktioniert ForceDeleteBackupFiles beim Aktivieren für alle Repository-Typen, das heißt, auch Windows-Repositorys hören auf, Retention anzuwenden und beginnen, Inhalte zu löschen. Mit anderen Worten, die lokale Festplatte unter Windows ist die beste Wahl für ein solches Backup-System.
Backup-Kopie und Windows-Repository
Mit BCJ wird es noch interessanter. Es gibt nicht nur vollständige Retention, sondern es ist auch nicht nötig, bei jedem Wechsel der Festplatte ein vollständiges Backup zu machen! So funktioniert es:
Zuerst beginnt B&R, Punkte auf der ersten Festplatte zu erstellen. Angenommen, wir haben die Retention auf 3 Punkte festgelegt. Die Aufgabe wird im unendlich inkrementellen Modus ausgeführt und alles Überflüssige zusammengeführt (ich erinnere daran, dass GFS-Retention in diesem Fall nicht unterstützt wird).
Dann schließen wir die zweite Festplatte an. Da dort noch keine Kette vorhanden ist, erstellen wir ein vollständiges Backup, woraufhin wir eine zweite Kette aus drei Punkten erhalten:
Schließlich ist es an der Zeit, die erste Festplatte wieder anzuschließen. Und hier beginnt die Magie, denn die Aufgabe wird kein vollständiges Backup erstellen, sondern einfach die inkrementelle Kette fortsetzen:
Nach diesem Schritt wird auf jeder Festplatte eine unabhängige Kette existieren. Daher bezieht sich die Aufbewahrung hier nicht auf die Anzahl der Punkte auf allen Festplatten, sondern auf die Anzahl der Punkte auf jeder einzelnen Festplatte.
Backup-Kopie und Linux-Repository-Netzwerkspeicher
Und erneut geht die gesamte Eleganz verloren, wenn das Repository nicht auf einer lokalen Windows-Festplatte ist. Dieses Szenario funktioniert ähnlich wie das oben genannte mit einer einfachen Aufgabe. Bei jeder Rotation erstellt BCJ ein vollständiges Backup, während bestehende Punkte vergessen werden. Um keinen Speicherplatz zu verlieren, muss DWORD ForceDeleteBackupFiles verwendet werden.
Fazit
Infolgedessen haben wir in diesem langen Text zwei Arten von Aufgaben betrachtet. Natürlich gibt es noch viele weitere Aufgaben, aber nicht alle können im Rahmen eines Artikels behandelt werden. Wenn Sie nach dem Lesen noch Fragen haben, schreiben Sie diese in die Kommentare, ich freue mich darauf, persönlich zu antworten.
Quelle: habr.com
