Backup-Strategie unter Android 10 bzw. LineageOS 17.1

[Tom4723]

Hi,

wie ich leidvoll erfahren habe, verschlüsselt Android 10 bzw. LineageOS 17.1 per Default die data Partition, so dass nach Installation von TWRP und LineageOS, ersteres kein Backup dieser Partition mehr durchführen kann. Daher stellt sich nun die Frage nach einer alternativen Backup-Strategie.

Gibt es da Lösungen?

Gruß
Tom

 

[Rubycon]

Hi,
einfach einen Vendor flashen, der die gezwungene Verschlüsselung der Datenpartition umgeht.

Grüße

Download file G960FXXU8DTC5_vendor.img (650,00 Mb) | Turbobit.net

 

[Tom4723]

Danke für die Rückmeldung. Ich bin in der Zwischenzeit auch zu dem Schluss gelangt, dass es sich wohl um ein "Ei" handelt, dass mir der Hersteller meines Galaxy S9 (also Samsung) über die letzte offizielle Firmware "gelegt" hat. Ich habe da Informationen gefunden, die nahelegen "no-verity-opt-encrypt" vor dem Flashen des CustomROM (also in meinem Fall LineageOS) zu flashen. Ich werde noch etwas dazu recherchieren und wenn ich keine Gründe dagegen finde, diesen Ansatz einmal ausprobieren. Wenn alles klappt, dann kann ich bei der Gelegenheit auch das Recovery meines tar-basierten Backups der Data-Partition testen. Ich habe dabei alles gesichert mit Ausnahme von:

• "data/media" - die Daten werde ich vorher noch auf meine externe SDCARD speichern
• "data/lineageos_updates" - die alten Versionen von LineageOS zu sichern kostet zu viel Platz
• "cache", *_cache", *-cache" - ich glaube, die verschiedenen Cache-Verzeichnisse muss man nicht sichern

Gibt es ggf. etwas, dass beim Recovery zu beachten ist? Ich denke dabei an Dateien, die man auf keinen Fall per Recovery überschreiben sollte.

 

[Tom4723]

Ich habe im Original "vendor.img" die "etc/fstab.samsungexynos9810" so modifiziert, dass aus dem Eintrag

/dev/block/platform/11120000.ufs/by-name/USERDATA       /data   ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,forceencrypt=footer,quota,reservedsize=128M,length=-20480

der Eintrag

/dev/block/platform/11120000.ufs/by-name/USERDATA       /data   ext4    noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,encryptable=footer,quota,reservedsize=128M,length=-20480

wurde, das modifizierte image in eine neue Datei geschrieben und diese per TWRP geflasht.

Danach (immer noch per TWRP) die data Partition formatiert und Cache und Dalvik Cache gewiped.

Danach (immer noch per TWRP) die externe SDCARD gemounted und mein tar archiv auf die leere data Partition eingespielt.

Danach schließlich einen System Boot durchgeführt.

Die erste gute Nachricht ist, dass LineageOS korrekt gebootet hat und 99.9% meiner Einstellungen auf Anhieb wieder vorhanden waren. Es waren nur ein paar kleinere Justagen erforderlich. Die zweite gute Nachricht ist, dass die data Partition nun nicht automatisch verschlüsselt wurde, so dass ich darauf auch per TWRP zugreifen konnte.

Die schlechte Nachricht ist allerdings, dass sobald ich per LineageOS die data Partition verschlüssele, TWRP auch nach Eingabe des korrekten Keys nicht mehr in der Lage ist, die data Partition zu lesen. Ich habe dies getestet mit twrp-3.2.3-0, twrp-3.3.1-1 und twrp-3.4.0-0.

Sofern ich nicht ein entscheidendes Detail übersehen habe (für entsprechende Hinweise bin ich dankbar), bleibt es also vorerst bei meinem tar-basierten Backup/Recovery und der Hoffnung, dass eine künftige TWRP-Version irgendwann auf die verschlüsselte data Partition zugreifen kann.

Gute Nacht
Tom

 

[BOotnoOB]

dass sobald ich per LineageOS die data Partition verschlüssele,

Wie verschlüsselst du denn /data? Über die Einstellungen?

Der Patch der fstab ist der gängige Weg, der auch von allen disabler.zips genutzt wird. Das war vollkommen richtig.

Beitrag automatisch zusammengefügt: 28.10.2020

Über die Einstellungen würde genau das gleiche passieren, was du mithilfe des Patches der fstab deaktiviert hast.
Bei TWRP gibt es nur zwei Möglichkeiten: Entweder kann es mit Verschlüsselung umgehen oder nicht. Einen Kompromiss gibt es nicht.

 

[Tom4723]

Danke für die Klarstellung.

Ich habe verschlüsselt über:

Einstellungen > Sicherheit > Verschlüsselung und Anmeldedaten > Smartphone verschlüsseln

LOS 17.1 hat danach etwas im Vordergrund gewerkelt (vorbereitet) und dann einen Reboot ausgelöst, um während des Boot-Vorganges begleitet von einem "Android-Männchen" die data-Partition zu verschlüsseln (so war ich das auch von LOS12.1 gewohnt). Nach der Verschlüsselung wurde ich nach einem Zugangsschlüssel gefragt, den ich eingegeben habe. Danach ist LOS 17.1 bis zum Anmeldebildschitm hochgefahren.

Über die Einstellungen würde genau das gleiche passieren, was du mithilfe des Patches der fstab deaktiviert hast.

Den Eindruck habe ich auch gewonnen, wenngleich ich die Hoffnung hatte, dass die nutzergetriggerte Verschlüsselung unter Angabe eines Zugangsschlüssels (im Gegensatz zur automatischen Verschlüsselung ohne nutzerdefinierten Zugangsschlüssel) TWRP in die Lage versetzen würde, auf die data-Partition zuzugreifen. Leider ist das nicht der Fall.

Da ich ungern auf die Verschlüsselung meiner Daten verzichten möchte, werde ich bei meiner Backup & Restore Strategie bleiben und weiter hoffen, dass eine zukünftige TWRP-Version irgendwann in der Lage ist, die verschlüsselte Partition nach Eingabe des korrekten Zugangsschlüssels zu lesen.

 

[BOotnoOB]

Da ich ungern auf die Verschlüsselung meiner Daten verzichten möchte, werde ich bei meiner Backup & Restore Strategie bleiben und weiter hoffen, dass eine zukünftige TWRP-Version irgendwann in der Lage ist, die verschlüsselte Partition nach Eingabe des korrekten Zugangsschlüssels zu lesen.

Mach dir da keine allzu großen Hoffnungen. Weder deine Stock Firmware wird sich dahingehend ändern, noch die TWRP-Version.

Wie genau funktioniert denn deine alternative Backup-Lösung?

 

[Tom4723]

Keine Sorge, ich bin schon genug ernüchtert von Googles Ansichten über Internet- und Smartphone-Nutzer.

Als Backup-Lösung habe ich ein kleines bash Shell-Script "dataBackup" geschrieben, das mit entsprechenden Rechten (root, 744) unter /data zu speichern ist und das über ein Terminal mit root Rechten per "data/dataBackup [-v]" aufgerufen wird. Es startet ein "tar" Kommando, welches die gesamte data-Partition mit Ausnahme einiger vordefinierter Ordner/Datei-Namensmuster in ein mit gzip komprimiertes und dem Datum des Backup beschriftetes tar Archiv auf einer externen SDCARD schreibt. Die ausgenommenen Namensmuster kann man leicht an die persönlichen Bedürfnisse anpassen. Falls Interesse besteht, könnte ich es vielleicht hier als Anhang posten?

 

[BOotnoOB]

@Tom4723 Falls du es nicht ohnehin schon nutzt, kann ich dir Termux empfehlen. Das ist um einiges vielseitiger als die Terminal-Apps.
Hatte mir auch mal so ein Script gebastelt, aber TWRP war mir zum Schluss doch lieber. In deinem Fall ist es natürlich eine gute Alternative.
Was einige auch nicht berücksichtigen, wenn sie die Verschlüsselung komplett deaktivieren ist, dass jeder Dritte via TWRP uneingeschränkten Zugang zu deinen Daten hat! Daher machst du es eigentlich genau richtig.
Pass nur auf bei Magisk Modulen. Ohne TWRP kann ein Bootloop aufgrund eines falschen Moduls nur mit einem Reset behoben werden.

 

[Tom4723]

@BOotnoOB Es hat ein Weilchen gedauert, aber letztens habe ich Termux (mit etwas Anschieben, weil in der Version ein Bug war) installiert. Das Terminal gefällt mir besser als das Default-Terminal von LOS 17.1, weil ich nun auch auf die Steuertasten zugreifen kann. Allerdings muß ich schon ein paar Verrenkungen auf mich nehmen, bis ich a) in (irgend)einer bash Shell, b) als root eingeloggt, c) mit einem Termux Terminal d) im Ordner "/" lande.

1. Termux starten
2. su eingeben (danach ist man zwar root aber "nur" in der /system/bin/sh und im falschen Verzeichnis)
3. /sdcard/.bashrc einrichten (nur einmalig versteht sich) und darin $HOME verbiegen nach "/" (eigentlich macht man so etwas nicht, aber ich will die Prozedur nicht nach jedem LOS Update wiederholen)
4. bash starten (dies ist dann übrigens nicht die bash von Termux, sondern die von LOS 17.1 unter /system/xbin/bash)

Der Tausch einer unverschlüsselten data Partition gegen ein komfortables Backup per TWRP ist mir zu riskant. Da bleibe ich dann lieber noch ein Weilchen bei meinem Backup-Script und vertraue darauf, das TWRP irgendwann auch den vollständigen Sprung nach Android10 schafft. Das Backup-Script läuft unterdessen recht gut. Ich habe bereits ein paar Mal ein Backup wieder eingespielt und mußte danach nur ein paar kleinere manuelle Justierungen vornehmen. Selbst wenn man ein Firmware-Update vornimmt, halten sich die manuellen Justierungen in Grenzen. Zusätzlich zum Backup ist es allerdings wichtig, die Kontakte auf die externe SDCARD zu exportieren, denn aus irgendeinem Grund werden die Kontakte nicht von meinem Script erfasst. Möglicherweise liegen sie in irgendeiner Cache-Datei oder einem Cache-Verzeichnis, die ich von meinem Backup ausgeschlossen habe.
Das Problem mit dem Boot Loop kenne ich zur genüge. Dort lande ich, wenn ich wieder einmal eine Original Firmware flashe. Vermutlich weil ich irgendwann einmal ein speziell debloatetes ROM auf Basis von Oreo installiert hatte, dieses danach aber nicht ordnungsgemäß wieder deinstalliert habe. Glücklicherweise beeindruckt dies LOS 17.1 (und auch LOS 18.1) nicht .

 

[BOotnoOB]

@Tom4723 Termux bringt seine eigene Umgebung mit, quasi schon eine Linux VM. Um Root zu erlangen und gleichzeitig nicht aus der Shell in Termux zu fliegen, musst du das Package tsu (und root-repo??) installieren. Damit hast du dann innerhalb von Termux Root-Zugriff, kannst dich aber auch ganz normal mit Root im gesamten Verzeichnis deines Handys bewegen.

Hab mich auch etwas intensiver mit der Art und Weise beschäftigt, wie TWRP die Datenpartition sichert. Leider haben sie eigene Funktionen implementiert und greifen nicht auf Standardbefehle zurück. Dadurch wird ein manueller Befehl etwas kompliziert im Aufbau, aber das Ergebnis ist 1:1 wie bei TWRP:

tar -cv --xattrs --exclude='media/*' -f PATH_BACKUP_FILE /data

Soll das ganze noch aufgeteilt werden, so wie es TWRP macht:

tar -cv --xattrs --exclude='media/*' -ML 1572864 --file=PATH_BACKUP_FILE.part1 [...] --file=PATH_BACKUP_FILE.partX /data

 

[Tom4723]

@BOotnoOB Habe tsu wie folgt installiert

% pkg install tsu

und dann aufgerufen per

% tsu

Es funktioniert soweit, setzt aber sein HOME directory auf "/data/data/com.termux/files/home/.suroot" anstatt "/". Besteht die Möglichkeit, das HOME Directory von root zu ändern, ohne das tsu-Script unter ../usr/bin/tsu zu modifizieren?

 

[BOotnoOB]

@Tom4723

HOME=/

Beitrag automatisch zusammengefügt: 28.01.2021

Eine Auflistung des kompletten Environments lässt du dir mit set anzeigen.

 

[Tom4723]

@BOotnoOB

Es funktioniert soweit, setzt aber sein HOME directory auf "/data/data/com.termux/files/home/.suroot" anstatt "/". Besteht die Möglichkeit, das HOME Directory von root zu ändern, ohne das tsu-Script unter ../usr/bin/tsu zu modifizieren?

OK, "tsu" muß sein HOME-Directory dort setzen, wo es Schreibrechte hat. Deshalb im Termux-Baum und nicht unter "/". Die Partition unter "/" ist (aus Sicherheitsgründen) readonly gemountet. Sinnvollerweise sucht die "bash" im HOME-Directory nach einer .bashrc. Dort habe ich meinen Wunsch-Prompt, ein paar Aliase und am Schluß den Wechsel "cd /" eingetragen. So lande ich nach Aufruf von "tsu" im root-Verzeichnis und kann auch schnell wieder zurück ins HOME-Directory.
Zur Archivierung per "tar": Ich schließe in meinem Skript mehr Unterverzeichnisse aus, als TWRP.

echo "data/media/*" >> ${EXFILE}
echo "data/lineageos_updates" >> ${EXFILE}
echo "data/magisk_backup_*" >> ${EXFILE}
echo "cache" >> ${EXFILE}
echo "*_cache" >> ${EXFILE}
echo "*-cache" >> ${EXFILE}

Und die --xattrs Option habe ich bislang nicht verwendet. Ich werde sie mir einmal genauer anschauen. Danke für den Tipp.

 

[BOotnoOB]

OK, "tsu" muß sein HOME-Directory dort setzen, wo es Schreibrechte hat

Bestimmt aber nur wegen der bash_history, denn sonst befindet sich nichts in ~/.suroot. Die normale Terminalapp hat nämlich keine History und dort ist für root HOME=/.

Mit der Option -xattrs bist du immer auf der sicheren Seite bei einem Backup von /data. In erster Linie wollte ich die Sicherungen auf die gleiche Art erzeugen, wie sie auch von TWRP erzeugt werden.

 

[Tom4723]

Habe gerade herausgefunden, dass ich ein 100%-iges Recovery hinbekomme, wenn ich die zuvor genannten Cache Excludes entferne und die entsprechenden Cache-Ordner oder -Dateien mitsichere. Das Backup wird dadurch zwar 120MB größer, aber dafür spare ich enorm Zeit beim Wiederherstellen des vorherigen Stands.

 

[BOotnoOB]

Zur Archivierung per "tar": Ich schließe in meinem Skript mehr Unterverzeichnisse aus, als TWRP.

echo "data/media/*" >> ${EXFILE}
echo "data/lineageos_updates" >> ${EXFILE}
echo "data/magisk_backup_*" >> ${EXFILE}
[B][COLOR=rgb(209, 72, 65)]echo "cache" >> ${EXFILE}[/COLOR][/B]
[COLOR=rgb(209, 72, 65)][B]echo "*_cache" >> ${EXFILE}[/B][/COLOR]
[B][COLOR=rgb(209, 72, 65)]echo "*-cache" >> ${EXFILE}[/COLOR][/B]

Und die --xattrs Option habe ich bislang nicht verwendet. Ich werde sie mir einmal genauer anschauen. Danke für den Tipp.

Auf welchen Cache, bzw. welche Pfade beziehen sich "cache", "*_cache" und "*-cache"? Du hast den internen Speicher als "/data/media" angegeben, also wird sich "cache" auf die Partition /cache beziehen, oder?

 

[Tom4723]

Vermutlich ist es am einfachsten, das ganze Skript anzugeben. Ggf. muß es leicht angepaßt werden:

#!/system/bin/sh

# =============================================================================
# dataBackup - backup of encrypted /data partition
#
# Author: Tom4723@android-hilfe.de (2021-02-14)
#
# Installation
# - become root
# - save "dataBackup" under "/data"
# - set permissions to "744" (-rwxr--r--)
# Backup
# - insert and mount an external sdcard
# - open a terminal (either on Android or remote per "adb shell")
# - become root (su)
# - run "data/dataBackup" (use option -v to run in verbose mode)
# Recovery
# - insert and mount the external sdcard with the backup to be recovered
# - open a terminal and become root (su)
# - ensure to have root permissions (whoami)
# - ensure the working directory is "/"
# - run "tar xzvf <fully qualified backup file>"
# - exit the terminal and reboot the system
# =============================================================================

# ----------------------------------------------------------------- definitions

CWD=`pwd`
TAROPT="cz"
EXFILE="/mnt/tarExclude"
BACKUP=`date +"backup_%Y-%m-%d_%H%M%S.tar.gz"`

# ----------------------------------------------------------------------- usage

usage() {
    echo "usage: dataBackup [-v]"
    exit 1
}

# ---------------------------------------------------------- parse command line

while getopts "v" opt; do
    case "${opt}" in
         v) TAROPT="czv";;
         *) usage;;
    esac
done

shift $((OPTIND-1))

if [ $? != 0 ] ; then
    usage
fi

# --------------------------------------------------------- check for su status

WHOAMI=`whoami`

if [ ${WHOAMI} != "root" ] ; then
    echo "Error: No root permission"
    exit 1
fi

# ------------------------------------------------------------ check for sdcard

cd /
SDCARD=`mount | grep "/mnt/media_rw.*/storage" | cut -f3 -d" "`

if [ -z ${SDCARD} ] ; then
    echo "Error: No external sdcard found"
    exit 1
fi

if [ ! -d ${SDCARD}/Backup ] ; then
    mkdir ${SDCARD}/Backup
fi

# --------------------------------------------------------- set up exclude file

if [ -f ${EXFILE} ] ; then
    rm ${EXFILE}
fi

touch ${EXFILE}
echo "data/media/0/Alarms" >> ${EXFILE}
echo "data/media/0/DCIM" >> ${EXFILE}
echo "data/media/0/Download" >> ${EXFILE}
echo "data/media/0/Movies" >> ${EXFILE}
echo "data/media/0/Music" >> ${EXFILE}
echo "data/media/0/Notifications" >> ${EXFILE}
echo "data/media/0/Pictures" >> ${EXFILE}
echo "data/media/0/Podcasts" >> ${EXFILE}
echo "data/media/0/Ringtones" >> ${EXFILE}
echo "data/lineageos_updates" >> ${EXFILE}
# echo "data/magisk_backup_*" >> ${EXFILE}
# echo "cache" >> ${EXFILE}
# echo "*_cache" >> ${EXFILE}
# echo "*-cache" >> ${EXFILE}

# --------------------------------------------------------------- create backup

tar ${TAROPT} -X ${EXFILE} -f ${SDCARD}/Backup/${BACKUP} /data
echo "${SDCARD}/Backup:"
ls -l ${SDCARD}/Backup

# ------------------------------------------------------- clean up exclude file

if [ -f ${EXFILE} ] ; then
    rm ${EXFILE}
fi

cd ${CWD}
exit 0