---
title: "BackupPC: Zentralisiertes, Deduplizierendes Enterprise Backup"
articleId: 042
tags: ["backup", "deduplication", "rsync", "disaster-recovery", "deep-dive"]
summary: "Dieser Artikel bietet einen tiefen Einblick in die Architektur und den operativen Betrieb von BackupPC. Wir untersuchen, wie das System Deduplizierung über Hard Links auf Dateisystemebene realisiert, und stellen Best Practices für Performance-Tuning und Recovery in großen Umgebungen vor."
status: published
author: "SysAdmin Team"
---

# BackupPC – Zentralisiertes Dateisystem-Backup mit Hard-Link-Deduplizierung

> **TL;DR / Management Summary**
> BackupPC ist ein ausgereiftes, Pull-basiertes Backup-System, das sich durch extrem effiziente Speicherung auszeichnet. Es nutzt Hard Links, um identische Dateien über alle Backups und Hosts hinweg nur einmal physisch auf der Platte abzulegen (Deduplizierung). Dies reduziert den Speicherbedarf drastisch. Setzen Sie BackupPC primär für große, homogene Umgebungen (viele App- oder Web-Server mit ähnlichen Binaries/Konfigurationen) ein, in denen Bandbreite und Plattenplatz entscheidend sind. Der Hauptvorteil liegt im minimalen Overhead auf den Clients und der hohen Speicherplatzeinsparung. Beachten Sie, dass der Performance-Flaschenhals die Metadaten-I/O des Backup-Servers ist.

---

## 1. Einführung & Architektur

BackupPC wurde entwickelt, um die Ineffizienz herkömmlicher inkrementeller Backups zu überwinden, bei denen eine volle Kopie pro Backup-Zyklus (oder gar pro Host) gespeichert wird.

### Warum brauchen wir das?

**Problemstellung aus der Praxis:** In einer Enterprise-Umgebung mit 200 Webservern, die alle auf der gleichen RHEL/Debian-Basis laufen und dieselben 5 GB an Systembibliotheken, Kerneln und App-Containern nutzen, werden 1 TB an redundantem Datenmüll erzeugt, wenn jeder Server individuell gesichert wird.

*   **Vergleich mit Alternativen:**
    *   **Standard-Partitioning + Tar/Rsync:** Hoher Speicherbedarf, langsame Restores.
    *   **ZFS/Btrfs Send/Receive:** Effizient, aber dezentral (Client muss Snapshots managen) und Block-basiert.
    *   **BackupPC:** Zentralisiert, File-basiert (ideal für heterogene OS-Mixes), Deduplizierung auf Anwendungsebene ohne spezielle Dateisysteme auf dem Client.

### Deep Dive: Hard Link Deduplizierung

Der architektonische Kern von BackupPC ist die Deduplizierung durch Hard Links.

1.  **Speicherstruktur:** Alle Backups werden in einem zentralen `$Conf{TopDir}` gespeichert. Die Daten liegen in einem Pool-Verzeichnis, getrennt nach Hosts und Backup-Nummern.
2.  **Backup-Vorgang (Inkementell/Full):** Wenn ein Client gesichert wird (via rsync über SSH), wird jede Datei geprüft:
    *   Ist die Datei identisch (Größe, Checksumme/MD5) zu einer bereits im Pool vorhandenen Datei?
    *   **Ja (Hit):** Statt die Datei erneut auf die Platte zu schreiben, erstellt BackupPC einen *Hard Link* von der Host-spezifischen Backup-Struktur zur vorhandenen physischen Datei im Pool.
    *   **Nein (Miss):** Die Datei wird in den Pool geschrieben, und ein Hard Link wird zur Host-Struktur erstellt.
3.  **Vorteil:** Die physische Speicherung ist unabhängig von der Anzahl der logischen Backups. Selbst ein **Full Backup** nach einer Woche dauert nur wenig länger als ein Inkrementelles, da nur die geänderten Dateien tatsächlich übertragen und gespeichert werden müssen.

### Architektur-Diagramm

BackupPC operiert typischerweise als Perl-CGI-Anwendung, die im Hintergrund `rsync` Prozesse steuert.

```mermaid
graph TD
    subgraph Client 1 (Web Server)
        A[sshd / rsync]
    end
    subgraph Client N (DB Server)
        B[sshd / rsync]
    end

    subgraph BackupPC Server (TopDir: /mnt/backuppc)
        D((Scheduler/Cron))
        E(Perl Backend / Rsync Controller)
        F[CGI Web Interface]
        G[Storage Pool ($TopDir/cpool)]
        H[Host Metadata ($TopDir/pc/hostN)]
    end

    D -- start job --> E
    E -- Pull via SSH --> A
    E -- Pull via SSH --> B
    E -- Write/Link Data --> G
    E -- Update Pointers --> H
    F -- read Status --> H

Kernel-Sicht (Device Mapper, Block Layer): BackupPC arbeitet oberhalb der Dateisysteme (FS-Level). Die Performance hängt direkt von der Effizienz des verwendeten Filesystems ab, insbesondere bei der Verwaltung großer Verzeichnisse mit Millionen von Hard Links (Metadata I/O). Das bedeutet, wir verlassen uns auf das VFS (Virtual Filesystem Switch) und das gewählte Dateisystem (z.B. XFS, siehe Abschnitt 3).

# 2. Installation & Grundkonfiguration (Praxis)

Wir richten BackupPC auf einem dedizierten Backup-Server ein, der über ausreichend I/O-Kapazität verfügt.

# Voraussetzungen

1. OS: Linux (Debian/RHEL/Ubuntu).
2. Pakete: backuppc, rsync, perl-modules (insbesondere Time::ParseDate, CGI).
3. Webserver: Apache oder Nginx (mit CGI/FastCGI-Support für die BackupPC_Admin CGI-Skripte).
4. Speicher-FS: XFS oder Btrfs (DRINGEND empfohlen). EXT4 hat Limits bei der Skalierung von Verzeichnis-I/O mit sehr vielen Dateien/Links.
5. Benutzer: Der Systembenutzer backuppc muss erstellt sein.

# Schritt-für-Schritt Setup (Der “Happy Path”)

Dieser Pfad geht davon aus, dass wir den Secure Shell (rsync over ssh) Transport nutzen, da er robuster und performanter ist als Samba/rsyncd.

# 2.1 Server: SSH-Key-Generierung

Der BackupPC-User benötigt einen SSH-Key, der ohne Passphrase erstellt wurde.

# 1. Sicherstellen, dass wir als backuppc arbeiten können
sudo su - backuppc

# 2. Key generieren (4096 Bit, kein Passwort)
# Wir nutzen einen spezifischen Dateinamen, um den Key bei Bedarf in die Konfiguration einzubinden.
ssh-keygen -t rsa -b 4096 -f /var/lib/backuppc/.ssh/id_rsa_backuppc_pull -N ""

# 3. Öffentlichen Key kopieren (z.B. nach /tmp/)
cp /var/lib/backuppc/.ssh/id_rsa_backuppc_pull.pub /tmp/

# 2.2 Client: Key-Installation und Hardening

Auf jedem Client muss der öffentliche Schlüssel in die authorized_keys des Root-Users (oder des Backups-Users) platziert werden.

# Auf dem Client (als root oder backup-user)
mkdir -p ~/.ssh
cat /path/to/id_rsa_backuppc_pull.pub >> ~/.ssh/authorized_keys

# Wichtig: Beschränkung des Kommandos (Hardening)
# Fügen Sie in die authorized_keys ZWEI Parameter vor dem Key ein:
# command="/usr/bin/rsync --server --sender -vlogDtprze.iLsf . /",no-pty,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3Nz... backuppc@server

# Erklärung: Dadurch kann der backuppc-User nur rsync ausführen.
# Alles andere (interaktive Shell, Port-Forwarding) wird blockiert.

# 2.3 Konfiguration des Hosts (/etc/backuppc/pc/client.pl)

Wir nutzen die Client-spezifische Konfiguration (im Verzeichnis pc/) und definieren den Transport.

# /etc/backuppc/pc/web01.example.com.pl

# Hostname muss der des Clients entsprechen
$Conf{RsyncShareName}    = ['/', '/etc', '/var/www'];
$Conf{XferMethod}        = 'rsync';

# Wir nutzen SSH (Standard: Port 22)
$Conf{RsyncArgs}         = [
    '--numeric-ids',        # IDs beibehalten (wichtig bei NFS/LDAP-Umgebungen)
    '-a',                   # Archivmodus (rekursiv, Permissions, Zeiten, Symlinks)
    '--delete-excluded',    # Dateien, die jetzt ausgeschlossen sind, im Backup löschen
    '--exclude-from=/etc/backuppc/exclude_global.txt', # Globale Exclusions
    '--ignore-errors'       # Weiterarbeiten bei Lesefehlern (produktionskritisch)
];

# WICHTIG: Pfad zum privaten Key, wenn nicht der Standard genutzt wird
$Conf{RsyncSshArgs}      = '-e ' .
    "'ssh -i /var/lib/backuppc/.ssh/id_rsa_backuppc_pull -T -x -oStrictHostKeyChecking=no'";

# Zeitplan
$Conf{FullPeriod}        = 7;      # Alle 7 Tage ein 'logisches' Full Backup
$Conf{IncrPeriod}        = 1;      # Tägliches Inkrementelles
$Conf{FullKeepCnt}       = 4;      # 4 volle Backups aufbewahren
$Conf{IncrKeepCnt}       = 10;     # 10 inkrementelle Backups pro Full-Zyklus

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning

Die Deduplizierung durch Hard Links ist extrem CPU- und I/O-intensiv auf der Metadaten-Ebene.

# 3.1 Filesystem-Optimierung

Ich empfehle XFS für den $Conf{TopDir} aufgrund seiner hervorragenden Skalierbarkeit für große Verzeichnisse und seiner Performance bei Metadaten-Operationen (Lookups).

• Mount-Optionen (XFS):

  # /etc/fstab Eintrag für die Backup-Platte
  UUID=... /mnt/backuppc xfs defaults,noatime,logbufs=8,logbsize=256k 0 0
  

  • noatime: Reduziert unnötige Schreibvorgänge.
  • logbufs/logbsize: Erhöhen die Größe des XFS-Journals im Speicher, um die Geschwindigkeit von Metadata-Updates zu verbessern.

# 3.2 I/O Scheduler

Bei SSDs/NVMe-Arrays sollte der I/O Scheduler auf none (oder noop) gesetzt werden. Bei klassischen Spindeln (JBOD) kann deadline oder cfq vorteilhaft sein, aber oft bringt noop die beste Konsistenz, da der Scheduler des Array-Controllers oder der SSD selbst meist effizienter ist.

# 3.3 BackupPC Interne Limits

• $Conf{MaxBackupPCJobs}: Legen Sie diesen Wert niemals höher als die Anzahl der physischen Cores Ihres Servers plus 1 fest, es sei denn, Sie haben reines NVMe Storage. Zu viele parallele I/O-Anfragen führen zu massivem Thrashing auf der Festplatte. Für Spinning Disk Arrays: Max 4-6 Jobs.
• $Conf{MaxBackupPCNightlyJobs}: Dieser Wert steuert die CPU-intensive BackupPC_nightly Wartung (Pooling, Cleanup). Halten Sie ihn niedrig (typ. 1) und stellen Sie sicher, dass er außerhalb der Peak-Backup-Zeit läuft.

# Hardening & Security

# 3.4 Web-Interface (CGI) Absicherung

BackupPC wird oft unsicher ausgeliefert (z.B. mit Standard-HTTP-Auth).

1. Transport Layer Security: Das Web-Interface muss zwingend über HTTPS erreichbar sein.
2. Authentifizierung: Nutzen Sie Apache/Nginx native Basic Auth oder LDAP/SSO, um den Zugriff zu schützen. Deaktivieren Sie die BackupPC-eigene Benutzerverwaltung, wenn möglich.
3. SELinux/AppArmor: Stellen Sie sicher, dass der Webserver (z.B. www-data) nur Lesezugriff auf die CGI-Skripte und die BackupPC-Logs hat, aber keinen direkten Schreibzugriff auf den $TopDir. Der Schreibzugriff ist dem backuppc User vorbehalten.

# 3.5 Client-seitige Rechte (SSH Hardening)

Wie in Abschnitt 2.2 beschrieben, muss die authorized_keys Datei auf dem Client restriktiv sein.

# Beispiel für EINE Zeile in authorized_keys auf dem Client
command="/usr/bin/rsync --server --sender -vlogDtprze.iLsf . /",no-pty,no-X11-forwarding,from="192.168.1.100" ssh-rsa ...

Der Zusatz from="<BackupPC-IP>" stellt sicher, dass der Key nur von der bekannten Backup-Server-IP verwendet werden kann.

# 4. Day-2 Operations: Wartung & Alltag

Nachdem das System in Betrieb ist, liegt die Herausforderung in der Wartung des riesigen Hard-Link-Pools.

# Typische Tasks

# 4.1 Pool-Wartung (Nightly Cleanup)

Der BackupPC_nightly Job ist kritisch. Er löscht alte Backups, leert den “Trash” (temporär gelöschte Dateien) und rekalibriert die Hard-Link-Referenzen. Ist dies nicht effizient, sammeln sich nicht referenzierte, aber physisch existierende Dateien an.

• Controlling Storage:
  • $Conf{MaxCacheSize}: Definiert, wie groß das “Trash”-Verzeichnis werden darf. Wenn dieser Wert erreicht ist, beginnt BackupPC, die ältesten nicht mehr referenzierten Dateien zu löschen. Achtung: Setzen Sie diesen Wert nicht zu niedrig, da der Garbage Collection Prozess selbst I/O-intensiv ist.

# 4.2 Vergrößern/Verkleinern (Datenträger-Migration)

Da der $TopDir oft die größte Platte ist, wird eine Migration auf eine größere Platte früher oder später nötig.

Gefahr: Ein einfacher cp -r oder tar zerstört die Hard Links, da das Dateisystem die Links nicht korrekt neu erstellt. Das Ergebnis ist eine Vervielfachung des Speicherbedarfs.

Korrekte Migration: Nutzen Sie rsync mit den Optionen, die Hard Links und Extended Attributes erhalten.

# Annahme: /mnt/backuppc (alt) -> /mnt/backuppc_new (neu)

# Wichtig: -a (archive), -H (hard-links), -X (extended attributes), -A (ACLs)
rsync -aHAXxv /mnt/backuppc/ /mnt/backuppc_new/

Nach der Migration muss die neue Platte gemountet und der backuppc Dienst neu gestartet werden.

# 4.3 Wiederherstellung eines Hosts

Die Wiederherstellung erfolgt am besten über das Web-Interface (BackupPC_Admin). Bei einem DR-Fall (Disaster Recovery), bei dem der Client-Host nicht mehr existiert, ist die Nutzung des Kommandozeilen-Tools BackupPC_restore erforderlich.

# Wiederherstellung des gesamten /etc Verzeichnisses von Host 'web01'
# Backup-Nummer 0 ist das aktuellste Full Backup
/usr/share/backuppc/bin/BackupPC_restore web01 0 /etc/ /tmp/web01_etc_restore

# Automatisierung (Ansible)

Für das Einrichten neuer Hosts nutzen wir Ansible. Da BackupPC Konfigurationen in Perl-Dateien speichert, muss entweder das ini_file Modul oder das lineinfile Modul verwendet werden, um die Konfigurationsdateien sauber zu modifizieren.

# Ansible Playbook Snippet: Neuen Host 'db01' hinzufügen
- name: Add new client host configuration
  hosts: backuppc_server
  vars:
    new_client_hostname: db01.example.com
    config_dir: /etc/backuppc/pc

  tasks:
    - name: Ensure client config file exists
      ansible.builtin.template:
        src: templates/host_config.pl.j2
        dest: "{{ config_dir }}/{{ new_client_hostname }}.pl"
        owner: backuppc
        group: backuppc
        mode: '0640'

    - name: Restart backuppc service to load new config
      ansible.builtin.service:
        name: backuppc
        state: restarted

# 5. Troubleshooting & “War Stories”

Die größten Probleme entstehen durch I/O-Latenz und Inkonsistenzen im Hard-Link-Metadatenpool.

# Top 3 Fehlerbilder

# 1. Symptom A: Backup läuft in Timeout (Xfer PING failed)

• Fehlermeldung: Xfer PING failed: 1 oder Got fatal error during xfer (Backup aborted by signal=PIPE)
• Ursache: Häufigste Ursachen sind:
  1. Netzwerkunterbrechung.
  2. Der Rsync-Prozess auf dem Client wurde beendet (z.B. durch OOM-Killer).
  3. Das SSH-Kommando auf dem Client hat keine Shell/TTY, was zu Problemen führt.
• Lösung:
  • Überprüfen Sie die Client-Logs (/var/log/auth.log) auf SSH-Fehler.
  • Stellen Sie sicher, dass in der BackupPC-Konfiguration der rsync Pfad korrekt ist ($Conf{RsyncClientPath}).
  • Für große/langsame Backups: Erhöhen Sie den ssh Timeout im $Conf{RsyncSshArgs}: -oServerAliveInterval=60 -oServerAliveCountMax=3.

# 2. Symptom B: Performance-Einbruch und langsame “Inkrementelle” Backups

• Symptom: Inkrementelle Backups dauern plötzlich so lange wie Full Backups. Die CPU-Last ist auf dem Backup-Server hoch.
• Ursache: Der Festplatten-I/O ist gesättigt. Während der Deduplizierung müssen Millionen von Hard Links und Metadaten-Einträgen gelesen und geschrieben werden. Random I/O ist der Engpass.
• Analyse: Nutzen Sie iostat -x 5 auf dem Backup-Server. Suchen Sie nach hohem await (Wartezeit) und hohem util (Auslastung).
• Lösung:
  • Reduzieren Sie $Conf{MaxBackupPCJobs} (siehe 3.3).
  • Migrieren Sie auf schnelleres Storage (SSD/NVMe).
  • Prüfen Sie, ob das Dateisystem (XFS) mit optimalen Optionen gemountet ist (siehe 3.1).

# 3. Symptom C: Speicherplatz wird nicht freigegeben

• Symptom: Alte Backups werden gelöscht, aber die Plattennutzung sinkt nicht proportional.
• Ursache: Die BackupPC_nightly Routine wurde nicht erfolgreich abgeschlossen, oder die Hard-Link-Referenzen sind inkonsistent. Die Dateien liegen im trash Verzeichnis, aber das Cleanup (Garbage Collection) hat versagt.
• Lösung: Führen Sie die Wartung manuell aus: sudo -u backuppc /usr/share/backuppc/bin/BackupPC_nightly. Wenn das nicht hilft, müssen Sie die Konsistenz des Hard-Link-Pools prüfen. Wenn alles versagt, muss das $Conf{MaxCacheSize} Limit erhöht werden, um den Garbage Collector Zeit zu geben, oder das trash Verzeichnis manuell bereinigt werden (Äußerste Vorsicht!).

# Recovery Szenarien

# Recovery Diagramm (Critical Failures)

graph TD
    A[Hard Drive Failure/Corruption on TopDir] --> B{Metadata or Pool Corrupted?};
    B -- Metadata (H) --> C[Run BackupPC_dumpHistory.pl];
    C --> D[Restore config/metadata files from external backup];
    D --> E[Try to restart BackupPC];

    B -- Pool (G) --> F[Run fsck/xfs_repair on Storage FS];
    F --> G[If successful, try to run BackupPC_check for consistency];
    G -- Failed --> H[Treat as catastrophic loss of all old backups];
    H --> I[IMMEDIATELY start new Full Backups for ALL clients];
    I --> J[Accept loss of historic data, focus on RTO/RPO];

Anekdote (“War Story”): Metadata Corruption Wir hatten einmal einen Stromausfall in einem Rechenzentrum. Obwohl das XFS-Journal die meisten Daten rettete, waren einige Metadaten (speziell die config.pl Dateien einiger Hosts) korrupt. Das führte dazu, dass BackupPC beim Start nicht mehr wusste, welche Backups zu welchem Host gehörten. Die Lösung bestand darin, die kritische Konfiguration (/etc/backuppc) aus dem letzten externen Backup (das System-Backup des Backup-Servers selbst!) wiederherzustellen, bevor wir versuchten, BackupPC_check auszuführen. Vertrauen Sie niemals einem Backup-System, das sich selbst nicht redundant sichert.

# 6. Monitoring & Alerting

Der Schlüssel beim Monitoring von BackupPC liegt in der Beobachtung der I/O-Metriken und der Speicherplatz-Verwaltung, nicht nur der Backup-Erfolge.

# Metriken

# 6.1 I/O KPIs (vom Backup-Server)

• Disk Utilization (util%): Muss unter 80% bleiben, besonders während der BackupPC_nightly Läufe.
• I/O Wait Time (iowait): Hohe Werte (>5%) deuten auf den Engpass hin.
• Metadata Usage: Wie viele Inodes sind auf dem Storage-FS belegt? (Kann kritisch werden, wenn Millionen von Hard Links existieren).

# 6.2 BackupPC Interne Metriken

Die wichtigsten Informationen sind in der Datei $TopDir/log/hosts und im Summary-Log.

• $Conf{DataPoolUsed}: Physisch genutzter Speicherplatz.
• $Conf{TotalFiles}: Gesamtanzahl der logisch gesicherten Dateien.
• Deduplication Ratio: (Logischer Speicher / Physischer Speicher). Sollte immer über 5:1 liegen, ansonsten prüfen, ob die Hard Links korrekt funktionieren.

# Alerting-Regeln

# 7. Fazit & Empfehlung

BackupPC bleibt eine hervorragende Wahl für spezifische Backup-Anwendungsfälle, insbesondere im FOSS-Bereich.

Empfehlung:

Ich empfehle BackupPC stark für Umgebungen, in denen die Effizienz der Dateispeicherumgebung maximiert werden muss. Es ist ideal für 10 bis 300 homogene Clients, da hier die Deduplizierung den größten Mehrwert bringt. Die zentrale Verwaltung über das Web-Interface ist einfach und robust.

Wann würde ich es NICHT einsetzen?

1. Massive Skalierung (> 500+ Clients): Der Performance-Engpass der Metadatenverwaltung (Hard Links auf Dateisystemebene) wird irgendwann unüberwindbar. Hier sind verteilte, datenbankbasierte Systeme (z.B. Block-Storage Solutions oder moderne FOSS-Tools wie Borg) besser geeignet.
2. VM-Image Backups: BackupPC ist Datei-basiert. Für komplette VM-Images sind blockbasierte Lösungen wie Veeam oder ZFS/Proxmox Backup Server effizienter.
3. Sehr heterogene Umgebungen: Wenn Hosts kaum Datei-Überlappung haben, bringt die Hard-Link-Deduplizierung wenig, und der Mehraufwand für die Metadatenverwaltung lohnt sich nicht.

Ausblick: Neuere Versionen von BackupPC (v6+) konzentrieren sich darauf, die flache Datei-basierte Konfiguration durch Datenbank-Backends zu ersetzen, um die Metadaten-Performance und Skalierbarkeit zu verbessern. Dies sollte die “500-Clients-Grenze” in Zukunft erweitern.

# Anhang: Cheatsheet

# Referenzen

• BackupPC Offizielle Dokumentation
• Rsync Manpage (insb. Optionen -a, -H)
• XFS Filesystem Administration Guide
• Perl CGI Security Best Practices