Sichern von Veeam-Backups auf Cloudspeicher (AWS) – Teil 3 von 3
In diesem dritten und letzten Teil der Artikel-Reihe «Sichern von Veeam Backups auf Cloudspeicher (AWS)» widmet sich Rinon Belegu der Konfiguration in Veeam.
In den ersten beiden Teilen dieser Blog-Serie wurden die Grundlagen der eingesetzten Technologien und die Grundkonfiguration des Storage Gateways erläutert. In diesem dritten und letzten Teil der Artikel-Reihe widme ich mich der Konfiguration in Veeam.
Hinzufügen zu Veeam
Auf dem zukünftigen Veeam Tape Server füge ich jetzt die VTL über iSCSI hinzu:
Ich sehe jetzt den MediaChanger und mehrere Tape Drives. Diese kann ich nun verbinden.
Im Device Manager muss ich noch den Treiber für den Changer und die Drives laden. Die Tape Drives werden jetzt angezeigt:
Falls dies nicht der Fall ist, müssen Sie den Default LTO-5-Treiber laden.
Für den Medium Changer benutze ich bei Veeam «Sony TSL-A500C Autoloader».
In Veeam 9.5 füge ich jetzt den TapeServer hinzu, an dem wir vorher per iSCSI die Library angehängt haben.
Die restlichen Fenster klicke ich ohne Anpassungen durch.
Nun sehe ich die Library und Tapes im Veeam. Wenn Sie sich wundern, warum es plötzlich drei sind: Dies ist, weil ich ein weiteres im Nachgang hinzugefügt habe.
Bevor der Backup-Spass anfangen kann, gehe ich noch in die Optionen des Changers.
Dort wähle ich «Use nativ SCSI command instead of Windows driver»:
Nun erstelle ich in Veeam einen Medienpool. Ein GFS-Medienpool bei Veeam speichert Daten auf Tape nach dem Grossvater-Vater-Sohn-Prinzip.
Für meinen Testaufbau belasse ich alle Einstellungen auf dem Standard. Ich wähle nur die AWS VTL, die ich vorher erstellt habe. Ich definiere hier, dass automatisch Bänder vom Free-Pool herangezogen werden, falls zum Backup neue benötigt werden.
Die Vorhaltezeiten belasse ich bei den Standardwerten, da dies nur für Demo-Zwecke dient.
Wir könnten den Inhalt mit Veeam auch verschlüsseln:
Am Schluss erhalte ich noch eine Zusammenfassung. Diese bestätige ich mit «Finish».
Nun erstelle ich einen neuen Tape-Job, um das Ganze zu testen:
Im ersten Fenster definiere ich einen Namen für den Job. Hier kann ich auch einen allfälligen Kommentar hinzufügen.
Ich kann jetzt die Quelle der Daten definieren, die auf das Band geschrieben werden. Ich wähle einen Backup-Job.
Hier definiere ich, welcher Medien-Pool für die Full-Backups verwendet werden soll. Dort selektiere ich den vorher erstellten «GFSPool1».
Wenn ich auf diese Weise in die AWS Cloud sicher, muss ich mir ganz genau überlegen, wann ich die Medien «auswerfe», da ich mit der Aktion eine Verschiebung von S3 auf Glacier provozieren kann. Dies würde die Wiederherstellungszeit extrem verlängern.
Für unsere Zwecke belasse ich das «Scheduling», wie es vom Hersteller angeboten wird:
Mit Setzen des Hakens auf «Run the job when I click Finish» und dem Bestätigen starte ich den Job:
Die Geschwindigkeit ist hierbei nur so langsam, weil die Verbindung zum lokalen Gateway über eine 1-Gbit-LAN-Strecke geht, die schon einer Belastung ausgesetzt ist. Die Leitung ist im Backup-Moment voll ausgeschöpft.
Sobald die Cache Disk ausgeschöpft ist und der Upload zu S3 von AWS zu viele Daten hängig hat, wird die Datenübertragung von Veeam zur Storage Appliance gefreezed, dies spiegelt sich in der nächsten Grafik wider:
Wenn wir uns zurückerinnern: Unsere Cache Disk war 20 GB. Hier sieht man, warum das richtige Definieren der Disks wichtig ist: