Veeam Backup auf Swiss S3 einrichten – Setup, Block Generation und Best Practices

Veeam Backup & Replication kann seit Version 12 direkt auf S3-kompatiblen Object Storage sichern – ohne Umweg über ein Scale-Out Backup Repository. Wer dabei auf einen Schweizer Speicherort mit Georedundanz und Immutability setzt, landet schnell beim Swiss S3 Storage von Backup ONE. Dieser Beitrag zeigt Schritt für Schritt, wie du das Repository einrichtest, erklärt das oft missverstandene Konzept der Block Generation und listet auf, worauf du bei der Konfiguration achten musst.

Warum S3 als Backup-Target?

Klassische Backup-Repositories auf lokalen Disks oder NAS-Systemen stossen bei wachsenden Datenmengen an Grenzen – sowohl bei der Skalierbarkeit als auch beim Schutz gegen Ransomware. Object Storage mit S3-API löst beide Probleme: Der Speicher skaliert praktisch unbegrenzt, und mit Object Lock lassen sich Backups unveränderbar machen. Kein Admin und kein Angreifer kann immutable Daten vor Ablauf der Schutzfrist löschen oder überschreiben.

Swiss S3 von Backup ONE basiert auf Dell ECS (Elastic Cloud Storage) und bietet georedundante Speicherung über zwei Schweizer Rechenzentren (Zürich und Genf, über 100 km Distanz – FINMA-konform). Die Daten verlassen die Schweiz nicht, und Object Lock wird nativ unterstützt. Für Veeam wird Swiss S3 als «S3 Compatible» Repository angebunden.

Swiss S3 als Repository in Veeam einrichten

Die Einrichtung erfolgt über den «New Object Storage Repository»-Wizard in Veeam Backup & Replication v13. Hier der Ablauf:

Voraussetzungen

Bevor du loslegst, stelle sicher, dass folgende Punkte erfüllt sind:

• Du hast einen Swiss S3 Account bei Backup ONE mit Access Key und Secret Key.
• Ein Bucket ist angelegt. Wenn du Immutability nutzen willst: Object Lock und Versioning müssen beim Erstellen des Buckets aktiviert worden sein – das lässt sich nachträglich nicht einschalten.
• Die Default Retention auf dem Bucket ist deaktiviert. Veeam setzt die Retention pro Objekt selbst. Eine Default Retention auf Bucket-Ebene führt zu unvorhersehbarem Verhalten.
• Der Veeam Backup Server (oder der Gateway Server) hat HTTPS-Zugriff auf den S3-Endpoint von Backup ONE.

Schritt-für-Schritt-Anleitung

1. Repository hinzufügen: Navigiere zu Backup Infrastructure → Backup Repositories → Add Backup Repository → Object Storage → S3 Compatible.
2. Name vergeben: Wähle einen sprechenden Namen, z.B. «Swiss-S3-Immutable-30d».
3. Credentials und Endpoint konfigurieren: Unter «Account» fügst du deine S3-Credentials hinzu (Access Key + Secret Key). Als Service Point gibst du den HTTPS-Endpoint an, den du von Backup ONE erhalten hast. Die Region kannst du auf «default» belassen.
4. Bucket und Folder wählen: Veeam listet die verfügbaren Buckets auf. Wähle deinen vorbereiteten Bucket und erstelle einen Folder (z.B. «veeam-backups»). Pro Repository solltest du einen eigenen Folder verwenden.
5. Immutability aktivieren: Setze den Haken bei «Make recent backups immutable» und definiere die gewünschte Schutzfrist (z.B. 30 Tage). Mehr dazu im nächsten Abschnitt.
6. Mount Server definieren: Wähle einen Mount Server für Restore-Operationen. Dieser Server muss ebenfalls Zugriff auf den S3-Endpoint haben.
7. Wizard abschliessen: Prüfe die Zusammenfassung und klicke «Finish». Veeam validiert die Verbindung und erstellt das Repository.

Das Repository steht jetzt als direktes Backup-Target oder als Capacity Tier in einem Scale-Out Backup Repository (SOBR) zur Verfügung.

Block Generation – was es ist und wie du rechnest

Die Block Generation ist eines der am häufigsten missverstandenen Konzepte bei Veeam + Object Storage. Wer es nicht versteht, wundert sich über unerwartet hohen Speicherverbrauch oder über Daten, die sich nicht löschen lassen, obwohl die Retention längst abgelaufen scheint.

Das Problem, das Block Generation löst

Bei einem Forward Incremental Backup besteht jeder Restore Point aus einem Full Backup plus den nachfolgenden Incrementals. Veeam muss sicherstellen, dass die gesamte Backup-Kette – also Full und alle zugehörigen Incrementals – für die definierte Immutability-Dauer geschützt bleibt. Ein Incremental ohne das zugehörige Full ist wertlos.

Ohne Block Generation müsste Veeam bei jedem neuen Incremental die Immutability aller bestehenden Blöcke in der Kette verlängern. Das erzeugt eine grosse Zahl an API-Requests – und bei vielen S3-Anbietern kosten API-Calls Geld.

Wie Block Generation funktioniert

Block Generation ist ein Zeitfenster, innerhalb dessen alle Datenblöcke (Full und Incrementals) dasselbe Immutability-Ablaufdatum erhalten. Veeam addiert dieses Zeitfenster automatisch auf die konfigurierte Immutability-Dauer. Du musst nichts konfigurieren – der Wert wird automatisch gesetzt.

Die Standardwerte für die Block Generation sind:

• 10 Tage – für S3 Compatible (also auch für Swiss S3 von Backup ONE), Azure, Wasabi, Google Cloud und die meisten anderen Anbieter.
• 30 Tage – für Amazon S3 und IBM Cloud.

Rechenbeispiel mit Swiss S3

Angenommen, du konfigurierst folgendes Setup:

• Backup-Methode: Forward Incremental
• Job Retention: 30 Restore Points
• Immutability: 30 Tage
• Block Generation: 10 Tage (automatisch, da S3 Compatible)

Die Formel für die tatsächliche Aufbewahrungsdauer lautet:

Tatsächliche Aufbewahrung = Immutability + Block Generation
                         = 30 Tage + 10 Tage
                         = 40 Tage

Das bedeutet: Datenblöcke bleiben mindestens 40 Tage auf dem Storage, auch wenn dein Job nur 30 Restore Points vorhält. Planst du deine Speicherkapazität nur für 30 Tage, wird es eng.

Wenn die Job Retention die Immutability-Dauer übersteigt, sieht die Formel so aus:

Tatsächliche Aufbewahrung = Job Retention + Immutability + Block Generation

Beispiel: 30 Tage Retention + 30 Tage Immutability + 10 Tage Block Generation = 70 Tage effektiver Speicherverbrauch.

Was passiert innerhalb einer Generation?

Wenn am Tag 1 ein Full Backup auf den Storage geschrieben wird, setzt Veeam dessen Immutability auf 30 + 10 = 40 Tage. Alle Incrementals, die in den folgenden 9 Tagen (innerhalb derselben Generation) dazukommen, erhalten dasselbe Ablaufdatum wie das Full. Ein Block, der am Tag 9 geschrieben wird, hat also dasselbe Ablaufdatum wie ein Block von Tag 1. Am Tag 11 startet eine neue Generation – und Veeam verlängert die Immutability der bestehenden Blöcke um weitere 10 Tage.

Dieses Prinzip reduziert die API-Calls massiv: Statt bei jedem täglichen Backup die Immutability aller alten Blöcke zu verlängern, passiert das nur einmal pro Generation (alle 10 Tage).

Block Generation bei GFS-Backups

Bei GFS-Backups (Grandfather-Father-Son) prüft Veeam die GFS-Retention und setzt die Block Generation entsprechend. Für wöchentliche GFS-Backups wird die Block Generation standardmässig angewendet, weil zwischen zwei wöchentlichen Fulls eine hohe Wahrscheinlichkeit besteht, dass viele Blöcke geteilt werden.

Ein Beispiel: Bei einer wöchentlichen GFS-Retention von 28 Tagen und einer Block Generation von 10 Tagen beträgt die tatsächliche Aufbewahrung 28 + 10 = 38 Tage. Die Block Generation wird dabei jede Woche um 7 Tage reduziert, und eine neue Generation startet, sobald die vorherige abgelaufen ist.

Das musst du bei der Kapazitätsplanung berücksichtigen – besonders bei monatlichen oder jährlichen GFS-Punkten, wo die Block Generation prozentual weniger ins Gewicht fällt, aber bei wöchentlichen Backups den Speicherbedarf spürbar erhöht.

Worauf du sonst noch achten musst

Job Retention vs. Immutability richtig abstimmen

Ein häufiger Fehler: Die Job Retention wird tiefer gesetzt als die Immutability. Beispiel: 14 Tage Job Retention, 30 Tage Immutability. Veeam zeigt in der Konsole nur 14 nutzbare Restore Points an – aber auf dem Storage liegen Daten für 40 Tage (30 + 10 Block Generation). Die «versteckten» Restore Points zwischen Tag 14 und Tag 40 sind zwar vorhanden, aber in der Veeam-UI nicht sichtbar. In v13 gibt es keinen einfachen Weg, diese Punkte für einen Restore zu nutzen.

Die Empfehlung: Setze die Job Retention mindestens gleich hoch wie die Immutability. Wenn du 30 Tage immutable Backups willst, setze auch die Job Retention auf 30 Tage. So sind alle geschützten Restore Points in der UI sichtbar und nutzbar.

Bucket-Konfiguration vor dem ersten Backup

Object Lock und Versioning müssen beim Erstellen des Buckets aktiviert werden. Nachträgliches Aktivieren ist bei den meisten S3-Implementierungen nicht möglich. Wenn du einen bestehenden Bucket ohne Object Lock verwendest und später Immutability einschalten willst, musst du einen neuen Bucket erstellen und die Daten migrieren.

Kein Default Retention auf dem Bucket

Stelle sicher, dass auf dem Bucket keine Default Retention Policy aktiv ist. Veeam setzt die Retention pro Objekt selbst via S3 Object Lock. Eine zusätzliche Default Retention auf Bucket-Ebene kann zu Konflikten führen und im schlimmsten Fall Daten länger halten als erwartet – oder das Löschen verhindern.

Kapazitätsplanung mit Puffer

Rechne bei der Speicherplanung immer mit der tatsächlichen Aufbewahrungsdauer inklusive Block Generation. Bei Swiss S3 (S3 Compatible) sind das 10 Tage on top. Bei täglichen Backups mit 30 Tagen Immutability musst du also mindestens 40 Tage an Daten einplanen – plus Puffer für wachsende Datenmengen und synthetische Fulls.

Ein Folder pro Repository

Verwende pro Object Storage Repository einen eigenen Folder innerhalb des Buckets. Das vereinfacht das Monitoring und verhindert Konflikte, wenn mehrere Veeam-Instanzen auf denselben Bucket zugreifen. Bei S3-Compatible-Repos empfiehlt Veeam zudem, nicht mehr als einen Bucket pro Scale-Out Backup Repository zu verwenden, da die Metadaten-Verarbeitung sonst langsamer wird.

Gateway Server bei eingeschränktem Internetzugang

Wenn dein Veeam Backup Server keinen direkten HTTPS-Zugang zum S3-Endpoint hat (z.B. wegen Firewall-Regeln), konfiguriere einen Gateway Server. Dieser übernimmt die Kommunikation mit dem Object Storage und kann in einer DMZ oder einem dedizierten VLAN stehen.

Praxis-Tipps aus dem Alltag

Aus der Erfahrung mit zahlreichen Veeam-Installationen auf Swiss S3 haben sich folgende Punkte als besonders relevant erwiesen:

• Immutability-Dauer bewusst wählen: 30 Tage sind ein guter Startwert für die meisten KMU. Wer regulatorische Anforderungen erfüllen muss (z.B. FINMA), sollte die Dauer mit dem Compliance-Team abstimmen. Zu lang gewählte Immutability treibt die Speicherkosten unnötig hoch.
• Testen vor dem Produktivbetrieb: Richte zuerst einen Test-Bucket ein, führe ein paar Backup-Zyklen durch und prüfe, ob die Immutability-Daten und die Block Generation sich so verhalten wie erwartet. Ein Blick in die Bucket-Metadaten via S3-Browser oder CLI hilft.
• Monitoring einrichten: Überwache den Speicherverbrauch auf dem Bucket aktiv. Gerade in den ersten Wochen nach der Einrichtung wächst der Verbrauch durch die Block Generation stärker als erwartet. Ein Alert bei 80% des geplanten Volumens gibt dir genug Vorlauf.
• Restore regelmässig testen: Ein Backup, das sich nicht wiederherstellen lässt, ist kein Backup. Teste den Restore von Object Storage mindestens quartalsweise – inklusive der Restore-Performance, die bei S3-Targets anders ausfällt als bei lokalem Storage.
• Encryption aktivieren: Auch wenn Swiss S3 transportverschlüsselt ist und die Daten auf dem Storage verschlüsselt abgelegt werden – aktiviere zusätzlich die Veeam-eigene Encryption. So bist du unabhängig vom Storage-Anbieter geschützt, und die Daten sind auch bei einem Export oder einer Migration verschlüsselt.

Fazit

Veeam auf Swiss S3 von Backup ONE einzurichten ist technisch unkompliziert – die eigentliche Herausforderung liegt im Verständnis der Block Generation und der korrekten Abstimmung von Job Retention und Immutability. Wer die Formel Tatsächliche Aufbewahrung = Immutability + Block Generation verinnerlicht und die Kapazitätsplanung entsprechend macht, vermeidet böse Überraschungen bei Speicherkosten und Restore-Verfügbarkeit.

Du willst Swiss S3 als Backup-Target evaluieren oder brauchst Unterstützung bei der Konfiguration? Kontaktiere uns – wir helfen dir beim Setup und bei der Kapazitätsplanung.