Entwicklungen

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

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?

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
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) 14:15 Uhr -