13.1 & VMWare Datenverlust nach Crash

Hinweis: In dem Thema 13.1 & VMWare Datenverlust nach Crash gibt es 15 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Hallo,


    wir betreiben mehrere virtuelle Server 13.1 unter vmware 6.7. Gestern hatten wir beim Speicher einen Totalausfall, woraufhin alle virtuellen Server brutal ausgegangen sind.
    Nach dem Starten waren in den Anwendungsdaten einige Dateien auf Dateigröße 0 und andere Dateien wiederum hatten einen Datenstand von vor 8 Wochen.
    Selbst eine aktuelle Sicherung aus Veeam brauchte "nur" den alten Datenstand zurück.
    Lediglich ein täglich ausgeführtes robocopy hatte aktuelle Daten.


    Auch in Logs war eine Lücke von 8 Wochen. Mit den Systemen wird täglich gearbeitet.


    Hat hier jemand eine Erklärung? Das betraf 4 von 8 Servern mit 100% gleicher Installation.


    Danke

    Für den Inhalt des Beitrages 131544 haftet ausdrücklich der jeweilige Autor: hf40

    So wie ich das sehe, war der Crash ein Hardwareproblem! Ihr betreibt da Linux unter VMWare! Das ist mit Sicherheit kein Problem von Opensuse (obwohl die Version 13.1 auch schon recht alt ist), sondern von VMWare!
    Hier bist du aber in einem Opensuse Forum nicht bei VMWare!

    Für den Inhalt des Beitrages 131546 haftet ausdrücklich der jeweilige Autor: Z_O_O_M

    Ich denke, ihr habt eure (hoffentlich) täglichen Backups von VEEAM leider auf genau den Volumes gesichert, die beim Absturz mit in's Nirvana gingen.
    Der wöchentliche Backup war noch erreichbar, die täglichen weg.
    Auch Backups wollen mit Verstand nach allen Regeln der Kunst konfiguriert werden.


    Aber das ist nur eine Vermutung.
    Vernünftiges kann man dazu erst sagen, wenn du den exakten Setup beschreiben würdest.
    Was liegt wo wie? Welche Backjobs tun was genau? Und welche Restore- Automatismen greifen da?
    Wie sind die VMs konfiguriert? Welchen Diskspace- Setup verwenden die?

    Hallo, nein. Die Volumes des Backups befinden sich auf einem separaten Storage.
    Zudem hatte die VM ja bereits nach dem Hochfahren (nach Crash) veraltete Daten.
    Das Backup war halt unsere Hoffnung (vergeblich)

    Für den Inhalt des Beitrages 131634 haftet ausdrücklich der jeweilige Autor: hf40

    Zitat von Z_O_O_M

    So wie ich das sehe, war der Crash ein Hardwareproblem! Ihr betreibt da Linux unter VMWare! Das ist mit Sicherheit kein Problem von Opensuse (obwohl die Version 13.1 auch schon recht alt ist), sondern von VMWare!
    Hier bist du aber in einem Opensuse Forum nicht bei VMWare!

    Ich könnte mir auch vorstellen, das SuSe nicht permanent auf Platte schreibt (wobei mehrere Wochen lang Daten im Cache halten ist schon schwer). Oder die Treiber für den Storage sind fehlerfaft (wobei wir die aktuellen für diese Version einsetzen). Also irgendwer hats gecachet, Linux oder Vmware.

    Für den Inhalt des Beitrages 131635 haftet ausdrücklich der jeweilige Autor: hf40

    Da stimmt was nicht.


    Entweder funktioniert euer Backup, dann sind die Daten vorhanden,
    oder der Backup läuft immer schief.


    Es soll vorkommen, dass man Backups vor der Verwendung zurückspielen muss.
    Von nichts, kommt nichts.

    Moin zusammen,


    ich sag nur Snapshot ist Dein Freund. VMWare bringt von Hause aaus _alles_ mit um eine tägliche volle Sicherung zu fahren.


    Sicherung auf Dateiebene kann manja zusätzlich fahren, aber tägliche Snapshots sollten das absolute Muss sein!


    Desweiteren kann man auf Dateiebene unter Linux mit rear volle Sicherungen fahren incl. Boot ISO Datei.
    Voraussetzung, irgendwo netzwerkteschnisch gut ereichbarer NFS Server mit angeschlossenem 'Datengrab' oder TSM Server.

    Viele Grüße,
    T.

    Für den Inhalt des Beitrages 131646 haftet ausdrücklich der jeweilige Autor: Tamerlain

    Ein Backup, welcher Art auch immer, hat nun nichts mit veralteten Daten nach einem Crash mit Neustart zu tun.
    Im Übrigen habe ich ein Ticket bei VMWare erstellt. Mal sehen, was die mir sagen können.

    Für den Inhalt des Beitrages 131648 haftet ausdrücklich der jeweilige Autor: hf40