raspiBackup Release 0.7

Vielen Dank fuer die Logs. Dort finde ich

20241127-004335 DBG 6300:                  --- sourceSDSize: 512109838336 - targetSDSize: 512110190592

und

20241127-005018 DBG 6300:                  --- sourceSDSize: 512110190592 - targetSDSize: 512110190592

Das sind 688 Sektoren a 512 Bytes oder 344 MB die fehlen.

Die SourceSDSize wird aus den Infos in der sfdisk Datei errechnet und dabei kann nur der Space der allokierten Partitionen beruecksichtigt werden. Die TargetSDŚize ist die Ausgabe von blockdev --getsize64 <device>

Kann es sein dass Du auf Deiner SSD die letzte Partition nicht bis zum Ende angelegt hast? D.h. raspiBackup merkt dass nicht bis zum Ende aller Space nutzt wird und expandiert entsprechend. Die nachfolgende Sicherung speichert jetzt die vollstaendige Partitionierung in der sfdisk Datei ab und beim nächsten Restore wird dann die Gleichheit der Groesse bemerkt.

Quote from Franjo G

Es ist durchaus möglich, dass dabei ein kleiner Rest unzugeordnet blieb.

Anders kann ich mir den Effekt nicht erklaeren. Und die beiden Logs bestaetigen es. Hat mich etwas Wuehlerei in den Logs und auch noch Tests bei mir gekostet um das zu verifizieren. Haette ja auch sein koennen dass bei der Partitionsanpassung noch etwas nicht stimmt.

Quote from Franjo G

Dr. Zufall hilft.

Jupp - durch diesen kleinen Unterschied zu mir hast Du den Bug gefunden .

Ich habe nie auf dasselbe Device restored sondern immer auf eine andere SD Karte. Und die haben bekanntlicherweise immer unterschiedliche Groessen. Dann wirst Du zum Mops mit dem Testen ... da Du dabei immer wieder das SrcSystem primen musst. Sonst waere mir das auch aufgefallen.

Vielen Dank fuer Deine Muehe und Geduld.

Quote from Franjo G

aber ich habe nur eine NVME.

Gottseidank - denn dadurch hast Du den Bug gefunden

Franjo G Findest Du die Option -00 nuetzlich? Die Idee kam mir irgendwann kurz vor Ende des Codings fuer 0.7.0.

Quote from Franjo G

Das geht dann wesentlich schneller, als wenn vorher formatiert wird.

War auch meine Idee: Man hat irgendwas Kleines vergeigelt auf dem System und restored dann nur die Dateien die man vergeigelt oder geloescht hat. Der Restore geht dann wesentlich schneller.

Das haette ich auch bei meinem InfluxDB Update einsetzen koennen. Nur war da der Test noch nicht so durch.

Die Option ist aber nur im partitionsorientierten Modus verfuegbar. Sie muesste eigentlich auch in den normalen Modus eingebaut werden.

Mache ich aber nicht.

Eigentlich kam der partitionsorientierte Modus rein wg NOOBS. Das ist aber gottseidank Geschichte ...

Aber mit den grossen Platten/SSDs die es mittlerweile gibt wo man noch viel Platz ausser den zwei notwendigen Systempartitionen hat macht der Modus mittlerweile allgemein Sinn denn er deckt den normalen Modus ab - jetzt nachdem die Anpassung der letzten Partition auch im partitionsorientierten Modus implementiert ist.

Somit werde ich zukuenftig Erweiterungen nur noch im partitionsorientierten Modus einbauen. Wenn Aenderungen wg neuen OSen notwendig sind werde ich natuerlich den normalen Modus weiterhin maintainen.

Bevor ein neues raspiBackup Release allgemein verfuegbar gemacht wird nutze ich natuerlich die Beta Version auch auf meinen Raspberries. Gerade habe ich mal testhalber eine RPi4 mit genutzten 16GB aus einem -P Backup mit der Option -00 restored. Das Backup liegt auf einer per 1Gb connected NAS und das Ziel ist eine SD Karte.

--- RBK0340I: Restore time: 00:01:59.

Da die Restoretimemessage erst gerade von mir eingebaut wurde - macht sicherlich Sinn - muss ich jetzt zum Vergleich noch mal den Restore ohne die Option -00 laufen lassen.

Update kommt gleich ...

UPDATE:

--- RBK0340I: Restore time: 00:12:00.

Klar gibt es zwischen dem Restore mit der Option -00 keine grossen Updates und somit ist das die beste Restorezeit die man in meinem Falle erreichen kann. Wenn man aber durch irgendwelche Updates sein Systen unbrauchbar gemacht hat ist das eine sehr schnelle Methode das System wieder brauchbar zu machen

Anyhow moechte ich einen Jeden raspiBackup Nutzer ermuntern die Beta mal (an)zu testen und Feedback zu geben. Ist immer unangenehm wenn nach kurzer Zeit einer neuen Release wie z.B. 0.7.0 relativ schnell eine 0.7.0.1 oder sogar 0.7.0.2 nachgeschoben werden muss

Habe gerade bemerkt dass er Link auf die neuen Features und Enhancements fuer 0.7 im ersten Beitrag dead war da ich die Release auf 0.7 geaendert habe und noch auf 0.6.10 verwiesen wurde Der Link ist jetzt korrigiert sowie auch hier direkt aufrufbar.

Im englischen Forum hat jemand darauf hingewiesen dass es ganz sinnvoll wäre mal shellcheck über raspiBackup laufen zu lassen. Das war schon vor 2 Jahren von mir vor Weihnachten geplant aber da das mir zu dröge war ist der Issue im Backlog gelandet.

Ich habe den Issue wieder herausgeholt und beseitige shellcheck Warnungen immer mal wieder wenn ich Abends Lust habe. Ist schon bei der Menge von Code sehr dröge zumal die meisten Hinweise schnell gefixed sind und kein Problem darstellen..

Eben habe ich aber eine Warnung von shellcheck bekommen die valide ist und die leider ein paar größere Änderungen im Code erfordert.

Vor Weihnachten wird es deshalb sicherlich nichts mehr damit die Beta zu finalizen und zu publishen

Quote from DBa

Kleiner Verbesserungsvorschlag für die finale Version:

Ist eine gute Idee. Ist schon eingebaut

--- RBK0092I: Saving partition mmcblk0p2 (55.20 MiB/6.61 MiB) ...

Quote from DBa

Mit dieser Syntax ist anders herum intuitiver (6.61 MiB/55.20 MiB), also wenn man auf "used" und "overall" verzichtet.

Hm ... ich finde es andersherum intuitiver So gross ist die Partition und soviel ist genutzt.

Quote from DBa

Da sollte 0.7.0 stehen, oder?

Good catch Schon geändert