Im vorherigen Artikel Wir haben Ihnen von den neuen Funktionen im im Januar veröffentlichten Update 4 für Veeam Backup & Replication 9.5 (VBR) erzählt, bei dem wir absichtlich keine Backups auf Magnetbändern erwähnt haben. Es wäre eine eigene Erzählung wert, denn es gibt tatsächlich viele neue Funktionen.

– Leute von QA, schreibt ihr einen Artikel?
– Warum nicht!

Magnetbänder im 21. Jahrhundert

Die Speicherung von Daten auf Magnetbändern (Kassetten, „Bändern“, wie wir sie in R&D nennen) ist nicht auf den in die Vergangenheit gehörenden Computer ZX-Spectrum beschränkt, dessen ein Spiel mehrere Minuten benötigte, um in den 48 kb RAM von einer Magnetbandkassette geladen zu werden. In einem Vierteljahrhundert haben sich die Geschwindigkeiten und Kapazitäten von Kassetten um 6 bis 7 Größenordnungen erhöht. Diese Vergleich ist nicht ganz korrekt, und den Moore'schen Gesetz Standard Die meisten Pakete wurden unter Verwendung der Technologie folgt man nicht. Dennoch ermöglichen moderne Technologien, auf einer Kilometer langen Kassette 12 Terabyte Daten (bis zu 30 Terabyte im Komprimierungsmodus) zu speichern, wodurch ein 160-Dollar-Speicher die Konkurrenz hinsichtlich der Kosten für eine langfristige Speicherung großer Datenmengen selbst unter Berücksichtigung der Investitionen in Aufnahme- /Lesegeräte hinter sich lässt. Daten auf solchen Kassetten werden zuverlässig 15-30 Jahre lang gespeichert.

Ich werde es von einer anderen Seite betrachten. In letzter Zeit sind Ransomware auf ein neues Niveau gestiegen. Sie können wochen- und monatelang in der Infrastruktur eines großen Unternehmens auf ihren Moment warten, und mit dem Auftreten einer neuen Zero-Day-Sicherheitslücke können sie (nicht ohne menschliche Hilfe, denn es geht um viel Geld) nicht nur alle Daten, sondern auch alle Backup-Kopien, die nur erreichbar sind, vernichten. Hier aktuelles Beispielmusste ein Unternehmen Lösegeld an die Erpresser zahlen. Die sogenannten Air Gap, d.h. physisch von der Infrastruktur isolierte Backups, sind im Grunde die einzige zuverlässige Rettung vor solchen Situationen geworden. Magnetband ist hier eine der zeitlosen Lösungen.

Aber allein mit Spezifikationen und technologischen Neuheiten wie Eisen- und Barium-Ferrit von führenden Herstellern (IBM, HPE, Oracle, Dell) können Daten nicht zuverlässig geschützt werden; es wird gute Software benötigt. Bei Veeam gibt es ein ganzes Team, das sich mit Bandbackups beschäftigt, etwa 10 Personen analysieren, planen, forschen, entwickeln und testen täglich. Die Ergebnisse dieser Arbeit konnten Sie in vorherigen Artikeln sehen (eins, zwei). Was wurde also im letzten Jahr getan?

Glossar

Es steht die Wahl zwischen Freiheiten in Bezug auf die eigene Sprache und die die Lesbarkeit erschwerenden Bürokratismen an. Ich bevorzuge Letzteres, daher bitte ich im Voraus um Entschuldigung, falls einige der Fachbegriffe aus der folgenden Liste jemandem unangenehm auffallen. Hier möchte ich auch kurz daran erinnern, was jeder Begriff bedeutet.

Die Experten von VBR können diesen Teil überspringenJob – job – eine Sicherungsaufgabe. Im Grunde basiert das gesamte VBR auf Jobs. Neben Backup und Replikation kann dies auch das Kopieren auf Magnetband (backup to tape job, Tape-Job) umfassen. Ich möchte darauf hinweisen, dass die Wiederherstellung aus einem Backup (Restore) ebenfalls ein Job ist, in diesem Artikel wird mit diesem Begriff jedoch speziell das Backup gemeint.

Storage – storage – ein historisch gewachsenes Bezeichnung. Dies sind Dateien in das Repository (repository – Speicher), die Backups enthalten – vollständig und inkrementell. In einem Storage können sowohl eine als auch mehrere virtuelle Maschinen vorhanden sein.

Kette – chain – eine Sequenz von miteinander verbundenen Storages. Für die Wiederherstellung von Daten aus einem n-ten inkrementellen Storage sind alle vorherigen von (n-1) bis 1 sowie der vollständige Storage erforderlich, auf den sich der erste inkrementelle bezieht.

Source, Target – source, target. Source – die ursprüngliche Entität, die vom Job verarbeitet wird. Bei Backups/Repliken handelt es sich in der Regel um eine virtuelle Maschine im Hypervisor. Im Falle eines Tape-Jobs ist die Source der eigentliche Backup-Job (oder die Dateien im Falle eines File to tape-Jobs). Das Target für Backup-Jobs ist das Repository, in dem die Backups gespeichert werden. Bei Tape-Jobs handelt es sich um den Medien-Pool.

Medien-Pool – media pool – ein Pool von Speichermedien, in unserem Fall – Kassetten. Ein logischer Container, der vom Benutzer erstellt wird und Kassetten einer oder mehrerer Bibliotheken enthält. Somit hat ein Tape-Job immer einen Medien-Pool als Target, das heißt, die Daten werden nicht auf eine bestimmte Kassette oder auf eine beliebige Kassette in der Bibliothek geschrieben, sondern auf eine bestimmte Gruppe davon. Der Medien-Pool hat eine Einstellung zur Aufbewahrungsdauer der Daten, nach deren Ablauf die Kassette überschrieben werden kann. Benutzer können sowohl gewöhnliche (standard) als auch GFS-Pools. Jeder dieser Typen kann nun auch WORM und non-WORM sein, dazu später mehr.

Medien-Set – media set – Kassettensätze im Medienpool, auf die kontinuierlich Backups/Dateien geschrieben werden. Für GFS-Pools haben die Medien-Sets auch eine Bindung an das Intervall (zum Beispiel jährlich – yearly), Kassetten rotieren nur innerhalb ihres Intervalls.

Laufwerk, Wechsler – Elemente der Tape-Bibliothek. Das Laufwerk liest und spult die Kassette, der Wechsler – das ist ein Roboter, der die Kassetten zwischen den Lager- und Ausgabeschächten sowie dem Laufwerk bewegt. Es gibt auch Standalone-Laufwerke (standalone – unabhängig), hier übernimmt eine Person die Rolle des Wechslers. Für das Laufwerk ist ein korrekt installierter Hersteller-Treiber auf einer Windows-Maschine erforderlich, an die die Bibliothek angeschlossen ist; mit dem Wechsler können wir jedoch auch ohne Treiber über native SCSI arbeiten.

Tenant to tape. Der Anbieter schützt – die Kunden sind geschützt

Legt gleich die Karten auf den Tisch. Die umfangreichste Funktion unseres Updates, die für Cloud-Anbieter, die in ihrer Infrastruktur VBR verwenden, entwickelt wurde. Die Entwicklung begann bereits vor zwei Jahren. Bald haben wir gemerkt, dass wir mit dieser ernsthaften Aufgabe bis zum nächsten Release nicht fertig werden würden, haben eine kurze Pause eingelegt und letztendlich die Funktion in Update 9.5, Update 4 veröffentlicht.

Kurz gesagt, jetzt haben Anbieter die Möglichkeit, Backups ihrer Kunden auf Kassetten mit Hilfe von Tape-Jobs im GFS-Pool zu kopieren. Das gibt den Anbietern – und das sind große, uns sehr am Herzen liegende und kommerziell wichtige Jungs – zwei Möglichkeiten:

• ihre Kunden (Mieter, tenant – Mieter) vor Datenverlust durch versehentliches Löschen oder infrastrukturelle Probleme ("Überschwemmung im Serverraum") zu schützen;
• ihren Mietern einen zusätzlichen Service zur Wiederherstellung von Daten aus einem alten Backup anzubieten, das gemäß der Aufbewahrungsrichtlinie bereits aus dem Cloud-Repository gelöscht wurde, aber auf den Kassetten nach wie vor vorhanden ist.

Aus Marketingsicht ist die Funktionalität sehr "geschmackvoll", aus unserer Sicht jedoch nicht weniger komplex in der Umsetzung.

Entwicklung

Das Hauptproblem, das entstanden ist, ist die Verschlüsselung der Daten. Die meisten Cloud-Backups sind verschlüsselt, die Statistik spricht von ⅔ der Gesamtzahl. Diese Zahl war für uns eine Überraschung, wir hatten vermutet, dass fast alles verschlüsselt wird, aber das stimmt nicht – viele Kunden scheinen bedingungslos Vertrauen in ihre Anbieter zu haben.

Die Praxis ist einfach: Der Provider sollte die Daten seiner Mandanten nicht entschlüsseln können. Im Rahmen eines neuen Features müssen jedoch Speichereinheiten mit Backups auf der Seite des Providers geöffnet werden. Dies ist notwendig, um Datenblöcke zu verschieben, zum Beispiel zur Erstellung eines vollständigen virtuellen Backups. Wichtig ist, dass dies unabhängig vom Mandanten geschehen muss, wenn die erforderlichen Schlüssel während der Ausführung des Jobs nicht an den Provider übermittelt werden.

Die Lösung dieses Problems, die übrigens auch in einem anderen wichtigen Feature des kürzlich veröffentlichten Updates verwendet wird – Kapazitätsstufe – besteht in der Hinzufügung eines zusätzlichen Verschlüsselungsschlüssels. Der Archivschlüssel (Archive key) wird in der Datenbank des Providers in verschlüsselter Form gespeichert. Mit Hilfe eines ausgeklügelten Verfahrens kann der Provider den Speicher öffnen, Datenblöcke zwischen den Speichern verschieben und neu verschlüsseln (da jeder – seinen eigenen Schlüssel hat), aber die Daten selbst können nicht entschlüsselt werden.

Ausgeklügeltes Verfahren (funktionsfähige Variante)

Ich möchte hinzufügen, dass alle Ingenieure in R&D Verschlüsselung in unserem Produkt sehr schätzen, obwohl niemand alle Details darüber kennt, wie es funktioniert. (Es gab hier noch einen Witz „und warum funktioniert es überhaupt“, aber den haben die Redakteure nicht durchgelassen.)

Tests

Für das Feature wurden Hunderte von Fehlern gemeldet. Die kompliziertesten Bereiche sind – Verschlüsselung, Benutzeroberfläche, Probleme beim Restore.

Aus der Perspektive des Testens stellte die große Variabilität eine Herausforderung dar, die „Kombinatorik“ der Arten und Typen von Mandantenjobs und Repositories – sowohl für die Quelle als auch für das Ziel beim Wiederherstellen der Backups in die Infrastruktur. All dies ist an die Logik des GFS-Modells (einschließlich des neuen – Parallelität und tägliche Mediensets, dazu später mehr), und insgesamt an die für Teips ungewohnte Cloud-Spezifik angepasst. Vergessen Sie nicht, reichlich mit Verschlüsselung zu würzen. Wenn ich die Metapher fortsetzen darf, haben wir uns an diesem Gericht förmlich überfressen – es aus allen Perspektiven genossen.

Ein Abschnitt des Testplans

Infolgedessen

Detaillierte Informationen finden Sie in Benutzerhandbuch (vorerst auf Englisch): Backup, Wiederherstellung. Ich werde auf die wesentlichen Punkte eingehen.

Backup

Der Provider fügt Mandanten zu der Tape-Job mit dem GFS-Pool als Ziel hinzu. Falls eine Cloud-Lizenz vorhanden ist, steht im zweiten Schritt des Wizards die Option zur Verfügung MandantenMan kann alle Tenants sofort oder einzeln hinzufügen oder auch nur ein bestimmtes Kontingent (aber kein Sub-Kontingent) eines einzelnen Tenants auswählen. Es ist nicht erlaubt, tenant-spezifische Backups mit normalen lokalen Backups in einer einzigen Aufgabe zu vermischen.

Die anderen Einstellungen sind fast identisch mit einer normalen Aufgabe im GFS-Pool.

Eine Datenwiederherstellung ist sowohl auf der Seite des Anbieters als auch auf der Seite des Tenants möglich.

Wiederherstellung auf der Seite des Anbieters

Wird über den neuen Assistenten durchgeführt. Hier kann man bis zu einer einzelnen Aufgabe hinuntergehen, es wird die gesamte Kette wiederhergestellt, die zu einem bestimmten Zeitpunkt im Repository war.

Es gibt drei Wiederherstellungsoptionen:

1. An den ursprünglichen Standort. In diesem Fall wird das Original-Backup, sofern vorhanden, gelöscht; die Aufgaben des Tenants werden automatisch auf die wiederhergestellte Kette umgestellt. Es wird davon ausgegangen, dass diese Wiederherstellung für den Kunden völlig unbemerkt bleibt; lediglich für kurze Zeit wird er von dem Cloud-Repository getrennt.
2. In ein neues Kontingent/Repository. Der Anbieter kann beispielsweise ein separates temporäres Konto für diesen Zweck erstellen, das später gelöscht wird. Das Backup erscheint in der Infrastruktur des Tenants nach der Synchronisation mit der Basis des Anbieters.
3. Einfach auf die Festplatte eines Linux- oder Windows-Servers, der in der Infrastruktur des Anbieters registriert ist. Diese Kette kann dann auf einen USB-Stick geschrieben und an den Tenant gesendet werden.

Wiederherstellung auf der Seite des Tenants

Diese Option setzt voraus, dass der Kunde über seine eigene Tape-Infrastruktur und einen großen Datenumfang für die Wiederherstellung verfügt. Das Band mit den gespeicherten Backups kann vom Anbieter physisch an den Kunden per Lieferdienst gesendet werden, dieser katalogisiert es auf seiner Hardware, entschlüsselt die Bänder und Backups und arbeitet mit den Sicherungskopien, als ob er sie selbst auf das Band geschrieben hätte. So ein Lifehack, um Terabyte über WAN nicht herunterladen zu müssen.

Großartige Verbesserungen des GFS-Pools

GFS-Medienpools wurden vor zwei Jahren in VBR in Version 9.5 eingeführt. Im neu veröffentlichten Update haben wir diese Funktionalität sowohl wegen der Einführung der Tenant-to-Tape-Funktion als auch auf Anfrage der Benutzer erheblich verbessert.

Tägliche Medien-Sets

Es gibt ein neues tägliches (daily) Mediasatz. Nun können im GFS-Pool Backups für jeden Tag gespeichert werden, und nicht nur vollständige, sondern auch inkrementelle. Letztere benötigen erheblich weniger Platz und wurden zur Einsparung von Bandbreite eingeführt. Es wird vorausgesetzt, dass diese Kassetten ständig in der Bibliothek rotiert werden und nicht zur Fernlagerung transportiert werden. Für die Wiederherstellung aus einem inkrementellen Punkt werden Kassetten eines der älteren Mediasätze (wöchentlich, monatlich, vierteljährlich oder jährlich) benötigt. Es ist nicht möglich, einen täglichen Mediasatz ohne einen Wochenmediasatz einzuschließen, da in den meisten Fällen zur Wiederherstellung aus dem inkrementellen Backup genau die wöchentlichen Kassetten benötigt werden. Diese befinden sich entweder immer in der Bibliothek oder werden in einem nicht so entfernten Lager aufbewahrt.

Logik der Tape-Jobs im GFS-Mediapool nicht ganz einfach, technische Autoren werden das bestätigen. Kurz gesagt, ohne ins Detail zu gehen, werden in wöchentlichen und älteren Mediasätzen nur vollständige Backups (einschließlich virtueller vollständiger Backups) kopiert, jeweils eines für jedes Datum, während im täglichen Mediasatz alle im Repository befindlichen Backups für den aktuellen Tag gespeichert werden, da die Backup-Jobs öfter als einmal täglich gestartet werden können.

Parallelität, Startzeit und Wartezeit in GFS-Pools

Jetzt ist es möglich, mehrere Chains oder Jobs parallel auf mehreren Laufwerken der Bibliothek im GFS-Mediapool zu schreiben (früher nur in normalen Pools). Dies wird in Schritt Optionen des Mediapools aktiviert.

Wichtige Klarstellung: dieselbe Datei wird immer in einen Stream geschrieben, daher wird empfohlen, bei mehreren großen virtuellen Maschinen die per-VM-Einstellung im Repository zu aktivieren, damit das Backup aus mehreren Chains besteht.

Darüber hinaus ist es jetzt möglich, die Startzeit des GFS-Jobsfestzulegen. Vielen Nutzern gefiel der Start um Mitternacht und die anschließende Wartezeit von fast einem ganzen Tag, bis der Quelljob abgeschlossen ist, nicht. Jetzt kann diese Zeit beispielsweise auf den späten Abend festgelegt werden, wenn bereits Daten auf das Band zu kopieren sind. Darüber hinaus haben wir auf Wunsch der Nutzer die Option in die erweiterten Einstellungen aufgenommen, die zuvor nur über einen Registrierungsschlüssel aktiviert werden konnte. Es reicht aus, Die aktuellste Wiederherstellungspunkt verarbeiten, anstatt zu warten – und auf die Kassette wird das kopiert, was im Repository zum Zeitpunkt des Starts des Tape-Jobs vorhanden ist (zum Beispiel der Punkt für den gestrigen Tag), es gibt überhaupt keine Wartezeit.

Optimierte Arbeit mit mehreren Bibliotheken

Es geht um eine Situation, in der mehr als eine Bibliothek zu einem Medienpool hinzugefügt wurde. Wir haben das auch früher unterstützt, aber hin und wieder kamen Kunden mit Beschwerden über unvorhersehbares Verhalten.

War

Beispielsweise wurde ein Tape-Job gestartet, der zwei Laufwerke in der ersten Bibliothek belegte, aber die Parallelitätseinstellungen ermöglichen die Nutzung von bis zu vier Laufwerken. Soll dieser Job auf die zweite Bibliothek des Medienpools umschalten und diese ebenfalls nutzen, oder wäre das ein Ressourcenverbrauch?

Ein anderer Fall. Die Option, beim Zustand "keine verfügbaren Kassetten" umzuschalten, wurde gewählt, in der ersten Bibliothek gibt es nur eine Kassette, aber darauf können potenziell alle Daten passen. Die Einstellungen erlauben jedoch ein paralleles Schreiben auf zwei Kassetten. Soll in diesem Fall die zweite Bibliothek genutzt werden?

Wir haben beschlossen, diesen Bereich zu ordnen, indem wir die Möglichkeit geschaffen haben, das Verhalten ausdrücklich zu konfigurieren.

Wurde

Die Bibliotheken im Medienpool haben Rollen – aktiv und passiv. Und der Medienpool selbst hat zwei Modi: ausfallsicher oder Failover (failover) und paralleles Schreiben (paralleling). Jetzt kann der Medienpool je nach Anforderungen unterschiedlich konfiguriert werden.

• Wenn Sie mehrere gleichberechtigte Bibliotheken haben und das Schreiben in diese parallelisieren müssen – aktivieren Sie den Modus für paralleles Schreiben, wobei allen Bibliotheken aktive Rollen zugewiesen werden müssen. In diesem Fall werden neue Kassetten und Laufwerke sofort genutzt, sobald dies erforderlich ist, unabhängig davon, in welcher Bibliothek sie sich befinden. Es gibt jedoch immer noch eine Priorität – zunächst versuchen wir, Ressourcen in der höher eingestuften Bibliothek zu finden.
• Wenn jedoch eine Hauptbibliothek und ein älteres oder Standalone-Laufwerk als Reserve vorhanden sind, aktivieren Sie den Failover-Modus, indem Sie die Hauptbibliothek an die Spitze der Liste setzen und eine passive Rolle für die Reservelaufwerke wählen. Der Umschaltung auf ein solches Gerät erfolgt nur, wenn dies wirklich notwendig ist, damit der Job überhaupt irgendwie funktioniert. Eine solche Situation wird als Ausnahme betrachtet, über die eine Benachrichtigung per E-Mail gesendet wird.

Es gibt eine komplexere Situation, die wir derzeit nicht unterstützen – mehrere aktive Bibliotheken in Anwesenheit von passiven. Das Feedback wird zeigen, ob es Bedarf an solchen Konfigurationen gibt und ob die Funktion in Zukunft verbessert werden muss. Standardpraxis.

WORM-Unterstützung

WORM – Write Once Read Many – Kassetten, die nicht gelöscht oder überschrieben werden können auf Hardware-Ebene, es können nur Daten hinzugefügt werden. Ihre verpflichtende Nutzung wird durch die Vorschriften einiger Organisationen, beispielsweise im Gesundheitswesen, geregelt. Das Hauptproblem mit solchen Kassetten war früher, dass VBR bei Inventarisierung oder Katalogisierung einen Header aufzeichnete, der später nicht mehr gelöscht werden konnte, und Tape-Jobs bei einem solchen Versuch mit einem Fehler abbrachen.

In Update 4 von 9.5 wurde die vollständige Unterstützung solcher Kassetten eingeführt. WORM-Mediapools, sowohl normal als auch GFS, wurden hinzugefügt, in die nur Kassetten dieses Typs platziert werden können.

Neue Kassetten haben ein blaues, "eingefrorenes" Symbol. Aus Sicht des Benutzers unterscheidet sich die Arbeit mit WORM-Kassetten nicht von der Arbeit mit normalen.

Die "Wormigkeit" der Kassetten wird ursprünglich durch das Suffix des Barcodes, bestimmt, wenn der Barcode jedoch normal oder unleserlich ist, gibt der Treiber bei der ersten Einfügung der Kassette die Informationen zurück. WORM-Kassetten in einen normalen Mediapool zu legen und auf ihnen zu schreiben, ist nicht möglich. Lustiges Detail: Es gibt bereits Benutzer, die WORM-Barcodes auf normalen Kassetten angebracht haben und von den Veränderungen in ihrer Infrastruktur nach dem Update überrascht waren.

Chip der Kassette

Gleichzeitig mit der Einführung von nicht beschreibbaren Kassetten begann die Arbeit mit dem Chip.Standardattribute im Chip wurden von uns früher nicht verwendet, jetzt lesen und schreiben wir in einige von ihnen, betrachten sie jedoch nicht als primäre Datenquelle. Der Hauptorientierungspunkt bleibt nach wie vor der Header der Kassette. Diese Entscheidung stellte sich als richtig heraus: Nach einem Monat nach dem Release sehen wir, wie die "Tierwelt" der Hardware der Benutzer Überraschungen im Hinblick auf die Arbeit mit dem Chip bereitet.

Backup von NDMP-Volumes auf Band

Abschließend – zur gefragtesten Funktion dieses Updates, die am häufigsten kommentiert wurde. Das Backup von NDMP-Volumes auf Kassetten ist nun verfügbar. In die VBR-Infrastruktur muss ein NDMP-Server hinzugefügt werden, wonach es in der Dateibänder-Job möglich sein wird, Volumes von diesem Host auszuwählen. Diese werden als Dateien mit einem speziellen Attribut auf die Bänder geschrieben, um sie bei der Katalogisierung von normalen zu unterscheiden.

In der ersten Implementierung gibt es bestimmte Einschränkungen: Erweiterungen werden nicht unterstützt, außerdem ist ein Backup und Restore nur des gesamten Volumes möglich, nicht von einzelnen Dateien. Das Backup erfolgt über dump (im Fall von NetApp - ufsdump), hier gibt es besondere Merkmale: Die maximale Anzahl an inkrementellen Punkten beträgt 9, danach wird ein vollständiges Backup erzwungen.

Als Fazit

Dies waren nur die wichtigsten Neuerungen im Bereich Tape-Backup in VBR 9.5 Update 4. Weitere Änderungen werde ich in einer Liste anführen:

• Möglichkeit zur Festlegung der Reihenfolge von Quell-Jobs und Dateien in Tape-Jobs;
• Die Rolle des Tape Operators wurde hinzugefügt (der Benutzer kann alles tun, außer vom Band wiederherzustellen - dafür gibt es den Restore Operator);
• Vollwertige Include/Exclude-Masken wurden in den Dateibändern-Job integriert (außer NDMP);
• Die Wiederherstellung im Dateibänder-Job wurde verbessert (der Ordner wird mit den Dateien wiederhergestellt, die zu dem Zeitpunkt des Backups dort waren und nicht mit allen, die jemals in der Backup-Historie dort waren - eine sehr gefragte Funktion, übrigens);
• Die Geschwindigkeit der Wiederherstellung einer sehr großen Anzahl von Dateien von Bändern wurde erhöht;
• Der Algorithmus zur Auswahl des nächsten Bandes zum Schreiben wurde verbessert, insbesondere wird bei gleichen Bedingungen das gesamte geschriebene/gelesene Datenvolumen während seiner Lebensdauer berücksichtigt, wobei das aktuellste Band genommen wird;
• Die Stabilität des Produkts wurde verbessert.

Nützliche Links

Zur Abwechslung nenne ich ein paar Links zu russischsprachigen Ressourcen:

• Link zum Download der kostenlosen Testversion VBR 9.5 Update 4
• Artikel auf Habr „Nützliche Tipps zur Archivierung von Veeam-Backups auf Magnetband“
• Artikel auf Habr „7 nützliche Tipps zum Schutz von Backups vor Ransomware“
• Abschnitt des Benutzerhandbuchs, der sich auf Bänder bezieht (in englischer Sprache)
• Und wir sind zurück an gewohnter Stelle mit den Überblicksvideos „Wie es funktioniert“ (zwar bisher nur in englischer Sprache) - man kann sich diese ansehen hier. Über Bänder wird in den Folien 95 – 102 gesprochen.

Quelle: habr.com