Dateien und Ordner sichern

Zum Inhaltsverzeichnis

Neben Platten, Volumes und VMs sichert bkp_agent auch Dateien und Ordner. Statt einer Quelle (source=) nennt das Profil einen oder mehrere Pfade (path=). Die Dateien gehen durch denselben Store und denselben Chunker wie Blockdaten: Was der Store schon hat, speichert er nicht noch einmal, auch wenn es aus einer Platten- oder VM-Sicherung stammt. Ein Datei-Lauf ist wie jeder Lauf für sich vollständig. Zurück kommen einzelne Dateien, ganze Ordner oder alles, an den ursprünglichen Ort, in einen anderen Ordner oder als ZIP-Archiv.

Ein Profil sichert entweder Geräte (source=) oder Dateien (path=), nicht beides. Lizenz und Punkte sind dieselben wie bei jeder anderen Sicherung des Agents.

9.1 Ein Dateiprofil#

Für einen ersten Versuch genügt die Kommandozeile:

bkp_agent --path /srv/daten --exclude 'cache/' --out /backup --name daten

Ausgabe:

[bkp_agent] INFO  sichere /srv/daten nach /backup/default.cbs: ID-Hash blake3
[bkp_agent] WARNUNG / wird ohne Snapshot gelesen (es liegt nicht auf einem logischen LVM-Volume): Dateien, die sich
                  während der Sicherung ändern, passen womöglich nicht zueinander
[bkp_agent] INFO  5 Datei(en) und 2 Ordner gesichert (650011 Bytes): 5 neu, 0 geändert, 0 unverändert, 0 gelöscht
[bkp_agent] INFO  fertig: full Lauf 20261106T085724Z-c1d00c34-... in /backup/default.cbs: 650011 Bytes in Dateien;
                  Datenblöcke 5, neu 5 (0.0% dedupliziert); 652982 Bytes gesendet, 652982 neu gespeichert

Jede weitere Sicherung ist derselbe Befehl. Der Agent liest dann nur Dateien, deren Größe, Zeiten oder Inode sich geändert haben; alle anderen übernimmt er aus dem Lauf davor, ganze unveränderte Ordner auf einmal. --type full liest alles neu (und beginnt eine neue Store-Generation). Nach einer kleinen Änderung sieht die Zusammenfassung so aus:

Ausgabe:

[bkp_agent] INFO  5 Datei(en) und 2 Ordner gesichert (480028 Bytes): 1 neu, 1 geändert, 3 unverändert, 1 gelöscht
[bkp_agent] INFO  fertig: inkrementelle Sicherung 20261106T085730Z-beafba22-... in /backup/default.cbs: 480028 Bytes in Dateien;
                  Datenblöcke 2, neu 2 (0.0% dedupliziert); 32268 Bytes gesendet, 32268 neu gespeichert

Auf Dauer gehört die Sicherung in ein Profil der Konfigurationsdatei (packaging/bkp_agent.cfg.example enthält dasselbe Beispiel). Ziele sind wie bei jeder Sicherung out=, target= oder Sinks (Kapitel 4):

/etc/bkp/bkp_agent.cfg

[fs1-files]
path=/etc
path=/srv/data
path=/home
exclude=*.tmp
exclude=/srv/data/scratch/
sinks=files-local

[sink:files-local]
type=out
path=/backup

Danach genügt bkp_agent --name fs1-files. Unter Windows stehen die Pfade mit Laufwerk da, etwa path=C:\Users und path=D:\Daten. Die Schlüssel eines Dateiprofils:

Pfade müssen vollständig sein und dürfen nicht doppelt vorkommen. Ein Gerät (/dev/…) gehört in ein Profil mit source=, ein Netzwerkpfad (\\server\freigabe) wird abgelehnt: Dateien einer Freigabe sichert man auf dem Rechner, der sie hat. Liegt ein Pfad in einem anderen gewählten, gehört er ohnehin dazu. Fehlt ein Pfad beim Lauf, sichert der Agent die anderen, nennt den fehlenden im Bericht und meldet den Lauf als teilweise gelungen (partial).

9.1.1 Was mitgesichert wird#

• Linux: Inhalt, Rechte (mode), Besitzer und Gruppe, Zeiten, erweiterte Attribute (xattrs) samt POSIX-ACLs, symbolische Links (als Link, nie verfolgt), Hardlinks (die Daten einmal) und Gerätedateien, Pipes und Sockets (nur als Name).
• Windows: Inhalt, Attribute, Zeiten, der Security Descriptor (Besitzer und NTFS-Berechtigungen; die Überwachungsliste SACL nur, wenn das Konto das Recht dazu hat), alternative Datenströme und Reparse Points (als Link, nicht betreten). Dateien, die nur in der Cloud liegen (OneDrive „Nur online verfügbar“), werden nicht heruntergeladen und nicht gesichert; der Bericht nennt sie. Lange Pfade über 260 Zeichen sind kein Problem.

9.1.2 Snapshots#

Damit die Dateien zueinander passen, liest der Agent nach Möglichkeit aus einem Snapshot:

• Windows: immer eine VSS-Schattenkopie, ein Satz über alle beteiligten Laufwerke (Kopie-Sicherung, die Sicherungshistorie anderer Programme bleibt unberührt). Gelingt die Schattenkopie nicht, scheitert der Lauf mit dem nächsten Schritt (etwa: den Dienst „Volumeschattenkopie“ prüfen).
• Linux mit LVM: Liegen die Pfade auf ext2/3/4 oder XFS in einem logischen Volume, nimmt der Agent je Volume einen Snapshot (Platz wie bei --snapshot-size), hängt ihn nur lesend unter /run/cybackup/fs ein und liest von dort. Gespeichert werden die ursprünglichen Pfade.
• Linux ohne LVM: Der Agent liest die Dateien so, wie sie gerade sind, und sagt das einmal im Bericht (Warnung oben). Ändert sich eine Datei, während er sie liest, liest er sie bis zu zweimal neu; bleibt sie unruhig, speichert er den letzten Stand und vermerkt „während der Sicherung geändert“. Der Lauf bleibt erfolgreich, mit Hinweis.

--snapshot off (Profil snapshot=off) liest auch unter LVM ohne Snapshot, --snapshot on lässt den Lauf scheitern, wenn kein Snapshot möglich ist.

Wird eine Datei-Sicherung angehalten (bkp_sched hold, Zeitfenster, Konsole), bleiben ihre Snapshots erhalten: unter Linux die LVM-Snapshots (Name <volume>_bkpf<job>, Tags bkp_agent und bkp_job_<job>), unter Windows die Schattenkopien als dauerhafte Kopien (nicht mit --vss-persistent off). Der fortsetzende Lauf liest aus denselben Snapshots, ohne Hooks: die Sicherung zeigt alle Dateien so, wie sie beim ersten Start waren, auch wenn sie während des Halts geändert wurden. Fehlt ein Snapshot inzwischen (Neustart unter Windows ohne dauerhafte Kopie, übergelaufener LVM-Snapshot, von Hand entfernt), nimmt der Lauf neue und sagt das im Protokoll; eine angefangene große Datei liest er dann von vorn. Fertig, beendet (bkp_sched stop) oder nach --resume-max-age verschwinden die Snapshots.

9.1.3 Änderungsjournal unter Windows#

Auf NTFS-Laufwerken merkt sich der Agent den Stand des Änderungsjournals (USN-Journal). Beim nächsten Lauf liest er daraus, welche Ordner sich geändert haben, und durchsucht nur diese; alle anderen übernimmt er unverändert. Das spart bei großen Laufwerken mit wenigen Änderungen viel Zeit. Er durchsucht stattdessen alle Ordner, wenn das Journal neu angelegt wurde oder der gemerkte Stand schon herausgefallen ist, das Laufwerk kein NTFS ist, die Rechte fehlen oder --type full gesetzt ist. Der Grund steht im Bericht („Durchlauf“).

9.1.4 Bericht#

Die Ergebnisdatei des Agents (--result-file) hat bei Datei-Läufen ein Objekt files: Dateien, Ordner, Bytes, gelesen, neu, geändert, unverändert, gelöscht, während der Sicherung geändert, Fehler, Journal oder voller Durchlauf und die Pfade ohne Snapshot. Fehler bei einzelnen Dateien (etwa „Zugriff verweigert“) machen den Lauf zu partial; eine Datei, die zwischen Durchsuchen und Lesen verschwunden ist, ist nur ein Hinweis. bkp_sched zeigt diese Zahlen in seiner Mail (Zeilen „Dateien“, „Änderungen“, „Durchlauf“, „Snapshot“, „Hinweis“, „Fehlt“), die Verwaltungskonsole in der Laufliste und im Protokollfenster.

9.2 Ausschlüsse#

exclude= (mehrfach) lässt Dateien und Ordner aus. Ein ausgelassener Ordner wird mit allem darunter übergangen. Die Schreibweise:

Unter Windows zählt \ wie /, und Groß- und Kleinschreibung spielen keine Rolle. Ein gewählter path= wird nie ausgelassen, auch wenn ein Muster passt.

Mit default-excludes=yes (Standard) fallen außerdem diese Pfade weg:

bkp_agent --help zeigt die Liste des jeweiligen Systems.

9.3 Dateien wiederherstellen#

bkp_restore --files arbeitet auf einem Datei-Lauf. Die Stores wählt man wie bei jedem Restore: lokal mit --store, direkt vom Server mit --server oder über die Sinks eines Profils (Kapitel 7). Den Lauf wählt --name (der neueste), --name … --at <zeit> oder --run <lauf>; --list zeigt Datei-Läufe mit der Art und der Zahl der Dateien:

bkp_restore --store /backup/default.cbs --list

gekürzt: ohne die Spalten Rechner, Daten, Gesendet, Neu und Aufbewahrung

LAUF                         ERSTELLT          NAME                        TYP              QUELLE  STATUS
20261106T085724Z-c1d00c34-…  06.11.2026 09:57  daten (Dateien, 5 Dateien)  Full          634,8 KiB  ok
20261106T085730Z-beafba22-…  06.11.2026 09:57  daten (Dateien, 5 Dateien)  Incremental   468,8 KiB  ok
20261106T085731Z-f2260dad-…  06.11.2026 09:57  daten (Dateien, 5 Dateien)  Incremental   468,8 KiB  ok

9.3.1 Typischer Ablauf: eine gelöschte Datei zurückholen#

Auf dem Rechner, auf dem die Datei fehlte, genügen drei Schritte. bkp_restore liest dabei bkp_agent.cfg (mit sinks.cfg daneben) und findet die Stores und Schlüssel der Sinks selbst; --store oder --server braucht es nicht. Im Beispiel sichert das Profil daten den Ordner /srv/daten auf zwei USB-Platten (usb1, usb2), usb2 ist gerade abgezogen.

1. Welche Sicherungen gibt es? bkp_restore --list ohne weitere Angaben zeigt alle Sicherungen aller Profile, jede einmal, mit den Sinks, auf denen sie liegt. Ein Sink, der gerade nicht erreichbar ist, steht ruhig unter der Tabelle, mit dem nächsten Schritt; die übrigen Sicherungen erscheinen trotzdem. Ist eine Dateisicherung dabei, nennt die Fußzeile den Suchbefehl.

bkp_restore --list

gekürzt: ohne die Spalten Rechner, Quelle, Daten, Gesendet, Neu und Aufbewahrung

LAUF                         ERSTELLT          NAME                        TYP           STATUS  ZIELE
20261106T163945Z-4c5cbe47-…  06.11.2026 17:39  daten (Dateien, 4 Dateien)  Voll          ok      usb1
20261106T164051Z-9fe20cc8-…  06.11.2026 17:40  daten (Dateien, 4 Dateien)  Inkrementell  ok      usb1
20261106T164152Z-619e4739-…  06.11.2026 17:41  daten (Dateien, 4 Dateien)  Inkrementell  ok      usb1
jeder Lauf lässt sich für sich wiederherstellen (voll wie inkrementell); ZIELE = wo die Sicherung liegt
eine Datei suchen: bkp_restore --name <Sicherung> --files find "<Muster>"
usb2: gerade nicht erreichbar; das Laufwerk anschließen oder den Ordner /media/usb2 prüfen, dann erneut aufrufen

Wer vom Job des Planers ausgeht, bekommt Profil, Sinks und den passenden Befehl mit bkp_sched show <job> (Kapitel 13, „Einen Job im Einzelnen“); welche Sinks es gibt und ob sie erreichbar sind, zeigt bkp_restore --sinks:

bkp_restore --sinks

Ausgabe:

NAME  ART     ORT          ERREICHBAR           PROFILE
usb1  Ordner  /media/usb1  ja                   daten
usb2  Ordner  /media/usb2  nein (Ordner fehlt)  daten
PROFILE = die Sicherungen (--name), die in das Ziel schreiben; alle Sicherungen: bkp_restore --list

2. Die Datei suchen und ihre Fassungen ansehen. --files find sucht in allen Läufen der Sicherung; * vor und hinter dem Namensteil findet die Datei, auch wenn man den genauen Namen nicht mehr weiß. --files versions zeigt dann jede Fassung mit dem letzten Lauf, in dem sie vorkam.

bkp_restore --name daten --files find "*Angebot*"
bkp_restore --name daten --files versions /srv/daten/projekte/Angebot-Mueller.docx

gekürzt: ohne Zeitstempel, Meldungsnummern und die Wiederholung des Hinweises zu usb2

[bkp_restore] INFO  Ziel usb2 ist gerade nicht erreichbar (der Ordner /media/usb2 fehlt); es geht ohne weiter. Um es
                    einzubeziehen, das Laufwerk anschließen und erneut aufrufen
[bkp_restore] INFO  2 Treffer in 3 Lauf/Läufen der Sicherung daten
TYP    GRÖSSE  GEÄNDERT          ZUERST GESEHEN    ZULETZT GESEHEN   LÄUFE  PFAD
Datei    19 B  06.11.2026 17:39  06.11.2026 17:39  06.11.2026 17:39      1  /srv/daten/projekte/Angebot-Mueller.docx
Datei    31 B  06.11.2026 17:40  06.11.2026 17:40  06.11.2026 17:40      1  /srv/daten/projekte/Angebot-Mueller.docx

[bkp_restore] INFO  2 Version(en) in 3 Lauf/Läufen; eine davon mit --run <letzter Lauf> --files restore <Pfad>
                    wiederherstellen (--as-version behält die aktuelle Datei)
Versionen von /srv/daten/projekte/Angebot-Mueller.docx:
#  TYP    GRÖSSE  GEÄNDERT          ZUERST GESEHEN    ZULETZT GESEHEN   LÄUFE  LETZTER LAUF
1  Datei    19 B  06.11.2026 17:39  06.11.2026 17:39  06.11.2026 17:39      1  20261106T163945Z-4c5cbe47-…
2  Datei    31 B  06.11.2026 17:40  06.11.2026 17:40  06.11.2026 17:40      1  20261106T164051Z-9fe20cc8-…

Findet --files find nichts (Exit-Code 4), nennt es darunter die zutreffenden Gründe, jeweils als Hinweis mit nächstem Schritt:

• Das Muster enthält weder * noch ? noch / und passt deshalb nur auf genau diesen Namen; für einen Namensteil etwa "*angebot*".
• Der gesuchte Pfad liegt außerhalb der gesicherten Ordner (die Meldung nennt sie) oder ist durch exclude= bzw. die Standard-Ausschlüsse von der Sicherung ausgenommen (die Meldung nennt die Regel, auch für Pfade unter einem ausgeschlossenen Ordner).
• Ein Lauf hat den Pfad mit einer Warnung übersprungen, etwa weil die Datei nicht lesbar war: Lauf, Zeit und Grund.
• Immer: welche Läufe durchsucht wurden (Zahl, erster und letzter, Ortszeit), dass ältere Stände nach ihrer Aufbewahrung nicht mehr da sind und Dateien nach dem letzten Lauf noch nicht gesichert; mit --since/--until auch, dass außerhalb nicht gesucht wurde.
• Läufe, die sich nicht lesen ließen, mit dem nächsten Schritt.

Dieselben Gründe (ohne den ersten) nennen --files versions, restore und ls, wenn der Pfad im Lauf fehlt. Mit --json <datei> stehen sie für Programme im Feld hints (exact_name, outside_paths, excluded, warning, span, unread).

3. Zurückholen. Mit --run und dem letzten Lauf der gewünschten Fassung, an den ursprünglichen Ort (--original), in einen anderen Ordner (--to) oder neben die aktuelle Datei (--as-version); ohne --run nimmt --name den neuesten Lauf, --at <zeit> den neuesten bis zu diesem Zeitpunkt:

bkp_restore --name daten --run 20261106T164051Z-9fe20cc8-… --files restore /srv/daten/projekte/Angebot-Mueller.docx --original

Ausgabe:

[bkp_restore] INFO  wiederhergestellt: 1 Datei(en) (31 B), 0 Ordner, 0 Link(s) und andere Einträge;
                    0 übersprungen, weil schon vorhanden (siehe --overwrite)

Viele Dateien auf einmal durchsieht man am bequemsten als Ordner (--files mount, Abschnitt „Lauf als Ordner“). Ein unbekannter --name führt nicht ins Leere: Die Meldung nennt die Profile aus bkp_agent.cfg (höchstens 20) und bkp_restore --list.

9.3.2 Ansehen und zurückholen#

bkp_restore --store /backup/default.cbs --name daten --files ls /srv/daten/projekte
bkp_restore --store /backup/default.cbs --name daten --files restore /srv/daten/projekte --to /srv/zurueck
bkp_restore --store /backup/default.cbs --name daten --files restore /srv/daten/projekte --original --overwrite older

Ausgabe:

TYP           GRÖSSE  GEÄNDERT                  NAME
Datei            18 B  2026-11-06T09:57:31+01:00  angebot.txt
Datei       195,3 KiB  2026-11-06T09:54:44+01:00  bericht1.docx
Datei       195,3 KiB  2026-11-06T09:54:44+01:00  bericht2.docx
Datei        29,3 KiB  2026-11-06T09:57:30+01:00  protokoll.pdf
[bkp_restore] INFO  wiederhergestellt: 4 Datei(en) (419,9 KiB), 1 Ordner, 0 Link(s) und andere Einträge;
                    0 übersprungen, weil schon vorhanden (siehe --overwrite)

• --files ls [<pfad>] zeigt einen Ordner des Laufs (ohne Pfad die oberste Ebene). Pfade stehen so da, wie sie gesichert wurden: /etc/ssh unter Linux, C:\Users\anna unter Windows (Eingaben auch als C:/Users/anna). find, versions, ls und diff zeigen Windows-Pfade mit \, --json behält /.
• --files restore <pfad>… holt Dateien und Ordner zurück, einen Ordner mit allem darunter, <ordner>/* nur seinen Inhalt. Mit --to <ordner> landet jeder gewählte Eintrag unter seinem Namen in diesem Ordner (/srv/daten/projekte wird zu /srv/zurueck/projekte); mit --original an seinem ursprünglichen Ort, nur auf einem System derselben Art.
• --overwrite never|older|always regelt vorhandene Dateien: never (Standard) lässt sie stehen und zählt sie als übersprungen, older ersetzt sie, wenn sie älter sind als die gesicherte, always immer.
• --as-version legt eine einzelne Datei neben die aktuelle, als angebot (Stand 2026-11-06 09-57).txt (Zeit des Laufs, Ortszeit); die aktuelle bleibt unberührt.
• --paths-from <datei> nimmt weitere Pfade aus einer Datei (einer je Zeile, bis 100000), --json <datei> schreibt das Ergebnis für Programme (Status ok, partial oder error, Zähler, Liste der Fehler).

Zurück kommen auch Besitzer, Rechte, erweiterte Attribute, Links und Zeiten (Besitzer und Gerätedateien nur als root; unter Windows Security Descriptor, Attribute und alternative Datenströme). Jede Datei wird unter einem vorläufigen Namen geschrieben und erst fertig umbenannt. Namen aus dem Store verlassen nie den Zielordner, und Links im Ziel werden nicht verfolgt. Scheitert ein einzelner Eintrag, nennt ihn bkp_restore, macht mit dem Rest weiter und endet mit Exit-Code 3.

Auf einem anderen Rechner stellt man Dateien wieder her, indem man bkp_restore dort aufruft, wo der Store erreichbar ist: lokal, über einen Sink des Profils oder direkt vom Backup-Server; bei einem verschlüsselten Store mit --decrypt-key file:<pfad>.

9.3.3 Suchen, Versionen, Änderungen#

bkp_restore --store /backup/default.cbs --name daten --files find '*.txt'
bkp_restore --store /backup/default.cbs --name daten --files versions /srv/daten/projekte/angebot.txt
bkp_restore --store /backup/default.cbs --name daten --run 20261106T085730Z-beafba22-… --files diff

Ausgabe:

[bkp_restore] INFO  4 Treffer in 3 Lauf/Läufen der Sicherung daten
TYP         GRÖSSE  GEÄNDERT          ZUERST GESEHEN    ZULETZT GESEHEN   LÄUFE  PFAD
Link                06.11.2026 09:54  06.11.2026 09:57  06.11.2026 09:57      3  /srv/daten/link.txt
Datei         11 B  06.11.2026 09:54  06.11.2026 09:57  06.11.2026 09:57      1  /srv/daten/projekte/angebot.txt
Datei         28 B  06.11.2026 09:57  06.11.2026 09:57  06.11.2026 09:57      1  /srv/daten/projekte/angebot.txt
Datei         18 B  06.11.2026 09:57  06.11.2026 09:57  06.11.2026 09:57      1  /srv/daten/projekte/angebot.txt

Versionen von /srv/daten/projekte/angebot.txt:
  #  TYP    GRÖSSE  GEÄNDERT          ZUERST GESEHEN    ZULETZT GESEHEN   LÄUFE  LETZTER LAUF
  1  Datei    11 B  06.11.2026 09:54  06.11.2026 09:57  06.11.2026 09:57      1  20261106T085724Z-c1d00c34-…
  2  Datei    28 B  06.11.2026 09:57  06.11.2026 09:57  06.11.2026 09:57      1  20261106T085730Z-beafba22-…
  3  Datei    18 B  06.11.2026 09:57  06.11.2026 09:57  06.11.2026 09:57      1  20261106T085731Z-f2260dad-…

[bkp_restore] INFO  1 neu, 1 geändert, 1 gelöscht (es zählen nur Inhalt und Links, nicht Zeiten oder Berechtigungen)
~ /srv/daten/projekte/angebot.txt
- /srv/daten/projekte/bericht3.docx
+ /srv/daten/projekte/protokoll.pdf

• --files find <muster> sucht in allen Läufen der Sicherung (* beliebige Zeichen, ? eines, beide nicht über / hinweg). Ein Muster mit / passt auf ganze Pfade (/home/*/bericht*), sonst auf den Namen; unter Windows ohne Rücksicht auf Groß- und Kleinschreibung. Jede gefundene Fassung steht einmal da, mit erstem und letztem Auftauchen. --since/--until grenzen die Läufe ein. Ordner, die zwischen zwei Läufen gleich blieben, liest die Suche nur einmal; deshalb ist sie auch über viele Läufe schnell. Nichts gefunden: Exit-Code 4.
• --files versions <pfad> zeigt die verschiedenen Fassungen einer Datei über alle Läufe. Eine neue Fassung entsteht nur durch geänderten Inhalt oder ein geändertes Linkziel, nicht durch Zeiten oder Rechte. Eine Fassung holt man mit --run <letzter Lauf> --files restore <pfad> zurück, auf Wunsch mit --as-version.
• --files diff [<pfad>] zeigt, was gegenüber dem Lauf davor neu (+), geändert (~) und gelöscht (-) ist; --run2 <lauf> vergleicht mit einem anderen Lauf.

9.3.4 Als ZIP-Archiv#

bkp_restore --store /backup/default.cbs --name daten --files zip /srv/daten/projekte --to /srv/projekte.zip

Ausgabe:

[bkp_restore] INFO  Archiv geschrieben: 4 Datei(en) (419,9 KiB), 1 Ordner; 420,9 KiB als ZIP

Das Archiv (ZIP64, deflate; --to - schreibt auf die Standardausgabe) enthält Namen, Inhalte und Änderungszeiten. Besitzer, Rechte, erweiterte Attribute, Security Descriptors, alternative Datenströme, Links und Gerätedateien fehlen darin; die bringt nur --files restore zurück.

9.4 Lauf als Ordner#

Statt Dateien zurückzuschreiben, kann bkp_restore einen ganzen Datei-Lauf als schreibgeschützten Ordner zeigen. Inhalte liest es erst aus dem Store, wenn jemand eine Datei öffnet; so lassen sich auch große Läufe sofort durchsehen und einzelne Dateien mit den üblichen Werkzeugen herauskopieren.

bkp_restore --store /backup/default.cbs --name daten --files mount --to /mnt/daten-lauf --idle 60
ls -l /mnt/daten-lauf/srv/daten/projekte
umount /mnt/daten-lauf

Ausgabe:

Lauf 20261106T085731Z-f2260dad-… der Sicherung daten wird schreibgeschützt in /mnt/daten-lauf gezeigt.
Er bleibt bis Strg+C oder umount /mnt/daten-lauf.
/mnt/daten-lauf ist ausgehängt.

• Linux (als root): ein eigener FUSE-Kern ohne zusätzliche Bibliothek. Gezeigt werden alle Dateien, Links, Besitzer, Rechte und erweiterten Attribute wie gesichert. Der Ordner muss leer sein oder wird angelegt und danach wieder entfernt. Windows-Berechtigungen und alternative Datenströme zeigt die Ansicht nicht; die gibt es über --files restore.
• Windows (als Administrator, ab Windows 10 1809 bzw. Server 2019): über die Windows-Funktion Projected File System (ProjFS). Gezeigt werden Dateien und Ordner mit Größen und Zeiten; die Laufwerke eines Windows-Laufs erscheinen als Ordner ohne Doppelpunkt (C:\mnt\C\Users\…). Schreiben, Anlegen, Umbenennen und Löschen weist die Ansicht ab (startet man bkp_restore von Hand, kann nur ein ebenfalls als Administrator gestartetes Programm desselben Kontos dort noch Dateien anlegen; sie werden mit dem Ende der Ansicht entfernt). Ist die Funktion aus, schaltet die Verwaltungskonsole sie auf Wunsch ein (dism, danach ist oft ein Neustart nötig).
• --idle <minuten> beendet die Ansicht nach so vielen Minuten ohne Zugriff (0, der Standard, lässt sie stehen); --json <datei> nennt Pfad, Lauf und Prozess, solange der Ordner da ist.

Über den Scheduler (Verwaltungskonsole, Knopf „Als Ordner anzeigen…“) liegt die Ansicht unter Linux in /run/cybackup/ansicht/<job>/<lauf>, unter Windows in Ansicht\<job>\<lauf> im Warteschlangenordner des Schedulers (nur Administratoren und SYSTEM). Höchstens vier Ansichten sind gleichzeitig offen; nach 60 Minuten ohne Zugriff hängt der Scheduler sie aus, übrig gebliebene beim nächsten Start.

9.5 Dateien aus Platten- und VM-Sicherungen#

Auch aus einem Block- oder VM-Lauf lassen sich einzelne Dateien holen, ohne die ganze Platte zurückzuspielen, unter Linux als root und unter Windows als Administrator. Unter Linux:

bkp_restore --store /backup/default.cbs --name srv1 --image-volumes
bkp_restore --store /backup/default.cbs --name srv1 --image-mount --to /mnt/srv1 --idle 60
bkp_restore --store /backup/default.cbs --name srv1 --volume disk/1 --files restore /etc/fstab --to /srv/zurueck
bkp_restore --store /backup/vm.cbs --name web1 --volume scsi0/vg0/root --files zip /var/www --to www.zip

• --image-volumes listet die Volumes auf den Platten des Laufs (Partitionen und logische LVM-Volumes) mit Dateisystem, Größe und Bezeichnung, und warum sich eines nicht öffnen lässt (verschlüsselt, kein Dateisystem, eine Volume-Gruppe, die sich hier nicht öffnen lässt). --disk <slot> nimmt nur eine Platte eines VM-Laufs.
• --image-mount --to <ordner> hängt jedes Volume nur lesend unterhalb des Ordners ein, ein Unterordner je Volume (disk-1, scsi0-vg0-root …). Nichts wird vorher zurückgespielt; die Daten kommen beim Lesen aus dem Store. Journale werden nicht nachgespielt, ein Volume erscheint also genau so, wie es gesichert wurde. Es bleibt bis Strg+C, umount aller Volumes oder --idle.
• --volume <volume> lässt --files ls, --files zip und --files restore (dann mit --to) auf einem Volume arbeiten statt auf einem Datei-Lauf; die Namen stammen aus --image-volumes. Eine Suche über mehrere Läufe gibt es bei Platten nicht.

Lesen kann bkp_restore ext2/3/4, XFS, Btrfs, NTFS, FAT und exFAT, auch in LVM in der Platte. BitLocker- und LUKS-Volumes werden als verschlüsselt genannt und nicht geöffnet. Die Volume-Gruppen aus der Sicherung werden umbenannt geöffnet, eine gleichnamige Volume-Gruppe des Rechners wird nie berührt. Was ein abgebrochener Aufruf hinterlassen hat, räumt der nächste auf.

Unter Windows gelten dieselben Optionen, als Administrator. Der Store liegt auf diesem Rechner oder wird mit --server von einem Backup-Server gelesen:

bkp_restore --store D:\Sicherung\default.cbs --name pc1 --image-volumes
bkp_restore --store D:\Sicherung\default.cbs --name pc1 --image-mount --to C:\Ansicht\pc1 --idle 60
bkp_restore --store D:\Sicherung\default.cbs --name pc1 --volume disk/3 --files restore \Users\anna\Documents --to C:\Zurueck
bkp_restore --store D:\Sicherung\vm.cbs --name buero --volume scsi0-0/2 --files zip \Daten --to C:\Zurueck\daten.zip

Ausgabe:

VOLUME  TYP            GRÖSSE  BEZEICHNUNG  HINWEIS
disk/1  MSR          16,0 MiB               von Windows reserviert, enthält keine Dateien
disk/2  ntfs        119,2 GiB  System
disk/3  ntfs        800,0 GiB  Daten
disk/4  BitLocker    80,0 GiB               verschlüsselt (BitLocker); die Disk wiederherstellen und mit ihrem Schlüssel öffnen

• bkp_restore stellt die Platten des Laufs über ein eigenes, nur lesbares iSCSI-Ziel auf 127.0.0.1 bereit, an das sich der iSCSI-Initiator von Windows anmeldet; nichts wird vorher zurückgespielt, kein Treiber wird installiert. Der Dienst „Microsoft iSCSI-Initiator-Dienst“ (MSiSCSI) wird bei Bedarf gestartet und danach wieder beendet, wenn er vorher aus war. Der Initiator meldet sich – auch an 127.0.0.1 – erst an, wenn der Rechner seit dem Start einmal mit einem Netzwerk verbunden war (gesehen unter Windows 11); ohne Netz bricht bkp_restore nach 30 Sekunden mit diesem Hinweis ab. Ein Internetzugang ist nicht nötig, jedes verbundene Netzwerk genügt.
• Die Platte erscheint schreibgeschützt und ohne Laufwerksbuchstaben. Ist die gesicherte Platte noch am Rechner angeschlossen, bekommt die Kopie neue Platten- und Partitionskennungen, damit Windows beide zugleich zeigt; die Originalplatte bleibt unverändert.
• --image-mount --to <ordner> zeigt jedes lesbare Volume als Unterordner (disk-2, scsi0-0-1 …). Schreiben weist der Ordner ab. Die Ansicht bleibt bis Strg+C, bis alle Volume-Ordner abgehängt sind (mountvol <ordner> /D) oder bis --idle. Mit --viewer <SID> darf zusätzlich dieses Benutzerkonto den Ordner lesen (die SID zeigt whoami /user); ohne die Angabe öffnen ihn nur Programme, die als Administrator laufen, nicht der Explorer.
• Lesen kann Windows NTFS, ReFS, FAT und exFAT. Linux-Dateisysteme und LVM nennt --image-volumes mit dem Hinweis „bitte über das Target oder einen Linux-Rechner öffnen“, BitLocker- und LUKS-Volumes als verschlüsselt. Volumes auf dynamischen Datenträgern und in Speicherplätzen lassen sich nur lesen, nachdem die Platten zurückgespielt wurden.
• --files restore schreibt wie bei Datei-Läufen Zeitstempel, Attribute, alternative Datenströme und Berechtigungen zurück und kommt mit langen Pfaden zurecht.
• Endet bkp_restore ohne Abbau (abgebrochen, Rechner abgestürzt), räumt der nächste Aufruf oder der Start des Schedulers die übrig gebliebene Ansicht ab.

In der Verwaltungskonsole geht das ohne Kommandozeile: Bei Platten- und VM-Jobs bietet „Dateien wiederherstellen“ die Auswahl Volume, nicht lesbare Volumes sind ausgegraut und nennen den Grund; „Als Ordner anzeigen…“ zeigt alle lesbaren Volumes eines Laufs als Ordner (Kapitel 14, „Dateien wiederherstellen“).

9.6 Ransomware-Warnung#

Verschlüsselt Schadsoftware die Dateien eines Rechners, sieht die nächste Sicherung ungewöhnlich aus: fast alles geändert, viele neue Dateien mit seltsamen Endungen. Der Agent vergleicht deshalb jeden Datei-Lauf mit den Läufen davor. Auffällig ist ein Lauf, wenn

• der Anteil der neuen, geänderten und gelöschten Dateien über ransom-ratio liegt (Standard 30 %) und zugleich das ransom-factor-Fache (Standard 5) des Üblichen beträgt (Median der letzten 10 Läufe; erst ab 3 Läufen davor und ab 20 berührten Dateien), oder
• mehr als 50 neue Dateien Endungen tragen, die Erpressungssoftware verwendet: .locky, .crypt, .crypted, .cerber, .wncry, .wnry, .wcry, .zepto, .odin, .encrypted, .locked, .ryk, .conti, .lockbit, .djvu, .crypz, .cryp1, .ecc, .ezz, .exx, .aaa, .micro, .enc (dieselbe Liste nutzt pruef-virus).

Ein auffälliger Lauf wird trotzdem gespeichert, mit einer Warnung und den Gründen im Lauf und im Bericht. bkp_sched meldet ihn als „auffällig“ per Mail, die Verwaltungskonsole markiert ihn in der Laufliste und im Fenster „Dateien wiederherstellen“, und ein Backup-Server schickt Kunde und Betreiber die Mail auffaellig: „Ungewöhnlich viele Dateien wurden geändert – möglicher Verschlüsselungsangriff. Ältere Stände bleiben erhalten.“

Vor allem schützt er die älteren Stände: Für ransom-hold-days Tage (Standard 30) löscht keine Aufbewahrung (Agent, bkp_maintenance prune, Target-Scheduler) einen Lauf derselben Sicherung, der vor dem auffälligen liegt. War es ein Fehlalarm, etwa nach einer gewollten Umstellung vieler Dateien, hebt ein Administrator den Schutz auf; der Lauf behält einen Vermerk darüber:

bkp_restore --store /backup/default.cbs --run 20261106T085731Z-f2260dad-… --clear-anomaly

Mit ransom-check=no ist die Prüfung für ein Profil aus.

9.7 Prüfungen auf Datei-Läufen#

Die Prüf-Kette des Target-Schedulers (Kapitel 11) behandelt Datei-Läufe eigens: pruef-restore spielt nichts zurück, merkt sich aber Lauf und Schlüssel, pruef-mount zeigt den Lauf schreibgeschützt als Ordner (unter <mount-point>/<nn>-<sicherung>/files/whole), und pruef-count und pruef-virus lesen ihn dort wie ein eingehängtes Dateisystem. pruef-fsck und pruef-vm-start überspringen Datei-Läufe. bkp_dump --run <lauf> zeigt bei einem Datei-Lauf die Wurzel und die oberste Ebene, --path <ordner> einen Ordner.