Backup & Storage

Scale-Out Backup Repository (Veeam)

Allgemeine Infos

Das Scale-Out Backup Repository (SOBR) ist eine Funktion von Veeam Backup & Replication. Veeam beschreibt es als Repository-System mit horizontaler Skalierung für die mehrstufige Datenablage. Mehrere einzelne Backup-Repositories oder Object-Storage-Repositories, die sogenannten Extents, bilden gemeinsam die Performance-Ebene. Backup-Jobs schreiben auf das SOBR als ein einziges Ziel, Veeam verteilt die Dateien selbst auf die Extents.

Für längere Aufbewahrung lässt sich das SOBR um eine Capacity-Ebene und eine Archive-Ebene auf Object Storage erweitern. Typische Einsatzfälle sind wachsende Backup-Bestände, bei denen ein neues Storage einfach als weiterer Extent hinzukommt, und Langzeitaufbewahrung in der Cloud ohne eigene Bandinfrastruktur.

Abgrenzung: Tiered Storage bezeichnet allgemein die Verteilung von Daten auf Speicherklassen, das SOBR ist Veeams konkrete Umsetzung für Backup-Dateien. Object Storage ist ein Speichertyp, der im SOBR als Extent oder Capacity-Ebene dient. Unveränderlichkeit (Immutable Backup) stellt nicht das SOBR selbst her, sondern der jeweilige Extent, etwa ein gehärtetes Linux-Repository oder ein S3-Ziel mit Object Lock. Wie lange Sicherungen liegen, regelt die Backup-Aufbewahrung im Job.

Funktionsweise & Details

Ein SOBR arbeitet in drei Ebenen:

  1. Performance-Ebene: Ein oder mehrere Extents, also normale Backup-Repositories (z. B. Windows- oder Linux-Server, gehärtete Repositories) oder Object-Storage-Repositories, nehmen die aktuellen Sicherungen auf. Veeam schreibt Backup-Dateien auf alle Extents dieser Ebene.
  2. Platzierungsrichtlinie: Bei „Data locality“ bleiben alle Dateien einer Backup-Kette auf demselben Extent, was synthetische Vollsicherungen und Fast Clone auf ReFS und XFS ermöglicht. Veeam empfiehlt diesen Modus für die meisten Umgebungen. Der Modus „Performance“ verteilt Voll- und inkrementelle Dateien auf verschiedene Extents und ist nur für spezielle Fälle gedacht.
  3. Capacity-Ebene: Ein Object-Storage-Repository (z. B. S3-kompatibel oder Azure Blob) nimmt Daten aus der Performance-Ebene auf. Mit der Kopierrichtlinie landen neue Sicherungen zusätzlich dort, mit der Verschieberichtlinie wandern ältere Ketten nach Ablauf eines einstellbaren Zeitfensters dorthin.
  4. Archive-Ebene: Für Sicherungen mit sehr langer Aufbewahrung, etwa GFS-Monats- und Jahresstände, auf Archivklassen von Object Storage.

Extents lassen sich in den Wartungsmodus versetzen und evakuieren, um Hardware ohne Unterbrechung der Jobs auszutauschen.

Vorteile & Nutzen

  • Wachstum ohne Umbau der Jobs, weil neuer Speicher als weiterer Extent hinzukommt und alle Jobs weiter auf dasselbe Ziel schreiben.
  • Geringere Kosten für Langzeitaufbewahrung, da ältere Ketten automatisch auf günstigeren Object Storage wandern, statt teuren Primärspeicher zu belegen.
  • Offsite-Kopie ohne zusätzlichen Backup-Copy-Job, wenn die Kopierrichtlinie der Capacity-Ebene jede neue Sicherung in die Cloud schreibt.
  • Hardwaretausch im laufenden Betrieb, weil ein Extent evakuiert und die Daten auf die übrigen Extents verteilt werden.

Praxisbeispiel

Ein Logistikdienstleister mit 220 Mitarbeitenden hat zwei Backup-Server mit je 60 TB lokalem Speicher, die regelmäßig volllaufen. Die IT fasst beide als gehärtete Linux-Repositories zu einem SOBR mit Data-locality-Richtlinie zusammen und hängt eine S3-kompatible Capacity-Ebene mit Object Lock an. Neue Sicherungen werden per Kopierrichtlinie sofort in den Objektspeicher kopiert, Ketten älter als 30 Tage verlassen den lokalen Speicher. Der lokale Platzbedarf sinkt deutlich, und die Offsite-Kopie für die 3-2-1-Regel entsteht ohne zusätzlichen Job.

Worauf sollte man achten?

  • Verwende für die Performance-Ebene möglichst gleichartige Extents mit ReFS oder XFS, sonst gehen Fast-Clone-Vorteile bei gemischten Dateisystemen verloren.
  • Lege Unveränderlichkeit auf jeder Ebene fest (gehärtetes Repository lokal, Object Lock in der Capacity-Ebene), da sie pro Extent und nicht für das SOBR insgesamt gilt.
  • Kalkuliere Abruf- und API-Kosten des Cloud-Speichers ein, denn Restores aus Capacity- und Archive-Ebene lesen Daten aus dem Objektspeicher zurück.
  • Laufen auf einem Extent ständig Tasks, aktualisiert Veeam den freien Speicher nur verzögert. Der Registry-Wert SobrForceExtentSpaceUpdate (DWORD, 1) erzwingt eine regelmäßige Neuberechnung.
  • Plane pro Extent ausreichend Reserve ein, denn bei Data locality muss eine komplette Backup-Kette auf einen einzelnen Extent passen.

Lizenz & Verfügbarkeit

Kein eigenständiges Produkt: Das Scale-Out Backup Repository ist eine Funktion von Veeam Backup & Replication und wird mit dessen Lizenz genutzt (Veeam Data Platform in den Editionen Foundation, Advanced und Premium, lizenziert pro Workload über die übertragbare Veeam Universal License). Speicher für Capacity- und Archive-Ebene rechnet der jeweilige Object-Storage-Anbieter separat ab. Stand: Oktober 2026.

Fazit

Das SOBR ist der Standardweg, um Veeam-Backups über mehrere Speichersysteme und in die Cloud zu verteilen. Setze es mit Data locality, unveränderlichen Extents und einer Capacity-Ebene auf, dann wächst Dein Backup-Speicher ohne Umbau der Jobs.

Weiterführende Links

Verwandte Artikel