weidner/computer/sysadmin/

Backup mit duply

Ich sichere meine Server oft mit duply, einem Skript, das hilft, Daten über das Netz oder lokal zu sichern. Das kann ich mit Dutzenden anderen Skripts und Programmen auch, mal mehr und mal weniger komfortabel. Das Besondere an duply ist aber, dass ich die Dateien außerhalb meines Einflußbereiches speichern kann, ohne mir Sorgen um meine Daten machen zu müssen, denn duply verwendet GnuPG um die Daten zu schützen.

Dabei kann ich auf die unterschiedlichsten Mechanismen, wie zum Beispiel FTP, SMB, SSH, rsync, zurückgreifen, um die Daten an ihren Speicherort zu bringen.

Aus diesem Grund verwende ich duply am häufigsten, um Daten off-site zu lagern. Zum Beispiel die Konfiguration meiner Server zu Hause via WebDAV auf angemietetem Webspace oder Konfiguration und Daten meines Webservers auf vom Provider bereitgestelltem Platz.

Dabei ist duply schnell eingerichtet, wenn man vom Erzeugen des GPG-Schlüssels absieht, das auf einer virtuellen Maschine schon mal mehrere Stunden dauern kann. Dann erzeuge ich den Schlüssel doch besser auf einem Rechner mit genügend Zufall an Bord.

Installieren

Die Installation ist sehr einfach. Als erstes besorge ich duply, das geht am bequemsten aus den Repositories meiner Linux-Distribution. Andernfalls müsste ich die zusätzlich benötigte Software selbst zusammensuchen.

Auf Debian und davon abgeleiteten Linux-Distributionen geht das mit:

# apt install duply

Auf Fedora verwende ich:

# dnf install duply

Damit bin ich eigentlich fertig mit der Installation. Je nachdem, wie ich das Backup kopiere, benötige ich vielleicht noch das passende Programm dafür.

GPG Schlüssel

Gleichzeitig mit der Installation oder auch schon vorher fange ich an, den GPG-Schlüssel zu generieren:

# gpg --gen-key

Dabei verwende ich die folgenden Parameter bei den Rückfragen von gpg:

1            (RSA)
4096         (Bits)
0            (does not expire)
y

Den Namen des Schlüssels, Kommentar und E-Mail wähle ich entsprechend dem Rechnernamen nach folgendem Schema:

Host $name (Backup) < backup @ mamawe.net >

Je nach vorhandener Entropie und der Geschwindigkeit, mit der die nötige Menge davon für die Zufallszahlen bereitsteht, kann es jetzt etwas länger dauern.

Konfigurieren

In der Zwischenzeit kann ich duply konfigurieren. Dazu lasse ich mir zunächst Templates für die Konfigurationsdateien generieren.

Tipp:

Will ich die Backup-Konfiguration zentral unter /etc/ ablegen, muss ich das Verzeichnis /etc/duply/ vor dem ersten Aufruf von duply anlegen. Andernfalls landet die Konfiguration in $HOME/.duply/, das heißt für root in /root/.duply/.

# mkdir /etc/duply
# duply $name create

Ich verwende für $name meist den Namen des Rechners, der gesichert werden soll. Prinzipiell kann ich auch mehrere Konfigurationen für duply mit jeweils verschiedenem Namen anlegen.

Duply erzeugt mir nun das Verzeichnis /etc/duply/$name/, dass die zwei Dateien conf und exclude enthält, die ich anpassen muss.

conf

Die Datei conf enthält ein Template für die Konfiguration.

Die wichtigsten Variablen darin sind:

Es gibt noch etliche weitere Variablen, die ich anpassen kann. Diese sind in den Kommentaren im Template erklärt.

exclude

Die Datei exclude soll steuern, welche Dateien gesichert werden und welche nicht. Dabei bedeutet + am Anfang der Zeile, dass das nachfolgende Verzeichnis gesichert werden soll. Ein - am Anfang der Zeile bedeutet, die nachfolgend beschriebenen Verzeichnisse und Dateien sollen ausgelassen werden.

Bei mir sieht die Datei meist etwa so aus:

+ /etc
+ /home
+ /root
+ /usr/local
+ /var/local
- **

Achtung! Am Ende der Zeilen darf kein Slash ('/') stehen, da ansonsten nur Verzeichnisse und keine Dateien gesichert werden.

pre

Existiert eine ausführbare Datei namens pre im Konfigurationsverzeichnis, so führt duply diese aus, bevor es die Dateien sichert. Das ist eine gute Gelegenheit backup-mysql aufzurufen, um einen aktuellen Abzug der Datenbank in der Sicherung zu haben.

Bei mir sieht diese Datei etwa so aus:

#!/bin/sh

LOCALDIR=/etc/local

test -d $LOCALDIR || mkdir -p $LOCALDIR
if test -d $LOCALDIR; then
  dpkg --get-selections > $LOCALDIR/dpkg-selections
fi

[ -x /usr/local/sbin/backup-mysql ] && su backup -c /usr/local/sbin/backup-mysql

exit 0

Mit dpkg --get-selections lege ich eine aktuelle Liste der installierten Software an, so dass ich den Rechner aus einer Sicherung leichter wiederherstellen kann.

Das Programm backup-mysql rufe ich mit su auf, damit die Datenbank nicht als root gesichert wird, während duply für die Systemsicherung unter UID 0 läuft.

Testen

Bin ich mit der Konfiguration fertig und ist der GnuPG-Schlüssel generiert, sichere ich damit erstmalig:

# duply $name backup_verify

Mit

# duply $name status

sehe ich anschließend, ob alles glatt ging. Zusätzlich kann ich mir die Liste der gesicherten Dateien mit

# duply $name list

ausgeben lassen.

Funktioniert das Backup von Kommandozeile, kann ich es in die crontab eintragen:

32 2 * * 1-6 root test -x /usr/bin/duply && /usr/bin/duply $name backup_verify_purge --force >> /var/log/duply-last.log 2>&1
32 2 * * 0 root test -x /usr/bin/duply && /usr/bin/duply $name full_verify_purge --force >> /var/log/duply-last-full.log 2>&1

Damit bekomme ich pro Woche einen Vollbackup und sechs inkrementelle Backups.

Restore

Das Wiederherstellen der Daten ist eben so einfach wie die Sicherung. Insbesondere kann ich die Daten auf jedem Rechner wieder herstellen, der Zugang zum TARGET und das zuvor gesicherte Duply-Verzeichnis hat.

Der Aufruf ist:

duply $name restore $zielverzeichnis

beziehungsweise, falls ich den Stand von einem bestimmten Datum haben will:

duply $name restore $zielverzeichnis $alter

Bevor ich das aufrufe, stelle ich sicher, dass ich unter $zielverzeichnis genügend Platz habe.

Abschließende Hinweise

Ich verwende aus zwei Gründen für jeden Server einen eigenen GPG-Schlüssel:

  1. Wird der GPG-Schlüssel eines Servers kompromittiert, so sind die Backups der anderen Server davon meist nicht betroffen.

  2. Habe ich versehentlich die Variable TARGET in der Datei conf bei zwei Servern gleich gesetzt, bekomme ich das recht schnell mit, weil GPG die Dateien des jeweils anderen Servers nicht entschlüsseln kann.

Ein wichtiger Punkt, über den ich mir Gedanken machen muss ist das Verzeichnis /etc/duply/$name/ und sein Inhalt.

Im Normalfall brauche ich mich nicht um dieses Verzeichnis zu kümmern, duply legt dort beim ersten Sichern automatisch eine Kopie des verwendeten Schlüssels (public, private) ab. Solange der Server läuft, holt sich duply von dort alle benötigten Informationen und den Schlüssel.

Ist der Server jedoch defekt, komme ich ohne den Inhalt dieses Verzeichnisses nicht an die Backups heran. Darum muss ich das Verzeichnis nebst Inhalt vom Server kopieren und an einer sicheren Stelle verwahren.

Sicher bedeutet hier einerseits, dass es mir nicht verloren gehen darf und andererseits, dass es keinem Unbefugten in die Hände fallen darf.

Damit wäre das wichtigste zu duply gesagt, die Man-Page enthält noch viele weitere Informationen.

Auch im Thomas-Krenn-Wiki findet sich eine Anleitung zu duply.

Updates

Posted 2017-08-30
Tags: