Komplett-Backup als "Katastrophenschutz"

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Komplett-Backup als "Katastrophenschutz"

      Irgendwie fehlt mir da was auf der UHD-Schiene.

      Das Experten-Menü mit der Sicherung einzelner Partitionen ist erstmal weg und ein Angebot zur 'Komplettsicherung' von Kernel + RootFS fehlt auch ... noch.

      Nun stehe ich vor dem Problem, dass ich meine Notfall-Reserve (OpenHDF 6.2) in Bank 1 updaten möchte (6.3 ist gerade raus).

      Das Online-Update geht nicht, wenn ich nicht vorher die vorhandene Version auf einen aktuellen Build der 6.2 aktualisiere. Das Aktualisieren geht aber auch nicht!

      Also bin ich gezwungen, das komplett neu zu flashen, was aber entweder mit disk.img meine Speicherstruktur (mit dem Common-Bereich in Partition 11) platt macht, oder aber bei einem ofgwrite mit ausgepacktem und von disk.img befreiten HD51-Verzeichnis - im schlimmsten Fall - die Bank 1 unbrauchbar macht. Dann ist eh Alles platt.

      Fast alle Optionen würden den Verlust der anderen drei Bänke bedeuten, auf denen meine Neutrino-Testimages in ständigem (Entwicklungs-) Gebrauch sind. Und aus diesem Grund auch strukturell stark von den üblicherweise verwendeten Original-Images abweichen. Da auf die Original-Images keine Rücksicherung meines aktuellen StatusQuo funktioniert, müsste ich die alle von Hand "nachrüsten".

      Wäre daher viel schöner, wenn mir Jemand von den Linux-Gurus - zur Not auch heimlich - ein Script zustecken könnte, mit dem ich meine drei Bänke (DDT, TuxBox und NI) als ofgwrite-fähige Komplettsicherung (kernel.bin und rootfs.tar.bz2) für ein eventuelles Notfall-Backup ablegen könnte... 8)

      Vielleicht hat aber auch schon Jemand dieses Feature in Neutrino eingebaut und braucht nur noch Jemanden zum Testen ?!? ^^
    • Verstehe zwar nicht warum man ein E2 Image auf der Box braucht :D ....aber :
      Man kann doch von eine Neutrino Partition mit ofgwrite ein Image flashen.
      Die E2 Images kann man ja auspacken und die beiden Dateien nach /tmp schubsen, dann per Telnet : ofgwrite -m1 /tmp und fertig ist der Lack ( pray if E2 would start :D )

      Das aktuelle root mit mount --bind irgendwo hin mounten und mit tar einpacken sollte auch kein Problem sein....
      Und den passenden Kernel hat man ja evtl. von der 1. Install ( ist ja im Archiv )
    • @PauleFoul
      Das sichert nur die Verkehrsdateien, wie /var und so weiter.

      Ich brauche das Speicher-Abbild der Kernel-Partition als kernel.bin und der zugehörigen Firmware-Partition als rootfs.tar.gz

      @DboxOldie
      Die Enigma-Partition brauche ich als 'ausgereiftes' Notfall-Startimage.
      Und als abschreckendes Beispiel...
      pray if E2 would start
      Genau deshalb habe ich den Thread gestartet :D

      Das aktuelle root mit mount --bind irgendwo hin mounten und mit tar einpacken
      Ich schau mir mal die make-Targets für die flashimages an. Kann ich vielleicht wieder was lernen...
    • Nö, nur "Sicherung wird aus /var/ erstellt"
      Mit den Optionen "tmp" und "Deaktivieren".

      Ich habe die drei Dateien in das plugin-Verzeichnis unter /lib/tuxbox/ gelegt sowie .bin und .so auf 755 gesetzt.
      Alternativ auch saveall.bin nach /var/plugins => es bleibt dabei.

      Ich vermute, die HDD (/dev/sda == NEO1TB) wird in dem NI-Image garnicht erkannt.
      Ich versuche morgen mal einen Symlink "HDD" darauf zu legen...

      Nachtrag:
      Jou, das war's.
      jetzt kommt auch "HDD" und "4 Partitionen sichern HDD"
      Mal sehen was dabei rauskommt...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Janus ()

    • Sollte mich wundern wenn es an der Partitionierung hapert...

      Denn die Reihenfolge der Kernel und rootfs Partitionen ist die gleiche wie bei E2 (ATV), es gibt lediglich eine Part mehr
      und die rootfs sind etwas kleiner.

      Oder sichert das Tool die kompletten 800 MiB (E2 Part) und kapituliert vor den 750 MiB (DDT Part) ?

      Mal zum spielen :
      mkdir -p /tmp/buimg <--- Verzeichnis in /tmp anlegen
      mount --bind / /tmp/buimg <---- das aktuelle rootfs da mounten
      tar -cvf /tmp/rootfs.tar -C /tmp/buimg ./ <--- ein tar File erzeugen in /tmp

      Nun kannst auf einer Linux Maschine mit bzip2 das tar File noch komprimieren, und bekommst ein rootfs.tar.bz2 ( bzip2 ist glaube nicht in den Images )
      Genau das was ofgwrite braucht, und wie oben erwähnt: Kernel hat man ja aus Install, der ist ja nicht verändert.
      Kann man aber auch mit dd rauspuhlen, wenn man will.
    • PauleFoul schrieb:

      Hast Du den /saves/ Ordner mit angelegt?
      Ja, nachträglich! (Könnte man vielleicht in das Tool einbauen)

      Danach lief das durch (wobei die Meldung 2x angezeigt wurde, einmal ganz kurz und dann - darunter - für den restlichen Vorgang nochmal.

      Was das Ergebnis betrifft:
      Scheint komplett und umfasst sogar die Partitionen 10 (Swap) und 11 (SwapData). Ist also durchaus zu gebrauchen. Kurze Stichprobe nach dem etwas umständlichen Auspacken unter Windows: Daten sind lesbar.

      Ich denke, das ist im Prinzip zu gebrauchen, wenn eine Rücksicherung anwenderseitig selektiv (nach Bank oder Partition) gemacht werden kann. Ich möchte mir ja im konkreten Fall nach einem Not-Update nicht die Bank 1 wieder mit der Vorversion überschreiben.


      Der von DboxOldie zuletzt gepostete Script-Entwurf scheint mir aber auf den ersten Blick auch vielversprechend.
      Muss ich noch ausprobieren...
    • DboxOldie schrieb:

      Mal zum spielen
      Das Spielen mit dem Script-Vorschlag hat funktioniert!

      Im NI-Image ist bzip2 per busybox verfügbar, also kommt damit - nach angemessener Wartezeit - ein rootfs.tar.bz2 raus
      Das zumsammen mit einem kernel.bin - aus meiner letzten ni350-...hd51.tgz extrahiert - in ein Verzeichnis tmp/HD51 gelegt und dann aus Bank 2 (DDT-Image) per

      ofgwrite -m4 /tmp/HD51

      erfolgreich wiederhergestellt.

      Da hat es auch etwas weniger wehgetan, dass ich per Filezilla mal eben /tmp/buimg gelöscht habe!
      (war leider kein Symlink) Naja, WinDoofie halt...

      Ich denke, mein Problem ist "technisch" gelöst.
      Werd' das irgendwann mal idiotensicher "einpacken", aber erstmal reicht mir das so per Telnet-Aufruf.
      Dank für Eure Hilfe!
    • Janus schrieb:

      Da hat es auch etwas weniger wehgetan, dass ich per Filezilla mal eben /tmp/buimg gelöscht habe!
      (war leider kein Symlink) Naja, WinDoofie halt...
      :D

      Nee ist kein Sym, sondern echtes Verzeichnis in /tmp als Mountpoint für root ( / )
      Löschen bedeutet dann : Ast absägen auf den man sitzt....
      Kann man ja nach Nutzung umounten :
      umount -lf /tmp/buimg

      Da es in /tmp liegt ist das nach reboot eh weg