Allgemein

Wir haben jetzt eine Basisinstallation von Duply / Duplicity durchgeführt und diese in VZDump integriert.
Es gibt aber noch einige Anmerkungen und Optimierungen welche durchgeführt werden können.

VZDump Erfolgsbericht

Leider achtet VZDump bei der Anzeige von Erfolg und Misserfolg in der aktuellen ProxmoxVE Version (4.3-9) nicht darauf ob ein hook Script erfolgreich war oder nicht.
Aus diesen Grund muss hier manuell geprüft werden oder etwa ein Nagioscheck etabliert werden um sicher zu stellen das das Duply Backup erfolgreich war.

VZDump Compressor

Standartmäßig wird von ProxmoxVE eingesetzt und empfohlen lzo als Komprimierung zu nutzen, lzo ist leider was incrementelle Backups betrifft nicht die beste Wahl und führt zu schlechten ergebnissen.
Theoretisch optimal ist keine Kompression einzusetzen und die RAW tar/vma files zu nutzen, dass Problem hierbei ist oft der enorme Platzverbrauch auf dem Backupstorage und auch wenn dieser vorhanden ist sollte getestet werden ob das Ergebnis wirklich besser ausfällt gesehen auf die gesamte Backupperformance.
Als bester Kompromiss hat sich gzip herausgestellt da VZDump mit den Flag „rsyncable“ Komprimiert führt das zu kleinen incrementellen Backups.
Nachteil von gzip ist die lange Komprimierungsdauer, dies kann jedoch durch hilfe von „pigz“ gelöst werden und wird bei uns schon lange produktiv eingesetzt.
pigz ist ein Multicore gzip Komprimierungstool es werden also mehrere Kerne (1er bei gzip normal) zur Komprimierung genutzt, schon mit 4 Kernen kann der Standartkompressor lzo damit überholt werden.

Einrichten kann man pigz wie folgt:

apt-get install pigz

Folgende Zeile muss geändert werden:

#pigz: N:

pigz: 1

Das sagt VZDump nutze pigz und nicht gzip zum Komprimieren, eine 1 bedeutet nutze die hälfte der verfügbaren Kerne. (VZDump Doku).

Duply Konfiguration

In der Duply Konfiguration gibt es einige Punkt die geändert werden können je nach vorliegenden Backupplan.

Backup Zeiten Anzahl etc.
Diesen Punkt muss jeder individuell für sich ausarbeiten, ich empfehle dazu die Duply Dokumentation zu lesen (Duply Doku)
Um das Backupverhalten zu steuern müssen die Parameter in der Duply Konfiguration (/etc/duply/pve_$HOSTNAME/conf) und die Variable „$duply_backup“ in der /opt/vz_hook.pl angepasst werden.

Volumesize
In der Duply Konfiguration Zeile:

#VOLSIZE=50
#DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "

Hierdurch wird bestimmt wie groß jeweils ein Volume sein soll, der sinn besteht darin wenn z.b. beim Uploaden des Backups über eine langsame Internetverbindung die Verbindung abbricht müssen nicht mehrere Gigabyte neu übertragen werden sondern nur ein Volume.
Standartmäßig steht dieser Wert auf 25MB was gerade bei großen VM´s zu tausenden Volumes führen kann.
Dieser wert ist natürlich individuell an hand der Gegebenheiten zu bestimmten, aber in unseren Setup haben sich 1000 als guter Wert herausgestellt.
Bei Bandbreiten ab 50Mbit gehen damit höchstens 3 Minuten verloren wenn es mal zu Problemen kommen sollte, das Dateisystem wird nicht mit zu vielen Dateien überschwemmt und es kann anhand der Volumeanzahl schnell auf den Speicherverbrauch geschlossen werden.

GPG und Kompression
GPG Verschlüsselung nutzt gleichzeitg Komprimierung und dieses Verhalten kann nicht abgestellt werden, da die VZDump Backups bereits Komprimiert sind (ausser RAW) sollte folgende Zeile geändert werden:

#GPG_OPTS=''

GPG_OPTS='--compress-algo=bzip2 --bzip2-compress-level=1'

Damit wird auf der niedrigsten Stufe komprimiert und etwas Performance und Zeit herausgeholt werden.

Wenn hingegen keine Verschlüsselung gewünscht ist kann die Komprimierung auch ganz deaktviert werden in dem GPG_KEY auf disabled gesetzt wird und ein Parameter in die Duply Konfiguration eingetragen wird.

GPG_KEY='example'

GPG_KEY='disabled'

echo 'DUPL_PARAMS="$DUPL_PARAMS --no-compression "' >> /etc/duply/pve_$HOSTNAME/conf

Async Upload
Per default erstellt Duplicity ein Volume im TMP Verzeichnis und läd dieses dann hoch, dass bedeutet in der Zeit wo ein neues Volume erstellt wird findet kein Upload statt.
Damit die Bandbreite aber optimal Ausgenutzt wird gibt es den Parameter „–asynchronous-upload“ welcher den Upload async im Hintergrund stattfinden lässt.
Laut Duplicity Doku ist dieser Parameter experimental, wir konnten bis jetzt noch keine negativen Erfahrungen damit machen und setzen es auf verschiedenen Setups ein.

echo 'DUPL_PARAMS="$DUPL_PARAMS --asynchronous-upload "' >> /etc/duply/pve_$HOSTNAME/conf

Blocksize (nur incrementelle Backups)
Blocksize ist in Duplicity ein Wert welcher herangezogen wird um Source und Remote Datei auf unterschiede zu untersuchen, dieser wird von Duplicity berechnet aber es gibt eine Höchstgrenze von default 2048.
Man kann es sich so vorstellen das Duplicity bei einen incrementellen Backup die beiden Dateien nicht Byte für Byte untersucht und diese unterschiede dann im incrementellen Backup speichert sondern größere Blöcke heranzieht. Wenn sich in so einen Block etwas geändert hat wird in ein Signaturfile geschrieben das sich etwas in diesen Block geändert hat und der Block in das incrementelle Backup aufgenommen.

Dieses verhalten mit kleiner Blocksize ist bei einen z.b. normalen Fileserver mit vielen Verzeichnissen und Dateien optimal da sich hier wahrscheinlich 99% der Dateien nicht ändern und damit überhaupt nicht incrementell Gesichert werden müssen.
Steht aber im Kontrast zu unseren Backup der VM Dump´s welche sich jedes mal ändern und sehr sehr groß sind.

Meine Empfehlung ist daher den Wert „max-blocksize“ auf 262144 zu ändern, im Produktivbetrieb konnten wir damit nur einen minimalen Anstieg der incr. Backupgröße beobachten dafür ist die laufzeit der incr. Backups aber deutlich Reduziert.

echo 'DUPL_PARAMS="$DUPL_PARAMS --max-blocksize 262144 "' >> /etc/duply/pve_$HOSTNAME/conf