NetBackup-FETB-Lizenzierung: Warum die Kapazität zu hoch wirkt

Eine NetBackup-FETB-Überschreitung sollten Sie abgleichen, bevor Sie Backup-Policies neu gestalten. Wer einen Dateiserver von einer Agent-Policy auf Schutz auf VM-Ebene umstellt, senkt die Lizenznutzung damit nicht automatisch, denn die aktuellen FETB-Plus-Bedingungen klassifizieren qualifizierende virtuelle Workloads unabhängig vom angewendeten Policy-Typ mit einem Verhältnis von 1,5 zu 1.

Genau daran hing ein aktuelles Administratorproblem. Die Umgebung lag über ihrem lizenzierten Limit, und als Lösung war geplant, Dateiserver von wöchentlichen vollständigen Backups plus täglichen differenziellen Agent-Backups auf VM-Backups mit Accelerator und blockbasierten Inkrementen umzustellen.

Was misst NetBackup-FETB eigentlich?

FETB steht für Front End Terabyte und ist eine Messgröße der Kapazitätslizenz, die sich nach der Menge der geschützten Front-End-Daten richtet. Mit der Größe des deduplizierten Backup-Repositorys hat sie ebenso wenig zu tun wie mit der Zahl der Bytes, die jeder Backup-Job schreibt.

Die NetBackup-Dokumentation beschreibt ein FETB als 1 TB geschützter Daten. Für die Lizenzsumme wertet das Usage-Reporting die geschützte Umgebung sowie Policy- und Workload-Informationen aus.

Deshalb führt die Backup-Häufigkeit in Lizenzgesprächen leicht in die Irre. Ein wöchentliches vollständiges Backup plus mehrere differenzielle Backups bewegen mehr Daten durch die Infrastruktur als ein einzelner Snapshot, doch der Lizenzzähler misst das geschützte Front-End und behandelt nicht jede geschriebene Kopie als neue vollständige Menge. Bevor Sie Zeitpläne ändern, ermitteln Sie daher, welche Clients und Workloads die Lizenzsumme erzeugen.

Erhält ein virtueller Dateiserver das 1,5-zu-1-FETB-Plus-Verhältnis?

Nach Cohesitys NetBackup Product Specific Terms vom April 2026 zählt FETB Plus physische Workloads im Verhältnis 1 FETB Plus zu 1 FETB geschützter Daten und virtuelle Workloads im Verhältnis 1 FETB Plus zu 1,5 FETB geschützter Daten. Zu den virtuellen Workloads gehören virtuelle Maschinen auf Plattformen wie VMware, Hyper-V, Nutanix AHV, Red Hat Virtualization, Azure Stack und OpenStack.

Entscheidend ist die Formulierung, dass die virtuelle Klassifizierung unabhängig vom Policy-Typ gilt, mit dem die Workload geschützt wird. Das stützt den Einwand aus der Reddit-Diskussion: Ist der Dateiserver bereits eine qualifizierende virtuelle Workload und besitzt die Organisation die passende Flexible-Licensing-Edition, bringt der Wechsel von einer Agent-Policy zu einer VM-Policy möglicherweise nicht die erhoffte Lizenzreduzierung.

Wenden Sie dieses Verhältnis nicht aus dem Gedächtnis auf jeden Vertrag an. Produktbedingungen ändern sich, Editionen unterscheiden sich, und ältere Entitlements folgen womöglich anderen Regeln. Gleichen Sie den Berichtszeitraum mit den Product Specific Terms und den Kaufunterlagen ab, die für Ihre Umgebung gelten.

Reduzieren Accelerator und blockbasierte Inkremente den FETB-Wert?

Backup-Traffic und Storage-Aufwand können sie senken, als Lizenztrick taugen sie aber nicht. Accelerator und blockbasierte inkrementelle Methoden sind operative Optimierungen. Sie können die Datenmenge späterer Backups verringern, weil NetBackup unveränderte Daten nicht erneut sendet, wie es bei einem klassischen vollständigen Lesen der Fall wäre.

Die FETB-Kapazitätslizenzierung misst etwas anderes. Umfasst die geschützte Front-End-Workload weiterhin 20 TB, wird aus ihr durch eine effizientere Backup-Strecke nicht automatisch eine mit 10 TB lizenzierte Workload.

Architektonisch lohnt es sich, das auseinanderzuhalten. Backup-Optimierung wirkt auf Netzwerk, Media-Server-Last, Fensterlänge und Repository-Verbrauch, während die Lizenzregeln festlegen, wie die geschützte Workload gezählt wird.

Wenn Sie auch Backup-Architekturen in anderen Virtualisierungs-Stacks vergleichen, hilft der Proxmox-Backup-Vergleich, die Backup-Methode von der Größe der geschützten Workload zu trennen. Auch dort gilt, dass der effizienteste Datenpfad nicht automatisch den kleinsten Lizenzzähler ergibt.

Kann nbdeployutil denselben Server doppelt zählen?

Das Tool kann Ergebnisse liefern, die Sie abgleichen müssen, etwa wenn dasselbe Asset über unterschiedliche Policy-Pfade geschützt wird oder die Usage-Klassifizierung nicht sauber übereinstimmt. In der Reddit-Diskussion lautete der konkrete Rat, zu prüfen, ob derselbe Dateiserver während der Migration zwischen den Methoden durch VMware- und Windows-NT- oder Standard-Policies mehrfach gezählt wurde.

Laut NetBackup-Dokumentation berücksichtigt das Usage-Reporting die geschützten Daten, und mehrere Kopien desselben Backups zählen nicht einfach als separate geschützte Front-End-Kapazität. Policy-Kombinationen, korrekter Licensing-Support, Client-Identität und Übergangszustände können den Report trotzdem überraschend aussehen lassen.

Behandeln Sie nbdeployutil deshalb als Report, den Sie abgleichen, und übernehmen Sie die Zahl nicht ungeprüft. Öffnen Sie die detaillierte Client- und Policy-Ausgabe und gleichen Sie Hostnamen mit den tatsächlichen Assets ab. Suchen Sie nach doppelten Identitäten, alten Policies, die noch laufen, und Workloads, die sowohl auf VM- als auch auf Gastebene geschützt werden.

Schützen zwei Policies absichtlich unterschiedliche Datensätze auf demselben Server, sind die Daten aus Lizenzsicht möglicherweise nicht doppelt. Schützen sie während einer Migration dasselbe Dateisystem, dokumentieren Sie diese Überschneidung und gleichen Sie sie nach dem geltenden Lizenzprozess ab.

Was sollten Sie vor der Änderung von Schutz-Policies prüfen?

Beginnen Sie mit dem Vertrag und den aktuellen Product Specific Terms. Klären Sie, ob die Umgebung unter NetBackup Platform Base Complete Edition with Flexible Licensing oder einem anderen Modell lizenziert ist und ob FETB Plus gilt.

Führen Sie dann einen aktuellen Usage-Report aus und gruppieren Sie die Ergebnisse nach Workload. Halten Sie für jeden Großverbraucher die physische oder virtuelle Klassifizierung, die Policy-Typen, die geschützte Größe, doppelte Schutzpfade und ob das Asset noch aktiv ist.

Migrationen verdienen besondere Aufmerksamkeit. Oft bleibt eine alte Agent-Policy aktiv, während eine neue VM-Policy getestet wird. Für die Sicherheit der Wiederherstellung ist diese Überschneidung sinnvoll, sie kann aber Lizenzberichte verkomplizieren, wenn beide Pfade wochenlang laufen.

Ich würde außerdem Assets markieren, die stillgelegt wurden, aber noch in Policy-Definitionen stehen. Die allgemeine Lektion zur Backup-Hygiene aus Proxmox Backup Server gilt auch hier: Das Inventar muss der Realität entsprechen, denn veraltete Schutzobjekte erzeugen operatives Rauschen, auch wenn die Storage-Technologie eine andere ist.

Sollten Sie trotzdem auf Backup auf VM-Ebene umsteigen?

Steigen Sie um, wenn es Recovery, Betrieb oder Infrastruktureffizienz verbessert. Die Annahme, es werde das FETB-Problem lösen, ist dafür kein guter Grund. Backup auf VM-Ebene kann die Wiederherstellung ganzer Maschinen vereinfachen und bei manchen Workloads die Verwaltung von Guest-Agents reduzieren, während Schutz auf Gast- oder Anwendungsebene für granulare Datei- oder Datenbank-Wiederherstellung weiterhin nötig sein kann.

Vergleichen Sie bei Dateiservern zuerst die Restore-Anforderungen. Brauchen Sie die vollständige VM-Wiederherstellung, einzelne Dateien, lange Aufbewahrung, anwendungskonsistente Snapshots oder eine Wiederherstellung auf alternativer Infrastruktur? Danach wählen Sie die NetBackup-Methode, die diese Anforderungen erfüllt.

Ist der Lizenzreport falsch, korrigieren Sie Report und Klassifizierung. Ist das Lizenz-Entitlement für die geschützte Umgebung tatsächlich zu klein, bleiben mehrere Wege: den geschützten Umfang reduzieren, Aufbewahrung oder Workload-Design dort ändern, wo es das Entitlement beeinflusst, einzelne Workloads auf eine andere Plattform oder ein anderes Produkt verschieben oder ausreichend Kapazität kaufen.

Am schlechtesten ist es, die Wiederherstellung zu schwächen, nur damit ein verwirrender Report kleiner aussieht. Gleichen Sie zuerst ab und gestalten Sie danach neu.