Veeam Failover-Cluster-Kopien: Die Falle doppelter Daten

Cluster-Backup-Probleme werden schnell teuer, wenn gemeinsam genutzter Speicher so kopiert wird, als hätte jeder Node eine eigene Kopie. Genau dieses Verhalten meldete 2026 ein Veeam-12-Administrator: Backup-Kopien des Windows Failover Cluster wurden als nicht cluster-aware beschrieben, wobei gemeinsam genutzter Speicher für jeden Node dupliziert wurde.

Dieser Bericht sollte mit Vorsicht gelesen werden. Er beschreibt eine einzelne Produktivumgebung und einen Veeam-12-Workflow. Die im Juli 2026 aktualisierte aktuelle Veeam-13-Dokumentation besagt, dass die Backup-Kopie für Veeam-Agent-Failover-Cluster-Backups eine einzige Backup-Kopie-Datei pro Failover-Cluster erzeugt. Die Lücke zwischen diesen beiden Aussagen ist der Grund, warum Version und Schutzmethode eine Rolle spielen.

Was hat der Veeam-12-Administrator tatsächlich berichtet?

Die Umgebung nutzte Windows Failover Cluster, lokale Backups, S3-Kopier-Workflows und Tape. Inmitten einer umfassenderen Beschwerde über S3 und Support fügte der Administrator eine konkrete Cluster-Einschränkung hinzu: Unter Veeam 12 unterstützten die Windows-Failover-Cluster-Jobs Backup-Kopien nicht ordentlich, weil der Kopiervorgang nicht cluster-aware war und gemeinsam genutzten Speicher für jeden Node duplizierte.

Die Quelle nennt weder Cluster-Größe noch Kapazität des gemeinsam genutzten Volumes, den genauen Veeam-12-Build, die Agent-Version, die Job-Konfiguration noch einen Storage-Screenshot. Diese fehlenden Details sind wichtig. Sie verhindern, dass der Fall zu „Veeam 12 dupliziert immer Cluster-Daten" verallgemeinert wird.

Was der Fall belegt, ist eine praktische Warnung. Wenn ein Schutzprodukt die Node-Zugehörigkeit anders sieht als die Eigentümerschaft gemeinsam genutzter Daten, kann die Backup-Kopie-Kapazität stark von dem abweichen, was der Administrator erwartet.

Dieses Verhalten sollte beim Design-Test entdeckt werden, nicht erst nach Monaten angesammelter Aufbewahrung.

Warum ist die Duplizierung von gemeinsam genutztem Speicher so ein großes Problem?

Weil der Multiplikationsfaktor brutal sein kann. Ein großer Cluster-Datensatz, der einmal kopiert wird, mag akzeptabel sein. Derselbe Datensatz, der für jeden Cluster-Node erneut abgebildet wird, kann deutlich mehr sekundären Speicher verbrauchen und die Kopierfenster verlängern.

Die Kosten beschränken sich nicht auf reine Kapazität. Zusätzliche Daten erzeugen mehr Repository-I/O, mehr Object-Storage-Operationen, mehr WAN-Traffic, längere Aufbewahrungsverarbeitung und längere Health-Checks. Wenn das Kopierziel abrechnungspflichtiger Cloud-Storage ist, kann sich auch die Rechnung ändern.

Selbst On-Premises können doppelte logische Daten frühere Storage-Anschaffungen erzwingen und die Synchronisation für die Disaster Recovery erschweren, innerhalb des geforderten Zeitfensters fertig zu werden.

Der Storage-Hub von Mr.PlanB ist hier relevant, weil Backup-Kapazität um das Datenbewegungsmuster herum modelliert werden muss, nicht nur um die Größe des Quellvolumes. Ein gemeinsam genutzter 20-TB-Datensatz verhält sich wirtschaftlich nicht wie 20 TB, wenn der Schutz-Workflow ihn mehrfach schreibt.

Was sagt Veeam 13 zu Backup-Kopien von Failover-Clustern?

Die aktuelle Dokumentation von Veeam Backup & Replication 13 beschreibt einen eigenen Schutz-Workflow für Failover-Cluster mit Veeam Agent für Microsoft Windows. Sie besagt außerdem, dass beim Kopieren dieser Failover-Cluster-Backups der Backup-Copy-Job eine einzige Backup-Kopie-Datei pro Failover-Cluster erzeugt.

Dieselbe Dokumentation merkt an, dass Failover-Cluster-Jobs aufgrund von Cluster-Einschränkungen keine Backup-Dateien pro Maschine erzeugen. Stattdessen wird der Cluster für diese Backup-Methode als ein zusammenhängender Cluster-Scope behandelt.

Das unterscheidet sich deutlich von dem Verhalten, das der Administrator für Veeam 12 beschrieben hat. Es legt nahe, dass jeder, der das Problem 2026 bewertet, zuerst prüfen sollte, ob die genaue Version und Schutzmethode sich noch immer so verhalten, bevor er um die alte Einschränkung herum plant.

Gehen Sie nicht davon aus, dass „Veeam 12 hat das in einer Umgebung getan" beweist, dass „Veeam 13 das jetzt tut". Gehen Sie auch nicht davon aus, dass ein Upgrade eine Umgebung ohne Test repariert. Der genaue Job-Typ spielt eine Rolle.

Wie testen Sie Cluster-Awareness vor dem Rollout?

Erstellen Sie einen repräsentativen Cluster mit gemeinsam genutzten Daten und führen Sie einen vollständigen Schutzzyklus in ein Test-Repository durch. Erfassen Sie die logische Quellgröße, die Größe des ersten vollständigen Backups, das Inkrement-Verhalten und die Größe der Backup-Kopie.

Fügen Sie dann einen Node hinzu oder verschieben Sie die geclusterte Rolle zwischen Nodes. Führen Sie Backup und Kopie erneut aus. Das sekundäre Repository sollte deutlich zeigen, ob gemeinsam genutzte Daten einmalig behandelt oder pro Node wiederholt werden.

Führen Sie denselben Test nach einem Veeam-Upgrade erneut durch. Ein Produkt kann zwischen Major Releases ändern, wie geclusterte Assets erkannt, gruppiert oder kopiert werden. Eine Kapazitätsplanung, die für eine Version korrekt war, kann später zu konservativ oder zu optimistisch werden.

Für Virtualisierungsteams, die größere Plattformwechsel prüfen, macht der Proxmox-Backup-Leitfaden von Mr.PlanB einen ähnlichen Punkt: Backup-Verhalten muss gegen die tatsächlich geschützten Plattformobjekte getestet werden, nicht aus einem allgemeinen Feature-Label abgeleitet.

Was sollten Sie neben der Repository-Größe noch messen?

Messen Sie Kopierdauer, WAN-Nutzung, Wiederherstellungsgranularität und was passiert, wenn ein Node nicht verfügbar ist. Ein kleineres Backup ist nicht automatisch besser, wenn der Restore-Workflow dadurch schwieriger wird.

Testen Sie bei einem Failover-Cluster die Wiederherstellung gemeinsam genutzter Daten und einzelner Nodes gemäß der unterstützten Methode. Bestätigen Sie, ob wiederhergestellte Daten korrekt auf den Cluster zurückgeführt werden. Bestätigen Sie, wie Witness-Disks und gemeinsam genutzte Disks während der Wiederherstellung dargestellt werden.

Die aktuelle Veeam-Dokumentation beschreibt spezifisches Verhalten für gemeinsam genutzte Disks und Disk-Witnesses. Das ist ein weiterer Grund, warum der Restore-Test wichtig ist. Cluster-Backup ist nicht einfach gewöhnliches Server-Backup, das mehrfach wiederholt wird.

Testen Sie außerdem die Aufbewahrung. Wenn ein Backup-Copy-Job langfristige GFS-Punkte verwendet, kann sich ein Duplizierungsproblem über viele wöchentliche, monatliche oder jährliche Wiederherstellungspunkte hinweg summieren.

Ein sauberes vollständiges Backup ist kein ausreichender Beleg für ein Kapazitätsmodell über ein ganzes Jahr.

Sollte ein Team nur wegen dieses Problems auf Veeam upgraden?

Nur nachdem bestätigt wurde, dass die aktuelle unterstützte Version das genaue Verhalten ändert, das das Problem verursacht. Die Veeam-13-Dokumentation ist für das konkrete Backup-Copy-Modell von Failover-Clustern ermutigend, aber ein Upgrade ändert mehr als nur ein Feature.

Inventarisieren Sie Repositories, Proxys, Agents, Tape, Object-Storage, Verschlüsselung, Skripte und Application-Aware-Processing, bevor Sie die Control Plane verschieben. Reproduzieren Sie dann den Cluster-Kopiertest in der Zielversion, bevor Sie das Problem für gelöst erklären.

Wenn die Umgebung bereits eine V13-Migration plant, sollte dieser Test Teil der Abnahme sein. Wenn V12 stabil und für den erforderlichen Zeitraum unterstützt ist, ist je nach Workload möglicherweise eine kleinere Architekturänderung möglich.

Die Frage lautet nicht „Ist V13 neuer?". Die Frage lautet: „Beseitigt der unterstützte V13-Workflow die gemessene Duplizierung, ohne eine andere Wiederherstellungsanforderung zu brechen?"

Was würde ich mit einem Cluster tun, der bereits Daten dupliziert?

Ich würde zuerst die Verschwendung quantifizieren. Vergleichen Sie die reale geschützte gemeinsam genutzte Kapazität des Clusters mit der logischen Kapazität, die in das sekundäre Repository geschrieben wird. Identifizieren Sie, welche Wiederherstellungspunkte wiederholte Daten enthalten und wie stark die Aufbewahrung diesen Effekt verstärkt.

Dann würde ich denselben Cluster-Schutz-Job in einer aktuellen Veeam-13-Testumgebung mit dem dokumentierten Failover-Cluster-Workflow nachbauen. Führen Sie primäres Backup, Backup-Kopie, Aufbewahrung und Restore-Tests durch.

Wenn die aktuelle Version wie dokumentiert eine Kopie auf Cluster-Ebene erzeugt und die Wiederherstellung funktioniert, hat das Upgrade einen messbaren Business Case. Bleibt die Duplizierung bestehen, weil die Produktivumgebung eine andere Schutzmethode verwendet, ist der nächste Schritt, das Job-Design zu ändern oder mit diesen Belegen einen gezielten Support-Fall zu eröffnen.

Cluster-Awareness ist keine Checkbox. Es ist etwas, das Sie beweisen, indem Sie beobachten, wie das Produkt gemeinsam genutzte Daten speichert und wiederherstellt.