Verschlüsseltes Backup mit Duply (Duplicity)

Um vertrauliche Daten auf potenziell nicht sicheren Speichern oder in der Cloud zu sichern, eignet sich Duplicity als Backup-Software. Duplicity erzeugt inkrementelle Backups und beherrscht neben der lokalen Sicherung eines Verzeichnisses in ein anderes Verzeichnis oder eine externe USB-Festplatte auch die Protokolle SSH/SCP, RSync, FTP, WebDAV, IMAP, Amazon S3 und noch ein Dutzend andere Clouds. Der Wrapper Duply erleichtert dabei die Bedienung.
Ich beschreibe in diesem Artikel die Installation und Konfiguration auf einem Ubuntu Server 16.04, die genauso auf Desktops und anderen Ubuntu-Versionen funktionieren sollte, wenn man die Versionsunterschiede z.B. von gnupg beachtet.
Gesichert werden soll im meinem Beispiel eine NAS-Station auf einer anderen NAS-Station.

Installation

Duply ist ein Wrapper für Duplicity und ich verwende ihn, da ich damit sehr einfache Scripdateien zu Steuerung erstellen kann und nicht mit den vielen Parametern von Duplicity arbeiten muss. Die Installation von Duply erfolgt mit

Für die Zugangsdaten zu den NAS-Stations und den Key zur Verschlüsselung lege ich mir im Verzeichnis /root ein Verzeichnis /.securedir an, auf das nur der Besitzer root Zugriff hat.

In diesem Verzeichnis werden die Dateien mit den Zugangsdaten zu den beiden NAS-Stations angelegt, die jeweils nur aus zwei Zeilen bestehen:

username=<Username auf NAS>
password=<Passwort auf NAS>

Ich verzichte hier auf die Variante, in der der Sicherungsserver Mitglied in einer Domäne ist. Ansonsten muss hier noch einer weiteren Zeile domain= der FQDN angegeben werden und auch an anderen Stellen berücksichtigt werden.
Diese jeweils zweizeiligen Credential-Files lege ich mit nano an und erstelle gleich die Verzeichnisse für die späteren Mountpunkte.

Die Mountpunkte müssen nun noch in /etc/fstab definiert werden.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
//<IP der NAS1>/<Pfad des Verzeichnisses> /mnt/NAS1 cifs credentials=/root/.securecred/.credNAS1 0 0
//<IP der NAS2>/<Pfad des Verzeichnisses> /mnt/NAS2 cifs credentials=/root/.securecred/.credNAS2 0 0

Da es sich bei den NAS-Stationen in diesem Beispiel um Geräte handelt, die mit SMB-Protokoll angesprochen werden, verwende ich zum Mounten den Samba-Client cifs, den man evtl. nachinstallieren muss. Danach kann man die Geräte mounten.

Sollte es Probleme beim Mounten geben, hilft die Analyse des Fehlers beim manuellen Mounten mit

Erhält man hier mit Ubuntu 18.04 einen Fehler Code -22, dann versucht man mit der Version 1.0 von cifs zu mounten, da ab 17.04 auf die cifs-Version 3.0 umgestellt wurde. Eine Fehler Code -13 ist übrigens ein Fehler in den Credentials für die NAS-Station.

Funktioniert das Mounten mit vers=1.0, muss die fstab geändert werden, indem auch dort auch mit cifs-Version 1.0 gemountet wird.

# <file system> <mount point> <type> <options> <dump> <pass>
//<IP der NAS1>/<Pfad des Verzeichnisses> /mnt/NAS1 cifs credentials=/root/.securecred/.credNAS1,vers=1.0 0 0
//<IP der NAS2>/<Pfad des Verzeichnisses> /mnt/NAS2 cifs credentials=/root/.securecred/.credNAS2,vers=1.0 0 0

Schlüssel erzeugen

Der Schlüssel zum Encrypten des Backups wird mit gnupg erzeugt. Das Verzeichnis /.gnupg wird dabei im Userverzeichnis erstellt (Durch das sudo -i sind wir immer noch als root angemeldet!).
Zusätzlich wird der gnupg-agent benötigt, der erst ab Version 2 automatisch mit installiert wird.

Dieser Befehl bezieht sich auf die Version vor 2.x.x von gnupg, bei den neuen Versionen muss der Befehl gpg –generate-full-key verwendet werden, um die Gültigkeit auf unbegrenzt zu setzen. Den am Ende der Erstellung ausgegebenen Namen des Keys benötigt man für die Konfiguration. -> Hier eine kleine Hilfe beim Umgang mit gpg.

Zur Kontrolle kann man die vorhandenen Schlüssel überprüfen:

WICHTIG: Die Schlüssel sollte man auf jeden Fall exportieren und an einem sicheren Ort (USB-Stick) aufbewahren!

Sonderfall: Bestehenden Schlüssel übertragen und verwenden

Um einen bereits verwendeten Schlüssel weiter zu verwenden, muss er aus seinem aktuellen Keyring exportiert und im Keyring des Backup-User importiert werden. Dazu holt man die ID mit gpg -k und exportiert und importiert.
Das gleiche Vorgehen gilt, wenn man den Backup-Server neu aufsetzen musste. Dann hat man hoffentlich den USB-Stick mit den ehemals exportierten Schlüsseln und importiert diese.

Nach dem Import muss die Gültigkeit und das Vertrauen für den Schlüssel angepasst werden.

Konfiguration

Für ein Backup muss zunächst eine Konfiguration mit Duply erzeugt werden (wir sind immer noch root!).

Damit legt Duply im Verzeichnis /root/.duply/<Name des Backups> eine Datei conf an, in der Key, dass zugehörige Passwort und weitere Parameter angegeben werden. Die grundlegenden Angaben sind darin

In der conf-Datei ist die Syntax beschrieben, die man z.B. zur Sicherungen in der Cloud oder bei Nutzung anderer Protokolle verwendet.

Sicherung

Dazu erstellt man am besten ein Script, das man dann mit CronTab ausführen kann (siehe weiter unten). Hier wurde mit duply BU_Doks create das Konfigurationsverzeichnis für Duply angelegt.

ssmtp sorgt hier dafür, dass die Log-Files per E-Mail versendet werden. Wie man ssmtp eintichtet, habe ich -> hier beschrieben.
Als Parameter habe ich hier nach BU_Doks_backup incr angegeben, wodurch eine inkrementelle Sicherung erstellt wird. Die erste Sicherung kann mit dem Parameter backup gemacht werden, danach sollte man wenn notwendig mit full neue komplette Backupsätze erstellen und diese mit incr dann weiter fortschreiben. Wird zu lange inkrementell gesichert, steigen die Zeiten bei Rücksicherungen an. Zudem ist man immer gut beraten zwei oder mehr Backupsätze zu haben.

Anzupassen ist nun auf jeden Fall in der conf-Datei noch die Zahl der aufzubewahrenden Sicherungen und wie lange inkrementell gesichert werden soll, bevor wieder ein neues vollständiges Backup erstellt wird. Dazu setzt man die beiden Parameter MAX_FULLBKP_AGE und MAX_FULL_BACKUPS.

Testen des Backups

Die wichtigste Aufgabe einer Backup-Software ist natürlich die Wiederherstellbarkeit der Daten zu garantieren. Das sollte man regelmässig überprüfen, indem man einige Daten zurücksichert. Einzelne Dateien werden mit folgendem Befehl zurückgesichert.

Dabei sollte der Restore-Pafd nicht mit dem Pfad der Originaldatei identisch sein und der Name unter dem die Datei im Zielverzeichnis geschrieben werden soll muss angegeben werden.
Einen kompletten Restore führt man so aus:

Das Zielverzeichnis test_20181012 darf nicht existieren, sonst bekommt man — Finished state FAILED ‚code 11‘ !

Automatisieren

Ein Cron-Job sorgt dafür, dass das Backup regelmässig ausgeführt wird. Dazu ruft man mit crontab -e die Steuerungsdatei auf und trägt das Backup-Script ein. Eine gute und ausführliche Erklärung findet sich z.B. -> hier.
Mit Duply können auch vor- und nachbereitende Scripte ausgeführt werden. Diese Scripte liegen im Konfigurationsverzeichnis des jeweiligen Backups mit dem Namen pre bzw. post.
Überalterte Backup-Sätze können mit dem Parameter full_verify_purge –force entfernt werden.

Probleme

Bei sehr grossen Sicherungsdatenmengen oder Netzwerkproblemen läuft hin und wieder die Festplatte voll. Im Beitrag -> Fehlermeldung von Duply und „apt-get update failed“ habe ich beschrieben, wie man den Fehler erkennt und behebt.