Ich begrüße die Leser unseres Blogs! Teilweise kennen wir uns bereits – meine englischen Beiträge wurden hier in Übersetzung von meiner lieben Kollegin veröffentlicht. . Diesmal habe ich mich entschieden, direkt an das russischsprachige Publikum zu schreiben.
Für mein Debüt wollte ich ein Thema finden, das für ein möglichst breites Publikum interessant ist und eine detaillierte Betrachtung erfordert. Daniel Defoe behauptete, dass jeden Menschen der Tod und die Steuern erwarten. Von meiner Seite kann ich sagen, dass jeder Support-Ingenieur mit Fragen zu den Richtlinien für die Aufbewahrung von Wiederherstellungspunkten (oder einfacher gesagt – Retention) konfrontiert wird. Wie Retention funktioniert, begann ich vor 4 Jahren zu erklären, als ich Junior Engineer der ersten Stufe war, und ich erkläre es auch jetzt noch, als Teamleiter eines spanisch- und italienischsprachigen Teams. Ich bin mir sicher, dass meine Kollegen der zweiten und sogar dritten Supportstufe ebenfalls regelmäßig dieselben Fragen beantworten.
Vor diesem Hintergrund wollte ich einen endgültigen, möglichst detaillierten Beitrag schreiben, auf den russischsprachige Nutzer immer wieder zurückgreifen könnten wie auf ein Nachschlagewerk. Der Zeitpunkt ist günstig – die neu veröffentlichte Jubiläumsausgabe der zehnten Version hat neue Möglichkeiten zur grundlegenden Funktionalität hinzugefügt, die über Jahre unverändert geblieben ist. Mein Beitrag richtet sich in erster Linie an 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, wenn ich ein wenig in die Zukunft blicke, kann ich sagen, dass in der nächsten Version einige Änderungen zu erwarten sind, aber darüber werden wir berichten, wenn die Zeit kommt. Also, fangen wir an.
Backup-Job
Zunächst betrachten wir den Teil, der in Version 10 unverändert geblieben ist. Die Retention-Politik wird durch mehrere Parameter definiert. Lassen Sie uns das Fenster zur Erstellung eines neuen Jobs öffnen und zum Tab Speicher wechseln. Hier sehen wir einen Parameter, der die gewünschte Anzahl der Wiederherstellungspunkte definiert:
Das ist jedoch nur ein Teil der Gleichung. Die tatsächliche Anzahl der Punkte wird auch durch den Backup-Modus bestimmt, der für den Job eingestellt ist. Um diesen Parameter auszuwählen, klicken Sie auf die Schaltfläche Erweitert im selben Tab. Dies öffnet ein neues Fenster mit vielen Optionen. Lassen Sie uns diese nummerieren und nacheinander betrachten:
Wenn nur Option 1 aktiviert wird, arbeitet der Job im „unendlich inkrementellen“ Modus (forever forward incremental). Hier gibt es keine Schwierigkeiten – der Job speichert eine 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 das festgelegte Limit überschreitet, wird das älteste Inkrement mit dem vollständigen Backup zusammengeführt. Mit anderen Worten, wenn der Job eingestellt ist, 3 Punkte zu speichern, gibt es direkt nach der Sitzung 4 Punkte im Repository, wonach das vollständige Backup mit dem ältesten Inkrement zusammengeführt wird und die Gesamtzahl der Punkte auf 3 zurückkehrt.
Das Retention-Verfahren für den „rückwärts-inkrementellen“ Modus (Option 2) ist ebenfalls extrem einfach. Da hierbei der neueste Punkt das vollständige Backup ist und eine Kette von sogenannten Rollbacks (Dateien mit der Erweiterung VRB) folgt, genügt es, einfach den ältesten Rollback zu löschen, um das Retention-Verfahren anzuwenden. Die Situation wäre die gleiche: Direkt nach der Sitzung überschreitet die Anzahl der Punkte das festgelegte Limit um 1, wonach sie auf den gewünschten Wert zurückkehrt.
Beachten Sie, dass im rückwärts-inkrementalen Modus auch ein periodisches vollständiges Backup (Option 4) aktiviert werden kann, aber das ändert nichts an der Sache. Ja, in der Kette erscheinen vollständige Wiederherstellungspunkte, aber wir werden trotzdem einfach die ältesten Punkte einzeln löschen.
Schließlich kommen wir zu dem interessanten Teil. Wenn das inkrementelle Backup aktiviert wird, aber zusätzlich die Optionen 3 oder 4 (oder sogar beide gleichzeitig) aktiviert werden, beginnt der Job, periodische vollständige Backups mit einer „aktiven“ oder synthetischen Methode zu erstellen. Die Methode zur Erstellung des vollständigen Backups ist unwichtig – sie enthält die gleichen Daten, und die inkrementelle Kette wird in „Unterketten“ aufgeteilt. Diese Methode wird als forward incremental bezeichnet, und genau sie wirft einen Großteil der Fragen bei unseren Kunden auf.
Retention wird hier durch das Entfernen des ältesten Teils der Kette (von einem vollständigen Backup bis zum inkrementellen) angewendet. Dabei werden nicht nur leere Backups oder nur Teile der Inkremente entfernt. 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 ein Retention angewendet werden muss, definiert diese Einstellung hier die minimale Anzahl. Mit anderen Worten, nach dem Löschen der ältesten "Unterkette" sollte die Anzahl der Punkte im verbleibenden Teil nicht unter dieses Minimum fallen.
Ich werde versuchen, dieses Konzept grafisch darzustellen. Angenommen, die Retention ist auf 3 Punkte eingestellt, die Aufgabe läuft jeden Tag mit einem vollständigen Backup am Montag. In diesem Fall wird die Retention angewendet, wenn die Gesamtsumme der Punkte 10 erreicht:
Warum ausgerechnet 10, wenn 3 eingestellt sind? Am Montag wurde ein vollständiges Backup erstellt. Von Dienstag bis Sonntag hat die Aufgabe Inkremente erstellt. Schließlich wird am folgenden 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 der Punkte nicht unter die festgelegten 3 fällt.
Wenn das Konzept klar ist, lade ich Sie ein, die Retention selbst zu berechnen. Nehmen wir an, die Aufgabe wird zum ersten Mal am Donnerstag gestartet (es wird natürlich ein vollständiges Backup erstellt). Die Aufgabe ist so eingestellt, dass sie am Mittwoch und Sonntag vollständige Backups erstellt und 8 Wiederherstellungspunkte speichert. 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 zu notieren, 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) löschen können und die restliche Kette nicht unter die erforderlichen 8 Punkte fällt. Es wird klar, dass wir das tun können, wenn wir insgesamt 11 Punkte haben, d. h. am Sonntag der zweiten Woche.
Einige Leser könnten einwenden: „Warum das alles, wenn es ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Zuletzt haben wir die Option "Transform previous backup chains into rollbacks" (mit der Zahl 5 gekennzeichnet) nicht betrachtet. Diese Option verwirrt manchmal Kunden, die sie „automatisch“ aktivieren, in der Annahme, einfach ein synthetisches Backup zu aktivieren. Diese Option aktiviert jedoch einen ganz besonderen Backup-Modus. Ohne ins Detail zu gehen, möchte ich gleich sagen, dass diese Option in der aktuellen Produktentwicklung veraltet ist und ich mir kein Szenario vorstellen kann, in dem sie sinnvoll verwendet werden sollte. Ihr Wert ist so fraglich, dass Anton Gostev eine Zeit lang im Forum nach Beispielen für ihre nützliche Verwendung fragte (wenn Sie welche haben, schreiben Sie in die Kommentare, ich bin sehr interessiert). Wenn keine Beispiele gefunden werden (ich denke, das wird der Fall sein), wird die Option in zukünftigen Versionen entfernt.
Der Auftrag wird bis zu dem Tag, an dem ein synthetisches vollständiges Backup geplant ist, Inkremente (VIB) erstellen. An diesem Tag wird tatsächlich ein VBK erstellt, aber alle Punkte bis zu diesem VBK werden in Rollbacks (VRB) umgewandelt. Danach wird der Auftrag weiterhin Inkremente zum vollständigen Backup bis zum nächsten synthetischen Backup erstellen. Schließlich entsteht in der Kette eine explosive Mischung aus VBK-, VBR- und VIB-Dateien. Die Aufbewahrung erfolgt ganz einfach – durch das Löschen des letzten VBR:
Probleme
Neben dem Verständnis, wie das funktioniert, sind die meisten Probleme, die beim Einsatz des inkrementellen Modus auftreten, normalerweise mit dem vollständigen Backup verbunden. Ein regelmäßiges vollständiges Backup ist für diesen Modus erforderlich, andernfalls wird das Repository Punkte anhäufen, bis es überfüllt ist.
Zum Beispiel kann ein vollständiges Backup zu selten erstellt werden. Angenommen, der Auftrag ist so eingestellt, dass er 10 Punkte speichert, während ein vollständiges Backup einmal im Monat erstellt wird. Es ist klar, dass die tatsächliche Anzahl der Punkte hier deutlich höher sein wird als geplant. Oder der Auftrag ist sogar so eingestellt, dass er im unbegrenzten inkrementellen Modus arbeitet und 50 Punkte speichert. Dann hat jemand zufällig ein vollständiges Backup erstellt. Von nun an wird der Auftrag warten, bis der vollständige Punkt 49 Inkremente angehäuft hat, danach wird die Aufbewahrung angewendet und er kehrt in den unbegrenzten vollständigen Modus zurück.
In anderen Fällen wird ein vollständiges Backup regelmäßig eingerichtet, aber aus irgendeinem Grund nicht durchgeführt. Hier beschreibe ich die häufigste Ursache. Einige Kunden ziehen es vor, die „run after“-Option zu verwenden und Aufgaben in einer Kette zu konfigurieren. Nehmen wir ein Beispiel: Es gibt 3 Aufgaben, die jeden Tag laufen und am Sonntag ein vollständiges Backup erstellen. Die erste Aufgabe startet um 22:30 Uhr, die anderen werden in der Kette gestartet. Das inkrementelle Backup dauert 10 Minuten, daher sind bis 23:00 Uhr alle Aufgaben abgeschlossen. Das vollständige Backup hingegen benötigt eine Stunde, deshalb geschieht am Sonntag Folgendes: Die erste Aufgabe läuft von 22:30 bis 23:30 Uhr. Die nächste von 23:30 bis 00:30 Uhr. Und die dritte Aufgabe wird dann bereits am Montag gestartet. Das vollständige Backup ist für Sonntag eingestellt, weshalb es in diesem Fall einfach nicht vorhanden sein wird. Die Aufgabe wird auf das vollständige Backup warten, um die Retention anzuwenden. Seien Sie also vorsichtig bei der Verwendung der „run after“-Option oder verwenden Sie sie gar nicht – stellen Sie einfach ein, dass die Aufgaben zur gleichen Zeit starten, und lassen Sie den Ressourcenplaner seine Arbeit tun.
Die komplexe Option „Remove deleted items“
Wenn man durch die Aufgaben-Einstellungen unter Storage – Advanced – Maintenance navigiert, kann man auf die Option „remove deleted items data after“ stoßen, die nach Tagen berechnet wird.
Einige Kunden erwarten, dass dies die Retention ist. Tatsächlich handelt es sich um eine völlig separate Option, deren Missverständnis zu unerwarteten Folgen führen kann. Zunächst muss jedoch erklärt werden, wie B&R auf Situationen reagiert, in denen während der Sitzung nur einige Maschinen erfolgreich gesichert werden.
Stellen Sie sich folgendes Szenario vor: eine unendlich inkrementelle Aufgabe, die auf die Aufbewahrung von 6 Punkten eingestellt ist. In der Aufgabe sind 2 Maschinen, eine sichert immer erfolgreich, die andere hat manchmal Fehler. Infolgedessen ergab sich zur siebten Punkt eine solche Situation:
Es ist Zeit, die Retention anzuwenden, aber bei einer Maschine gibt es 7 Punkte und bei der anderen nur 4. Wird hier die Retention angewendet? Die Antwort ist – ja, wird sie. Wenn auch nur ein Objekt gesichert wurde, betrachtet B&R den Punkt als erstellt.
Eine ähnliche Situation kann auftreten, wenn eine Maschine einfach nicht während einer bestimmten Sitzung in den Auftrag eingeschlossen wurde. Das geschieht beispielsweise, wenn Maschinen nicht einzeln, sondern in Containern (Ordnern, Speicher) in den Auftrag aufgenommen werden und eine Maschine vorübergehend in einen anderen Container migriert. In diesem Fall wird der Auftrag als erfolgreich angesehen, aber in der Statistik finden Sie eine Meldung, die darauf hinweist, dass diese Maschine nicht mehr vom Auftrag bearbeitet wird.
Was passiert, wenn man das ignoriert? Im Fall von unendlich inkrementellen oder rückwärts inkrementellen Modus wird die Anzahl der Wiederherstellungspunkte der 'problematischen' Maschine mit jeder Sitzung abnehmen, bis sie 1 erreicht, die in VBK gespeichert ist. Mit anderen Worten, selbst wenn die Maschine lange Zeit nicht gesichert wird, bleibt immer noch ein Wiederherstellungspunkt erhalten. Die Sache gestaltet sich anders, wenn periodische vollständige Backups aktiviert sind. Wenn man die Signale von B&R ignoriert, kann der letzte Punkt zusammen mit dem alten Teil der Kette gelöscht werden.
Nachdem Sie diese Details verstanden haben, können wir endlich die Option "Remove deleted items data after" betrachten. Sie löscht alle Punkte für eine bestimmte Maschine, wenn diese Maschine für X Tage nicht gesichert wird. Bitte beachten Sie, dass diese Einstellung nicht auf Fehler reagiert (wir haben es versucht – es hat nicht funktioniert). Es sollte nicht einmal ein Versuch unternommen werden, die Maschine zu sichern. Auf den ersten Blick scheint die Option nützlich zu sein und sollte immer aktiviert bleiben. Wenn ein Administrator die Maschine aus dem Auftrag entfernt hat, wäre es logisch, nach einiger Zeit unnötige Daten und die Kette zu bereinigen. Diese Einstellung erfordert jedoch Disziplin und Aufmerksamkeit.
Ich gebe ein Beispiel aus der Praxis: In den Auftrag wurden mehrere Container aufgenommen, deren Zusammensetzung ziemlich dynamisch war. Aufgrund des fehlenden RAM hatte der B&R-Server Probleme, die unbemerkt blieben. Der Auftrag wurde gestartet und versuchte, Backups der Maschinen zu erstellen, mit Ausnahme einer, die zu diesem Zeitpunkt nicht im Container war. Da viele Maschinen Fehler meldeten, musste B&R standardmäßig 3 zusätzliche Versuche unternehmen, das Backup der "problematischen" Maschinen zu erstellen. Wegen der konstanten RAM-Probleme erstreckten sich diese Versuche über mehrere Tage. Ein weiterer Versuch, ein Backup der fehlenden VM zu erstellen, wurde nicht unternommen (das Fehlen der VM ist kein Fehler). Letztendlich wurde während eines der Wiederholungsversuche die Bedingung "Löschen gelöschter Elemente" erfüllt und alle Punkte der Maschine wurden gelöscht.
Dazu kann ich Folgendes sagen: Wenn Sie Benachrichtigungen über die Ergebnisse der Aufträge eingerichtet haben, und noch besser — eine Integration mit Veeam ONE nutzen, dann wird dies Ihnen wahrscheinlich nicht passieren. Wenn Sie jedoch einmal pro Woche auf den B&R-Server schauen, um zu überprüfen, ob alles funktioniert, sollten Sie von Optionen, die potenziell zu einer Löschung der Backups führen könnten, besser Abstand nehmen.
Was in v.10 hinzugefügt wurde
Das, was wir zuvor besprochen haben, war in B&R über viele Versionen hinweg vorhanden. Haben wir diese Arbeitsprinzipien verstanden, schauen wir uns nun an, was in der Jubiläumsausgabe "zehn" neu hinzugekommen ist.
Tägliche Aufbewahrung
Oben haben wir die "klassische" Aufbewahrungsrichtlinie betrachtet, die auf der Anzahl von Punkten basiert. Ein alternativer Ansatz besteht darin, im selben Menü "Tage" anstelle von "Wiederherstellungspunkten" festzulegen.
Die Idee ist aus dem Namen klar – die Aufbewahrung wird eine festgelegte Anzahl an Tagen speichern, die Anzahl der Punkte an jedem Tag spielt dabei keine Rolle. Dabei sollte Folgendes beachtet werden:
- Der aktuelle Tag wird nicht in die Berechnung der Aufbewahrung einbezogen.
- Tage, an denen der Auftrag überhaupt nicht ausgeführt wurde, werden ebenfalls gezählt. Dies sollte im Hinterkopf behalten werden, um nicht versehentlich die Punkte der Aufträge zu verlieren, die unregelmäßig arbeiten.
- Ein Wiederherstellungspunkt wird ab dem Tag gezählt, an dem seine Erstellung begonnen hat (d.h. wenn der Auftrag am Montag gestartet und am Dienstag beendet wurde, dann ist dies der Punkt ab Montag)
Im Übrigen werden die Prinzipien der Anwendung des Retentionsverfahrens durch die gewählte Backup-Methode bestimmt. Lassen Sie uns eine weitere Aufgabe zur Berechnung versuchen, indem wir dieselbe inkrementelle Methode verwenden. Angenommen, die Retention ist auf 8 Tage festgelegt, der Job läuft alle 6 Stunden mit einem vollständigen Backup am Mittwoch. Der Job läuft jedoch nicht am Sonntag. Der Job startet am Montag zum ersten Mal. Wann wird die Retention angewendet?
Antwort
Wie gewohnt ist es am besten, eine Tabelle zu zeichnen. Ich erlaube mir, die Aufgabe zu vereinfachen und werde nicht alle Punkte zu zeichnen, die an jedem Tag erstellt wurden, da die Anzahl der Punkte pro Tag hier keine Rolle spielt. Für uns ist nur wichtig, dass am ersten Montag und an den Mittwoch der erste Punkt ein vollständiges Backup sein wird, während an den anderen Tagen der Job einfach 4 inkrementelle Punkte erstellt.
Wir stellen uns klar, dass die Retention durch das Löschen des vollständigen Montags-Backups und dessen Inkrement angewendet wird. Wann wird das geschehen? Wenn der verbleibende Teil der Kette 8 Tage umfasst. Dabei zählt der aktuelle Tag nicht, der Sonntag hingegen zählt. Daher lautet die Antwort: am Donnerstag der zweiten Woche.
Archivierungsmethode GFS für reguläre Jobs
Bis zur Version 10 war die Aufbewahrungsmethode Großvater-Vater-Sohn (GFS) nur für Archivkopierjobs (Backup copy) und für Jobs zum Kopieren auf Magnetband verfügbar. Jetzt ist sie jedoch auch für reguläre Backups verfügbar.
Obwohl dies nicht zum aktuellen Thema gehört, möchte ich nicht versäumen zu erwähnen, dass die neue Funktionalität nicht bedeutet, dass von der 3-2-1-Strategie abgerückt wird. Das Vorhandensein von Archivpunkten im Haupt-Repository beeinflusst dessen Zuverlässigkeit nicht. Es wird angenommen, dass GFS zusammen mit einem skalierbaren Repository verwendet wird, um diese Punkte in S3 und ähnliche Speicher zu laden. Wenn Sie es nicht verwenden, ist es besser, primäre und Archivpunkte in verschiedenen Repositories zu speichern.
Nun betrachten wir die Prinzipien der Erstellung von GFS-Punkten. In den Einstellungen des Jobs, im Schritt Storage, gibt es einen speziellen Button, der folgendes Menü öffnet:
Die Essenz von GFS lässt sich in mehrere Punkte zusammenfassen (bitte beachten Sie, dass GFS in anderen Arten von Jobs anders funktioniert, aber dazu später mehr):
- Der Auftrag erstellt kein separates vollständiges Backup für den GFS-Punkt. Stattdessen wird das am besten geeignete vollständige Backup aus den vorhandenen verwendet. Daher sollte der Auftrag im inkrementellen Modus mit periodischen vollständigen Backups arbeiten, oder das vollständige Backup muss manuell vom Benutzer erstellt werden.
- Wenn nur ein Zeitraum aktiviert ist (zum Beispiel wöchentlich), beginnt der Auftrag zu Beginn des GFS-Zeitraums einfach auf das vollständige Backup zu warten und markiert das erste passende als GFS.
Beispiel: Der Auftrag ist so eingestellt, dass er einen wöchentlichen GFS speichert, indem er das Backup am Mittwoch nutzt. Der Auftrag läuft jeden Tag, aber das vollständige Backup ist auf Freitag angesetzt. In diesem Fall beginnt am Mittwoch der GFS-Zeitraum, und der Auftrag beginnt auf einen geeigneten Punkt zu warten. Dieser wird am Freitag verfügbar sein und mit dem GFS-Flag markiert.
- Wenn mehrere Zeiträume aktiviert sind (zum Beispiel wöchentlich und monatlich), wird B&R eine Methode anwenden, die es ermöglicht, denselben Punkt für mehrere GFS-Zeiträume zu verwenden (zur Platzersparnis). Die Flags werden nacheinander zugewiesen, beginnend mit dem jüngsten.
Beispiel: Der wöchentliche GFS ist für Mittwoch festgelegt, und der monatliche für die letzte Woche des Monats. Der Auftrag läuft jeden Tag und erstellt vollständige Backups am Montag und Freitag.
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-Zeitraum am Mittwoch beginnt. Das vollständige Backup vom Freitag eignet sich jedoch vollständig für den GFS-Punkt. Dieses System ist uns bereits bekannt.
Nun betrachten wir, was in der letzten Woche des Monats passieren wird. Der monatliche GFS-Zeitraum beginnt am Montag, aber das montägliche VBK wird nicht als GFS markiert, weil der Auftrag bestrebt ist, ein VBK sowohl als monatlichen als auch als wöchentlichen GFS-Punkt zu kennzeichnen. Dabei beginnt die Suche speziell mit den wöchentlichen, da diese per Definition auch monatlich werden können.
Wenn nur der wöchentliche und der jährliche Zeitraum aktiviert sind, funktionieren sie unabhängig voneinander und können 2 separate VBKs als entsprechende GFS-Zeiträume markieren.
Aufträge zur Erstellung von Sicherungskopien (Backup Copy)
Ein weiterer Aufgabentyp, der oft Erläuterungen zur Funktionsweise erfordert. Zunächst betrachten wir die "klassische" Arbeitsweise, ohne Neuerungen von v.10.
Einfache Methode der Aufbewahrung
Standardmäßig arbeiten solche Aufgaben im unendlichen inkrementellen Modus. Die Erstellung von Punkten wird durch zwei Parameter bestimmt – das Kopierintervall und die gewünschte Anzahl von Wiederherstellungspunkten (Retention über Tage gibt es hier nicht). Das Kopierintervall wird auf dem ersten Tab Job bei der Erstellung der Aufgabe festgelegt:
Die Anzahl der Punkte wird etwas weiter unten auf dem Tab Ziel festgelegt.
Die Aufgabe erstellt 1 neuen Punkt für jedes Intervall (wie viele Punkte ursprünglich für die VM erstellt wurden, spielt keine Rolle). Am Ende des Intervalls wird der neue Punkt finalisiert und, falls erforderlich, erfolgt die Retention durch das Zusammenführen von VBK und dem ältesten Inkrement. Dieser Mechanismus ist uns bereits bekannt.
Die Retention-Methode mit GFS
BCJ kann auch archivierte Punkte speichern. Dies wird auf demselben Tab Ziel konfiguriert, etwas unterhalb der Einstellungen zur Anzahl der Wiederherstellungspunkte:
GFS-Punkte können auf zwei Arten erstellt werden – synthetisch, indem Daten aus dem sekundären Repository verwendet werden, oder indem ein vollständiges Backup imitiert wird und alle Daten aus dem primären Repository ausgelesen werden (aktiviert durch die Option, die mit der Zahl 3 gekennzeichnet ist). Die Retention wird in beiden Fällen stark variieren, daher betrachten wir sie getrennt.
Synthetisches GFS
In diesem Fall wird der GFS-Punkt nicht genau am vorgesehenen Tag erstellt. Stattdessen wird der GFS-Punkt erstellt, wenn das VIB des Tages, an dem die Erstellung des GFS-Punkts vorgesehen war, mit dem vollständigen Backup zusammengeführt wird. Dies führt manchmal zu Missverständnissen, denn die Zeit vergeht, und der GFS-Punkt ist immer noch nicht da. Nur ein mächtiger Zauberer aus dem Support kann vorhersagen, an welchem Tag der Punkt tatsächlich erscheinen wird. Tatsächlich ist keine Magie nötig – es genügt, die festgelegte Anzahl von Punkten und das Synchronisationsintervall zu betrachten (wie viele Punkte jeden Tag erstellt werden). Versuchen Sie, es selbst an folgendem Beispiel zu berechnen: Die Aufgabe ist so eingestellt, dass sie 7 Punkte speichert, das Synchronisationsintervall beträgt 12 Stunden (d. h. 2 Punkte pro Tag). Momentan gibt es bereits 7 Punkte in der Kette, heute ist Montag, und für diesen Tag ist die Erstellung des GFS-Punkts vorgesehen. An welchem Tag wird er erstellt?
Antwort
Hier wäre es besser zu beschreiben, wie sich die Kette dynamisch im Tagesverlauf ändern wird:
Am Montag wird das letzte Inkrement in der Kette als GFS gekennzeichnet, aber es gibt keine weiteren sichtbaren Änderungen. Jeden Tag erstellt der Job 2 neue Punkte, und das Retention bewegt die Kette unbarmherzig voran. Schließlich ist es am Donnerstag an der Zeit, das Retention auf dasselbe Inkrement anzuwenden. Diese Sitzung wird mehr Zeit in Anspruch nehmen als gewöhnlich – denn der Job wird die benötigten Blöcke aus der Kette "herausziehen" und einen neuen vollständigen Punkt erstellen. Ab diesem Moment wird die Kette insgesamt 8 Punkte enthalten – 7 in der Hauptkette + GFS.
Erstellung von GFS-Punkten mit der Option „Ganzen Punkt lesen“
Wie bereits erwähnt, arbeitet BCJ im unendlich inkrementellen Modus. Jetzt werden wir die einzige Ausnahme von dieser Regel betrachten. Wenn die Option „Ganzen Punkt lesen“ aktiviert ist, wird der GFS-Punkt genau am geplanten Tag erstellt. Der Job selbst wird im inkrementellen Modus mit regelmäßigen vollständigen Backups arbeiten, die wir oben besprochen haben. Das Retention wird auch durch das Löschen 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. Daher werden beim Berechnen des Retention die Punkte mit GFS-Flags nicht berücksichtigt.
Angenommen, der Job ist so eingestellt, dass er 7 Punkte speichert und jeden Montag einen wöchentlichen GFS-Punkt erstellt. In diesem Fall wird der Job tatsächlich jeden Montag ein vollständiges Backup erstellen und es als GFS kennzeichnen. Das Retention wird angewendet, wenn die Anzahl der verbleibenden Inkremente nach dem Löschen der Inkremente aus dem ältesten Teil nicht unter 7 fällt. So sieht es im Diagramm aus:
Am Ende der zweiten Woche gibt es insgesamt 14 Punkte in der Kette. Während der zweiten Woche hat der Job 7 Punkte erstellt. Wäre es ein einfacher Job, wäre das Retention bereits angewendet worden. Aber das ist BCJ mit GFS-Retention, daher zählen wir die GFS-Punkte nicht, was bedeutet, dass es nur 6 gibt. Das heißt, wir können das Retention noch nicht anwenden. In der dritten Woche erstellen wir ein weiteres vollständiges Backup mit dem GFS-Flag. 15 Punkte, aber diesen zählen wir wieder nicht. Und schließlich erstellen wir am Dienstag der dritten Woche ein Inkrement. Jetzt, wenn wir die Inkremente der ersten Woche löschen, erfüllt die Gesamtzahl der Inkremente die festgelegten Retentionanforderungen.
Wie bereits oben erwähnt, ist es in dieser Methode äußerst wichtig, dass vollständige Backups regelmäßig erstellt werden. Nehmen wir an, wenn der Hauptretention auf 7 Tage eingestellt ist, aber nur 1 Jahrespunkt existiert, ist es nicht schwer vorzustellen, dass die Inkremente deutlich mehr als 7 ansammeln werden. In solchen Fällen ist es besser, die synthetische Methode zur Erstellung von GFS zu verwenden.
Und wieder „Gelöschte Elemente entfernen“
Diese Option ist auch für BCJ verfügbar:
Die Logik dieser Option ist hier die gleiche wie bei normalen Backup-Jobs – wenn die Maschine eine angegebene Anzahl von Tagen nicht bearbeitet wird, werden ihre Daten aus der Kette entfernt. Bei BCJ ist der Nutzen dieser Option jedoch objektiv höher, und das ist der Grund.
Im normalen Modus arbeitet BCJ im endlos inkrementellen Modus, daher wird, wenn zu irgendeinem Zeitpunkt die Maschine aus dem Job entfernt wird, der Retention-Prozess nach und nach alle Wiederherstellungspunkte entfernen, bis nur noch einer verbleibt – im VBK. Stellen wir uns nun vor, dass der Job immer noch so eingestellt ist, dass synthetische GFS-Punkte erstellt werden. Wenn die Zeit gekommen ist, muss der Job GFS für alle Maschinen in der Kette erstellen. Wenn eine Maschine überhaupt keine neuen Punkte hat – na ja, dann müssen wir den verwenden, den wir haben. Und das jedes Mal. Am Ende kann eine solche Situation entstehen:
Achten Sie auf den Abschnitt Dateien: Wir haben ein Haupt-VBK und 2 wöchentliche GFS-Punkte. Und jetzt schauen Sie auf den Abschnitt Wiederherstellungspunkte – in diesen Dateien liegt tatsächlich das gleiche Abbild der Maschine. Es hat natürlich keinen Sinn, solche GFS-Punkte zu haben, sie nehmen nur Platz ein.
Eine solche Situation kann nur bei Verwendung synthetischer GFS auftreten. Um dies zu verhindern, verwenden Sie die Option „Gelöschte Elemente entfernen“. Vergessen Sie jedoch nicht, sie auf eine angemessene Anzahl von Tagen einzustellen. Der Support hat Fälle gesehen, in denen die Option auf weniger Tage eingestellt wurde als das Synchronisationsintervall – BCJ begann verrückt zu spielen und entfernte Punkte, bevor sie erstellt werden konnten.
Bitte beachten Sie auch, dass diese Option bereits erstellte GFS-Punkte nicht berührt. Wenn Sie Archive bereinigen möchten, müssen Sie dies manuell tun – indem Sie mit der rechten Maustaste auf die Maschine klicken und „Vom Speicher löschen“ auswählen (vergessen Sie nicht, im erscheinenden Fenster die Option „GFS-Vollbackup entfernen“ zu aktivieren):
Neuheit v.10 – sofortige Kopie (immediate copy)
Nachdem wir die „klassischen“ Funktionen durchgegangen sind, kommen wir zur Neuheit. Es gibt eine Besonderheit, aber sie ist sehr wichtig. Es handelt sich um einen neuen Betriebsmodus.
Es gibt kein Konzept wie "Synchronisationsintervall". Der Auftrag wird ständig prüfen, ob neue Punkte hinzugekommen sind, und diese alle kopieren, egal wie viele es sind. Dabei bleibt der Auftrag inkrementell, das heißt, selbst 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 arbeiten nach den oben beschriebenen Regeln (allerdings ist hier nur synthetisches GFS verfügbar).
Die Laufwerke drehen sich. Eigenschaften von Repositories mit rotierenden Laufwerken
Die ständige Bedrohung durch Ransomware hat es zur de facto Sicherheitsstandard gemacht, eine Kopie der Daten auf einem Medium zu haben, auf das der Virus nicht zugreifen kann. Eine Möglichkeit besteht darin, Repositories mit rotierenden Laufwerken zu verwenden, bei denen die Laufwerke abwechselnd eingesetzt werden: Während ein Laufwerk verbunden und zum Schreiben verfügbar ist, werden die anderen an einem sicheren Ort aufbewahrt.
Um B&R beizubringen, mit solchen Repositories zu arbeiten, müssen in den Repository-Einstellungen, im Schritt Repository, die Schaltfläche Erweitert angeklickt und die entsprechende Option ausgewählt werden:
Danach wird VBR erwarten, dass die bestehende Kette regelmäßig aus dem Repository verschwindet, was die Rotation des Laufwerks bedeutet. Je nach Art des Repositories und der Art des Auftrags wird sich B&R unterschiedlich verhalten. Das lässt sich in der folgenden Tabelle darstellen:
Betrachten wir jede Möglichkeit.
Standardauftrag und Windows-Repository
Wir haben also einen Auftrag, der Ketten auf das erste Laufwerk speichert. Bei der Rotation verschwindet die erstellte Kette faktisch, und der Auftrag muss irgendwie mit diesem Verlust umgehen. Trost findet er in der Erstellung eines vollständigen Backups. Somit bedeutet jede Rotation ein vollständiges Backup. Aber was passiert mit den Punkten auf dem ausgeschalteten Laufwerk? Sie werden gespeichert und bei der Berechnung der Retention berücksichtigt. So ist die angegebene Anzahl der Punkte im Auftrag die Anzahl, die auf allen Laufwerken gehalten werden muss. Ein Beispiel:
Der Auftrag läuft im unendlich-inkrementellen Modus und ist so eingestellt, dass 3 Wiederherstellungspunkte gespeichert werden. Aber wir haben auch ein zweites Laufwerk, und wir führen einmal pro Woche eine Rotation durch (es kann auch mehr als zwei Laufwerke geben, was die Essenz nicht ändert).
In der ersten Woche wird die Aufgabe Punkte auf der ersten Festplatte erstellen und überflüssige zusammenführen. Somit wird die Gesamtanzahl der Punkte drei betragen:
Dann verbinden wir die zweite Festplatte. Bei der Ausführung wird B&R bemerken, 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 speichern. Die Gesamtsituation wird folgendermaßen aussehen:
Schließlich verbinden wir die erste Festplatte erneut. Vor dem Erstellen eines neuen Punktes wird die Aufgabe überprüfen, wie es mit dem Retention ist. Und die Retention, erinnere ich daran, ist so eingestellt, dass 3 Punkte gespeichert werden. Inzwischen haben wir 3 Punkte auf Festplatte 2 (aber sie ist abgeschaltet und wird an einem sicheren Ort aufbewahrt, wo B&R nicht zugreifen kann) und 3 Punkte auf Festplatte 1 (und diese ist angeschlossen). Das bedeutet, wir können 3 Punkte auf Festplatte 1 ohne Bedenken löschen, da sie die Retention überschreiten. Danach erstellt die Aufgabe ein vollständiges Backup, und unsere Kette sieht dann so aus:
Wenn die Retention so eingestellt ist, dass Tage anstelle der Anzahl der Punkte gespeichert werden, ändert sich die Logik nicht. Außerdem wird GFS-Retention bei der Verwendung von Repositories mit Rotationsfestplatten überhaupt nicht unterstützt.
Eine gewöhnliche Aufgabe und ein Linux-Repository für Netzwerkspeicher.
Diese Variante ist ebenfalls möglich, wird aber insgesamt weniger empfohlen aufgrund der auferlegten Beschränkungen. Auf die Rotationsfreigabe und das Verschwinden der Kette wird die Aufgabe ebenfalls reagieren – durch die Erstellung eines vollständigen Backups. Das Limit ist mit dem abgeschnittenen Mechanismus der Retention verbunden.
Hier wird bei der Rotation 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 leicht zu erraten, dass solche vergessenen Ketten irgendwann das gesamte Repository füllen werden.
Die Lösung besteht darin, DWORD ForceDeleteBackupFiles hinzuzufügen, wie auf dieser Seite angegeben: . Danach wird die Aufgabe einfach alle Inhalte des Auftragsordners oder des Repository-Ordners (abhängig vom Wert) bei jeder Rotation löschen.
Allerdings ist das keine elegante Retention, sondern einfach das Löschen aller Inhalte. Leider gab es im Support Fälle, in denen als Repository einfach das Wurzelverzeichnis der Festplatte angegeben war, wo neben den Backups auch andere Daten lagen. All dies wurde bei der Rotation zerstört.
Darüber hinaus funktioniert die Funktion ForceDeleteBackupFiles für alle Repository-Typen, das bedeutet, dass auch Repositories auf Windows die Retention nicht mehr anwenden und den Inhalt löschen werden. Mit anderen Worten, eine lokale Festplatte auf Windows ist die beste Wahl für solch ein Backup-Speichersystem.
Backup-Kopie und Windows-Repository
Mit BCJ wird alles noch interessanter. Nicht nur, dass es ein vollwertiges Retention-System gibt, sondern es ist auch nicht erforderlich, bei jedem Wechsel der Festplatte ein vollständiges Backup zu erstellen! So funktioniert es:
Zunächst beginnt B&R mit der Erstellung von Punkten auf der ersten Festplatte. Angenommen, wir haben die Retention auf 3 Punkte eingestellt. Der Job wird im unendlich-incrementellen Modus arbeiten und alles Überflüssige zusammenfassen (ich erinnere daran, dass GFS-Retention in diesem Fall nicht unterstützt wird).
Dann schließen wir die zweite Festplatte an. Da es noch keine Kette darauf gibt, erstellen wir ein vollständiges Backup, danach haben wir eine zweite Kette mit drei Punkten:
Schließlich ist es an der Zeit, die erste Festplatte erneut anzuschließen. Und hier beginnt die Magie, denn der Job wird kein vollständiges Backup erstellen, sondern einfach die inkrementelle Kette fortsetzen:
Danach wird es auf jeder Festplatte eine eigene unabhängige Kette geben. Daher bedeutet Retention hier nicht die Anzahl der Punkte auf allen Festplatten, sondern die Anzahl der Punkte auf jeder Festplatte einzeln.
Backup-Kopie und Linux-Repository Netzwerkstorage
Und erneut verliert die gesamte Eleganz ihren Reiz, wenn das Repository nicht auf einer lokalen Windows-Festplatte ist. Dieses Szenario funktioniert ähnlich wie oben beschrieben mit einem einfachen Job. Bei jeder Rotation wird BCJ ein vollständiges Backup erstellen, während die bestehenden Punkte vergessen werden. Um nicht ohne Speicherplatz dazustehen, sollte DWORD ForceDeleteBackupFiles verwendet werden.
Fazit
So haben wir in diesem umfangreichen Text zwei Arten von Jobs behandelt. Natürlich gibt es viel mehr Jobs, aber es ist nicht möglich, alle in einem einzigen Artikel zu betrachten. Wenn Sie nach dem Lesen noch Fragen haben, schreiben Sie sie bitte in die Kommentare, ich beantworte sie gerne persönlich.
Quelle: habr.com
