Backup des /home-Verzeichnisses mit parallel laufenden Tasks

Worum geht es?

In unserem heterogenen Netzwerk mit Windows-, MacOS- und Linux-Clients werden alle Nutzer-Daten letztendlich auf einem Linux-Server gespeichert. Dies geschieht teilweise direkt, teilweise über periodisch laufende Sync-Prozesse. Vielleicht erstelle ich mal eine Beschreibung, wie das bei uns realisiert wird, dies ist aber Stand heute nicht geplant.

Auf dem Linux-Server finden sich die Daten dann im Home-Verzeichnis der angelegten User. Diese wollte ich einem regelmäßigen Backup unterziehen. Jetzt kann man natürlich sagen, dass einfach nur diese Home-Verzeichnisse kopiert werden müssen und fertig. Stimmt natürlich erstmal, aber ich wollte noch ein paar Dinge mehr:

Die Installation (ein großes Wort für das, was gemacht werden muss) ist einfach. Los geht's:

Inhalt

Voraussetzungen für das Backup-Skript

Das Backup-Skript backup_home.sh benötigt: Die 4 Programme lassen sich unte Linux einfach mit 
apt-get install afio parallel gzip perl
installieren, wenn nicht schon geschehen.

Einstellungen

Diese sind denkbar einfach und leicht vorzunehmen: Man öffnet das Skript backup_home.sh mit einem Texteditor seiner Wahl, geht die Einstellungen am Anfang des Skriptes durch und ändert sie bei Bedarf.

Parallele Instanzen:

###
# Wieviele parallele Instanzen?
#
# Zu beachten bei magnetische Platten:
# Hier sind die Festplatten selbst und deren Anschluss der limitierende
# Faktor. Wenn 3, 4 oder mehr Instanzen gleichzeitig Daten auf einer
# magnetischen Platte suchen und auch schreiben wollen stören sich die
# Instanzen bei den Zugriffen gegenseitig.
#
# Zu beachten bei SSDs:
# Sind lediglich SSDs beteiligt kann man durchaus die Instanzen hoch-
# setzen und die Verarbeitungsraten vergleichen, um die schnellste Einstellung
# zu ermitteln. Ich konnte dies allerdings nicht ausprobieren da auf
# unserem Server die Daten auf magnetischen Platten liegen.
INSTANZEN=2
Wer nur SSDs in Betrieb hat kann hier mal mit mehr Instanzen rumspielen. Bei magn. Platten stören sich parallele Prozesse, sowohl beim Lesen als auch beim Schreiben. Siehe auch weiter unten Benchmarks - und einige Überlegungen.

Wo liegen die Home-Verzeichnisse der User?

Dies ist das Verzeichnis, dass gebackuped wird. 
# wo liegen die home-Directories der User? Für gewöhnlich ist das "/home".
HOMEDIR="/home"

Zielverzeichnis für das Backup:

###
# wo soll das Backup hin? (bei uns ist unter /mnt/backup eine separate Platte gemountet). Das
# Backup-Verzeichnis sollte auf jeden Fall auf einer anderen Platte als die Daten liegen.
# Liegt alles auf einer sind bei einem Ausfall sowohl die Daten als auch das Backup futsch.
BUPDIR="/mnt/backup"
Ich erwähne es hier nochmal, da es wirklich wichtig ist: Legt BUPDIR unbedingt auf eine andere Platte als die Datenplatte, ansonsten ist bei einem Ausfall der Platte alles weg: Daten und Backup!

Vorheriges Backup festhalten?

Dies ermöglicht es, 3 Datenbestände vorzuhalten: 
###
# altes Backup in Unterverzeichnis "old/" sichern?
# KEEPOLD=<true|false>
KEEPOLD="true"

Backup komprimieren?

###
# Komprimierung
# COMPRESS=<true|false>
#COMPRESS="true"
Unser Server hat zuwenig Performance um hier wirklich loszurasen - und da wir genügend Platz haben lasse ich die Backups unkomprimiert erstellen. Erst wenn die Backups von Zeit zu Zeit auf eine externe USB-Platte gespielt werden wird komprimiert. Das macht bei uns dann aber ein anderer, schnellerer Rechner.

Grösse eines Backup-Files:

###
# Grösse eines Backup-Files
#BACKUPSIZE=$((2**31-2**23))	# 2 GByte - 10 MByte Buffer
BACKUPSIZE=$((2**32-2**23))	# 4 GByte - 10 MByte Buffer
Ganz am Anfang - das Skript hat seinen Ursprung in 2004 - war geplant, das Backup von Zeit zu Zeit auf optische Datenträger zu sichern: Anfangs CDs, dann DVDs. Deshalb findet sich in einem Backup auch immer noch das Skript backuptodvd.sh, das eben genau dieses bewerkstelligt.

CDs und später auch DVDs wurden aber schnell zu klein. Auch sind optische Datenträger inzwischen nicht mehr zeitgemäß, weswegen es egal ist, wie groß eine Backup-Datei ist. Ich habe die Erstellung von backuptodvd.sh einfach nie aus dem Backup-Skript herausgenommen.

Angaben für backuptodvd.sh:

###
# Angaben für "backuptodvd.sh" (sind für das eigentliche Backup nicht notwendig,
# sondern wenn man später die BUP-Files auf DVDs schreiben möchte)
BURNDEVICE="/dev/cdrom"
DVDCHANGENOTIFY="true"
ROOTUSER="root"	# bekommt eine Mail mit der Aufforderung, einen neuen Rohling einzulegen
Wie oben schon geschrieben: Ich habe backuptodvd.sh einfach im Backup-Skript belassen und nie gelöscht. Für das Backup selbst ist es nicht notwendig.

Benchmarks - und einige Überlegungen

# Benchmarks
###################################################################
#                                                                 #
#  Instanzen   Kompri-     Ver.-Rate      Laufzeit     Umfang     #
#              mierung?                                           #
#                                                                 #
#      1        nein      27,1 MByte/s     7:40:29    748 GByte   #
#      1        nein      26,7 MByte/s     7:41:49    740 GByte   #
#      2        nein      26,6 MByte/s     7:44:29    742 GByte   #
#      3        nein      26,5 MByte/s     7:57:29    759 GByte   #
#      2        nein      26,0 MByte/s     8:05:12    756 GByte   #
#      3        nein      26,0 MByte/s     8:06:04    758 GByte   #
#      3        nein      25,8 MByte/s     8:08:34    740 GByte   #
#      4        nein      25,5 MByte/s     8:15:51    759 GByte   #
#      4        nein      25,4 MByte/s     8:09:02    748 GByte   #
#      4         ja       10,7 MByte/s    19:14:10    758 GByte   #
#                                                                 #
###################################################################
Es zeigt sich, dass es zumindest auf unserem Server keinen Sinn macht, das Backup mit vielen parallelen Tasks laufen zu lassen. Die Hardware ist etliche Jahre alt (CPU mit 4 Kernen ohne Hyperthreading, 8 GByte RAM, eine relative alte Debian-Installation, und nur SATA-Magnetplatten), entsprechend ist die Performance. Ich hatte mir trotzdem mehr erhofft.

Meine Vermutung ist, dass sich die unterschiedlichen Tasks bei den Festplattenzugriffen gegenseitig stören. Mit steigender Task-Anzahl sinkt die Verarbeitungsrate. Klar: Wenn der Kamm mit den Lese- und Schreibköpfen permanent zwischen den Stellen hin und her wechseln muss, an denen die verschiedenen Tasks sowohl Daten lesen als auch schreiben - auch wenn dies auf einer anderen Platte ist - startet bei jedem Wechsel der Such- und Positioniervorgang des Kamms erneut (Stichworte: Spurwechsel- & Latenzzeiten). Dadurch sinkt in Summe die Verarbeitungsrate.

Auch mit eingeschalteter Komprimierung zeigen sich auf der alten Hardware keinerlei Geschwindigkeitsvorteile. Ich lasse sie bei uns ausgeschaltet.

Interessant wäre das Backup-Skript mal auf einem wirklich performanten Server mit vielen Kernen, großzügigem Speicherausbau und SSDs laufen zu lassen. Da dürfte die parallele Abarbeitung voll zum Tragen kommen. Hier muss aber jeder mit seiner eigenen Hardware eigene Benchmarks durchführen.

Backup per CRON

Bei uns läuft das Backup immer in der Nacht von Freitag auf Samstag um 0:35 Uhr. Der entsprechende Eintrag in /etc/crontab ist: 

35 0 * * 6    root  <Pfad wo backup_home.sh liegt>/backup_home.sh > /dev/null 2>&1
Wenn das Skript durchgelaufen ist wird eine Mail mit einigen Statistik-Daten des Backup-Laufes an root geschickt.

Restore eines Backups

Bei jedem Backup-Lauf wird für jeden User ein Restore-Skript erzeugt: 

restore_$USER.sh
Dieses Skript findet sich in dem jeweiligen Backup-Verzeichis. Es sollte auch immer beim Backup belassen werden. Zum Restore einfach dieses Skript starten, der Inhalt des Backups wird dann in ein Unterverzeichnis entpackt.

Download "backup_home.sh"

Und hier das Skript:

Autor

Dirk Schimansky

Bei Fragen einfach eine E-Mail schreiben.

Spende

Wer Lust hat: Bitte schön, auch ich trinke gerne mal ein Bier! :-)

Danke!

Quellen

--- keine ---


13.01.2020 - Tools - Dirk Schimansky - Impressum