Habe es doch wie Du vorgeschlagen hast umgedreht. Saving #bytes von #bytes ist doch intuitiver.

raspiBackup Release 0.7.0
-
framp -
November 9, 2024 at 9:25 PM -
Thread is Unresolved
-
-
raspiBackup Release 0.7.0? Schau mal ob du hier fündig wirst!
-
da warte ich auf die Implementierung der BTRFS-Snapshots.
Das wird sicherlich in der nächsten Release drin sein denn das ist eine gute Idee. Aber da musst Du Dich schon noch etwas gedulden. Erst muss die aktuelle Beta noch fertiggestellt werden. Und dann hängt es von meiner verfügbaren Zeit ab wie schnell ich eine 0.7.1 nachschieben kann mit dem btrfs Support.
-
da warte ich auf die Implementierung der BTRFS-Snapshots.
Das wird sicherlich in der nächsten Release drin sein denn das ist eine gute Idee. Aber da musst Du Dich schon noch etwas gedulden. Erst muss die aktuelle Beta noch fertiggestellt werden. Und dann hängt es von meiner verfügbaren Zeit ab wie schnell ich eine 0.7.1 nachschieben kann mit dem btrfs Support.
Ich darf mich ja trotzdem schon darauf freuen
Und in der Zwischenzeit kann ich ein paar code-Schnippsel zur Verfügung stellen:
- Bestimmen des Dateisystemtyps machst Du vermutlich schon irgendwo; wenn nicht, dann hier:
findmnt -n -o FSTYPE /dev/$PART|| echo "none"
- Snapshot kreiieren:
btrfs subvolume snapshot "$(findmnt -n -o TARGET /dev/$PART)" "/$(basename "$NAME")"
- Der Snapshot ist dann unter /$NAME zugreifbar, als ein extra Mountpoint.
- Snapshot wieder entfernen:
btrfs subvolume delete "$(findmnt -n -o TARGET /dev/$PART)/$NAME"
Die zu bearbeitende Partition ist (ohne führendes /dev) in $PART, der Name des Snapshots - in $NAME.
-
Und in der Zwischenzeit kann ich ein paar code-Schnippsel zur Verfügung stellen:
Danke. Gerne. Dann komme ich schneller on speed mit btrfs. Aber bitte im git issue
Das ist mein zentraler Anlauf- und Dokumanentationspunkt für alle Arbeiten an allen Issues.
-
Aber bitte im git issue
-
DBa Wenn ich mit btrfs-convert die rootpartition konvertiere bootet das System nicht mehr. Wie ich herausgefunden habe muss dazu erste einmal die initrd neu gebaut werden mit dem btrfs modul, die cmdline.txt und fstab muss btrfs statt ext4 bekommen und was weiss ich noch was noch angepasst werden muss.
Hast Du einenLink auf eine Anleitung handy wie man möglichst einfach die Rootpartition eines existierenden Systems auf btrfs umstellen kann? Ich dachte ich erstelle mir mal eben in 5 Minuten zwischen Beta Tests ein System mit btrfs um mal erste Erfahrungen zu sammeln - aber jetzt sitze ich schon mehr als 60 Minuten dran
-
DBa Wenn ich mit btrfs-convert die rootpartition konvertiere bootet das System nicht mehr. Wie ich herausgefunden habe muss dazu erste einmal die initrd neu gebaut werden mit dem btrfs modul, die cmdline.txt und fstab muss btrfs statt ext4 bekommen und was weiss ich noch was noch angepasst werden muss.
Hast Du einenLink auf eine Anleitung handy wie man möglichst einfach die Rootpartition eines existierenden Systems auf btrfs umstellen kann? Ich dachte ich erstelle mir mal eben in 5 Minuten zwischen Beta Tests ein System mit btrfs um mal erste Erfahrungen zu sammeln - aber jetzt sitze ich schon mehr als 60 Minuten dran
Ich musste dazu nur eine Sache ändern: in der cmdline.txt "rootfstype=ext4" ersatzlos rauslöschen (und natürlich der Partition das richtige Label verpassen).
Wenn dieser Parameter nicht mehr da ist, bestimmt er den Typ von allein. Zumindest bei Ubuntu, welches OS benutzt Du?
-
Ich nutze RaspianOS lite für meine raspiBackup Tests um die Backupzeiten minimal zu halten.
Die UUIDs habe ich angepasst in cmdline.txt und fstab wie auch den fstype. Das reicht aber nicht da das initrd noch den btrfs Support erhalten muss. Ohne den kann in den Dateien btrfs stehen soviel wie will ... da tut nix.
Ich kümmere mich jetzt weiter um die raspiBackup 0.7.0 Beta. Das ist wichtiger. Ich dachte nur ein System könnte mal eben schnell auf btrfs umgestellt werden
-
Wie Ihr vielleicht gemerkt habt habe ich die Beta wieder unpublished. Es sind noch verschiedene Dinge dazugekommen die von mir erst noch getestet werden müssen.
Auch gab es eine Menge usability Fixes - also Checks und Meldungen dass irgendwas nicht richtig konfiguriert wurde oder im Environment nicht OK ist.
Das Licht am Ende des Tunnels ist zu sehen. Aber leider noch nicht ganz
-
Schon wieder eine SD Karte dead
Ist erstaunlich wie schnell doch SD Karten die Grätsche machen wenn immer wieder ein Backup restored wird.
Anyhow - die Beta ist backwardcompatible ( Danke simonz).
Dummerweise kannte die 0.6.9.1 das neue Backupverzeichnisformat nicht und stieg beim Backup aus wenn man mit der Beta 0.7.0 Backupverzeichnisse erstellt hatte. Ich habe den 0.6.9.1 Code jetzt updated so dass sowohl Backup erstellt werden können wenn 0.7.0 Backupverzeichnisse existieren wie auch 0.7.0. Backups mit der Release 0.6.9.1 restored werden können.
Mit sudo raspiBackup -U -S wird die lokale raspiBackup Release auf den neuen Stand von 0.6.9.1 updated.
-
Wäre es nicht eine gute Idee gewesen, Release 0.6.9.2 daraus zu machen, statt 0.6.9.1 zu ändern?
-
jein. Ich sehe Deinen Punkt.
Aber wenn ich die Versionsnummer erhöhe bekommt jeder den Hinweis dass es eine neue Release gibt obwohl die 0.70. Beta noch nicht mehr verfügbar ist. Ich bin immer noch am Testen. Wenn sie dann verfügbar sein wird wird kaum jemand wieder auf die 0.6.9.1 zurückgehen. D.h. die updated 0.6.9.1 ist eigentlich nur für Leute interessant die die Beta testen. Und auch für mich der im Mixedenvironment testet.
-
Ich halte grundsätzlich nichts davon, einmal releaste Versionen nachträglich zu modifizieren. Im Falle der Fehler ist es auch hilfreich, wenn man Versionen ausprobieren kann, um festzustellen, ab welcher Version der Fehler auftritt.
-
Jeder Codestand meldet seinen git commit sha. Somit kann ich jederzeit den jeweiligen Codestand aus dem git ziehen und mir ansehen
-
-
Nachdem ich mal wieder eine Handvoll SD Karten durch intensive Tests der Beta geschrottet habe ist jetzt die 0.7.0 Beta wieder online
. Ein paar kleine Bugs habe ich noch entdeckt und gefixed.
Wer also Lust und Zeit hat ist gerne eingeladen die Beta #2 (noch einmal) zu testen
-
Quote
6) Ein neues Backup wird erst einmal nicht im Backupverzeichnis erstellt sondern in einem tmp Verzeichnis. Wenn aus irgendwelchen Gruenden der Backup abbricht bleibt dann keine Leiche im Backupverzeichnis stehen.
Was bedeutet das ? Da ich aktuell tar_Backups erstelle, müsste man also 4-5GB zusätzlich Platz auf der microSD vorhalten ? Ich nutze aktuell nur 8GB-Karten
-
Was bedeutet das ? Da ich aktuell tar_Backups erstelle, müsste man also 4-5GB zusätzlich Platz auf der microSD vorhalten ?
Das bezieht sich auf die genutzte Verzeichnisstruktur auf dem Ziel-Datenträger, nicht auf die zu sichernde Quelle.
-
Nur wenn raspiBackup abstürzt kann das eintreten was Du befürchtest. Allerdings kann das auch schon jetzt auftreten. Und dann kannst Du auch nicht erkennen dass der Backup unvollständig ist.
Die Wahrscheinlichkeit für diesen Fall ist aber sehr gering. Dann bekommst Du einen kontrollierten Fehlerabbruch dass kein Platz mehr da ist und musst das tmp Verzeichnis manuell löschen.
-
Verstehe es nicht...
Wird das tar-Backup in meinem Fall RPi mit microSD zunächst lokal gespeichert oder wird ein /tmp auf dem Ziellaufwerk erstellt?
-
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!