Wissensdatenbank

Die Frage, die niemand stellt — bis es zu spät ist

Festplatten fallen aus. Ransomware verschlüsselt. Mitarbeiter löschen. Datenbanken werden korrupt. Cloud-Anbieter haben Ausfälle. All diese Ereignisse haben eines gemeinsam: Ohne Backup sind die Daten weg.

Die Frage ist nicht ob du ein Backup brauchst. Sondern wann.

Wovor Backups schützen

Die Kosten ohne Backup

Überlege, was deine Daten wert sind:

• Finanzdaten — Jahre an Buchhaltung, Rechnungen, Steuerdokumenten
• Kundendaten — CRM, Verträge, Kommunikationshistorie
• Geistiges Eigentum — Quellcode, Designs, Dokumentation
• Betriebsdaten — Konfigurationen, Automatisierungsskripte, Infrastrukturzustand

Irgendetwas davon von Grund auf neu aufzubauen kostet mehr als jede Backup-Lösung. Für viele Unternehmen bedeutet der Verlust kritischer Daten: Türen schließen.

Was ein gutes Backup ausmacht

Ein Backup ist nur nützlich, wenn es wiederhergestellt werden kann. Grundprinzipien:

1. Regelmäßig — Backups laufen nach Zeitplan, nicht “wenn jemand dran denkt”
2. Getestet — Restore-Tests beweisen, dass das Backup tatsächlich funktioniert
3. Offsite — mindestens eine Kopie wird außerhalb des Primärstandorts aufbewahrt
4. Überwacht — fehlgeschlagene Backups werden sofort erkannt, nicht Wochen später
5. Dokumentiert — der Restore-Prozess ist bekannt, bevor der Notfall eintritt

Wo Bareos reinpasst

Bareos ist eine Open-Source-Backup-Lösung, die all das handhabt — Zeitplanung, Überwachung, Offsite-Kopien, Restore-Tests. Sie ist praxiserprobt in Produktionsumgebungen von kleinen Büros bis zu großen Unternehmen.

Onesimus gibt Bareos eine moderne visuelle Oberfläche. Statt bconsole-Befehle auswendig zu lernen, verwaltest du deine gesamte Backup-Infrastruktur über eine native Desktop-Anwendung.

Die 3-2-1-Backup-Regel lernen →

Die einfachste Regel, die Unternehmen rettet

Die 3-2-1-Regel ist die am weitesten akzeptierte Backup-Strategie. Sie ist einfach, effektiv und technologieunabhängig:

• 3 Kopien deiner Daten
• 2 verschiedene Speichermedien
• 1 Kopie offsite

Warum drei Kopien?

Eine Kopie ist keine Kopie. Wenn dein einziges Backup auf demselben Server wie deine Daten liegt, zerstört ein einzelnes Ereignis (Brand, Ransomware, Hardware-Ausfall) beides.

Zwei Kopien sind besser, aber immer noch riskant. Wenn beide Kopien auf demselben Medientyp liegen (z.B. zwei Festplatten), könnte ein Herstellungsfehler oder Firmware-Bug beide betreffen.

Drei Kopien machen gleichzeitigen Verlust statistisch unwahrscheinlich. Du bräuchtest drei unabhängige Ausfälle zur gleichen Zeit.

Warum zwei Medientypen?

Verschiedene Speichertechnologien versagen unterschiedlich:

Zwei verschiedene Medientypen zu verwenden bedeutet, dass ein einzelner Fehlermodus nicht alle Kopien auslöschen kann. Gängige Kombinationen:

• Disk + Band — der klassische Enterprise-Ansatz
• Disk + Cloud — moderne Hybrid-Strategie
• NAS + Externe Platte — Ansatz für kleine Unternehmen

Warum eine Offsite-Kopie?

Lokale Katastrophen kümmern sich nicht um deine Backup-Strategie. Brand, Hochwasser, Diebstahl oder ein Stromstoß können alles an einem Standort zerstören. Eine Kopie muss physisch getrennt sein:

• Remote-Rechenzentrum — ein anderes Gebäude, eine andere Stadt
• Cloud-Storage — geographisch verteilt by Design
• Band-Einlagerung — physische Bänder offsite aufbewahrt

Die 3-2-1-Regel mit Bareos

Bareos unterstützt all diese Szenarien nativ:

• Mehrere Pools für verschiedene Kopienstufen (Primär, Kopie, Archiv)
• Copy-Jobs, die Backups auf einen zweiten Storage duplizieren
• Cloud-Storage-Integration für Offsite-Kopien
• Band-Unterstützung für Air-Gapped-Backups

Onesimus wird dies in der Pro-Edition visualisieren — alle Kopien, Pools und Storage-Standorte in einer Ansicht. Community ermöglicht schon jetzt die Verwaltung der Jobs und Zeitpläne, die 3-2-1 umsetzen.

Über 3-2-1 hinaus: Die 3-2-1-1-0-Regel

Moderne Best Practices erweitern die Regel:

• 3-2-1 plus 1 Air-Gapped oder unveränderliche Kopie
• 0 Fehler — jedes Backup mit automatisierten Restore-Tests verifizieren

Die extra “1” schützt gegen Ransomware, die gezielt Backup-Systeme angreift. Ein Air-Gapped-Band oder ein unveränderlicher Cloud-Snapshot kann nicht von Malware verschlüsselt werden.

Backup-Level kennenlernen: Full, Incremental, Differential →

Nicht alle Backups sind gleich

Jedes Mal alles zu sichern ist sicher, aber verschwenderisch. Nur Änderungen zu sichern ist effizient, aber komplex. Die richtige Strategie kombiniert beides — und Backup-Level zu verstehen ist der Schlüssel.

Full Backup

Ein Full-Backup kopiert jede Datei, unabhängig davon, ob sie sich geändert hat.

Einsatz: Wöchentliche oder monatliche Basis-Backups, kritische Systeme, Compliance-Anforderungen.

Incremental Backup

Ein Incremental-Backup kopiert nur Dateien, die sich seit dem letzten Backup beliebigen Levels geändert haben.

Einsatz: Nächtliche Backups zwischen Fulls, Umgebungen mit hohen Änderungsraten.

Beispielkette:

Mo: Full (100 GB)
Di: Incremental (2 GB) — Änderungen seit Mo
Mi: Incremental (3 GB) — Änderungen seit Di
Do: Incremental (1 GB) — Änderungen seit Mi

Wiederherstellung Donnerstag braucht: Full + Di-Inc + Mi-Inc + Do-Inc.

Differential Backup

Ein Differential-Backup kopiert alle Dateien, die sich seit dem letzten Full-Backup geändert haben.

Einsatz: Umgebungen, in denen Restore-Geschwindigkeit wichtiger ist als Storage-Effizienz.

Beispielkette:

Mo: Full (100 GB)
Di: Differential (2 GB)  — Änderungen seit Mo
Mi: Differential (5 GB)  — Änderungen seit Mo (kumulativ)
Do: Differential (6 GB)  — Änderungen seit Mo (kumulativ)

Wiederherstellung Donnerstag braucht: Full + Do-Diff.

VirtualFull Backup

Ein VirtualFull ist ein synthetisches Full-Backup, das aus bestehenden Backups konstruiert wird, ohne vom Client zu lesen. Bareos erstellt es, indem das letzte Full mit allen nachfolgenden Incrementals auf der Storage-Seite kombiniert wird.

Einsatz: Client- und Netzwerklast während Full-Backup-Fenster reduzieren.

Welche Strategie solltest du verwenden?

Kleine Umgebungen (< 10 Clients)

Wöchentlich Full + Täglich Incremental

Einfach, geringer Storage-Overhead, akzeptable Restore-Zeiten.

Mittlere Umgebungen (10-100 Clients)

Monatlich Full + Wöchentlich Differential + Täglich Incremental

Balance zwischen Storage, Backup-Fenster und Restore-Geschwindigkeit.

Große Umgebungen (100+ Clients)

Monatlich VirtualFull + Täglich Incremental

Minimaler Client-Einfluss, synthetische Fulls halten Restore-Ketten kurz.

Wie Onesimus hilft

Onesimus zeigt deine Zeitpläne visuell — farbkodiert nach Backup-Level. Die Gantt-Timeline macht offensichtlich, wann Fulls laufen, wie Incrementals die Lücken füllen und wo deine Backup-Fenster sind.

Die Zeitplan-Visualisierung ist in Community verfügbar. Zu verstehen, welche Level wie viel Storage verbrauchen, wird Teil von Onesimus Pro.

Retention verstehen und wie sie Storage beeinflusst →

Was ist Retention?

Retention definiert, wie lange ein Backup aufbewahrt wird, bevor es überschrieben oder gelöscht werden kann. Sie ist die Brücke zwischen “wir haben genug Storage” und “wir können die Daten vom letzten Monat noch wiederherstellen.”

In Bareos wird Retention pro Pool gesetzt und gilt für Volumes. Wenn die Retention eines Volumes abläuft, wird es für Recycling freigegeben — sein Speicherplatz kann für neue Backups wiederverwendet werden.

Warum Retention wichtig ist

Zu kurz = keine Recovery Points, wenn man sie braucht. Zu lang = Storage füllt sich schneller als erwartet.

Die meisten regulatorischen Umgebungen verlangen 30-90 Tage. Manche Branchen verlangen Jahre.

Wie Retention in Bareos funktioniert

Bareos verfolgt drei Arten von Retention:

File Retention

Wie lange einzelne Dateieinträge im Katalog gehalten werden. Nach Ablauf kann man nicht mehr einzelne Dateien im Backup durchsuchen — aber die Backup-Daten selbst sind noch auf dem Volume.

Job Retention

Wie lange Job-Datensätze im Katalog gehalten werden. Nach Ablauf verschwinden die Job-Metadaten aus dem Katalog, aber die Volume-Daten existieren möglicherweise noch.

Volume Retention

Wie lange ein Volume aufbewahrt wird, bevor es recycelt werden kann. Das ist die entscheidende Retention für Storage — wenn die Volume Retention abläuft, kann Bareos den Platz wiederverwenden.

Die Beziehung:

File Retention <= Job Retention <= Volume Retention

Dateieinträge verfallen zuerst, dann Job-Datensätze, dann das Volume selbst.

Die richtige Retention wählen

Beginne mit der Frage: “Was sind die ältesten Daten, die ich wiederherstellen müsste?”

Dann Storage berücksichtigen:

Längere Retention = mehr Storage. Die Beziehung ist nicht linear — sie hängt von Backup-Levels und Änderungsraten ab:

• Full + Täglich Incremental, 30 Tage Retention: ~5x die Datengröße
• Full + Täglich Incremental, 90 Tage Retention: ~12x die Datengröße
• Monatlich Full + Täglich Incremental, 365 Tage Retention: ~15x die Datengröße

Das sind grobe Schätzungen. Deine tatsächlichen Zahlen hängen von Änderungsraten, Komprimierung und Deduplizierung ab.

Die Retention-Falle

Der häufigste Fehler: Retention setzen, ohne die Storage-Auswirkung zu verstehen. Ein Admin ändert Retention von 30 auf 90 Tage — und drei Monate später ist der Pool voll.

Das ist genau Frage 4 der 5 Fragen, die jeder Backup-Admin stellt: “Was passiert, wenn ich die Retention ändere?” Die Möglichkeit, Retention-Änderungen vor dem Anwenden zu simulieren, ist für Onesimus Enterprise geplant.

Retention vs. Recycling

Retention ist wann ein Volume für Wiederverwendung freigegeben wird. Recycling ist das tatsächliche Wiederverwenden. Ein Volume nach Retention wird nicht automatisch gelöscht — es bleibt, bis Bareos den Platz braucht.

Diese Unterscheidung ist wichtig: Du könntest Volumes haben, die über der Retention sind, aber noch nützliche Daten enthalten. Intelligente Recycling-Empfehlungen (geplant für Onesimus Pro) werden helfen zu identifizieren, welche Volumes wirklich sicher wiederverwendet werden können.

Pools und Volumes verstehen →

Die Storage-Hierarchie

Bareos organisiert Backup-Daten in drei Ebenen:

Storage Daemon
  └── Pool (logische Gruppierung)
       └── Volume (physische Speichereinheit)
            └── Job-Daten (Backup-Inhalt)

Diese Hierarchie zu verstehen ist essenziell für Storage-Kapazitätsmanagement — und es ist die Grundlage für alles, was Onesimus visualisiert.

Was ist ein Pool?

Ein Pool ist ein logischer Container, der Volumes mit demselben Zweck und denselben Richtlinien gruppiert. Stell ihn dir wie einen Aktenschrank mit einem bestimmten Etikett vor.

Gängige Pool-Konfigurationen:

Jeder Pool hat eigene Einstellungen für:

• Volume Retention — wie lange Daten aufbewahrt werden
• Maximale Volume-Größe — wie groß ein Volume werden kann
• Maximale Volumes — wie viele Volumes der Pool halten kann
• Recycle — ob abgelaufene Volumes wiederverwendet werden können
• Auto-Prune — ob Bareos automatisch abgelaufene Daten entfernt

Was ist ein Volume?

Ein Volume ist eine physische Speichereinheit — typischerweise eine Datei auf der Platte oder ein Band. Es enthält die tatsächlichen Backup-Daten von einem oder mehreren Jobs.

Volume-Status in Bareos:

Der Lebenszyklus: Append → Full → Used → Purged → Recycled → Append.

Warum Pools wichtig sind

Ohne Pools gehen alle Backups in einen großen Haufen. Mit Pools kannst du:

• Backup-Level trennen — Full-Backups auf große Volumes, Incrementals auf kleinere
• Verschiedene Retention pro Typ — Fulls 90 Tage behalten, Incrementals 14
• Verschiedene Storage-Ziele — Fulls auf Band, Incrementals auf Platte
• Kopieren und Migrieren — Daten zwischen Pools für Offsite oder Archivierung verschieben

Der Scratch-Pool

Der Scratch-Pool ist besonders. Er hält “leere” Volumes, die Bareos automatisch jedem Pool zuweisen kann, der Platz braucht. Wenn ein Pool ein neues Volume braucht und keins verfügbar ist, zieht Bareos eins aus Scratch.

Das ist nützlich, weil:

• Du Volumes nicht vorab bestimmten Pools zuweisen musst
• Storage on-demand genutzt wird
• Recycelte Volumes zu Scratch zurückkehren können, um überall wiederverwendet zu werden

Pool-Management in Onesimus

Pool-Management kommt in Onesimus v0.3.0 — visuelle Pool-Übersicht mit Volume-Status und Lebenszyklus-Tracking. Onesimus Pro wird Verbrauchsanalyse pro Job und Client, Wachstumstrends und Recycling-Empfehlungen ergänzen.

Die 5 Kernfragen, die jeder Backup-Admin stellt, drehen sich alle um das Verständnis von Pools und Volumes — wo Storage hingeht, wann er ausgeht und wie man ihn optimiert.

Zurück zur Wissensdatenbank →

Der Zeitplan ist das Rückgrat

Jeder Backup-Job braucht einen Zeitplan. Der Zeitplan bestimmt, wann der Job läuft, welches Backup-Level er verwendet (Full, Incremental, Differential) und wie oft. Stimmt der Zeitplan nicht, leidet alles Nachgelagerte — Jobs kollidieren, Backup-Fenster werden verpasst, Storage füllt sich unvorhersehbar.

In Bareos ist ein Schedule eine benannte Ressource mit einer oder mehreren Run-Direktiven. Jede Run-Direktive legt eine Uhrzeit, einen Tag und ein Backup-Level fest.

Anatomie eines Bareos-Zeitplans

Ein typischer Zeitplan sieht so aus:

Schedule {
  Name = "WeeklyCycle"
  Run = Full         1st sun at 02:00
  Run = Differential 2nd-5th sun at 02:00
  Run = Incremental  mon-sat at 21:00
}

Das bedeutet:

Ein einzelner Zeitplan kann mehreren Jobs zugewiesen werden. Das ist effizient, bedeutet aber auch, dass jeder Job mit WeeklyCycle zur exakt gleichen Zeit startet — was zum häufigsten Planungsfehler führt.

Das Kollisionsproblem

Wenn 10 Jobs denselben Zeitplan teilen und alle um 21:00 starten, treffen sie alle gleichzeitig auf den Storage Daemon. Das Ergebnis:

• Netzwerksättigung — alle Clients senden gleichzeitig Daten
• Disk-I/O-Engpass — der Storage Daemon schreibt alle Streams parallel
• Verlängerte Backup-Fenster — Jobs, die 30 Minuten dauern sollten, brauchen 3 Stunden
• Timeout-Fehler — Clients trennen die Verbindung, weil der SD nicht nachkommt

Die Lösung: Startzeiten staffeln

Statt eines Zeitplans für alles, erstelle mehrere Zeitpläne mit versetzten Startzeiten:

Schedule {
  Name = "Staffelung_Gruppe_A"
  Run = Incremental mon-sat at 20:00
}

Schedule {
  Name = "Staffelung_Gruppe_B"
  Run = Incremental mon-sat at 21:00
}

Schedule {
  Name = "Staffelung_Gruppe_C"
  Run = Incremental mon-sat at 22:00
}

Verteile deine Jobs auf diese Gruppen, damit nur wenige Clients gleichzeitig laufen.

Priorität und Reihenfolge

Bareos unterstützt eine Priority-Direktive pro Job. Niedrigere Zahlen laufen zuerst. Jobs mit gleicher Priorität laufen parallel; höhere Nummern warten.

Job {
  Name = "BackupDatabase"
  Schedule = "WeeklyCycle"
  Priority = 5          # läuft zuerst
}

Job {
  Name = "BackupFileserver"
  Schedule = "WeeklyCycle"
  Priority = 10         # wartet, bis Priorität 5 fertig ist
}

Das ist nützlich, wenn:

• Ein Datenbank-Dump fertig sein muss, bevor das Datei-Backup startet
• Ein kritischer Server die volle Bandbreite bekommen soll, bevor weniger wichtige Clients beginnen
• Du sequenzielle Ausführung willst, ohne separate Zeitpläne zu erstellen

Backup-Fenster

Ein Backup-Fenster ist der Zeitraum, der für Backups zur Verfügung steht — typischerweise nachts oder in nutzungsarmen Stunden. Wenn dein Backup-Fenster 20:00–06:00 ist, müssen alle Jobs innerhalb dieses Fensters fertig werden.

Schlüsselfaktoren, die das Backup-Fenster beeinflussen:

Das Fenster dimensionieren

Beginne damit, dein größtes Full-Backup zu messen, und rechne rückwärts:

Verfügbares Fenster:  10 Stunden (20:00–06:00)
Größtes Full:          4 Stunden
Verbleibend:           6 Stunden für alle anderen Jobs

Wenn die verbleibende Zeit nicht reicht, erwäge:

• Fulls am Wochenende laufen zu lassen, wenn das Fenster größer ist
• VirtualFull zu verwenden, um clientseitige Full-Backups ganz zu vermeiden
• Fulls auf verschiedene Tage zu verteilen (nicht alle am Sonntag)

Gängige Scheduling-Muster

Einfacher Wochenzyklus

Full:        Sonntag 02:00
Incremental: Montag–Samstag 21:00

Am besten für kleine Umgebungen mit wenigen Clients und genug Storage für wöchentliche Fulls.

Monatliches Full + wöchentliches Differential

Full:         1. Sonntag 02:00
Differential: 2.–5. Sonntag 02:00
Incremental:  Montag–Samstag 21:00

Reduziert die Full-Backup-Häufigkeit. Differentials halten die Restore-Ketten kurz.

Gestaffelte Multi-Gruppen

Gruppe A (Datenbanken):    20:00 täglich, Full Sonntag
Gruppe B (Fileserver):     21:30 täglich, Full Samstag
Gruppe C (Arbeitsplätze):  23:00 täglich, Full Freitag

Verteilt die Last über die Nacht. Jede Gruppe hat ihren eigenen Full-Tag, um Sonntags-Staus zu vermeiden.

Häufige Fehler

Wie Onesimus hilft

Scheduling ist genau der Bereich, in dem die Konsole an ihre Grenzen stößt. Eine Liste von Run-Direktiven zeigt nicht das große Bild. Onesimus bietet:

• Gantt-Timeline — alle Jobs über einen Tag oder eine Woche sehen, farbcodiert nach Level, mit geschätzten Laufzeiten
• Kollisionserkennung — überlappende Jobs werden automatisch markiert
• Job-zu-Schedule-Zuordnung — klicke auf einen Zeitplan und sieh, welche Jobs ihn nutzen
• Laufzeit-Statistiken — historische Min/Avg/Max pro Job und Level, damit du weißt, ob ein Job in sein Fenster passt

Die Schedule-Visualisierung ist in der Community-Edition verfügbar. Den Storage-Impact deines Zeitplans zu verstehen, wird Teil von Onesimus Pro sein.

Mehr über Backup-Levels → · Mehr über Retention →