Backup / Sicherung von Fritzbox (bzw. korrekterweise „FRITZ!Box“) erstellen

Ein Blogeintrag für die Erstellung einer Datensicherung für die Fritzbox scheint fast absurd – schließlich hat die FRITZ!Box eine halbwegs taugliche Admin-Oberfläche, innerhalb derer man das Backup per Klick erzeugen und downloaden kann.

…wäre da nicht eine Kleinigkeit (s.u.)…

Regulär ist es wie einleitend bemerkt kinderleicht, seine Daten zu sichern:

  • in die Verwaltungsoberfläche gehen
  • dort den Menüpunkt „System / Einstellungen sichern“ aufrufen
  • den Tab„Sichern“ aufrufen
  • Sicherung durchführen

Man hat hier die Möglichkeit, ein Passwort zu vergeben. Schade nur, dass der Hersteller AVM an dieser Stelle nicht darauf hinweist, dass dies zwingend erforderlich ist, wenn man das Backup in ein anderes Gerät (z.B. wie in meinem Fall eine Austausch-Hardware) einspielen möchte.

RTFM, könnte man sagen, denn im Handbuch steht es drin:

Um Ihre gesicherten Einstellungen in eine andere FRITZ!Box gleichen Modells zu laden oder um für Ihre FRITZ!Box Einstellungen einer FRITZ!Box anderen Modells zu übernehmen, muss die Sicherungsdatei jeweils mit einem Kennwort versehen sein.

Darauf will man also achten 😉

rsync zwischen MacOS (HFS+) und Linux (ext3) – und defekte Dateinamen

Bei umfangreicheren rsync-Läufen hier im lokalen Netz (ging um ca. 4 TB die von einem Ubuntu Server mit ext3 auf einen Mac mit HFS+ gehen sollten) stellten sich 2 Probleme heraus, die beim Sync zwischen Linux Maschinen nicht auftraten:

  • Ein großer Teil der Daten (und zwar alle mit Leerzeichen oder Umlauten im Dateinamen) wurde bei jedem rsync Aufruf neu übertragen, obwohl die Dateien sich nicht geändert hatten.
  • Umlaute waren z.T. defekt.

Eine längere Herleitung spare ich mir hier mal – statt dessen nur das Ergebnis der Recherchen, da das ggf. noch für jemanden nützlich sein könnte:

Das Problem entstand durch unterschiedliche Charsets auf beiden Maschinen:

Something else that can trip up rsync is a filesystem changeing the filename behind the scenes. This can happen when a filesystem changes an all-uppercase name into lowercase, or when it decomposes UTF-8 behind your back.

An example of the latter can occur with HFS+ on Mac OS X: if you copy a directory with a file that has a UTF-8 character sequence in it, say a 2-byte umlaut-u (303274), the file will get that character stored by the filesystem using 3 bytes (165314210), and rsync will not know that these differing filenames are the same file (it will, in fact, remove a prior copy of the file if –delete is enabled, and then recreate it).

You can avoid a charset problem by passing an appropriate –iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using –iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).

(Die Erklärung stammt aus der rsync FAQ.)

Dem geneigten Mac-User fällt aber leider schnell auf, dass das mitgelieferte rsync den Parameter --iconv leider nicht versteht. Hier empfiehlt sich das Updaten z.B. über Macports – dazu hatte ich hier gerade schon ein paar Zeilen geschrieben.

Lange Rede, kurzer Sinn – nach dem rsync Update und der Angabe der Parameter schaut das bisher sehr gut aus. Folgender Kommandozeilenaufruf wird dabei verwendet:

rsync -a --modify-window=1 --stats --progress --exclude "*.frk"' --delete --iconv=UTF8-MAC,UTF8 root@SERVERNAME:/pfad/zum/Quell-Verzeichnis/ /pfad/zum/Ziel-Verzeichnis/