===== 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
(aus https://www.linux-tips-and-tricks.de/de/faq/#a18)
==== 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 [[https://www.it-beratung-koch.de/kb/raspberry-pi-live-backup-der-sd-karte-anlegen/|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 [[https://www.it-beratung-koch.de/kb/raspberry-pi-live-backup-der-sd-karte-anlegen/|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
==== PiShrink für macOS ====
Über [[https://florianmuller.com/quickly-resize-and-shrink-raspberry-pi-sd-card-image-on-macos|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]].
==== Bootable Backup macOS Monterey ====
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.
Update März 2023:
Die Verbindungen zum Mac brechen immer wieder ab. Vielleicht liegt es ja am CIFS? Oder doch am WLAN? Es geht auch nicht, wenn der Mac am LAN hängt, den Raspberry zusätzlich habe ich noch nicht am LAN. Sollte ich nicht besser SMB3 nehmen?
https://www.thedigitalpictureframe.com/installing-samba-on-your-raspberry-pi-buster-and-optimizing-it-for-macos-computers/
Update Sept. 2023:
Nach einem Update kam beim mount der Fehler "mount error(95): Operation not supported". Lösung war, dass man Version 2.0 angeben musste. "sudo mount -t cifs -o vers=2.0,username=..."
Stand September 2023