In im vorherigen Artikel Wir haben Ihnen die neuen Funktionen im im Januar veröffentlichten Update 4 für Veeam Backup & Replication 9.5 (VBR) vorgestellt, wobei wir bewusst keine Backups auf Magnetbändern erwähnt haben. Eine Darstellung dieses Bereichs verdient einen eigenen Artikel, da es wirklich viele neue Funktionen gab.

– Leute aus QA, wollt ihr einen Artikel schreiben?
– Warum nicht!

Bandlaufwerke im 21. Jahrhundert

Die Datenspeicherung auf Magnetbändern (Kassetten, „Tapes“, wie wir in R&D sie nennen) beschränkt sich nicht auf den in die Vergangenheit entschwundenen Computer ZX-Spectrum, dessen ein Spiel mehrere Minuten benötigte, um 48 kb RAM von einer Kassettenlaufwerk zu laden. In einem Vierteljahrhundert haben sich die Geschwindigkeiten und Kapazitäten von Kassetten um 6-7 Größenordnungen erhöht. Dies ist kein ganz korrekter Vergleich, und gemäß Moores Gesetz Standard. LTO modern Technologien ermöglichen es jedoch, auf einem Kilometer langen Band von einer Kassette 12 Terabyte Daten (bis zu 30 Terabyte im Kompressionsmodus) zu speichern. Somit bleibt das 160-Dollar-Speichergerät in Bezug auf die Kosten für die langfristige Speicherung großer Datenmengen auch unter Berücksichtigung der Investitionen in Aufzeichnungs- und Lesegeräte den Wettbewerbern weit voraus. Daten auf solchen Kassetten werden zuverlässig 15 bis 30 Jahre lang aufbewahrt.

Ich betrachte es von einer anderen Seite. In letzter Zeit sind Erpressungsviren auf ein neues Niveau gestiegen. Sie können in der Infrastruktur großer Unternehmen wochenlang und monatelang auf ihre Gelegenheit warten, und mit dem Auftreten einer neuen Zero-Day-Sicherheitslücke – können sie (nicht ohne menschliche Hilfe, denn es stehen große Summen auf dem Spiel) nicht nur alle Daten, sondern auch alle erreichbaren Backups vernichten. Hier aktuelles Beispiel, mussten Unternehmen Lösegeld zahlen. Die sogenannten Air Gaps, d.h. physisch von der Infrastruktur isolierte Backup-Systeme, sind praktisch die einzige zuverlässige Rettung vor solchen Szenarien. Magnetbänder sind hier eine der zeitlosen Lösungen.

Aber eine Spezifikation und technologische Neuheiten von führenden Herstellern (IBM, HPE, Oracle, Dell) reichen nicht aus, um Daten zuverlässig zu schützen; es wird auch gute Software benötigt. Bei Veeam gibt es ein ganzes Team, das sich mit Tape-Backups beschäftigt; etwa 10 Personen analysieren, planen, forschen, entwickeln und testen täglich. Die Ergebnisse dieser Arbeit konnten Sie in den vorherigen Artikeln sehen.eins, zweiWas wurde im letzten Jahr erreicht?

Glossar

Es stellt sich die Wahl zwischen Freiheiten im Umgang mit der eigenen Sprache und solchen Bürokratismen, die das Lesen erschweren. Ich bevorzuge die erste Option und entschuldige mich im Voraus, falls einige der Fachbegriffe aus der folgenden Liste für das Auge unangenehm sein sollten. Hier möchte ich kurz wiederholen, was jeder dieser Begriffe bedeutet.

Die Experten von VBR können diesen Teil überspringen.Job – Job – ein Backup-Auftrag. Tatsächlich basiert das gesamte VBR auf Jobs. Neben Backup und Replikation kann es auch das Kopieren auf Magnetband (Backup to tape job, Tape-Job) umfassen. Ich möchte anmerken, dass die Wiederherstellung aus einem Backup (Restore) ebenfalls ein Job ist, aber in diesem Artikel beziehe ich mich mit dem Begriff speziell auf Backups.

Storage – Speicher – ein historisch gewachsenes Konzept. Es sind Dateien in Repository (Repository – Ablage), die Sicherungskopien enthalten – vollständige und inkrementelle. In einem Speicher können sowohl eine als auch mehrere virtuelle Maschinen vorhanden sein.

Kette – chain – eine Folge miteinander verbundener Speicher. Für die Wiederherstellung von Daten aus dem n-ten inkrementellen Speicher sind alle vorherigen von (n-1) bis 1 und der vollständige Speicher erforderlich, auf den sich der erste inkrementelle bezieht.

Source, Target – source, target. Source – die ursprüngliche Entität, die von der Job verarbeitet wird. Im Falle von Backups/Replikaten ist dies in der Regel eine virtuelle Maschine im Hypervisor. Bei Tape-Jobs ist die Source der Backup-Job selbst (oder die Dateien im Fall eines File-to-Tape-Jobs). Das Target für den Backup-Job ist das Repository, in dem die Backups gespeichert sind. Für Tape-Jobs hingegen ist es der Media-Pool.

Media-Pool – media pool – Pool von Speichermedien, in unserem Fall – Kassetten. Ein logischer Container, der vom Benutzer erstellt wird und Kassetten aus einer oder mehreren Bibliotheken enthält. Eine Tape-Job hat daher immer einen Media-Pool als Ziel, das heißt, die Daten werden nicht auf eine bestimmte Kassette oder auf irgendeine Kassette in der Bibliothek, sondern auf eine definierte Auswahl geschrieben. Der Media-Pool hat eine Einstellung zur Speicherdauer von Daten, nach deren Ablauf die Kassette überschrieben werden kann. Der Benutzer kann reguläre (Standard) und GFS-Pools. Jede dieser Arten kann jetzt auch WORM und non-WORM sein, dazu später mehr.

Media-Set – media set – Set von Kassetten im Media-Pool, auf die kontinuierlich Backups/Dateien geschrieben werden. Für GFS-Pools haben Media-Sets auch eine Bindung an Intervalle (z. B. jährlich), Kassetten rotieren nur innerhalb ihres Intervalls.

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

Mieter zu Band. Der Provider ist geschützt – die Kunden sind geschützt.

Die Karten liegen auf dem Tisch. Die bedeutendste Funktion unseres Updates, die für Cloud-Anbieter, die in ihrer Infrastruktur VBR nutzen. Die Entwicklung wurde vor zwei Jahren begonnen. Bald merkten wir, dass wir dieser ernsthaften Herausforderung bis zur nächsten Veröffentlichung nicht gerecht werden konnten, hielten eine kurze Pause ein und veröffentlichten schließlich die Funktion in Version 9.5 Update 4.

Kurz gesagt, jetzt haben Provider die Möglichkeit, die Backups ihrer Kunden über Tape-Jobs in einen GFS-Pool auf Kassette zu kopieren. Das gibt den Providern – und das sind wirklich große, uns sehr am Herzen liegende und kommerziell wichtige Partner – zwei Vorteile:

• ihre Kunden (Mieter, tenant – Mieter) vor Datenverlust durch versehentliches Löschen oder infrastrukturelle Probleme („Überschwemmung im Rechenzentrum“) zu schützen;
• Mandanten eine zusätzliche Dienstleistung zur Wiederherstellung von Daten aus einem alten Backup anzubieten, das gemäß der Datenspeicherungspolitik bereits lange aus dem Cloud-Repository gelöscht wurde, aber noch auf Bändern vorhanden ist.

Aus Marketingsicht ist die Funktionalität äußerst attraktiv, für uns hingegen nicht weniger kompliziert in der Umsetzung.

Entwicklung

Das grundlegende Problem ist die Verschlüsselung von Daten. Die meisten Cloud-Backups sind verschlüsselt, laut Statistik betrifft dies etwa ⅔ der Gesamtzahl. Diese Zahl hat uns überrascht, wir hatten angenommen, dass nahezu alles verschlüsselt ist, aber viele Kunden scheinen bedingungslos von ihren Anbietern überzeugt zu sein.

Das Paradigma ist einfach: Der Anbieter darf die Daten seiner Mandanten nicht entschlüsseln können. Gleichzeitig erfordert die neue Funktion, dass der Anbieter Speicher mit Backups öffnet. Dies ist notwendig, um Datenblöcke zu übertragen, beispielsweise zur Erstellung von einem vollständigen virtuellen Backup. Wichtig ist, dass dies unabhängig vom Mandanten erfolgt, wenn die erforderlichen Schlüssel während der Ausführung des Jobs nicht an den Anbieter übermittelt werden.

Die Lösung dieses Problems, die übrigens auch in einer anderen wichtigen Funktion des neuen Updates verwendet wird, besteht darin, einen zusätzlichen Verschlüsselungsschlüssel hinzuzufügen. Capacity Tier Der Archivschlüssel wird verschlüsselt in der Datenbank des Anbieters gespeichert. Mit einem cleveren Schema kann der Anbieter damit den Speicher öffnen, Datenblöcke zwischen verschiedenen Speichern verschieben und neu verschlüsseln (denn jeder hat seinen eigenen Schlüssel), aber die Daten selbst können nicht entschlüsselt werden.

Cleveres Schema (Funktionsweise)

Ich füge hinzu, dass alle Ingenieure in der R&D das Verschlüsseln in unserem Produkt sehr schätzen, obwohl niemand genau weiß, wie es in allen Details funktioniert. (Hier gab es auch einen Witz, 'und warum es überhaupt funktioniert', aber den haben die Redakteure nicht durchgelassen.)

Testen

Für die Funktion wurden Hunderte von Bugs dokumentiert. Die anspruchsvollsten Bereiche sind die Verschlüsselung, die Benutzeroberfläche und Probleme beim Wiederherstellen.

Aus Sicht des Testens stellte die hohe Variabilität, die 'Kombinatorik' der Arten und Typen von Tenant-Jobs und Repositories eine Herausforderung dar – ich meine sowohl den Source- als auch den Target-Bereich bei der Wiederherstellung von Backups in die Infrastruktur. All dies ist die Logik im Rahmen des Modells GFS. (einschließlich neu – Parallelisierung und tägliche Media-Sets, mehr dazu unten), und insgesamt auf die für Tape ungewohnte Cloud-Spezifik. Vergessen Sie nicht, reichlich mit Verschlüsselung abzuschmecken. Wenn wir das Bild fortsetzen, so haben wir uns an diesem Gericht satt gegessen – aber auch aus allen Richtungen probiert.

Fragment des Testplans

Infolgedessen

Eine ausführliche Beschreibung finden Sie in Benutzerhandbuch (vorerst auf Englisch): Back-up, Wiederherstellung. Ich möchte auf die wichtigsten Punkte eingehen.

Backup

Der Anbieter fügt Mandanten zur Tape-Job mit einem GFS-Pool als Ziel hinzu. Bei Vorhandensein einer Cloud-Lizenz steht im zweiten Schritt des Wizards die Option zur Verfügung Mandanten. Es können alle Mandanten auf einmal oder einzeln hinzugefügt werden, oder es kann lediglich eine spezifische Quote (aber keine Sub-Quote) eines einzelnen Mandanten ausgewählt werden. Es ist nicht möglich, Mandanten-Backups und gewöhnliche lokale Backups in einem Job zu mischen.

Die restlichen Einstellungen sind fast vollständig identisch mit einem normalen Job im GFS-Pool.

Die Datenwiederherstellung ist sowohl auf der Seite des Anbieters als auch auf der Seite des Mandanten möglich.

Wiederherstellung auf der Seite des Anbieters

Wird über den neuen Wizard ausgeführt. Hier kann man bereits bis zu einem einzelnen Job heruntergehen, die gesamte Kette, die an einem bestimmten Tag im Repository war, wird wiederhergestellt.

Es gibt drei Varianten des Restaurants:

1. In den ursprünglichen Standort. In diesem Fall wird das originale Backup, sofern vorhanden, gelöscht; die Jobs des Tenants werden automatisch auf die wiederhergestellte Kette umgestellt. Es wird davon ausgegangen, dass eine solche Wiederherstellung für den Kunden im Grunde nicht spürbar ist, lediglich für kurze Zeit wird er vom Cloud-Repository getrennt.
2. In das neue Kontingent/Repository. Der Anbieter kann zu diesem Zweck beispielsweise ein separates temporäres Konto 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 kopiert und an den Tenant gesendet werden.

Wiederherstellung auf der Seite des Tenants

Diese Option setzt voraus, dass der Kunde über eine eigene Tape-Infrastruktur und ein großes Datenvolumen für das Restaurant verfügt. Der Anbieter kann die Kassetten mit den gespeicherten Backups physisch per Lieferservice an den Kunden senden. Dieser katalogisiert sie auf seiner Hardware, entschlüsselt die Kassetten und Backups und arbeitet mit den Sicherungskopien, als hätte er sie selbst auf Band aufgezeichnet. So ganz einfach, um Terabytes nicht über das WAN herunterladen zu müssen.

Umfassende Verbesserungen des GFS-Pools

GFS-Medien-Pools wurden vor zwei Jahren mit VBR in Version 9.5 eingeführt. Im kürzlich veröffentlichten Update haben wir diese Funktionalität aufgrund der Einführung der Funktion "Tenant to tape" sowie auf Wunsch der Nutzer erheblich verbessert.

Tägliche Medien-Sets

Es gibt ein neues tägliches (täglich) Medien-Set. Jetzt können im GFS-Pool tägliche Backups gespeichert werden, und zwar nicht nur vollständige, sondern auch inkrementelle. Letztere benötigen erheblich weniger Speicherplatz, was zur Einsparung von Bandbreite dient. Es wird vorausgesetzt, dass diese Kassetten ständig in der Bibliothek rotiert werden und nicht für die Langzeitlagerung abtransportiert werden. Für die Wiederherstellung aus einem inkrementellen Punkt sind jedoch Kassetten eines der älteren Medien-Sets (wöchentlich, monatlich, vierteljährlich oder jährlich) erforderlich. Es ist nicht möglich, das tägliche Medien-Set zu aktivieren, ohne das wöchentliche einzuschließen, da in den meisten Fällen zur Wiederherstellung aus einem inkrementellen Backup wöchentliche Kassetten benötigt werden. Diese befinden sich entweder immer in der Bibliothek oder werden in einem nicht so weit entfernten Lager aufbewahrt.

Logik der Tape-Jobs im GFS-Medien-Pool nicht die einfachste, technische Autoren können das bestätigen. Kurz gesagt, ohne ins Detail zu gehen: Bei wöchentlichen und älteren Medien-Sets werden nur vollständige Backups (einschließlich virtueller vollständiger Backups) kopiert, jeweils eins für jedes Datum, während bei täglichen Sets alle aktuellen Backups im Repository für den laufenden Tag gesichert werden, da der Backup-Job häufiger als einmal täglich gestartet werden kann.

Parallelität, Startzeit und Wartezeit in GFS-Pools

Jetzt ist es möglich, mehrere Ketten oder Jobs parallel auf mehreren Laufwerken der Bibliothek in GFS-Mediapools aufzuzeichnen (zuvor nur in herkömmlichen Pools). Dies wird in Schritt Optionen des Medienpools aktiviert.

Wichtiger Hinweis: dieselbe Datei wird immer in einem Stream geschrieben, daher wird empfohlen, bei mehreren großen virtuellen Maschinen die per-VM-Einstellung im Repositoryzu aktivieren, damit das Backup aus mehreren Ketten besteht.

Darüber hinaus ist es jetzt möglich, die Startzeit des GFS-Jobs selbst auszuwählen.. Viele Benutzer mochten den Mitternachtsstart nicht und warteten fast den ganzen Tag, bis der Source-Job abgeschlossen war. Jetzt kann diese Zeit beispielsweise auf den späten Abend eingestellt werden, wenn bereits etwas auf das Tape kopiert werden kann. Darüber hinaus haben wir auf Nutzeranfragen hin, die erweiterte Option in die Einstellungen integriert, die zuvor nur über einen Registrierungsschlüssel aktiviert werden konnte. Es genügt, auszuwählen Verarbeiten Sie den letzten Wiederherstellungspunkt, anstatt zu warten – und es wird das kopiert, was zum Zeitpunkt des Starts des Tape-Jobs im Repository vorhanden ist (zum Beispiel der Punkt vom gestrigen Tag), es gibt überhaupt keine Wartezeit.

Verbessertes Arbeiten mit mehreren Bibliotheken

Es geht um die Situation, in der mehr als eine Bibliothek zu einem Medienpool hinzugefügt wurde. Das haben wir auch früher unterstützt, aber gelegentlich kamen Kunden mit Beschwerden über nicht ganz vorhersehbares Verhalten.

War

Zum Beispiel hat ein Tape-Job begonnen, der zwei Laufwerke in der ersten Bibliothek belegt, aber die Parallelisierungseinstellungen erlauben es, vier Laufwerke gleichzeitig zu nutzen. Sollte dieser Job nun auf die zweite Medienpool-Bibliothek wechseln und auch diese nutzen, oder wäre das eine Ressourcenverschwendung?

Ein weiterer Fall. Die Option „wechseln bei Bedingung ‚keine verfügbaren Kassetten‘“ wurde ausgewählt, doch in der ersten Bibliothek gibt es nur eine Kassette, auf die potenziell alle Daten passen. Allerdings erlauben die Einstellungen das gleichzeitige Schreiben auf zwei Kassetten. Sollte in diesem Fall die zweite Bibliothek aktiviert werden?

Wir haben beschlossen, diesen Bereich zu ordnen, indem wir die Möglichkeit bieten, das Verhalten explizit einzustellen.

Ist

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

• Wenn Sie mehrere gleichwertige Bibliotheken haben und die Schreibvorgänge parallelisieren müssen, aktivieren Sie den Modus für paralleles Schreiben. Dazu müssen allen Bibliotheken aktive Rollen zugewiesen werden. In diesem Fall werden neue Kassetten und Laufwerke sofort verwendet, sobald der Bedarf entsteht, unabhängig davon, in welcher Bibliothek sie sich befinden. Es gibt jedoch eine Priorität: Zunächst versuchen wir, die Ressourcen in der oben aufgeführten Bibliothek zu finden.
• Wenn es eine Hauptbibliothek und ein älteres oder Standalone-Laufwerk als Reserve gibt, aktivieren Sie den Failover-Modus, indem Sie die Hauptbibliothek an die Spitze der Liste setzen und den Backup-Geräten eine passive Rolle zuweisen. Der Wechsel zu einem solchen Gerät erfolgt nur, wenn dies wirklich notwendig ist, damit der Job überhaupt funktioniert. Diese Situation wird als anormal betrachtet, und eine Benachrichtigung wird per E-Mail versendet.

Es gibt eine komplexere Situation, die wir derzeit nicht unterstützen – mehrere aktive Bibliotheken zusammen mit passiven. Das Feedback wird zeigen, ob es Bedarf für solche Konfigurationen gibt und ob die Funktion in Zukunft weiterentwickelt werden muss. Das ist 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 ist durch die Regeln einiger Organisationen, wie beispielsweise im medizinischen Bereich, vorgeschrieben. Das Hauptproblem mit solchen Kassetten war früher, dass VBR bei Inventarisierung oder Katalogisierung den Header aufzeichnete, der anschließend nicht mehr gelöscht werden konnte, und Tape-Jobs mit einem Fehler abbrachen, wenn ein solcher Versuch unternommen wurde.

In Update 9.5 Version 4 wurde die vollständige Unterstützung solcher Kassetten implementiert. WORM-Medien-Pools, sowohl regulär 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 mit normalen.

Die „Worm-Qualität“ der Kassetten wird ursprünglich durch das Suffix des Barcodes bestimmt., falls der Barcode jedoch gewöhnlich oder nicht lesbar ist, gibt das Laufwerk die Informationen beim ersten Einsetzen der Kassette aus. WORM-Kassetten können nicht in einen normalen Mediapool eingefügt und beschrieben werden. Interessanterweise haben sich bereits Benutzer gefunden, die WORM-Barcodes auf normalen Kassetten geklebt haben und überrascht waren über die Änderungen in ihrer Infrastruktur nach dem Update.

Chip der Kassette

Gleichzeitig mit der Einführung von nicht beschreibbaren Kassetten begannen wir mit dem Chip. Standardattribute im Chip wurden früher von uns nicht verwendet, jetzt schreiben und lesen wir in einige davon, nehmen sie jedoch nicht als primäre Datenquelle wahr. Der Hauptbezugspunkt bleibt nach wie vor der Titel der Kassette. Diese Entscheidung hat sich als richtig erwiesen: Ein Monat nach der Veröffentlichung sehen wir, wie die „Zoo“ -Hardware der Benutzer Überraschungen im Umgang mit dem Chip präsentiert.

Backup von NDMP-Volumes auf Band

Abschließend – zur am meisten nachgefragten Funktion dieses Updates hinsichtlich der Anzahl der Rückmeldungen. Das Backup von NDMP-Volumes auf Kassetten ist jetzt verfügbar. In die VBR-Infrastruktur müssen Sie einen NDMP-Server hinzufügen, nach dem Sie in der Dateitape-Job die Volumes von diesem Host auswählen können. Sie werden in Form von Dateien mit einem speziellen Attribut auf den Kassetten abgelegt, um sie bei der Katalogisierung von normalen Dateien zu unterscheiden.

In der ersten Implementierung gibt es bestimmte Einschränkungen: Erweiterungen (extensions) werden nicht unterstützt, zudem ist ein Backup und Restore nur des vollständigen Volumes, jedoch nicht einzelner Dateien möglich. Das Backup erfolgt über dump (im Falle von NetApp – ufsdump), hier gibt es eigene Besonderheiten: die maximale Anzahl inkrementeller Punkte beträgt 9, nach denen eine vollständige Sicherung erzwungen wird.

Zusammenfassend

Dies waren nur die bedeutendsten Neuerungen im Bereich der Datensicherung auf Magnetband in VBR 9.5 Update 4. Weitere Änderungen werde ich in einer Liste anführen:

• die Möglichkeit, die Reihenfolge von Source-Jobs und Dateien in Tape-Jobs festzulegen;
• eine Rolle Tape Operator hinzugefügt (der Benutzer kann alles tun, außer Wiederherstellungen von Band – dafür gibt es den Restore Operator);
• vollwertige Include-/Exclude-Masken in der Dateitape-Job hinzugefügt (außer NDMP);
• Die Wiederherstellung in der Tape-Job-Funktion wurde überarbeitet (der Ordner wird mit den Dateien wiederhergestellt, die zum Zeitpunkt des Backups vorhanden waren, und nicht mit allen, die jemals darin waren – eine sehr gefragte Funktion übrigens);
• Die Wiederherstellungsgeschwindigkeit einer sehr großen Anzahl von Dateien von Bändern wurde erhöht;
• Der Algorithmus zur Auswahl des nächsten Bands für die Aufzeichnung wurde optimiert, insbesondere unter Berücksichtigung aller anderen Faktoren das Volumen der über das gesamte Leben des Bandes geschriebenen/gelegten Daten, wir nehmen das aktuellste;
• Die Stabilität des Produkts wurde verbessert.

Nützliche Links

Zur Abwechslung liste ich hier einige Links zu russischsprachigen Ressourcen auf:

• Link zum Herunterladen der kostenlosen Testversion VBR 9.5 Update 4
• Artikel auf Habr „Nützliche Tipps zur Archivierung von Veeam-Backups auf Magnetbändern“
• Artikel auf Habr „7 nützliche Tipps zum Schutz von Backups vor Ransomware“
• Benutzerhandbuch-Abschnitt zu Bändern (in englischer Sprache)
• Die Übersichtsvideos „Wie es funktioniert“ sind wieder an ihrem alten Platz (zunächst nur in englischer Sprache) – können angesehen werden hier. Über Bänder wird in den Folien 95 – 102 berichtet.

Quelle: habr.com