Rsync Backup Server Teil2

2010-01-20 - kostaki 1 Kommentar »

Im ersten Teil dieses Artikels wurde der Server und Client vorbereitet und die Authentifizierung zwischen beiden funktioniert mit Hilfe des SSH Keys ohne Passworteingabe. In diesem Teil wird auf das zum Einsatz kommende Script eingegangen mit dem sehr einfach mehrere Clients/Server an den Backup Server angeschlossen werden können.

Script erstellen und Crontab einrichten

Wer nur ein sehr einfaches Script will, kann hier den Abschnitt Cron Job Setup lesen. Mein eingesetztes Script lagert die Config in ein extra Verzeichnis aus und unterstützt mögliche Filterlisten. Zum hinzufügen eines neuen Remote Servers auf dem Backup Server muss nur eine neue Config Datei angelegt und mit den richtigen Daten gefüllt werden. Hier gibt es das Script zum Download

Erklärung:

/home/b-user/scripts/ in diesem Verzeichnis liegt das Script (backup.sh)
/home/b-user/scripts/backup/ liegen die Configs und Filterlisten für die Remote Server
/home/b-user/scripts/logs/ die Logfiles des Backups

Beispiel Config:
/home/b-user/scripts/backup/beispiel

REMOTEUSER=r-user
REMOTEHOST=remote
REMOTEPATH=/remote/dir/
LOCALPATH=/local/dir/

Außerdem kann man noch REMOTEPORT angeben, wenn es nicht Standard 22 ist und REMOTERSYNCPATH, wenn Rsync auf dem Remote Server irgend wo speziell liegt.

Beispiel Filter:
/home/b-user/scripts/backup/beispiel.filter

- logs/
- modules/
- error/

Startet man das Backup Script ohne Parameter, werden alle Configs im Config Ordner abgearbeitet. Will man nur eine spezielle Config, dann kann man den Namen als Parameter angeben.

b-user@backup:~/scripts$ ./backup.sh
b-user@backup:~/scripts$ ./backup.sh beispiel

Die Dateien werden dann von REMOTEPATH nach LOCALPATH kopiert. Die im Script verwendeten Rsync Parameter kann man natürlich anpassen.

-r Rekursive
-l Symlinks als Symlinks kopieren
-t Erhält die modified Zeiten
-h Human Readable
-z Aktiviert komprimierte Übertragung
--progress zeigt den Fortschritt an (für Crontabs kann das raus)
--stats Statistiken am Ende der Übertragung
--delete Löscht Dateien auf dem Backup Server, die auch auf dem Remote Server gelöscht wurden

Man könnte auch einen weiteren Wert in die Config setzen um pro Server verschiedene Parameter verwenden zu können.

Zu guter Letzt noch das Crontab anlegen.

b-user@backup:~$ crontab -e

Um das Script täglich um 3 Uhr morgens aufzurufen:

0 3 * * * /home/b-user/scripts/backup.sh >> /home/b-user/scripts/logs/backup.log 2>&1

Archivierung der Rsync Kopien

Mit dem aktuellen Script legt man ja nur eine 1:1 Kopie von Remote Server Dir auf dem Backup Server an. Wenn man das Script also täglich ausführt, dann werden Daten die heute gelöscht werden morgen früh um 3 Uhr auch auf dem Backup Server gelöscht. Das gibt einem schon eine gewisse Zeit zum reagieren, aber zu einer guten Backup Strategie gehört noch mehr. Ich habe deshalb auch noch ein Archiv Script auf dem Backup Server laufen das die kopierten Daten packt und für eine gewisse Zeit vorhält.

Zum Archivieren setze ich auch ein eigenes Script ein, das sich an das Backup Script anlehnt. Auch hierbei gibt es einen Ordner in dem die Configs liegen und in dem man ein paar Optionen definieren kann. Das Script kann man hier downloaden

Erklärung:

/home/b-user/scripts/ in diesem Verzeichnis liegt das Script (archive.sh)
/home/b-user/scripts/archive/ liegen die Configs
/home/b-user/scripts/logs/ die Logfiles des Archive

Beispiel Config:
/home/b-user/scripts/archive/beispiel

BACKUPDIR=/local/archive/;
SOURCEDIR=/local/source/;
DATESTRING=%u;

Das Script macht nichts anderes als SOURCEDIR in BACKUPDIR zu archivieren. Hierzu wird tar benutzt und der Dateiname setzt sich aus dem Configfilenamen und dem DATESTRING zusammen. In diesem Beispiel wird %u verwandt, was der Tag der Woche ist. Wird das Script also täglich aufgerufen, werden 7 Archive, für jeden Wochentag eines, vorgehalten. Das kann man aber anpassen wie man möchte. Im Kopf des Scriptes stellt man dazu die Taroptionen ein die man haben möchte (ich benutze pbzip2, bei nicht bzip2 Komprimierungen muss der Filename im Script angepasst werden) und kann es dann entweder mit einem Parameter oder ohne aufrufen. Gibt man einen Confignamen als Parameter an, dann wird nur diese Config geladen und ausgeführt

b-user@backup:~/scripts$ ./archive.sh
b-user@backup:~/scripts$ ./archive.sh beispiel

Aufpassen sollte man das man sich die Platten nicht voll schreibt. Nun noch das Crontab anlegen und fertig. Da mein Backup Server nichts anderes macht als Backups, lege ich das Archivieren auf 12:00 Uhr.

b-user@backup:~$ crontab -e

0 12 * * * /home/b-user/scripts/archive.sh >> /home/b-user/scripts/logs/archive.log 2>&1

Abschluss

Man hat nun 1:1 Kopien der Remote Server auf einem Zentralen Backup Server und wenn man möchte kann man diese archivieren. Stirbt ein Remote Server, so hat man hiermit eine Kopie zur Wiederherstellung. Löscht man ausersehen etwas auf einem Remote Server, so kann man sich hier ebenfalls bedienen. Man kann das Backup Script natürlich auch in kürzeren Intervallen aufrufen. Bisher habe ich meine Backup Server nur 2-3 mal gebraucht, aber in diesen Fällen war es wichtig einen gehabt zu haben und man schläft auch sehr viel besser.

Ich hoffe ich habe nicht allzu oft r-user/b-user usw. durcheinander gebracht. Wenn jemand etwas auffällt, hinterlasst mir bitte ein Kommentar.

Debian Root