Automatisches Erstellen eines Backups (Pi sichert sich selbst)

L I V E Stammtisch ab 20:30 Uhr im Chat
  • == Übersicht ===

    • Einführung
    • Voraussetzungen
    • Erstellung des Backupscripts
    • Aktivieren des regelmäßigen Backups
    • Zurückspielen des Backups
    • Erweiterungen
    • Benutzung des Backupscripts raspiBackup


    == Einführung ===

    Sobald man seine Pi endlich so eingerichtet und konfiguriert hat, dass sie zuverlässig Ihre Ihr zugewiesenen Aufgaben erfüllt wird es Zeit sich Gedanken zu machen, wie man immer automatisch einen aktuellen Backup erstellen kann, damit im Notfall, falls Daten verloren gehen oder die SD Karte ihren Geist aufgibt, sehr schnell die Pi wieder mit dem Backup zum Leben erwecken kann.

    Die Backupmethode und wie häufig und wieviele Backups man erstellt hängt davon ab, wie aktuell die Backups sein müssen, wie die Bandbreite zum Backupmedium ist, wieviel Platz auf dem Backupmedium vorhanden ist und ob man auf ältere Datenstände der Pi in bestimmten Fällen zurückgreifen muss.

    Dieses Tutorial beschreibt, wie man recht einfach die Pi dazu bringen kann, sich regelmäßig selbst zu sichern. Voraussetzung dafür ist, dass vor der Sicherung alle aktiven Programme wie xbmc, Apache, mysql, samba, nfs-server usw vorher beendet werden. Dann ist einzig und allein ein externes Speichermedium, welches an die Pi direkt per USB oder per Netz angeschlossen ist, notwendig. Das kann eine USB Platte, irgendein NAS Speicher im Netz wie eine Fritzbox, eine richtige NAS Box, ein anderer ständig laufender Rechner im Netz oder eine Cloud welche per davfs zugreifbar ist, sein. Diese müssen dann ihren Speicher per nfs (Linux) oder samba bzw cifs (Windows) anbieten oder einen ssh Zugang anbieten der von rsync (Linux) benutzt werden kann.

    Am Ende des Tutorials hat man seine Pi so konfiguriert, dass sie automatisch regelmäßig einen Backup von sich selbst erstellt welches dann sowohl unter Windows als auch Linux benutzt werden kann um sie wiederzubeleben. Ausserdem wird parallel eine kleine Einführung in Linux bash Programmierung gegeben, denn um die Aufgabe zu erfüllen muss ein kleines bash Script erstellt werden. Es ist nicht schwer und was man lernt hilft zukünftige eigene Automatisierungsaufgaben selbst anzugehen und zu lösen. Wer kein Interesse hat ein wenig die bash Programmierung kennenzulernen und sich einzuarbeiten findet hier hier ein fertiges Script zum Download, welches ich selbst zum Sichern und Wiederherstellen meiner Pis benutze. Wie man dann das Backup wieder restored wird dann natürlich auch für dd und tar beschrieben.

    Backups kann man mit dd, tar oder rsync anlegen. dd sichert die gesamte SD Karte während tar nur die wirklich existierenden Daten sichert. D.h. wenn eine SD Karte 8 GB hat werden mit dd auch 8 GB gesichert während mit tar nur die tatsächlichen Daten gesichert werden. Meine raspxbmc hat eine 8GB SD Karte, deren tar Sicherung 300MB belegt. Der Nachteil mit tar ist, dass man dazu auch ein Linux System braucht, um die Daten im Backupfall wieder zu erhalten. Dazu kann man aber die Pi mit einem raspbian nehmen. Bei rsync wird noch weniger gesichert denn dieses sind nur die geänderten Daten. Deshalb geht das Backup mit rsync i.d.R. noch sehr viel schneller. Man kann eine Pi mit Hilfe einer anderen Pi wieder aus einem dd, tar oder rsync Backup restaurieren lassen. Ein dd Backup kann man auch mit Windows wieder zurückspielen.

    Wenn man ein laufendes Linux System sichern will, sollten erst alle aktivern Anwendungen gestoppt werden, da sonst inkonsistente Backups entstehen können. D.h. dass besonders Dienste wie samba, apache, owncloud, mysql usw vorher gestoppt werden sollten. Nach erfolgreichem Backup können alle gestoppten Dienste wieder gestartet werden.

    === Voraussetzungen ===

    1) Eine laufende Pi mit raspian
    2) Ein gemountetes externes Speichermedium und dort ein Unterverzeichnis in welchem die Backups abgelegt werden

    === Erstellung des Backupscripts ===

    In der folgenden Beschreibung wird angenommen, dass das ein Backupmedium unter /backup gemountet wurde und darin ein Verzeichnis raspi existiert.

    Das Backuperstellen ist ein Aufruf von dd, tar oder rsync. Damit das dann auch regelmässig erstellt wird gibt es in Linux cron, der schon in einem Tutorial (siehe Tutorial zu cron) beschrieben wurde. Dort trägt man einen Befehl ein, der regelmäßig zu bestimmten Zeiten auszuführen ist. Da auch noch dafür gesorgt werden muss, dass nicht unendlich viele Backups sondern nur eine maximale Anzahl erstellt werden, ist es geschickter, ein kleines bash Script zu erstellen, welches den eigentlichen Backupvorgang steuert und dieses über cron aufrufen zu lassen. Der Vorteil ist auch dass man dieses Script auch manuell in der Konsole aufrufen und damit testen kann.

    Ein bash Script beginnt immer mit

    Bash
    #!/bin/bash


    denn damit wird festgelegt, dass alle folgenden Zeilen der bash Sprachbeschreibung (Syntax) folgen. Alternativ kann man da auch andere
    Sprachen festlegen wie

    Python
    #!/usr/bin/python


    oder

    Perl
    #!/usr/bin/perl


    und die folgenden Zeilen müssen dieser Sprachbeschreibung von Python der Perl folgen.

    Um das Script aufrufen zu können sind noch folgende Massnahmen notwendig:
    Annahme: Das Script soll backup.sh heissen
    1) Erstellen des Scripts backup.sh mit einem Editor
    2) chmod +x backup.sh

    Den Aufruf des Scripts nimmt man dann mit

    Code
    . backup.sh

    vor. ACHTUNG: Der Punkt am Anfang ist notwendig!

    Will man das Script debuggen und sehen welche Befehle tatsächlich ausgeführt werden ist der folgende Scriptaufruf sinnvoll:

    Code
    bash -x backup.sh


    bzw wenn man noch weitere Details der bash Ausführung sehen möchte

    Code
    bash -xv backup.sh

    Das einfachste bash Script ist einfach eine Aneinanderfolge von Befehlen, die man in der Konsole eingeben kann. Damit kann man mit der folgenden Zeile sehr einfach eine Backup der gesamten SD Karte anstossen:

    Code
    dd if=/dev/mmcblk0 of=/backup/raspi/MeinBackup.img bs=1MB


    Am Ende existiert die Datei MeinBackup.img unter/backup/raspi die leicht per dd oder den entsprechnden Windows Tools wieder auf eine andere SD Karte zurückgespielt werden kann. Der Nachteil ist, dass immer nur ein Backup MeinBackup.img existiert. Normalerweise will man wenigstens drei Backups vorhalten. Deshalb muss man den Name der Datei mit dem aktuellen Datum und der Zeit versehen.

    Dazu gibt es das date Kommando und mit

    Code
    date +%Y%m%d-%H%M%S


    bekommt man das aktuelle Datum sowie die aktuelle Zeit.

    In ein bash Script kann man den Aufruf von date wie folgt einbinden um einen Backupfilenamen mit Datum und Uhrzeit zu erstellen:

    Code
    dd if=/dev/mmcblk0 of=/backup/raspi/MeinBackup-$(date +%Y%m%d-%H%M%S).img bs=1MB


    Alles was in $(...) steht wird ausgeführt und das Ergebnis dann in der Zeile im Script ersetzt. Z.B. würde momentan (16.6.2013 um 22:39:27) das Ergebnis des Befehls, wenn das Script ausgeführt würde, wie folgt aussehen:

    Code
    dd if=/dev/mmcblk0 of=/backup/raspi/MeinBackup-20130613-223927.img bs=1MB


    D.h. es wird bei jedem Backuplauf eine neue Datei erstellt und man kann aus dem Namen erkennen, wann es erstellt wurde. Das führt aber zu einer Invasion von Backups und sprengt über kurz oder lang die Speicherkapazität des Backupmediums. Deshalb müssen nach dem Erstellen des Backups alte nicht mehr benötigte Backups gelöscht werden.

    Eine Lösung ist die Hintereinanderschaltung von 3 Befehlen mit dem Pipe Operator |: Dadurch wird das Ergebnis des vorhergehend Befehls jeweils in den folgenden Befehl weitergeleitet und so gefiltert und bearbeitet, dass die Kombination der einfachen Linux Befehle zusammen ein komplex zu berechnendes Ergebnis liefern (Siehe auch Unix Philosophie)

    Code
    ls -tr MeinBackup*| head -n -3 | xargs rm -v


    Was macht diese Zeile? Zum Ausprobieren sollte man ein neues Verzeichnis, z.B. Test erstellen und dort Testdateien erstellen mit

    Code
    for i in {1..5}; do touch MeinBackup-$i; sleep 3; done


    In diesem Verzeichnis zeigt dann

    Code
    ls -tr


    alle Dateien in dem aktuellen Verzeichnis an und zwar aufsteigend nach dem Datum sortiert.

    Code
    head -n -3


    filtert aus dieser Liste von Zeilen alle bis zu 3ten Zeile und man erhält damit die Dateien, die älter als die ersten 3 neuesten Dateien sind und welches die zu löschenden Dateien sind. Gibt es weniger ist die Liste leer.

    Code
    ls -tr | head -n -3


    in dem o.g. Verzeichnis mal ausführen.
    Mit

    Code
    xargs rm


    werden die Zeilen, die als Eingabe zu dem Befehl geliefert werden alle dem Befehl

    Code
    rm


    als Argument mitgegeben. Somit werden alle Dateien, die älter sind als die ersten 3 neuen Dateien gelöscht. Ausprobieren sollte man das nicht in einem Verzeichnis wo man die Dateien behalten will aber wenn man den Befehl etwas ändert in

    Code
    ls -tr MeinBackup* | head -n -3 | xargs -I '{}' echo "rm {}"


    wird nur angezeigt welcher rm Befehl ausgeführt werden würde aber der rm Befehl an sich nicht ausgeführt. Diesen Befehl kann man im Verzeichnis Test ausführen und sieht dann welche Dateien gelöscht werden würden.

    Ruft man nun den folgenden Befehl auf

    Code
    ls -tr MeinBackup*| head -n -3 | xargs rm -v


    bleiben die 3 neuesten Dateien übrig. Alle anderen Dateien werden nun gelöscht.

    Damit man sich Schreibarbeit erspart und auch schnell mal zum Testen die Pfade ändern kann benutzt man im bash Script Variablen, die einmal mit Werten versehen werden und dann überall im Script benutzt werden. Dadurch ist eine Änderung nur an einer Stelle notwendig.

    Variablen werden in bash definiert mit

    Code
    BACKUP_PFAD="/backup/raspi"


    und an der Benutzungstelle im Script muss dann der Variablenname mit vorangestelltem $ und geschweiften Klammern stehen wie z.B.

    Code
    ${BACKUP_PFAD}


    Die Anzahl der Backups sowie den Backupnamen sollte man auch noch variabel machen. Somit muss in dem Script folgendes stehen:

    Bash
    #!/bin/bash
    BACKUP_PFAD="/backup/raspi"
    ANZAHL_BACKUPS="3"
    BACKUP_NAME="MeinBackup"
    dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB
    pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${ANZAHL_BACKUPS} | xargs rm; popd


    Das sieht zwar im ersten Moment mit den vielen $ und {} verwirrend aus - aber man gewöhnt sich an die Schreibweise und erhält dadurch auch eine Menge Vorteile.

    Die Befehle pushd und popd sorgen dafür, dass man temporär in ein Verzeichnis mit pushd wechselt und mit popd wieder im vorherigen Verzeichnis landet. Das ist notwendig damit man nicht im falschen Verzeichnis - dem aktuellen - alle Dateien bis auf die aktuellsten 3 löscht. Wichtig ist, dass dass Verzeichnis nach pushd angegeben auch tatsächlich das Verzeichnis ist, in dem die Backups abgelegt werden.

    Diese bash Datei erstellt man am besten mit nano oder einem anderen Editor in /home/pi und nennt sie z.B. raspiBackup.sh. Danach testet man das Script und ruft es per sudo auf. Am Ende befindet sich eine Backupdatei unter /backup/raspi. Dieses Backup sollte nun getestet und per dd oder einem äquivalenten Windowsprogramm auf eine weitere SD Karte gebracht werden. Nun muss die Pi mit der BackupSD Karte wie gewohnt starten und somit der Backupprozess getestet sein.

    Wenn man nun ein anderes Backup erstellen will, z.B. ein tar Backup, muss man nun nur die Zeile im Script, die das Backup erzeugt ändern. Am Besten macht man dazu die Zeile mit dd unwirksam und fügt eine neue Zeile mit dem tar Befehl ein. Zeilen in Script macht man unwirksam wenn man ein # voranstellt. Das kann man auch sehr gut benutzen um Kommentare im Script zu schreiben. Wenn man im Script Befehle hat, die sehr lang sind sollte man sie der Übersichtlichkeit halber auf mehrere Zeilen verteilen. Dazu ist es notwendig am Ende aller Zeilen die zu dem einen Befehl gehören, immer ein \ zu schreiben - ausser in der letzten Zeile. Ausserdem sollte man vor dem Starten des Backups gewisse Services stoppen. Z.b. mysql, xbmc, webserver, samba usw und sie am Ende des Backups wieder starten.

    === Aktivierung des regelmäßigen Backups ===

    Das Backupscript sieht nun wie folgt aus um ein dd Backup auf einem raspbmc zu erzeugen. Wer ein tar Backup haben will muss die Zeile mit dd auskommentieren und die Zeilen vom tar aktivieren durch Entfernung des # am Anfang der Zeilen.

    Nun muss man noch überprüfen, ob die voreingestellten Definitionen

    Code
    BACKUP_PFAD="/backup/raspi"
    ANZAHL_BACKUPS="3"
    BACKUP_NAME="MeinBackup"
    STOP_SERVICES="service xbmc stop"       
    START_SERVICES="service xbmc start"


    stimmen und eventuell anpassen. Das Beispiel geht davon aus dass es ein raspxbmc ist welches gesichert werden soll.

    Für raspbian könnten die Definitionen wie folgt aussehen:

    Code
    BACKUP_PFAD="/backup/raspian"
    ANZAHL_BACKUPS="10"
    BACKUP_NAME="MeinBackup"
    STOP_SERVICES="service cups stop; service mysql stop; service samba stop"       
    START_SERVICES="service cups start; service nysql start; service samba start"

    Nun verschiebt man die Datei raspiBackup.sh in das Verzeichnis was für selbstgeschriebene Scripts unter Linux benutzt wird:

    Code
    sudo mv raspiBackup.sh /usr/local/bin/raspiBackup.sh


    und macht das Script ausführbar

    Code
    chmod 755 /usr/local/bin/raspiBackup.sh


    Nun muss mit

    Code
    sudo crontab -e


    noch eine Zeile in der Crontab eingefügt werden:

    Code
    00 22 * * 0 /usr/local/bin/raspiBackup.sh


    Danach wird jeden Sonntag automatisch ein Backup um 22 erzeugt. Durch Änderung des Crontabeintrages kann man die Frequenz und Zeit der Backuperstellung entsprechend seinen Bedürfnissen anpassen (Siehe Tutorial zu cron)

    === Zurückspielen des Backups ===

    ACHTUNG: Wenn man da aus Versehen nicht das Gerät der SD Karte sondern z.B. eine Festplatte als Gerät beim zurückschreiben angibt dann werden die Daten darauf unwideruflich zerstört! Also vorher immer mit

    Code
    sudo fdisk -l

    prüfen ob /dev/sda wirklich die SD Karte ist (Sieht man i.d.R. an der Speichergröße) und ggf den Gerätenamen entsprechend korrigieren.

    Bei einem dd Backup braucht man kein Script zum Zurückspielen des Backups. Eine einfach Befehlszeile reicht aus.

    Mit dem folgenden Befehl wurde der Backup angelegt.

    Code
    dd if=/dev/mmcblk0 of=/backup/raspi/MeinBackup.img bs=1MB

    Mit genau demselben Befehl, bei dem allerdings Eingabe (if=) und Ausgabe (of=) umgedreht wird, wird das dd Backup wieder auf eine SD Karte gespielt. Dabei muss dann die SD Karte in einem Kartenleser angeschlossen sein. I.d.R. wird die SD Karte dann /dev/sda.

    D.h. mit folgendem Befehl

    Code
    dd if=/backup/raspi/MeinBackup.img of=/dev/sda bs=1MB


    wird das Backup sehr einfach auf die SD Karte kopiert.

    Beim tar Backup ist es aufwändiger. Genaugenommen muss man auch schon beim Backuprozess weitere Dinge sichern, denn das Partitionslayout der SD Karte wird mit tar im Gegensatz zu einem dd Backup nicht mitgesichert. Weiterhin müssen alle Partitionen per tar gesichert werden, d.h. bei raspbian muss noch die /boot Partition /dev/mmcblk0p1 zusätzlich gesichert werden. Weiterhin müssen die Partitionen vor dem Restore formatiert werden.

    Die folgende Anleitung gilt für Images, die keine logischen Paritionen benutzen. wie z.B. raspbian.

    Die Partitionstabelle wird wie folgt gesichert:

    Code
    dd if=/dev/mmcblk of=partitiontable.img bs=1 skip=446 count=64

    und später wie folgt auf eine neue SD Karte geschrieben

    Code
    dd if=partitiontable.img of=/dev/sda bs=1 seek=446 count=64

    Nachdem die Partitionstabelle auf den neuen SD Karte angelegt wurde müssen die Partitionen noch formatiert werden. Bei raspbian sieht das wie folgt aus: (Annahme: Die SD Karte ist als /dev/sda angeschlossen) (Ggf /dev/sda durch den korrekten Gerätenamen ersetzen)

    Code
    mkfs.vfat -F 32 /dev/sda1
    mkfs.ext4 /dev/sda2

    Danach kann das tar Backup zurückgespielt werden. Dazu muss die Partition, die zurückgespielt wird, gemounted werden:

    Code
    mount /dev/mmcblk0p1 /mnt 
    tar -xzf -C /mnt /backup/raspi/MeinBackup_partition1.tgz
    umount /mnt


    und

    Code
    mount /dev/mmcblk0p2 /mnt 
    tar -xzf -C /mnt /backup/raspi/MeinBackup_partition2.tgz
    umount /mnt

    Wie man sieht sind das schon mehrere Schritte die beim Sichern und Zurückspielen notwendig sind und diese bieten sich an auch in ein bash Script geschrieben zu werden. Man kann also seine bisherigen erworbenen bash Script Kenntnisse sehr gut dazu nutzen :shy: .

    Eine Warnung: Wer den Restore auch in ein Script giessen will - dem empfehle ich dringend beim Testen vorsichtig zu sein und immer zu prüfen dass immer das richtige Gerät zum Wiederherstellen benutzt wird und sich das bestätigen zu lassen :shy: Z.B. hilft es sehr, wenn man vor dem eigentlichen Restore folgenden Code ausführt:

    Code
    echo "@@@ Achtung: Zielpartition richtig (j/n)? @@@"
    echo $(fdisk -l)
    read a
    [ "$a" == "j" ] || exit 127

    === Erweiterungen ===

    Dieses Basisscript kann man nun natuerlich dazu benutzen um es nach Belieben zu erweitern und seinen Bedürfnissen anzupassen. Beispiele sind
    - Andere Backupmethoden wie schnelleres und effizienteres rsync benutzen
    - Meldung bei Erfolg und Fehler des Backups per email oder im syslog
    - Protokollierung des Backupprozesses in /var/log/messages
    - Abfangen von Laufzeitfehlern

    === Der einfache Weg - das Script raspiBackup ===

    Alle obigen Erweiterungen und viele mehr sind im von mir selbst und mittlerweile auch in der Community genutzten Backup- und Restorescript verfügbar. Als Einleitung in die Shellprogrammierung ist es nicht geeignet. Wer nun aber Interesse an bash Programmierung bekommen hat kann dieses Script aber sehr gut nehmen und es sich ansehen um sich damit weiter in die bash Programmierung einzuarbeiten. bash lernt man am besten, indem man sich existierende Scripts ansieht und versteht was dort getan wird.

    Wie immer ist es bei Backups extrem wichtig auch zu testen, dass sie funktionieren. Denn es ist nichts so frustrierend wie zu dem Zeitpunkt, in dem man ein Backup braucht, feststellen muss, das das Backup nicht OK ist. Ein Backup zu testen geht bei der Pi recht einfach, denn man muss nur eine weitere SD Karte haben, auf der man das Backup zurückspielt und testet, ob das zurückgespielte Backup OK ist.
    Ein regelmäßiger Test des Backups sollte obligatorisch sein, denn es gibt erfahrungegemäß immer wieder Ereignisse, die dazu führen, dass ein Backup nicht mehr funktioniert, das Backup korrupt ist oder Daten fehlen und ein Restore deshalb nicht mehr möglich ist.

  • Automatisches Erstellen eines Backups (Pi sichert sich selbst)? Schau mal ob du hier fündig wirst!

  • Ich kann beim laufenden pi ein Backup mit dd von der kompletten SD karte machen??

    bisher hatte ichs immer so, pi aus, karte raus in Netbook rein und dort per linux und dd die karte gebackupt ^^

  • Ein Backup eines Systems, welches heruntergefahren wurde, ist immer das sicherste. Da liegt keine Information irgendwo im Hauptspeicher rum und nix aendert sich in der Zeit des Backups. Leider muss man das immer manuell machen.

    Bei einem laufenden System kann sich zum Zeitpunkt des Backups immer noch etwas aendern, was inkonsistente Daten erzeugen kann. Deshalb sollte man moeglichst alle Aktivitaeten, die Daten auf dem System aendern, beenden und damit das Risiko soweit wie moeglich minimieren. D.h. sql, samba, webserver etc runterfahren bzw ein DB Backup mit sql erstellen. Im Script ist das die Stelle mit 'Stoppe services'.

    Dazu noch ein paar Links mit weiteren Infos zu dem Thema:

    Systembackup mit dd | Der Blog rund um Linux und andere freie Software
    How to copy a Linux installation - ThinkWiki
    HowTo: Backup a Running VM to Sparse File and Restore using LVM Snapshots, dd and cp | F1Linux.com

  • Guten Morgen,
    erst mal vielen Dank für das klasse Tutorial. Bis jetzt funktioniert auch alles einwandfrei. Jedoch habe ich jetzt noch ein weiteres Anliegen / Vorschlag für das Tutorial.
    Ich würde gerne das Backup verschlüsseln (Archiv mit Passwort), da ich dieses über WebDav Mount auf eine Cloud lege(z.b Telekom 25GB kostenlos). Unter Windows habe ich das immer über ein CMD Skript mit WinRar realisiert. So könnte man ein Backup seiner SD-Karte machen und dieses automatisch nachts auf die Cloud laden lassen. Ich lasse mich aber auch bei Nachteilen gerne eines besseren belehren=)
    Vielen Dank !
    Django

  • Das Script kann nach belieben angepasst werden um das Ergebnis zu encrypten. Entweder mit pgp bzw gpg (gpg Howto) oder auch zip.


    Das Entpacken läuft dann mit

    Code
    dd if=${BACKUPFILE}.des3 | openssl des3 -d -k ${PASSWORD} | tar zxf -


    Nachteil ist, dass das Password in dem Script im Klartext steht und auch waehrend der Laufzeit des Backups im Klartext von jedem anderen Benutzer auf der Pi lesbar ist. Wenn das ein Problem ist sollte pgp benutzt werden.

    Das Ergebnis von dd kann man natuerlich ebenso durch openssl pipen.

  • Hallo framp,

    habe das Skript mal getestet. Er erstellt bei mir zwar eine Zip Die auch nur mit einem Passwort entpackt werden kann, jedoch ist die Zip Datei ohne Inhalt. Die passende tgz Datei wird einwandfrei erstellt.
    An was könnte das liegen ??
    Gruß

  • Ich habe den Befehl oben geändert. Jetzt wird schon mit tar gezipped und dann anschliessend per openssl encrypted. Ich habe es nur im kleinen Rahmen getestet. Also gib bitte Feedback ob es auch im grossen Rahmen funktioniert.

  • Vielen Dank!
    Folgendes werde ich testen und abhacken:

    [ok] Skript über Cron starten
    [ok] Backup auf USB Festplatte (573MB, 1887s, 303kB/s)
    [ok] Backup auf webdav Laufwerk (Aber schnelle Verbindung nötig)
    [ok] Entpacken mit gesetztem Passwort (Sollte aber noch gesagt werden, auf welchem System dieses entpackt werden soll, also Ext. oder direkt auf dem Raspi)
    [ok] Backup auf SD rückspielen über Ubunut(VM)

    Alles Perfekt !!!

    Grüße

    Einmal editiert, zuletzt von django (26. Juli 2013 um 09:22)

  • Ich erhalte wenn ich das Script laufen lassen, eine Fehlermeldung beim Stopen des Services:

    xbmc: unrecognized service

    Ich verwende raspian!

  • Du benutzt also nicht das hier runterzuladene Script sondern das im Turorial beschriebene. Dort wir davon ausgegegangen, dass man eine raspxbmc Installation hat. Bei raspbian müssen die beiden Zeilen

    Code
    STOP_SERVICES="service xbmc stop"
    START_SERVICES="service xbmc start"


    in

    Code
    STOP_SERVICES=""
    START_SERVICES=""


    geändert werden da es da kein xbmc gibt. Wenn Du aber samba, cups und sql usw bei Dir am Laufen hast solltest Du die alle dort eintragen. Also z.B.

    Code
    STOP_SERVICES="service samba stop; service cups stop; service mysql stop"
    START_SERVICES="service mysql start; service cups start; service samba start"

    Ich werde das oben in dem Tutorial noch besser beschreiben.

  • Bin eben über einen Thread gestolpert wo jemand beschrieben hat wie er sein Backup auf die Dropbox schiebt - allerdings in Englisch. Sieht nicht schlecht aus.

    Ich würde meine Daten dort aber aus aktuellem Anlass (NSA et al) so nicht backupen.

  • Wie gesagt benutze ich eine erweiterte Version des Backupscripts bei mir selbst @home für meine drei Pis. Mir war nicht wohl dabei nicht zu wissen ob der Backup vielleicht nicht funktioniert hat und deshalb habe ich das Script so erweiteret, dass es

    1) Fehler beim Backup bemerkt und entsprechend loggt
    2) Optional kann eine Status emails am Anfang und am Ende des Backuprozesses an eine eMailAdresse geschickt werden. Im Fehlerfalle enthält es auch das Fehlerlog.

    Dabei hat mir Dieses Tutorial - Die Post geht ab - eMails mit der Pi versenden geholfen meine Pis in die Lage zu versetzen eMails zu versenden. Vielen Dank an kungel für sein nützliches Tutorial.

    Konkret konnte ich dann auch bald feststellen, dass in einer eMail ein Backupfehler berichtet wurde und anhand des Logs sah ich sofort, dass mein Backupspeicher voll war und deshalb kein Backup mehr erstellt werden konnte.

  • Restores eines gemäß dieses Tutorials erzeugten Backups habe ich, wie man es immer machen sollte, getestet. Doch heute trat der Ernstfall bei mir ein: Mein USB Stick meines LAN Servers gab seinen Geist auf :-(. Auch wenn man es getestet hat steigt dann der Puls denn jetzt kommt der Moment der Wahrheit ...

    Da mein LAN Server schnell wieder funktionieren muss habe ich den Backup auf eine SD Karte zurückgespielt. Hat auch soweit perfekt funktioniert.

    Es wurde schon angeregt auch den Restore eines Backups im Tutorial aufzunehmen. Das gehe ich auch an. Nur habe ich momentan dazu absolut keine Zeit.

    EDIT: Der Restore ist nun auch verfügbar

  • Ich würde davon abstand nehmen jede Woche jedesmal ein vollständiges Bit-für-Bit Abbild über dd zu erzeugen - das beansprucht sowohl das Quell als auch das Ziel Device viel zu krass - weswegen vermutlich nun auch dein Stick den Geist aufgegeben hat...

    Flash-Speicher allgemein - egal ob SSD, SD oder USB - vertragen nicht unendlich viele Schreib/Lese-Zyklen

    Ich würde das lieber mit rsync regeln ...


    Mit rsync werden in diesem Fall nur die Dateien kopiert, die sich verändert haben.
    Wenn man einmal ein komplettes Image erstellt hat und dann nur noch mit rsync arbeitet, wird nicht jedesmal nochmal alles kopiert sondern wie bereits erwähnt nur das was sich seither verändert hat..
    Das geht vorallem auch in den meisten Fällen wesendlich schneller als jedesmal ein komplettes Image zu erzeugen

    1) Einmalig ein Image mit " dd " erstellen, in diesem Beispiel wird das " if " Laufwerk nach /mnt/usbstick/Backup_sda.img geschrieben:

    Code
    dd if=/dev/sda of=/mnt/usbstick/Backup_sda.img

    2) Ein Verzeichnis für den 3.Schritt erstellen:

    Code
    mkdir -p /mnt/Backup

    3) Das erstellte Image mounten (einbinden):

    Code
    mount -o loop /mnt/usbstick/Backup_sda.img /mnt/Backup

    4) Das Programm "rsync" installieren:

    Code
    apt-get install rsync

    5) Script /root/rsync_backup.sh erstellen

    http://msi.to/file/9797


    Wer an sein Gerät immer nur einen USB-Stick oder Festplatte anschliest kann ausserdem sein System so einstellen dass das Device immer automatisch beim einstecken, eingehängt (mounted) und beim abziehen auch wieder ausgehängt (unmounted) wird - letzteres ist ebenfalls wichtig da es sonst haufenweise Fehlermeldungen in den Systemlogs verursacht

    Spoiler anzeigen

    1) udev Regel anlegen:

    Code
    nano /etc/udev/rules.d/99-usbautomount.rules

    Mit folgendem Inhalt:

    Code
    ACTION=="add", SUBSYSTEMS=="usb", KERNEL=="sd?1", RUN+="/bin/mount /dev/%k /mnt/usbstick"
    ACTION=="remove", SUBSYSTEMS=="usb", KERNEL=="sd?1", RUN+="/bin/umount /dev/%k"


    Das ist eine sehr einfach gehaltene Regel, damit ein x-beliebiger USB-Stick immer nach /mnt/usbstick eingebunden wird..

    2) udev neu starten:

    Code
    /etc/init.d/udev restart

    3) mount-point (Verzeichnis wohin der Stick gemounted wird) anlegen:

    Code
    mkdir -p /mnt/usbstick

    4) USB-Stick mit einer FAT32 Partition formatieren, einstecken und mit dem Befehl

    Code
    mount


    prüfen ob obiges funktioniert


    Das funktioniert in der Form aber nur mit einem USB-Stick/HDD. Wer mehrere nutzten möchte, muss die udev-Regel anpassen bzw anhand genauerer Merkmale das Device unterschieden!

  • Ein Backup auf eine SD Karte zu erstellen ist Unsinn. In meinem Falle war es der USB Stick vom OS der nicht mehr wollte.

    Du hast da aber einen validen Diskussionpunkt. Dieser Ansatz mit rsync hat Vor- ... aber auch und Nachteile.

    Pro:
    1) Schnellere Sicherung da rsync nur die Updates sichert. Für einfache daily Backups die erste Wahl.

    Con:
    1) Nur eine Backupversion verfügbar. Wenn man mal dummerweise etwas gelöscht hat und das erst nach längerer Zeit feststellt kann man nicht mehr auf ältere Backups zurückgreifen.

    Wie Du vielleicht gesehen hast ist in meinem Backupscript schon ein switch Statement als Platzhalter für rsync vorgesehen. Ist schon in Arbeit ... aber die Zeit fehlt momentan.

    EDIT: rsync ist im Script verfügbar und es werden Hardlinks benutzt um mehrere Backupversionen zu unterstützen.


  • Ein Backup auf eine SD Karte zu erstellen ist Unsinn.


    wer lesen kann hat oft Vorteile...

    Wer erstellt denn auf eine SD Karte ein Backup? Also ich zumindest nicht, was man auch hierran erkennen kann: /mnt/usbstick/Backup_sda.img (und an dem was im Spoiler steht)


    In meinem Falle war es der USB Stick vom OS der nicht mehr wollte.


    Und nochmal: Wer lesen kann ist klar im Vorteil...

    In meinem ersten Satz steht das dein Stick vermutlich deshalb verreckt sei (zu hohe und unnötige Belastung) aber es spielt keine Rolle ob dein OS auf einem USb-Stick lief oder auf einer SD..


    Con:
    1) Nur eine Backupversion verfügbar. Wenn man mal dummerweise etwas gelöscht hat und das erst nach längerer Zeit feststellt kann man nicht mehr auf ältere Backups zurückgreifen.

    Quatsch - rsync updaten nur Dateien aber löscht nichts! (es sei denn man stellt es entsprechend ein)
    Wenn man also auf seinem System eine Datei dummerweise löscht dann ist sie auch nach einem Monat weiterhin auf dem Backup Laufwerk vorhanden


    Aber weisste was? Der Klügere gibt nach

    ciao

  • Zitat von meigrafd


    Aber weisste was? Der Klügere gibt nach


    Wer von uns hier der Klügere ist lassen wir besser kompetentere Leute entscheiden. Jedenfalls halte ich Dir den Spiegel vor und schenke Dir <*)))><.

    Mir liegt es absolut fern Dich in Deiner Artikulationslust zu unterdrücken. Aber wie Du schon geschrieben hast gibt der Klügere nach und ich beende damit diese OT Diskussion. Wenn Du weiter Lust hast dieses Thema zu diskutieren können wird das gerne per PN ausdiskutieren.

    Irgendwie fühle ich mich mittlerweile an Verleihnix und die Querelen die seine Dorfgallier mit ihm immer wieder haben erinnert ...

  • Servus,

    ich habe mal eine Frage.
    Wenn ich

    [code]sudo dd if=/dev/mmcblk0p6 of=/home/pi/myServer/myShare/MeinBackup.img bs=1MB[code]

    im Terminal ausführe klappt alles wunderbar.

    Wenn ich das Script

    [#!/bin/bash
    #
    # Konstanten
    #
    BACKUP_PFAD="/home/pi/myServer/myShare"
    ANZAHL_BACKUPS="3"
    BACKUP_NAME="RaspiOwnCloud"
    STOP_SERVICES="service cups stop; service mysql stop; service samba stop"
    START_SERVICES="service cups start; service nysql start; service samba start"
    #
    # Stoppe services
    #
    ${STOP_SERVICES}
    #
    # Backup mit dd erstellen
    #
    sudo dd if=/dev/mmcblk0p6 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB
    #
    # Backup mit tar erstellen
    #
    #tar -cpz --one-file-system -f ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).tgz \
    # --exclude=${BACKUP_PFAD} \
    # --exclude=/proc \
    # --exclude=/lost+found \
    # --exclude=/sys \
    # --exclude=/mnt \
    # --exclude=/media \
    # --exclude=/dev \
    # /
    #
    # Starte services
    #
    ${START_SERVICES}
    #
    # Loeschen alter Backups
    #
    pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${ANZAHL_BACKUPS} | xargs rm; popd]

    nehme klappt es nicht.

    In meiner Crontab sieht der Eintrag wie folgt aus

    [00 10 * * 1 /usr/local/bin/raspiBackup.sh]

    dort ist auch das Script abgelegt.

    Wenn ich

    [chmod 755 /usr/local/bin/raspiBackup.sh]

    mache kommt auch keine Meldung das es nicht geklappt hätte.

    Wo könnte es denn klemmen?

    -- Edit

    Ich habe jetzt mal folgendes gemacht:

    [sudo chmod +x raspiBackup.sh]

    Ich war natürlich im entsprechenden Verzeichnis.

    Hat aber auch nichts gebracht :(

    Spielt es eine Rolle das der Owner der Datei www-data ist und nicht der User PI oder root?

    Einmal editiert, zuletzt von Dome_2001 (26. August 2013 um 11:42)

  • chmod wirft nur etwas aus wenn es einen Fehler gab - wenn also dann gleich wieder er promt kommt ist alles oke

    Bevor du das Script in die Crontab packst und wartest bis es Montag wird, führe das Script zunächst mal manuell aus um zu pürfen ob es überhaupt funktioniert

    Also entweder in das Verzeichniss wechseln und ./raspiBackup.sh eingeben, oder (da es in /usr/local/bin/ liegt) nur raspiBackup.sh eingeben, oder den absoluten Pfad: /usr/local/bin/raspiBackup.sh

    Wenn das problemlos funktioniert gäbe es zunächst keinen Grund wieso es nicht auch über crontab funktionieren sollte - es sei denn der Eintrag in der Crontab ist fehlerhaft
    Leider schreibst du nicht in welche Crontab du es eingetragen hast :huh:, es gibt nämlich leider mehrere..


    Und wem die Datei gehört ist egal solange " root " derjenige ist der die Datei ausführen soll - root darf alles ;)


    PS: bitte Scripts oder crontab einträge künftig in [ code ] (ohne die leerzeichen) (oder im Editor oben auf Kode, neben der Sprechblase) posten, danke

  • Danke für die Antwort.
    Wenn ich in der Konsole nun in das Verzeichnis wechsel
    cd /user/local/bin
    mir mit ls alles anzeigen lasse finde ich das Script.
    Wenn ich dann
    ./raspiBackup.sh oder nur raspiBackup.sh mache kommt die Meldung
    bash: /user/local/bin/raspiBackup.sh: /bin/Bash M: bad interpreter: No such file or directory.

    Wo klemmt es? Verstehe es echt nicht.

    Danke schon mal

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!