Veeam: Retention und Repository-Platz

Kunde SMS; Veeam sms-vbr01, Linux, geprüft 13.0.3.63. Systembindung, Endpoints und Vault-Item-IDs stehen in context/systems.yaml.

Aktueller Stand

Am 20.09.2026 wurden die sieben ausdrücklich freigegebenen alten Hyper-V-/ Migrationsbestände vollständig entfernt. Zusätzlich wurden sechs erst beim Verzeichnisabgleich gefundene Dateien einer Kette vom Juni 2020 nach separater Benutzerfreigabe gelöscht. Alle sieben alten Verzeichnisse sind leer oder entfernt.

Abschlussmessung 12:29 MESZ: QNAP-Day 43 % belegt, 11,83 TiB frei (12.697.821.100 KiB). RAID5: vier Mitglieder, [UUUU], kein aktiver NFS-Unlink. Veeam enthält genau die 15 aktuellen Backups. Deren 151 Dateien sind vorhanden; tatsächliche Größen und Änderungszeiten stimmen mit der Kontrollaufnahme überein. Das ist eine Datei-/Katalogprüfung, kein Restore-Test oder Inhaltsprüfsummenvergleich. Beide aktuellen Jobs melden als letztes Ergebnis Success; nächste Läufe 22:00 (Schulnetz) und 23:00 (Verwaltungsbackup). Repository-Rescan erfolgreich.

Nachweise: docs/veeam-cleanup-2026-09-20.json, docs/veeam-retention-2026-09-20.json, changes/2026-09-20-veeam-cleanup.receipt.json.

Aufbewahrung

Schulnetz (9 VMs) und Verwaltungsbackup (6 VMs): 7 Tage, GFS 1 Woche / 2 Monate / 1 Jahr; synthetisches Full samstags, Active Full deaktiviert. Diese Einstellungen wurden nicht verändert. Der Platzverbrauch wurde durch die separat verbliebenen Altbestände bereinigt. GFS-Fulls und Kettenabhängigkeiten benötigen zusätzlichen Platz; kürzere Tagesretention entfernt weder GFS-Fulls noch automatisch jeden importierten Altbestand.

Zugriff und Bestandsprüfung

REST API https://10.64.1.20:9419, Header x-api-version: 1.3-rev1. Token nur im Zielprozess über lanstyle-vault run, Kunde sms, System sms-veeam, Credential sms-veeam-admin. Keine Tokens, Kennwörter oder Accountnamen protokollieren.

Server-ID 83dbdbef-f91a-4342-a874-65dc3ab8c698 prüfen. Backups und Dateien vollständig paginieren; Repository-ID, Jobbindung, GFS, Alter und Dateipfade abgleichen. Die installierte REST-Revision unterstützt die Konfiguration von Proxmox-Jobs nicht. Dafür vorhandenes Veeam-PowerShell-Modul verwenden: Get-VBRJob und Get-VBRJobOptions, SSH mit sms-veeam-codex über sms-pve03, VBR-Anmeldung separat mit sms-veeam-admin. Kein Root-Fallback und keine wiederholten Anmeldungen nach Authentifizierungsfehlern.

QNAP-Day: sms-qnap-day-admin, physischer Share /share/CACHEDEV1_DATA/Backup. Aufeinanderfolgende Prüfungen bündeln und die bestehende SSH-Sitzung wiederverwenden; für neue Verbindungen globale OpenSSH-Konfiguration mit ControlMaster/ControlPersist nutzen. Keine Fremdpakete auf den Appliances installieren. Aktuelle Kapazität über df prüfen; Veeams Kapazitätswerte können bis zum Rescan veraltet sein.

Wiederkehrender Bereinigungsweg

1. Destruktive Löschung einmal mit exakten Beständen und fehlendem Rückweg freigeben lassen. Prestate: Server, Repository, Backup-IDs, Dateien, Größen, Altersgrenzen und zu erhaltende Backups sichern. Unbekannte Zusatzketten benötigen eine eigene Scope-Freigabe.
2. Unterstützter Veeam-Pfad: DELETE api/v1/backups/{id} mit fromDB=false, fromDBIfSPUnavailable=false, includeGFS=false. Seriell arbeiten und die zurückgegebene Session bis zum Terminalzustand verfolgen.
3. Nach jeder erfolgreichen Session die zugehörigen Dateipfade auf dem NAS und den Erhalt der aktuellen Backup-IDs prüfen. Bei unklarem Ergebnis keine DELETE-Wiederholung; Session, Dateibestand und Dateisystemaktivität abgleichen.
4. Bei NFS-Timeout und weiter wachsendem freien Platz laufende Blockfreigabe abwarten. Kein Neustart, Remount oder Dateisystemcheck zur Beschleunigung. Ein verschwundener Katalogeintrag beweist keine vollständige Dateilöschung.
5. Nach Stillstand betroffener Backupjobs Repository über POST api/v1/backupInfrastructure/repositories/rescan mit der gebundenen Repository-ID abgleichen. Als Imported/Orphaned erkannte Bestände über Veeam löschen. Nicht mehr registrierte Restdateien nur nach eindeutiger Zuordnung und ausdrücklicher Löschfreigabe behandeln: exakte Pfade, Typ, Größe und unveränderten Prestate prüfen, ausschließlich diese Dateien entfernen. Kein pauschales Verzeichnis-RM und keine aktiven Ketten anfassen.
6. Abschluss: freigegebene IDs und Dateien fehlen; Altverzeichnisse prüfen; aktuelle Backup-IDs und Dateien vorhanden; freien Platz direkt messen. Veeams backupSize kann von der tatsächlichen Dateigröße abweichen – für einen Vorher/Nachher-Vergleich dieselbe Dateisystemsicht verwenden.

Löschen hat keinen technischen Rollback. Eine Konfigurationssicherung stellt entfernte Backupdaten nicht wieder her. Git/Change/Receipt, Wiki und OPKG nachführen.