Backup in die Cloud
Nutzen Sie ihren (vielfach ungenutzt) vorhanden Speicherplatz bei Cloud-Anbietern für das persönliche Sicherheits-Backup außer Haus. Kür: Ein verschlüsselter USB-Stick mit einem beliebigen Live-Linux wie z.B. MX-Linux ermöglicht weltweiten Zugriff von einem beliebigen PC/Notebook.
Eines ist sicher, meine Daten sind sicher. So sicher, dass ich genau dann, wenn ich sie brauche, eventuell keinen Zugriff darauf habe: Im Urlaub im Ausland, wenn meine Papiere gestohlen wurden. Ein Stromausfall, der meinen Server außer Gefecht setzte, weil er nicht mehr fehlerfrei startet und ich keinen Zugriff auf den Fileserver mehr bekomme. Oder schlimmer: ein Unglück Zuhause wie Feuer oder Hochwasser, das meinen Server zerstört hat. Denkbar ist auch, dass Daten aus Versehen gelöscht wurden, was vielleicht nicht einmal bemerkt wurde.
Für letzteren Fall läuft auf meinem Fileserver drei Mal täglich ein Skript, welches ein Snapshot-Backup erzeugt, ohne wirklich viel Platz zu benötigen: Das allseits bekannte „rsync“ – das Schweizer Taschenmesser unter Sync- bzw. Kopierprogrammen – ist in der Lage, per Hardlink Kopien im Filesystem anzulegen, welchen keinen zusätzlichen Speicherplatz belegen. Es gibt natürlich viele Programme die Backups erzeugen können, aber ein stabiles selbstgeschriebenes Skript hat für mich immer noch einen gewissen Vorteil: Es funktioniert, überall. Ohne dass ein Programm-Update daran eventuell rumpfuscht, es nicht mehr unterstützt wird, eine neue Version ein Upgrade oder sogar eine Migration erfordern würde.
Dieser Artikel ist zugegebenermaßen entstanden, weil ich mein seit Jahr(zehnt)en installiertes System einer längst überfälligen Generalüberholung unterzog. Zur Verschlüsselung meiner persönlichen Daten kam EncFS zum Einsatz, welches 2014 in einem Audit einige Sicherheitslücken offenbarte, von denen einige immer noch nicht behoben sind (https://vgough.github.io/encfs/). Meine Recherche nach einer Alternative führte mich zu gocryptfs (https://github.com/rfjakob/gocryptfs-website). Gocryptfs auf der anderen Seite hielt (bisher) einem 2-Tages Audit stand. EncFS und gocryptfs verwenden das gleiche Konzept – ein virtuell ver- / entschlüsseltes Dateisystem wird durch einen Mount-Befehl in das Dateisystem eingehängt. Beide bieten eine „-reverse“ Option, welche unverschlüsselte Daten online in verschlüsselter Form in einem Dateisystem zur Verfügung stellt. Diese Option ist prädestiniert für das verschlüsselte Backup von Dateien, welche individuell und nur Bedarfsorientiert gesichert werden sollen.
Ein früherer Defekt einer nagelneuen 4TB Disk innerhalb der Garantie zog aufgrund des Hardware-Fehlers einen zwei Wochen dauernden Löschvorgang der Disk nach sich. In Kombination mit den Sicherheitsbedenken des Einsatzes von EncFS für Backup-Szenarien in Cloud-Speicher ist demzufolge die Vollverschlüsselung aller Festplatten und der Einsatz von gocryptfs naheliegend. Mein Backup-Skript kopierte die bisher im Dateisystem verschlüsselten Dateien 1:1 in die Cloud. Mit der Vollverschlüsselung der Festplatte stehen aber keine verschlüsselten Daten zum Kopieren mehr zur Verfügung. Gocryptfs erzeugt mit der Option -reverse ein virtuelles Filesystem, welches Dateien online verschlüsselt, ohne diese erneut auf der Festplatte zu speichern.
Das Passwort zum Ver- und Entschlüsseln der Disks sollte nicht auf der Festplatte selbst gespeichert werden, welche es entschlüsselt. Damit der Server bei einem Reboot trotzdem ohne Passwortabfrage automatisch hochfährt, wird das Passwort z.B. von einem USB-Stick gelesen. Dieses kann in einer Datei oder auch versteckt in den ersten ungenutzten Blocks eines Devices außerhalb des Dateisystems gespeichert sein. Da in meinem Boot-Vorgangs das Netzwerk schon zur Verfügung steht, wenn die Dateisysteme mit den User-Daten eingehängt werden, lese ich das Passwort per SSH von einem anderen Gerät ein, sodass der USB-Stick selbst nicht auf meinem Backup-Server erreichbar ist.
In Punkto Datensicherheit werden jetzt folgende Aspekte berücksichtigt:
- Mehrfache tägliche Datensicherung schützt vor versehentlichem Löschen
- Vollverschlüsselung schützt persönliche Daten auf den Festplatten
- Passwörter zum Entschlüsseln der Festplatten sind auf unabhängiges System bzw. Device wie USB-Sticks ausgelagert
- Backup der Daten liegt verschlüsselt in der Cloud vor
Wenden wir uns dem Thema Cloud-Backup zu. Wir haben alle erzwungenermaßen bereits Accounts bei mehreren Cloud-Providern wie z.B Google, Microsoft, T-Online um nur einige zu nennen. Viele bieten auch mehr oder weniger kostenlosen oder zusätzlichen Cloud-Speicher an, der selten Verwendung findet. Warum sollten wir also diesen allzeit und weltweit zur Verfügung stehenden Datenspeicher nicht dafür nutzen, unsere wichtigen Daten dort verschlüsselt abzuspeichern? Dem steht die durch dezentrale Zersplitterung entstehende Aufwand zur Beherrschung des zugrundeliegenden Datenchaos entgegen. Doch dem kann abgeholfen werden.
Idee ist, dass wir die vorhandenen unterschiedlichen Cloud-Speicher für ein Backup der wichtigen persönlichen Daten nutzen. Dieser lässt ich normalerweise über Protokolle wie webdav oder SSH/SFTP auf dem eigenen Rechner einbinden. Zur Synchronisierung der Daten in die Cloud kommt rsync zum Einsatz. Entweder in Kombination mit SSH, oder per webdav werden die Daten per gocryptfs verschlüsselt und in die Cloud kopiert. Die benötigten Tools hierfür stehen alle als kostenlose Standard-Tools zur Verfügung: webdav, ssh, shell-skript, du, mount, find, rsync und gocryptfs.
Um die in der Cloud verschlüsselten Daten zu lesen, werden diese per webdav oder sshfs auf einem Rechner gemountet und anschließend mittels gocryptfs wieder entschlüsselt in das lokale Dateisystem eingebunden. Das kann sogar auf einem Live-Linux und damit auch auf einem USB-Stick erfolgen, den ich am Schlüsselbund immer parat habe.
Gocryptfs ist einfach zu benutzen. Man verschlüsselt ein vorhandenes Verzeichnis ‚SourceDir‘ wie folgt:
$ mkdir Encrypted $ gocryptfs -reverse -init -config ConfigFile SourceDir $ gocryptfs -reverse -config ConfigFile SourceDir Encrypted
Im ‚Encrypted‘ Verzeichnis sind jetzt alle Daten aus ‚SourceDir‘ verschlüsselt abgebildet, eine Änderung der verschlüsselten Dateien selbst ist nicht möglich (‚Encrypted‘ ist als Abbild von ‚SourceDir‘ nur ReadOnly).
Die Dateien aus ‚Encrypted‘ können entschlüsselt werden mit:
$ mkdir Decrypted $ gocryptfs -config ConfigFile Encrypted Decrypted
Die Daten stehen jetzt wieder entschlüsselt im Verzeichnis ‚Decrypted‘ zur Verfügung.
Struktur, der natürliche Feind von Chaos
Trivial ist anders: Verteile individuelle Verzeichnisse von unterschiedlichen Stellen zu unterschiedlichen Cloud-Anbietern. KISS – „Keep it small and simple“ hilft auch hier, Ordnung ins vermeintliche Chaos zu bringen, und die angestrebte Usability und Stabilität der Lösung herzustellen.
Wie sieht die Lösung aus?
- Der Cloud-Speicher wird per SSH oder WebDav eingebunden
- Die individuellen Daten-Verzeichnisse werden temporär in einem Backup-Verzeichnis gebündelt
- Das Backup-Verzeichnis wird verschlüsselt, virtuell durch gocryptfs --reverse
- Das verschlüsselte Verzeichnis wird mit rsync in den Cloud-Speicher synchronisiert
Der Mount-Befehl stellt mittels der Optionen –bind und -ro sämtliche Daten-Verzeichnisse in einem Backup-Verzeichnis zusammen. Gocryptfs verschlüsselt dieses Verzeichnis mit der Option –reverse. Rsync kopiert schließlich sämtliche Dateien direkt in den Cloud-Speicher (-e ssh), oder in das per WebDav eingebundene Cloud-Verzeichnis.
Normalerweise sind die persönlichen Daten aller Nutzer eines Servers über mehrere Verzeichnisse verstreut. Außerdem müssen nur einige Verzeichnisse in die Cloud gesichert werden. Eine einfache Konfiguration für ein zentrales CryptFS-Backup-Cloud Skript bildet die Grundlage für Usability und Stabilität (robust und wartungsarm) der Lösung. Da nur Standard-Protokolle und Programme verwendet werden, ist die Lösung extrem portabel und kann z.B. auf einem Rasperry, einem Linux-SAT-Receiver und anderen vorhandenen Devices implementiert werden.
Die Cloud-Backup Konfiguration muss folgende Informationen verknüpfen:
- Cloud-Speicher mit zugehörigem Account
- lokale Datenverzeichnisse der Benutzer
Für jeden Anwender bzw. dessen Accounts bei Cloud-Anbietern wird definiert, welche Verzeichnisse in dessen Cloud-Speicher synchronisiert werden sollen. That’s it – sounds easy, is easy – and rock stable!
Die individuellen Konfigurationen sind in sehr einfachen (Shell-) Skripten z.B. unter /etc/cryptfs-backup-cloud hinterlegt. Konfiguration der Backup-Verzeichnisse, hier am Beosipel MagentaCloud von t-online für Benutzer jens:
$ mkdir /etc/cryptfs-backup-cloud
$ cat > /etc/cryptfs-backup-cloud/t-online_neobiker <<EOF
#!/bin/sh
# my cryptfs-backup-cloud script
# rsync an encrypted filesystem to cloud storage
[ -z "$RSYNC_CRYPT" ] && RSYNC_CRYPT=/usr/local/sbin/rsync-gocryptfs-cloud
# -----------------------------------------------
provider=t-online # provider name
WEBDAV=https://webdav.magentacloud.de/ # URL of provider cloud storage
SSH_HOST=
login=neobiker
#-----------------------------------------------
user=neobiker
#$RSYNC_CRYPT -p $provider -s $SSH_HOST -l $login -u $user \
$RSYNC_CRYPT -p $provider -w $WEBDAV -l $login -u $user \
-r /srv/daten \
-x Downloads \
home/neobiker-daten \
home/neobiker \
EOF
Eine Namenskonvention wie <provider>_<login> bringt etwas Übersicht bei mehreren Providern, Accounts und Benutzern:
$ ls /etc/cryptfs-backup-cloud t-online_neobiker t-online_otherUser 1blu_homepage_neobiker 1blu_double_neobiker
Ein Hilfsprogramm liest in Zusammenspiel mit einem Cronjob alle Konfigurationen und startet die Backups nacheinander:
$ cryptfs-backup-cloud [-c] [Konfiguration1] [Konfiguration2] […]
Die Option -c (check) ermittelt per „du -csh“ den belegten Speicherplatz aller konfigurierten Verzeichnisse aus, wobei -x einzelne Verzeichnisse vom Backup ausschliesst. Die Gesamtsumme der fürs Backup definierten Verzeichnisse hilft beim initialen Verteilen der Datenmengen auf die verschiedenen Cloud-Speicher.
$ cryptfs-backup-cloud -c t-online_neobiker
disc usage in configuration t-online_neobiker:
19G home/neobiker-daten
108K home/neobiker
19G insgesamt
thereof excluded:
8,5G home/neobiker-daten/Downloads
9,5M home/neobiker-daten/Documents/Downloads
8,5G insgesamt
Alle anderen optionalen Parameter werden transparent an das Backup Skript ‚rsync-gocryptfs-cloud‘ durchgereicht. rsync-gocryptfs-cloud und seine Parameter:
$ rsync-gocryptfs-cloud [-t] [-v] [-d] [-delete] -p <provider> (-w webdav | -s ssh_host | -m mount_point) -l <login> -u <user> [-b <mybackup>] [-x exclude1> [-x exclude2]…] -r <root dir> <dir1> <dir2> <…>
Die Option -t (test) führt einen Testlauf („dry-run“) aus, es werden keine Dateien synchronisiert. Die Option -v (verbose) listet alle von rsync identifizierten Dateien auf, -d (debug) gibt zusätzliche Informationen des Skripts aus, wie z.B. den genauen Aufruf von rsync bzw. find samt den identifizierten Dateien für den anstehenden Backuplauf. Mit -x (exclude) können einzelne Verzeichnisse vom Backup ausgeschlossen werden, -b (backup) bezeichnet das Verzeichnis, in welches die Daten synchronisiert werden, voreingestellt ist „mybackup“. Die Option -m wurde am Schluss hinzugefügt, um das verschlüsselte Backup auch einfach auf einen beliebigen lokalen Mount-Point speichern zu können, z.B. eine externe Festplatte. Ist diese Option definiert, wird kein Remote-Backup gestartet, sondern stattdessen nur ein „lokales“ Backup. So braucht man die normale Remote-Konfiguration nicht anpassen, und kann trotzdem auf einem lokalen Laufwerk das verschlüsselte Backup zusätzlich sichern.
Die Option –delete teilt rsync mit, fehlende (gelöschte) Dateien im Zielsystem auch zu löschen. Sofern ein Zeitstempel des letzten erfolgreichen Backups vorliegt wird kein Fullbackup initiiert. In diesem Fall ermittelt der Befehl find im lokalen Filesystem alle Dateien, welche einen neueren Zeitstempel haben und sendet diese Liste an rsync. Die Option -f (full) initiiert ein Fullbackup trotzdem. Dies stellte sich als sinnvoll heraus, da webdav als Filesystem denkbar schlecht für rsync und dessen Standard Methoden zum Identifizieren von Dateiänderungen geeignet ist. Beim Kopieren von Dateien bleiben Zeitstempel nicht erhalten weshalb die Prüfsumme von Dateien verwendet wird. Die delta-x-fer Option arbeitet bei verschlüsselten Dateien und mit webdav nicht performant. Deshalb bevorzugt das Skript, sofern möglich, die Nutzung von rsync via ssh und verwendet die Option –whole-file. Apropos find im lokalen Filesystem: Hiermit werden natürlich keine Dateien gefunden, welche nachträglich mit einem älterem Zeitstempel in ein Backup-Verzeichnis verschoben wurden (alter Zeitstempel bleibt erhalten). In diesem Fall ist die Option -f für ein Fullbackup einmalig anzuwenden.
Installation und Beispiele im Detail:
/etc/cryptfs-backup-cloud/* # individuelle Backup Konfigurationen /usr/local/sbin/cryptfs-backup-cloud # Hilfsskript, liest Konfigurationsfiles /usr/local/sbin/rsync-gocryptfs-cloud # Backup Skript
Das Passwort zum Ver-/entschlüsseln der Daten liest das Skript standardmäßig aus der Datei /etc/GoCryptFS.PWD. Auf Debian Systemen installiert man gocryptfs am besten aus dem Testing repository, andernfalls ist die Version veraltet. Sshfs benutze ich als Alternative für Cloud-Speicher, welche mir nur ssh aber kein webdav anbieten. Benötigt wird das vom Backup-Skript nicht, sondern nur, wenn ich solchen Cloud-Speicher entschlüsselt wieder einbinden möchte.
$ apt-get install davfs2 gocryptfs rsync sshfs $ cp cryptfs-backup-cloud rsync-gocryptfs-cloud /usr/local/sbin $ cd /usr/local/sbin $ chmod +x cryptfs-backup-cloud rsync-gocryptfs-cloud
Das wars auch schon mit der Installation, jetzt muss das Backup nur noch durch die Backup-Konfigurationsfiles für jeden Benutzer konfiguriert werden.
In den beiden Skripts cryptfs-backup-cloud (Hilfsskript) und rsync-gocryptfs-cloud (Backup Skript) können am Anfang individuelle Konfigurationen angepasst werden. Erwähnenswert ist hier die Variable CHECK_LIMIT. Überschreitet die Anzahl geänderten Dateien seit dem letzten Backuplauf diesen Wert, bricht das Skript mit einer Warnung ab – ein einfaches Mittel z.B. gegen einen Locker-Schädling, damit dieser nicht gleich das Backup mitverschlüsselt. Der einmalige Aufruf mit der Option -f für ein Fullbackup hilft hier, nach einer vorherigen Prüfung (z.B. Optionen -t -v -d) warum das Limit überschritten wurde, das trotzdem alles gesichert wird.
Standardmäßig verwendet das Skript folgende Dateien und Verzeichnisse:
/etc/GoCryptFS.PWD # GoCryptFS Passwort /etc/cryptfs-backup-cloud/ # Backup Konfigurationen /mnt/mybackup-cloud/<provider>/<login> # assemble backup-dirs /mnt/mybackup-cloud/gocryptfs/<provider>/<login> # encrypted dir /mnt/webdav/<provider>/<login> # webdav Cloud-Storage /mnt/webdav/decrypt/<provider>/<login> # decrypted <mybackup> dir
Die Konfiguration der Cloudspeicher mit Webdav erfolgt in den beiden Dateien davfs2.conf und secrets im Verzeichnis /etc/davfs2. Der Webdav Cloudspeicher ist in der Datei secrets und /etc/fstab zu konfigurieren:
$ cat /etc/secrets # T-Online Magentacloud /mnt/webdav/t-online/neobiker <Login@t-online.de> "<passwort>"
Zugehöriger /etc/fstab Eintrag zum mounten der Cloud-Speicher:
$ grep davfs /etc/fstab https://webdav.magentacloud.de/ /mnt/webdav/t-online/neobiker davfs rw,noauto,uid=neobiker,gid=User-neobiker,file_mode=777,dir_mode=777 0 0
Damit kann die Konfiguration und der Zugriff auf den Cloudspeicher getestet werden, nachdem noch ein Passwort zur Verschlüsselung definiert wird:
Setze ein Passwort für gocryptfs:
$ echo > /etc/GoCryptFS.PWD „mein GoCryptFS Passwort“ $ chmod 660 /etc/GoCryptFS.PWD
Die Backup-Konfiguration wurde schon weiter oben definiert. Wieviel Speicherplatz die Konfiguration beinhaltet prüft man mittels:
$ cryptfs-backup-cloud -c t-online_neobiker
disc usage in configuration t-online_neobiker:
19G home/neobiker-daten
108K home/neobiker
19G insgesamt
thereof excluded:
8,5G home/neobiker-daten/Downloads
9,5M home/neobiker-daten/Documents/Downloads
8,5G insgesamt
Teste das Backup-Skript und den Cloudspeicher Zugriff:
$ cryptfs-backup-cloud -t t-online_neobiker
bind t-online/jens: home/neobiker-daten
bind t-online/jens: home/neobiker
2020-05-01 13:01 : (webdav) start neobiker
rsync-crypt to t-online: neobiker started full initial sync
/sbin/umount.davfs: warte bis mount.davfs (PID 12852) die Dateien im Cache
gesichert hat .. OK
2020-05-01 13:01: cryptfs-backup-cloud finished
Konfiguration eines Cronjob, der täglich um 01:31 Uhr das Backup startet:
$ crontab -e ### Cloud-Server Remote Backup 31 01 * * * /usr/local/sbin/cryptfs-backup-cloud
Nützliche Aliase für die Standardkonfiguration des Skriptes in ~/.bash_aliases:
alias mount_t-online_neobiker='mount /mnt/webdav/t-online/neobiker' alias mountCFS_t-online_neobiker_CFS='gocryptfs -passfile /etc/GoCryptFS.PWD -config /mnt/mybackup-cloud/gocryptfs/.config/t-online_neobiker.reverse.conf /mnt/webdav/t-online/neobiker/mybackup /mnt/webdav/decrypt/t-online/neobiker' $ webdav_t-online_neobiker # mountet den MagentaCloud Speicher nach /mnt/webdav/t-online_neobiker $ webdav_t-online_neobiker_CFS # entschlüsselt das Crypted-Backup unter /mnt/webdav/decrypt/t-online_neobiker
Anwendungsfall 1: Homeverzeichnisse per WebDav in MagentaCloud von T-Online sichern, wurde im Artikel ausgeführt Verzeichnis von T-Online mounten (/etc/fstab Eintrag ist vorhanden, oder alias verwenden):
$ mount /mnt/webdav/t-online/neobiker/
Backup Verzeichnis mounten und Datei wiederherstellen (verwendet obigen alias):
$ mountCFS_tonline_neobiker $ cp /mnt/webdav/decrypt/t-online/neobiker/home/neobiker-daten/Documents/Cryptfs_Artikel.docx .
Anwendungsfall 2: Es wird rsync direkt mittels SSH zur Synchronisation der Dateien benutzt. SSHFS wird als Alternative zu webdav verwendet, um den Cloud-Speicher zu mounten:
alias sshfs_1blu='sshfs <login>@<webhosting_host>.1blu.de: /mnt/webdav/1blu/<login>/'
Konfiguration eines SSH Cloud-Speicher bei 1Blu:
$ cat /etc/cryptfs-backup-cloud/1blu_homepage_neobiker
#!/bin/sh
# my cryptfs-backup-cloud script
# rsync an encrypted filesystem to cloud storage
[ -z "$RSYNC_CRYPT" ] && RSYNC_CRYPT=/usr/local/sbin/rsync-gocryptfs-cloud
#-----------------------------------------------
provider=1blu # provider name
WEBDAV= # URL of provider cloud storage
SSH_HOST=<webhosting_host>.1blu.de
login=<1blu login>
#-----------------------------------------------
user=neobiker
#$RSYNC_CRYPT -p $provider -w $WEBDAV -l $login -u $user \
$RSYNC_CRYPT -p $provider -s $SSH_HOST -l $login -u $user \
-r /srv/daten \
data/homepage \
Beispiel des Speicherns dieses Artikels mit den Optionen -v(erbose) und -d(ebug): Man sieht die Aufrufparameter von mount, find und rsync und den letztlichen Aufruf mit allen Parametern:
$ cryptfs-backup-cloud -d -v t-online_neobiker
2020-05-22 17:10: rsync-gocryptfs-cloud assemble for t-online: neobiker
bind t-online/jens: home/neobiker-daten
bind t-online/jens: home/neobiker
2020-05-22 17:10: mount -t davfs -o uid=neobiker,gid=User-neobiker,file_mode=770,dir_mode=770 https://webdav.magentacloud.de/ /mnt/webdav/t-online/neobiker
2020-05-22 17:10 : (webdav) start neobiker
2020-05-22 17:10: find /mnt/mybackup-cloud/t-online/neobiker/home/ -path */temp -prune -o -path */Temp -prune -o -path */Downloads -prune -o -path */Downloads -prune -o -newer /mnt/mybackup-cloud/t-online/neobiker/.backup -type f -print
Files to sync: 1 (rm /mnt/mybackup-cloud/t-online/neobiker/.backup for full backup)
find -newer:
home/neobiker-daten/Documents/Cryptfs_Artikel.docx
rsync to t-online: neobiker started
2020-05-22 17:10: nice rsync --files-from=- --whole-file --bwlimit 1.5m --ignore-errors --exclude-from /var/run/rsync_exclude_6764 --exclude temp --exclude Temp --exclude Downloads --exclude Downloads --verbose --stats --checksum /mnt/mybackup-cloud/gocryptfs/t-online/neobiker/ /mnt/webdav/t-online/neobiker/mybackup/
find -newer:
XdLfx5-75ieq8bMIYGeP7Q==/-eFqsSvk2rnYpMpT8PCxvA==/ZrfIzMtF9hLwBx7WozrLDg==/1UsMcd37sCt4lHaTK2Nw_G1Ei7fo5mRjfi00xJ2GbQc=
XdLfx5-75ieq8bMIYGeP7Q==/-eFqsSvk2rnYpMpT8PCxvA==/ZrfIzMtF9hLwBx7WozrLDg==/gocryptfs.diriv
building file list ... done
XdLfx5-75ieq8bMIYGeP7Q==/-eFqsSvk2rnYpMpT8PCxvA==/ZrfIzMtF9hLwBx7WozrLDg==/1UsMcd37sCt4lHaTK2Nw_G1Ei7fo5mRjfi00xJ2GbQc=
Number of files: 5 (reg: 2, dir: 3)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 82,656 bytes
Total transferred file size: 82,640 bytes
Literal data: 82,640 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.592 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 82,976
Total bytes received: 31
sent 82,976 bytes received 31 bytes 33,202.80 bytes/sec
total size is 82,656 speedup is 1.00
2020-05-22 17:10: rsync to t-online: jens (ok)
/sbin/umount.davfs: warte bis mount.davfs (PID 7018) die Dateien im Cache
gesichert hat .. OK
2020-05-22 17:10: cryptfs-backup-cloud finished