BTRFS Superblocks nach "Server wird verschoben" defekt

  • Ich hatte ja in dem "Bad Gateway" Thread schon geschrieben, dass mein Server ein komoisches Verhalten an den Tag gelegt hat.

    Zunächst war nichts mehr erreichbar, als ich ein paar Stunden später ins SCP bin wurde der Server gerade verschoben.

    Als dies erledigt war habe ich den Server neu gestartet, jedoch konnte die root Partition nicht gemountet werden.


    Der Server besteht aus einer kleinen Grub und Boot Partition sowie einer BTRFS Partition mit einigen Subvolumes (Debian Buster).


    Der Fehler lautet: "BTRFS partition not mount parent transid verified failed and child eb corrupted .... parent transid verify failed on 21020672 wanted 8751 found 8847"
    In Grub selbst konnte ich auch sonst nichts erreichen, bin dann in ne Linux Live Debian Distro und hab mir die Sache mal etwas näher angeschaut.

    Mounten der Partition war nicht möglich, hab versucht den Superblock wiederherzustellen bzw mit einem der beiden backup blocks zu mounten bzw diese zu verwenden, sind aber auch beide defekt.

    Hab die Partition überprüfen lassen und versucht zu reparieren, ebenfalls nicht möglich.


    Mit btrfs restore kann ich aber Daten von der Platte nach draußen kopieren, Problem natürlich, dass ich ne zweite Platte bräuchte um die Daten wirklich rauskopieren zu können.

    Habe mit rclone einen Cloudspeicher gemountet, jedoch lässt er mir die Daten nicht in die Cloud schieben, zumindest nicht so einfach.


    Backups habe ich, von wichtigen Daten relativ aktuell, die anderen sind schon etwas älter aber nicht so tragisch, kopien habe ich, halt in ner anderen Ordner Struktur.


    Hat vielleicht jemand eine Idee was ich tun kan?

    Ein Ticket habe ich eröffnet, aber ich glaube kaum, dass mir Netcup irgendwie eine Lösung anbieten kann.


    Ich bin gerade relativ sauer, da ich jetzt schon knapp 3h dran sitze und ich selbst nichts verbockt habe.


    [ich habe einen Snapshot im SCP vom sauberen System erstellt, allerdings haben sich die Daten seither natürlich sehr verändert und da es sich um ein copy-on-write Backup handelt, glaube ich nicht, dass das einspielen dieses Snapshots dieses Problem lösen wird]

  • […]

    Hab die Partition überprüfen lassen und versucht zu reparieren, ebenfalls nicht möglich.

    Mit btrfs restore kann ich aber Daten von der Platte nach draußen kopieren, Problem natürlich, dass ich ne zweite Platte bräuchte um die Daten wirklich rauskopieren zu können.

    Habe mit rclone einen Cloudspeicher gemountet, jedoch lässt er mir die Daten nicht in die Cloud schieben, zumindest nicht so einfach.

    […]

    Wurde die Reparatur über ein Bootimage derselben Distribution versucht oder nach "normalem" Start der KVM (sollte keinen Unterschied machen, würde Ersteres aber zur Not immer einmal probieren)?


    Wenn die Reparatur nicht möglich ist, und neben der Datenspeicherung ggf. eine Analyse auf einem anderen System angedacht ist, wäre meiner Meinung nach der Neustart über ein Bootimage gefolgt von einer Kopie des gesamten virtuellen Speichermediums mit dd das Naheliegendste (hilfsweise aus dem laufenden System heraus), was selbst mit Cloudspeicher funktionieren sollte, welcher via WebDAV (dem "einfachsten" Protokoll) eingehängt ist. Durch Verwendung von gzip o. Ä. (mit niedriger/mittlerer Kompressionsstufe) sollte eine gewisse Komprimierung möglich sein, ohne den Kopiervorgang zu stark zu verlangsamen. Alternativ wäre wohl ein Export des KVM-Speicherabbilds möglich (allerdings ggf. kostenpflichtig, sofern der Support hier nicht Kulanz walten lässt).


    Nach Sicherung der Daten bleibt im Falle eines erneuten Fehlschlags bei der Strukturreparierung durch btrfs scrub nur die Neuformatierung. Bei einer Neu­installa­tion könnte – sofern bislang nicht geschehen – der Qemu-Guest-Agent als zusätzliche Absicherung gegen das beschriebene Problem Sinn machen (reine Vermutung, aber bei dem Verschieben einer VM zwischen Hostsystemen kann der Agent anlagemäßig Dateisysteme innerhalb der KVM "kooperativ" einfrieren und wieder auftauen sowie analog bspw. die Konsistenz von Datenbanken sicherstellen; siehe hier für ein Beispiel – ohne Agent kann das Hostsystem hier insbesondere auf Anwendungs­(logik)­ebene "wenig" (=gar nichts) ausrichten).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ich habe die Reperatur mit der selben Distro probiert, also latest Debian stable.

    btrfs scrub funktioniert nur wenn die Partition auch gemounted werden kann, was leider nicht möglich ist.


    Es handelt sich teilweise um hundert tausende Datenbank dateien mit unterschiedlichen berechtigungen/eigentümern.

    Ich habe das ganze normal komprimiert mit tar und erhalt der rechte gesichert und mehrfach abgelegt.

    Hatte bzw habe einfach nur sehr wenig Lust, das ganze System neu aufzusetzen O.O


    Wenn ich die daten mit dd in ein per WebDAV gemounteten Cloud Speicher ziehe bin ich Tagelang am laden. i.d.R. gibts Probleme wenn über einen langen Zeitraum mehr wie 4-5 connections hochladen, und selbst mit 10 habe ich dann Übertragungsraten von vielleicht 500kb/s.

    (btrfs restore macht ja vermutlich auch nichts anderes als dd über das volumen, dort kann ich zumindest mit regex Ausdrücken die Verzeichnisse rausklauben, wenn auch mühsam)

    Um das ganze erstmal in ein Verzeichnis zu packen fehlt halt dann der interne Speicher, insofern müsst ich sowieso die einzelnen Dateien übertragen. (hab schon angefangen mit ein paar Wichtigeren Sachen, wo mir das Backup fast schon zu alt ist)


    Das mit dem "Qemu-Guest-Agent" wusste ich nicht, werde ich dann demnächst installieren. Danke schon mal für den Hinweis und die Hilfe

  • Wenn ich die daten mit dd in ein per WebDAV gemounteten Cloud Speicher ziehe bin ich Tagelang am laden. i.d.R. gibts Probleme wenn über einen langen Zeitraum mehr wie 4-5 connections hochladen, und selbst mit 10 habe ich dann Übertragungsraten von vielleicht 500kb/s.

    Eine Möglichkeit, sich eine zweite Platte zu besorgen, wäre, stundenbasiert einen zweiten, ausreichend dimensionierten VPS zu mieten, welcher mit einer Basis­installa­tion/-partitionierung versehen wird. Das würde zumindest das Geschwindigkeitsproblem lösen, wenn btrfs restore (analog zu zfs send) via nc/netcat über das Netzwerk auf eine andere Festplatte schreiben kann. Wenn es eine lokale Festplatte sein muss, hilft das Buchen eines doppelt so großen VPS – sofern verfügbar –, das Einrichten einer zusätzlichen Partition und die Duplikation der ursprünglichen Partitionen via dd. (Tausch Zeit gegen Geld)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Das sind sehr nette Ideen, aber ich sehs im Grunde überhaupt nicht ein Geld zu investieren um ein Problem zu lösen welches mir extern über Netcup beschert wurde. Ganz im Gegenteil.

    Im Grunde soll der Netcup Support schauen, was er anbieten kann damit das Ganze möglichst elegant und mit möglichst wenig Zeitaufwand meinerseits über die Bühne geht.

    Mal abwarten was der Support schreibt.

  • Das sind sehr nette Ideen, aber ich sehs im Grunde überhaupt nicht ein Geld zu investieren um ein Problem zu lösen welches mir extern über Netcup beschert wurde. Ganz im Gegenteil.

    Im Grunde soll der Netcup Support schauen, was er anbieten kann damit das Ganze möglichst elegant und mit möglichst wenig Zeitaufwand meinerseits über die Bühne geht.

    Mal abwarten was der Support schreibt.

    Definitiv nicht sinngemäß aber dennoch kann man die RootServer Produkte per Zufriedenheitsgarantie innerhalb 30 Tage, bei voller Kostenrückerstattung, kündigen. :saint:

  • Jap, ist ein G9 (RS 4000, ein RS Ostern XL OST21 um genau zu sein)


    Bensen In deinem Satz ist das Wort "sinngemäß" auf jeden Fall nicht sinngemäß verwendet worden. Vielleicht solltest mal ne Runde nachdenken bevor du was kluges sagen möchtest. Rumflamen kannst aber gerne wo anders.

  • Bensen In deinem Satz ist das Wort "sinngemäß" auf jeden Fall nicht sinngemäß verwendet worden. Vielleicht solltest mal ne Runde nachdenken bevor du was kluges sagen möchtest. Rumflamen kannst aber gerne wo anders.

    Oh ha..


    Ich wollte einfach nur darauf hinweisen, dass du anstatt den von m_ueberall angesprochen VPS (Stundenbasierte Abrechnung) auch kurzerhand einen RootServer (Zufriedenheitsgarantie) anmieten könntest um deine Netzwerkperformance zu verbessern.

  • Achso, sorry - ich hab das total falsch verstanden, sorry für meine Reaktion.

    Das kostenlose vlan wäre ja in beiden fällen gleich - 100Mbit, nur halt deutlich schneller als WebDAV was viele kleine Dateien anbelangt.

    Bezüglich btrfs restore und netcat muss ich mich mal schlau machen.

    Grundsätzlich dumm, dass der Server über Nacht geschrottet wurde - daher auch meine schlechte Laune :-/


    Scheinbar bin ich aber nicht der einzigste.

  • Antwort vom Support ist gekommen:

    Mein Server wurde wegen eines Defekts am Hostsystem verschoben. Wenn die VM dann nicht mehr sauber startet lag es an einem Problem, welches zuvor schon existiert hat. Ich besitze einen virtuellen Server, welchen sie bereitstellen, daher ist es mein Problem und die Pflege obliegt mir.


    Wenn die Straße, wo ich mein Auto gegen Bezahlung parke, repariert wird, wegen eines Wasserrohrbruchs und mein Auto daher ohne Vorankündigung umgeparkt wird und danach nicht mehr startet weil der Motor nass geworden ist, ist es mein Problem, da mein Auto und nur fürs parken bezahlt wurde.


    Naja, was hab ich erwartet? Vielleicht ne extra Platte für 2-3 Tage ums schneller über die Bühne zu bekommen - aber in so Sachen merkt man halt dann doch, dass Netcup einfach ein billigst Provider ist (mit dem ich grundsätzlich sonst sehr zufrieden bin).



    Die große Frage ist, ob ihnen bewusst ist, dass es sicherlich kein Zufall ist dass bei mehreren Kunden, auf dem defekten Hostsystem, das Dateisystem zerstört wurde zur Selben Zeit als das Hostsystem defekt war/wurde und die VMs umgezogen wurden - oder ob sie das tatsächlich glauben, dass das purer Zufall sein soll basierend auf dem nicht sachgemässen Umgang des Kundens bzw. dessen Unfähigkeit.

  • Die große Frage ist, ob ihnen bewusst ist, dass es sicherlich kein Zufall ist dass bei mehreren Kunden, auf dem defekten Hostsystem, das Dateisystem zerstört wurde zur Selben Zeit als das Hostsystem defekt war/wurde und die VMs umgezogen wurden

    Wer ist denn noch betroffen?