Raspberry Pi Backup – Vollautomatisch sichern

232 Kommentare

Lukas · 11. Juli 2024 um 19:35
Hallo Murry,
wie schon eingangs vom Artikel erwähnt, kann es durchaus zu Problemen kommen. Daher habe ich diesen wichtigen Hinweis aufgenommen.
Was du auf jeden Fall prüfen musst ist, ob du unter /dev/ das Verzeichnis mmcblk0 finden kannst.
Mir fiel außerdem auf, dass die Anführungszeichen ggf. durch das Kopieren eine falsche Formatierung haben. Ersetze die am besten nochmal händisch. Da gab es in der Vergangenheit immer mal wieder Probleme (Kodierung).
Anhand der Fehlermeldung könnte ich mir aber durchaus vorstellen, dass es mit den Anführungszeichen zutun haben kann. Andernfalls ist die Analyse schwieriger und führt mehr ins Detail.
Smarte Grüße
Antworten

Murry · 11. Juli 2024 um 20:39
Hallo Lukas.
Danke für die fixe Antwort.
Habe ich auch jetzt erst gesehen, dass beim kopieren die Anführungszeichen verschwunden sind.
Ich habe gerade mal deinen Bash-Eintrag mit meinem verglichen.
Ich habe deinen Bash eigentlich 1:1 übernommen und nur noch auf Grund des Hinweises in einer der Kommentaren hier das gzip hinzugefügt und natürlich meinen Pfad zur Backupspeicherung abgeändert. Mit der alten Sicherung lief es ja auch wunderbar.
Ich vermute, als ich ein update vom piOS und oder Python gemacht habe, das da jetzt was nicht sauber läuft. Ich kann mich nicht daran erinnern sonst noch was anderes gemacht zu haben.
Habe kein Verzeichnis mmcblk0 unter /dev finden können.
Aber warte. Das bedeutet ja nur, das ich auf die SD-Karte zugreife, richtig?
Das kann ja nicht funktionieren, da ich von einer Festplatte boote. #facepalm
Dann muss ich ja „blkid“ schauen, welche sda es ist, im meinen Falle /dev/sda1, und dann geht es auch wieder.
Ok. Aber gut, das wir darüber gesprochen haben. Es zeigt sich mal wieder:
Es handelt sich um Fehler 40 (Der Fehler sitzt 40 cm vor dem Monitor) 😀
Danke für die Hilfe.
Beste Grüße,
Murry
Antworten

Lukas · 12. Juli 2024 um 07:53
Hallo Murry,
nein, kein Fehler 40 😉
Sowas passiert tatsächlich allen mal. Ärgerlich, aber kommt vor 😉
Du glaubst gar nicht, was ich schon alles zustande gebracht habe … Ganz schön wild.
Smarte Grüße
Antworten

Lukas · 16. Februar 2023 um 13:39
Hallo Kay,
generell ist das eine gute Idee, die du da hast. Ist auf jeden Fall zu empfehlen.
Auf jeden Fall braucht der Benutzer im entsprechenden Ordner Schreib- und Löschberechtigungen. Er muss neue Sicherungen anlegen können und alte löschen können.
Smarte Grüße
Antworten

Lukas · 10. November 2022 um 19:05
Hi Martin,
ja, das ist bei dieser Form des Backups leider richtig. Es werden immer alle Sektoren der SD-Karte oder der Festplatte abgelegt. Deshalb muss ich leider im Nachgang zugeben, dass diese Form der Sicherung nicht gerade die beste Wahl ist.
In den Kommentaren wird aber darüber diskutiert, wie man den benötigten Speicherplatz reduzieren kann. Es gibt auch tatsächlich andere Formen des Backups, die etwas besser sind.
Smarte Grüße
Antworten

dirk · 2. Januar 2023 um 20:32
Hi Lukas, gerade gesehen, die Crontab Anweisung funktioniert so nicht. Das Script wird nicht ausgeführt. Es müsste heißen: /home/pi/Scripts/./backup.sh > /dev/null
Antworten

Lukas · 2. Januar 2023 um 21:31
Hallo Dirk,
interessanter Hinweis. Bei mir hat es tatsächlich so funktioniert wie im Artikel angegeben.
Aber für den Fall der Fälle, ist deine Lösung sicherlich sehr interessant und hilfreich.
Smarte Grüße
Antworten

Lukas · 6. November 2022 um 07:35
Hallo,
ich habe mir mal die Zeit genommen, um etwas nach dem Fehler zu suchen.
Allerdings muss ich dir sagen, dass ich keine genaue Vorstellung darüber habe, warum das passiert. Oder was es damit auf sich hat.
Was ich mir eventuell erklären könnte ist, dass das Backup auf irgendeine Datei stößt, die von der Namensgebung her nicht so ist, wie sie vielleicht sein sollte. Zum Beispiel durch Benennungen mit einem Doppelpunkt etc.
Smarte Grüße
Antworten

Lukas · 28. Dezember 2021 um 19:10
Hallo Thomas,
du wirst dich jetzt vielleicht etwas wundern, aber in meinem Fall passt das. Ich mounte lediglich die Freigabe in den Ordner /mnt/nas.
Bei mir war die Freigabe lediglich das Netzlaufwerk auf dem NAS, das wiederum den Ordner Backup beinhaltete. Im Ordner drüber lagen bei mir noch ein paar Images.
Wenn du bei der Freigabe keinen Unterordner Backup hast, dann muss das tatsächlich auch ausgelassen werden. Da hast du recht.
Es ist immer eine Frage der genauen Ordnerstruktur. Dennoch eine sehr hilfreiche Anmerkung, vielen Dank dafür.
Smarte Grüße
Antworten

Daniel · 24. Februar 2022 um 18:01
Hallo, nach langer Zeit mal wieder eine Frage an dich 🙂
die Sicherungen laufen jetzt. Nur löscht er die alten Sicherungen nicht. Hier mein Skript.
#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=openhabian,password=XXXXXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/“
BACKUP_ANZAHL=“3″
BACKUP_NAME=“Sicherung“
DIENSTE_START_STOP=“openhab-cli“
#Dienste stoppen
${DIENSTE_START_STOP} stop
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB status=progress
#Dienste starten
${DIENSTE_START_STOP} start
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP$
#Festplatte auswerfen
umount /mnt/nas
vielleicht hast du einen Tipp was ich noch verkehrt habe.
Meine nächste Frage wäre noch wenn ich die Sicherung einmal in der Woche z.B. Mittwoch Nacht um 3 Uhr anlegen möchte, wie würde dann die Cronjobs Zeile aussehen müssen ?
Wie immer vielen Dank für deine Hilfe 😉
Antworten

Lukas · 24. Februar 2022 um 18:31
Hallo Daniel,
wenn du 3 Sicherungen auf dem NAS gespeichert hast, sollte bei der Erstellung der vierten Sicherung die älteste gelöscht werden.
Ich wüsste jetzt ehrlich gesagt nicht, woran das scheitert. Zur Not müsste man es leider manuell machen.
Den Cronjob kannst du dir ganz einfach hier erstellen: https://crontab-generator.org/
Smarte Grüße
Antworten

Daniel · 24. Februar 2022 um 20:36
vielen Dank für deine Antwort 🙂
ich habe jetzt mit deinem Link diese Zeile generiert. Müsste doch so passen oder ?
0 5 * * Thu /home/openhabian/backup.sh > /dev/null
also dann jeden Donnerstag um 5 Uhr morgens

Lukas · 25. Februar 2022 um 08:18
Hallo Daniel,
ich weiß nicht sicher, ob „Thu“ als Tagangabe funktioniert. Du kannst es ausprobieren um im Zweifel gegen eine 4 austauschen. Mit der 4 sollte es auf jeden Fall funktionieren.
Smarte Grüße

Assassins · 31. Mai 2022 um 14:57
This work 100%, and do everything for you
#!/bin/bash
get_codename() {
local VERSION_CODENAME
VERSION_CODENAME=$(bash -c ‚. /etc/os-release; echo $VERSION_CODENAME‘ | sed ’s/.*/\u&/‘)
echo „$VERSION_CODENAME“
}
directory_check() {
echo „Checking for „$BACKUP_PATH“ and creating if missing“
[ ! -d „$BACKUP_PATH“ ] && mkdir -p „$BACKUP_PATH“
}
function stopServices {
echo -e „Stopping Services before backup“
service apache2 stop
service smbd stop
}
function startServices {
echo -e „Starting the stopped Services“
service smbd start
service apache2 start
}
# Settings
BACKUP_PATH=“/media/Backup/RPI-Backup/$(get_codename)/${HOSTNAME}“
BACKUP_ANTAL=“3″
BACKUP_DATO=$(date +%d-%m-%Y)
ARCHITECTURE=$(getconf LONG_BIT)
HOSTNAME=$(hostname -s)
VERSION_CODENAME=$(get_codename)
stopServices
# Backup Image from USB
echo „Starting Backup“
directory_check
dd if=/dev/sda of=${BACKUP_PATH}/${HOSTNAME}${ARCHITECTURE}bits-${BACKUP_DATO}.img bs=1MB status=progress
echo
# Backup Image from SD-Kort
# dd if=/dev/mmcblk0 of=${BACKUP_PATH}/${HOSTNAME}${ARCHITECTURE}bits-${BACKUP_DATO}.img bs=1MB status=progress
echo
startServices
# PiShrink
echo „Starting PiShrink“
pishrink.sh ${BACKUP_PATH}/${HOSTNAME}${ARCHITECTURE}bits-${BACKUP_DATO}.img
echo
# Delete if there are more than ${BACKUP_ANTAL}
echo “ Delete if there are more than $BACKUP_ANTAL“
pushd ${BACKUP_PATH}; ls -tr ${BACKUP_PATH}/${HOSTNAME}${ARCHITECTURE}bits* | head -n -${BACKUP_ANTAL} | xargs rm; popd
echo
Antworten

Lukas · 20. Dezember 2021 um 09:20
Hallo Daniel,
schön, dass du bei mir im Blog vorbeigeschaut hast und dir die Mühe machst, dein Problem zuerst selbst zu lösen. Finde ich super!
Grundsätzlich habe ich dazu zwei Ideen. Wichtig dafür ist, dass du den Pfad mal auf deinem PC ausprobierst, so dass er auch richtig ist. Bei den FritzBox-Pfaden bin ich leider nicht so ganz sicher, wie die aussehen sollen.
Danach solltest du sicherstellen, dass der Pfad /mnt/nas auf deinem Raspberry existiert. Du musst also im Ordner /mnt den Ordner nas erstellen.
Wenn das passiert ist, kann es noch an der SMB-Version liegen. Die FritzBox hat per Default die Version 1.0 von SMB deaktiviert. Eventuell hilft es dir also, wenn du in deinem Befehl noch vers=3.0 ergänzt.
Der Befehl sollte dann wie folgt aussehen:
mount -t cifs -o user=USERNAME,password=PASSWORD,rw,file_mode=0777,dir_mode=0777,vers=3.0 //IP/FREIGABE /mnt/nas
Mir ist außerdem aufgefallen, dass du beim Mounten die Login-Daten erst nach den Pfaden angibst. Das kann problematisch sein. Halte dich daher bitte an die vorgegebene Syntax, wie im Code-Block zu sehen ist.
Beste Grüße
Antworten

Daniel · 20. Dezember 2021 um 16:49
Hallo ,
vielen Dank für deine schnelle Antwort 🙂 Also ich habe jetzt geschaut ob es den Ordner NAS gibt und ja er ist angelegt. Habe es jetzt mal mit
mount -t cifs -o user=openhabian,password=XXXXXXXXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 \\192.168.2.139\fritznas\Intenso-PortableSSD-01\Backup /mnt/nas. probiert und es kam folgende Meldung.
mount.cifs: bad UNC (\192.168.2.139fritznasIntenso-PortableSSD-01Backup)
Antworten

Lukas · 20. Dezember 2021 um 16:57
Hallo Daniel,
mir persönlich ist es wichtig, zeitnah und persönlich auf Kommentare und Rückfragen einzugehen. Daher nichts zu danken! 😉
Okay also wir sind schon einen ganzen Schritt weiter. Mir fällt nur noch auf, dass du Backslashes (\) benutzt, um den Pfad anzugeben. Probier es mal bitte mit ganz normalen Slashes (/).
Der Fehler ist vermutlich darauf zurückzuführen.
Außerdem: Wenn dein Passwort Sonderzeichen enthält, dann ändere diese mal bitte ab. Es kann sein, dass es bei bestimmten Zeichen zu Fehlinterpretationen kommt und deshalb keine Verbindung hergestellt werden kann.
Übrigens Daumen hoch dafür, dass du direkt das Passwort aus der Zeile entfernt hast. Du ahnst gar nicht, wie oft ich das in den Kommentaren schon selbst machen musste. 😉
Melde dich gerne nochmal hier in den Kommentaren, wenn sich etwas getan hat.
Beste Grüße
Antworten

Daniel · 20. Dezember 2021 um 17:07
Sonderzeichen habe ich nicht. Nur einen Großbuchstaben am Anfang und Eine Zahl.
mount -t cifs -o user=openhabian,password=XXXXXXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup /mnt/nas
Es kommt folgende Meldung:-bash: Syntaxfehler beim unerwarteten Wort `(‚

Lukas · 20. Dezember 2021 um 17:16
Ein Syntaxfehler ist grundsätzlich ein Fehler in der Struktur. Das bedeutet, dass irgendwo ein Zeichen platziert ist, das nicht an diese Stelle gehört. Es kann aber auch sein, dass ein Zeichen fehlt, das eigentlich da sein müsste.
Hier musst du nochmal ganz genau vergleichen, wie dein Skript aufgebaut ist und wie das ursprüngliche Skript aussieht.
Bedeutet, dass du Zeile für Zeile durchgehen musst und den Fehler suchen musst.
Irgendwo muss es eine Abweichung vom Soll geben 😉

Daniel · 20. Dezember 2021 um 18:01
Keine Ahnung warum mein Beitrag jetzt weg ist.
habe jetzt ein Leerzeichen entfernt und es kommt folgende Fehlermeldung.
mount -t cifs -o user=openhabian,password=XXXXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup/mnt/nas.
mount: //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup/mnt/nas: can’t find in /etc/fstab.

Lukas · 20. Dezember 2021 um 18:39
Genau, jetzt fehlt wiederum ein wichtiges Leerzeichen.
Vor /mnt/nas muss ein Leerzeichen sein.

Daniel · 20. Dezember 2021 um 18:53
ich habe keine Ahnung was ich falsch mache.[18:50:11] openhabian@openHABianDevice:~$ sudo mount -t cifs -o user=openhabian,password=XXXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup/ mnt/nas
[sudo] Passwort für openhabian:
Couldn’t chdir to mnt/nas: No such file or directory

Lukas · 20. Dezember 2021 um 19:18
Der Fehler ist soweit auch logisch. Du hast im Skript das Leerzeichen falsch gesetzt. Es muss heißen /mnt/nas
Bei dir sieht es aber so aus: /Backup/ mnt/nas
Wenn ich das richtig sehe, gibst du nur den Mount-Befehl in die Konsole ein. Du musst natürlich das ganze Skritp verwenden und als .sh-Datei abspeichern.
Ich weiß jetzt nicht, ob das so klar ist.

Daniel · 20. Dezember 2021 um 19:37
Ich dachte man kann die Befehle einzeln aufrufen. Um eventuelle Fehler zu entdecken.
Das ist mein ganzes Skript.
#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=openhabian,password=XXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup/mnt/$
#Variablen
BACKUP_PFAD=“/mnt/nas/Backup“
BACKUP_ANZAHL=“3″
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
und das sind die Meldungen wenn ich sudo ./backup.sh
eingebe.
mount: //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup/mnt/nas: can’t find in /etc/fstab.
dd: konnte ‚/mnt/nas/Backup/Sicherung-20211220.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.
umount: /mnt/nas: not mounted.

Lukas · 20. Dezember 2021 um 19:52
Das kannst du durchaus machen, ja. Ich meine nur, dass es dann um komplett zu funktionieren schon als ganzes Skript ausgeführt werden muss. 😉
Aber nun gut, von vorne.
Du mountest den Ordner /Intenso-PortableSSD-01/Backup auf /mnt/nas (nicht /mnt/$ und auch bitte mit Leerzeichen zwischen den beiden Pfaden)
Dann musst du als Backup-Pfad aber /mnt/nas angeben, da der Verweis ja schon auf den Unterordner Backup läuft. So wie du es machst hättest du im Ordner Backup nochmal einen Ordner Backup.
Bedeutet konkret:
mount -t cifs -o user=openhabian,password=XXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup /mnt/nas
sowie
BACKUP_PFAD=“/mnt/nas/“
Dann bitte einmal die Anführungszeichen löschen und neu eintippen (betrifft die Zeilen BACKUP_PFAD, BACKUP_ANZAHL und BACKUP_NAME). Es kann sein, dass es die falsche Kodierung hat und deshalb ist es besser, sie einzutippen statt zu kopieren.
Und wenn du diese Schritte getan hast, sehe ich kein Problem, wieso es nicht funktionieren sollte.
Beim popd wird zu Beginn immer eine Warnung kommen, bis zu 3 Sicherungen erreicht hast. Denn er versucht ja die 3. Sicherung zu löschen, die es aber noch gar nicht gibt.

Daniel · 20. Dezember 2021 um 20:13
So das ist jetzt mein Skript.
#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=openhabian,password=XXX,rw,file_mode=0777,dir_m$
#Variablen
BACKUP_PFAD=“/mnt/nas/“
BACKUP_ANZAHL=“3″
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$
#Festplatte auswerfen
umount /mnt/nas
wenn ich jetz sudo ./backup.sh eingebe kommt folgende Meldung.
[20:09:52] openhabian@openHABianDevice:~$ sudo ./backup.sh
[sudo] Passwort für openhabian:
mount error(16): Device or resource busy
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
[20:09:52] openhabian@openHABianDevice:~$ sudo ./backup.sh

Lukas · 20. Dezember 2021 um 20:25
Okay das sieht danach aus, als hättest du es schon gemountet. Du kannst mal versuchen mit „umount /mnt/nas“ und dann das Skript nochmal ausführen.
Sollte das nicht helfen, starte am besten den Pi nochmal neu, dass alles nochmal von Frischem geladen wird.
Aber ich denke das umount wird dir helfen.

Daniel · 20. Dezember 2021 um 20:40
Vielen Dank für deine Geduld mit mir 🙂 Aber ich denke es geht jetzt. die Fehlermeldung kam wahrscheinlich nur weil er schon eine Sicherung auf die NAS spielt. Denn in dem Ordner Backup befindet sich jetzt eine Datei mit dem Namen „Sicherung“ Kann ich irgendwo sehen wann er fertig ist und die Sicherung komplett ist ? Meine Nächste Frage wäre was müsste ich eingeben wenn ich die Sicherung jede Nacht um 2 Uhr starten wollen lassen würde. Der Hintergrund ist das ich gerade viel mit openhab 3 rumspiele und da schon einige male was schief gegangen ist. Bis jetzt habe ich jeden Tag meine SD Karte geklont.

Lukas · 20. Dezember 2021 um 21:02
Leider siehst du nicht, wann die Sicherung fertig ist. Das ist so nicht eingebaut.
Wenn du das Skript aber manuell startest, blendet sich automatisch wieder die Eingabezeile ein, sobald das Skript seine Arbeit erledigt hat.
Im automatisierten Modus kann man es nur daran erkennen, dass das Backup auf der Festplatte über ein paar Minuten nicht mehr größer wird.
Du musst außerdem aufpassen, weil das Sicherungsskript so seine Schwierigkeiten mit laufenden Diensten haben kann.
Es kann also durchaus sein, dass die Sicherung nicht so wiederherstellbar ist, wie du es dir wünschst. Dafür kann ich keine Garantie übernehmen.
Damit die Sicherung jede Nacht um 2 Uhr startet, musst du die Crontabs anlegen wie im Artikel beschrieben. Anstatt einer 5 schreibst du eben eine 2 rein.
Die 1 und 15 bei den Angaben stehen übrigens für den ersten und den 15. jedes Monats. Willst du dagegen täglich sichern, kannst du eine der beiden Zeilen weglassen und statt der 1 oder der 15 ein Sternchen * eintragen.
Der Stern steht für einen beliebigen Wert und deckt damit jeden Tag eines Monats ab.
Rein aus Sicherheitsgründen empfehle ich dir aber dringend (!) dennoch die SD-Karte hin und wieder zu klonen. Sollte mit dem Backup irgendwas auch nur im Ansatz schiefgehen, hast du so jederzeit eine Möglichkeit, dein System wiederherzustellen. Das sollte man keinesfalls unterschätzen.
Und bezüglich der Geduld: Wo kämen wir denn nur hin, wenn wir als Smart-Home-Community nicht auch die schweren Fälle mit Bravour lösen würden? 😉
Als Danke dafür springt ja glücklicherweise der eine oder andere Cent bei rum. Wenn du zum Beispiel auf eine Produktbox klickst und innerhalb von 24 Stunden im Online-Shop etwas kaufst, gibt der Onlinehändler freundlicherweise einen Teil davon an meinen Blog ab. Und das Beste daran ist, dich kostet es keinen einzigen Cent mehr 😉

Daniel Knoch · 20. Dezember 2021 um 22:31
jetzt ist es passiert das er versucht hat das Backup auf die sd Karte im Rasbi zu schreiben. Natürlich hat es nicht funktioniert. Habe mein Skript jetzt versucht abzuändern das openhabian gestoppt wird aber schreibt ./backup.sh:Zeile10:“openhabian“:Kommando nicht gefunden.
Das ist jetzt mein Skript:
#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=openhabian,password=XXXX,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/“
BACKUP_ANZAHL=“3″
BACKUP_NAME=“Sicherung“
DIENSTE_START_STOP=“openhabian“
#Dienste stoppen
${DIENSTE_START_STOP} stop
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB status=progress
#Dienste starten
${DIENSTE_START_STOP} start
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP$
#Festplatte auswerfen
umount /mnt/nas

Lukas · 21. Dezember 2021 um 07:37
Als Openhabian wird soweit ich weiß die Installation bezeichnet. Der Service selbst lautet anders. Du kannst vor der Zeile #Backup erstellen die folgende Zeile ergänzen:
systemctl stop openhab.service
und nach #Dienste starten
systemctl start openhab.service
Ich denke damit sollte es funktionieren. Aber da ich selbst OpenHAB3 nicht ausprobiert habe, bin ich mir nicht ganz sicher, ob die Befehle richtig sind. Laut Dokumentation zumindest müssten sie stimmen.

Daniel · 23. Dezember 2021 um 10:12
Hallo muss nochmal Nerven 🙂 Jetzt läuft mein Skript so wie es ist
#!/bin/bash
#Festplatte einbinden
mount -t cifs -o user=openhabian,password=xxx,rw,file_mode=0777,dir_mode=0777,vers=3.0 //192.168.2.139/fritznas/Intenso-PortableSSD-01/Backup /mnt/nas
#Variablen
BACKUP_PFAD=“/mnt/nas/“
BACKUP_ANZAHL=“3″
BACKUP_NAME=“Sicherung“
DIENSTE_START_STOP=“openhab-cli“
#Dienste stoppen
${DIENSTE_START_STOP} stop
#Backup erstellen
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img bs=1MB status=progress
#Dienste starten
${DIENSTE_START_STOP} start
#Alte Sicherung löschen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP$
#Festplatte auswerfen
umount /mnt/nas
nur leider geht es nur wenn ich es mit dem Befehl sudo ./backup.sh starte.
Für das automatische Starten habe ich folgende Zeile in Crontab eingefügt.
00 02 * * */home/openhabian/Scripts/backup.sh > /dev/null doch leider startet es nicht in der Nacht um 2 Uhr. Ich muss dazu sagen das die Datei backup.sh bei mir im Ordner /home/openhabian/ liegt und es da keinen Ordner Scripts gibt. Hatte aber auch schon 00 02 * * */home/openhabian/backup.sh > /dev/null probiert. Ging leider auch nicht. Vieleicht habt ihr noch eine Idee was ich falsch mache ?
Antworten

Lukas · 23. Dezember 2021 um 10:31
Hallo Daniel,
du nervst nicht. Das darfst du nicht denken 😉
Schön erstmal zu wissen, dass dein Skript soweit läuft. Finde ich super, dass du dran geblieben bist!
Der Pfad mit dem Scripts im Namen gibt den Pfad an, wo das Skript zu finden ist. Wenn du keinen Unterordner Scripts hast, dann darfst du das natürlich auch nicht angeben. Wichtig sind außerdem auch hier wieder die Leerzeichen, wenn ich das richtig sehe.
Für dich korrekt müsste es also wie folgt lauten:
0 2 * * * /home/openhabian/backup.sh > /dev/null
Wenn ich es richtig sehe, hast du zwischen dem letzten Sternchen und dem Pfad kein Leerzeichen. Aus diesem Grund scheint es zu scheitern.
Am besten kopierst du daher mal diese Zeile in deine Crontabs und probierst es nochmal aus. Die alten Zeilen aus deinem Test vorher natürlich rausnehmen 😉
Viel Erfolg!
Antworten

Lukas · 3. Dezember 2021 um 13:53
Herzlich willkommen bei mir im Blog!
Vielleicht am Rande: Das Backup mit dem Skript hat so seine Schwachstellen, wie du vielleicht schon den Kommentaren entnommen hast. Daher wäre ich insbesondere im Hinblick auf einen eigenen BTC Node sehr vorsichtig.
Du hast vermutlich beim Mounten einen Fehler drin. Du mountest ../MEINNAME/Backup/Node/mnt/ns – Dort fehlt ein Leerzeichen. Vor /mnt/nas muss unbedingt ein Leerzeichen rein.
Zudem ist es so, dass der Backup-Pfad nicht stimmen kann. Wenn du den Ordner …/Backup/Node in den Ordner /mnt/nas mountest, darfst du im Backup-Pfad nur /mnt/nas eingeben. Weil du bist ja quasi schon im Unterordner.
Wenn du darüber hinaus noch das Problem mit Permission denied bekommst, solltest du das Skript mal als sudo ausführen.
Beste Grüße
Antworten

mr.peaceful · 3. Dezember 2021 um 14:46
Vielen Dank Lukas!
Ich hab es geschafft.
Sicherung läuft.
Ich schau mal, ob ich dafür einen Cron Job einrichte oder es alle heilige Zeit mal per Hand anschiebe.
Nochmals viele Dank!
peaci
Antworten

Lukas · 3. Dezember 2021 um 15:38
Sehr gerne!
Viel Spaß mit deinem Raspberry. Klingt auf jeden Fall spannend, was du damit machst.
Beste Grüße
Antworten

Lukas · 25. November 2021 um 17:11
Hallo Maxi,
wichtig wäre mal, dass du das Skript mit sudo ausführst. Also sudo ./backup.sh
Hast du denn auch den Ordner /mnt/nas angelegt? Es scheint mir so, als gäbe es den Ordner nicht. Den musst du mit sudo-Rechten manuell erzeugen, sonst kann leider nichts gemountet werden.
Beste Grüße
Antworten

Maxi · 25. November 2021 um 22:02
Hallo Lukas,
Vielen dank für deine schnelle Antwort, ich meine ich hab das alles gemacht
pi@server:~ $ sudo ./backup.sh
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
dd: konnte ‚/mnt/nas/backup/Sicherung-20211125.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.
umount: /mnt/nas: not mounted.
pi@server:~ $ sudo mkdir /mnt/nas
mkdir: das Verzeichnis „/mnt/nas“ kann nicht angelegt werden: Die Datei existiert bereits
Grüße
Antworten

Lukas · 26. November 2021 um 10:09
Hallo Maxi,
du mountest von deinem Server die Netzwerkfreigabe Serverbackup. Befindet sich in diesem Ordner ein Unterordner Backup?
Und wenn ja, hast du den Ordner groß oder klein geschrieben? Linux unterscheidet hier sehr strikt, weshalb auch im Skript der Ordnername groß/klein geschrieben werden muss, so wie auf dem Netzlaufwerk.
Irgendwas scheint hier mit dem Verzeichnis nicht zu stimmen.
Beste Grüße
Antworten

emmi2205 · 29. November 2021 um 23:29
Hallo Maxi,
der mount error (95) bedeutet sehr wahrscheinlich, dass Dein NAS nur SMB version 2.0 oder älter unterstützt. Raspberry kann allerdings nur mit SMB 2.1 oder neuer umgehen. Ich konnte auf meinem NAS (Synology) SMB 3.0 aktivieren – danach funktioniert der Mount Befehl sofort. Versuch’s mal.
Antworten

Lukas · 30. November 2021 um 08:38
Guten Morgen,
vielen Dank für dein Feedback zu diesem Problem. An die SMB Version habe ich tatsächlich nicht gedacht, das ist ein guter Einwand.
Ich hoffe Maxi wird das an dieser Stelle lesen und damit dem Problem auf die Spur kommen.
Vielen Dank auch für deinen Besuch bei mir im Blog.
Beste Grüße

Lukas · 23. November 2021 um 08:37
Hallo Framp,
ich danke dir für deinen Besuch und deinen ausführlichen Kommentar zu meinem Artikel.
Du hast recht, die Dienste sollten besser beendet werden. Das Skript stammt noch aus einer Zeit, in der mein Raspberry Pi noch recht neu war. Ist schon eine ganze Weile her und seither greife ich nicht mehr darauf zurück.
Daher gab es an dieser Stelle keine Überarbeitung mehr. Die Lösung über rsync wird ja im Grunde auch von diversen NAS genutzt und ist auf jeden Fall eine bessere Möglichkeit.
Ich schaue mir das von dir angesprochene Tool mal an, weiß allerdings noch nicht, ob es dazu einen Artikel geben wird. Aktuell nutze ich nur noch einen einzigen Pi und der ist mit RaspberryMatic ausgestattet. Er wird daher anders von mir gesichert als in dem Artikel beschrieben.
Beste Grüße
Antworten

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
Antworten

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
Antworten

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
Antworten

Hans · 26. Oktober 2021 um 20:22
Hallo Peter,
guck dir die Zeile im Script noch mal an … da steht kein sudo vor dem pushd ….
Antworten

Aandreas · 25. Oktober 2021 um 20:36
Hallo Lukas,
da mir gerade mein Octoprint abgeschmiert ist und ich alles neu aufsetzten muss, habe ich genau nach einer solchen Lösung gesucht. Da ich bisher nur ein bisschen VBA geschrieben habe, bin ich in Linux sehr unbedarft. Ich wollte einen USB-Stick verwenden und nur zwei Sicherungen verwenden. Was muss ich schreiben, um den Stick zu nutzen?
Antworten

Lukas · 25. Oktober 2021 um 21:06
Hallo Andreas,
du musst den Pfad anpassen. Und zwar muss er auf den Ordner lauten, wo die Backups gespeichert werden sollen. Also da wo der USB-Stick eingehängt ist.
Das muss in die Variable „BACKUP_PFAD“ gesetzt werden.
Dann kannst du die Variable „BACKUP_ANZAHL“ auf 2 setzen und es werden dann nur zwei Sicherungen gespeichert.
Eine gute Anleitung zur Einbindung eines Sticks findest du hier: https://raspberrytips.com/mount-usb-drive-raspberry-pi/
Beste Grüße
Antworten

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
Antworten

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
Antworten

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
Antworten

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
Antworten

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
Antworten

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.
Antworten

Torsten · 5. November 2021 um 13:40
Hi Lukas,
ich habe noch eine Frage/Idee und hänge aber. Und zwar kann man mit pishrink das Image ja wunderbar auf den eigentlichen Platzbedarf verkleinern (ohne Daten zu komprieren), wenn man mal auf ne andere Karten- oder Plattengröße ausweichen muss. Das wurde hier in anderen Kommentaren auch schon thematisiert und funktionier auch echt super. Ich kann dann nämlich statt SDA1 oder SDA2 direkt SDA komplett mit dd rüberziehen und habe im Endergebnis von meiner 120er Platte dennoch nur ein Image von 8GB. Dieses geshrinkte Image als bootfähiges Image zurückzuspielen klappt einwandfrei, habe ich bereits getestet.
Mit dem Befehl
sudo pishrink.sh PfadZurImagedatei PfadZurNeuenDatei
funktioniert das auf Kommandozeile ohne Probleme.
Wenn ich jetzt aber
sh ./pishrink.sh ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d)-shrinked.img
in die backup.sh einbaue, passiert da leider nix. Meiner (teilweise ganz speziellen) Logik folgend, müsste das doch aber eigentlich so passen, oder?
Vielleicht siehst Du mit Deinen Augen ja ad hoc, was ich da falsch gemacht habe,
Torsten

Lukas · 5. November 2021 um 20:57
Hallo Torsten,
pishrink selbst habe ich nicht ausprobiert. Habe leider auch keinen passenden Raspi dafür mehr im Netz aktiv. Was ich mir allerdings vorstellen kann ist, dass du die Datei erst erzeugen musst und dann „shrinken“ kannst.
Wie sich das Tool mit dem Skript verhält weiß ich leider aktuell überhaupt nicht. Sollte ich da aber auf etwas stoßen, würde ich dir hier in den Kommentaren (so dass es auch andere sehen können) Bescheid geben.
Und sollte sich noch jemanden finden lassen, der mehr dazu weiß, gerne auch hier in die Kommentare! 🙂
Beste Grüße

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
Antworten

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
Antworten

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
Antworten

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… 😀
Antworten

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!
Antworten

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
Antworten

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
Antworten

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?
Antworten

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.
Antworten

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

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
Antworten

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
Antworten

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.
Antworten

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 🙂

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 🙂
Antworten

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
Antworten

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
Antworten

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.
Antworten

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

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!
Antworten

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
Antworten

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! 🙂
Antworten

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 🙂
Antworten

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! 🙂
Antworten

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.
Antworten

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
Antworten

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!
Antworten

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 🙂

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.
Antworten

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! 🙂
Antworten

Harpo · 23. Oktober 2020 um 19:42
Leider habe ich die gleiche Fehlermeldung bei existierendem Verzeichnis ‚Backup‘.
Antworten

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 😉
Antworten

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!

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.
Antworten

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
Antworten

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! 🙂
Antworten

Lukas · 3. August 2020 um 08:56
Hallo Alfons,
danke für die Anmerkung! Ich glaube da werden dir sicherlich eine Leser dankbar sein 🙂
Antworten

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.
Antworten

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
Antworten

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.
Antworten

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
Antworten

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. 🙂
Antworten

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.
Antworten

Dirk Mohrdiek · 7. Juli 2020 um 20:19
Danke für die schnelle Antwort. Hier hilft wohl am besten eine passende, kleinere Speicherkarte.
Antworten

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.
Antworten

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
Antworten

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.
Antworten

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.
Antworten

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.
Antworten

Olaf · 5. Juni 2020 um 12:49
Alles klar, danke für deine Antwort.
Antworten

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.
Antworten

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
Antworten

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.
Antworten

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!
Antworten

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.
Antworten

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.

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.
Antworten

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)
Antworten

Lukas · 7. März 2020 um 13:00
Super, danke dir für die Rückmeldung! Das sind auf jeden Fall gute Nachrichten 🙂
Antworten

Lukas · 3. März 2020 um 19:52
Sehr gerne!
Antworten

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! 🙂
Antworten

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)
Antworten

Lukas · 27. März 2021 um 09:11
Hallo Michi,
vielen Dank für deine hilfreiche Antwort! 🙂
Antworten

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.
Antworten

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
Antworten

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.
Antworten

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.
Antworten

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.
Antworten

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!!!!!
Antworten

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. 🙂
Antworten

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.
Antworten

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!
Antworten

Lukas · 12. Oktober 2019 um 11:31
Super! Das sind tolle Neuigkeiten.
Ich wünsche viel Spaß mit dem Skript und ein tolles Wochenende. 🙂
Antworten

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.
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.

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 🙂
Antworten

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. 🙂
Antworten

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.
Antworten

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.
Antworten

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.
Antworten

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.
Antworten

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! 🙂
Antworten

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.
Antworten

Werner · 11. Juni 2019 um 18:52
Hallo Lukas
das habe ich ja gemacht. Der Ordner ist da
Gruß
Werner
Antworten

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.
Antworten

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.
Antworten

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.
Antworten

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
Antworten

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 !
Antworten

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. 😉
Antworten

Bernd · 25. September 2022 um 12:33
Hallo,
wie wäre es wenn man das Backup Script um eine Verkleinerung des Images mit pishrink ergänzt? Dann wäre die Größe der SD-Karte kaum mehr ein Problem.
Ich versuche es geräde händisch nach dieser Anleitung:
https://hobbyblogging.de/raspberry-pi-vollautomatisch-sichern
Geht aber sicher auch als Bestandteil des Skripts.
Mfg Bernd
Antworten

Bernd · 25. September 2022 um 12:34
Sorry! Falscher Link 😉
https://hoerli.net/raspberry-pi-backups-verkleinern/

Bernd · 25. September 2022 um 15:28
Hallo,
wenn man das Backup Skript um pishrink.sh erweitert geht es super! Da wird das Backup Img gleich verkleinert so dass es auf jede SD Karte passt. Einfach mal Googeln und in das Backup Skript so einfügen:
#!/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
#Backup verkleinern
pishrink.sh ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img
#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
Viel Spaß
Mfg Bernd
Antworten

Lukas · 25. September 2022 um 18:31
Hallo Bernd,
vielen Dank für deine Ergänzung zum Skript.
Da warst du auf alle Fälle schneller als ich antworten konnte. 😉
Tatsächlich wurde das Skript von einigen schon in die Richtung erweitert. Da ich selbst es nicht mehr aktiv nutze, habe ich es natürlich auch nicht mehr weiterentwickelt.
Aber ich bin gerade für Enthusiasten wie dich sehr dankbar, die das auf eigene Faust machen.
Speicherplatz sparen ist auf jeden Fall eine erstrebenswerte Sache.
Smarte Grüße
Antworten