EdgeMax router retten …

Ich hatte die vergangene Woche relativ viel Pech und ich beide meiner EdgeMax-Router (EdgeMax Lire und EdgeMax 5PoE) in einen zustand gebracht, in dem sie nicht mehr ordentlich booteten. Beide Zustände waren selbst verschuldet: Bei einem Router hab ich scheinbar einen wichtigen BootSkript modifiziert, so dass in einem bestimmten Zustand ein Booten nicht mehr möglich war. Bei dem anderen Router hab ich wohl durch „ungünstiges“ Reseten das FileSystem geschrottet.

Es stehen nun zwei Varianten für das Recovery zur Verfügung.

  1. Recovery System vie TFTP booten und Fehler beheben
  2. Router aufschrauben, USB Stick ausbauen, Stick an anderem System mounten und die Reperatur starten

Alles setzt auf dem EdgeMax RecoveryKit auf. Will man via TFTP sein system retten, geht man nach dieser Anleitung vor: https://community.ubnt.com/t5/EdgeMAX/EdgeMax-rescue-kit-now-you-can-reinstall-EdgeOS-from-scratch/td-p/514857

In meinem fall musste ich jedoch nicht alles neu installieren. Wenn man das Rettungs-OS hoch gefahren hat, ist unter /root/w das overlay gemounted. Hat man im EdgeOS irgendein Script oder Config File geändert, taucht es hier auf. Löscht man es, hat man wieder die original Version. Im Zweifelsfall kann man einfach alle Änderungen in einen Sicherungs-Ordner verschieben und von Scratch starten …

Eine andere Hausnummer war der IO Defect. Hier musste ich erst mal den Stick ausbauen und testen. Nach mehrfachen „badblock“ Durchläufen war klar, dass es nur das FileSystem zerschossen hatte. Da nach den Durchlauf von Badblock die PartionsTabelle zerstört wurde muss ich komplett vom scratch aufsetzten.

Mit folgendem script habe ich angefangen: https://github.com/vyos/emrk/blob/master/bin/emrk-reinstall.

Da ich keine Risiko eingehen wollte, habe ich alle befehle einzeln per hand ausgeführt, man kann aber auch einfach die variablen korrekt setzten und das Skript im ganzen ausführen. Anschließend Stick wieder einbauen router hochfahren und neu konfigurieren…

Wenn rdiff-backup mal streikt…

Rdiff-backup ist meine favorisierte Backuplösung. Sie hat einfach zu viele nette Feutures, allen vor ran der geringe Speicherplatzverbrauch plus der Datei-Historie. Leider hat rdiff-backup ein Problem mit seiner Stabilität.  Wenn es mal zu einem inkonsistenten Backup kommt. steht man ziemlich mit runter gelassenen Hosen da. Ich selbst leide an einem solchen Problem. Um zu ermitteln ob mit einem Backup alles in Ordnung ist muss man folgenden Befehl ausführen:

Liefert dieser Befehl keinen Output kann man es ruhig angehen lassen. Gibt es jedoch Meldungen wie diese hier, sollte man auf jeden Fall prüfen was mit dem Backup nicht stimmt.

Wenn man dem nicht traut kann man mittels folgenden Befehl einen kompletten vergleiche Quelle<>Backup anstoßen:

Dieser Befehl liefert die Files, bei dehnen sich Quelle und Backup unterscheiden unabhängig davon ob sich laut Change-Time irgendwas an der Datei geändert haben sollte.
Zusätzlich gibt es noch:

Dieser macht das gleiche wie der vorherige Befehl, nur vergleicht er nur die gespeicherten Hashes mit den neu genierten der Qulle. Das hilft nichts, wenn sich die Dateien im Backup geändert haben (z.B. korruptes File-System).
Kurz wenn der „compare-file‘ Befehl sagt „alles ok“, dann kann man dem trauen. Er ist jedoch auch der aufwändigste. Jeh nach Datenmenge kann das 24 Stunden und mehr brauchen. Leider hat der Befehl auch noch einen anderen Hinkfuß. Für die Dauer der Prüfung darf die Quelle nicht geändert werden, da es sonst zu unnützen Flaschmeldungen kommt.

Hat man einmal eine Datei (oder mehrere) ermittelt die defekt im Backup gespeichert vorliegt muss man diese im Backup aktualisieren. Leider bietet rdiff-backup dafür keinen Mechanismus. So das man händisch bei allen dateien  den „mdoified“-Zeitstempel auf einen Wert nach dem letzt Backup setzt muss. Also einfach ein touch auf alle Quelldateien bei den das Backup nicht in Ordnung ist, anschließend rdiff-backup nochmal laufen lassen.