AegisGrid sichert Dateien und Blockgeräte (Images, LVM-Volumes, Partitionen, ganze Platten) und stellt sie wieder her. Jede Sicherung landet als Run in einem deduplizierenden Store: Der Agent zerlegt die Quelle in Stücke (Chunks), deren Grenzen sich nach dem Inhalt richten, und speichert nur Chunks, die der Store noch nicht hat. Jeder Run ist für sich vollständig und einzeln wiederherstellbar. Die Daten werden mit zstd oder lz4 komprimiert, auf Wunsch beim Client verschlüsselt und per TLS an einen Backup-Server (bkp_target) übertragen.
Dieses Handbuch richtet sich an Administratoren: Sie richten Sicherungen, den Backup-Server und Restores ein und betreiben sie.
Wer Version 1 mit FULL-, DIFF- und INC-Sicherungen kennt, findet in Kapitel 27 („Umstieg für FULL/DIFF/INC-Kenner“) die Gegenüberstellung und eine Checkliste für das Update.
Alle Beispiele sind lauffähig; die abgedruckten Ausgaben stammen aus echten Testläufen. Wo ein Beispiel nur auf einem echten LVM-System, unter Windows oder mit einem Hypervisor funktioniert, steht das dabei.
1.1 Was AegisGrid kann#
- Deduplizierte Snapshots. Jede Sicherung ist ein vollständiger Zeitpunkt, gespeichert wird aber nur, was der Store noch nicht hat. Es gibt keine Ketten, kein DIFF und kein Zusammenführen. Dedupliziert wird über alles im Store, also auch zwischen Rechnern, die sich einen Store teilen.
- Inhaltsabhängige Chunks (FastCDC). Wird vorn in einer Quelle etwas eingefügt, verschieben sich die Grenzen danach nicht; die folgenden Chunks bleiben gleich und werden wiedererkannt.
- Vertraute Anzeige: Der erste Run eines Backup-Namens heißt Full, alle weiteren Incremental. Das ist nur eine Orientierung: wiederherstellen lässt sich jeder Run allein.
- Freie Bereiche werden übersprungen. Bei ext2/3/4 und NTFS liest der Agent nur belegten Platz. Nullbereiche werden als Löcher vermerkt, nicht gespeichert.
- Konsistente Sicherung laufender Systeme: LVM-Snapshots (Linux), VSS-Schattenkopien (Windows) und frei konfigurierbare Hooks.
- Dateien und Ordner: Statt ganzer Platten auch einzelne Pfade sichern, mit Rechten, ACLs und Ausschlüssen; zurück kommen einzelne Dateien, ganze Ordner, frühere Versionen oder ein ZIP-Archiv, und ein Lauf lässt sich als Ordner ansehen. Eine Ransomware-Warnung schützt die älteren Stände (Kapitel 9).
- Netzwerk-Backup: Der Agent streamt direkt an
bkp_target, vollständig TLS-verschlüsselt (das Server-Zertifikat wird gepinnt), Anmeldung über API-Keys, die an Verzeichnisse gebunden sind. Übertragen wird nur, was dem Store auf dem Server fehlt. - Verschlüsselung beim Client (AES-256-GCM oder ChaCha20-Poly1305, je Store): Der Server sieht weder Inhalte noch Schlüssel.
- Mehrere Ziele in einem Lauf (Sinks): bis zu 8 Stores lokal und auf Servern; die Quelle wird nur einmal gelesen.
- Parallel und schnell: Reader, Chunker und mehrere Worker (Hash und Kompression) arbeiten als Pipeline; SHA-256 nutzt SHA-NI/AVX2, wenn vorhanden; mit
--hash blake3sinkt die CPU-Last des Hashens deutlich. - Schutz der Daten: Aufbewahrung je Run, Scrub (Prüfen aller Daten), Reparatur aus einer zweiten Kopie, Teil-Restore beschädigter Sicherungen, Spiegeln ganzer Stores, auch in S3-Objektspeicher, Export einzelner Runs als Archiv (Band, USB) und WORM-Sperren.
- Signierte Updates:
bkp_updaterinstalliert Updates atomar, testet sie vorher und schaltet bei einem Fehler selbst zurück.
1.2 Die Programme#
| Programm | Aufgabe | Plattform |
|---|---|---|
bkp_agent | Sichert ein Blockgerät, eine Image-Datei oder Dateien und Ordner in einen oder mehrere Stores: lokal (--out), auf einen Server (--target) oder über benannte Sinks | Linux, Windows |
bkp_restore | Stellt einen Run auf eine Datei oder ein Blockgerät wieder her: aus einem lokalen Store, direkt vom Server, aus den Sinks eines Profils oder aus einem Archiv; aus Dateisicherungen einzelne Dateien und Ordner, auch als ZIP oder als Ordner zum Ansehen | Linux, Windows |
bkp_target | Backup-Server: empfängt Sicherungen per TLS in seine Stores, API-Key-ACL, optional eigener Scheduler | Linux |
bkp_maintenance | Aufbewahrung (prune, set-retention), Runs löschen, Scrub, Repair, Spiegeln, Export/Import, store-info; API-Keys, Zertifikate und Schlüssel erzeugen | Linux |
bkp_monitor | Live-Anzeige des Fortschritts laufender Agents und Restores (ncurses) | Linux |
bkp_dump | Zeigt einen Store, seine Runs und das Manifest eines Runs (Segmente, Chunks, Löcher) | Linux, Windows |
bkp_restore_legacy | Liest Sicherungen im alten FULL/DIFF/INC-Format von Version 1 (list, restore, prune, delete) | Linux, Windows |
bkp_sched | Job-Scheduler: startet Jobs zeitgesteuert, einmalig oder nach anderen Jobs; Mail-Benachrichtigung, HTTPS-API für conf-clients. Unter Windows als Dienst aegisgrid-sched, nur Sicherungen mit bkp_agent und Hyper-V | Linux, Windows |
bkp_console | Verwaltungskonsole: zeigt und steuert die Job-Planer (bkp_sched) eines oder mehrerer Rechner über deren HTTPS-API, mit Fenster | Windows |
bkp_target_console | Target-Konsole: verwaltet und beobachtet einen oder mehrere Backup-Server (bkp_target) über die Target-API, mit Fenster | Windows |
bkp_updater | Prüft einen HTTPS-Server auf signierte Updates und installiert sie | Linux, Windows |
bkp_sitesrv | Standortserver: gleicht die eigenen Targets und die für Konsolen freigegebenen Planer eines Kontos ab, gehostet bei AegisGrid, im eigenen Netz oder beim Partner (Kapitel „Standortserver“) | Linux, Windows |
bkp_license | Freischaltung der Installation mit Freischaltcode oder per Datei, Lizenzstatus, Erneuerung, Platz freigeben (Kapitel 23) | Linux, Windows |
bkp_setup | Installationsprogramm: lädt gewählte Komponenten vom Update-Server, installiert und richtet sie ein (Text-Assistent unter Linux, Fenster unter Windows, --silent) | Linux, Windows |
bkp_m365 | Sichert Microsoft 365 (Mails, Kalender, Kontakte, Aufgaben, OneDrive, SharePoint) eines Kontos oder Tenants | Linux |
bkp_m365_restore | Listet, durchsucht, exportiert M365-Sicherungen und schreibt sie zurück nach Microsoft 365 | Linux |
bkp_hyperV | Sichert eine Hyper-V-VM über einen Recovery-Checkpoint als einen VM-Run, nach der ersten Sicherung nur die Änderungen (RCT) | Windows |
bkp_hyperV_restore | Stellt einen VM-Run von bkp_hyperV als neue VM oder einzelne Disks als VHDX-Dateien wieder her | Windows |
Jedes Programm hat --help.
1.3 Grundbegriffe#
| Begriff | Bedeutung |
|---|---|
| Store | Verzeichnis <store>.cbs (Name mit --store, Standard default), in dem die Sicherungen liegen: unter dem --out-Verzeichnis oder auf dem Server unter <storage>/<verzeichnis>/. Dedupliziert wird über alles, was im Store liegt. |
| Run | Eine Sicherung: Backup-Name, Zeitpunkt, Größen, Aufbewahrung und der Verweis auf ihre Daten. Ein Run entsteht erst, wenn alle Daten sicher im Store liegen, und ist einzeln restorebar. |
| Name | Freier Name des Backups (--name), zum Beispiel je Rechner oder Volume. Alle Runs eines Namens bilden seine Zeitleiste. |
| Chunk | Ein Stück der Quelle (im Mittel 256 KiB), dessen Grenzen FastCDC nach dem Inhalt bestimmt. Jeder Chunk wird über seinen Inhalts-Hash (die ID) erkannt und nur einmal gespeichert. |
| Full / Incremental | Anzeige in Listen und Mails: der erste Run eines Namens in einer Generation heißt Full, jeder weitere Incremental. Beide sind gleichwertig vollständig. |
| Generation | Ein neuer, eigenständiger Store <store>.g<JJJJMMTT>.cbs neben dem alten, der keine Daten mit diesem teilt (physisch unabhängige Basis). Beginnt mit --type full oder automatisch nach --store-generation. |
| Sink | Ein Ziel eines Laufs: ein Store lokal oder auf einem Server. Ein Lauf kann in mehrere Sinks zugleich schreiben; jeder bekommt seinen eigenen Run. |
| Archiv | Ein einzelner Run als eine Datei (.cba, bkp_maintenance export), ohne Store lesbar; für Band, USB-Platte oder Prüfer. |
| Snapshot | Eingefrorener Zeitpunkt eines Volumes (LVM) bzw. Schattenkopie (VSS), damit das Abbild zu einem Zeitpunkt passt. |
| API-Key | Geheimer Schlüssel, mit dem sich ein Agent am bkp_target anmeldet. Ein Key ist in der ACL an ein oder mehrere Verzeichnisse gebunden. |
| Manifest | Signierte Liste der verfügbaren Updates auf dem Update-Server. |
1.4 Überblick über die Abläufe#
Datenfluss
Quelle (Volume/Datei) Ziel
┌──────────────┐ Snapshot ┌───────────┐ lokal ─────────► Verzeichnis (--out)
│ /dev/vg0/data├────────────►│ bkp_agent │
└──────────────┘ (LVM/VSS) └─────┬─────┘ TLS ┌────────────┐ ┌─────────────┐
└───────────────►│ bkp_target ├──►│ /srv/backups│
└─────▲──────┘ └──────┬──────┘
│ TLS │ lokal
┌──────┴──────┐ ┌──────▼──────┐
Ziel-Volume ◄─────────────────────────────────── │ bkp_restore │◄──┤ Store (.cbs)│
└─────────────┘ └─────────────┘