Rsync Backup Script mit ZFS/EXT4 Unterstützung und Infomail für Remote und lokale Systeme

backup-rsync-remote.sh
  • rsync_mail_template.html
  • backup.config
  • backup-source.config
  • Die Datei backup.config beinhaltet die allgemeine Konfiguration, wer soll das Infomail erhalten, Absenderadresse, Backupmedium, Dateisystemtyp,…
    Welche Systeme gesichert werden sollen, wohin die Sicherung geht, wie lange die Sicherung vorgehalten wird, welche Dateien nicht gesichert werden und über welchen Port die SSH Verbindung zum System aufgebaut wird – das steht in der Datei backup-source.config.
    Das Template File rsync_mail_template.html dient als Vorlage für das Infomail und das eigentliche Backup Script ist die Datei backup-rsync-remote.sh.

    Mein exclude-File schaut wie folgt aus:

    /proc
    /dev
    /media
    /lost+found
    /mnt
    /sys
    /var/cache
    /var/games
    /srv/backup
    /var/lib/lxcfs/

    Die brauche ich zum Rücksichern nicht wirklich und machen beim Sichern mehr Probleme als ein Backup der Dateien lösen kann. /srv/backup ist der Pfad in dem ich mein Sicherungsmedium einhänge, darum schließe ich das ebenfalls aus.

    Ich kopiere die vier Dateien immer nach /usr/local/sbin/ und mache mit „chmod +x backup-rsync-remote.sh“ das Backup Script ausführbar. Nach ein paar Anpassungen des Backup Scripts kann es dann schon losgehen.

    Wer z.B. einen Cloud Server einfach nur in ein lokales Verzeichnis auf seinem Backup Server sichern möchte (also kein externes Medium im Spiel), der fügt folgende Zeile in backup-source.config ein:

    cloudserver1.example.domain|/srv/backup.cloud|30|/usr/local/sbin/excludeliste-rsync|22

    Es wird also mit dem fqdn (full qualified domain namen) des Servers gestartet, anschließend folgt das Verzeichnis in dem die Sicherung abgelegt wird, die 30 sind die Anzahl an Sicherungen die vorgehalten werden, dann noch ein exclude-File mit Verzeichnissen die nicht gesichert werden sollen und am Schluss der SSH Port unter dem der Server ohne Passwort Abfrage erreichbar ist. 

    Die Sicherung eines Cloud Server kann jetzt bereits gestartet werden, sofern die backup.config mit passenden Werten versehen wurde bekommt man nach der ersten erfolgreichen Sicherung ein entsprechendes Mail angeliefert.

    KERNEL==“sd?1″,SUBSYSTEM==“block“,DRIVER==““,ATTR{partition}==“1″,ATTR{start}==“2048″,ATTR{size}==“7814035086″,

    SYMLINK=“backup_disk“

    Die passenden Werte für meine Sicherungsplatten bekomme ich vom Befehl:

    udevadm info -a -p $(udevadm info -q path -n /dev/sdf1)

    Wobei /dev/sdf1 entsprechend durch den Devicenamen eurer Sicherungsplatte zu ersetzen ist – am einfachsten findet man der heraus indem man die Sicherungsplatte ansteckt und sich mit „dmesg|tail“ die letzten Kernel Meldungen anzeigen lässt. 

    Hat man die Udev Regel entsprechend erstellt/angepasst muss man den udev Dienst neu starten und triggern, das passiert mit folgender Befehlsabfolge:

    systemctl restart udev
    udevadm trigger

    Anschließend sollte /dev/backup_disk existieren. Jetzt muss man die Platte nur noch für die Sicherung initialisieren:

    backup-rsync-remote.sh –init-ext4

    Zugegeben etwas mehr Aufwand als mit ZFS! 🙂
    Jede Sicherungsplatte muss einmal initialisiert werden und bekommt dabei eine eindeutige ID zugewiesen (steht in der Datei HDID auf der Platte).

    Die einzelnen Sicherungen landen dann jeweils im Verzeichnis „daily.X“ beginnend mit 0 für die aktuelle Sicherung, der Rest dürfte fast selbsterklärend sein. Wer mit „du -sch pfad-zum-sicherungsverzeichnis var NeveProperties = {"ajaxurl":"https:\/\/blog.grufo.com\/wp-admin\/admin-ajax.php","nonce":"47c7dd4fc3","isRTL":"","isCustomize":""};