Ein paar Leser scheinen Probleme bei der Wiederherstellung der Backups zu haben. Images können mit Win32 Disk Imager wiederhergestellt werden. Keine Garantie, dass es funktioniert. Alternativ kannst du die SD-Karte aus dem Gerät nehmen und „offline“ eine Sicherung in deinem PC machen mit oben genanntem Tool.

Einen Einplatinencomputer, auf dem nur eine kleine Anwendung für die Steuerung deines Smarthomes läuft, sichern? Das ist doch voll übertrieben und verursacht mehr Aufwand als Nutzen?

Falsch gedacht!

Was machst du denn, wenn die Speicherkarte deines Raspberry Pis * den Geist aufgibt und dein Zuhause plötzlich im wahrsten Sinne des Wortes hirnlos ist?

Du wirst ganz schön blöd aus der Wäsche schauen, das kann ich dir versprechen. Denn viele der Einstellungen wiederherstellen kann unter Umständen Stunden, wenn nicht sogar Tage an Arbeit bedeuten.

Raspberry Pi
Raspberry Pi als Smarthome-Zentrale

Zuletzt aktualisiert 18.10.2021 / (*) Affiliate Links / Bilder von der Amazon Product Advertising API / Der angegebene Preis kann seit der letzten Aktualisierung gestiegen sein.

Dann doch lieber jeden Tag sichern?


Das dann vielleicht doch nicht. Im Normalfall – gerade im Bezug auf Openhab – lohnt sich kein tägliches Backup. Die Konfigurationsdateien ändern sich im Normalfall nicht und die Protokolldateien kann man getrost in die Tonne kicken, sofern alles rund läuft.

Daher ist ein tägliches Backup nicht wirklich sinnvoll. Man sollte sich lieber in regelmäßigen Abständen ein Backup anlegen und das dann sicher aufbewahren, bevor man bei Änderungen ein neues erstellt. Und ein Backup im laufenden Betrieb ist dabei absolut möglich und auch sinnvoll, wenn es um Smart Home geht. Denn wer möchte schon für die Dauer des Backups auf seinen Komfort verzichten?

Smart Home
Interessierst du dich für Smart Home? Dann gefällt dir bestimmt das Smarthome Kompendium. Hier findest du sauber aufgelistet eine Menge an smarten Geräten.

Ein Backup über SSH erstellen

Da viele Personen ihren Raspberry Pi ohne Tastatur und Bildschirm betreiben, erkläre ich dir ganz kurz, wie das Backup im laufenden Betrieb grundsätzlich abläuft.

Du meldest dich per SSH auf der Konsole deines Raspberry Pi an und gibst den Befehl für das Backup ein. Die Aufgabe wird angestoßen und du musst warten, bis diese abgeschlossen ist. Wenn du vorher deine Verbindung zum Pi schließt, wird dein Backup abgebrochen.

Warum ist das so?

Du hast beim Anmelden quasi eine Instanz gestartet. Die ist so lange aktiv, bis sie wieder beendet wird. Beenden kannst du deine Instanz, indem die Verbindung unterbrochen wird oder das Fenster geschlossen wird.

Wird deine Instanz also nun beendet, kann deine Aufgabe nicht weiter ausgeführt werden, da sie innerhalb dieser Instanz läuft.

Du kannst dir das in etwa so vorstellen, wie ein Container, in den du Sachen packen kannst. So lange der Container in deiner Nähe ist, kannst du immer wieder etwas hineinwerfen. Wird der Container nun aber abgeholt und ist weg, kannst du nichts mehr hineinwerfen. Du brauchst erst wieder einen neuen Container. Logisch, oder?

Notebook

Das Problem wird per Cronjob gelöst

Kennst du die Aufgabenplanung unter Windows? Du kannst dort Aufgaben hinterlegen, die zu einem bestimmten Zeitpunkt ausgeführt werden. Diese Aufgabenplanung gibt es in ähnlicher Weise auch unter Linux. Man nennt es dort jedoch Cronjob.

Diesen Cronjob definierst du für einen bestimmten Zeitpunkt. Dazu nennst du deinem Raspberry Pi noch die Aufgabe, die er ausführen soll. So, wie du zu deinem Kind sagen kannst, es soll bitte die Spülmaschine nach der Schule ausräumen. (Macht man das heute noch so?)

Das Betriebssystem auf deinem Pi klappert nun kontinuierlich die Datei ab und vergleicht die aktuelle Uhrzeit mit den Angaben in deinem Cronjob. Stimmen die Daten überein, wird die Aufgabe ausgeführt.

Und siehe da, du hast ein vollautomatisches Raspberry Pi Backup.

Die Sicherung muss extern gespeichert werden

Doch wohin nun mit der Sicherung? In einen Ordner auf deinem Raspberry Pi? Ergibt das Sinn?

Wohl kaum.

Geht die Speicherkarte kaputt, wäre die Sicherung ebenfalls verloren. Dann hättest du dir den Aufwand auch direkt sparen können. Zumal das Erstellen der Sicherung deine Speicherkarte abnutzt und sie nur schneller in den Tod treibt.

Sichere die Daten daher lieber auf eine externe Festplatte * oder ein NAS * in deinem Netzwerk. Denn ein Backup im Netzwerk bietet dir viele Vorteile.

Das NAS ist im Normalfall sowieso 24 Stunden erreichbar und wartet nur auf Arbeit. Da das Ganze auch über die Netzwerkverbindung erledigt werden kann, musst du nicht einmal etwas anschließen. Clever, oder?

Exklusiv für dich:  Fernsehaufnahmen mit Raspberry Pi und NAS

Das Vorgehen bei der externen Sicherung

Bevor du extern sichern kannst, musst du deinem Pi erklären, wohin er die Datei schreiben darf. Dazu richtest du am besten auf deinem NAS eine eigene Freigabe ein, auf die der Raspberry zugreifen darf. Das ist besser, als deinen Account zu nutzen.

Danach muss die Freigabe auf dem Raspberry Pi verbunden werden. In der Linuxwelt spricht man hierbei meist von mounten. Das bedeutet im Grunde nur, dass du die Freigabe einhängst und dann darauf zugreifen kannst. Nichts Spektakuläres.

Das Mounten kannst du von deinem Sicherungsskript ausführen lassen, das zeige ich dir gleich. Dann wird die Sicherung erstellt und ganz am Ende wird die Freigabe des NAS wieder ausgehängt. Es wird keine dauerhafte Verbindung benötigt.

Exklusiv für dich:  Backups erstellen - das musst du wissen!

Die technische Umsetzung

Das Projekt ist auf Github verfügbar.

Jetzt wollen wir uns ans Eingemachte wagen. Wir erstellen zusammen ein Skript, das die Aufgaben Einhängen, Sichern und Aushängen übernimmt. Dieses Skript soll jeweils am 1. und am 15. eines Monats ausgeführt werden.

Der 1. und der 15. sind dabei kein willkürlicher Wert. Diese Tage gibt es in jedem Monat. Der 30. oder 31. hingegen fällt in manchen Monaten einfach weg. Das wäre blöd, denn dann hättest du keine Sicherung und würdest im Zweifelsfall wieder blöd aus der Wäsche schauen.

Doch nun ran an den Speck. Das Skript (entstammt der Seite raspberrypi.tips) sieht, wenn es fertig ist, wie folgt aus:

#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=USERNAME,password=PASSWORD,rw,file_mode=0777,dir_mode=0777 //IP/FREIGABE /mnt/nas
#Variablen
BACKUP_PFAD="/mnt/nas/Backup"
BACKUP_ANZAHL="5"
BACKUP_NAME="Sicherung"
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
#Festplatte auswerfen
umount /mnt/nas

Lege das Skript mit folgendem Befehl an:

nano backup.sh

Speichere es im Anschluss mit STRG + X und durch Bestätigen des Dialogs. Merke dir, wo du es abgelegt hast, den Pfad wirst du später noch brauchen.

Außerdem musst du das Skript noch ausführbar machen mit dem Befehl:

chmod +x backup.sh

Du musst nun außerdem noch den Order /mnt/nas anlegen.

Das gelingt dir ganz einfach mit dem Befehl sudo mkdir /mnt/nas. In den Ordner NAS wird später die Freigabe deines NAS-Systems eingebunden. Ohne diesen Ordner funktioniert es nicht.

Wichtige Anmerkung: Es gab bisher mehrfach das Problem, dass die Anführungszeichen im Skript falsch kodiert wurden. Solltest du Probleme haben, ersetze bitte einmal alle Anführungszeichen und probiere erneut, ob es funktioniert.

Durch die Kommentare siehst du schon direkt, was in welchem Abschnitt passiert. Ich möchte dir die Hauptbestandteile dennoch kurz erläutern.

Die Variablen

Die Variablen werden später als Platzhalter im Skript eingesetzt und sollen eigentlich nur eine Möglichkeit zur schnellen Anpassung bieten. Man sieht direkt auf den ersten Blick, wofür eine Variable steht und man kann den Wert direkt ändern, ohne lange im Code suchen zu müssen.

Wobei man fairer Weise sagen muss, dass bei so wenig Code auch ein Suchen noch möglich wäre.

Das Backup erstellen

Dank der Hilfssoftware dd lassen sich schnell Sicherungen erstellen. Die Parameter if und of stehen dabei für den Input und den Output. Das lässt sich ganz einfach merken.

Als Input wird ganz einfach die Speicherkarte des Raspberry Pi angegeben und als Output definieren wir den Pfad für das Backup, dessen Name und hängen daran noch ein Datum in der Form YYYY.mm.dd, so dass die unterschiedlichen Versionen unterschieden werden können und das Backup nicht jedes Mal überschrieben wird.

Dadurch kannst du auch auf ein älteres Backup zurückgreifen.

Alte Sicherungen löschen

Diesen Punkt kannst du theoretisch auslassen. Dadurch werden allerdings alle Backups behalten und dein NAS wird irgendwann eine Menge an Backups enthalten. Aus diesem Grund ergibt es durchaus Sinn, alte Backups zu löschen.

In diesem Skript werden fünf Backups behalten und alles was darüber hinaus geht, wird gelöscht. Fünf Backups bedeuten zweieinhalb Monate an Möglichkeiten zur Wiederherstellung.

Der letzte Schritt: die Automatisierung

Cool, du hast nun ein funktionierendes Skript, um Backups anzulegen. Jetzt musst du es nur noch automatisieren, dass es zu den oben genannten Zeitpunkten automatisch ausgeführt wird. Überlege dir schon einmal, zu welcher Uhrzeit es für dich am besten ist. Ich habe mich auf 5 Uhr am Morgen festgelegt, da auf meinem Raspberry Pi in der Nacht noch andere Skripte laufen.

Starte das Bearbeiten der Cronjobs indem du folgendes in die Kommandozeile eintippst:

sudo crontab -e

Wir legen den Cronjob mit Hilfe von sudo an, da wir so auf alle Fälle Zugriff auf jedes Verzeichnis haben werden.

Füge nun in der Datei am Ende folgende Zeilen ein:

0 5 1 * * /home/pi/Scripts/backup.sh > /dev/null
0 5 15 ** /home/pi/Scripts/backup.sh > /dev/null

Ändere bitte den Pfad deines Skripts entsprechend ab.

Die Angabe hinter dem Pfad steht übrigens dafür, dass keine Ausgabe stattfindet beim Ausführen des Skripts. Im Fehlerfall wird es natürlich dennoch eine Ausgabe geben.

Speichere nach dem Beenden deiner Eingaben auch hier die Datei durch STRG + X und das Bestätigen des Dialogs.

Erledigt, lehne dich zurück

Super gemacht! Du hast nun ein vollautomatisches Raspberry Pi Backup eingerichtet und erhältst ab sofort zwei Backups je Monat auf dein NAS. Super komfortabel und ohne Aufwand.

Was hast du für Erfahrungen mit einem Backup auf dem Raspberry Pi gemacht? Oder hast du es bislang noch gar nicht in Erwägung gezogen?

Schreib es in die Kommentare und lass uns darüber sprechen.

Summary
Raspberry Pi Backup - Vollautomatisch sichern
Article Name
Raspberry Pi Backup - Vollautomatisch sichern
Description
Hier erfährst du, wie du dein Raspberry Pi Backup einrichtest und den Rechner vollautomatisch sichern kannst.
Author
Publisher Name
Hobbyblogging
Publisher Logo
Kategorien: Computer und Digitales

Lukas

Hey, ich bin Lukas. Seit einigen Jahren schreibe ich in meinem Smart Home Blog über Hausautomation und Digitalisierung. Als Wirtschaftsinformatiker weiß ich, wie wichtig die Vernetzung von IT-Systemen ist. Diese Erkenntnisse übertrage ich auf mein eigenes Smart Home, das ich auf Basis von ioBroker betreibe. Hierzu nutze ich die Leistung eines eigenen Rackservers in meinem Keller, der alle Dienste und Smart Home Systeme aufrecht erhält. Mit ihm habe ich mir einen großen Traum erfüllen können. In deinen Ohren klingt das mindestens genauso spannend, wie für mich? Dann komm mit auf unsere Reise zu einem vollwertigen, sicheren und komfortablen Smart Home. Ganz oben findest du Verknüpfungen zu Social Media, wo du mir gerne folgen darfst. Ich freue mich auf dich!

172 Kommentare

Peter · 18. Oktober 2021 um 16:34

Hallo Lukas, habe einen Ubuntu Server 20.01 auf dem Pi4 (SD Karte) installiert. Alles soweit nach Anleitung gemacht. Den Befehl mal händisch ausprobiert, anbei das Ergebnis:

63864+1 records out
63864+1: command not found
ubuntu@ubuntu-iobroker:/$ 63864569856 bytes (64 GB, 59 GiB) copied, 4163.81 s, 15.3 MB/s
-bash: syntax error near unexpected token `(‚
ubuntu@ubuntu-iobroker:/$ sudo: pushd: command not found

Das ist meinbackup.sh user + password habe ich hier mal wieder auf default gesetzt)
:
#!/bin/bash
#Festplatte einbinden
sudo mount -t cifs -o user=username,password=password,rw,file_mode=0777,dir_mode=0777 //192.168.2.10/FTP/Pi4 /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/Backup“
BACKUP_ANZAHL=“5″
BACKUP_NAME=“Sicherung“
#Backup erstellen
sudo dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
#Alte Sicherung löschen
sudo pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
#Festplatte auswerfen
sudo umount /mnt/nas

    Lukas · 18. Oktober 2021 um 18:05

    Hallo Peter,

    mir ist offen gestanden nicht ganz klar, warum du Ubuntu Server auf einem Raspberry Pi installierst? Für den Raspberry nutzen die meisten Raspberry Pi OS.

    Du kannst mal versuchen, die Anführungszeichen zu ersetzen. In der Vergangenheit gab es da öfter mal Probleme mit dem Charset. Einfach löschen und auf der Tastatur neu eingeben.
    Sollte das nicht helfen, könnte es eventuell an den PATHs liegen oder an einem Problem mit der Bash.
    Starte das Skript auf jeden Fall mit ./meinskript.sh in der Konsole.

    Sollte das alles nicht funktionieren, bin ich für den ersten Moment auch etwas ratlos. Da kann ich dir nur folgenden Thread empfehlen, den ich im Internet dazu gefunden habe:
    linux – /bin/sh: pushd: not found

    Beste Grüße

      Peter · 18. Oktober 2021 um 19:49

      Hi Lukas, danke für die schnelle Antwort – kein Problem – habe iobroker am laufen und Ubuntu Server war mich naheliegend. Das mit den Ausrufezeichen probier ich mal aus.
      Habe noch was eingebaut und nochmal getestet – das img wird erzeugt, ist auch so groß wie meine SD-Karte – es kommt eigentlich nur der Fehler:

      sudo: pushd: command not found
      rm: missing operand
      Try ‚rm –help‘ for more information.
      ./backup.sh: line 21: popd: directory stack empty

      Also macht dieser Teil Probleme:

      sudo pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd

        Lukas · 18. Oktober 2021 um 20:21

        Hallo Peter,

        am Anfang ist es übrigens völlig normal, dass das „rm“ fehlschlägt. Erst wenn die gewünschte Anzahl von Sicherungen vorhanden ist, beginnt er mit dem Löschen.
        Vorher läuft er da noch in einen Fehler, den ich wohl besser abfangen müsste.

        Dennoch sollte pushd zumindest nicht mit dieser Fehlermeldung beendet werden. Ich hoffe du hast Erfolg mit der von mir empfohlenen Seite.

        Beste Grüße

Marcel · 8. Oktober 2021 um 22:58

Super, genau was ich gesucht habe !!!
Auch wenn dieser Beitrag schon ein paar Tage alt ist, egal hauptsache es funktioniert.
Grüße Marcel

    Lukas · 9. Oktober 2021 um 12:15

    Hallo Marcel,

    danke für das positive Feedback!

    Ja, der Artikel ist schon ein paar Tage alt. Die Infos sind aber glücklicherweise immer noch aktuell. Viel Spaß mit der Sicherung. 🙂

    Beste Grüße

Chris · 31. August 2021 um 17:24

Super, super und nochmal super. Selten ist das Einrichten von Funktionalität im Raspberry einfacher gewesen … Danke für die 1A Anleitung!

    Lukas · 1. September 2021 um 08:28

    Hallo Chris,

    vielen Dank für das positive Feedback! Und super, dass es bei dir so gut geklappt hat. Freut mich 🙂

    Beste Grüße

Pascal · 11. August 2021 um 15:45

Wie spiele ich das Backup denn wieder zurück?
LG

    Lukas · 11. August 2021 um 15:58

    Hallo Pascal,

    wie im Beitrag ganz oben erwähnt, kannst du das Image mit Win32 Disk Imager wiederherstellen. Dazu muss dann die Speicherkarte in deinen PC gesteckt werden.

    Beste Grüße

Torsten · 2. August 2021 um 21:50

Hi Lukas,

ich danke dir für die Mühe, die Du Dir mit dem Artikel gemacht hast, aber auch ich habe eine Frage. Das ist mein (naja Dein) Script:

#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=openhabian,password=XXX,rw,file_mode=0777,dir_mode=0777 //192.168.178.3/RaspberryPiPlex /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/Backup“
BACKUP_ANZAHL=“5″
BACKUP_NAME=“Sicherung“
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
#Festplatte auswerfen
umount /mnt/nas

beim direkten Ausführen mit sudo ./backup.sh kommen folgende Meldungen:

dd: konnte ‚/mnt/nas/Backup/Sicherung-20210802.img‘ nicht öffnen: Datei oder Verzeichnis nicht gefunden
./backup.sh: Zeile 11: pushd: /mnt/nas/Backup: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf ‚/mnt/nas/Backup/Sicherung*‘ nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: fehlender Operand
„rm –help“ liefert weitere Informationen.
./backup.sh: Zeile 11: popd: Der Verzeichnisstapel ist leer.

Was hab ich denn da falsch gemacht? :-/
Torsten

    Lukas · 3. August 2021 um 09:06

    Hallo Torsten,

    danke für deinen Besuch in meinem Blog.

    Die Frage wurde tatsächlich schon öfter gestellt. Dazu findest du auch den einen oder anderen Hinweis in den Kommentaren.
    Grundsätzlich deutet das Verhalten darauf hin, dass die Verbindung zum Ordner auf dem NAS nicht steht. Stelle also sicher, dass es den Share RaspberryPiPlex auf deinem NAS gibt und sich darin ein Ordner Backup befindet.
    Dann sollte die Verbindung hergestellt werden können.

    Beste Grüße

      Torsten · 11. Oktober 2021 um 17:05

      Hi Lukas,

      ich habe mich nochmal an das Thema rangemacht und bin auch etwas weiter. Ich habe mein Raspberry nicht auf SD-Karte, sondern auf einer an USB angeschlossenen SSD laufen. Also habe ich /dev/mmcblk0 auf /dev/sda1 abgeändert.

      Hier hat er jetzt nur 256 MB gesichert, aber über sda2 lief es dann… 59,2 GB… also alles paletti

      Ich danke Dir sehr für Deine Hilfe,
      Torsten

        Lukas · 11. Oktober 2021 um 18:58

        Hallo Thorsten,

        schön, dass es bei dir geklappt hat! Freut mich auch sehr, wieder von dir gelesen zu haben.

        Beste Grüße und eine schöne Woche wünsche ich dir.

Uli · 17. Juli 2021 um 10:17

Super! Vielen Dank für deine Arbeit.

    Lukas · 17. Juli 2021 um 16:43

    Hallo Uli,

    vielen Dank für das nette Feedback. Darüber habe ich mich sehr gefreut! 🙂

    Beste Grüße

GeorgW · 1. Juli 2021 um 09:03

Danke für diese tolle Anleitung! Ich habe noch einen kleinen Verbesserungsvorschlag, für diejenigen, die das Script manuell ausführen wollen, und den Sicherungs-Fortschritt beobachten wollen:

ersetze die „dd …“ Zeile mit:

dd if=/dev/sda of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB status=progress

Damit bekommt man die übertragene Datenmenge und -geschwindigkeit angezeigt.

beste Grüße
Georg

    Lukas · 1. Juli 2021 um 09:28

    Hallo Georg,

    vielen Dank für die sinnvolle Ergänzung. Da werden sich mit Sicherheit einige Leser freuen! 🙂

    Beste Grüße

Georg · 29. Juni 2021 um 12:26

Das ist super, genau danach habe ich gesucht…
Hat jemand Ahnung, wie man das umbauen müsste, wenn man nur einen Ordner mit Inhalt vom Raspi sichern möchte?
Habe eine Docker-Umgebung, und würde dort nur die wichtigsten Daten sichern wollen (nicht die Container als solches..)

    Lukas · 29. Juni 2021 um 12:34

    Hallo Georg,

    danke für deinen Besuch in meinem Blog.

    Ich habe leider momentan keinen Raspberry mehr im Einsatz, an dem ich eine solche Sicherung testen könnte. Leider.
    Aber theoretisch kannst du hierfür ein Skript nutzen, das entweder cp oder rsync einsetzt. Damit solltest du genau das machen können.

    Beste Grüße

      Georg · 29. Juni 2021 um 14:36

      Danke für die schnelle Antwort. Danke für den Hinweis, da versuche ich mich mal reinzugooglen… Hauptsache man hat mal eine Idee zu anknüpfen… 😀

        Lukas · 29. Juni 2021 um 18:50

        Hallo Georg,

        sehr gerne! Ich helfe gerne wo ich kann. Leider kann auch ich manchmal nicht die ideale Antwort liefern.
        Dafür freut es mich umso mehr, dass ich dir zumindest einen guten Tipp geben konnte.

        Viel Erfolg!

Jörg · 25. April 2021 um 10:02

Hallo, danke für die Anleitung, funktioniert tadellos. Kann man eigentlich noch eine automatische Verkleinerung per Shrink mit einbauen? Wäre ja sinnvoll, weniger Platzverbrauch auf dem NAS und keine Größenprobleme beim verwenden einer neuen SD-Card.

    Lukas · 25. April 2021 um 10:14

    Hallo Jörg,

    ja man kann noch eine Verkleinerung einbauen. Beispielsweise kurz vor Ende des Skripts wäre das möglich.
    Da ich das Skript selbst allerdings momentan nicht mehr einsetze, bin ich auch in der Weiterentwicklung nicht voran gekommen.
    Falls dich Shrink allerdings interessiert, gibts hier ein paar nützliche Infos dazu: https://github.com/Drewsif/PiShrink

    Beste Grüße

Markus · 13. April 2021 um 21:22

Hallo,
Ich bekomme nach Eingabe von: mount -t cifs -o user =raspberrypi, password=******,rw,file_mode=0777,dir_mode=0777 //192.168.178.1/FRITZ.NAS/VendorCo-ProductCode-01/iobroker /mnt/NAS

die Fehlermeldung: mount: only root can use „–options“ Option

Was habe ich falsch gemacht?

Gruß
Markus

    Lukas · 14. April 2021 um 08:43

    Hallo Markus,

    die Ausgabe verrät dir, dass du diesen Befehl ausschließlich als Administrator nutzen kannst. Wenn du den Mount-Befehl verwendest, so wie du ihn gezeigt hast, musst du davor sudo schreiben.
    Sudo gibt an, dass der Befehl mit Administratorrechten durchgeführt wird. Das Skript selbst musst du demnach auch mit sudo ausführen.

    Beste Grüße

      Markus · 14. April 2021 um 10:35

      Hallo Lukas,

      Jetzt habe der Zeile nun sudo vorangestellt und bekomme dann nach bestätigen der Befehlszeile die Fehlermeldung:

      mount error(112):H ost ist down
      Refer to the mount.cifs(8) manual page (e.g. man mount.cifs).

      Ich weiß nicht ob das wichtig ist, ich habe mich vom Laptop aus per Remotezugriff auf den Raspi geschaltet. Soll/muss ich für solche Aktionen mit Tastatur und Bildschirm direkten den Raspi Gehen? Habe ich dann mehr Berechtigungen?

        Lukas · 14. April 2021 um 11:11

        Hallo Markus,

        nein, du brauchst dazu keine Tastatur und Bildschirm direkt am Pi. Über die Konsole kannst du die gleichen Funktionen nutzen. Das kannst du dir vorstellen, wie mit einer TeamViewer-Sitzung.
        Die Fehlermeldung Host ist down sagt, dass er keine Verbindung herstellen kann. Beispielsweise weil die IP-Adresse oder ein anderer Teil falsch ist. Am besten checkst du nochmal die Netzwerkeinstellungen am Pi.

          Markus · 14. April 2021 um 16:09

          Hallo Lukas,,
          Die Netzwerkeinstelungen passen soweit. Einen gedanklichen Fehler hab ich gefunden, ich musste natürlich erst „nano Backup.sh“ aufrufen undvsann das Skript dort eingeben…. ich hatte das die ganze Zeit unter dem Prompt versucht.

          Skript ist soweit erstellt, frontal ebenfalls gesetzt. Ich hatte es vorhin mal testweise so gesetzt, dass ein Backup hätte ausgeführt werden sollen. Außer in der log-Datei um 13:00:01 einen Cronjob-Eintrag dev/null ist aber nix zu finden… ein Backup würde nicht erstellt.

          Für mich noch eine Verständnisgrage: Du hast sowohl in der dd-Befehlszeile am Ende mnt/NAS, als auch im Datei-pfad angegeben. Im Cronjob hast Du jedoch mnt/nas/skripte/Backup.sh angegeben? Das ist der Sprichertort Deines Skripte, richtig? Und die anderen nur der Übergabeort des Backups, oder?

          Lukas · 14. April 2021 um 17:08

          Hallo Markus,

          nano Backup.sh bewirkt, dass du das Skript bearbeiten kannst. Aufrufen musst du es (sofern du im gleichen Ordner wie das Skript bist) mit ./backup.sh

          Sofern kein Backup erstellt wurde rate ich dir (analog zum Kommentar von Flo), die Schritte einmal manuell nacheinander auszuführen. Da siehst du dann direkt, ob es eine Fehlermeldung gibt oder nicht.
          Möglicherweise hat sich hier noch ein Fehler eingeschlichen.

          Zu deiner Verständnisfrage: Du legst das Skript irgendwo auf deinem Pi ab. Ich habe hierzu den Ordner ~/Skripte/ genutzt. Dieser befindet sich im Homeverzeichnis des angemeldeten Benutzers (root hat kein eigenes Homeverzeichnis, seines ist das Wurzelverzeichnis / ). Wenn dein Skript also in /home/pi/Skripte/backup.sh liegt, musst du diesen Pfad aufrufen, um das Backup zu starten.
          Das Verzeichnis /mnt/nas hingegen ist der Ordner, wo dein Netzlaufwerk eingebunden wird. Wenn dein Backupordner also auf einer Festplatte an der FritzBox liegt, wird dieser Ordner dort hinein „gemountet“. Dort muss dann dementsprechend das Backup rein.
          Das Verzeichnis deines Skripts muss nicht das gleiche sein wie von der FritzBox. Das wäre auch gar nicht empfehlenswert. Denn das Skript muss VOR dem Mounten aufgerufen werden. Liegt das Skript nun im Verzeichnis das gemountet wird, kann es gar nicht ausgeführt werden. Das würde nur dann funktionieren, wenn das Verzeichnis dauerhaft gemountet ist. Das kann das Skript allerdings nicht übernehmen. Hier wäre ein kleiner Eingriff ins System notwendig.

          Ich hoffe deine Fragen konnte ich dir verständlich beantworten. Ansonsten gerne nochmal nachfragen.

          Beste Grüße

          Markus · 14. April 2021 um 18:45

          Hallo Lukas,
          Mein Skript liegt im Verzeichnis /home/pi und sieht wie folgt aus:

          #!/bin/bash
          #Festplatte einbinden
          mount -t cifs -o user=xxxxx,password=xxxxx,rw,file_mode=0777,dir_mode=0777 //192.168.178.1/FRITZ.NAS/Vendorco-ProductCode-01/iobroker/backup /mnt/nas
          #Variablen
          BACKUP_PFAD=“/mnt/nas“
          BACKUP_ANZAHL=“5″
          BACKUP_NAME=“SICHERUNG“
          #Backup erstellen
          dd if/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(Date +%Y%m%d).img bs=1MB
          #Alte Sicherung löschen
          Pushed ${BACKUP_PFAD}; 1s -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
          #Festplatte auswerfen
          Unmount /mnt/nas

          Ich habe das Backup nun mit ./Backup.sh manuell zu starten und bekomme folgende Meldungen ausgeworfen:

          mount: only Root can use „–option“ Option
          dd: nicht erkannter Operand „if/dev/mmcblk0“
          „dd –help“ liefert weitere Informationen.
          ./backup.sh: Zeile 11: pushed: Kommando nicht gefunden
          ./backup.sh: Zeile 11: Is: Kommando nicht gefunden
          rm: fehlender Operand
          „rm –help“ liefert weitere Informationen
          ./backup.sh: Zeile 11: popd: Der Verzeichnisstapel ist leer.
          ./backup.sh: Zeile 13: unmount:Kommando nicht gefunden

          Wegen des only Root… hattest Du ja schon geschrieben, dass ich hier dann den Befehl wohl per sudo machen muss. Wie schreibe ich das, damit das dann auch über den Cronjob mit Admin-rechten läuft?

          Zeile 11, pushed und unmount…. Fehlen mir hier irgendwelche Systemkomponenten die erst noch installiert werden müssen?

          Zeile 11, Is Kommando nicht gefunden? Tipp-/Lesefehler? Ich habe den Buchstaben groß i genommen, muss das ein kleines L sein?

          Lukas · 14. April 2021 um 19:02

          Hallo Markus,

          grundsätzlich eine Anmerkung zum Skript: du musst die Befehle tatsächlich so schreiben, wie sie vorgegeben sind. In deinem Beispiel fällt mir auf, dass einige Befehle am Zeilenanfang groß geschrieben sind. Beispiel Unmount und Pushed. Das musst du korrigieren.

          Dann sehe ich noch, dass bei „Backup erstellen“ das dd if keinen Abstand hat. Korrekt wäre also dd if /dev …
          Gleiche das Skript am besten nochmal mit meinem ab.

          Wenn du das Skript selbst mit root-Rechten ausführen willst, machst du das mit sudo ./backup.sh
          Sofern du es automatisieren willst, musst du den Cronjob mit sudo crontab -e anlegen.
          Alle Automatisierungen, die mit diesem Befehl abgespeichert werden (bzw. in dieser Datei), werden automatisch mit Root-Rechten ausgeführt.

          Zu deiner Frage mit dem großen I: Es muss ein ls sein (kleines L, kleines s).

          Markus · 14. April 2021 um 19:15

          Ich hatte das Skript gerade so vom Bildschirm abgetippt (hate extra aufgepasst, das die Autokorrektur vom Tablet nicht alles durchwürfelt, die waren mir doch durchgegangen) – ich weiß nämlich nicht wie ich in der Oberfläche mit Copy/Paste arbeiten kann. Im Skript stehen pushed und unmount kleingeschrieben und zwischen dd und if ist ein Leerzeichen. Kann man hier im Kommentarbereich vielleicht einen eindeutigsten Schrifttyp, zb. Courier nehmen?

          Was hat es mit den anderen Fehlermeldungen auf sich? Lese YSrsprldstri sehe ich da erdt einmal unproblematisch – da ja noch kein Backup besteht ist der Ordner zwangsläufig leer. Und die anderen Fehler?

          Lukas · 14. April 2021 um 20:04

          Ich denke die anderen Fehler hängen damit zusammen. Eindeutig identifizieren ist schwierig, weil ja die Problematik bestehen kann, dass die Fehler wiederum durch andere ausgelöst werden.

          Wenn du PuTTy nutzt, musst du den Text im Browser bspw. kopieren und dann mit einem Klick auf die rechte Maustaste einfügen. Das geht recht problemlos.
          Ob du als Kommentator andere Schriften nutzen kannst, weiß ich nicht. Im Artikel selbst geht das auf jeden Fall. Das schaue ich mir dann nochmal an 🙂

          Markus · 15. April 2021 um 23:33

          Hallo Lukas,
          es ist vollbracht – mein Backup läuft.
          Was war falsch? Hier und da noch ein paar Tipp-fehler – es heißt ja z.b. nicht unmoung sondern umount. Auch musste ich eine andere Form des dd-Befehls nehmen., die fritzbox 7390 kann nur SMB1 (!) Und FRITZ.BOX wird im Mountbefehl dann tatsächlich komplett klein geschrieben.
          Zusätzlich habe ich nun noch ein Stop vom Diensten mit eingebaut. Hier nun das komplette Skript.

          #!/bin/bash
          #Festplatte einbinden
          mount -t cifs //192.168.178.1/fritz.nas/VendorCo-ProductCode-01/iobroker/backup /mnt/nas -o username=xxxxxxxxxx,password=xxxxxxxxxx,rw,file_mode=0777,dir_mode=0777,vers=1.0
          #Variablen
          BACKUP_PFAD=“/mnt/nas“
          BACKUP_ANZAHL=“5″
          BACKUP_NAME=“SICHERUNG“
          DIENSTE_START_STOP=“iobroker“
          #Dienste stoppen
          ${DIENSTE_START_STOP} stop
          #Backup erstellen
          dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
          #Dienste starten
          ${DIENSTE_START_STOP} start
          #Alte Sicherung löschen
          pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm -f; popd
          #Festplatte auswerfen
          umount /mnt/nas

          Meine Backups werden 16GB (die Größe der SD-Karte) groß, Übetragungsdauer bei 1,1MN/s macht dann 4 h 16 min. Die Größe ist aber kein Problem für mich, ich habe da eine 2 TB-Festplatte an der Fristzbox hängen und bei 5 Backups macht das ja gerade mal 80 GB.

          Gruß
          Markus

          Lukas · 16. April 2021 um 09:54

          Hallo Markus,

          großartig, dass es nun bei dir funktioniert. Das freut mich.
          Die Erweiterung deines Skripts finde ich super, so werden die wichtigsten Dienste beendet und es entstehen keine Probleme beim Sichern.

          Das mit der Übertragung ist natürlich so eine Sache, wobei es bei einem Raspberry nicht unbedingt ein Problem ist. Schließlich hängt er – genauso wie in deinem Fall die FritzBox – sowieso 24 Stunden am Strom und hat dadurch genügend Zeit für die Sicherung.

          Beste Grüße

Flo · 8. April 2021 um 21:09

Hey,

ich habs nach bestem Wissen und Gewissen nachbauen wollen. 😉 bei mir kommt beim Ausführen des Skriptes der Fehler „./backup.sh: line 11: popd: directory stack empty“

Hier meine backup.sh

#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=pi,password=******,rw,file_mode=0777,dir_mode=0777 //192.168.1.200/Backup/pi /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/Backup“
BACKUP_ANZAHL=“10″
BACKUP_NAME=“Backup_pi“
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
#Festplatte auswerfen
umount /mnt/nas

Kann sich das jemand erklären?
Danke für die Hilfe
VG
Flo

    Lukas · 9. April 2021 um 08:48

    Hallo Flo,

    ich habe aus deinem Kommentar zur Sicherheit das Passwort für deinen Pi entfernt.

    Grundsätzlich entfernt das Skript am Ende eines Backups alte Sicherungen aus diesem Verzeichnis. Die Anzahl liegt dabei bei 10 (in deinem Beispiel). Wenn du nun in deinem Verzeichnis weniger als 10 Backups hast (oder genau 10 Backups), dann kommt eine Fehlermeldung am Ende. Das passiert da es keine Sicherung gibt, die gelöscht werden muss.
    Wenn du das Skript ausführst, siehst du am Ende des Durchlaufs dann, ob ein Backup angelegt wurde? Falls ja, musst du dir darüber keine Gedanken machen. Die Fehlermeldung ist zwar unschön, aber nicht weiter schlimm.

    Beste Grüße

      Flo · 9. April 2021 um 10:54

      Hallo Lukas,

      danke dir für deine Rückmeldung. Leider wird kein Backup erstellt. Der Ordnet auf dem NAS ist leer.
      Kann es sein das ich oben bei den Ordnern einen Fehler gemacht habe? Es gibt sowohl den Ordner /mnt/nas/Backup auf dem pi als auch den Ordner //192.168.1.200/Backup/pi auf dem NAS.
      habe ich evtl bei der Einrichtung einen Fehler gemacht? Du schreibst oben vom dd Tool. Muss das erst installiert werden oder ist das Standard bei Linux?
      Danke dir und VG
      Florian

        Lukas · 9. April 2021 um 12:07

        Hallo Florian,

        dd sollte auf dem Linux bereits vorhanden sein. Mir wäre zumindest nicht bekannt, dass es extra installiert werden muss.

        Wenn du auf deinem NAS einen Ordner hast /Backup/pi und diesen in /mnt/nas einbindest, dann erfolgt die Sicherung in den Ordner /Backup.
        Was du probieren kannst ist, dass du den Mount-Befehl händisch in der Konsole ausführst und dann den den dd-Befehl. Alle geschweiften Klammern musst du dabei natürlich händisch ausfüllen.
        Alternativ kannst du testweise den popd-Teil entfernen und das Skript nochmal ausführst. Wenn dann etwas fehlschlägt, solltest du die entsprechende Fehlermeldung sehen.

        Normalerweise sollte das Backup natürlich sichtbar sein, wenn sonst kein Fehler auftritt. Am besten schaust du mal nochmal nach, ob wirklich nichts angelegt wurde.

          Flo · 11. April 2021 um 12:22

          Hi Lucas,

          leider passiert nichts. ich bin nicht wirklich der Konsolen und Linux Spezi 😉 Ich würde gern manuell in der Konsole testen. Mich verwirrt deine Aussage mit den Klammern. Kannst du evtl die Befehle mal hier posten? Das wäre mir eine große Hilfe.
          Danke dir und VG
          Flo

          Lukas · 11. April 2021 um 13:33

          Hallo Flo,

          damit du in der Konsole testen kannst, musst du die einzelnen Schritte händisch ausführen. Das war ja sicherlich bereits klar.

          Der erste Schritt ist, die Freigabe vom NAS zu mounten. Dazu hast du den Befehl:
          mount -t cifs -o user=pi,password=******,rw,file_mode=0777,dir_mode=0777 //192.168.1.200/Backup/pi /mnt/nas
          Hier musst du natürlich dann wieder dein Passwort eintragen.

          Wenn der erste Schritt keinen Fehler liefert, kannst du zum nächsten übergehen. Hier ist ein wenig mehr Anpassung gefragt.
          dd if=/dev/mmcblk0 of=/mnt/nas/Backup/Backup_pi-11042021.img bs=1MB
          Hier siehst du, dass ich alle Variablen in den { geschweiften Klammern } ausgetauscht habe gegen deine Werte.

          Wenn auch dieser zweite Schritt erfolgreich verlaufen ist, kann es nur noch am Befehl für die alten Sicherungen liegen. Doch ich denke, dass bei dir im zweiten Schritt ein Fehler auftauchen wird.
          Mit diesem Fehler kann man dann eine genauere Fehlerüberprüfung durchführen.

          Beste Grüße

          Flo · 12. April 2021 um 18:27

          Hallo Lukas,

          bei mir muss vorher wohl schon etwas schief laufen…….ich bekommen nach „mount -t cifs -o user=pi,password=******,rw,file_mode=0777,dir_mode=0777 //192.168.1.200/Backup/pi /mnt/nas“ folgenden Fehler: „-bash: !,rw,file_mode=0777,dir_mode=0777: event not found“

          Wennich die Backup.sh ausführe folgende:
          „dd: failed to open ‚/mnt/nas/Backup/Backup_pi-20210412.img‘: No such file or directory
          ./backup.sh: line 11: pushd: /mnt/nas/Backup: No such file or directory
          ls: cannot access ‚/mnt/nas/Backup/Backup_pi*‘: No such file or directory
          rm: missing operand
          Try ‚rm –help‘ for more information.
          ./backup.sh: line 11: popd: directory stack empty“

          Kannst du dir das erklären? Da ist doch schon zu Anfang was schief gelaufen oder ;)?
          VG
          Flo

          Lukas · 13. April 2021 um 08:55

          Hallo Flo,

          entschuldige, ich habe mir die Sache erst einmal im Netz genauer angesehen.

          Wenn dein Passwort ein Ausrufezeichen enthält (ich glaube das war so?), dann setze mal ein neues Passwort ohne Ausrufezeichen. Es kann sein, dass die Shell da versucht etwas zu interpretieren. Das Ausrufezeichen steht eigentlich für eine Negierung, weshalb es da zu Fehlern kommen kann. Im Netz gibt es einige Personen, die genau dieses Phänomen haben. Dort hilft es dann nur, ein anderes Passwort ohne Ausrufezeichen zu verwenden.

          Beste Grüße

          Flo · 21. April 2021 um 15:43

          Hi Lukas,
          besten Dank für den Hinweis. Das hat geholfen. Teilweise 😉
          der erste Befehlssatz „Mount….“ läuft fehlerfrei durch.
          Der zweite „dd…“ hängt sich auf, im Terminal passiert nichts mehr.
          Wenn ich die backup.sh manuell ausführe kommt folgendes:

          root@raspberrypi:~# ./backup.sh
          mount error(13): Permission denied
          Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

          Kannst du dir da einen Reim drauf machen?

          Danke dir und VG
          Florian

          Flo · 21. April 2021 um 16:01

          PS: jetzt hast geklappt, es kommt folgende Meldung:

          ./backup.sh: line 11: popd: directory stack empty
          root@raspberrypi:/home/pi/Scripts#

          Backup ist aber angelegt, allerdings nicht aufs NAS kopiert. Woran könnte das nun wieder liegen ;)?

          Lukas · 21. April 2021 um 17:07

          Hallo Flo,

          die Meldung ist soweit korrekt, da es vermutlich noch nicht genügend Backups zum Löschen gibt.

          Wenn dein Backup nicht auf dem NAS auffindbar ist, musst du die Pfade checken. Theoretisch sollte es sich auf dem Raspi gespeichert sein, da er selbst sonst seine komplette Festplatte damit belastet.
          Eventuell befindet sich das Backup in einem Unterordner auf deinem NAS.

          Flo · 21. April 2021 um 20:22

          Hallo Lukas,

          danke für deine Antwort. Mein Verständnis wäre das er das Backup macht, auf das NAS überträgt und auf dem PI löscht…sonst Müll ich ja die SD Karte zu. Oder verstehe ich das falsch?

          Das Backup von heute ist auf dem PI zu finden, nicht aber auf dem NAS. Unterordner kann es nicht sein, da gibts keinen 😉
          Kann das ein Fehler im Code sein?? Gibts ne Möglichkeit das manuell zu checken?

          VG
          Flo

          Lukas · 21. April 2021 um 20:25

          Hallo Flo,

          ja das Backup sollte normalerweise auf dem NAS landen. Ganz automatisch.
          Dazu muss im Skript der BACKUP_PFAD auf den Pfad gesetzt werden, wo das Netzlaufwerk gemountet wird. Das gibst du weiter oben mit dem Befehl mount an (ganz hinten).
          Wenn dort steht /mnt/nas/Backup, dann muss auch der Backup-Pfad auf dieses Verzeichnis gesetzt sein.
          Ist der Ordner nicht gemountet, dann kann auch das Backup nicht auf dem NAS landen.

          Flo · 21. April 2021 um 20:34

          Hey,

          okay das war der Fehler.. zur Aufklärung falls das auch anderen passiert.

          Ich dachte wenn ich den Ordner mnt/nas/ mounte werden automatisch auch die Unterordner kopiert….werden sie aber nicht…….

          Zu deutsch der gemountete Ordner und der Backup Ordner müssen gleich sein….

          Lukas, herzlichen Dank dass du dir die Zeit genommen hast! Super!
          VG
          Flo

          Lukas · 21. April 2021 um 20:45

          Sehr gerne Flo. Ich hoffe das läuft jetzt bei dir rund und du musst nicht irgendwann doch aus der Not heraus auf die Sicherungen zurückgreifen 🙂

Kevin · 8. Februar 2021 um 17:47

Hi, vielen Dank für die Anleitung.
Falls noch jemand das Backup auf einen NFS Share machen möchte:

mount -t nfs NASIP:/volume1/Backup /mnt/backup -O user=USER,password=PASSWORT,rw,file_mode=0777,dir_mode=0777

Nutze eine Synology NAS mit dem Share Backup auf dem Festplattenverbund volume1.

    Lukas · 8. Februar 2021 um 18:04

    Hallo Kevin,

    vielen Dank für deinen Kommentar und deine Anmerkung. Ich bin mir sicher, dass sich einige darüber freuen werden 🙂

Albrecht · 26. Januar 2021 um 12:46

…Hi Lukas, auch ich habe es mittlerweile geschafft, Deine Anleitung mit ein paar Modifikationen bei mir einzusetzen. Vielen Dank dafür! Ich frage mich allerdings, ob laufende Dienste gestoppt werden sollten, damit die Sicherung möglichst keine korrupten Daten enthält. Zur Zeit habe ich auf meinem Raspi nur die Hausautomatisierungssoftware fhem unter buster am Laufen. Einen Test, das auf die von dir beschriebene Art und Weise erstellte backup zu restoren, hat eine meiner Sicherungen erfolgreich bestanden, aber das alleine heißt ja noch nichts. Was meinst Du dazu?

    Lukas · 26. Januar 2021 um 14:17

    Hallo Albrecht,

    danke für deinen Kommentar und das Feedback.

    Grundsätzlich ist es natürlich immer besser, wenn laufende Dienste gestoppt werden. Du hast dazu schon das richtige Stichwort genannt: korrupte oder beschädigte Dateien.
    Allerdings ist es innerhalb eines universellen Skripts natürlich nicht immer leicht, alle Dienste zu erfassen, da die sehr individuell sein können.

    Du kannst das Skript aber natürlich dahingehend erweitern und anpassen, dann gehst du quasi auf Nummer sicher.

    Beste Grüße

      Albrecht · 9. Februar 2021 um 08:58

      Hi Lukas, heute stelle ich fest, dass es wohl ein Berechtigungsproblem beim Löschen gibt, da das Programm bei mir nicht die Backups löscht, die über der definierten Anzahl liegen. Ich habe die Programmzeile daher direkt via ssh im Terminalprogramm ausgeführt und bekomme folgende Antwort:

      rm: cannot remove ‚/mnt/nas/RaspberryBackup–2021-01-26_04-30.img‘: Permission denied

      KannstDu mir einen Tip geben?

      VG,
      Albrecht

        Lukas · 9. Februar 2021 um 09:04

        Hallo Albrecht,

        du musst mal schauen, ob es auf deinem NAS dem User erlaubt ist, die Dateien zu löschen. Eventuell gibt es da noch eine Einschränkung (was ich fast nicht glaube).
        Dann ist natürlich noch die Frage, ob es mit sudo funktioniert. Wenn ja, dann liegt es einfach daran, dass die Dateien eigentlich dem Administrator gehören und du sie als „normaler User“ nicht löschen darfst.
        Da hilft es dann, das Skript als sudo auszuführen.

        Dazu kannst du einfach die Zeile Code mal mit sudo im Terminal ausführen und schauen, ob das Problem immer noch besteht.

          Albrecht · 9. Februar 2021 um 15:50

          Hi Lukas, vielen Dank für Deine fixe Rückinfo. Sudo allein reicht nicht aus; – mit root geht’s dann. Mittlerweile habe ich den Löschjob an die Aufgabenplanung der Synology weiterdelegiert und die Befehlszeile

          pushd /volume1/homes/pi; ls -tr /volume1/homes/pi/RaspberryBackup*.img | head -n -8 | xargs rm; popd

          dort als tägliche Job laufen.

          Vielen Dank,
          Albrecht

          Lukas · 9. Februar 2021 um 19:56

          Hallo Albrecht,

          keine schlechte Idee. Ich muss zugeben, darauf wäre ich nicht gekommen. Aber ich denke es ist eine ziemlich gute Idee, dass das die Synology übernimmt. Sie beheimatet schlussendlich ja auch die Daten.

          Beste Grüße

Björn · 17. Januar 2021 um 14:19

Hi Lukas,
vielen Dank für die das Script. Leider funktioniert bei mir etwas noch nicht und ich kann mir nicht erklären, was es ist.
Hast du eventuell noch eine Idee? Auszug aus der SSH
pi@Bienenstock:~ $ cd /mnt/nas
pi@Bienenstock:/mnt/nas $ ls
Backup
pi@Bienenstock:/mnt/nas $ cd /Scripts
pi@Bienenstock:/Scripts $ sudo bash backup.sh
dd: konnte ‚/mnt/nas/Backup/Sicherung-20210117.img‘ nicht öffnen: Datei oder Verzeichnis nicht gefunden
backup.sh: Zeile 11: pushd: /mnt/nas/Backup: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf ‚/mnt/nas/Backup/Sicherung*‘ nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: fehlender Operand
„rm –help“ liefert weitere Informationen.
backup.sh: Zeile 11: popd: Der Verzeichnisstapel ist leer.

nano backup.sh
#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=pi,password=XXXXXXX,rw,file_mode=0777,dir_mode=0777 //192.168.178.1/Jarvis/Safe1/Pi-Backup /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/Backup“
BACKUP_ANZAHL=“5″
BACKUP_NAME=“Sicherung“
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
#Festplatte auswerfen
umount /mnt/nas

Wenn ich eine Datei in Windows in den Ordner lege, kann ich diese sehen.
pi@Bienenstock:/mnt/nas $ ls -la
insgesamt 4
drwxrwxrwx 2 root root 0 Jan 17 14:16 .
drwxr-xr-x 3 root root 4096 Jan 17 10:41 ..
-rwxrwxrwx 1 root root 346175 Feb 17 2016 Fotografie_Spiecker.png

Grüße aus dem Norden
Björn

    Lukas · 17. Januar 2021 um 18:31

    Hallo Björn,

    schön, dass du hier in meinen Blog gefunden hast!

    Was du mal ausprobieren kannst ist, dass du eine Textdatei über den Pi im Verzeichnis /mnt/nas/Backup erstellst. Sollte das nicht funktionieren, hat der User Pi eventuell nicht die Berechtigung, um in den Ordner schreiben zu dürfen.
    An sich sieht dein Skript gut aus und ich denke, dass es daran scheitern könnte.

    Die Meldung bezüglich dem rm ist übrigens okay, da noch kein Backup angelegt wurde. Ist zwar unschön, aber hindert das Skript nicht an seiner Arbeit. Sobald die Anzahl der Backups erreicht ist, wird auch dieser Fehler verschwinden.

    Beste Grüße!

      Björn · 18. Januar 2021 um 14:47

      Hi Lukas,

      habe den Fehler gefunden. Warum auch immer muss ich mich irgendwo vertan haben, oder was auch immer.
      Der „Backup“ Ordner wurde zwar in mnt/nas/ angelegt und ich konnte dort auch Dateien sehen und ändern.
      Der Ordner war aber auch direkt hinter dem localhost also: pi@Bienenstock:/Backup $
      Also ich den Pfad in der backup.sh geändert hatte, auf diese Angabe, lief alles Problemlos.

      Danke dir und weiter so!
      Gruß
      Björn

        Lukas · 18. Januar 2021 um 14:49

        Hallo Björn,

        super, dass es geklappt hat und du den Fehler finden konntest.

        Wir lesen uns sicherlich mal wieder. Bis dahin alles Gute und bleib gesund! 🙂

Sebastian · 13. Januar 2021 um 09:47

Vielen Dank für das tolle Script. Es funktioniert 1A. Danke und weiter so!

    Lukas · 13. Januar 2021 um 10:04

    Hey Sebastian,

    vielen Dank für das positive Feedback. Freut mich, dass es bei dir so gut funktioniert!

    Beste Grüße 🙂

Robert · 5. Januar 2021 um 12:04

Toller Tipp! hat mir gleich geholfen.
Danke vielmals dafür!

    Lukas · 5. Januar 2021 um 12:11

    Hallo Robert,

    freut mich sehr, dass ich dir mir meinem Artikel weiterhelfen konnte.
    Ich hoffe man liest sich wieder! 🙂

Holger · 15. Dezember 2020 um 10:55

Hallo zusammen ich bekomme es leider auch nicht hin
ich habe eine Raspi 4
Im Hauptverzeichnis meiner Raspi habe ich einen Ordner angelegt /mnt/nas
die backup.sh ebenso im Hauptverzeichnis
Auf meinem NAS (Synology) ist ein Ordner mit Schreibrechten „Sicherungen“ .

mein backup.sh sieht folgendermaßen aus:

#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=XXXXXX,password=XXXXXX,rw,file_mode=0777,dir_mode=0777 //192.168.178.123/sicherungen /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/sicherungen“
BACKUP_ANZAHL=“5″
BACKUP_NAME=“Sicherung“
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
#Festplatte auswerfen
umount /mnt/nas

nun kommt folgende Fehlermeldung wenn ich die Backup.sh starte:

mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
dd: failed to open ‚/mnt/nas/sicherungen/Sicherung-20201215.img‘: No such file or directory
backup.sh: line 11: pushd: /mnt/nas/sicherungen: No such file or directory
ls: cannot access ‚/mnt/nas/sicherungen/Sicherung*‘: No such file or directory
rm: missing operand
Try ‚rm –help‘ for more information.
backup.sh: line 11: popd: directory stack empty
umount: /mnt/nas: not mounted.

an was kann es liegen ?

Grüße Holger

    Lukas · 15. Dezember 2020 um 21:48

    Hallo Holger,

    entschuldige die späte Rückmeldung von mir.

    Führe mal den Mount-Befehl alleine aus und schau mal, was dabei raus kommt. Eventuell bekommst du da dann eine etwas detailliertere Fehlermeldung von deinem Pi ausgegeben.

      Holger · 16. Dezember 2020 um 07:09

      Kein Stress Lukas danke für die Rückmeldung……

      wenn ich nur den mount befehl eingebe Passwort und User habe ich natürlich eingetragen kommt folgendes :
      mount error(95): Operation not supported
      Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

      Grüße Holger

        Lukas · 17. Dezember 2020 um 08:47

        Hallo Holger,

        ich konnte nun etwas zu der Thematik recherchieren. Möglicherweise gibt es hier ein „Problem“ mit der SMB-Version.
        Schau mal dazu bitte auf deiner Synology welche Version sie für SMB verwendet. Diese Version muss dann eventuell noch an den Mount-Befehl im Skript angehängt werden.
        Beispiel:

        mount -t cifs -o user=XXXXXX,password=XXXXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.178.123/sicherungen /mnt/nas

        Und das Skript dann natürlich per Sudo ausführen.

        Beste Grüße!

          Holger · 18. Dezember 2020 um 09:47

          Hallo Lukas ,
          Vielen Dank prima funktioniert jetzt !
          Tatsächlich war es die Vers=3.0

          Danke LG

          Lukas · 18. Dezember 2020 um 09:59

          Hey Holger,

          super, dass es geklappt hat und viel Spaß mit deinem Raspberry Pi 🙂

Michael · 1. November 2020 um 20:27

Hallo,
ich habe das ganze gerade auch ausprobiert und bin nach einigen Fehlern, die hier schon beschrieben waren und die ich daher lösen konnte, auch auf eine Fehlermeldung gestoßen, die hier noch nicht auftauchte:
Ich habe das Script testweise manuell gestartet. Es läuft und schreibt eine img-Datei auf das NAS, die knapp so groß ist wie die Speicherkarte. Am Ende kommt aber die Meldung:

dd: Schließen der Ausgabedatei ‚/mnt/nas/Backup/Sicherung-20201101.img‘: Eingabe-/Ausgabefehler

Kann das jemand zuordnen? Ich habe noch nicht versucht, die generierte img-Datei wiederherzustellen, aber das klingt schon so, als wäre irgendwas nicht in Ordnung, oder?

    Lukas · 3. November 2020 um 09:50

    Hallo Michael,

    das klingt für mich danach, als ob die Datei auf dem Pi danach noch „geöffnet“ ist.
    Zuordnen kann ich das im Moment leider gar nicht. Da müsste ich nochmal nachschauen.

    Was du mal probieren kannst, ist eine Datei in /mnt/nas händisch anzulegen. Beispielsweise mit nano.
    Es könnte sein, dass es hier zu Rechteproblemen gekommen ist. Das kann man so ziemlich schnell erkennen.

Harpo · 23. Oktober 2020 um 18:41

Sehr schöne Anleitung! Leider produziert das Skript eine Fehlermeldung, die ich als Linux-Neuling nicht deuten kann.
dd: failed to open ‚/mnt/nas/Backup/Sicherung-20201023.img‘: No such file or directory
das Verzeichnis ‚/mnt/nas/‘ existiert . Das Mounten produziert ebenfalls keine Fehlermeldung. Aber die Sicherungsdatei wird nicht geschrieben.

    Lukas · 23. Oktober 2020 um 18:47

    Du mountest dein NAS in den Ordner /mnt/nas. Schau mal bitte nach, ob in diesem Zielorder der Unterordner Backup existiert.
    Ich nehme an, dass dieser Ordner fehlt und deshalb das Backup fehlschlägt.

    Sollte das nicht helfen, melde dich gerne nochmal! 🙂

      Harpo · 23. Oktober 2020 um 19:42

      Leider habe ich die gleiche Fehlermeldung bei existierendem Verzeichnis ‚Backup‘.

        Lukas · 23. Oktober 2020 um 19:56

        Kannst du mir mal dein Skript zukommen lassen? Entweder hier in den Kommentaren oder per E-Mail.
        Nimm dazu am besten das Passwort raus 😉

          Harpo · 24. Oktober 2020 um 15:36

          Hier ist das Skript:

          #!/bin/bash
          #Festplatte einbinden
          mount -t cifs -o user=USER,password=PASSWORD,rw,file_mode=0777,dir_mode=0777 //192.168.178.94/BackupOpenHab /mnt/nas
          #Variablen
          BACKUP_PFAD=“/mnt/nas/Backup“
          BACKUP_ANZAHL=“5″
          BACKUP_NAME=“Sicherung“
          #Backup erstellen
          dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
          #Alte Sicherung löschen
          pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
          #Festplatte auswerfen
          umount /mnt/nas

          Im Prinzip eigentlich 1:1 Dein Skript, oder?

          Harpo · 24. Oktober 2020 um 15:39

          Und hier ist die komplette Fehlermeldung:

          dd: failed to open ‚/mnt/nas/Backup/Sicherung-20201024.img‘: No such file or directory
          backup.sh: line 11: pushd: /mnt/nas/Backup: No such file or directory
          ls: cannot access ‚/mnt/nas/Backup/Sicherung*‘: No such file or directory
          rm: missing operand
          Try ‚rm –help‘ for more information.

          Lukas · 24. Oktober 2020 um 18:56

          Im Grunde ist das 1:1 mein Skript, da hast du soweit recht. Lediglich der Name der Freigabe auf dem NAS unterscheidet sich, das ist aber unproblematisch.
          Ich möchte nur nochmal zum Verständnis nachhaken, wenn du in der Freigabe BackupOpenHab bist, siehst du dort einen Ordner der Backup heißt?

          Du kannst den mount Befehl aus dem Skript mal händisch in die Konsole des Pi eingeben und dann mit cd /mnt/nas in den Ordner navigieren. Wenn du jetzt cd eingibst, solltest du einen Ordner namens Backup sehen.
          Im Moment kann ich es mir leider gar nicht anders erklären, als dass dieser Ordner im Verzeichnis fehlt.

          Entschuldige, dass ich dahingehend nochmal nachfrage. Aber gerade bei Freigaben und Verzeichnissen kommt es häufig mal zu Missverständnissen. Ich hoffe das kannst du nachvollziehen.

          Harpo · 26. Oktober 2020 um 12:44

          Tatsächlich. Es war nur der Ordner ‚Backup‘, der im Verzeichnis fehlte. Ich hatte den Ordner im falschen Verzeichnis angelegt. Vielen Dank für die schnelle Hilfe. Das Backup läuft jetzt.

          Lukas · 26. Oktober 2020 um 19:02

          Sehr gerne!

Anonymous · 7. September 2020 um 23:30

DEEB

Hallo, 2 Fragen beschäftigen mich.
1. Funktioniert das Backup erstellen auch wenn ein Berryboot mit mehreren Systemen auf den Raspi läuft?
2. Wie kann ich Daten mit dem Backup sichern, die ich z.B. auf einem USB Stick, (der an dem zu sichernden Raspi angeschlossen ist) mit sichern?

    Lukas · 8. September 2020 um 09:15

    Bei deiner ersten Frage bin ich mir leider nicht ganz sicher, da ich die Konstellation nicht getestet habe.

    Für eine Sicherung eines Sticks ist das Backup nicht gedacht. Hier müsste ein extra Skript erstellt werden, das gezielt einen Mountpunkt (in diesem Fall den USB-Stick) sichert.

      DEEB · 9. September 2020 um 00:46

      Hallo Lukas, danke für die schnellen Antworten.

      zu 1. Schade, wäre aber sicher auch für andere Interessant. Habe auf zwei von 4 Raspi’s ein Berryboot mit mehreren Systemen (Raspian mit GUI und Raspian-Light mit Nextcloud und FHEM bzw. Raspian mit GUI und Raspian-Light mit OMV-NAS Server) zu laufen. Eine Image Datei wird durch dein BackupProgramm erzeugt! Habe aber noch nicht getestet, ob sich dieses auch wieder auf eine SD Karte zurückspielen lässt und dann auch noch funktioniert. Vermute so einfach wird das nicht gehen. Im Berryboot Startscreen gibt es unter Edit eine Funktion zum Clonen von Berryboot SD-Karten.
      Wenn es hierzu neue Erkenntnisse oder Fragen gibt, würde ich mich über eine Info von dir sehr freuen.
      zu 2. ist sicherlich möglich, dann wäre es aber eine individuelle Bastel-/Einzellösung. Ein universeller / generischer Ansatz wäre hierfür natürlich besser und wünschenswert.
      Aber dafür reichen meine Linux-Kenntnisse nicht aus.

      3. Hast du dich schon mal mit pshrink beschäftigt? Damit kannst du wohl ein Image erzeugen, das nur so groß ist, wie Daten tatsächlich vorhanden sind. Das Image wird dann nicht so groß wie die teilweise noch unbeschriebene SD-Karte. Wäre interessant wenn sich das in dein Backup-Script mit integrieren lässt.

      Viele Grüße DEEB

        Lukas · 9. September 2020 um 08:46

        Guten Morgen,

        in der Tat wäre eine Lösung zur Sicherung eines USB-Sticks sehr interessant. Aktuell nutze ich allerdings nur die interne SD vom Pi, daher kam dieser Einsatzzweck bei mir noch nicht in Betracht.
        Wenn ich doch mal etwas Zeit habe könnte ich mir aber vorstellen, dass ich hierfür ein Skript baue. Mal schauen. Momentan ist meine Zeit da leider sehr begrenzt.

        Mit pishrink habe ich mich bislang noch nicht befasst. Das hat den Hintergrund, dass ich intern mit einem Datenserver arbeite, der 10 TB Speicher zur Verfügung stellt und ich die Anzahl der Backups begrenze.
        Sicherlich wäre auch das eine gute Idee. Ich kann mich allerdings nur so weit vortasten, wie ich die Skripte selbst verwende. Ich möchte keine Skripte erstellen, die ich nicht selber nutze oder auf Herz und Nieren teste.
        Sonst könnte ich etwas einfach nicht guten Gewissens weiterempfehlen 😉
        Wenn bei dir das Argument des Speichers im Vordergrund steht wäre für mich im Moment die Alternative zu sagen, dass du die Anzahl der Backups beispielsweise auf 3 anstatt auf 5 begrenzt. Das ist zwar nicht die Lösung dazu, dient aber als Workaround vorerst.

        Danke für deinen wertvollen Input! 🙂

Alfons · 2. August 2020 um 22:22

Kleiner Tipp – macht die Größen erträglich

dd if=/dev/mmcblk0 bs=1MB | gzip > ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img.zip

    Lukas · 3. August 2020 um 08:56

    Hallo Alfons,

    danke für die Anmerkung! Ich glaube da werden dir sicherlich eine Leser dankbar sein 🙂

Flo · 8. Juli 2020 um 13:58

Hi Lukas,

vielen Dank für die tolle Anleitung! Läuft! Ich hätte nur eine Frage. Welches Programm nimmst du her um ein image wieder herzustellen, falls nötig?
Gruß, Flo

    Lukas · 8. Juli 2020 um 17:24

    Hallo Flo,

    du kannst zur Wiederherstellung beispielsweise BalenaEtcher verwenden. Der Win32 Disk Imager erfüllt aber genau die gleiche Aufgabe.
    Tools hierzu wirst du jede Menge finden. Ich persönlich empfand den BalenaEtcher bislang als die beste Möglichkeit. Das Tool gefällt mir persönlich einfach sehr gut.

      cosmic spawn · 17. September 2020 um 16:40

      Hi,

      danke für das Tutorial! Ich hätte noch eine kleine Ergänzung zur Sicherheit. Da im skript Username und Passwort stehen, sollte man das ganze in eine Authentifikationsdatei auslagern und dafür entsprewchende rechte vergeben (600).
      Hier beschrieben: https://wiki.ubuntuusers.de/Samba_Client_cifs/
      Eigentlich sollte das mounten doch auch um die fstab der Raspberry möglich sein, oder? Ich hab das leider noch nicht getestet. Darum nur als Anregung!
      LG

        Lukas · 17. September 2020 um 17:54

        Danke für das Feedback!

        Du hast natürlich recht, dass unter Sicherheitsaspekten die Zugangsdaten ausgelagert werden sollten.
        Zur Einfachheit habe ich diesen Schritt weggelassen. Am Skript selbst kann man sich allerdings je nach Kenntnissen und Interesse weiter austoben und es jederzeit verbessern. Dazu ist der Code auf GitHub verfügbar.

    Cosmic Spawn · 17. September 2020 um 16:21

    Hi,

    das ganze sollte doch auch einfach wieder mit dem dd-Befehl zu machen sein, oder? Als Quelle die Datei und als Ziel die leere SD-Karte.
    Also ungefähr so:
    $ sudo dd if=/backup/pfad/backup-20200917.img of=/dev/sdx bs=1MB && sync

      Lukas · 17. September 2020 um 17:53

      Theoretisch sollte das möglich sein. Ausprobiert habe ich es nicht. Ich denke die meisten werden die SD-Karte am Windows-PC befüllen und in einen anderen Pi stecken. Daher habe ich mich auch in meinem Beitrag auf diese Möglichkeit beschränkt.
      Der Vorteil liegt außerdem ganz klar in der Bedienbarkeit. Denn eine GUI ist deutlich leichter zu handhaben als die Kommandozeile. 🙂

Dirk Mohrdiek · 7. Juli 2020 um 05:27

Ich habe das Skript implementiert, funktioniert prima soweit. Allerdings legt das Skript IMG-Dateien mit vollständiger Größe der Speicherhkarte an, in meinem Fall 128 GB. Und die Karte ist bei weitem nicht voll, ein df -h zeigt ca. 10% Auslastung. Bei 5 vorgehltenen Versionen kommt da mächtig was zusammen, was dann auch wieder zusammen mit dem Backup des NAS gesichert werden muss. Hat jemand eine Idee dazu?

    Lukas · 7. Juli 2020 um 09:08

    Hallo Dirk,

    ja bei 128 GB kommt wirklich einiges zusammen. Das Tool erstellt ein 1:1 Abbild der Speicherkarte, weshalb dieses so groß ist.
    Man könnte es mit den Tools von Linux packen und so zumindest etwas Speicher einsparen. Eine andere Lösung habe ich im Moment leider nicht parat, außer dass du nur benötigte Dateien per Befehl kopierst.
    Hier bräuchte man dann allerdings ein anderes Skript.

      Dirk Mohrdiek · 7. Juli 2020 um 20:19

      Danke für die schnelle Antwort. Hier hilft wohl am besten eine passende, kleinere Speicherkarte.

        Lukas · 8. Juli 2020 um 17:23

        Hallo Dirk,

        ich denke auch, dass eine kleinere Speicherkarte helfen würde, sofern du die große Karte sowieso nicht voll bekommst.

        Alex · 4. August 2020 um 10:52

        Hi,
        man es auch mit pishrink auf die tatsächliche Größe schrumpfen.
        https://github.com/Drewsif/PiShrink

          Lukas · 4. August 2020 um 11:44

          Hallo Alex,

          vielen Dank für diesen Hinweis! 🙂

      sm0k0 · 9. Juli 2020 um 09:50

      Hallo,
      schönes Script.
      Um das Ziel File „on the Fly“ zu komprimieren braucht man das DD nur durch einen Kompressor wie gzip zu pipen, dann sähe der Befehl so aus:
      dd bs=1M iflag=fullblock if=dev/mmcblk0 | gzip -c > ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img.gz
      Es sei darauf hingewiesen das eine Kompression den Raspi ganz schön beschäftigen kann, der Vorgang wird sich daher verlangsamen.

        Lukas · 9. Juli 2020 um 12:09

        Vielen Dank für diese wertvolle Anmerkung!

        In der Tat verlangsamt das den Prozess wesentlich, wobei das je nach Einsatzgebiet des Pis verkraftbar ist.

Olaf · 4. Juni 2020 um 10:42

Danke, das Script läuft ans sich gut. Ich hab’s mal testweise ausgeführt und schon nach der ersten Sicherung kommt ein Fehlermeldung zum „rm“:

pi@raspberrypi:~ $ sudo ./pi-backup.sh
31914+1 Datensätze ein
31914+1 Datensätze aus
31914983424 bytes (32 GB, 30 GiB) copied, 714,566 s, 44,7 MB/s
/mnt/nas/Backup /home/pi
rm: fehlender Operand
„rm –help“ liefert weitere Informationen.
/home/pi

Ich nehme an, es ist der Aufräumteil vom Script, wobei der ja noch gar nicht ausgeführt werden sollte.
Mein Linux-Kernel ist 4.19.118-v7l+
Oder kann man das ignorieren?

    Lukas · 4. Juni 2020 um 14:32

    Hallo Olaf,

    deine Vermutung ist korrekt. Das liegt daran, dass es noch keine Sicherungen zum Löschen gibt.
    Man könnte an der Stelle natürlich eine Überprüfung einbauen, um diesen Fehler zu vermeiden.

    Du kannst den Fehler ignorieren, spätestens beim Backup X (je nachdem, welche Anzahl bei dir festgelegt ist), wird alles ohne Fehler ausgeführt.

      Olaf · 5. Juni 2020 um 12:49

      Alles klar, danke für deine Antwort.

Mika · 28. März 2020 um 13:32

Hallo,

Ich bin gerade etwas am „verzweifeln“. Ich habe das Script übernommen mit Vers=2.0 hier aus den Kommentaren, Daten alle angepasst, aber das Skript meldet beim ausführen zurück

/bin/bash: Festplatte einbinden : Datei oder Verzeichnis nicht gefunden

Ich habe wie der andere User ein Verzeichnis im Homeverzeichnis angelegt unter /home/pi/nas_back, dieses auch im Skript angegeben, aber nix da. Auf der Synology sind auch alle Verzeichnisse angelegt und freigegeben für den User.

Wenn ich den mount Befehl manuell eingebe auf dem Pi mounted er das Verzeichnis. Führe ich dann wieder das Skript aus, kommt wieder dieselbe Fehlermeldung. So langsam bin ich mit meinem Latein am Ende.

    Lukas · 28. März 2020 um 13:44

    Hallo Mika,

    tut mir leid, dass du so eine Verzweiflung hast. Wir bekommen das sicherlich zusammen hin!

    Probiere bitte als erstes Mal einen Ordner ohne einen Unterstrich. Eventuell funktioniert das mit dem Skript nicht so richtig.

    Micha · 29. Mai 2020 um 02:52

    #!/bin/bash
    #Festplatte einbinden
    sudo mount -t cifs //sds.fritz.box/BPi /home/pi/NAS -o user=(DEIN BENUTZERNAME),password=(DEIN PASSWORT)
    #Variablen
    BACKUP_PFAD=“/home/pi/NAS“
    BACKUP_ANZAHL=“3″
    BACKUP_NAME=“SD-SicherungPI“
    #Backup erstellen
    sudo dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs$
    #Alte Sicherung löschen
    pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP$
    #Festplatte auswerfen
    sudo umount /home/pi/NAS

Mike · 14. März 2020 um 20:15

Hallo Lukas,

erstmal vielen Dank für deine Anleitung. Irgendwo scheint sich bei mir ein Fehler eingeschlichen zu haben. Ich erhalte aktuell folgende Fehler, nachdem der eigentliche Backup Job abgeschlossen ist.

Ich habe gerade 4 Mal den Job ausgeführt und die Dateien manuell umbenannt, falls es daran liegen sollte. Es gibt ein Problem mit pushd und popd:

+ pushd /home/pi/DiskStation/Backup
/home/pi/Scripts/backup.sh: 13: /home/pi/Scripts/backup.sh: pushd: not found
+ head -n -3
+ xargs rm
+ ls -tr /home/pi/DiskStation/Backup/Sicherung-20200311.img /home/pi/DiskStation/Backup/Sicherung-20200312.img /home/pi/DiskStation/Backup/Sicherung-20200313.img /home/pi/DiskStation/Backup/Sicherung-20200314.img
+ popd
/home/pi/Scripts/backup.sh: 13: /home/pi/Scripts/backup.sh: popd: not found

    Lukas · 14. März 2020 um 20:34

    Hallo Mike,

    rufst du das Script auch mit ./Script.sh auf?
    Alternativ kannst du es mal versuchen mit bash Script.sh

    Beachte bitte auch, dass zum Beginn des Skripts die Angabe der /bin/bash enthalten ist.

    Sollte das nicht die Lösung bringen, lass es mich gerne nochmal wissen.

      Mike · 15. März 2020 um 14:26

      Hallo Lukas,

      das war es, danke für den Wink. Ich hab es wohl mit sh statt bash gestartet.

      Ich würde gerne die Löschzeile besser verstehen, doch bekomme ich die einzelnen Schnipsel noch nicht zusammen.

      PS: Den Post von 20:36 kannst du löschen.

      Danke!

        Lukas · 15. März 2020 um 15:39

        Hallo Mike,

        im Grunde wird gezählt, wie viele Sicherungen bereits im Ordner existieren. Sofern die maximale Anzahl erreicht ist, werden dann die alten Sicherungen gelöscht.
        Damit lässt sich der Speicherplatzverbrauch eindämmen, so dass dein Speicher nicht komplett vollläuft.

          Mike · 27. März 2020 um 11:08

          Hallo Lukas,

          ich frage mich gerade, wieso sich nahezu alle Artikel auf Win32DiskImager beziehen, doch könnte man doch auch balenaEtcher oder Raspberry Pi Images nutzen, um die Sicherung wiedereinzuspielen?

          Danke!

          Lukas · 27. März 2020 um 13:01

          Hallo Mike,

          ja, absolut richtig. Auch der balenaEtcher kann diese Aufgabe erfüllen. Er kann außerdem auch noch ein vollständiges Image der SD-Karte machen.
          Ich habe dazu schon einen Beitrag im Kopf, bin aber leider noch nicht zur Umsetzung gekommen.

Alexander · 6. März 2020 um 10:47

Hallo Lukas!
Super script – läuft tadellos.
Lässt sich das img für restore 1:1 auf neue SD schreiben?

    Lukas · 6. März 2020 um 10:59

    Hallo Alexander,

    danke für das Feedback 🙂

    Mit dem richtigen Tool ist das möglich, ja. Beispielsweise mit dem balenaEtcher.
    Es gibt allerdings Berichte von Nutzern, die mit dem Skript keinen so großen Erfolg hatten.
    Die sicherste Methode für ein Backup bleibt daher, ein Image mit dem balenaEtcher zu machen, wenn der Raspberry Pi ausgeschaltet ist.
    Dazu plane ich schon einen Beitrag, der in den nächsten Wochen erscheinen soll.

      Alexander · 7. März 2020 um 12:00

      Hi! mit
      sudo dd bs=1m if=/pfad/Sicherung-YYYYMMDD.img of=/dev/rdiskN conv=sync
      erfolgreich wieder hergestellt. (N=nummer des dev)

        Lukas · 7. März 2020 um 13:00

        Super, danke dir für die Rückmeldung! Das sind auf jeden Fall gute Nachrichten 🙂

s.p · 3. März 2020 um 19:26

Super, vielen Dank!

Stefan · 17. Februar 2020 um 09:48

Ich kann keine Netzlaufwerke mounten auf meinem pi
ich bekomme immer die Fehlermeldung:
sudo mount -t cifs //192.168.178.38/restricted /media/test/ -o user=piUser
Password for piUser@//192.168.178.38/restricted: ***************
mount error: cifs filesystem not supported by the system
mount error(19): No such device
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
kann mir da jemand helfen ? Habe das Netz schon fleißig durchstöbert, aber da gibts auch keine konkrete Lösung, es wird nur diskutiert.
Weder unter dem NAS noch dem Pi steht in der /proc/filesystems was von gifs
unter meinem Mac z.b. lässt sich das Laufwerk ohne Probleme mounten.

    Lukas · 17. Februar 2020 um 18:43

    Hallo Stefan, probiere mal den folgenden Befehl aus dem Skript oben:

    mount -t cifs -o user=USERNAME,password=PASSWORD,rw,file_mode=0777,dir_mode=0777 //IP/FREIGABE /mnt/nas

    Tausche dazu bitte die entsprechenden Werte gegen deine aus. Ich hoffe du hast damit Glück! 🙂

    Michi · 27. März 2021 um 00:15

    Eventuell verwendet Dein NAS noch ein veraltetes SMB Protokoll. Ab Raspberian Stretch wird 2.1 oder höher erwartet.

    Option 1: Verwende das veraltete Protokoll (sollte man aber aus sicherheitsgründen nicht tun)
    sudo mount -t cifs -o vers=1.0 //192.168.178.38/restricted /media/test/ -o user=piUser
    oder
    sudo mount -t cifs -o vers=2.0 //192.168.178.38/restricted /media/test/ -o user=piUser

    Option 2: Richte Dein NAS auch für SMB 3 ein (bei der Synology unter Systemsteuerung -> Dateidienste -> SMP/AFP/NFS -> Erweiterte Einstellungen -> Maximales SMB-Protokoll: SMB3)

      Lukas · 27. März 2021 um 09:11

      Hallo Michi,

      vielen Dank für deine hilfreiche Antwort! 🙂

megaheinrich · 11. Februar 2020 um 17:39

Hallo!
Danke für das tolle Skript!
Bin kein großer Linux Profi – spiel mich nur ein wenig mit Raspi’s herum – „Hausautomation für arme“ 🙂
Funktioniert soweit – bis 4,3 GB – dann Fehlermeldung – zuwenig Speicher – hab 2 T SSD san an Fritzbox 6890 – welche nahezu leer ist!

dd: Schreiben von „/media/mount/FRITZSSD/Raspi/backup/RaspiWZ-20200211.img“: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
4295+0 Datensätze ein
4294+0 Datensätze aus
4294917504 Bytes (4,3 GB) kopiert, 815,634 s, 5,3 MB/s
/media/mount/FRITZSSD/Raspi/backup ~
rm: fehlender Operand
„rm –help“ gibt weitere Informationen.
~
umount: /media/mount is not in the fstab (and you are not root)

Hat jemand Idee warum bei 4,3 GB Schluss ist?
Gruss Heinz

    Lukas · 11. Februar 2020 um 22:28

    Hallo Heinz,

    ja, tatsächlich habe ich dazu eine Idee, wieso bei knapp 4 GB Schluss ist.
    Schau mal bitte nach, welches Dateisystem du verwendest. Bei FAT ist eine Begrenzung der einzelnen Dateigröße vorhanden.
    Ein Image mit dieser Sicherung hat aber mehr als 4 GB, weshalb die Sicherung abbricht.

      Megaheinrich · 12. Februar 2020 um 12:02

      Danke für die prompte Antwort!
      Ja – jetzt hab ich‘s auch auf der avm Seite gelesen…

      Gruß Heinz

        Lukas · 12. Februar 2020 um 12:13

        Hallo Heinz,

        fragen kostet nichts 😉
        Manchmal ist es auch nicht leicht den Überblick zu behalten.

        Ich wünsche dir viel Erfolg bei deinem Backup.

tam · 18. November 2019 um 00:09

Ich habe diese Script verwendet und regelmäßig Backups gemacht. Nun habe ich ein Backup via dd wieder auf die gleiche SD Karte gespielt und siehe da, der Pi bootet davon nicht. Habe noch andere Backups getestet, gleiches Problem.
Wer also diese Backups dazu nutzen will sich im Fall der Fälle eine Neuinstallation zu sparen, liegt falsch. Ich muss mir nun eine neue Lösung überlegen…

    Lukas · 18. November 2019 um 07:10

    Interessant wäre an der Stelle, was für ein Fehler denn angezeigt wird bzw. wo er ins Stocken kommt.
    Hast du eine SD-Karte der gleichen Größe genutzt, die auch gleich formatiert ist? Ich denke die Größe der Blöcke sind hier ausschlaggebend.
    Du kannst ein solches Backup nicht nur mit dd wiederherstellen, sondern auch mit Win32 Disk Imager.

Gerd · 6. November 2019 um 13:57

Hallo,

bei mir hat das Backup-Script – wie bei einigen anderen hier – nicht funktionieren wollen, obwohl ich es 1:1 kopiert und dann die im Guide beschriebenen Punkte angepasst habe. Ich habe es mit einem Raspberry Zero WH und einem Synology NAS probiert und nun läuft es. Im Prinzip müssen die Befehle per sudo ausgeführt, ein paar Pfade geändert und GANZ WICHTIG (bei mir), der mount Befehl um vers=2.0 erweitert werden. Zumindest Synology unterstützt wohl nur Samba bis 2.0. Den Ordner „nas“ habe ich vorher im /home/pi/ Verzeichnis erstellt. Wie dem auch sei, hier der Code:

#!/bin/bash
#Festplatte einbinden
sudo mount -t cifs //IP-NAS/FREIGABEORDNER /home/pi/nas -o user=USERNAME,password=PASSWORT,rw,vers=2.0
#Variablen
BACKUP_PFAD=“/home/pi/nas/“
BACKUP_ANZAHL=“5″
BACKUP_NAME=“SD-System-Sicherung“
#Backup erstellen
sudo dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
#Festplatte auswerfen
sudo umount /home/pi/nas

Für die, die Ahnung haben: Über Kritik bin ich sehr dankbar.

Bis dann.

    Lukas · 6. November 2019 um 21:35

    Hallo Gerd,

    danke für die Anmerkung und die Verbesserung. Das mit der Version ist natürlich bei einigen Geräten ein entscheidender Knackpunkt.

    Micha · 29. Mai 2020 um 02:14

    Hey Gerd! Ich habe einige Skripte probiert und bin fast verzweifelt, bis ich auf Deines, bzw. Lukas hat den Blog eröffnet, gestoßen bin. Beiden Jungs DANKE! Hab es es endlich hinbekommen mit meiner Synology!Ich denke Dein Hinweis (SMB2.0) war das Schlagwort.
    Jetzt brauch ich nur noch jemanden, der mir die Visualisierung im iobroker vortanzt 🙂 Im Moment könnte ich alles hinwerfen.

    Viele Grüße aus Berlin und nochmal DANKE!!!!!

      Lukas · 29. Mai 2020 um 17:15

      Hallo Micha,

      entschuldige bitte die späte Freischaltung deines Kommentars!

      Danke für dein Feedback. Freut mich sehr, dass ich dir mit meinem Blog weiterhelfen konnte. 🙂

Sascha · 9. Oktober 2019 um 23:19

Hallo,
ich habe versucht mit deiner Anleitung von meinem Pi auf mein NAS-Laufwerk zu kommen.
Leider funktioniert das mounten schon nicht.
Auf dem Pi habe ich unter /home/pi/ den Mount-Ordner „nas“ angelegt.
Unter /home/pi das Backup-Script abgelegt.
Rufe ich das Script im Terminal auf (sudo bash backup.sh) bekomme ich nur eine Fehlermeldung: „: No such file or directorynas“ und das NAS wird nicht eingebunden.
Wenn ich das Mounten direkt im Terminal ausführe, geht es.
Ich habe das Script ausführbar gemacht, ich habe es auch schon der Gruppe root übergeben, alles ohne Erfolg.
Hast du vielleicht eine Idee was ich falsch mache?

Gruß
Sascha

    Lukas · 10. Oktober 2019 um 10:39

    Hallo Sascha,

    ich vermute, dass entweder in der Pfadkonfiguration etwas nicht stimmt oder der Ordner so nicht zugreifbar ist.
    Ein Mountpoint innerhalb des Home-Directory würde ich grundsätzlich aber nicht unbedingt empfehlen.

      sascha · 11. Oktober 2019 um 22:24

      Wir habens hin bekommen. Es war ein Fehler beim erstellen des Scripts gewesen. Hatte es unter Windows erstellt, als ich es dann mit Linux erstellt gings!

        Lukas · 12. Oktober 2019 um 11:31

        Super! Das sind tolle Neuigkeiten.

        Ich wünsche viel Spaß mit dem Skript und ein tolles Wochenende. 🙂

        Tim · 31. März 2020 um 12:03

        Moin,
        ich frage mich, wie ich anstelle der SD-Karte, eine am Pi angeschlossene HDD mit darauf installiertem Betriebssystem sichern kann. Ist es der gleiche Pfad /dev/mmcblk0 ? Und wie bekomme ich ein Backup wiederhergestellt, ebenfalls mit balenaEtcher?
        Danke schon mal für Antworten.

          Lukas · 31. März 2020 um 14:28

          Hallo Tim,

          wie der Pfad für die Festplatte lautet, kann ich dir tatsächlich gerade gar nicht sagen. Bislang habe ich nie einen Raspberry Pi mit Festplatte betrieben.

          Je nach Größe der Festplatte würde dieses Backup aber in meinen Augen zu lange dauern. Hier lohnt sich vielleicht ein Festplatten-Kloner.

          Tim · 1. April 2020 um 11:38

          Hallo Lukas, danke dir für die Antwort.
          Ic habe zwischenzeitl. gelesen, dass man mit Berry Boot das oder die installierten Betriebssysteme sichern kann, z.B. auf ein anderes USB Device.

          Lukas · 1. April 2020 um 18:41

          Hallo Tim,

          schön, dass du dich nochmal gemeldet hast. Danke dafür.

          Die Lösung kannte ich bisher auch noch nicht. Werde ich mir bei Gelegenheit mal ansehen. Vielleicht finde ich dafür ja doch auch noch einen Einsatzzweck.

Eric · 7. September 2019 um 21:34

Ich nutze z-way Server für z-wave. Dieser scheint regelmäßig seine Konfigurationen in .json-Dateien zu schreiben. Von den letzten drei Wochen hatte ich images, dabei scheint immer mindestens eine von den .json-Dateien kaputt zu sein. Der Server meldet z.B. „SyntaxError: Unexpected token }“ oder „unexpected end of input stream“ und startet nicht mehr.
In Zukunft werde ich regelmäßig mit der eingebauten Funktion von z-way Sicherungen machen. Auch die SQL-Datenbank werde separat sichern. Bei größeren Änderungen des Systems nehme ich die SD-Karte raus und ziehe ein Image mit einem anderen Rechner.

    Lukas · 7. September 2019 um 22:01

    Hallo Eric,

    ich schätze, dass da tatsächlich während des Backups Daten geändert wurden. Bei OpenHAB hingegen sind die Konfigurationsdateien im Normalfall fix.
    Aber es ist natürlich super ärgerlich, wenn das Backup versagt. Ich hoffe du hast künftig mehr Glück mit einer anderen Methode. Ich drücke dir die Daumen 🙂

Eric · 5. September 2019 um 14:47

Achtung: Datensicherungen des laufenden Systems mit dem Kommando dd können inkonsistent sein.

Ich hatte nach dieser Anleitung eine wöchentliche Sicherung des Pi eingerichtet. Als der Ernstfall eintrat und ich es zurückspielen musste, startete mit Glück noch das Betriebssystem, meine Anwendung (Smarthome) aber nicht mehr, weil wichtige Dateien während er Sicherung geschrieben wurden und in der Sicherung eine „unbrauchbare Mischung“ der Daten entstand. Hier ist das ausführlich begründet: https://superuser.com/a/396808/1031662

Das hier genannte Skript ist zwar vielfach im Internet verbreitet aber nicht empfehlenswert, es sei denn, man macht sich die Mühe möglichst viele Prozesse während der Sicherung zu stoppen. Und selbst dann ist keine Integrität garantiert.

Die einzigen mir bekannten sicheren Methoden sind:
Pi ausschalten, SD entfernen und z.B. am Windows-PC mit Win32DiskImager kopieren (mache ich momentan)
oder
LVM benutzen: https://raspberrypi.stackexchange.com/a/85959

Hier wird eine Standardinstallation des Pi mit LVM erbeten:
https://github.com/raspberrypi/linux/issues/2400

    Lukas · 5. September 2019 um 23:05

    Hallo, du hast natürlich Recht, dass die genannte Methode nicht perfekt ist. Im professionellen Umfeld hätte sie keinen Bestand. Da kann ich dir nur zustimmen.

    Dass ein Restore des Backups jedoch solch große Probleme macht, ist mir nicht bekannt. Vielleicht kannst du etwas zu deiner eingesetzten Software erzählen.

    Was man natürlich insbesondere bei OpenHAB auch machen kann, ist das manuelle Sichern (oder automatisch) der Konfigurationsdateien. 🙂

Christopher · 8. August 2019 um 16:55

Man kann das Backup auch gzip(en) um Speicherplatz zu sparen.

Komprimiertes Archiv einer Partition erstellen und den Status Fortschritt dabei ausgeben (status=progress)

dd if=/dev/mmcblk0 bs=1MB status=progress | gzip > ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img

zurückspielen:

gunzip -c ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img | dd of=/dev/mmcblk0

    Lukas · 8. August 2019 um 18:01

    Hallo Christopher,

    danke für die Anmerkung, das ist eine gute Ergänzung.

    Für mich persönlich sehe ich da keine Notwendigkeit. Denn abgesehen vom geringeren Speicherplatz, erhöht es auch die Dauer des Backups. Bei einer 16 GB Speicherkarte muss das für mich nicht sein.

    Ich halte es grundsätzlich aber dennoch für sinnvoll, insbesondere dann wenn viele Backups gespeichert bleiben oder die Speicherkarte noch größer ist.

K. Müller · 19. Juli 2019 um 20:50

Vielen Dank für die verständliche und ausführliche Erklärung, es liest sich wirklich gut. Dennoch beschäftigt mich eine Frage, könnte man das Script so schreiben das es von einem NAS unabhängig ist und stattdessen auf eine Freigabe auf einen anderen Rechner im Netzwerk speichert, ich hatte mir das in etwa so vorgestellt das es zu einer bestimmen Zeit überprüft ob dieser Recher erreichbar ist und dann die Sicherung macht oder falls keine Erreichbarkeit gegeben ist nach einer bestimmten Zeit nochmals überprüft wird bis die Sicherung irgendwann fertig ist.

viele Grüße K. Müller

    Lukas · 20. Juli 2019 um 09:13

    Guten Morgen,

    also grundsätzlich ist das Skript von der Programmierung nicht auf ein NAS beschränkt. Wichtig ist lediglich, dass für das Skript das Smb-Protokoll genutzt wird. Damit kann im Grunde jedes NAS und jeder Windows-Rechner dafür dienen. Bei einem Linux-Rechner muss vorher die Freigabe über Samba erstellt werden und dann sollte das auch damit funktionieren.

    Die Erreichbarkeit des Rechners müsste man gesondert überprüfen. Hier könnte man im oberen Teil des Skripts einen Teil einbauen, der die Prüfung durchführt. Bei erfolgreicher Prüfung wird das Skript dann weiter ausgeführt, andernfalls wird es abgebrochen.

Wilfried Gronert · 13. Juni 2019 um 18:06

Hallo,
ich würde gerne mein RASPI auf diese art sichern. Habe aber kaum Erfahrung mit Linux bzw. Raspbian.
Ich habe ein NAS an IP.Adr 192.168.1.14 . Hier habe ich das Verzeichnis \Raspberry\Datensicherung eingerichtet. Wie müsste ich das in dem Script angeben bzw. beim mounten ?

    Lukas · 13. Juni 2019 um 18:54

    Hallo Wilfried,

    schön, dass du dich direkt von Beginn an mit dem Thema Datensicherung befasst. Tatsächlich ist es ja ein wichtiges Thema.

    Wenn du auf deinem NAS eine Freigabe Raspberry erstellt hast und sich darin der Ordner Datensicherung befindet, musst du im Skript wie folgt angeben:

    mount -t cifs -o user=USERNAME,password=PASSWORD,rw,file_mode=0777,dir_mode=0777 //192.168.1.14/Datensicherung /mnt/nas

    Bitte achte darauf, dass auf deinem Raspberry Pi im Ordner mnt der Ordner nas existiert. Anlegen kannst du ihn mit dem Befehl „mkdir nas“. Im Anschluss daran musst du im Skript noch den Pfad für deine Sicherung anpassen:

    BACKUP_PFAD=“/mnt/nas/Datensicherung“

    Den Abschnitt über die E-Mail am Ende kannst du löschen, sofern du keine E-Mails erhalten möchtest. Solltest du E-Mails erhalten wollen, muss dein Raspberry Pi in der Lage sein, E-Mails zu verschicken (beispielsweise durch ssmtp).

    Achte außerdem darauf, dass du am Anfang des Skripts den Benutzernamen und das Passwort einträgst, dass dein Raspberry Pi Zugriff auf die Freigabe erhält.

      Timo · 13. April 2020 um 09:33

      Hallo Lukas,
      vielen Dank für die tolle Anleitung – aber kannst du den Hinweis mit „mkdir“ mit in den Text oben aufnehmen?! Das hat mich gestern 2 Stunden googlen gekostet – aber ich verstehe jetzt mehr Linux, auch nicht schlecht.

        Lukas · 13. April 2020 um 10:04

        Hallo Timo,

        danke für die Anmerkung. Ich habe den Text oben ergänzt.

        Es tut mir natürlich leid, dass dich das 2 Stunden gekostet hat. Gerade weil es eigentlich eine Kleinigkeit ist und natürlich selbstverständlich erwähnt werden sollte.
        Wenn du Linux nun allerdings besser verstehst, ist das zumindest etwas Gutes.

        Ich wünsche dir einen schönen Ostermontag! 🙂

Werner · 11. Juni 2019 um 18:12

Hallo Lukas

ich habe alles gecheckt. Die Freigabe backup gibt es auf der NAS. Username und Passwort stimmt auch. Groß Kleinschreibung habe ich auch beachtet. Der Ordner nas existiert. IP Adresse stimt
Was kann das sein?

Gruß
Werner

    Lukas · 11. Juni 2019 um 18:14

    Hallo Werner,

    den Ordner nas musst du händisch anlegen. Dazu navigierst du in das Verzeichnis mnt und führst dort den Befehl „mkdir nas“ aus. Der Ordner wird nun angelegt und kann ab sofort genutzt werden.

      Werner · 11. Juni 2019 um 18:52

      Hallo Lukas

      das habe ich ja gemacht. Der Ordner ist da

      Gruß
      Werner

        Lukas · 11. Juni 2019 um 18:58

        Hallo Werner,

        bitte sei doch so nett und schicke mir mal dein aktuelles Skript per E-Mail zu: support@hobbyblogging.de

        Ich bin mir sicher, wir finden eine Lösung für dein Problem.

Werner · 11. Juni 2019 um 09:57

Hallo

Super Anleitung. Nur waum bekomme ich diesen Fehler? Mein Server läuft und die Einstellungen stimmen alle.

mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
dd: failed to open ‚”/mnt/nas/backup”/”TestSicherung”-20190610.img‘: No such file or directory
backup.sh: line 11: pushd: ”/mnt/nas/backup”: No such file or directory
head: invalid number of lines: ‘”5”’
ls: cannot access ‚”/mnt/nas/backup”/”TestSicherung”*‘: No such file or directory
rm: missing operand
Try ‚rm –help‘ for more information.
backup.sh: line 11: popd: directory stack empty

Gruß
Werner

    Lukas · 11. Juni 2019 um 11:36

    Hallo Werner,

    danke für dein Feedback zum Artikel.

    Ich glaube bei dir ist das Problem, dass dein NAS nicht erreichbar ist. Die Fehlermeldung „host is down“ lässt darauf schließen, dass der Raspberry Pi das NAS nicht erreicht.
    Du musst sicherstellen, dass auf deinem NAS der Ordner Backup in der Freigabe existiert, die zu in deinem Raspberry Pi einbinden möchtest. Außerdem muss der Ordner nas im Verzeichnis mnt angelegt sein. Nur so kann das Skript an diese Stelle die Freigabe mounten.
    Womöglich hilft es dir auch (sofern es vorher bereits einmal funktioniert hat) deinen Raspberry Pi und dein NAS neu zu starten.
    Außerdem kannst du sicherstellen, dass die richtige IP-Adresse des NAS in der Konfiguration des Skripts eingetragen ist.

    Ich wünsche dir viel Erfolg und lass gerne nochmal von dir hören.

Martin · 23. April 2019 um 15:14

Hallo Lukas,
vielen Dank für die Anleitung.
– Kann ich auch einen Server im Internet nutzen, oder geht das nur innerhalb eines LAN?
– Wird immer ein volles Backup angelegt, oder kann ich sagen, dass jedes 3. Backup ein vollständiges ist und die anderen nur die Änderungen jeweils speichern? So könnte ich Speicher sparen und oder häufiger sichern…

Vielen Dank

Martin

    Lukas · 23. April 2019 um 21:31

    Hallo Martin,

    das Skript ist explizit dazu gemacht, innerhalb des LANs Sicherungen anzulegen. Sicherlich lässt sich das Skript auch anpassen, um damit einen Server woanders zu nutzen.
    Was man machen könnte wäre eine VPN-Verbindung zum Remote-Server herzustellen und dessen Laufwerk einzubinden. Das Skript nutzt hierfür cifs.

    Zu deiner zweiten Frage:
    Es werden immer volle Images angelegt. So gesehen befindet sich die komplette Festplatte des Raspberry Pi (also die SD-Karte) als Abbild auf dem NAS. Damit der Speicher nicht überläuft werden maximal 5 Sicherungen behalten. Die Anzahl kannst du auch runtersetzen. Dann wird weniger Speicher in Anspruch genommen.
    Eine inkrementelle Sicherung (also die veränderten Dateien) ist vom Skript nicht vorgesehen.

    Wenn du also tatsächlich auf einem Remote-Server eine inkrementelle Sicherung machen möchtest, müsste man hierfür ein eigenes Skript schreiben.

Sebastian · 19. Dezember 2018 um 10:13

Hallo, vielen Dank für diesen tollen Beitrag. Das automatische Back-up finde ich super nützlich. Allerdings musste ich leider feststellen, dass alle SD-Karten unterschiedlich viele Blöcke haben und sich dadurch ein Back-Up lediglich auf die vorher verwendete SD-Karte zurückspielen lässt oder aber man muss eine größere SD-Karte verwenden. Hast Du für dieses Problem evtl. auch eine Lösung?
Viele Grüße
Sebastian

    Lukas · 20. Dezember 2018 um 08:10

    Hallo Sebastian,

    ich muss leider zu meinem Nachteil zugeben, dass ich dieses Backup bislang noch nicht wieder eingespielt habe (Zeitgründe). Allerdings gehe ich sehr stark davon aus, dass die SD-Karte genauso formatiert sein muss, wie die gesicherte Karte. Sprich gleiche Blöcke usw.
    Von der Größe her muss es eine mindestens genauso große SD-Karte sein, das ist soweit richtig.
    Was man allerdings machen kann ist, dass man das Backup über eine virtuelle Maschine auf eine kleinere Karte überträgt. Das ist zwar sehr umständlich, sollte aber möglich sein.

    Es gibt allerdings auch noch andere Arten von Backups, so dass man wirklich nur bestimmte Daten sichert und nicht die komplette Karte. Dann würde dieses Problem gar nicht erst aufkommen.

    Gruß Lukas

    Henning · 7. November 2019 um 21:56

    Ganz klarer Fall, das kleinere Backup muss auf eine SD Karte die mindestens genauso groß ist wie das Backup der alten und da reden wir übers KB, sonst wird es nicht funktionieren. Backup lässt sich zwar zurückspielen aber der Pi wird nicht booten. Habe das selbst mit einer alten SD Karte anno Zwieback ( 32 GB ca 2012 durch…

    Good luck. Ich kann meinem Vorredner nur zustimmen, die sicherste Variante das alles am Ende tut ist Pi herunterfahren, Karte raus, sichern und wieder zurück, sonst könnte es in Punkto Komplett Sicherung ein Böses erwachen geben. Ich spiele die Backups zur SIcherheit immer noch mit Balena Etcher zurück, dort ist eine umfangreiche Kopierprüfung enthalten ( Validierung ).

    Good luck !

      Lukas · 7. November 2019 um 22:06

      Hallo Henning,

      danke für dein wertvolles Feedback! Die Anmerkung, dass das Herunterfahren die sicherste Methode ist, ist natürlich absolut richtig.
      Ich möchte dir keinesfalls widersprechen.
      Nüchtern betrachtet würde ich in der Zwischenzeit auch etwas mehr Zeit in das Thema Backup investieren. 😉

Wirtschaftsinformatiker · 5. November 2018 um 23:48

Supernützliche Anleitung, man dankt. Finde deine Smart Home Beiträge eigentlich alle sehr spannend.

Fernsehaufnahmen mit Raspberry Pi und NAS - Hobbyblogging · 13. Februar 2020 um 17:08

[…] unkompliziert und sollte schnell vonstatten gehen. Wenn du sogar einmal meinen Beitrag über das vollautomatische Backup des Raspberry Pi gelesen hast, dann kennst du sogar schon das grundlegende Vorgehen. Denn das Speichern von […]

QNAP TS-453BE-2G - NAS im Test - Hobbyblogging · 13. Oktober 2019 um 08:01

[…] in vielen Beiträgen habe ich über ein NAS (Network Attached Storage) geschrieben, das für Backups, Fernsehaufnahmen oder zum Speichern von Dateien geeignet ist. Doch so wirklich ein NAS vorgestellt […]

Deutschlands Hitzewelle macht auch der Technik zu schaffen · 31. Juli 2018 um 08:02

[…] ich definitiv nicht. Dank einem vollautomatischen Backup wäre das Neuaufsetzen zwar einfacher, aber bequem bedeutet eben auch, dass man das nicht machen […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.