datenritter blog

Wie ich schrieb, habe ich mein Smartphone zerschossen, als ich gerade meine Daten sichern wollte. So richtig. So, dass Daten und Einstellungen verloren schienen. PANIK!

In solchen Momenten hilft es, Ruhe zu bewahren. Die Daten sind nicht weg, man kommt nur nicht ran. Also tut man erst mal nichts, bis man weiß, was zu tun ist. Bei android-hilfe.de habe ich sogar jemanden gefunden, der sein Smartphone deswegen seit einem Jahr im Schrank liegen hat.

Das Problem ist, dass man nicht einfach jede beliebige Firmware neu flashen kann. Der Bootloader des Telefons nimmt nur signierte Dateien mit der Original-Firmware (Stock-Firmware) des Herstellers an. Diese würde einen vielleicht schon an die Daten lassen, zumindest aber die Installation eines Rettungssystems (Recovery) erlauben, startet jedoch nicht, wenn man nicht, wie in den einschlägigen Smartphone-Foren in vielen redundanten Threads und "How-Tos" mit großen bunten Buchstaben nachzulesen, einen "Factory-Reset" oder "Wipe" vornimmt. Was bedeutet, die persönlichen Daten vom internen Speicher zu tilgen.



Ohne ein Rettungssystem saß man bislang in der Zwickmühle. Bislang. "HowTo: Daten vom zerflashten ... »

Interessant:

Nebenbei bemerkt überleben Speicherkarten, sofern sie hermetisch dicht sind (einige SD-Typen, xD, Micro-SD), durchaus auch eine Vollwäsche bei 60°, wie wir bereits (unfreiwillig) testen konnten. Problematisch sind dagegen Kartentypen mit unvollständig verklebtem Gehäuse oder konstruktiv undichten Kontakten (CompactFlash).

Quelle: Heise-Meldung.

Es gibt also Hoffnung für die Urlaubsfotos, auch wenn diese am Grund des Sees liegen. Andererseist: Mal schnell das Kärtchen ins Wasser werfen, um Beweise zu vernichten ist auch nicht drin.

Wegen eines Fehlers beim Umkopieren eines großen Datenbestands sind mir die Änderungszeitstempel (modification time, mtime) abhanden gekommen. Ein weiterer guter Grund, ein Backup zu haben!

Um die Zeitstempel wiederherzustellen, ohne die Dateien selbst zu überschreiben, habe ich aus dem Backup eine Liste erzeugt, in der Dateipfade und Zeiten getrennt durch " #+# " gespeichert werden. Das geht z.B. mit stat, und zwar so:

#!/bin/sh

ifs_backup="$IFS"
TARGETDIR=/actual/place

find . | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
MODTIME=`stat -c %y "${DIRFILE}"|sed -s "s/\..*//"`
DIRFILE2="${TARGETDIR}"`echo -n "${DIRFILE}"|sed -s "s/^.//"`
echo "${DIRFILE2} #+# ${MODTIME}">> dirfilelist.txt
done


Die Einträge in dirfilelist.txt sehen dann etwa so aus:

/home/adorno/test/script.sh #+# 2009-06-06 15:23:00


Das folgende Script liest diese gespeicherten Daten und ändert die Dateien auf dem Zielsystem:

#!/bin/sh

ifs_backup="$IFS"

while true; do
COUNT=0
cat dirfilelist.txt | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
DIRFILE2=`echo "${DIRFILE}"|sed -s "s/\ #+#\ .*//"`
NEWMODTIME=`echo "${DIRFILE}"|sed -s "s/.*\ #+#\ //"`
if [ -e "${DIRFILE2}" ]; then
MODTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
touch -cm -d "${NEWMODTIME}" "${DIRFILE2}"
NEWTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
echo "${DIRFILE2} has modification time ${MODTIME}, changed to ${NEWMODTIME}. Result: ${NEWTIME}" >> mtimeset.log
COUNT=$((COUNT + 1))
else
echo ${DIRFILE2}" does not exist!" >> mtimeset_error.log
fi
if [ ${COUNT} -gt 10000 ]; then
echo "Deleting 10000 lines from dirfilelist.txt."
sed '10001,$w dirfilelist2.txt' dirfilelist.txt >/dev/null
mv dirfilelist2.txt dirfilelist.txt
break;
fi
done
done


Die äußere Schleife bewirkt, dass die Liste gleich um die abgearbeiteten Einträge (evtl. abzüglich einer Zeile zu wenig) bereinigt wird, verhindert aber, dass das Script terminiert. Man kann es also auch mal abbrechen, muss dafür aber die Logfiles im Auge behalten.

Die Scripte sind nicht unbedingt elegant, und natürlich gibt es viel Raum für Verbesserungen. Vor allem an der Geschwindigkeit lässt sich sicher noch etwas machen, wenn man z.B. Aufrufe von stat einspart.

Wie dem auch sei: Have a backup!

Die letzten zwei Stunden lief Chaosradio 144 "Datenträger, Datenverlust und Datenrettung — Vom magnetischen Flußwechsel zum Dokument".

Es ging um Festplattenfehler ebenso wie Anwenderfehler, um die Methoden zur Rettung der Daten, um RAID-Systeme und sogar um das zuverlässige Löschen alter Daten. Und der häufigste Tipp war: Habt ein Backup!

Bei Datenrettungen, dem Erstellen von Dateisystemen für virtuelle Maschinen oder forensischen Maßnahmen entstehen Festplattenimages, welche nicht direkt ein Dateisystem, sondern eine eigene Partitionstabelle enthalten. Diese lassen sich mit losetup "loopmounten":

losetup /dev/loop1 image.dd

Doch bekanntlich hat man dann zumindest unter Debian Linux ein Problem, da für die Partitionen innerhalb des Image-Files keine Device-Nodes in /dev/ angelegt werden.

Überall im Netz findet man Anleitungen, wie man aus der mit fdisk -ul /dev/loop1 ausgegebenen Partitionstabelle des Files Offsets berechnet, welche mount als Option übergeben werden können. Unter anderem hier und hier. Das ist, sagen wir mal, etwas umständlich.

Theoretisch kann man das Problem auch mit dem Device Mapper lösen. Laut Manpage muss man dmsetup dazu "nur" eine Partitionstabelle übergeben, die Devices erscheinen dann unter /dev/mapper/. Mir ist das selbst mit einer von dmsetup selbst ausgegebenen Tabelle nicht gelungen.

Deswegen überlässt man diese Aufgabe einfach einem Programm, nämlich kpartx:

kpartx -a /dev/loop1

legt Devices für die im loopback-gemounteten File enthaltenen Partitionen an. Danach funktioniert sowas dann auch unter Debian:

mount /dev/mapper/loop1p1 /mnt

Will man die eigenen Beiträge bei heise online vor der Löschung retten, so bedient man sich eines Scripts, das der User cassiel dort veröffentlicht hat. Es benutzt wget mit Cookies:

#!/bin/bash

# Datei mit den beiden Heise-Cookies (notwendig für login)
COOKIEFILE=cookies.txt

# Nummer des ersten runterzuladenden Beitrags (0=der aktuellste)
POST=0

# Nummer des ältesten noch runterzuladenden Beitrags
MAXPOST=122

# eure Usernummer. Findet ihr in der URL der Liste der eigenen Beiträge im Forenprofil.
USERNR=12345

echo
echo "Schritt 1: Laden der Beitragslisten"
echo
while [ $POST -lt $MAXPOST ]; do
printf -v HTML "postlist-%04d.html" $POST
wget --load-cookies $COOKIEFILE -O $HTML http://www.heise.de/extras/foren/user_postings/user-${USERNR}/hs-${POST}/
sed -n '\/foren\/S-.*\/read\// s#.*href="\([^"]*\).*#\1#p' $HTML >> postlist.txt
POST=$(( POST + 16 ))
done

echo
echo "Schritt 2: Laden der einzelnen Beiträge"
echo
sort postlist.txt | uniq | while read line; do
wget --load-cookies $COOKIEFILE -x -N http://www.heise.de$line;
done

Das Vorgehen ist wie folgt:
1. Betreten des heise-Forums und Einloggen.
2. Klick auf Forenprofil.
3. Rechts im Menü Klick auf "Meine Beiträge".
4. Das erste Posting ist immer Nummer 0. Deshalb bleibt POST=0 gesetzt.
5. Die letzte Postingseite ansteuern. Die URL hat die Form http://www.heise.de/extras/foren/user_postings/user-123456/hs-123/. Die letzte Zahl solange erhöhen, bis nur noch das letzte Posting aufgelistet wird.
6. Die letzte Zahl aus der URL minus Eins für MAXPOST und die vorletzte Zahl (12345) für USERNR im Script eintragen.
7. Im Browser nach den Cookies schauen. Das folgende Cookie-File mit dem Wert für ssoheisede anpassen und als cookies.txt speichern:

# HTTP cookie file.
# Generated by Wget on 2008-10-30 05:20:54.
# Edit at your own risk.

www.heise.de FALSE / FALSE 122836265 ssoheisede %34%22dirid%22%35%2341...(cryptischer Code, ersetzen!)...
www.heise.de FALSE / FALSE 122836265 ssoinit userdb

Achtung: Zwischen den Feldern stehen Tabs, keine Spaces! Alle Daten außer dem Wert für ssoheisede, also "%34...", bleiben unverändert.

Dann startet man das Script, und wget saugt alle eigenen Beiträge auf die Platte. Wenn es nicht klappt, konnten die Cookies von wget nicht richtig eingelesen werden, und daher wurden die Benutzerbeiträge nicht erkannt. Das Script tut dann nach der Meldung "Schritt 2: Laden der einzelnen Beiträge" nichts mehr.

Die Pfeil-Taste klemmt ein wenig, statt einer Mail werden fünf ausgewählt, das endgültige Löschen mit Shift-Entf ist von der Routine zum Reflex geworden. Zu spät, die Mails sind endgültig gelöscht, und welche es sind, weiß ich auch nicht mehr.

Doch der Server speichert jede Nacht eine Kopie meiner Mailbox und meines Home-Verzeichnisses. Ausgerechnet mit mutt kann ich das gesicherte mbox-File öffnen, darin navigieren, und die verschwundenen Mails in das aktuelle File kopieren.

Noch einfacher wäre es gewesen, wenn ich die eingebaute "Backup"-Funktion des Mailprogrammes genutzt hätte, also den Papierkorb. Die schützt auch, wenn die Mails nicht schon "von gestern" sind.

Der Sicherheitsexperte Bruce Schneier schreibt in seinem Beitrag Third Parties Controlling Information über ein Forum, das eine wertvolle Informationsquelle für Weinkenner war, bis seine Daten verloren gingen:

Wine Therapy is a web bulletin board for serious wine geeks. It's been active since 2000, and its database of back posts and comments is a wealth of information: tasting notes, restaurant recommendations, stories and so on. Late last year someone hacked the board software, got administrative privileges and deleted the database. There was no backup.

Of course the board's owner should have been making backups all along, but he has been very sick for the past year and wasn't able to.

"Backups! 3" vollständig lesen »

Im IRC-Channel #debian habe ich folgenden Dialog über Backups aufgeschnappt:

john: ok, do you have complete backup of it you can restore?
jane: wait...
jane: i found the old shadow-file in a backup!
***jane jumps around happily
john: wow
jane: regular backups ...
john: you're the -first- person who has ever said yes to "do I backup"
john: and I've been on this net since it started
jane: *g*
john: and before that, openprojects.net
john: since -it- started

Das ist beunruhigend.