# GFS – Grandfather-Father-Son Backup Rotation Schema im Enterprise-Einsatz

TL;DR / Management Summary Das GFS-Schema ist eine hierarchische Retention-Strategie, die Speicherkosten optimiert, indem sie die Granularität der Sicherungen mit zunehmendem Alter reduziert. Sie ist der Goldstandard für Umgebungen mit strengen gesetzlichen Compliance-Anforderungen (z.B. 7 Jahre Aufbewahrung). Nutze GFS immer dann, wenn du eine Balance zwischen schnellen Wiederherstellungen (Son-Level) und langfristiger Archivierung (Grandfather-Level) auf unterschiedlichen Speichermedien (Disk, Cloud, Tape) benötigst.

# 1. Einführung & Architektur

GFS ist keine Backup-Software, sondern ein Retention-Modell. Es definiert, wann eine Sicherungskopie von einem kurzlebigen Speicherort in einen langlebigen Archivspeicher überführt (promoted) oder gelöscht werden muss.

# Warum brauchen wir das?

• Problemstellung aus der Praxis: Eine simple “Halte die letzten 30 Tage”-Strategie führt bei jährlichen Compliance-Anforderungen (z.B. SOX, DSGVO) zu ineffizienten Speichervolumen. Wenn wir 7 Jahre Daten benötigen, aber jeden Tag ein Full Backup speichern, explodieren die Kosten.
• GFS-Lösung: GFS strukturiert die Datenaufbewahrung in drei Ebenen:
  • Son (S): Tägliche Backups. Hohe Granularität, kurze Verweildauer (z.B. 5-7 Tage). Dienen der schnellen Wiederherstellung bei Benutzerfehlern oder kleinen Ausfällen (hohes RPO).
  • Father (F): Wöchentliche Backups. Mittlere Granularität, mittlere Verweildauer (z.B. 4 Wochen). Dienen der Wiederherstellung nach größeren Ausfällen, die eine Woche dauern könnten.
  • Grandfather (G): Monatliche/Jährliche Backups. Niedrige Granularität, lange Verweildauer (z.B. 12 Monate, 7 Jahre). Dienen der gesetzlichen Archivierung und Disaster Recovery.

# Architektur-Diagramm (Retention Logic Flow)

Die GFS-Architektur ist ein Logik-Stack, der typischerweise durch ein zentrales Backup-Management-System (oder proprietäre Skripte) auf Basis von Datum und Wochentag gesteuert wird.

graph TD
    A[Tägliche Sicherung] --> B{Ist es der letzte Tag der Woche?};
    B -- Nein --> C(Als 'Son' (S) Speichern, 7 Tage halten);
    B -- Ja --> D{Als 'Father' (F) Promoten};
    D --> E{Ist es der letzte Tag des Monats?};
    E -- Nein --> F(Als 'Father' (F) Speichern, 4 Wochen halten);
    E -- Ja --> G{Als 'Grandfather' (G) Promoten};
    G --> H(Als 'Grandfather' (G) Speichern, 12 Monate / 7 Jahre halten);
    H --> I[Archivspeicher (Tape/Cold Cloud)];
    F --> J[Zwischenspeicher (Fast Disk)];
    C --> J;

# Kernel-Sicht (Die Speicherschicht)

Obwohl GFS primär eine logische Strategie ist, beeinflusst sie die physische Speicherung direkt:

1. Block Layer: Alle Backups beginnen als Block- oder File-Level-Daten.
2. Storage Target (S- und F-Tier): Diese Ebenen liegen typischerweise auf schnellem, dedupliziertem Block- oder Object Storage (RAID, NVMe Array, S3 Standard). Hohe I/O-Performance ist entscheidend für schnelle Wiederherstellungen (niedriges RTO).
3. Archiv Target (G-Tier): Diese Ebene wird auf kostengünstigere, langsamere Targets verschoben. Dies kann Cold Storage (AWS Glacier, Azure Archive) oder physische Tape Libraries (LTO) sein. Hier sinken die Speicherkosten dramatisch, aber das RTO für diese Daten steigt (Stunden oder Tage, anstatt Minuten).

# 2. Installation & Grundkonfiguration (Praxis)

Da GFS eine Logik ist, besteht die “Installation” darin, die Policy in das Backup-System zu integrieren und das Speichermodell zu definieren.

# Voraussetzungen

1. Zeitsynchronität (NTP): Absolut kritisch. Die Promotionslogik (day_of_week, day_of_month) muss konsistent sein. Zeitabweichungen führen zu inkonsistenten Retention Chains.
2. ID-System: Jede Sicherung benötigt eine eindeutige, unveränderliche ID und Metadaten (Zeitstempel, Quelle, Größe).
3. Speicherpools: Mindestens zwei getrennte Storage Pools (Primary Fast / Secondary Archival).

# Schritt-für-Schritt Setup (Implementierung der Logik)

Wir demonstrieren die logische Konfiguration, wie sie in einem cron oder einem Backup-Orchestrator ausgeführt wird.

Angenommen, wir definieren:

• S = Letzte 7 Tage (täglich)
• F = Letzte 4 Wochen (jeweils die Sicherung vom Samstag)
• G = Letzte 12 Monate (jeweils die Sicherung vom letzten Tag des Monats)
• Y = Letzte 7 Jahre (jeweils die G-Sicherung vom Dezember)

#!/bin/bash
# retention_cleanup.sh

# Definiere das Basis-Verzeichnis der Backups
BACKUP_ROOT="/mnt/backup_repo"

# --- VARS ---
DATE_TODAY=$(date +%Y%m%d)
DAY_OF_WEEK=$(date +%u) # 1=Montag, 7=Sonntag

# --- 1. SON Retention (S) ---
# Lösche Backups, die älter als 7 Tage sind
find ${BACKUP_ROOT}/daily/ -type d -mtime +7 -exec rm -rf {} \;
echo "INFO: Daily 'Son' backups older than 7 days purged."

# --- 2. FATHER Promotion (F) ---
# Finde das Backup, das zur F-Promotion markiert werden muss (z.B. Sonntag)
if [ "$DAY_OF_WEEK" -eq 7 ]; then
    # Wir nehmen das Backup von gestern (Samstag) als 'Father'
    FATHER_DATE=$(date --date="1 day ago" +%Y%m%d)
    
    # Prüfen, ob die Quell-Sicherung existiert
    if [ -d "${BACKUP_ROOT}/daily/${FATHER_DATE}" ]; then
        # Kopiere (oder verschiebe/hardlink) in den wöchentlichen Pool
        # --archive / -P für Permissions und Sicherheit
        rsync -aP "${BACKUP_ROOT}/daily/${FATHER_DATE}" "${BACKUP_ROOT}/weekly/"
        echo "SUCCESS: Backup ${FATHER_DATE} promoted to 'Father' tier."
    else
        echo "ERROR: Source daily backup for Father promotion not found!"
    fi
fi

# --- 3. GRANDFATHER Promotion (G) ---
# Finde das Backup, das zur G-Promotion markiert werden muss (Letzter Tag des Monats)
# Hier nutzen wir das 'next_month' Trick, um den Monatswechsel sicher zu erkennen
if [ "$(date +%d)" -gt 28 ]; then
    NEXT_MONTH_DAY=$(date -d tomorrow +%d)
    if [ "$NEXT_MONTH_DAY" -eq 1 ]; then
        # Gestern war der letzte Tag des Monats
        GRANDFATHER_DATE=$(date --date="1 day ago" +%Y%m%d)

        # Promotion von Weekly (F) nach Monthly (G)
        rsync -aP "${BACKUP_ROOT}/weekly/${GRANDFATHER_DATE}" "${BACKUP_ROOT}/monthly/"
        echo "SUCCESS: Backup ${GRANDFATHER_DATE} promoted to 'Grandfather' tier."
        
        # Starte den Cold Storage Job (z.B. S3 sync mit Lifecycle Policy)
        /usr/local/bin/archive_to_glacier.sh "${BACKUP_ROOT}/monthly/${GRANDFATHER_DATE}"
    fi
fi

# 4. F und G Cleanup (Retention Policy)
# Hier müssen die spezifischen Retention-Rules implementiert werden (z.B. Lösche F-Backups > 4 Wochen, G-Backups > 12 Monate, ausser Dezember Gs).

Profi-Tipp: Nutzen Sie in komplexen GFS-Umgebungen Hardlinks (wenn das Filesystem dies unterstützt) anstelle von Kopien, um Speicherplatz zu sparen, solange die Daten im gleichen Volume liegen. Beim Verschieben auf ein Archiv-Volume (Tiering) ist jedoch eine echte Kopie nötig.

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning (Speicher-Tiering)

Der wichtigste Tuning-Hebel im GFS-Kontext ist das Storage Tiering und die Deduplizierung.

1. Deduplizierung (Source-Side): Führen Sie die Deduplizierung idealerweise auf dem Client (Source-Side) durch, bevor die Daten das Netzwerk verlassen. Dies reduziert das Übertragungsvolumen, was besonders wichtig für die täglichen (S) Backups ist.
2. Tiering Strategie (Promotion): Die Promotion von F nach G sollte nicht nur eine logische Markierung sein, sondern eine physische Verschiebung.
   • Metadaten-Trennung: Die Backup-Metadaten (der Index) müssen immer auf dem schnellsten Speicher verbleiben, selbst wenn die eigentlichen Daten im Archiv (G-Tier) liegen. Nur so wird das Durchsuchen alter Backups schnell und das RTO überschaubar.
   • Chunk-Sizes: Bei der Archivierung auf Tapes (G-Tier) die Chunk-Sizes der Backup-Software maximieren, um die Bandlaufwerkeffizienz zu erhöhen (weniger Start/Stopp-Zyklen).

# Hardening & Security (Compliance Focus)

In einer GFS-Umgebung sind die Grandfather-Backups das letzte Rettungsnetz und oft Gegenstand von Audits.

1. Unveränderlichkeit (Immutability):
   • Implementieren Sie Write Once Read Many (WORM) auf dem Archivspeicher (G-Tier). Bei S3 nutzen Sie den Object Lock im Compliance-Modus für die Dauer der gesetzlichen Aufbewahrungspflicht.
   • Dies verhindert, dass Ransomware oder böswillige Insider die archivierten G-Backups löschen oder verschlüsseln können.
2. Verschlüsselung (End-to-End): Alle Backups sollten mit starker, getrennter Verschlüsselung gesichert werden (AES-256). Der Schlüssel für die G-Tier-Daten sollte sicher im Key Management System (KMS) verwahrt und nur wenigen Mitarbeitern zugänglich sein.
3. Audit-Trail: Führen Sie detaillierte Log-Dateien über jede Promotion, jeden Cleanup und jeden Löschvorgang (zwingend erforderlich für Compliance-Nachweise). Diese Logs müssen selbst archiviert werden.

# 4. Day-2 Operations: Wartung & Alltag

Die größte Herausforderung bei GFS ist die Verwaltung der langlebigen Retention Chains.

# Typische Tasks

# Automatisierung (Ansible)

Ansible oder Terraform wird verwendet, um sicherzustellen, dass die GFS-Policy auf allen Backup-Clients und im zentralen Orchestrator idempotent umgesetzt wird.

# Ansible Playbook: Sicherstellung der GFS-Retention Policy Konfiguration

- name: Enforce GFS Retention Policy on Backup Server
  hosts: backup_master
  tasks:
    - name: Deploy GFS Cleanup Script
      ansible.builtin.copy:
        src: files/retention_cleanup.sh
        dest: /usr/local/bin/retention_cleanup.sh
        owner: root
        mode: '0700'

    - name: Ensure retention schedule is active (Promotion Logic)
      ansible.builtin.cron:
        name: "GFS Daily Cleanup and Promotion"
        minute: "0"
        hour: "3" # Läuft nach Abschluss der nächtlichen S-Backups
        user: root
        job: "/usr/local/bin/retention_cleanup.sh >> /var/log/gfs_retention.log 2>&1"
        cron_file: gfs_rotation

    - name: Configure S3 Object Lock for Grandfather (G) Archive Bucket
      community.aws.s3_bucket:
        bucket: my-enterprise-gfs-archive
        object_lock_enabled: true
        force_ipv4: true
        state: present
        # Wichtig: Die eigentliche Retention Rule (7 Jahre) wird über S3 Lifecycle Policy konfiguriert

# 5. Troubleshooting & “War Stories”

Die Komplexität von GFS liegt in den logischen Edge Cases und der Interaktion zwischen den Speichertiers.

# Top 3 Fehlerbilder

# 1. Symptom A: Speicherpool für ‘Father’ (F-Tier) läuft schneller voll als erwartet.

• Fehlermeldung: Storage Quota exceeded, Backup Job failed.
• Ursache: Die Promotion von F nach G schlägt fehl (z.B. Archive-System offline, Netzwerk-Timeout), und F-Backups verbleiben auf dem schnelleren, teureren Speicher. Oder die Deduplizierung hat nicht gegriffen (z.B. durch Client-Software-Update).
• Lösung: Sofortige manuelle Überprüfung der G-Promotion-Skripte und der Zielverfügbarkeit (Tape Library, Cloud API). Temporär die F-Retention verlängern, bis das G-Problem behoben ist, um keine Daten zu verlieren.

# 2. Symptom B: Performance-Einbruch bei der Wiederherstellung alter G-Backups.

• Analyse: Die Wiederherstellungszeit (RTO) übersteigt die SLA um das 10-fache.
• Ursache: Die Metadaten (Katalog) der G-Backups sind nicht im schnellen Speicher verfügbar und müssen erst aus dem langsamen Archiv (Band oder Cold Cloud) wiederhergestellt werden. Oder der Tape-Robot muss Bänder erst physisch lokalisieren.
• Lösung: Stellen Sie sicher, dass die Metadaten (der Index) nie archiviert werden, sondern auf dem Primary Storage verbleiben. Bei Tape-Systemen: Prüfen Sie das “Tape Staging” – wichtige G-Backups (z.B. Jahresenden) können auf schnellen Zwischenspeicher (Disk Cache) kopiert werden.

# 3. Symptom C: “Ich kann den Stand vom 3. Februar 2022 nicht wiederherstellen.”

• Ursache: Fehler im G-Promotion-Skript. Die Logik zum Finden des letzten Tages des Monats war fehlerhaft (z.B. hartkodiert auf den 31. des Monats, was im Februar scheitert), wodurch das G-Backup für diesen Monat nie erstellt oder markiert wurde.
• Lösung: Manuelles Durchforsten des F-Tiers, um zu prüfen, ob ein passendes Wochen-Backup existiert, das man stattdessen verwenden kann. Für die Zukunft: Testen der Promotion-Logik mit Edge Cases (Schaltjahr, Monate mit 30/31 Tagen).

# Recovery Szenarien

Metadata Corruption (Der GAU): Wenn die zentrale Katalogdatenbank des Backup-Systems beschädigt wird (z.B. durch Hardware-Ausfall), sind alle Retention Chains nutzlos, da das System nicht mehr weiß, welche Datei zu welchem Backup gehört, selbst wenn die Daten physisch auf dem Band liegen.

• Lösung: Backup der Metadaten. Führen Sie dreimal täglich ein dediziertes Backup der Backup-Katalogdatenbank durch und speichern Sie es außerhalb des primären Backup-Speichers (z.B. auf einem separaten, verschlüsselten NFS-Share). Nutzen Sie vgcfgrestore (wenn LVM involviert ist) oder die systemeigene Katalogwiederherstellung.

Anekdote (War Story): Wir hatten einmal den Fall, dass ein fehlerhafter rsync-Parameter dazu führte, dass die G-Promotion nur die Metadaten, aber nicht die eigentlichen Datenblöcke auf das Archiv-System verschob. Dies fiel erst 14 Monate später auf, als eine behördliche Anfrage die Wiederherstellung eines alten Jahresabschlusses erforderte. Seitdem gilt die Regel: Ein Restore-Test ist wichtiger als 100 erfolgreiche Backups.

# 6. Monitoring & Alerting

Monitoring muss sich auf die Integrität der Kette und die Verfügbarkeit des Archivs konzentrieren, nicht nur auf den I/O-Durchsatz.

# Metriken (KPIs)

# Alerting-Regeln

• PAGER (Kritisch):
  • RCI-Failure: Wenn die G-Promotion an zwei aufeinanderfolgenden Versuchen fehlschlägt (Datenverlustrisiko für die Langzeitarchivierung).
  • F-Tier Storage Free Space < 15%.
• E-Mail (Warnung):
  • RTO Test Failure.
  • Retention Cleanup Script hat Log-Einträge der Stufe ERROR oder WARNING.

# Beispiel Prometheus Exporter Logik

Ein einfacher node_exporter Textfile Collector kann die RCI melden:

# /var/lib/node_exporter/textfile_collector/gfs_health.prom
gfs_promotion_success{tier="F"} 1
gfs_promotion_success{tier="G"} 0  # CRITICAL: G-Promotion failed heute
gfs_weekly_storage_free_bytes 1.5e+12

# 7. Fazit & Empfehlung

GFS ist ein bewährtes und leistungsstarkes Modell zur Kostensenkung und Compliance-Sicherstellung. Es ist jedoch logisch anspruchsvoll.

Wann würde ich GFS einsetzen?

• Wenn Compliance-Vorgaben (Jahre der Aufbewahrung) existieren.
• In großen, heterogenen Enterprise-Umgebungen, in denen eine manuelle Retention-Verwaltung unmöglich ist.
• Wenn Sie verschiedene Speichertiers (High Performance Disk, Cloud Archive, Tape) optimal nutzen wollen.

Wann würde ich es nicht einsetzen?

• In kleinen bis mittleren Umgebungen oder für einzelne Server: Die Komplexität übersteigt den Nutzen. Ein einfaches Rolling Snapshot-Schema oder ein linearer Retentionsplan (z.B. ZFS Snapshots, die durch ein einfaches prune-Skript verwaltet werden) ist oft einfacher und ausreichend.
• Wenn die Recovery-Zeit für alle Daten gleich (und sehr kurz) sein muss; dann ist die Archivierung auf den G-Tier nicht sinnvoll, da sie das RTO erhöht.

Ausblick: Moderne Backup-Lösungen (wie Veeam oder Rubrik) implementieren die GFS-Logik oft unter der Haube und abstrahieren die Skripting-Komplexität, bieten aber weiterhin die Flexibilität, die physischen Targets (Tape, Cloud) für S, F und G zu definieren. Die Grundprinzipien bleiben jedoch unverändert.

# Anhang: Cheatsheet (Logik & Management)

# Referenzen

• NIST Special Publication 800-88 Rev. 1: Guidelines for Media Sanitization (Relevant für die Löschung abgelaufener S/F-Daten).
• ISO/IEC 27001: Informationssicherheits-Managementsysteme (Relevant für Audit-Trails und Immutability).
• Upstream Documentation: (Je nach verwendetem Tool: Bacula/BareOS Retention Guide, CommVault Retention Policies, etc.)