Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
Backup, Shrink, Compress
Immer, wenn es mal wieder gekracht hat, wünscht man sich ein Backup von 'gestern'. Auf einem Schild habe ich gelesen „kein backup - kein Mitleid“. Das ist zwar richtig, aber was soll man machen?
Das SD-Full-Backup meiner beiden Raspberry dauert jeweils eine Stunde. Runterfahren, SD raus, in SD-Reader, in den Mac rein, unmounten, mit dd kopieren, auswerfen, wieder in den Pi und starten. Dann das gleiche noch mit dem anderen.
Nur die Dateien aus dem User-Ordner kopieren ist eine andere Idee, aber man darf die Datenbank nicht vergessen oder irgendwelche config-Dateien, die man im Zuge der Entwicklung geändert hat.
Bei einem Problem passt dann alles nicht mehr zusammen, und an dem 3 Monate alten *seufz* Full-Backup ist bestimmt soviel inzwischen anders, dass man sich nicht traut es einzuspielen.
Konkretes Problem 1 (Juli 2021): Ich hatte pi3 komplett neu aufgesetzt, gesichert und dann doch auf dem alten weiter gemacht - 3 Monate. Besser neu aufsetzen, oder doch irgendwas von dem jetzt laufenden auf den schon 3 Monate alten rüber kopieren???
Konkretes Problem 2 (Juli 2021): Ich wollte 'nur' was ausprobieren mit umkompilierten von Lire für Butter. 130MB Daten installiert deinstalliert, developer Sachen und dann ging es nicht. Nach dem remote und was auch immer ging die Maria-db nicht mehr, bis ich sie neu installiert hatte. Die Daten waren zum Glück noch da.
Ideen zum Backup der Rechner:
- was habe ich nach dem letzten Backup an Systemsoftware installiert
- welche config-dateien oder anderes habe ich verändert
- was habe ich an eigener software installiert
- was ist an daten 'irgendwohin' z.B. in die Datenbank geflossen.
nicht vergessen:
- im root-user installierte dinge
- in unsichtbaren Dateien/Ordnern befindliche Dinge
Beenden der Services vor dem Backup; starten in umgekehrter Reihenfolge danach:
Service Stop Befehl nfs systemctl stop nfs-kernel-server Samba systemctl stop samba Pilight systemctl stop pilight Cups systemctl stop cups Minidlna systemctl stop minidlna Apache systemctl stop apache2 Wordpress systemctl stop wordpress nginx systemctl stop nginx mysql systemctl stop mysql seafile systemctl stop seafile Owncloud Siehe Apache FHEM systemctl stop fhem iobroker systemctl stop iobroker cron systemctl stop cron
SD-Karte in den Mac und ein Image ziehen
diskutil list sudo diskutil unmount /dev/disk2s1 sudo dd bs=1m if=/dev/rdisk2 of=./20220323_PiBackup.img sudo diskutil eject /dev/rdisk2
Backup der kompletten SD-Karte vom Raspberry->Mac bei laufendem Betrieb
Sicher ist, Datenbankdienste und andere Dienste erst zu beenden, auch wenn dann die HomeAutomation nicht mehr geht. Aber vielleicht Nachts, oder wenn ich unterwegs bin?
Man kann auch alte Logdateien erst löschen. Einiges habe ich von dieser Seite.
am Mac Dateifreigabe aktivieren, bei geteilte Ordner den 'pi_backup'-Ordner nehmen unter Optionen... Windows Dateifreigabe aktivieren sudo mkdir /media/mount sudo mount.cifs //192.168.178.37/pi_backup /media/mount -o user=username # lan und username ersetzen sudo mount.cifs //192.168.178.44/pi_backup /media/mount -o user=username #wlan und username ersetzen sudo fdisk /dev/mmcblk0 (dann p und q) (erste Zeile ist bei mir: Disk /dev/mmcblk0: 29,7 GiB, 31914983424 bytes, 62333952 sectors) sudo dd if=/dev/mmcblk0 of=/media/mount/20210708_PiBackup.img bs=1M (Dauer mit lan<->lan 22:40 Uhr - 23:28 Uhr) sudo umount /media/mount/
Erst hatte ich Probleme, da ich keinen Mac-Ordner angegeben hatte, nur die IP. Geholfen hat dann
tail -f /var/log/kern.log
Wenn der umount nicht geht, rausfinden welcher Prozess zugreift mit (Beispiel):
fuser -m /media/mount returns /media/mount: 1503 ps | grep 1503
Nachdem ich wiederholt - heute hier - über pishrink gestolpert bin (wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh), führe ich es mal auf. Damit kann man die Größe des Images reduzieren.
sudo /bin/bash /etc/scripts/pishrink.sh -d backup.img backup-small.img ca. 3 Stunden: [31.91GB->13.63GB]
und das ganze dann noch Grippen oder 7zippen oder so (besser auf dem Mac, der ist schneller)
gzip -q backup-small.img Keka 7z am Mac ca. 20 Minuten:[13.63GB->8.79GB] mit neuer keka Version nur 10 Minuten
Größenreduzierung um 75% durch pishrink+7z
Image zurückspielen geht nur über die altbekannte Methode mit dem SD-Karten-Leser.
Das gleiche jetzt mit pi3(wifi)→router→lan(Mac) 45min; shrink 2 Stunden; nur zippen: 5GB; 7zip: 6min 4.1GB
Besonderheiten einzelner Rechner
An unterschiedlichen Pi's muss man unterschiedliche services beenden. Beim Zero ist es dann doch leichter, die SD-Karte zu kopieren. Platzreduktion dann, indem man über einen anderen Pi das Springen erledigt. Damit nicht zu viele Daten hin und her gehen vielleicht doch das Packen am schnellen Mac erledigen. Es geht schneller bei einer Netzwerkverbindung als über WLAN.
Es gab ein Problem, dass das Image keine Schreibberechtigung hatte. Dazu dann das Schloss im Info-Feld anklicken und Schreibberechtigungen vergeben.
PI3 /home/pi/backup/shrink_zero_img.sh
Stand März 2022