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

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

(aus https://www.linux-tips-and-tricks.de/de/faq/#a18)

diskutil list
sudo diskutil unmount /dev/disk2s1
sudo dd bs=1m if=/dev/rdisk2 of=./20220323_PiBackup.img
sudo diskutil eject /dev/rdisk2

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

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

Über diese] Seite bin ich erst darauf aufmerksam geworden, dass es seit vier Jahren auch ein PiShrink für macOS gibt. Damit sollte es natürlich noch schneller gehen. Es wird dort e2fsprogs genutzt, in dem alle nötigen Tools vorhanden sind . Anleitung findet sich [[https://github.com/lisanet/PiShrink-macOS|hier.

Siehe: https://forums.macrumors.com/threads/carbon-copy-cloner-6-monterey-bootable-backup.2332092/ bzw.: https://forums.macrumors.com/threads/macos-12-13-carbon-copy-cloner-users-thread.2302964/?post=30065034#post-30065034

You need to prepare the volume for APFS replication to work. 11.x and the new 12.0 creates both a system and data volumes. Erase both in the disk utility → unmount backup target storage, erase system volume not the data volume, select erase volume group as preparation. In CCC you need to target that one volume as a destination in CCC with a new task. Then you will need to use the CCC choices in under your destination. Screen Shot 2021-07-01 at 5.09.15 PM.png

click on the destination disk you will see this.

Screen Shot 2021-07-01 at 5.11.36 PM.png Enter the legacy bootable backup assistant. I don't use SafetyNet for incremental backups, so that is off. Allow CCC to erase the volume.

Screen Shot 2021-07-01 at 5.13.00 PM.png Now when you start CCC backup task it should tell you that you are Replicating the APFS filesystem data. After it gets done this in disk utility should show both a system volume and a data volume. Now see if it will allow you boot off of it.

https://bombich.com/kb/ccc6/cloning-macos-system-volumes-apple-software-restore

Note that bootable clones are no longer the default method for CCC and are not recommended because of the limitations mentioned. You have to use the LBBA (Legacy Bootable Backup Assistant) in CCC to make a bootable clone.

Superduper! Has the same limitations and can also make a bootable clone. Details here:

https://www.shirt-pocket.com/blog/index.php/shadedgrey/C5/

As you can see the two companies are taking very different approaches to the same task with basically the same tools.

I have tested both this past week on M1 MBAs with Monterey.

Stand März 2022