TWRP-Backup - System richtig sichern und zurückspielen?

[BOotnoOB]

@guti TWRP kann die verschlüsselten Dateien nicht lesen und somit nicht öffnen und auch nicht sichern. Die ZIP kann gelesen werden und deren Inhalt spielt keine Rolle. Um die ZIP zu kopieren, muss der Inhalt der ZIP nicht lesbar sein. Deswegen hatte ich ja das Beispiel mit der Partition erwähnt.

Wenn /data verschlüsselt ist, kann ich den Inhalt zwar nicht lesen, aber ich kann die ganze Partition trotzdem als Image sichern und woanders mounten und entschlüsseln (simpel ausgedrückt). Dasselbe gilt für die verschlüsselte ZIP. Ich kann die ganze ZIP auch kopieren und woanderes entschlüsseln.

Beiträge automatisch zusammengeführt: 10.04.2021

Du musst die ZIP mit einer ganzen Partition gleichsetzen.

 

[guti]

Ok, d.h. Beginn und Ende der Dateien sind TWRP doch nicht bekannt, sondern nur die Verzeichnisstruktur.

Einzige Möglichkeit zum Backup wäre also die ganze Partition als Image zu sichern, und das kann kein Recovery.

 

[BOotnoOB]

@guti Doch, TWRP ist Beginn und Ende der Datei bekannt, aber sie kann nicht gelesen werden. Wie eine beschädigte Datei. Ein Dateiformat wird immer mithilfe der Dateisignatur erkannt (Header Magic). Nur ist diese verschlüsselt und kann nicht gelesen werden. In einer verschlüsselten ZIP ist das egal, weil die ZIP selber alle Infos enthält, die für die Entschlüsselung wichtig sind.

Einzige Möglichkeit zum Backup wäre also die ganze Partition als Image zu sichern, und das kann kein Recovery.

Na klar geht das, halt nur manuell über die Eingabe im Terminal mit dem Befehl "dd". Das ist ein ganz normaler Linux-Befehl, den TWRP auch benutzt, um z.B. /system als Image zu sichern. Nur ein Image von /data mit einer Größe von 110GB (oder wie groß der interne Speicher eben ist) zu erstellen, macht einfach keinen Sinn. Daher sichert TWRP nur die einzelnen Dateien.

 

[guti]

Na klar geht das, halt nur manuell über die Eingabe im Terminal mit dem Befehl "dd". Das ist ein ganz normaler Linux-Befehl, den TWRP auch benutzt, um z.B. /system als Image zu sichern. Nur ein Image von /data mit einer Größe von 110GB (oder wie groß der interne Speicher eben ist) zu erstellen, macht einfach keinen Sinn. Daher sichert TWRP nur die einzelnen Dateien.

Naja, eine 128 oder 200 GB SD-Karte ist nun nicht mehr so teuer, damit könnte man dann doch ein Komplettbackup machen (und ggf. auf Festplatte komprimieren, wenn die Parition zur Hälfte leer ist lässt sich das auch ganz gut komprimieren, es sind ja nur die Dateien verschlüsselt). Die Frage ist nur, ob, wenn man alle anderen Partitionen mit TWRP sichert und /data per dd, man das bei dieser Super-Partition auch wieder problemlos restored bekommt oder ob da etwas durcheinandergeht.

 

[BOotnoOB]

@guti Dynamische Partitionen (super.img) beziehen sich nur auf bestimmte Systempartitionen und nicht auf /data.
Klar gibt es günstige SD-Karten in der Größenordnung. Aber mit TWRP über den Befehl "dd" ein Image von dieser Größe auf SD zu kopieren, wird einige Zeit in Anspruch nehmen. Ich gehe von Stunden aus.

 

[guti]

Naja, besser ein paar Stunden warten als selber manuell bei einem Verlust von /data alles neu einrichten Oder hättest du einen anderen Tipp, wie man ein FBE-verschlüsseltes /data backupt?

 

[BOotnoOB]

Oder hättest du einen anderen Tipp, wie man ein FBE-verschlüsseltes /data backupt?

Sogar zwei Tipps:

1. Deine Datenpartition gar nicht erst verschlüsseln. Dazu muss sie aber komplett gelöscht werden. Meistens macht man solche Dinge bei der Entsperrung des Bootloaders und dieser Vorgang löscht ohnehin alles. Somit kein wirklicher Verlust und kompliziert ist es auch nicht.
Einziger Nachteil: Extrem unsicher, da deine Daten für jeden zugänglich sind, der dein Handy in die Finger bekommt. Die Displaysperre bringt in diesem Fall rein gar nichts, denn sie kann über TWRP ganz leicht gelöscht werden.

2. Deine Daten im laufenden Betrieb sichern, da sie dort unverschlüsselt vorliegen. In der Gesamtheit wirst du damit erfolgreich sein. Aber immer mit der Gefahr verbunden, dass die eine oder andere Datei nicht sauber gesichert werden kann, weil sie genau zu diesem Zeitpunkt vielleicht neu beschrieben wird. Darum sichert man ja normalerweise /data auch außerhalb von /data, nämlich in der Recovery.
Das Ganze lässt sich mit einem simplen TAR-Befehl + Optionen lösen. Das Ergebnis ist 1:1 wie in TWRP. Nur die Qualität ist nicht vergleichbar.

 

[guti]

@guti Dynamische Partitionen (super.img) beziehen sich nur auf bestimmte Systempartitionen und nicht auf /data.
Klar gibt es günstige SD-Karten in der Größenordnung. Aber mit TWRP über den Befehl "dd" ein Image von dieser Größe auf SD zu kopieren, wird einige Zeit in Anspruch nehmen. Ich gehe von Stunden aus.

Habe das gestern durchgeführt: Bei 108 GB /data Partition hat es 11:30 Stunden gedauert.

Jetzt bräuchte ich nur ein zweites Telefon, um ein Restore zu testen

 

[Lohenstein]

Also ich habe alles was im TWRP angeboten wird auf eine SSD gesichert. Allein mir fehlt ein bisschen der Glaube dass das zurückspielen funktioniert!

Ich habe noch ein weiteres, Interessantes Problem:
TWRP (Version 3.5.2_10-7-surya ) kann offenbar nicht wirklich auf dem Handy gespeichert werden.
Ich muss es immer mit dem Befehl adb:\fastboot boot twrp.img aufspielen.

C:\adb>fastboot boot twrp.img
< waiting for device >
downloading 'boot.img'...
OKAY [ 3.249s]
booting...
OKAY [ 5.086s]
finished. total time: 8.335s

Sobald ich zurück in das System boote ist das TWRP weg obwohl im Handy-Startmenü Recovery angeboten wird. Da springt das Handy aber ins Menü
Reboot
Wipe Data
Connect with MIAssistant
Safe Mode

 

[guti]

Ich habe noch ein weiteres, Interessantes Problem:
TWRP (Version 3.5.2_10-7-surya ) kann offenbar nicht wirklich auf dem Handy gespeichert werden.

Stock Firmware entfernt standardmäßig das TWRP-Recovery und reinstalliert das Stock Recovery, wenn man es nicht unterbindet. Das kann man zum Beispiel unterbinden, indem man in TWRP den multi_disabler flasht, den gibt es hier:
[Pie/10/11] [System-as-root] Multidisabler: disables encryption, Vaultkeeper, auto-flash of stock recovery, proca, wsm, cass, etc.

Der unterbundet auch, dass /data verschlüsselt wird. Wenn man die Verschlüsselung haben will, damit bei verlorenem/gestohlenen Handy nicht jeder an deine Daten kommt, musst du vorher erst einmal normal booten (dabei geht TWRP natürlich verloren), dann verschlüsselt er in der Regel automatisch, dann TWRP erneut flashen und dann nach TWRP booten und dort den multidisabler flashen. Dann bleibt TWRP auch.

Beiträge automatisch zusammengeführt: 13.12.2021

Sogar zwei Tipps:

1. Deine Datenpartition gar nicht erst verschlüsseln. Dazu muss sie aber komplett gelöscht werden. Meistens macht man solche Dinge bei der Entsperrung des Bootloaders und dieser Vorgang löscht ohnehin alles. Somit kein wirklicher Verlust und kompliziert ist es auch nicht.
Einziger Nachteil: Extrem unsicher, da deine Daten für jeden zugänglich sind, der dein Handy in die Finger bekommt. Die Displaysperre bringt in diesem Fall rein gar nichts, denn sie kann über TWRP ganz leicht gelöscht werden.

2. Deine Daten im laufenden Betrieb sichern, da sie dort unverschlüsselt vorliegen. In der Gesamtheit wirst du damit erfolgreich sein. Aber immer mit der Gefahr verbunden, dass die eine oder andere Datei nicht sauber gesichert werden kann, weil sie genau zu diesem Zeitpunkt vielleicht neu beschrieben wird. Darum sichert man ja normalerweise /data auch außerhalb von /data, nämlich in der Recovery.
Das Ganze lässt sich mit einem simplen TAR-Befehl + Optionen lösen. Das Ergebnis ist 1:1 wie in TWRP. Nur die Qualität ist nicht vergleichbar.

Da die Optionen beide nicht so toll sind (unverschlüsselt kommt nicht in Frage, und Backup im laufenden Betrieb mit Titanium ist ja nicht mehr, was es mal war, weil man danach doch ne Menge händisch wieder anpassen muss), habe ich mit dd die komplette verschlüsselte Datenpartition gebackupt, obwohl es über 11 Stunden gedauert hat.

Interessanterweise hat mein Firmware-Update (Galaxy S20 5G, DUC7 auf DUJ5) tatsächlich nicht funktioniert wie gedacht: Danach konnte er die nicht mehr booten, blieb lange beim Samsung-Logo hängen und dann bootloop, als könne er die verschlüsselte /data Partition nicht lesen. Ein Formatieren der Partition reicht und er konnte die neue Firmware booten, aber meine Daten waren weg.
Restore von /data per dd führte dazu, dass er wieder nicht booten konnte wie vorher. Selbst ein Restore aller anderern Partitionen per TWRP führte zu einem Bootloop noch vor dem Samsung-Logo, als wäre ein Downgrade der FW über TWRP-Restore so nicht möglich.

Weiß jemand, wo denn bei Samsung überhaupt die Schlüssel für die verschlüsselte /data Partition liegen? Bei einem vorherigen Update von DUB.. auf DUC7 funktionierte nämlich alles und meine Daten in der verschlüsselten /data Partition blieben erhalten.

 

[chrs267]

Weiß jemand, wo denn bei Samsung überhaupt die Schlüssel für die verschlüsselte /data Partition liegen?

Ja, auf /data.

als wäre ein Downgrade der FW über TWRP-Restore so nicht möglich.

Ist es auch nicht und davon wird auch abgeraten. Ein TWRP Backup hat nämlich nichts mit deiner kompletten Firmware zu tun. Die ist viel umfangreicher.

habe ich mit dd die komplette verschlüsselte Datenpartition gebackupt, obwohl es über 11 Stunden gedauert hat.

Genau aus diesem Grund sichert TWRP alle Dateien auf /data einzeln in einem Archiv.

 

[guti]

Genau aus diesem Grund sichert TWRP alle Dateien auf /data einzeln in einem Archiv.

Außer bei verschlüsselten /data-Partitionen, da sichert TWRP nämlich gar nichts (außer man macht es manuell wie ich mit dd).

Wenn die Keys auf /data liegen und ich /data mit dd zurückspiele, müsste ich doch wieder mein altes System booten können. Geht nur leider nicht, komme in einen Bootloop.

 

[chrs267]

Wenn die Keys auf /data liegen und ich /data mit dd zurückspiele, müsste ich doch wieder mein altes System booten können. Geht nur leider nicht, komme in einen Bootloop.

Warum sollte es denn ausschließlich nur wegen der Verschlüsselung zu einem Bootloop kommen?? Es gibt unendlich viele Gründe dafür.

 

[guti]

Guter Punkt; nachdem ich unter verschiedenen anderen Szenarien, z.B. mit der aktuellen Firmware nach Flashen von multidisabler bei (neu) verschlüsselter Datenpartition ebenfalls Bootloops hatte, bin ich das Ganze nochmal neu angegangen: Aktuelle Firmware neu geflasht, /data verschlüsseln lassen, TWRP geflasht, dort Magisk geflasht. Damit hatte ich ein funktionierendes, gerootetes System mit verschlüsselter Datenpartition. Daraufhin habe ich per dd wieder mein Backup von /data in TWRP zurückgespielt und hatte sogar etwas Hoffnung, dass er damit booten könnte.
Leider nein, es ist noch nicht mal ein richtiger Bootloop: Nach dem Initial-Screen nach Einschalten kommt noch nicht mal der Boot-Screen mit ausschließlich dem Samsung Logo, er fängt sozusagen gar nicht richtig an zu booten, sondern resettet sich davor, kommt wieder zum Initial-Screen und lädt dann das Recovery.

Daher meine Vermutung, dass er auf /data gar nicht zugreifen kann, bzw. das Booten wegen der Verschlüsselung nicht funktioniert.

 

[chrs267]

@guti Kann sein, kann aber auch nicht sein. Nur ändern kannst du es so oder so nicht. Angenommen, es liegt an der Verschlüsselung. Was willst du jetzt machen?
Du hast ein komplettes Backup deiner Datenpartition, das mehrere Stunden erstellt werden musste, riesengroß ist und du kannst nicht darauf zugreifen oder es wiederherstellen. Somit ist es völlig nutzlos und die Daten sind verloren.

 

[guti]

Ich wüsste dann wenigstens, was die Ursache ist, damit das nicht nochmal passiert.

 

[chrs267]

@guti Willst du genau wissen, was den Bootloop verursacht, brauchst du entsprechende Logs. Das blöde an solchen Logs ist, sie werden mit jedem Reboot zurückgesetzt. Selbst wenn du sie vor jedem Reboot durch ein Script auslesen und sichern könntest, um sie später anzusehen, wo willst du sie denn speichern??
Zu 95% kann man allgemein einen Bootloop erklären, weil eine spezielle Änderung vorgenommen wurde. Aber in deinem Fall sind die möglichen Ursachen nicht mehr überschaubar. Nochmal meine Frage: Sollte es an der Verschlüsselung liegen, was willst du daran ändern? Zukünftig deine Datenpartition nicht mehr verschlüsseln?

 

[nixgibts]

ich stehe vor dem gleichen Problem und muss hier einhaken.
Bei mir geht es um ein Lenovo Tab TB-X505F mit einem StockRom mit Android 10.

- Es wurde viel darüber diskutiert dass es eine FileBasedEncryption gibt und eine FullDiscEncryption. Jetzt stellt sich mir die simple Frage, wie sehe ich welche Form der Verschlüsselung es bei userdata ist?
- Es wurde gesagt dass TWRP nicht sichern kann wenn eine FDE vorhanden ist. Ist das aktuell immer noch so, und wie drückt sich das beim Backup-Versuch aus? Wird mir keine Data-Partition angezeit? Gibt es einen Fehler wenn TWRP es versucht und nicht zugreifen kann?
- ist das auch heute noch so dass TWRP bei verschiedenen Partitionen unterschiedlich sichert - also bestimmte Partitionen als Image, andere Partitionen
- ich habe das Gefühl dass eure Diskussion damit geendet hat mit der Erkenntnis dass man mit TWRP keine 1:1-Sicherung machen kann solange userdata verschlüsselt ist. Da frage ich mich welchen Sinn TWRP dann überhaupt noch hat?
Ich vermute mal dass das Patchen von boot für magisk nicht zwingend auf dem Gerät selbst erfolgen muss, sondern auch auf einer anderen Maschine erfolgen kann. Die gepatchte boot wird ohnehin via fastboot eingespielt.

 

[Frank65]

@nixgibts
Also ich habe immer eine Fehlermeldung im TWRP bekommen, dass data nicht gesichert werden kann. Habe es jetzt auch lange nicht mehr getestet, weil ich jetzt meine Backups mit Alpha Backup und Neo Backup mache.

 

[nixgibts]

Inzwischen bin ich auch soweit dass ich meine dass man sein Device mind. mit 2 Wegen sichern muss - mit TWRP und einem Backup-Tool.
Das TWRP-Backup dient wohl nur zum Restore auf dem gleichen Gerät, allerhöchstens noch einem anderen Gerät vom identischen Modell.
Wenn man seine Apps und Daten allerdings auf ein anderes Gerätemodell umziehen will, oder auch nur auf eine andere Android-Version, dann kommt man mit einem TWRP-Backup wohl nicht sehr weit. Sind wir mal ehrlich, wer kauft sich ein bestimmtes Gerät zweimal oder mehrfach.

@nixgibts
Backups mit Alpha Backup und Neo Backup

ok, dieses Alpha Backup schaue ich mir nicht mehr an. Da wurde seit 2021 nichts mehr gemacht und die Herstellerwebseite ist down. Sprich die App ist tot.
Sonst ergeht es mir wie bei Titanium Backup, bei dem ich die Vollversion gekauft habe und danach erst bemerkt habe dass das Tool bereits seit 2019 nicht mehr weiterentwickelt wird.

Ich hab mir mal "Swift Backup" zugelegt. Kennst du das zufällig auch?
Abgesehen davon ob die App Freeware ist oder kostenpflichtig, und abgesehen davon ob die auf irgendwelche Cloudspeicher direkt zugreifen kann, wo liegen denn die Unterschiede in den verschiedenen Apps?

alle versprechen:
- backup individual apps and their data.
- Scheduling
- Backups von mehreren Versionen einer App

Die Unterschiede müssen woanders liegen. Bei diesem Swift Backup wird z.B. explizit erwähnt dass es den Google-Authenticator nicht sichern kann.
Wie schaut es aus mit gespeicherten Wifi-Daten, mit dem Android-Zertifikate-speicher, Biometrischen Merkmalen, usw.?