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

[BOotnoOB]

@Frank65 Bei der Datei bleibt die Sicherung hängen, weil TWRP sie nicht zum Archiv (Sicherungsdatei) auf der ext. Karte hinzufügen kann.

/data/misc/AUyr7V7xmfGQN7Xy,U+8FC/OBiWrP9KYIdB7A,eozLgGOLyv9J

TWRP will und kann sie zwar sichern, aber nicht ins Archiv kopieren. Hätte TWRP ein Problem mit der Datei selbst, würde der Fehler nicht erst beim Kopiervorgang entstehen.

Ganz unten ist der Fehler zu sehen. Hab noch die Sicherung von zwei, drei andere Dateien als Vorlauf mit reinkopiert. Dadurch wird der Sicherungsvorgang pro Datei deutlicher.

Spoiler: Auszug aus dem Log

I:addFile '/data/misc' including root: 1
==> set selinux context: ubject_r:system_data_file:s0
==> th_write(TAR="/external_sd/TWRP/BACKUPS/RF8N635DKLL/2020-08-20--18-49-23_QP1A190711020G980FXXS4ATGB/data.f2fs.win000")

Printing tar header:
name = "/data/misc/"
mode = "0041771"
uid = "0001750"
gid = "0023416"
size = "00000000000"
mtime = "13714515534"
chksum = ""
typeflag = '5'
linkname = ""
magic = ""
uname = "system"
gname = "misc"
devmajor = ""
devminor = ""
prefix = ""
padding = ""
gnu_longname = "[NULL]"
gnu_longlink = "[NULL]"
th_write(): using selinux_context ("ubject_r:system_data_file:s0")

Printing tar header:
name = "/data/misc/"
mode = "0041771"
uid = "0001750"
gid = "0023416"
size = "00000000000"
mtime = "13714515534"
chksum = "0012060"
typeflag = '5'
linkname = ""
magic = "ustar "
uname = "system"
gname = "misc"
devmajor = ""
devminor = ""
prefix = ""
padding = ""
gnu_longname = "[NULL]"
gnu_longlink = "[NULL]"
th_write(): returning 0
I:addFile '/data/misc/AUyr7V7xmfGQN7Xy,U+8FC' including root: 1
==> set selinux context: ubject_r:recovery_data_file:s0
==> th_write(TAR="/external_sd/TWRP/BACKUPS/RF8N635DKLL/2020-08-20--18-49-23_QP1A190711020G980FXXS4ATGB/data.f2fs.win000")

Printing tar header:
name = "/data/misc/AUyr7V7xmfGQN7Xy,U+8FC/"
mode = "0040770"
uid = "0001750"
gid = "0001757"
size = "00000000000"
mtime = "13714517016"
chksum = ""
typeflag = '5'
linkname = ""
magic = ""
uname = "system"
gname = "log"
devmajor = ""
devminor = ""
prefix = ""
padding = ""
gnu_longname = "[NULL]"
gnu_longlink = "[NULL]"
th_write(): using selinux_context ("ubject_r:recovery_data_file:s0")

Printing tar header:
name = "/data/misc/AUyr7V7xmfGQN7Xy,U+8FC/"
mode = "0040770"
uid = "0001750"
gid = "0001757"
size = "00000000000"
mtime = "13714517016"
chksum = "0015337"
typeflag = '5'
linkname = ""
magic = "ustar "
uname = "system"
gname = "log"
devmajor = ""
devminor = ""
prefix = ""
padding = ""
gnu_longname = "[NULL]"
gnu_longlink = "[NULL]"
th_write(): returning 0
I:addFile '/data/misc/AUyr7V7xmfGQN7Xy,U+8FC/OBiWrP9KYIdB7A,eozLgGOLyv9J' including root: 1
==> set selinux context: ubject_r:recovery_data_file:s0
==> th_write(TAR="/external_sd/TWRP/BACKUPS/RF8N635DKLL/2020-08-20--18-49-23_QP1A190711020G980FXXS4ATGB/data.f2fs.win000")

Printing tar header:
name = "/data/misc/AUyr7V7xmfGQN7Xy,U+8FC/OBiWrP9KYIdB7A,eozLgGOLyv9J"
mode = "0100440"
uid = "0001750"
gid = "0001757"
size = "00000000105"
mtime = "13717444135"
chksum = ""
typeflag = '0'
linkname = ""
magic = ""
uname = "system"
gname = "log"
devmajor = ""
devminor = ""
prefix = ""
padding = ""
gnu_longname = "[NULL]"
gnu_longlink = "[NULL]"
th_write(): using selinux_context ("ubject_r:recovery_data_file:s0")

Printing tar header:
name = "/data/misc/AUyr7V7xmfGQN7Xy,U+8FC/OBiWrP9KYIdB7A,eozLgGOLyv9J"
mode = "0100440"
uid = "0001750"
gid = "0001757"
size = "00000000105"
mtime = "13717444135"
chksum = "0021663"
typeflag = '0'
linkname = ""
magic = "ustar "
uname = "system"
gname = "log"
devmajor = ""
devminor = ""
prefix = ""
padding = ""
gnu_longname = "[NULL]"
gnu_longlink = "[NULL]"
th_write(): returning 0
I:Error adding file '/data/misc/AUyr7V7xmfGQN7Xy,U+8FC/OBiWrP9KYIdB7A,eozLgGOLyv9J' to '/external_sd/TWRP/BACKUPS/RF8N635DKLL/2020-08-20--18-49-23_QP1A190711020G980FXXS4ATGB/data.f2fs.win000'
Fehler beim Erstellen der Sicherung.
I:ERROR tarList for thread ID 0
Fehler beim Erstellen der Sicherung.
I:InfoManager saving '/external_sd/TWRP/BACKUPS/RF8N635DKLL/2020-08-20--18-49-23_QP1A190711020G980FXXS4ATGB/data.info'
Prozess createTarFork() endete mit FEHLER: 255
Sicherung fehlgeschlagen, bereinige Sicherungs-Verzeichnis

 

[Astronaut2018]

Sehe nicht ein, dass ich auf meinen Phone nicht das installieren oder löschen kann was ich will.

Das musst du absolut nicht!
Root ist heute nicht mehr nötig!
Du kannst alles installieren das funktioniert immer.
Du kannst auch alles deinstallieren mit ADB Befehlen.
Nur wenn du mit Apps arbeitest du zwingend Root brauchen das würde für mich Root rechtfertigen.
Root hat nicht nur Vorteile!
Das ist aber deine Entscheidung!

 

[Frank65]

@BOotnoOB
Vielen Dank für die Analyse. Habe die Datei im Root Explorer gesucht, aber leider nicht gefunden.

@Astronaut2018
Das mit dem ADB stimmt nicht ganz. Mit ADB kannst du die Apps deaktivieren und nicht deinstallieren. Ansonsten habe ich so einige Apps am laufen, die Root benötigen.

 

[Astronaut2018]

Mit ADB kannst du die Apps deaktivieren und nicht deinstallieren.

Für User 0 kann man die deinstallieren.
Zum Beispiel Chrome taucht in meinem System nicht mehr auf und auch nicht nach monatlichen Updates.

 

[Frank65]

@Astronaut2018
Durch das deaktivieren tauchen diese auch im System nicht mehr auf. Das Thema hatten wir schon einmal in einem anderen thread. Durch das Deaktivieren gaukelst du dem System eine Deinstallation vor. Diese sind aber in Wirklichkeit noch da.

 

[Astronaut2018]

@Frank65
Ja ich weiß, beim Werksreset sind die wieder da.
Aber die laufen nicht mehr im Hintergrund.
Und sind für mich nicht mehr sichtbar.
Beim deaktivieren in den Einstellungen /Apps sind die Apps sichtbar bei ADB nicht.

 

[BOotnoOB]

@Frank65 Dieser Buchstabensalat hinter /data/misc sieht genauso aus, wie bei einer verschlüsselten Datenpartition, die in TWRP geöffnet wird.

Nicht alle Verzeichnisse, die in TWRP existieren, müssen auch zwangsläufig im laufenden System zu finden sein. Wobei das eigentlich nur auf das root-Verzeichnis und Systempartitionen zutrifft. Ich würde in TWRP über den Dateiexplorer auch noch mal danach suchen.

 

[Frank65]

Da ich mein S20 gerootet habe, muss ich die Updates immer per Odin flashen. Jemand von euch ne Ahnung, ob man die Firmware auch per TWRP flashen kann? Ist ja auch ne zip Datei.
Danke und Gruß Frank

 

[BOotnoOB]

@Frank65 Eine .zip ist nicht direkt eine flashbare .zip, da gibt es einen großen Unterschied.
Die flashbare .zip installiert sich quasi selber, während die andere .zip der FW mithilfe eines Befehls geflasht (aufgespielt) werden muss.

 

[Frank65]

vielen Dank für die Info. Dann muss ich wohl über Odin flashen.....

 

[Frank65]

Für alle die den Fehler in TWRP beim sichern " ERROR: 255 on the data-partition. " bekommen, weil die Sicherung von "data" fehlschlägt.
[Pie/10/11] [System-as-root] Multidisabler: disables encryption, Vaultkeeper, auto-flash of stock recovery, proca, wsm, cass, etc.

 

[guti]

Klar, wenn du die dateiweise Verschlüsselung (FBE) deaktivierst, kann TWRP backuppen. Wenn die Dateien auf /data aber wie hier schon verschlüsselt sind, dürfte das nichts bringen, weil sie dadurch nicht entschlüsselt werden, sondern eben nur nach einen löschen von data nicht neu verschlüsselt wird.

Warum keine verschlüsselten Dateien gebackupt werden können durch TWRP ist mir allerdings nicht klar, wenn ich eine verschlüsselte zip speichere kann er die ja auch sichern.

 

[BOotnoOB]

Warum keine verschlüsselten Dateien gebackupt werden können durch TWRP ist mir allerdings nicht klar

Weil TWRP sie nicht lesen kann, das ist ja der Sinn der Verschlüsselung. Deine Daten wären ja sonst für jeden lesbar, z.B. wenn dein Handy geklaut wird. Entweder kann TWRP mithilfe deiner PIN/Muster/Passswort entschlüsseln oder die Verschlüsselung muss in der fstab deaktiviert werden.

Deine verschlüsselte ZIP ist ja als Datei an sich lesbar, nur der Inhalt nicht. Das ist der Unterschied.

 

[guti]

Wieso sollte TWRP sie nicht lesen können, was ist der Unterschied zu einer verschlüsselten Zip Datei? Ich kann mit TWRP ja durch die ganzen Verzeichnisse auf /data browsen, nur sind die Dateinamen eben verschlüsselt, und die Inhalte der Dateien natürlich auch. Dann kann TWRP aber von mir aus die Datei mit verschlüsseltem Namen und Inhalt backuppen, bei einem full restore müsste sie vom System ja wieder lesbar sein.

 

[BOotnoOB]

Wieso sollte TWRP sie nicht lesen können, was ist der Unterschied zu einer verschlüsselten Zip Datei?

Wenn du unbedingt die ganze Sache mit einer ZIP vergleichen willst, muss der Vergleich anders lauten:

In deinem Beispiel wäre /data die ZIP und der Inhalt von /data ist verschlüsselt - wie deine ZIP.
Jetzt sagst du, die ZIP kann aber von A nach B kopiert werden und auf B lässt sich die ZIP noch immer entschlüsseln und öffnen. Das ist auch richtig, weil die ZIP ein Datencontainer ist. Bei /data wäre es die gesamte Partition im ext4-Format. Ein Image davon würde deiner ZIP entsprechen. Aber so sichert TWRP die Partition /data nicht. TWRP sichert die einzelnen Dateien auf /data in einem TAR-Archiv.

Jetzt versuch mal den Inhalt deiner verschlüsselten ZIP ohne Key auszulesen und zu kopieren.

 

[guti]

Hm, so kannte ich es von full disk encryption, da konnte TWRP /data überhaupt nicht lesen. Bei FBE ist aber nicht ganz /data verschlüsselt, sondern nur die einzelnen Dateien. Deshalb kann ich ja auch durch die einzelnen Verzeichnisse browsen.

 

[BOotnoOB]

@guti Der Unterschied zw. FDE und FBE ist, dass bei der FBE die Metadaten/Dateiattribute trotzdem lesbar sind. Nur der Inhalt ist verschlüsselt.

Stell dir deine ZIP als Dateisystem vor, z.B. ext4. Demnach ist deine ZIP auf Grundlage der FDE verschlüsselt. Wäre sie mit FBE verschlüsselt, könntest du auch die Ordnerstruktur des Inhaltes erkennen.
Vielleicht ist das für dich eher "greifbar":

Das ext4-Dateisystem ist - wie viele andere Dateisysteme auch - so aufgebaut, dass in der Partitionstabelle ein Verweis zu den Speicheradressen der jeweiligen Dateien vorhanden ist. In diesem Fall sog. Inodes. Die Inodes beinhalten alle Metadaten der Datei und die genaue Speicheradresse, in dem Fall erster und letzter Speicherblock der Datei. Mithilfe dieser Infos kann dann der Inhalt erfasst und gelesen werden.

TWRP kann (bei der FBE) die Inodes lesen und die Datei lokalisieren, aber mit deren Inhalt aufgrund der Verschlüsselung nichts anfangen. Wäre es eine beschädigte Datei, bei der im Prinzip dasselbe passiert, käme eine entsprechende Fehlermeldung. Allerdings wird in unserem Fall darauf hingewiesen, das die Datei verschlüsselt ist und kein Fehler vorliegt. Somit zeigt TWRP alles an, außer den Inhalt. Und was nicht gekesen werden kann, kann auch nicht kopiert werden. Zumindest gilt das für ein Dateisystem.

Wäre jetzt kein Dateisystem vorhanden und TWRP, bzw. die Shell, würde keine Datei erwarten, könnte ganz simpel jedes Byte an den ausgewiesenen Speicherblöcken in Hex oder Binary Code kopiert werden. Der Inhalt bliebe erhalten, auch wenn nur verschlüsselt. Jetzt kommt aber das nächste Problem: Wie soll der Inhalt entschlüsselt werden? Dazu müssen noch alle anderen dazugehörigen Daten mit übernommen werden.

Diese Prozedur ist noch lange nicht zu Ende und für TWRP schon lange viel zu kompliziert. Also ist es, wie es ist und TWRP sichert keine verschlüsselten Dateien.

 

[Frank65]

Vielen Dank für die Erklärung, aber dies geht schon tief in die Inforamtik rein. Aber ist nicht auch so, dass Samsung bei dem S20 die Partition in eine Super Partition geändert hat. Ich denke nicht, dass hier die Verschlüsselung ein überwiegende Rolle spielt. Hier sollte es den Entwickern schwerer gemacht werden und natürlich auch das Rooten. Was sicherlich Samsung auch ein Dorn im Auge ist. Auch interessant in dem Zusammenhang ist, dass viele Custom Roms nur noch mit Lineage Recovery geflasht werden können. Deshalb habe ich mich von TWRP verabschiedet und habe Lineage Recovery geflasht. So komfortabel früher es sicherlich war das komplette System zu sichern, so sichere ich halt nun nur die Apps mit Alpha Backup. So hat man auch recht schnell alles wiederhergestellt.

 

[BOotnoOB]

Aber ist nicht auch so, dass Samsung bei dem S20 die Partition in eine Super Partition geändert hat.

Das hat nichts mit Samsung alleine zu tun. Seit Android 10 besteht die Möglichkeit (oder ist Pflicht?), sog. dynamische Partitionen zu verwenden. Dabei werden /system, /vendor, /product und je nach Hersteller auch weitere Systempartitionen zu einem super.img zusammengefasst. Dadurch können die Größen von /system usw. innerhalb dieses super.img frei festgelegt werden. Näheres ist im verlinkten Artikel gut erklärt.
Die Verschlüsselung betrifft nur /data und das ist keine Systempartition. Mit den dynamischen Partitionen hat /data daher absolut nichts zu tun.

Hier sollte es den Entwickern schwerer gemacht werden und natürlich auch das Rooten

Google interessiert sich nicht direkt dafür, ob dein Gerät Root-Zugriff hat oder der Bootloader offen ist. In deren Augen kannst du mit deinem Handy machen, was du willst. Pixel Factory Images
Das ist für mich persönlich die beste Anleitung eines Herstellers für die Entsperrung des Bootloaders inkl. Installation der Firmware, die ich bisher gesehen habe. Du hast Links zu allen Tools, ein umfangreiches Archiv aller Factory Images und den passenden OTA-Updates, schnelle Downloadserver (nicht selbstverständlich), detaillierte Step-by-Step Anleitung, ein Online Flash Tool (!), absolut keine Beschränkung beim Öffnen des Bootloaders (ein Befehl - Bootloder offen) etc.
Für Google sind drei Aspekte wichtig: Geld verdienen, Updatepolitik verbessern und die regulären Softwareentwickler. Dieser Kurs nimmt eben keine Rücksicht auf die Modding-Szene, das ist alles.

So hat man auch recht schnell alles wiederhergestellt.

TWRP ist aktuell sehr enttäuschend und offiziell kommt seit Monaten so gut wie kein neues Modell hinzu. Aber auch ohne TWRP ist es relativ einfach mithilfe von Shell-Befehlen eine brauchbare Sicherung zu erstellen. Das machen Linux-Nutzer schon seit Jahrzehnten so.

 

[guti]

TWRP kann (bei der FBE) die Inodes lesen und die Datei lokalisieren, aber mit deren Inhalt aufgrund der Verschlüsselung nichts anfangen. Wäre es eine beschädigte Datei, bei der im Prinzip dasselbe passiert, käme eine entsprechende Fehlermeldung. [...]

Wäre jetzt kein Dateisystem vorhanden und TWRP, bzw. die Shell, würde keine Datei erwarten, könnte ganz simpel jedes Byte an den ausgewiesenen Speicherblöcken in Hex oder Binary Code kopiert werden. Der Inhalt bliebe erhalten, auch wenn nur verschlüsselt. Jetzt kommt aber das nächste Problem: Wie soll der Inhalt entschlüsselt werden? Dazu müssen noch alle anderen dazugehörigen Daten mit übernommen werden.

Diese Prozedur ist noch lange nicht zu Ende und für TWRP schon lange viel zu kompliziert. Also ist es, wie es ist und TWRP sichert keine verschlüsselten Dateien.

Also erstmal vielen Dank, dass du dir die Zeit nimmst, so ausführlich zu antworten.
So ganz klar ist mir das ganze aber immer noch nicht: Bei FDE kennt TWRP weder Dateinamen noch die Position der Datei auf der Partition, und kann logischerweise kein dateiweises Backup erstellen. Bei FBE sind die (verschlüsselten) Dateinamen bekannt und werden angezeigt, die Position (Anfang/Ende) der Datei auf der Partition ist ebenfalls bekannt - wo ist dann der Unterschied zu einer verschlüsselten Zip-Datei? TWRP muss ja mit dem Inhalt der Datei nichts anfangen können, so lange der (verschlüsselt) gelesen werden kann, kann der doch auch 1:1 gebackupt werden. Bei der beschädigten Datei kommt eine Fehlermeldung, weil das Lesen vom Speicher fehlschlägt, aber was verhindert denn das Lesen der verschlüsselten Datei (in verschlüsselter Form)?

Um das Entschlüsseln muss sich TWRP ja nicht kümmern. Mir geht es nur darum, ein gesamtes Backup inkl. /data ziehen zu können, so dass ich alles wieder zurückspielen kann, wenn ich durch irgendwelche Änderungen mein System (oder /data) verhunze. Wenn ich alles 1:1 zurück spiele kann das System ja auch wieder booten und wieder die verschlüsselten Dateien lesen. Dass sie im Backup nicht lesbar und entschlüsselbar sind, ist dabei doch egal.