EncFS --reverse

Gerade habe ich in der Manpage von EncFS eine sehr schöne Lösung für ein sicheres Backup in der Cloud gefunden.

Encfs ist ein Dateisystem im Userspace und bietet eine Sicht auf Verzeichnisse an. Ursprünglich ging es darum verschlüsselte Verzeichnisse entschlüsselt anzuzeigen. Der Reverse Modus bietet genau den umgekehrten Weg an. Somit können beliebige (unverschlüsselte) Verzeichnisse mittels EncFs als verschlüsselte Verzeichnisse angezeigt werden.

"Wow. Wtf?" Werden sich gerade einige fragen. Aber mit dieser umgekehrten Sicht, kann man einfach mit einem Synchronisationswerkzeug das Ganze an syncronisieren. "Wow!"

Ich verweise einfach nur auf den Artikel: Daten sicher in der Synchro-Wolke dank encfs.

Habe leider keine Ahnung, ob dieser Modus auch für Mac bzw. auch für Windows via dokan verfügbar ist. :|

P.S. Python WrapperSkript encfs –reverse + rsync = encrb

Effiziente Synchronisierung mit Rsync

Durch einen Festplattenausfall letzte Woche ist für mich wieder einmal das Thema "Backup" sehr präsent geworden. Durch den glücklichen Umstand , dass dieser Ausfall sich angekündigt hat, war es mir möglich mein Sicherungskopien zu überprüfen.
Auf meinem Ubuntu-System nutze ich backintime. Damit habe ich platzsparende versionierte Vollbackups.
Die Verzeichnisstruktur sieht in etwa so aus:

/backup/backintime/.../20120630-200001-964/
...
/backup/backintime/.../20130121-200002-964/

Dieses Verzeichnis enthält jeweils ein Vollbackup, nutzt jedoch schon aus älteren Versionen bekannte und unveränderte Dateien mittels eines Hardlinks. Somit handelt es sich unter der Hand, um ein inkrementelles, sieht nach außen jedoch nach vollständig Backup aus. Diese Verzeichnisse enthalten zusammen ca. 4,3 Millionen Einträge und nehmen ca. 1,5TB Platz ein.
Für den Fall, dass nun auch mein kompletter Rechner ausfällt, habe ich eine weitere externe Festplatte im Schrank und synchronisiere diese circa wöchentlich mit dieser internen Sicherungskopie -- per rsync. Jetzt fängt es an spannend zu werden!
Wer rsync kennt, denkt sofort an

rsync -a --delete quelle ziel

fertig der Lack. Vielleicht noch an ein --delete um nicht mehr existente Dateien aus dem Ziel zu löschen - an mehr wahrscheinlich erst einmal nicht, oder? Zumindest war es bei mir so.Nun erwarte ich bei 1,5TB Daten mit 50GB neuen Daten eine Synchronisationszeit von (lahme Platte, ionice an, viele kleine Dateien etc. und viele andere ungünstige Faktoren) maximal 1h. Ist aber in der Schätzung schon grob übertrieben. Bei einer Dauertransferrate von ~25MB/s (möglicherweise viele kleine Dateien) dauert das ganze ca. 35 Minuten. Daher wunderte ich mich schon, daß nach 2 Stunden der Sync immer noch lief. Nochmal nachgeschaut in der Manpage und schon vorher --hard-links für das Einschalten der Synchronisation der Hardlinks gefunden:

rsync --archive --delete --hard-links quelle ziel

Damit sind die Hardlinks auch übertragen und wir können davon ausgehen, daß wir den gleichen Platzbedarf haben. Leider hat die Laufzeit meine Erwartungen gesprengt, zwar um den Faktor 5. Knappe 5Stunden hat der Sync gebraucht. Und der identische Aufruf gleich danach ohne Veränderung des Quellbackups genauso lange. Was war da los? Um es abzukürzen: Rsync weiß am Anfang noch nichts von den Hardlinks, denn es geht inkrementell rekursiv durch den Baum. Erst ganz am Ende, werden alle Kopien durch (erkannte) Hardlinks ersetzt. Damit haben wir jedes Mal ein unnötiges Kopieren aller Daten und aller Versionen in vollem Umfang. Das erklärt dann die Dauer. Mit 4,5 Stunden bei 1,5 TB sind das dann ~97MB/s. Das ist dann wieder ganz ordentlich.

Die Lösung brachte dann

rsync --archive --delete --hard-links --no-inc-recursive quelle ziel

Mit diesem Aufruf weiß nun rsync bereits vor dem eigentliches Kopieren, daß es sich um Hardlinks handelt und spart sich das Kopieren.

Abschließend bin ich bei dem gelandet und echt zufrieden:

$ time rsync --archive --progress  --hard-links --no-inc-recursive --delete --update --protect-args --progress --stats /backup .
building file list ... 
4245536 files to consider
backup/
backup/rsync.sh
         212 100%    0.00kB/s    0:00:00 (xfer#1, to-check=4245532/4245536)

Number of files: 4245536
Number of files transferred: 1
Total file size: 9387018802520 bytes
Total transferred file size: 212 bytes
Literal data: 212 bytes
Matched data: 0 bytes
File list size: 116819698
File list generation time: 267.316 seconds
File list transfer time: 0.003 seconds
Total bytes sent: 116819963
Total bytes received: 34

sent 116819963 bytes  received 34 bytes  142550.33 bytes/sec
total size is 9387018802520  speedup is 80354.55

real 15m10.993s
user 2m38.122s
sys 2m9.396s

Weitere Tipps:

• verwende --update bei lokalen Kopien
• verwende --protect-args wenn komische Dateinamen im Spiel sind (Leerzeichen, oder Sonderzeichen etc.)
• --delete wird nur aktiv beim Sync von Verzeichnissen, weil sonst die Argumentenliste expandiert wird und daher auf der Zielseite alte Dateien erhalten bleiben

Aufgrund der Tatsache, daß ich nicht alle Sachverhalte in der vollen epischen Breite darstellen wollte, ist jedem nochmal empfohlen, sich Zeit zu nehmen und nochmal richtig konzentriert zu lesen:

man rsync

Plausibilitätsprüfung

# Verzeichnisse weichen in den Größen ab (?), allerdings stimmen die Dateien und darauf kommt es ja an ;)
$ find /backup/ -type f -printf "hardlinks %n size %s name %p\n" | sed -e 's#name /backup#name backup#g' > find.backup.log
$ find backup/ -type f -printf "hardlinks %n size %s name %p\n" > find.backup-extern.log
$ diff --suppress-common-lines find.backup.log  find.backup-extern.log
$ md5sum find.backup.log
88da89b5d50d577c55c09692b9d19a46  find.backup.log
$ md5sum find.backup.log
88da89b5d50d577c55c09692b9d19a46  find.backup.log
# wer sich auftretende Unterschiede anschauen möchte
$ diff --suppress-common-lines find.backup.log  find.backup-extern.log
$ df -T | grep -i backup
/dev/sdd1                  ext4     1922858352 1559070956 266111796   86% /backup
/dev/sdc1                  ext4     1922858352 1560520788 264661964   86% /media/lars/EXTERN_BACKUP

Bie Ungenauigkeiten bitte gerne einen Kommentar hinterlassen.