Backup via rsync: Bootpartition?

  • Hallo, ich beschäftige mich gerade mit dem Thema Backup und probiere vieles aus, auch um zu sehen was für mich das Richtige ist. Aktuell arbeite ich mit rsync. Jetzt habe ich bereits alles Daten die sich auf der Systempartition der SD-Karte befinden, via rsync in den Backupordner kopiert. Dabei habe ich aber den Bootordner erstmal leer gelassen. Und nun bräuchte ich mal Hilfe.

    Alles was sich im Bootordner befindet, befindet sich ja auch auf der Bootpartition auf der SD-Karte. Was stelle ich nun mit diesem Ordner an? Einfach mit kopieren? In einem seperatem Ordner? Im aktuellen Zustand muss ich jedenfalls so vorgehen, dass ich zum wiederherstellen des Backups, die SD-Karte neu formatieren und dann das original Raspbian Image einmal aufspielen muss. Dann bootet er auch und ich kann die Daten wieder auf die SD-Karte kopieren. Aber wie mache ich das ohne vorher das Image neu zu installieren?

  • Ok, also kann ich den Bootordner schon gleich via rsync mit kopieren, ich muss beim wiederherstellen des Backups auf eine neue SD-Karte nur darauf achten, dass der Inhalt des Bootordners nicht mit auf die Systempartition kommt, sondern in die Bootpartition.

    Gut, wie sieht es denn mit der Größe aus, mit der ich die Partitionen der neuen SD formatiere? Muss ich mich an eine bestimmte Größe halten (Boot und Systempartition) oder ist das grundsätzlich egal, solange genug Platz für die Daten vorhanden ist?

    Und wie passe ich die beiden Dateien an? Die 2 UUIDs die im Moment in der fstab eingetragen sind lauten "PARTUUID=0abee9f0-01" und "PARTUUID=0abee9f0-02" und in der /boot/cmdline.txt steht "root=PARTUUID=0abee9f0-02"

    Wie finde ich im Falle einer Wiederherstellung die richtige UUID heraus, die ich da eintragen muss?

  • Warum nimmst Du nicht einfach raspiBackup? Damit erstellst Du höchst bequem ein Backup der Speicherkarte und bist immer auf der sicheren Seite, ohne grübeln zu müssen, wie Du es nun anstellst. Auf den ersten Blick sieht das etwas verwirrend aus, aber die Anleitung ist sehr gut, und wenn erst mal alles konfiguriert ist, kann man die Sache einfach vergessen und nur noch benutzen. Und wenn etwas passiert ist, spielt man das letzte Backup auf eine Karte zurück und alles ist wieder gut.

  • Hallo vielen Dank erstmal. Ich habe es jetzt hinbekommen, so ein Backup via rsync auch wiederherzustellen. Die Pi bootet und die Einstellungen scheinen alle so zu sein, wie ich sie zum Zeitpunkt hatte, an dem ich das Backup angelegt habe. Super soweit.

    Leider gibts es ein Problem. Sudo funktioniert nun nicht mehr: sudo: /usr/bin/sudo muss dem Benutzer mit UID 0 gehören und das »setuid«-Bit gesetzt haben

    Auch via su auf den root wechseln geht nicht mehr, denn obwohl ich das Rootpasswort weiß, weil ich es vor dem Backup vergeben habe, wird es nun abgelehnt. Ich habe keine Ahnung was da schief gelaufen sein soll. Die Partitionen waren jedenfalls leer als ich die Backupdaten draufkopiert habe.

    Warum nimmst Du nicht einfach raspiBackup? Damit erstellst Du höchst bequem ein Backup der Speicherkarte und bist immer auf der sicheren Seite, ohne grübeln zu müssen, wie Du es nun anstellst. Auf den ersten Blick sieht das etwas verwirrend aus, aber die Anleitung ist sehr gut, und wenn erst mal alles konfiguriert ist, kann man die Sache einfach vergessen und nur noch benutzen. Und wenn etwas passiert ist, spielt man das letzte Backup auf eine Karte zurück und alles ist wieder gut.

    Ja da hast du sicher recht, raspiBackup mag bequem und gut geeignet für diesen Zweck sein, aber ich finde es lehrreicher, mir solche Sachen von Grund auf anzueignen. Würde ich nur solche Skripte nutzen, ohne zu wissen, was da eigentlich passiert, würde ich ja nie lernen, wie Linux funktioniert :)

  • Nimm die SD-Karte aus dem RPi und stecke sie in einen anderen Linux-Rechner. Dort kannst du als root die Attribute von

    /usr/bin/sudo ändern.

    So sehen die Rechte der Datei aus:

    -rwxr-xr-x 1 root root 147560 Sep 28 03:17 sudo

    In was muss ich die abändern?

    Möglicherweise hast Du nur auf die "extended attributes" als rsync - Option vergessen.

    Servus !

    So sieht der rsync Befehl zum anlegen des Backups bei mir aus:

    sudo rsync -aAHXv --delete --exclude-from=/mnt/Backupplatte/Raspbian/rsync-exclude.txt / /mnt/Backupplatte/Raspbian/Systembackup_`date +%d%b%Y`/

  • Ja da hast du sicher recht, raspiBackup mag bequem und gut geeignet für diesen Zweck sein, aber ich finde es lehrreicher, mir solche Sachen von Grund auf anzueignen. Würde ich nur solche Skripte nutzen, ohne zu wissen, was da eigentlich passiert, würde ich ja nie lernen, wie Linux funktioniert :)

    Es ist allerdings die Frage, ob es für einen, der Klavierspielen lernen will, sinnvoll ist, sich gleich Liszts h-Moll-Sonate aufs Pult zu legen...

    Aber wenn Du verstehen willst, wie das geht, hole Dir das Skript und studiere es gründlich. Da hast Du ein gutes Beispiel, wie so etwas funktioniert, in aller nötigen Ausführlichkeit, von Leuten erstellt, die wirklich viel davon verstehen. Das ist mit Sicherheit ergiebiger als langes Herumstochern im Nebel.

  • Aber wenn Du verstehen willst, wie das geht, hole Dir das Skript und studiere es gründlich.

    Bei 5000 Codezeilen ist das sicherlich keine Aufgabe die mal so eben schnell erledigt ist :no_sad:

    Den Ansatz von Zottel finde ich schon OK. Es gibt eben diejenigen die ein Auto nur fahren wollen und diejenigen die genau wissen wollen warum ein Auto faehrt wenn sie damit fahren. Das Letztere mit einer steilen Lernkurve zu kaempfen haben ist sicherlich jedem klar :)

    Zottel Die rsync Optionen sind OK. Ich vermute Du hast das rsync Backup nicht auf ext3 oder ext4 abgelegt oder es irgendwie nicht per root gesichert bzw restored.

  • Das setUID Bit kann auch am Mountpoint ausgefiltert werden, wenn die Mountoption "suid" nicht gesetzt ist.

    Das fehlende setUID ist an den Rechten des Eigentümers zu erkennen Statt rwx wird rws angezeigt.

    Manuell wird das Bit mit chmod gesetzt. Siehe Abschnitt SETUID AND SETGID Bits von < man chmod >

    Mit rsync -X sollte normalerweise das setUID Bit am EXT4 Ziel ankommen, wenn nicht ein Mountbefehl dazwischenfunkt.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Also die externe Festplatte, auf der ich das Backup lege hat ext4 als Filesystem. Könnte höchstens sein, dass ich wirklich bei einem der Kopiervorgänge das sudo vergessen habe. Oder ist es zwingend erforderlich sich dazu komplett als root umzumelden? Achja, ich habe das Backup dann auch noch via gzip in eine tar gelegt: sudo tar -vzcf /mnt/Backupplatte/Raspbian/Systembackup_`date +%d%b%Y`.tar.gz /mnt/Backupplatte/Raspbian/Systembackup_`date +%d%b%Y`/

    Kann da eventuell was mit den Rechten schiefgelaufen sein, oder beim wieder Entpacken aus dem Archiv?

    Und noch eine Frage. Ich weiß, dass wenn ich die SD unter Windows mit Etcher flashe, die Partitionen dann ein Label haben ("LABEL_FATBOOT="boot" LABEL=boot" und "Label=root"). Ich formatiere die SD-Karte aber im Moment mit fdisk und kopiere dann das Backup einfach drauf. Da wird ja standardmäßig kein Label vergeben und somit besitzen die 2 Partitionen dann auch keins. Sind denn für den korrekten Betrieb Label notwendig?

  • Sorry ganz überlesen. Wie man das setUID Bit einer Datei manuell zuordnet, habe ich inzwischen begriffen, dank dem Hinweis von bombom. Daher funktioniert inzwischen auch sudo wieder, Allerdings scheint noch viel mehr im Argen zu sein (su gibt weiterhin Fehler bei der Authentifizierung aus usw,) daher denke ich, ich habe irgendwo bei den Schritten des Backups irgendwas falsch gemacht und ich fang nochmal von Vorn an.

    Was genau ist mit Mountoption gemeint in der die suid mit gesetzt werden muss? Der fstab-Eintrag in Raspbian oder der Vorgang bei dem ich vorübergehend auf einem anderen Linuxsystem die SD formatiere und das Backup drauf kopiere? Da nutze ich ja lediglich mount /dev/sdb2 /mnt/sdroot

  • Kann da eventuell was mit den Rechten schiefgelaufen sein, oder beim wieder Entpacken aus dem Archiv?

    Versuche doch erst einmal Deinen rsync Backup wieder erfolgreich zu restoren und danach den wieder in ein tar zu stecken. Ein Schritt nach dem anderen ;)

    Ausserdem verstehe ich nicht ganz warum Du dann den Backup nicht gleich in ein tar stopfst und dem Umweg ueber ein rsync Backup machst :conf:

  • Aktuell arbeite ich mit rsync. Jetzt habe ich bereits alles Daten die sich auf der Systempartition der SD-Karte befinden, via rsync in den Backupordner kopiert. Dabei habe ich aber den Bootordner erstmal leer gelassen.

    Mir ist im Moment nicht ganz klar, ob Du wirklich ausreichend differenzierst. Deswegen mal vorab eine Grundsatz-Aussage:

    Du kannst ein laufendes System nicht mit rsync dergestalt sichern, dass du hinterher mit diesem Backup wieder ein lauffähiges System herstellen kannst. rsync ist ein reiner Datei-Kopierer, damit kannst Du keine Sockets sichern, keine Anwendungs-Caches, Du verlierst voraussichtlich alle Hardlinks und alle Softlinks, ebenso die Capabilities, im Grundegenommen verlierst Du ganz viel von dem, was vorher das System tatsächlich ausgemacht hat. Das gleiche gilt für tar.

    Entweder Du beschränkst Dich darauf, mir rsync und tar reine Nutzerdaten (also Anwender-Dateien) und ggf. Konfigurationsdateien zu sichern, oder Du sicherst die ganze Paritition mit cat oder cp. Eine schlechte Wahl wäre es 'dd' dafür zu nehmen.... wobei das natürlich auch funktioniert. Aber wenn Du die ganze Partition sichern willst, muss Dir klar sein, dass das beim laufenden System in gewisser Weise russisches Roulette ist.... es kann gut gehen, das wird es sogar oft, aber es kann auch beim Restore übel knallen, so das Du eben doch vor einem Totalverlust stehst. Und bei einem Fullbackup muss Dir zusätzlich klar sein, dass das bereits am nächsten Tag exakt die gleiche Relevanz hat, wie der Wetterbericht für vorgestern. Und welche Erkenntnis auch noch spannend ist, wenn Du ein Fullbackup mit 150.000 oder mehr Dateien sicherst, sicherst Du 99% an Dateien, die beim Erstellen einer neuen SDC mit dem Raspbian-Iso automatisch sowieso wiederkommen. Die meisten fühlen sich allerdings besser, wenn sie Zeit, Aufwand und Speichermedien für 99% Müll verbraten, selbst wenn das wirklich unnütz ist. Insofern ist das zwar emotional völlg ok, technisch aber überflüssig.

    Die Frage bleibt, was verstehst Du unter Daten auf der Systempartition? Und zwar vor dem Hintergrund, das bei Linux erstmal sowieso alles Dateien sind. Sind mit 'Daten' die Nutzerdaten gemeint, die von Anwendern erzeugt wurden? Oder sind es alle Dateien des Betriebsystems? Oder sind es die Konfigurationsdateien, die Du angelegt hast? Oder sind das schlichtweg alle auf der SDC gespeicherten Dateien, völlig undifferenziert?

    Wie man das setUID Bit einer Datei manuell zuordnet

    Mein Rat: Du solltest an solchen Sachen generell nicht rumspielen oder daran Veränderungen vornehmen. In etlichen Jahren hatte ich noch nie auch nur an einem einzigen System die Notwendigkeit, so etwas tun zu müssen.... weder bei raspbian, noch bei debian, ubuntu, mint oder fedora. Die Betriebssysteme sind immer so eingestellt, dass sie auch ohne solche Eingriffe fehlerfrei funktionieren. Ichwürde auch keinen Ratschlägen folgen, die so etwas empfehlen, wenn Dir die Auswirkung nicht klar ist. Mit dem fahrlässigen Setzen des suid-Bits hebelst Du mal eben ganz schnell jegliche Sicherheit Deines Systems aus.

    2 Mal editiert, zuletzt von WinterUnit16246 (29. September 2019 um 15:06)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!