Servercrash

      Ich meld mich auch mal vorsichtig als jeamand mit Datenbank.-/SQL-Kenntnissen.
      allerdings ist mir das Ausmaß des Problems noch nicht ganz klar: wir haben (hatten) ein RAID 1mit 2 Platten und einem Controller. Eine Platte ist Matsch und der Controller defekt. Eine kaputte Platte ist ja erstmal kein Problem an der Stelle... Seit wann ist den der Controller defekt? Evangelion, kannst du das in etwa ermitteln? Wenn der noch nicht allzulange kaputt ist, sollte es doch möglich sein die Foren-DB auf einem aktuelleren Stand (als Januar) wieder anzubinden, selbst wenn der nicht mehr alles gespiegelt hat.
      Oder sehe ich das falsch? Magst mir vieleicht mal genauer erläutern welchen Zustand die DB aktuell hat, also in wie weit der Controller "Müll produziert hat"?

      Wenn ihr versucht die Daten wiederherzustellen, dann gebt doch bitte ein Feedback, ab wann es wieder Sinn macht Beiträge zu posten. Ich freu mich schon drauf ein paar Anime Reviews zu schreiben. Ist die tolle Anleitung dafür denn noch da? Wenn nein, kann man die dann wieder posten, falls wir die alten Daten nicht zurückbekommen? Ich bin sicher, wir bekommen schon wieder Leben hier rein. :D
      +kekskao+

      Eleanora schrieb:

      Ich meld mich auch mal vorsichtig als jeamand mit Datenbank.-/SQL-Kenntnissen.
      allerdings ist mir das Ausmaß des Problems noch nicht ganz klar: wir haben (hatten) ein RAID 1mit 2 Platten und einem Controller. Eine Platte ist Matsch und der Controller defekt. Eine kaputte Platte ist ja erstmal kein Problem an der Stelle... Seit wann ist den der Controller defekt? Evangelion, kannst du das in etwa ermitteln? Wenn der noch nicht allzulange kaputt ist, sollte es doch möglich sein die Foren-DB auf einem aktuelleren Stand (als Januar) wieder anzubinden, selbst wenn der nicht mehr alles gespiegelt hat.
      Oder sehe ich das falsch? Magst mir vieleicht mal genauer erläutern welchen Zustand die DB aktuell hat, also in wie weit der Controller "Müll produziert hat"?

      Also, ich habe mir das Ganze noch mal angeschaut und muss eine Hiobsbotschaft überbringen:

      Die Tabelle mit den Daten der Postings ist tot. Damit wird die Wiederherstellung der alten Datenbank unmöglich, weil die relevanten Daten nicht mehr lesbar sind.

      Aus technischer Sicht: Tabellen liegen als Dateien im Dateisystem des Servers vor. Wenn eine Tabelle beim Schreiben nicht richtig geschrieben werden kann (z.B. wegen eines defekten RAID Controllers), wird die Datei ungültig und vom System nicht mehr als gültige Datei erkannt. Ab einem gewissen Grad der Beschädigung wird die Datei verworfen und als irreparabel angesehen. Danach bleibt nichts mehr übrig als die Datei beim fsck löschen zu lassen, damit der Server keine Probleme mehr mit den betroffenen Sektoren hat.

      Ansonsten zu der Frage des Tathergangs:
      Seid wann der RAID Controller Probleme gemacht hat, habe ich noch nicht nachgeschaut und um ehrlich zu sein, mache ich das auch nicht mehr, weil es in meinen Augen nichts bringt. Beim Server wurden Stand heute die SDA, das Mainboard, CPU und RAM getauscht. Somit ist fast alles neu.
      Dass es Probleme gibt, habe ich auch erst gemerkt, als es schon zu spät war.
      Wir hatten am 05.07.2013 mit einer DDoS Attacke zu kämpfen und erst als der Server am 07.07.2013 immer noch Probleme gemacht hatte, habe ich mir das mal genauer angeschaut. Da der Server aber für die Arbeiten an der Hardware herunter gefahren werden musste, mussten die Tabellen, die sonst im RAM gehalten werden, ja auf das RAID geschrieben werden und da ist dann halt der Datenverlust passiert.

      Die Frage ist, kann man vorbeugen, dass so etwas nicht noch einmal passiert? Ich bin ja ein totaler Computerlaie, deswegen möge man die Frage entschuldigen.
      Sicherlich ist es ärgelich um die ganzen Beiträge von immerhin 1/2 Jahr, aber wenn man die Gewissheit hat, dass man dem vorbeugen kann würden die Leute mit Sicherheit wieder anfangen zu schreiben (behaupte ich jetzt einfach mal).

      Andererseits... wenn es einen guten "Schutzmechnismus" geben so etwas geben würde, hättet Ihr ihn mit Sicherheit angewandt... schon eine blöde Angelegenheit. :(

      you are someone in the world,
      but for someone you are the world

      Oi oi oi... da komm ich ausm Urlaub, bin sowieso schon mehr als muffelig, da ich seit knapp 6 Tagen am Urlaubsort mit dicker Grippe im Bett liege (und hier auch noch, muss insgesamt 10 Tage lang Antibiotiker schlucken) und dann muss ich auch hier noch so eine unschöne Sache sehen...

      Das ist ja echt mist... und ich hab mich schon gewundert dass hier so wenig in der Zeit in denen ich weg war so wenig geschrieben wurde... Blöde Sache.
      Ich mein, ist extrem sch... weil da zum Teil wirklich eine Menge Arbeit drin gesteckt hat und im allgemeinen so viel hier geschrieben wurde.
      Hab ich das also richtig verstanden, dass alles hin ist... oder wird jetzt noch irgendwie was gemacht?

      Soweit wie ich das verstanden habe ist das Restaurieren der alten Daten nicht mehr möglich, da irreperabel zerstört.
      Was man in Zukunft jedoch tun kann, um solch einen GAU zu verhindern, möchte ich gerne erläutern.

      Wenn es um Datenbanken geht, muss man peinlichst darauf achten, keine Redundanzen in den Datenbeständen zu erzeugen.
      Wenn es jedoch um erfolgreiche Backupstrategien geht, sind Redundanzen das A und O.
      Je mehr Spiegelungen man von einem Backup hat, desto geringer ist die Gefahr, dass im Fall eines Datenverlustes auch die Backups
      flöten gehen. Ist ja verständlich: Legt man ein Backup an einen anderen (physischen) Ort ab, wird dieser nicht von etwaigen Unfällen
      betroffen.

      Wichtig ist auch die Wahl der Backupstrategie.
      Ich würde inkrementelle Backups empfehlen. Auf diese Weise kann man sogar stündlich Backups erstellen, die nicht einmal viel Speicherplatz
      bedingen. Am Tag würde so eine Speichermenge von wenigen Bytes belegt werden - jenachdem, wie viel pro Tag so fabriziert wird :D
      Die Funktionsweise: Es wird einmal ein vollständiges Backup gezogen und dann alle X Stunden nur noch die Änderungen seit dem letzten
      Backup gespeichert - werden innerhalb der X Stunden z.B. nur 3 Beiträge verfasst, 5 abgeändert und 1 gelöscht, werden nur diese Änderungen
      gespeichert.

      Genauso wichtig wie das Backuppen der Daten ist jedoch der Speicherort für die Backups - wenn es der gleiche FTP-Server ist, könnte es evtl.
      durch Festplattenprobleme beschädigt oder unbrauchbar gemacht werden.
      Meiner Meinung nach müsste man die Backups auf einem gesonderten FTP-Server spiegeln (wenn Windows-Server einfach mit putty, ansonsten ssh/scp),
      um auf Nummer sicher zu gehen.
      Darüber hinaus kann man es einrichten, dass z.B. der (Ober-)Admin diese Backups automatisch auf die heimische Festplatte überspielt bekommt.
      Sollte nun die Platte putt gehen, auf der das Forum und die Backups liegen, könnte man entweder auf die gespiegelten Dateien auf dem anderen
      FTP oder die heimische Festplatte zurückgreifen - ein Datenverlust: Fast unmöglich!

      Dazu würde ich ein weiteres Feature einplanen, welches jedem Benutzer hier erlaubt, die eigenen Beiträge zu exportieren.
      So könnte jeder für sich selbst ein Backup seiner Daten anlegen, gerade wenn man hier viel schreibt und dadurch viel zu verlieren hat, wäre das wohl
      die direkteste Möglichkeit, gegen Datenverlust vorzugehen.
      Tatsächlich wäre die technische Umsetzung sogar recht simpel, eine einfache MySQL-Abfrage, ein geeigneten Ausgabeformat und schon ist der
      Benutzer in Sicherheit gewogen :D

      Ein paar simple Sicherungen, ein neuer Farbanstrich und schon ist das Board wieder gewappnet für neue Untaten :)