App-Backup

  • Was habt Ihr für Sicherungs-Apps im Einsatz, um im Falle eines Neuaufspielens des SF-Images, RatzFatz wieder zum gewohnten System zu kommen?

    Denn die SF-Datensicherung kann das so umfänglich ja nicht, die sichert ja nur die persönlichen Daten (Bilder, Video, Kontakte, Kalender usw.)


    -volker-

  • Wie ich vorgestern erst erleben musste: nichts. ||

    Andererseits war ein durchwischen auch mal ganz gut, es hatten sich gefühlt 100 nutzlose Apps da angesammelt. Hab jetzt nur wieder installiert, was ich augenfällig sofort brauchte. Hat mich trotzdem einen halben Tag gekostet. Und eine halbe Flasche Rotwein. ^^


    Aber: gute Frage, wird ja demnächst (eventuell) wieder gebraucht. Ich schliesse mich mal an.

  • Hi,


    ich habe, seit der Backup-Enttäuschung mit den boardeigenen Mitteln, mal My Data Transfer installiert. Das Ding macht ein dickes Backup (bei mir ca. 360 MB)...

    MyDataTransfer.jpg

    ...ich habe mich aber noch nicht drum gekümmert, was in dem Backup vorhanden ist. Das Backup hat die Endung .mydatatransfer

    Ich muss mich da mal durchprobieren, was das genau ist (tar, zip, usw.)

    Evtl. lese ich auch mal die Beschreibung des Prog. (soll ja helfen).


    -volker-

  • Zum APK Extractor hätte ich da mal eine Frage. Der schreibt die Files doppelt in den internen Speicher

    APK_Extractor.jpg

    Auch wenn ich, was ich noch nicht gemacht habe, ihm die SD-Karte dafür anbiete, wird er wohl immer noch in /home/nemo_bind/... etwas ablegen.

    Kann man da nicht besser Symlinks für einfügen, oder ist /home/nemo_bind/... schon ein Symlink?


    -volker-

    - Frickelphone (XA2 Plus mit Sailfish)

    - Lumia 930 (Windows Mobile 10)

    2 Mal editiert, zuletzt von Volker S ()

  • Das von mir installierte 'My Data Transfer' ist wohl auch nicht der Weisheit letzter Schluss. Klar Android-Apps archiviert er natürlich eh nicht, aber SF-Apps wohl nur die, die er mag.


    Das erstellte Backuparchiv hat ja die Endung ".mydatatransfer". Da das ein tar-Ball ist, braucht man das nur in ".tar" umzubenennen und man sieht was er da archiviert hat. Da fehlt m.M ne ganze Menge an SF-Apps.

    Im Prinzip sichert er /home/nemo/.config und /home/nemo/.local/share (und da auch nicht alles)

    Von /usr/share hat er gar nichts.

    PS: Ich weiß aber jetzt auch nicht wo sich Apps sonst noch installieren. Vielleicht mach ich nochmal ein Backup mit dem Tool.


    -volker-

  • Ein Restore von einem Backup habe ich natürlich auch noch nicht mit dem Prog angewendet. Aber die Diskrepanz von diesem Prog zeigt sich eindeutig, wenn Du diesen Tarball mal aufmachst. Unter Linux muss man das ja noch nicht mal umbenennen.


    Ich zeige Dir hier mal die Baumstruktur von meinem Backup:

    mydatatransfer_01.jpg

    Die Userdirectories .config und .local liegen unter dem User 'nemo', wobei unter .config (wie der Name es schon vermuten lässt) Konfigurationsdateien der installierten Apps aufzufinden sind (.ini, .cfg usw.). der komplette Pfad lautet /home/nemo/.config/

    Unter .local/share liegen normalerweise die Apps (die eigentlichen Programme) welche der User nemo (also 'Du') installiert hat (/home/nemo/.local/.share/). Aber auch hier gibt es Defizite (schau Dir mal die Verzeichnisgrößen an). Beispielsweise die App 'storeman' hat sich da nur mit 8 Bytes verewigt. Auch hier habe ich arge Zweifel das sich 'storeman' damit wieder herstellen lässt.

    Der Rest des Backups ist ähnlich anderen Backups (Bilder, Dokumente usw.)


    Anhand des nachfolgendem Bildes wird dann nun die Diskrepanz ebenfalls deutlich. Im oberen Bild sucht man unter den installierten Apps die App 'Defender' vergebens, während unter

    .config

    mydatatransfer_02.jpg

    man die config-Datei vom Defender findet. Das ist in meinen Augen alles andere als ein sicheres Backup. Der Defender ist also irgendwo anders installiert (/usr/share/ oder usr/etc, irgendwo im root-Verzeichnis halt - was weiß ich schon).

    Auch werden alle anderen Apps, die ins root wandern hier nicht gebackuped (beispielsweise 'depecher' liegt auch teilweise im /usr/share/


    Ein vernünftiges Backup-Prog wäre wirklich mal nötig - so bleibt eigentlich nur die screenshots-Funktion übrig, oder halt händisch: ls /usr/share/applications/ > /path/to/softwarelist.txt

    und falls man Patches besitzt: ls /usr/share/patchmanager/patches > /path/to/patchlist.txt.


    -volker-

    - Frickelphone (XA2 Plus mit Sailfish)

    - Lumia 930 (Windows Mobile 10)

    Einmal editiert, zuletzt von Volker S ()

  • Für meine Server, Clients und Sailfish nutze ich Borg Backup.

    Damit bin ich bisher sehr gut und zuverlässig gefahren.

    Die bisherigen Rücksicherungen haben sehr gut funktioniert.


    Achtung: Windows kann, glaube ich, nicht mit Borg gesichert werden! ;)


    Firmenhandy (iFön) wird kein Backup gefahren.

    Kalender, Kontakte und Daten werden mit meiner Cloud gesynct, was hervorragend funktioniert.

    Firmenkontakte, Kalender und Mails sind -leider ^^- via Exchange Konto eingebunden, werden in der Firma gesichert.

    iCloud ist deaktiviert und wenn das Gerät mal zurückgesetzt werden muss installiere ich die handvoll Apps einfach wieder neu.

    Der Status der Apps wird dabei aber, glaube ich, in der Wolke von Apple gesichert.

    IT Security Engineer | Security Officer
    Fachinformatiker / Systemintegrator | GNU / Linux Admin


    Die Sprache der Menschen ist einzigartig aber nicht eindeutig.
    Das Verständnis des Gesagten hängt vom Wohlwollen des Gegenüber ab.

  • Leider nicht, habs nicht installiert bekommen.


    Bin hiernach vorgegangen (nachdem ich wget nachinstalliert hatte, curl müsste aber auch gehen). Da kommt man in eine Art Weiterleitungsschleife, welche nach 20 Versuchen abbricht.

    Dann habe ich mir die Datei borg-1.1.11-armv6 händisch von hier runtergeladen, ausführbar gemacht und gestartet. Hat er aber nicht gefressen.

    Habe die Datei auch mal unter den normalen 'Downloads' abgelegt und versucht zu starten. Will er nicht.


    Keine Ahnung warum es dazu eine Anleitung gibt, die nicht funzt (der Bug sitzt betimmt wieder vor dem Bildschirm :)


    Ich wollte damals noch nachschauen, ob ich von Linux (bei mir Mint) per SSH das Smartphone sichern kann. Also Borg auf den Desktop installieren und dann das Device sichern. Hab mich aber bis jetzt noch nicht drum gekümmert.


    -volker-

  • Nachtrag: Hat jetzt doch funktioniert (nach obiger Vorgehensweise). Kann aber nicht erklären was beim ersten mal geharkt hat.

    Da ich mit wget nicht weitergekommen bin, habe ich die Datei "borg-1.1.11-armv6" händisch in mein /nemo/Downloads/ - Verzeichnis kopiert (mittels einem Desktop-Linuxdateibrowser und einer ssh-Verbindung (USB) zu meinem XA2).

    Da es eine ausfürbare Datei ist (also das Prog selber und keine Installationsdatei ist) wollte ich diese Datei nicht in einem Downloadverzeichnis stehen lassen und habe sie mittels Shell/Terminal in das Verzeichnis /usr/local/bin/ reinkopiert (vorher noch auf 'borg' umbenannt).

    Nun einfach im Terminal borg eingeben und es kommt eine ellenlange Optionsangabe, wie man das Prog zu starten hat.

    Da /usr/local/bin anscheinend als Umgebungsvariable (Path) angelegt ist, braucht man demnächst im Terminal nur noch 'borg' angeben um es zu starten.


    Beim (Linux-)Desktop gibt es noch eine graphische Oberfläche (Vorta) dazu. Muss mal schauen, ob es das auch unter SF gibt.


    -volker-

  • Backup & Prune


    Nachdem das Borgbackup auf Euren Sony's ist, fehlt es natürlich noch an einem Backup-Script. Dazu bedarf es ein paar Vorbereitungen.

    Ich selber habe mir erst mal auf meiner SD-Karte (ssh auf einem Fremdrechner geht aber wohl auch) ein Verzeichnis eingerichtet (Borgbackup), und in meinem home-Direktory (/home/nemo) das Verzeichnis bin angelegt und das Backupscript und das Initialscript dort abgelegt.


    Ohne Initiierung, auch wenn man keine Verschlüsselung wählt, funktioniert kein BorgBackup. Nach der Initiierung kann das Script ja gelöscht werden, und nur das Backupscript wird weiter benutzt.


    borginit.sh

    Shell-Script
    1. #!/bin/sh
    2. borg init --encryption=repokey /media/sdcard/F043-C3A1/BorgBackup

    Mit der Option --encryption=repokey wird in dem darauf nachfolgenden Pfad (wo auch das eigentlich Backup hinkommt) eine verschlüsselte Datei angelegt, damit man nachher wieder drauf zugreifen kann. Nach der Ausführung von borginit.sh wird man gebeten das Passwort einzutragen.

    Diese Datei (config) bitte später mit dem Passwort sichern. Falls Ihr eins von den Beiden verliert. löscht einfach alles in dem Backupverzeichnis und legt ein neues Backup an.


    Nun kommen wir zum eigentlichen Backup-Script (bitte auch in /home/nemo/bin ablegen, da /home/nemo/bin in der Pathanweisung liegt).

    backup.sh (ich habe einfach das Standardscript genommen, und ein paar exclude-Anweisungen eingefügt (an die großen Jungs hier im Forum - wenn es geht bitte erweitern, dass das Backup kleiner wird :) )


    Nach ca. 13 Minuten erscheint dann folgendes auf dem Terminalfenster:

    Backup und Prune.jpg


    Pruning = damit werden verschieden Versionen der Backups gesichert / bzw. alte Backups herausgeschmissen. So genau weiß ich auch noch nicht wie man das überprüfen kann, da es beim BorgBackup keine doppelten Dateien gibt (selbst ein Einzelbackup wird diesbezüglich gekürzt)

    Ich habe mal aus Spaß 20 Minuten nach einem Backup ein zweites gestartet. Diese Backup war dann viel schneller fertig, aber er zeigte mit in der Historie die doppelte entpackte Größe beider Backups an - der wirkliche Speicherplatz hat sich aber so gut wie gar nicht verändert. Ergo: Doppelte Dateien werden nicht physisch abgespeichert (waren bestimmt noch ein paar Cachedateien hinzugekommen).

    Damit man was zu lesen hast, hier die englischsprachige Dokumentation und hier ein bisschen was Deutsches.


    Also nochmal der Aufruf an die Spezis hier: Was kann man noch alles excluden, dass das Archiv kleiner wird?

    Nochwas: ich habe das Script ohne root-Rechte ausgeführt, musste aber feststellen das bei manchen Dateien der Zugriff verweigert wurde und ich habe ja auch am Ende eine Warnung erhalten, nur wird mir das nicht im Klartext mitgeteilt. Muss man das Backup deshalb mit root ausführen?


    €dit:

    So, nachdem ich das Script etwas abgeändert habe und nun Zugriff auf eine Logdatei besitze, muss ich nochmal etwas Zeit investieren und auch mal einen anständigen Restore in ein Probeverzeichnis hinlegen. So ganz traue ich der Geschichte noch nicht.


    -volker-

    - Frickelphone (XA2 Plus mit Sailfish)

    - Lumia 930 (Windows Mobile 10)

    6 Mal editiert, zuletzt von Volker S ()

  • Backups - erstellen will man sie nicht, kommt der GAU hat man sie besser ;)


    Borg schoss mir in der Tat auch gleich nach dem ersten Post in den Kopf. Genial das es das auch unter SFOS gibt. Befasst habe ich mich bis auf "Was kann es und wie sieht das aus ( video ) noch nicht da es damals recht neu war und ich den BORG generell nicht traue - aber Widerstand scheint zwecklos zu sein.


    Seit ich Linux nutze ( 2006 ) habe ich viele Lösungen Probiert und bin dabei immer wieder bei den Basis gelandet : dd, sshfs, dmcrypt/LUKS Container. Mein Systeme habe ich dementsprechend Installiert ( rootfs erst 10 GB heute 20, boot und Home separat ). Die Dokumentation von Installationen dauert meist viel länger als die Installation selbst. Aus der Doku baue ich mir dann Install Scripte und habe somit eine Neuinstallation ohne viel Aufwand ( Doku und Script mal außen vor ) erledigt. Praktisch wenn man versch. Systeme ( Desktop Laptops NAS Server ) hat. VM Spiegelungen für Softwaretests sind auch schnell gemacht.


    Backups mache ich dann einfach mit dd if=/dev/rootfs of=/path/to/sshfs/mount/$hostname_$(date+ %F).img Damit habe ich ganz sicher nichts vergessen -frisst nur ein wenig viel Speicher aber 20 GB bei 20TB auf dem Server sind mir dann auch egal. War hat der hat *fg

    Userdaten Sichere ich ebenfalls per Script :



    Zum Code Review bin ich noch nicht gekommen, daher ist es etwas chaotisch. Vor dem Erstellen des Archivs kann man mit ncdu noch einmal auf die Ordnergrößen schauen und ggf. Datenmüll löschen.


    Eine Frage stellt sich aber bei jedem Backup: Systemübergreifend oder fürs gleiche System. Sichert man eine ganze Partition direkt mit dd erfolgt eine Wiederherstellung ganz einfach wieder mit dd. Ohne große Datei Auswahl, Prüfung oder sonst was. Funktioniert aber nur bei mehr oder weniger Identischen Systemen ( i386, amd46, ARM). Die Desktop Installationen klone ich einfach und passe Treiber dann händisch oder per Script an, geht recht schnell.


    Anders siehts bei Systemübergreifenden Backups aus. Da habe ich auch noch nicht DIE Lösung gefunden. Da müsste man dann auch erstma alles suchen und vorallem FINDEN was zu den User und Systemconfigs gehört. Auch hier würde ich wie nach dem o.g. Script vorgehen. Alles in einen Ordner kopieren, optional mit einem Analysetool wie ncdu oder was Grafischem den Ordner prüfen und dann in ein ggf passwortgeschütztes Archiv kopieren, bzw. mit Borgback dann inkrementell sichern.


    Mein Android Support auf meinem Xc hats mit dem letzten Update zerschossen ( bzw alien dalvik läuft aber Apps öffnen sich nicht, Wayland Problem ? ) Das hat z.Z. Priorität oder halt ein XA2. Denke es wird ein XA2 bevor ich das Xc reflashe, allein wegen der Backups der ganzen Einstellungen der Menüs etc. Wenn das XA2 da ist teste ich erstmal was passiert wenn ich das ganze /home/user/nemo/* einfach vom Xc auf XA2 kopiere. An mein Xc Produktiv Gerät wollte ich nicht eher etwas "kaputreparieren" bevor das XA2 als Produktiv Gerät einsatzfähig ist.


    Theoretisch müssten doch die Menüs Apps Einstellungen etc alle im Home liegen und zumindest die Systembasisconfiguration von Wayland ( Menus, Iconanordnungen, Icons etc ) unter $/USER/.config liegen ?

  • Da man mit SFOS 3.3 ENDLICH !!! mal mit aktueller Syntax arbeiten kann hab ich mir mal die Mühe gemacht und eine kleines Script geschrieben das die installierten Pakete nach Repositories auflistet. Es ist noch ausbaufähig aber für Version 1.0 reicht es schon ;)


    Script laden kopieren und ausführen :


    Code
    1. curl https://jollausers.de/wcf/attachment/457-sfos-lipra-v1-0-sh-txt --output sfos_lipra.sh
    2. devel-su mv sfos_lipra.sh /usr/local/bin
    3. sfos_lipra.sh



    Edit: curl download des Anhangs geht nicht, kp warum.