Der Supergau ist eingetreten - Server-Systemplatte kaputt

[pibi]

Hallo zusammen

Nun hat es auch mich erwischt, ist ja auch kein Wunder mit einer ueber zehn Jahre alten Hardware. Trotzdem aergerlich:-(

Mein Server ist ein alter Compaq ML370 mit sechs eigenstaendigen Hot-swappable Disks. Und natuerlich hat es die Platte mit dem Betriebssystem erwischt, sie quietscht nur noch vor sich hin (Lagerschaden?):-( . Anyway, fuer Notfaelle habe ich auf einer separaten Disk in dem Server ein Diskimage der Systemplatte (erstellt mit "dd") vorgehalten, so dass ich relativ schnell wieder online war mit den wichtigsten Funktionen. Nur leider war dieses Image ca. 12 Monate alt, so dass alle Aenderungen des letzten Jahres nicht darauf enthalten waren. Bin selber schuld, ich weiss:-(

Ausserdem habe ich jede Nacht ein Backup gemacht (inkremential/differential/full) mit der Software "bacula". Diese befinden sich zum Glueck auf einer bzw. zwei separaten Platten in diesem Server, so dass sie vom Crash nicht betroffen sind. Nur leider ist die Datenbank mit den Bacula-Daten auch ueber den Jordan gegangen bzw. wurde mit dem ein Jahr alten Backup ueberschrieben.

Nun meine Frage: Ich schaffe es nicht, mit der Anleitung von hier (http://www.bacula.org/5.0.x-manuals/de/utility/utility/Volume_Utility_Tools.html) (Stichwort "bscan") alte Backups wieder einzulesen (ich verwende PostgreSQL), so dass ich aus ihnen einzelne Files restoren kann. Ich erhalte nur Fehlermeldungen. Wenn sich ein kundiger Linux hier zu erkenne gibt, gehe ich gerne in die Details.

Aufruf: Wer von Euch hat schon mal erfolgreich ein Desaster-Recovery mit Bacula durchgefuehrt und koennte mir Tips geben? Alles ist willkommen. Danke im Voraus.

Gruss Pit.

[pibi]

Hallo zusammen

Eine kleine Erfolgsmeldung: Mit
bextract /c0d4p2/bacula_stores/server1/Full-0002 /c0d5p1/gugus konnte ich den ganzen letzten Full-Backup der Systemplatte wiederherstellen. Zur Erklaerung:
- /c0d4p2/bacula_stores/server1/Full-0002 ist das File mit dem letzten Full-Backup
- /c0d5p1/gugus ist das Ziel, wo er die Daten aus dem Backup hinschreiben soll

Dieser Befehl restauriert die komplette Session "Full-0002" auf die Destination "/c0d5p1/gugus". Fuer meinen Zweck war das genau richtig, da der "Full" des Systems nur knapp 20 GB gross war.

Nun habe ich nur ein Problem: Trotz der aktuellen Firewall-Regeln kann ich zB. mit meinem Mobilfon via WLAN immer noch nicht nach "draussen" verbinden (http). Vorher hat es wunderbar funktioniert. Die Firewall habe ich natuerlich neu gestartet. Kann es sein, dass Firewall-Regeln irgendwo gecachet werden? Ich denke nicht, oder? Beim Einrichten habe ich immer sofort den Erfolg gesehen. Hmmmmh?

Gruss Pit.

[pibi]

Hallo zusammen

Ich muss auf meinen letzten Post nochmals zurueckkommen. Die Firewall-Einstellungen sind absolut identisch wie vor den GAU, aber trotzdem sind alle Spezial-Einstellungen nicht wirksam (ueber meinen Proxy funktioniert der Internetzugriff jetzt wieder perfekt):

Telefonie ueber Internet kann nicht registriert werden bei sipcall
das Mobilfon bekommt eine IP-Adresse, kann aber keine Internetseiten direkt abrufen

Das alles hat vor den GAU super funktioniert. /var/log/firewall, auf das ich alle Fehler der Firewall protokollieren lasse, wirft keine Fehlermeldungen fuer zB. die IP-Adresse meines Mobilfons aus.

Was habe ich uebersehen? Was muss ich noch aktivieren?

echo 1 > /proc/sys/net/ipv4/ip_forwardwird am Beginn des Firewall-Start-Scripts gesetzt.

Ich brauche dringend einen Anstoss in die richtige Richtung. Ich sehe momentan den Wald vor lauter Baeumen nicht mehr:-((

Danke fuer Ideen und Gruss
Pit.

[fork]

Ruhig und in kleinen Schritten jeden einzelnen Fall durchgehen.


DNS-Anfragen mitverfolgen
Traffic mit tcpdump beobachten(an allen betroffenen Schnittstellen)
Prüfen welche iptables - Regeln jeweils greifen
Prüfen das keine Pakete mit privaten IP-Adressen ins Internet geschickt werden
Logs der beteiligten Server Dienste prüfen

[pibi]

Hoi fork (und die schweigenden Mitleser)


Ruhig und in kleinen Schritten jeden einzelnen Fall durchgehen.
Besten Dank fuer den Tip. Das prinzipielle Vorgehe ist mir schon klar. Leider fehlt mir die Zeit fuer langwierige Analysen:-(

Daher habe ich den pragmatischen Weg gewaehlt (fuer unsere jungen Leser: obwohl sie das wahrscheinlich auch nicht verstehen (https://de.wikipedia.org/wiki/Pragmatismus)):

Da ich den letzten weekly-Full-Backup dank dem Befehl aus #2 komplett wiederherstellen konnte (auf eine temp. Plattform natuerlich), habe ich ein Rescue-System gebootet und nun nicht nur die Firewall-Settings, sondern das komplette System (also /, /usr und /var) auf die Bootplatte kopiert. Dank meiner seit Jahren angewendeten Philosophie der Auftrennung von Partitionen (eine Partition fuer /, eine fuer /var, eine fuer /boot und eine fuer /usr) konnte ich das mit "rsync" relativ "smooth" an die richtigen Orten restaurieren.

Und was soll ich sagen: Es laueft wieder alles wie vor den Disk-Crash!:-)

Was kann man aus dieser Geschichte lernen?

wer Daten speichert, braucht zwingend ein Backup und ueberprueft auch regelmaessig, ob man seine Daten auch daraus restaurieren kann
wenn Datenstrukturen aendern, muss auch die Backup-Definition angepasst werden
wichtige Daten (Diplomarbeit etc.) an mindenstens zwei raeumlich getrennten Orten vorhalten
(to be continued)..


Danke und Gruss aus der schoenen Schweiz
Pit.

[fork]

Leider fehlt mir die Zeit...

Zeit dürfte eine Vorraussetzung für sehr viele Problemlösungen sein. Auch eine Vorraussetzung für mich, bei einer Frage in einem Forum zu unterstützen.

Ansonsten zum Thema Backup:


Wenn möglich Trennung von Backupsystem und Anwendungssystem(Es ist sehr unwahrscheinlich, dass beides gleichzeitig ausfällt).