Veeam S3 und SOBR: Warum Tiering-Jobs scheitern

Veeam-S3- und SOBR-Tiering-Fehler können bestehen bleiben, selbst wenn die naheliegenden Netzwerktests gesund aussehen. Ein Administrator berichtete 2026 von sechs Monaten ungelöster Probleme, während On-Premises-S3-Appliances über eine dedizierte 10-Gb-Rechenzentrumsleitung weiterhin bei rund 900 bis 980 MB/s testeten.

Die aktuelle Dokumentation von Veeam Backup & Replication 13 unterstützt ausdrücklich S3-kompatiblen Objektspeicher und Scale-Out-Backup-Repository-Kapazitäts-Tiers. S3 ist also nicht grundsätzlich unzuverlässig, und Veeam kann Objektspeicher nutzen. Objektspeicher-Backup hat aber mehr bewegliche Teile, als ein einfacher Bandbreitentest prüfen kann.

Was scheiterte tatsächlich in der gemeldeten Veeam-S3-Umgebung?

Der Administrator beschrieb wiederholte Fehler im Veeam-Scale-Out-Backup-Repository-Tiering und in Backup-Copy-Workflows. Der Objektspeicher befand sich On-Premises im primären Rechenzentrum und an einem Disaster-Recovery-Standort. Ein dedizierter 10-Gb-Glasfaserpfad verband die Standorte zur Datenreplikation.

Das Design nutzte mehrere Buckets, und der Administrator begrenzte jeden Bucket auf maximal zwei Jobs. Die meisten primären Backup-Jobs zielten zunächst auf lokale Disk, und Backup-Copy-Jobs verschoben die Schutzdaten anschließend Richtung S3. Tape-Jobs blieben auf dem lokalen Disk-Pfad und lasen nicht von S3.

Diese Topologie grenzt das Problem ein. Der Administrator versuchte nicht, jedes Backup direkt gegen einen entfernten Cloud-Bucket über eine schwache Internetverbindung laufen zu lassen. Das lokale Disk-Backup blieb offenbar Teil des Designs, während die Objektschicht während sekundärer Kopier- und Tiering-Operationen für Probleme sorgte.

Der Veeam-Support bat um ausführliches S3-Logging und eine Erhöhung von S3RequestTimeoutSec auf 600 Sekunden gegenüber dem angegebenen Standardwert von 120. Sechs Monate in den Fall hinein betrachtete der Administrator die Umgebung noch immer nicht als stabil.

Warum kann sich hinter 900 MB/s trotzdem ein Objektspeicher-Problem verbergen?

Durchsatz ist nur eine Eigenschaft des Pfads. Ein Massendaten-Übertragungstest beantwortet die Frage: „Wie schnell kann ein großer Datenstrom diese Leitung unter diesen Bedingungen durchqueren?" Er beantwortet nicht die Frage: „Wie verhält sich dieser Storage über Tausende von Objekt- und Metadatenoperationen unter Backup-Nebenläufigkeit?"

Die aktuelle Veeam-Dokumentation beschreibt Kapazitäts-Tiers als Objektspeicher-Extents, die an ein Scale-Out Backup Repository angehängt sind. Backup-Daten können dorthin kopiert oder verschoben werden, und der Kapazitäts-Extent hält Datenblöcke, Metadaten, Checkpoint-Informationen und andere Hilfsobjekte vor.

Damit gibt es mehrere Schichten, in denen etwas schiefgehen kann. Das Netzwerk kann Paketverlust oder Latenzspitzen haben, die Objekt-Appliance kann unter Metadatenlast langsamer werden, und API-Anfragen können mit Timeout scheitern. Ebenso können DNS oder TLS zeitweise fehlschlagen, Storage-Firmware kann sich unter Nebenläufigkeit schlecht verhalten, oder eine Veeam-Komponente stößt auf einen Sonderfall. Keine dieser Möglichkeiten wird durch den Reddit-Bericht bewiesen, aber bei dieser Topologie muss man sie isolieren, statt zu raten.

Der Mr.PlanB-Leitfaden zu S3-Kosten und -Verhalten hilft hier weiter, denn Objektspeicher ist ein API-gesteuertes Storage-Modell und verhält sich anders als eine entfernte Festplatte.

Wie sollte ein Veeam-SOBR-Problem isoliert werden?

Reduzieren Sie die Umgebung, bis eine einzige fehlschlagende Operation reproduzierbar wird. Troubleshooting ist deutlich einfacher, wenn ein Job, ein Bucket, ein Proxy-Pfad und ein Objektziel auf Kommando scheitern können.

Beginnen Sie damit, den Veeam-Build, die Storage-Firmware, die Bucket-Konfiguration, Gateway- oder Proxy-Rollen, Verschlüsselungseinstellungen, Immutability-Einstellungen, den DNS-Pfad, die Zertifikatskette und die Zeitsynchronisation zu erfassen. Erfassen Sie dann den genauen Job-Schritt, an dem der Fehler auftritt.

Führen Sie eine kleine Backup-Copy zu einem Bucket ohne konkurrierende Jobs aus. Gelingt sie wiederholt, fügen Sie einen zweiten Job hinzu. Treten Fehler erst bei Nebenläufigkeit auf, haben Sie eine brauchbare Grenze gefunden. Scheitert ein Standort und der andere nicht, vergleichen Sie die Pfade. Scheitern beide auf dieselbe Weise, suchen Sie nach der gemeinsamen Veeam- oder Objektspeicher-Schicht.

Der Administrator hatte Buckets bereits auf zwei Jobs begrenzt, was darauf hindeutet, dass Nebenläufigkeit bereits auf dem Troubleshooting-Radar war. Der Support forderte zudem ein größeres S3-Timeout und ausführliches Logging an. Das waren vernünftige Experimente, aber jeder nächste Schritt sollte sich aus den Belegen des vorherigen Tests ergeben.

Was sagt die aktuelle Veeam-Dokumentation über SOBR?

Stand Juli 2026 beschreibt die Dokumentation von Veeam Backup & Replication 13 Scale-Out Backup Repository als ein logisches Repository-System, das Performance-Storage mit Kapazitäts- und Archiv-Tiers kombinieren kann. Der Kapazitäts-Tier kann Cloud- oder On-Premises-Objektspeicher nutzen, und Backups können direkt daraus wiederhergestellt werden.

Veeam dokumentiert außerdem S3-kompatiblen Storage als unterstützten Objektspeicher-Repository-Typ. Objekt-Repositories können als Ziele für Backup-Jobs und Backup-Copy-Jobs dienen und an SOBR-Tiers teilnehmen.

Daran sollte man denken, wenn man einen älteren oder versionsspezifischen Fehlerbericht liest. Ein Produktionsfehler heißt dann, dass die Implementierung, Umgebung, Version, das Storage-Ziel oder das Zusammenspiel dieser Schichten diagnostiziert werden muss, obwohl die Funktion an sich unterstützt wird.

Für Teams, die Architekturen vergleichen, zeigt der Mr.PlanB-Proxmox-Backup-Leitfaden einen anderen Designansatz: native Backup-Storage, Third-Party-Backup und Offsite-Kopien lösen sich überschneidende Probleme auf unterschiedliche Weise. Die richtige Architektur hängt von den Fehlermodi ab, die Sie beherrschen können.

Wann sollten Sie die Objekt-Appliance statt Veeam verdächtigen?

Verdächtigen Sie die Storage-Seite, wenn Fehler mit Bucket-Last, Anfragerate, Firmware-Änderungen, einem Standort, einem Knoten, einem API-Verhalten oder einem storage-seitigen Fehlermuster korrelieren. Verdächtigen Sie die Veeam-Seite, wenn dasselbe Ziel mit unabhängigen Tools sauber funktioniert, aber konsequent bei einer bestimmten Veeam-Operation scheitert.

Damit die Schlussfolgerung nicht in gegenseitiger Schuldzuweisung zwischen Herstellern endet, sammeln Sie Logs von beiden Seiten für denselben Zeitstempel. Die Objekt-Appliance sollte Anfragen, Antwortcodes, Latenz, Drosselung oder interne Fehler zeigen. Veeam-Logs sollten zeigen, welche Operation versucht wurde und welche Antwort empfangen wurde.

Verschwindet das Problem, wenn dieselbe Backup-Copy an ein anderes S3-kompatibles Ziel geht, ist das ein starker Beleg. Folgt es Veeam über verschiedene Objektplattformen hinweg, deutet das auf etwas anderes hin, und folgt es einer Appliance unabhängig von der Backup-Software, ist auch das aufschlussreich. Eine gute Troubleshooting-Matrix ändert deshalb jeweils nur eine Schicht.

Warum ist der Neuaufbau des Veeam-Servers eine schlechte erste Reaktion?

Ein Neuaufbau ändert viele Variablen gleichzeitig und mit unveränderlichem Storage kollidieren kann. Der Administrator sagte ausdrücklich, er könne nicht einfach den Server neu aufbauen und einen Offsite-Standort löschen, sobald die Umgebung einen schlechten Tag hat.

Der Einwand ist berechtigt, denn Immutability soll destruktive Änderungen erschweren. Eine Recovery-Plattform sollte einen dokumentierten Weg haben, um Konfiguration wieder anzubinden, zu importieren oder wiederherzustellen, ohne jeden ungeklärten Fehler als Erlaubnis zum Löschen geschützter Historie zu behandeln.

Sichern Sie vor einem Neuaufbau die Veeam-Konfigurationssicherung, Verschlüsselungspasswörter, Repository-Definitionen und die genaue Beziehung zum Objektspeicher. Bestätigen Sie, wie die Zielversion bestehende Daten importiert oder synchronisiert. Die aktuelle Kapazitäts-Tier-Dokumentation von Veeam beschreibt das Synchronisationsverhalten, wenn ein Objekt-Repository bereits ausgelagerte Daten enthält.

Der Mr.PlanB-Storage-Hub passt dazu, denn zur Wiederherstellbarkeit von Storage gehören neben den Bytes auf einem Gerät auch Metadaten und Steuerungsebenen-Informationen.

Was würde ich bei einem sechsmonatigen SOBR-Fehler tun?

Ich würde eine kontrollierte Reproduktionsumgebung um einen einzigen fehlschlagenden Objekt-Workflow herum aufbauen. Dazu gehören ein Quell-Backup, eine Backup-Copy, ein Bucket, ein Ziel-Appliance und ein Zeitfenster, und ich würde Veeam- und storage-seitige Logs für denselben Durchlauf sammeln.

Dann würde ich vier Vergleiche testen: primärer Standort gegenüber DR-Standort, ein Job gegenüber zwei, aktuelle Objekt-Appliance gegenüber einem anderen S3-kompatiblen Ziel und aktueller Veeam-Build gegenüber dem vom Hersteller unterstützten Wartungs-Build, falls ein Update verfügbar und freigegeben ist.

Ich würde den lokalen Disk-Schutzpfad gesund halten, während die Objektschicht untersucht wird. Ich würde außerdem prüfen, ob eine andere Offsite- oder Offline-Kopie weiterhin die geschäftliche Wiederherstellungsanforderung erfüllt.

Schnelle Leitungen sind nützlich, ersetzen aber keine Diagnose. Beim Objektspeicher-Backup kommen Sie am schnellsten zu einer Antwort, wenn Sie nicht mehr die gesamte Architektur auf einmal testen und stattdessen eine Schicht nach der anderen prüfen.