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 nützliche Lektion ist nicht, dass S3 unzuverlässig ist oder Veeam keinen Objektspeicher nutzen kann. Die aktuelle Dokumentation von Veeam Backup & Replication 13 unterstützt ausdrücklich S3-kompatiblen Objektspeicher und Scale-Out-Backup-Repository-Kapazitäts-Tiers. Die Lektion ist, dass Objektspeicher-Backup mehr bewegliche Teile hat, 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. 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 ist wichtig, weil sie das Problem eingrenzt. 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?

Weil Durchsatz nur eine Eigenschaft des Pfads ist. 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.

Diese Struktur schafft mehrere mögliche Fehlerschichten. Das Netzwerk kann Paketverlust oder Latenzspitzen haben. Die Objekt-Appliance kann unter Metadatenlast langsamer werden. API-Anfragen können mit Timeout scheitern. DNS oder TLS können zeitweise fehlschlagen. Storage-Firmware kann sich unter Nebenläufigkeit schlecht verhalten. Eine Veeam-Komponente kann auf einen Sonderfall stoßen. Keine dieser Möglichkeiten wird durch den Reddit-Bericht bewiesen, aber die Topologie bedeutet, dass sie isoliert und nicht erraten werden müssen.

Der Mr.PlanB-Leitfaden zu S3-Kosten und -Verhalten ist hier nützlich, weil Objektspeicher als API-gesteuertes Storage-Modell behandelt werden sollte, nicht als 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, ist das eine nützliche Grenze. 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 der nächste Schritt sollte immer an die Belege des vorherigen Tests geknüpft sein.

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.

Diese aktuelle Unterstützung ist wichtig, wenn man einen älteren oder versionsspezifischen Fehlerbericht liest. Ein Produktionsfehler bedeutet nicht, dass die Funktion nicht unterstützt wird. Er bedeutet, dass die Implementierung, Umgebung, Version, das Storage-Ziel oder das Zusammenspiel dieser Schichten diagnostiziert werden muss.

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.

Keine der beiden Schlussfolgerungen sollte auf gegenseitige Schuldzuweisung zwischen Herstellern zurückgehen. 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. Folgt es einer Appliance unabhängig von der Backup-Software, ist auch das aufschlussreich.

Eine gute Troubleshooting-Matrix ändert jeweils eine Schicht auf einmal.

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

Weil ein Neuaufbau viele Variablen gleichzeitig ändert 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.

Das ist ein gesunder Einwand. 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 ist relevant, weil Storage-Wiederherstellbarkeit auch Metadaten und Steuerungsebenen-Informationen umfasst, nicht nur Bytes auf einem Gerät.

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

Ich würde eine kontrollierte Reproduktionsumgebung um einen einzigen fehlschlagenden Objekt-Workflow herum aufbauen. Ein Quell-Backup, eine Backup-Copy, ein Bucket, ein Ziel-Appliance, ein Zeitfenster. 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. Sie sind keine Diagnose. Beim Objektspeicher-Backup führt der kürzeste Weg zu einer Antwort darüber, die gesamte Architektur nicht mehr auf einmal zu testen und stattdessen eine Schicht nach der anderen sich beweisen zu lassen.