Verwendung der mitgelieferten Backup-Funktion + Benchmark

  • Ich denke dies könnte interessant sein für Admins einzelner Server mit pd-admin und welche ausschließlich auf die mitgelieferte Backup-Funktion setzen (müssen).


    Die Sicherung mittels tar + gzip benötigt recht viele Ressourcen. Speziell bei kleineren Servern oder größeren Datenmengen kann dies für viel Last sorgen. Eines der Probleme ist z.B. dass tar + gzip nur Single Core fähig ist. Auch lässt sich meines Wissens nach nicht die IO steuern. Ich habe daher einmal ein paar Änderungen getestet und würde dies gern teilen/diskutieren. Dabei ging es mir jetzt speziell um die Sicherung der Home-Verzeichnisse.

    Das Testsystem

    - 2 CPU-Kerne (CPU E5-2680 v3 @ 2.50GHz)

    - 8 GB RAM

    - 100 GB SSD Speicherplatz


    $ ioping -R /


    --- / (xfs /dev/vda3) ioping statistics ---

    22.7 k requests completed in 2.86 s, 88.5 MiB read, 7.91 k iops, 30.9 MiB/s

    generated 22.7 k requests in 3.00 s, 88.5 MiB, 7.55 k iops, 29.5 MiB/s

    min/avg/max/mdev = 70.0 us / 126.4 us / 17.6 ms / 240.1 us


    Home-Verzeichnisse belegen unkomprimiert rund 1,7GB. In der Sicherung sind es nachher rund 920MB.

    Sicherung mit Standardmethode

    Befehl in backup_user.sh:


    nice -n 19 setuidgid $USER tar --preserve-permissions $PARM_EXCLUDE -czf $BACKUPDIR/user/$USER/$ROTATION/backup.tar.gz $HOME

    Merkmale

    - tar + gzip, Standardeinstellung

    - Single Core

    Benchmark

    ./backup.pl 64,36s user 21,89s system 106% cpu 1:20,94 total

    Sicherung mit 'pv'

    Befehl in backup_user.sh:


    nice -n 19 setuidgid $USER tar --preserve-permissions $PARM_EXCLUDE -czf - $HOME | pv -L 10m > $BACKUPDIR/user/$USER/$ROTATION/backup.tar.gz


    - tar + gzip + pv

    - Single Core

    - IO/Last durch pv besser steuerbar => Weniger Last, mehr Zeit


    Mit 'pv -L 10m' wird die Transferrate festglegt. Da mein Dateisystem rund 30MB/s schafft, habe ich den Wert auf 10MB/s gesetzt.

    Benachmark

    ./backup.pl 59,19s user 28,69s system 84% cpu 1:44,03 total

    Sicherung mit 'pigz'

    Befehl in backup_user.sh:


    nice -n 19 setuidgid $USER tar --preserve-permissions $PARM_EXCLUDE -cf - $HOME | pigz -6 > $BACKUPDIR/user/$USER/$ROTATION/backup.tar.gz


    - tar + pigz

    - Multi Core fähig

    - Hohe IO, geringere Zeit


    In der Standardeinstellung von pigz werden so viele Prozesse gestartet wie Prozessoren (Kerne) zur Verfügung stehen. Bei mir also zwei Prozesse. Mit "-p" kann dies steuern. Sicherlich sinnvoll wenn man auf System mit mehr Kernen nicht alle nutzen möchte.

    Benchmark

    ./backup.pl 70,58s user 14,80s system 168% cpu 50,538 total

    • Offizieller Beitrag

    Wir hatten schon mehrmals das Problem, dass das Backup etliche Stunden gedauert hat, einmal sogar so lange, dass mehrere Backups parallel liefen. Irgendwann viel jemanden auf, dass der Server recht träge ist, da liefen dann schon 2 oder 3 Backups parallel.


    Was ich damit sagen möchte, es sollte im Backupskript überprüft werden, ob noch ein andere Backupvorgang läuft.


    Warum es manchmal elendig lange dauert, konnten wir noch nicht herausfinden; liegt evtl. am Sonnenstand :/

  • Wir hatten schon mehrmals das Problem, dass das Backup etliche Stunden gedauert hat, einmal sogar so lange, dass mehrere Backups parallel liefen. Irgendwann viel jemanden auf, dass der Server recht träge ist, da liefen dann schon 2 oder 3 Backups parallel.

    Warum es manchmal elendig lange dauert, konnten wir noch nicht herausfinden; liegt evtl. am Sonnenstand :/

    Das kann an vielem liegen... Größe... Komplexität beim Komprimieren... MySQL Queries behindern sich gegenseitig. Sicher nicht einfach zu blicken. Wenn der Prozess läuft könnte man versuchen sich diesen mit strace anzuschauen. Oder man fügt in den backup_*.sh Skripten echo Befehle ein und loggt so die einzelnen Schritte.

    Was ich damit sagen möchte, es sollte im Backupskript überprüft werden, ob noch ein andere Backupvorgang läuft.

    Nichts leichter als das :) Im crontab einfach den Aufruf durch

    Code
    flock -n /tmp/pdaBackup.lock -c "/opt/pdadmin/bin/backup.pl"

    ersetzen. flock sollte bei den meisten System bereits installiert sein.

  • Die Sicherung mittels tar + gzip ist jedenfalls suboptimal, da recht ressourcen- oder zeitintensiv. Ich wollte erst einmal aufzuzeigen, dass man hier aber durchaus Anpassungen vornehmen kann. Ich hatte es auch mit lz4 getestet, das Ergebnis war jedoch nicht signifikant anders als die Standardmethode.

    • Offizieller Beitrag

    nice -n 19 setuidgid $USER tar --preserve-permissions $PARM_EXCLUDE -czf - $HOME | pigz -6 > $BACKUPDIR/user/$USER/$ROTATION/backup.tar.gz

    Ich riskier jetzt mal einen Denkfehler: Ist das nicht unnötig doppelt gemoppelt? sieht für mich so aus als würdest Du bereits ein gziptes Tar erstellen (wegen dem -czf) und dieses dann erst recht an pigz pipen.