Anzeige:
Ergebnis 1 bis 6 von 6

Thema: Der Supergau ist eingetreten - Server-Systemplatte kaputt

  1. #1
    ruestiger Rentner Avatar von pibi
    Registriert seit
    Jul 2002
    Ort
    Winterthur (CH)
    Beiträge
    2.697

    Der Supergau ist eingetreten - Server-Systemplatte kaputt

    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 (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.
    div. Hardware:
    Server openSuSI 15.1 / Laptops und Workstations openSuSI 15.2, 15.3 und 15.5
    Fritzbox 7940, Synology DS418

  2. #2
    ruestiger Rentner Avatar von pibi
    Registriert seit
    Jul 2002
    Ort
    Winterthur (CH)
    Beiträge
    2.697
    Hallo zusammen

    Eine kleine Erfolgsmeldung: Mit
    Code:
    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.
    div. Hardware:
    Server openSuSI 15.1 / Laptops und Workstations openSuSI 15.2, 15.3 und 15.5
    Fritzbox 7940, Synology DS418

  3. #3
    ruestiger Rentner Avatar von pibi
    Registriert seit
    Jul 2002
    Ort
    Winterthur (CH)
    Beiträge
    2.697
    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?
    Code:
    echo 1 > /proc/sys/net/ipv4/ip_forward
    wird 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.
    div. Hardware:
    Server openSuSI 15.1 / Laptops und Workstations openSuSI 15.2, 15.3 und 15.5
    Fritzbox 7940, Synology DS418

  4. #4
    Universaldilletant Avatar von fork
    Registriert seit
    Dec 2001
    Ort
    Frankfurt/Main
    Beiträge
    1.175
    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
    Geändert von fork (19.09.17 um 21:14 Uhr)

  5. #5
    ruestiger Rentner Avatar von pibi
    Registriert seit
    Jul 2002
    Ort
    Winterthur (CH)
    Beiträge
    2.697
    Hoi fork (und die schweigenden Mitleser)

    Zitat Zitat von fork Beitrag anzeigen
    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):

    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.
    div. Hardware:
    Server openSuSI 15.1 / Laptops und Workstations openSuSI 15.2, 15.3 und 15.5
    Fritzbox 7940, Synology DS418

  6. #6
    Universaldilletant Avatar von fork
    Registriert seit
    Dec 2001
    Ort
    Frankfurt/Main
    Beiträge
    1.175
    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).
    Geändert von fork (21.09.17 um 10:21 Uhr)

Ähnliche Themen

  1. Systemplatte für Homeserver welche
    Von seemann im Forum stationäre Hardware
    Antworten: 8
    Letzter Beitrag: 01.06.08, 20:07
  2. Suse 9.2. Wechsel der Systemplatte
    Von boxerfahrer im Forum stationäre Hardware
    Antworten: 4
    Letzter Beitrag: 04.05.07, 19:45
  3. Supergau eingetreten -> alle Daten weg?
    Von DrainDZ im Forum Linux Allgemein
    Antworten: 12
    Letzter Beitrag: 22.03.06, 01:37
  4. Supergau
    Von El_Barto im Forum System installieren und konfigurieren
    Antworten: 10
    Letzter Beitrag: 07.12.02, 21:27
  5. SuperGAU
    Von tom021 im Forum Windowmanager
    Antworten: 2
    Letzter Beitrag: 28.10.02, 00:32

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •