Kategorien
Allgemein

Backup für backintime

Für das Back­up mei­nes Desk­top benut­ze ich seit lan­gem back­in­ti­me.  Die­ses Tool erzeugt inkre­men­tel­le rsync-Back­ups, mit denen man im nach­hin­ein den Stand zu jedem Back­up-Zeit­punkt wie­der­her­stel­len kann - sehr über­sicht­lich und bequem.

Ziel von back­in­ti­me ist mein NAS, auf das per ssh zuge­grif­fen wird. Wenn ein­mal das Ursprungs-Back­up mit etwa 20 GByte erzeugt wur­de, kom­men täg­lich - je nach Akti­vi­tät - nur eini­ge MByte dazu. Die unver­än­dert bestehen­den Datei­en wer­den nicht kopiert, son­dern nur als hard links in die Back­up-Ver­zeich­nis­se ein­ge­tra­gen.

Nun ist eine Back­up-Genera­ti­on bes­ser als gar kei­ne, aber um halb­wegs seri­ös zu sein braucht man min­des­tens eine, bes­ser zwei zusätz­li­che Back­up-Genera­tio­nen, die im Ide­al­fall auch räum­lich getrennt von­ein­an­der auf­be­wahrt wer­den.

Ziel der zwei­ten Genera­ti­on soll das NAS an mei­ner Fritz­box sein. Lei­der ist die Fritz­box aus­schließ­lich über SMB erreich­bar (noch dazu das his­to­ri­sche SMB1).

Versuch 1: tar

Ein tar-Archiv stellt an das Ziel-Datei­sys­tem die gerings­ten Anfor­de­run­gen. Auch wenn man hard links archi­viert, muss das vom Ziel nicht unbe­dingt unter­stützt wer­den. Also prü­fen wir zunächst, ob ein Back­up per tar sinn­voll mach­bar ist. Das Fritz­box-Sha­re wird am NAS also per cifs gemoun­tet und das Back­up per tar vom NAS auf den Sha­re kopiert.

Aber wie ver­hält sich tar bei hard links? Back­in­ti­me macht davon sehr aus­gie­big Gebrauch. Da mir das nicht ganz klar war, habe ich eini­ge Ver­su­che ange­stellt. zunächst mal die ein­fachs­te Vari­an­te: Ursprungs­da­tei und Link befin­den sich im sel­ben Archiv:

$ touch a
$ ln a b
$ tar cvf 1.tar a b
a
b
$ tar -tvf 1.tar
-rw-r--r-- joerg/joerg       0 2018-12-01 14:43 a
hrw-r--r-- joerg/joerg       0 2018-12-01 14:43 b Verknüpfung zu a
$

Wie wahr­schein­lich von jedem erwar­tet, erzeugt tar für den Link b kei­ne Datei, son­dern trägt die Ver­lin­kung auf a in das Archiv ein. Was pas­siert aber, wenn die Ursprungs­da­tei nicht aus­drück­lich in das Archiv kopiert wird?

$ tar cvf 2.tar b
b
$ tar -tvf 2.tar
-rw-r--r-- joerg/joerg       0 2018-12-01 14:43 b
$

Auch das mach Sinn: der Link wird auf­ge­löst und als Datei in das Archiv kopiert. Jetzt über­prü­fen wir das Ver­hal­ten von inkre­men­tel­len tar-Archi­ven. Sie sol­len nur Datei­en kopie­ren, die nach dem letz­ten Back­up erzeugt wur­den. Was pas­siert aber, wenn das Inkre­ment einen Link auf eine älte­re Datei ent­hält, die eigent­lich nicht noch­mals gesi­chert wer­den müss­te?

mkdir files
$ touch files/a
$ tar cvf 1.tar -g timestamp.dat files
tar: Verzeichnis „files“ ist neu.
files/
files/a
$ touch files/b
$ tar cvf 2.tar -g timestamp.dat files
files/
files/b
joerg@ubuntu-desktop:/tmp/tar$ tar tvf 2.tar 
drwxr-xr-x joerg/joerg      10 2018-12-01 15:08 files/
-rw-r--r-- joerg/joerg       0 2018-12-01 15:08 files/b
$

Bis hier­hin ist alles wie erwar­tet: Im ers­ten Archiv wird Datei a ange­legt, wäh­rend sie im zwei­ten, inkre­men­tel­len Archiv fehlt. Die Infor­ma­tio­nen in timestamp.dat haben erge­ben, dass sich die Datei seit dem letz­ten Back­up nicht ver­än­dert hat und daher nicht erneut kopiert wer­den muss. Jetzt erzeu­gen wir aber einen Link auf Datei a:

$ ln files/a files/c
$ tar cvf 3.tar -g timestamp.dat files
files/
files/a
files/c
$ tar tvf 3.tar 
drwxr-xr-x joerg/joerg       7 2018-12-01 15:06 files/
-rw-r--r-- joerg/joerg       0 2018-12-01 15:05 files/a
hrw-r--r-- joerg/joerg       0 2018-12-01 15:05 files/c Verknüpfung zu files/a

Obwohl sich Datei a seit dem ers­ten Back­up nicht ver­än­dert hat, wird sie jetzt noch­mals in das Archiv kopiert. Nur so bleibt das Archiv in sich selbst kon­sis­tent, denn ande­ren­falls wäre der Link c nicht auf­lös­bar.

Im Fal­le von back­in­ti­me ist die­ses Ver­hal­ten aber fatal: hier ste­cken in jedem Back­up tau­sen­de hard links auf Datei­en, die sich nicht ver­än­dert haben, aber auf die­se Wei­se trotz­dem jedes mal mit­ko­piert wer­den müs­sen. So wächst die Grö­ße eines inkre­men­tel­len Back­ups von den eigent­lich nöti­gen weni­gen MBytes auf meh­re­re GBytes.

Ich habe kei­nen Weg gefun­den, tar bei­zu­brin­gen, bei der dere­fe­ren­zie­rung von Links auch ein frü­he­res Archiv mit her­an­zu­zie­hen. Damit erzeugt tar für back­in­ti­me-Archi­ve immer Unmas­sen an über­flüs­si­gen Daten und ist des­we­gen lei­der kom­plett unge­eig­net.

Versuch 2: rsync

In mei­ner Ver­zweif­lung habe ich dann doch noch ein­mal aus­pro­biert, wie sich das cifs-Sha­re bei links ver­hält. Zunächst ein­mal ein Lis­ting des Quell­ver­zeich­nis­ses inklu­si­ve ver­link­ter inodes:

$ ls -links files
insgesamt 0
527274 0 -rw-r--r-- 2 1000 1000 0 Dez  1 15:05 a
527272 0 -rw-r--r-- 1 1000 1000 0 Dez  1 15:05 b
527274 0 -rw-r--r-- 2 1000 1000 0 Dez  1 15:08 c
$

Man sieht, dass die Datei­en a und c auf die sel­be inode zei­gen. Jetzt kopie­ren wir das Ver­zeich­nis mit rsync auf die Fritz­box, wobei die Opti­on H für den Erhalt der hard links sor­gen soll.

$ rsync -avdH files /media/fritzbox/USB-Drive/
sending incremental file list
files/
files/b
files/c
files/a => files/b

sent 206 bytes  received 73 bytes  79.71 bytes/sec
total size is 0  speedup is 0.00
$ ls -links /media/fritzbox/USB-Drive/files
insgesamt 0
18874370 0 -rw-rw-rw- 2 1000 1000 0 Dez  1 15:05 a
18874371 0 -rw-rw-rw- 1 1000 1000 0 Dez  1 15:05 b
18874370 0 -rw-rw-rw- 2 1000 1000 0 Dez  1 15:08 c
$ 

Wer hät­te das gedacht: auch auf der Fritz­box zei­gen die Datei­en a und c auf die­sel­be inode, sind also hard links! Schein­bar ist ein Back­up per rsync also im Hin­blick auf die hard links doch sinn­voll mög­lich.

Nach dem Umstel­len des Back­up-Scripts auf rsync also der ers­te Ver­such. Lei­der hat­te ich nicht bedacht, dass cifs ohne Unix-Erwei­te­run­gen die Infor­ma­tio­nen über owner, group und per­mis­si­ons nicht spei­chern kann.

Obwohl nach dem Moun­ten das Datei­sys­tem mit unix gelis­tet wird, schei­nen die Unix-Erwei­te­run­gen bei der Fritz­box-Imple­men­tie­rung des SMB-Pro­to­kolls nicht oder zumin­dest nicht voll­stän­dig umge­setzt zu sein. Jeder Ver­such, Eigen­tü­mer, Grup­pe oder Per­mis­si­ons einer Datei zu ändern, endet mit einer Feh­ler­nach­richt über feh­len­de Rech­te dafür.

Man kann rsync trotz­dem ein­setz­ten, wenn man statt des --archi­ve Schal­ters, der impli­zit unter ande­rem auch --owner, --group und --perms setzt, nur --recur­si­ve, --times und --links angibt. Aller­dings wer­den dann alle Datei­en auf dem Sha­re mit Stan­dard-User, Group und -Per­mis­si­ons gespei­chert.

Stan­dard-User und -Grup­pe kön­nen zwar eben­so wie die Stan­dard-Per­mis­si­ons beim moun­ten des cifs-Sha­res ange­ge­ben wer­den, gel­ten dann aber für alle Datei­en auf dem Sha­re. Gibt man nichts an, ste­hen die Per­mis­si­ons übri­gens auf 777, so dass jeder, der gene­rell Zugriff auf das Sha­re hat, alle Rech­te an Datei­en und Ord­nern besitzt.

Statt des Stan­dard­werts von 0:0 (root:root) für Nut­zer- und Grup­pen-ID mel­det die Fritz­box übri­gens 1031:0, erlaubt aber das Über­schrei­ben per Mount-Para­me­ter.

Vie­le Pro­ble­me wür­den sich wahr­schein­lich erüb­ri­gen, hät­te man es auf der Fritz-Sei­te mit einem ‘ech­ten’ rsync-Ser­ver zu tun. Aber FRITZ!OS bie­tet kei­nen an und hat zudem die Mög­lich­kei­ten, selbst Soft­ware nach­zu­in­stal­lie­ren, seit eini­ger Zeit stark beschnit­ten. So kann man seit Ver­si­on 6.3 den Tel­net-Zugang nicht mehr akti­vie­ren, und mit fol­gen­den Ver­sio­nen wur­de der Ein­satz unsi­gnier­ter Soft­ware­pa­ke­te unter­bun­den.

Ein­zi­ge Mög­lich­keit, an zusätz­li­che Soft­ware zu kom­men, wäre wohl das freie Sys­tem Freetz, dass FRITZ!OS mit zusätz­li­chen Pake­ten zu einer neu­en OS-Ver­si­on bün­delt. Das Gan­ze müss­te man aber selbst kom­pi­lie­ren und als OS-Update ein­spie­len.

Neben dem Ver­lust der Garan­tie muss man auch damit rech­nen, dass sol­che Aktio­nen mal schief­ge­hen kön­nen. Ich wür­de das nicht ohne eine funk­tio­nie­ren­de Ersatz-Fritz­box ange­hen.

Seit län­ge­rem ist zudem freetz​.org, die Hei­mat des Pro­jekts, spo­ra­disch nicht erreich­bar. So konn­te ich zum Ver­öf­fent­li­chungs­zeit­punkt nicht fest­stel­len, ob es über­haupt für die aktu­el­le FRITZ!OS-Version ver­füg­bar ist.

Verschlüsseltes Dateisystem

Mit einem ver­schlüs­sel­ten Datei­sys­tem wie ecryptfs las­sen sich auch ein­zel­ne Ord­ner sichern. Eigen­tü­mer und Rech­te inner­halb des Con­tai­ners ver­wal­tet dann das Datei­sys­tem des Rech­ners, auf dem das ver­schlüs­sel­te Datei­sys­tem gemoun­ted wird, nicht das der Fritz­box. So soll­ten sich die Rech­te­pro­ble­me von rsync umge­hen las­sen. Frag­lich ist nur, wie sich das auf die Per­for­mance aus­wirkt.

Das Datei­sys­tem ecryptfs selbst ist zwar Bestand­teil der meis­ten Linux-Dis­tri­bu­tio­nen, aber die Hilfs­pro­gram­me müs­sen übli­cher­wei­se noch instal­liert wer­den:

$ apt-get install ecryptfs-utils

Für die ver­schlüs­sel­ten und ent­schlüs­sel­ten Daten muss jeweils ein Ver­zeich­nis ange­legt wer­den.

$ mkdir /media/remote/.geheim
$ mkdir -p /media/fritzbox/geheim
$ chmod 700 /media/fritzbox/geheim

Dabei liegt /media/fritzbox, das Ver­zeich­nis mit den ver­schlüs­sel­ten Daten, auf dem mit cifs gemoun­te­ten Sha­re der Fritz­box, wäh­rend sich /media/lokal auf dem NAS selbst befin­det und die unver­schlüs­sel­ten Daten auf­nimmt. Für das loka­le Ver­zeich­nis ver­wei­gern wir allen außer dem Eigen­tü­mer den Zugriff; für das Ver­zeich­nis auf der Fritz­box hät­te das kei­ne Wir­kung (sie­he oben).

Damit das spä­te­re Moun­ten ohne Pass­wort­ab­fra­ge erfol­gen kann, muss das Pass­wort für die Ver­schlüs­sel­ten Daten in den Schlüs­sel­ring der root-Users ein­ge­tra­gen wer­den:

$ ecryptfs-add-passphrase 
Passphrase: 
Inserted auth tok with sig [a8dfcae0c76dea6c] into the user session keyring
$

Zur Sicher­heit kann man sich den Inhalt des Schlüs­sel­rings mit keyc­tl auch noch­mals lis­ten las­sen:

$ keyctl list @u 
1 key in keyring:
983685422: --alswrv     0     0 user: a8dfcae0c76dea6c
$ 

Mit die­sem Schlüs­sel lässt sich jetzt das (noch lee­re) ver­schlüs­sel­te Ver­zeich­nis moun­ten:

$ mount -i -t ecryptfs -o ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=y,ecryptfs_sig=a8dfcae0c76dea6c,ecryptfs_fnek_sig=a8dfcae0c76dea6c,ecryptfs_unlink_sigs,ecryptfs_key_bytes=16,ecryptfs_cipher=aes /media/fritzbox/.geheim /media/lokal/geheim
$

Legt man jetzt im unver­schlüs­sel­ten Ver­zeich­nis eine Datei an, erscheint sie mit ver­schlüs­sel­tem Datei­na­men auch im ver­schlüs­sel­ten Ver­zeich­nis:

$ echo "geheime Daten">/media/lokal/geheim/GeheimDatei
root@omv0:~# cat /media/lokal/geheim/GeheimDatei
geheime Daten
$ ls /media/fritzbox/.geheim
ECRYPTFS_FNEK_ENCRYPTED.FWbpHMqM4Zi.lUQM9ah.l1WRL8A1RhEhzz2F.Jv8o.RkqGyLKObHJSxfK---
$

In der ver­schlüs­sel­ten Datei fin­det man erwar­tungs­ge­mäß kei­ne les­ba­ren Daten. Als ers­ten Per­for­mance-Test kann man eine gro­ße Datei, hier ein Vir­tu­al­box-Image von 4,4 GByte, in das loka­le Ver­zeich­nis kopie­ren.

$ du -h image.vdi
4,4G	image.vdi
$ date
So 2. Dez 15:32:29 CET 2018
$ cp image.vdi /media/fritz/geheim/
$ date
So 2. Dez 16:01:12 CET 2018
$

Am Ende ist die ver­schlüs­sel­te Datei eben­falls 4,4 GByte groß. Sie wächst auf der Fritz­box mit etwa 2,5…3 MByte/s. Die Gesamt­dau­er beträgt 28:43 Minu­ten oder 1723 Sekun­den, das ent­spricht eben­falls etwa 2,55 MByte/s. Die CPU des NAS zeigt dabei etwa 10% Last, die der Fritz­box 25%.

Hier der Ver­gleich zum unver­schlüs­sel­ten Kopie­ren:

$ mkdir /media/fritzbox/offen
$ date
So 2. Dez 16:14:47 CET 2018
$ cp image.vdi /media/fritz/offen/
$ date
So 2. Dez 16:16:36 CET 2018
$

Das unver­schlüs­sel­te Kopie­ren dau­ert nur 1:49 Minu­ten oder 109 Sekun­den, das ent­spricht 40,4 MByte/s. Das ist ernüch­ternd: der ver­schlüs­sel­te Trans­fer erreicht nur etwa 116 der Über­tra­gungs­ra­te der unver­schlüs­sel­ten Vari­an­te. 

Kapitulation

Der feh­len­de rsync-Ser­ver, die nicht vor­han­de­nen Unix-Erwei­te­run­gen des Sam­ba-Ser­vers und die ernüch­tern­de Geschwin­dig­keit eines ent­fernt gemoun­te­ten ver­schlüs­sel­ten Datei­sys­tems machen die Fritz­box als Ziel für Back­ups mei­nes back-in-time-Archivs unat­trak­tiv.

Ein RasPi erfüllt die Min­dest­an­for­de­run­gen mit sei­nem offe­nen Linux wesent­lich bes­ser. Ein rsync-Ser­ver und eine aktu­el­le Sam­ba-Imple­men­tie­rung ist immer mit an Bord. Der aktu­el­le 3B+ dürf­te mit Giga­bit-Ether­net und noch­mals schnel­le­rem Pro­zes­sor auch in Punk­to Geschwin­dig­keit eini­ge Vor­tei­le gegen­über der Fritz-Box haben. Lei­der bedeu­tet das aber wie­der einen wei­te­ren Kist­chen-Sta­pel mit RasPi, Netz­teil und Lauf­werk, der auch zusätz­lich Strom schluckt.

Wohl oder übel muss ich wohl zunächst kapi­tu­lie­ren. Ein loka­les Back­up auf eine direkt am NAS ange­schlos­se­ne USB3-Fest­plat­te dau­ert statt Stun­den nur weni­ge Minu­ten und sichert die Daten auch mit den kor­rek­ten Eigen­tü­mern und Zugriffs­rech­ten. Mit zwei oder 3 sepa­ra­ten Lauf­wer­ken lässt sich sogar sehr ein­fach ein Mehr­ge­nera­tio­nen-Sys­tem auf­bau­en. Nach dem Back­up lässt sich das Lauf­werk abzie­hen und sicher ver­stau­en.

Man darf nur nicht ver­ges­sen, die Back­ups auch regel­mä­ßig durch­zu­füh­ren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.