Xact.gmbh

(K)ein alter Hut.
Zwar ist es schon seit VBR v9.5 Update 4 möglich, Object Storage zu verwenden, im Gegensatz zu Veeam Backup für Microsoft (Office) 365 gab es hier bisher aber nicht die Nutzung als primären Storage Tier (Direct Backup to Object Storage).
VBR v12 steht nun ganz im Zeichen von Object Storage - ob aber Object Storage First ist eine Frage, die nicht zuletzt anhand der dafür eingesetzten Lösung samt deren Standort jeder für sich selbst klären muss.

The very basics.
Doch zuerst einmal ganz kurz rekapituliert - wie funktioniert Object Storage eigentlich?
Natürlich werden die Daten auch bei Object Storage am Ende, ebenso wie bei File- wie Blockstorage wieder auf Disken gespeichert - aber wie erfolgt die Verwaltung und der Transfer?
Wie der Name schon sagt werden die Daten als Objekte eingelagert - und selbige enthalten neben den eigentlichen (Payload) Daten wie zB. eine Datei (oder wie im Falle von Veeam entweder dehydrierte Backupfiles oder Data Chunks) auch Metadaten.

Die Objekte erhalten, jedes für sich, einen eigenen und eindeutigen Identifyer (id est Schlüssel oder Objektname) und über diesen kann darauf zugegriffen werden. Weil dabei die Daten in einem flachen Namespace liegen, wurde dafür auch der Name Bucket für den Speicher gewählt, der dem Anwender gesamt und ohne Strukturierung zur Verfügung steht.

Technisch erfolgt nun Speicherung, Zugriff, Lesen und Manipulation (Aktualisierung) sowie Löschen über ein Application Programming Interface (API). Während die Stärke von Object Storage in der massiven Skalierbarkeit (Scale-out mit mehreren/vielen Nodes wie Scale-up mit Ausbau der Kapazität je Storage Node) liegt, wird neben den verwendeten Disktypen und deren Perfomance schlussendlich dann meist die API Performace sowie die Bandbreite des Systems entscheidend sein.

Object Storages sind sowohl als cloud-basierte als auch on-premises Lösung mit jeweils unterschiedlichen Abrechnungsmodellen verfügbar. Während bei Cloud-Lösungen neben den Kosten der Speicherung der Daten zumeist auch solche für Upload, Download und Manipulation verrechnet werden, gibt es on-premises neben den Klassikern Kauf und Leasing auch Mietmodelle (zB. Zadara ⧉).

Doch nun zurück zu Veeam - was geht?
Gegenüber der Version 9.5 U4, die damals Support für

• Amazon S3
• S3 kompatible Lösungen
• Microsoft Azure und
• IBM Cloud

Wolkig, mit Aussicht auf sicheres Backup?
Cloud-basierte Object Storage Lösungen sind hier definitiv ein interessanter Ansatz, nicht zuletzt auch aus Sicht der erweiterten 3-2-1 Regel: ein Storage offsite und selbiges online, daür aber immutable (also - zumindest temporär - unveränderbar).
Nun ist die Immutability selbst kein neues v12 Feature, zumindest nicht bei Amazon S3 und S3 kompatiblen Storages (zum generellen S3c Support sowie Immutability siehe btw. hier ⧉ ), sondern vom Anbieter selbst, der Unterstützung durch Veeam und der korrekten Initiierung bei Erzeugung des Buckets abhängig.
Hier wird mit VBR v12 neuerdings auch Azure Immutability (KB 4416) ⧉ unterstützt.

Was es nicht ist.
Angemerkt sei an dieser Stelle, dass Object Storage nicht per se mit Immutability verwechselt werden darf - so bietet zB. auch das Veeam Hardened Repository ⧉ den Schutz der Immutability, der hier mit ext3/4, BTRFS und XFS, also mit klassischen Filesystemen und deren Support für i-Flags umgesetzt wird.

Zurück zur Cloud.
Die Performance von Backup und Restore hängt bei der Verwendung von Cloud Oject Storage nun einmal sowohl mit der zur Verfügung stehenden Bandbreite (die des Cloud Anbieter ebenso wie die eigene, letztere wird in der Praxis meist die massgebliche Begrenzung darstellen) als auch mit der Latenz (und allfälligem Packet Loss) zusammen.
Soferne sich das Ziel nicht sehr weit entfernt, sondern oft auch aus rechtlichen Gründen (wie zB. Datenschutz Grundverordnung) in naher nationaler oder internationaler Distanz befindet, wird Latenz oft weniger bedeutsam sein, während die Frage der Bandbreite in vielen Ländern allzu oft noch immer entweder gar nicht oder aber zumindest finanziell nicht befriedigend beantwortbar ist.

Mein Haus - meine Regeln!
Falls aus den zuvor genannten Gründen eine Cloud-Lösung nicht in Frage kommen kann/soll, die "eigene" IT also ohnedies unverändert und traditionell im Wesentlichen on-premises betrieben wird, spielt - auf Wunsch - Object Storage aber auch hier die erste Geige.

Im S3 compatible Markt tummeln sich sowohl klassische Storage Anbieter wie

• DELL EMC (ECS) ⧉
• Hitachi Vantara (HCP) ⧉
• Netapp (S3 Storage Grid) ⧉
• Quantum (ActiveScale) ⧉
• Pure Storage (Flashblade) ⧉

• Ceph ⧉
• Cloudian ⧉
• Data Core (Swarm) ⧉
• iTernity ⧉
• Min.io ⧉
• Scality ⧉
• Suse (Enterprise Storage) ⧉

Und schon wieder bewölkt.
Neben den bereits genannten, von Veeam schon seit längerer Zeit unterstützen, grossen Anbietern sind aber auch neuere mit lokalen Datacenter vertretene Plattformen wie zB. Wasabi ⧉ erwähnenswert, die speziell mit günstigeren Preisen gegenüber den altbekannten Platzhirschen werben.

Legt man aber darauf Wert, dass die Daten selbst im Object Storage auch einem vollautomatischen Tiering unterliegen, also (bestimmte) alte Daten automatisch auf einen noch kostengünstigeren Object Storage Tier verschoben werden sollen, kommt man zumindest aktuell nicht um Microsoft oder Amazon herum.

Ergänzung*: seit VBR v12.1 gibt es die Möglichkeit eines Archive Tiers jetzt auch bei bestimmten S3c Anbietern.

Zur Struktur der Daten im Archive Tier siehe hier ⧉.

In beiden Fällen kann bei Einbindung von Buckets als Capacity Tier eines Veeam Scale-Out Backup Repositories auch ein Archive Tier eingesetzt werden, in den GFS Full Backups dann automatisch ausgelagert werden können. Der Umstand, dass dabei die GFS Backup Object Daten mittels einer bei der jeweiligen Plattform laufenden VM konvertiert werden müssen, *erklärt damit auch die Limitierung des Features Archive Tier auf die beiden Hyperscaler Amazon und Microsoft Azure.

Bild 1, Archive Tier (Bildrechte: Veeam)

Wobei Veeam VBR bei letzterer Plattform dort nun mit v12 endlich auch die Immutability unterstützt!

Was darf es denn nun sein?
Wer aus Gründen wie Bandbreite, Kosten oder rechtlichen Gründen (Bedenken DSGVO vs. US-Cloudservice Anbieter)

• weder einen cloud-basierten Tier
• noch eine Co-Location

• Band mit Backup to Tape (unbedingt mit Auslagerung der Bänder aus der Library und dem Standort!)
• oder auch Disk mit Backup Copy (pruning oder mirroring mode) zu Object Storage oder aber einem "normalen" (Standard oder SOBR/Performance Tier)

This is the end my friend.
Je mehr Sicherheit, desto besser - aber idR desto höher auch der Preis - respektive Aufwand.
Was also - im wahrsten Sinne des Wortes - noch leistbar ist, sollte auch angestrebt werden, immer mit der erweiterten 3-2-1 Regel als Minimal-Variante.
Ob hier nun on-premises beim primary Backup und/oder bei der Secondary Copy in der Cloud oder Co-Location auf Object Storage gesetzt wird, ist letztlich anhand der individuellen Möglichkeiten abzuwägen.

Eines ist aber sicher: ungeschützte Daten sind generell - lokal wie in der Cloud - leichte Beute, public accessible Buckets in der Cloud mit sensiblen, tw. noch dazu unverschlüsselten Daten haben es ja bereits zu unrühmlichen "Ehren" in den Medien geschafft und sind daher ein absoluter no-go!

Verfasst am 20230515 von Claus Pfleger
Editiert:

• 20240730-1158h (Ergänzung Scality sowie S3c Archive Tier)
• 20230612-0844h (Ceph in Liste durchgestrichen - siehe diesen Veeam Foren Post ⧉)
• 20230608-1505h (Schreibfehler, Ergänzungen)
• 20230607-1545h (Typos, Schreibfehler)