OMV - btrfs mount error nach Stromausfall

[snaxilian]

Von BTRFS und RAID5/6 sollte man die Finger lassen.

Aha und warum rätst du dem TE dann vom stabilen mdadm ab und empfiehlst ihm hier doch BTRFS zu verwenden wenn du dann von Raid 5/6 abrätst?
Also ja wir wissen nicht 100%ig welches Raidlevel der TE verwendet aber er nutzt 4 HDDs und ich vermute mal, es wird kein Raid 10 sein.
Also hast du ihm Quatsch empfohlen oder war es dir einfach egal was mit seinen Daten passiert?

An dem Punkt hänge ich etwas, weil ich nicht genau weiß, was ich hier eintragen muss

Die Ausgabe der fstab könnte uns helfen, dir zu helfen.
ein 'cat /etc/fstab' würde den nötigen Inhalt liefern.

 

[henfri]

Warum gleich so unfreundlich und mit Boshaftigkeit unterstellen?

1) er nutzt raidt. Habe ich aber auch erst später gesehen.
2) mdadm hat das Gleiche Problem wie BTRFS in raid5.

Bin jetzt aber raus. Hab keine Lust auf diesen Ton.

Gruß,

Hendrik

 

[snaxilian]

Boshaftigkeit

Fehlinterpretation deinerseits oder bellen da betroffene Hunde? Ich halte mich da ja eher an Hanlon's Razor...

mdadm hat das Gleiche Problem wie BTRFS in raid5

Korrekt, beide haben ein write hole aber im Gegensatz zu btrfs kann man mdadm für ein Raid 5 oder 6 problemlos in produktiven Umgebungen verwenden ohne dass die Entwickler einem davon abraten. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

Finde es immer wieder faszinierend wie Fanboys bei egal welchem Thema die negativen Aspekte ausblenden, ignorieren und nicht darauf eingehen wenn man diese explizit erwähnt und versuchen das Thema woanders hin zu lenken^^

@Konfekt die Datei /etc/fstab könnte hilfreich sein, da dort dokumentiert ist welche Dateisysteme wo und mit welchen Optionen standardmäßig gemountet sind. Anhand dessen könnte @Piktogramm oder ich oder andere dir den genauen Befehl nennen mit dem du das Raid mit btrfs Dateisystem als read-only an der richtigen Stelle einhängen kannst.
Wenn dann alles wieder läuft, solltest du deine Backupstrategie überdenken und optimieren damit der potentielle Datenverlust geringer ausfällt in der Zukunft.

 

[Konfekt]

Hallo zusammen,

danke an alle für die vielen interessanten und wertvollen Ideen und Hilfestellungen. Habe jetzt erst mal "cat /etc/fstab" ausgeführt mit folgendem Ergebnis:

UUID=1ecadd94-8b53-4ef3-a8b1-6cb18af954e8 /   ext4 noatime,nodiratime,errors=remount-ro o       1
# /boot/efi was on /dev/sda during installation
UUID=9842-5873    /boot/efi     vfat    umask=0077      0        1
# swap was on /dev/sda3 during installation
#UUID=794418ee-8baa-4a35-9a91-84db6d72fc2e none      swap    sw        0         0
/dev/sr0          /media/cdrom0       udf,iso9660 user,noauto  0          0
# >>> [openmediavault]
/dev/disk/by-label/data         /srv/dev-disk-by-label-data     btrfs      defaults,nofail   0  2
/dev/disk/by-uuid/78688a03-e63e-45a0-b80c-7a7a85287463      /srv/dev-disk-by-uuid-78688a03-e63e-45a0-b80c-7a7a85287463   ext4     defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,ac1  0  2
#<<<[openmediavault]

Hoffentlich habe ich alles richtig händisch abgetippt.

Mein Ziel wäre tatsächlich, dass am ehesten noch das NAS normal mounten könnte, wenn das irgendwie möglich ist, heißt, ich könnte alle Daten über meine gewohnte Weise sichern. Wäre vermutlich nicht mal so viel, da die allermeisten Daten schon gesichert sind.

Die Frage wäre ja, wenn man das System retten/ reparieren kann, ist es dann noch verlässlich? Oder wäre ein Neuaufsetzen des RAID sinnvoller?

Ist ein RAID-5.

Wenn ich noch Infos liefern soll, immer fragen.

@snaxilian
Ja, sehr gern mit den jeweiligen Befehlen. Ich denke, ich würde über ein Neuaufsetzen dann nachdenken, gern auch mit einem anderen Dateisystem, ich bin jetzt nicht an BTRFS festgekettet,, ich würde mich durchaus informieren lassen, was sinnvoll ist.

Werde auch mal eine USV Stromversorgung anschaffen müssen, mir ist da schon mal was zerschossen worden wegen der ... Stromausfälle, die es hier öfters mal gibt, reicht langsam.

 

[Piktogramm]

Entschuldige bitte, dein Thread ist bei mir untergegangen.

Das Ziel für "mount" sollte /srv/dev-disk-by-label-data sein, mit den bereits genannten Parametern sollte dann das SMB-Share wieder lesend verfügbar sein.

Alternativ könntest du in der fstab die Zeile ändern:

/dev/disk/by-label/data         /srv/dev-disk-by-label-data     btrfs      defaults,nofail,ro,usebackuproot  0  2

Also schlicht die Optionen einfügen, die auch beim manuellen "mount" gesetzt werden.

PS: Wenn es trotz Pause weitergehen sollte, schreib ein @ an mich, da ist die Chance größer, dass ich es mitbekomme.

PPS: Da du das händig abgetippt hast. Für die Zukunft wäre es wahrscheinlich sinnvoll, dass du dir mal "ssh" anschaust. Dann könntest du von dem Rechner, von dem du Beiträge schreibst direkt kopieren/einfügen.

Ergänzung (16. August 2022)

@Konfekt
Selber das @ vergessen ..

 

[Konfekt]

@Piktogramm : Danke Dir vielmals, ich hatte auch einiges zu tun wegen Arbeit und Privatem, ich werde das jetzt mal versuchen und mich voraussichtlich melden

Nachtrag: Hat geklappt! Vielen Dank dafür, dann kann ich jetzt erst mal die Daten retten und schauen, was ggf. beschädigt wurde.

Im nächsten Schritt würde ich dann das NAS neu aufsetzen müssen. Ist OMV hier das Maß der Dinge, gäbe es Alternativen?

 

[Piktogramm]

Ich habe keine starken Gefühle was NAS-Distributionen angeht. Innerhalb der vorgesehenen Abläufe taugen die großen alle. Will man davon großartig abweichen oder geht irgendwas schief, braucht es Grundlagenwissen.

 

[Konfekt]

@Piktogramm

Dankeschön, dann werde ich wohl weiter auf OMV setzen, habe ja auch wieder einige Kommandos gelernt und kann mich damit schon etwas besser in der Shell bewegen. Habe jetzt auch soweit alles sichern können und dafür an alle ein dickes Dankeschön, das hat mir sehr geholfen!

Dann steht in den kommenden Tagen das fröhliche Neueinrichten und Einspielen der Daten an. Ich freu mich .

 

[henfri]

Dann steht in den kommenden Tagen das fröhliche Neueinrichten und Einspielen der Daten an. Ich freu mich .

Was musst du denn neu einrichten?
Doch nur den Speicher und die Shares, nicht aber das OS.

Und überleg Mal ob du wirklich raid5 nutzen willst.
Und ob du mdadm und BTRFS kombinieren willst.

Ich würde beides nicht machen.

 

[Konfekt]

@henfri

Genau, im Grunde muss ich Speicher und Shares neu aufsetzen, Rest bleibt ja.

Was wäre eine sinnvolle Alternative zu RAID-5? Habe insgesamt 4 Festplatten zu je 6 TB. Statt mdadm und BTRFS, was wäre empfehlenswert?

 

[snaxilian]

Das kommt ganz darauf an, was du erreichen willst. Es gibt nicht die eine allgemeingültige perfekte Lösung. Du musst die Kriterien benennen und daraus ergeben sich dann handfeste Kriterien. Anhand der Kriterien kann man dann prüfen, welche technischen Lösungen diese Anforderungen erfüllen.

Du gehst doch auch nicht ins Autohaus und fragst ob du dir jetzt ein Cabrio oder besser einen Kastenwagen kaufen solltest. Du überlegst dir zuerst welche Anforderungen du an das Auto hast, was du bereit bist zu zahlen, usw. und damit kannst du dann gucken gehen ob Cabrio oder Kastenwagen für dich sinnvoller ist.

 

[Konfekt]

@snaxilian

Ja, macht Sinn. Allgemein möchte ich einen RAID aufsetzen mit Ausfallschutz gegen Plattenausfall bei einer der HDD, dafür hatte ich den RAID-5. Das NAS soll im Grunde als Netzlaufwerk dienen, das ich von überall aus im Haus erreichen kann, per LAN und WLAN, per Samba-Share und per Android, also dass ich es ganz klassisch als Netzlaufwerk unter Windows einbinden kann.

 

[henfri]

RAID1 ohne mdadm.
Dann hast du aber nur 2*6GB statt aktuell 3*6.

 

[Konfekt]

Was spricht gegen RAID-5? Mal eben auf 6 TB verzichten fände ich auch blöd, zumal ich alles immer im Backup gesichert habe.

 

[henfri]

Was spricht gegen RAID-5

Dass das vermutlich der Grund für deinen Datenverlust ist.
Stichwort: write hole.
Lies Mal diesen Thread nochmal...

 

[Konfekt]

Snaxilian erwähnte dies hier:

Korrekt, beide haben ein write hole aber im Gegensatz zu btrfs kann man mdadm für ein Raid 5 oder 6 problemlos in produktiven Umgebungen verwenden ohne dass die Entwickler einem davon abraten. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

Für mich liest es sich, als ob mdadm mit RAID-5 ja kein Problem sein sollte. Zumal ich nach Sicherung meiner Daten auch keinen Verlust festgestellt habe, es ist alles soweit vorhanden. Lediglich scheint da in der Konfiguration etwas kaputt gegangen zu sein, aber rein von den Daten her ist alles da.

 

[Naturtrüb]

...sicher geht das, Synology macht das so schon geraume Zeit. BTRFS wird als Dateisystem für Snapshots genutzt, darunter werkelt das klassische Linux-RAID-Management mit mdadm und LVM für das Volume-Management:

https://kb.synology.com/en-nz/DSM/t...entation_for_Btrfs_File_System_on_SynologyNAS

Wenn das so furchtbar wäre, würden sie das ja nicht auf (fast) ihre ganze Produktpalette ausrollen:
https://www.synology.com/de-de/dsm/Btrfs

 

[henfri]

Für mich liest es sich, als ob mdadm mit RAID-5 ja kein Problem sein sollte.

Doch, steht doch weiter oben auch.
Und wenn das nicht reicht:
https://www.spinics.net/lists/linux-btrfs/msg106239.html
Achte auf den Namen des Fragestellers:-)

Lediglich scheint da in der Konfiguration etwas kaputt gegangen zu sein, aber rein von den Daten her ist alles da.

Also weiter mit dem Feuer spielen, weil es einmal gut gegangen ist...?
Na dann...

 

[snaxilian]

Man kann das Thema Write Hole auch übermäßig aufbauschen... Ja das Problem existiert aber damit das ernsthaft auftritt muss man

• Daten schreiben und
• Ein (Strom)ausfall des Systems muss statt finden und
• Das journaling des verwendeten Dateisystems muss ein Problem haben

@henfri Also vor allem lese ich, dass alle Systeme Vor- und Nachteile haben und keins perfekt ist. Btrfs hat zwar kein write hole aber andere Baustellen.
Btrfs hat echt einige wirklich tolle Stärken aber kann es vielleicht sein, dass du hier einem confirmation bias unterliegst? Denkst du wirklich Synology hätte sich nicht 1-2 Gedanken dazu gemacht warum sie mdadm + lvm + btrfs verwenden wenn das Thema write hole (oder andere Themen) so gravierend wäre?

Allgemein möchte ich einen RAID aufsetzen mit Ausfallschutz gegen Plattenausfall bei einer der HDD

Okay aber 'warum'? Ein Raid 5 erhöht ja nur die Verfügbarkeit der Daten. Hast du solch hohe Anforderungen an die Verfügbarkeit, dass diese auch zur Verfügung stehen müssen bei Ausfall einer HDD? Ist eine Downtime , bis Ersatz beschafft wurde und einspielen des Backups durch ist, inakzeptabel?

Der Punkt auf den ich hinaus möchte ist: Ein Raid schützt nicht vor Ransomware, nicht vor versehentlichem löschen deinerseits, nicht vor anderen Hardwareproblemen des NAS und nicht vor anderen Problemen die mir gerade nicht einfallen.

Wenn dir diese Verfügbarkeit weiter wichtig ist, dann hast du mit vier HDDs nur wenige Möglichkeiten:

• Raid 1: Kapazität einer HDD nutzbar, du hast drei gespiegelte Kopien, also können 3 beliebige HDDs ausfallen.
• Raid 10/1+0: Kapazität von zwei HDDs nutzbar. Je zwei HDDs werden gespiegelt (Raid 1) und darüber ein Raid 0. Es darf je eine HDD pro Raid 1 ausfallen.
• Raid 5: Kapazität von drei HDDs nutzbar, eine beliebige HDD darf ausfallen.
• Raid 6: Kapazität von 2 HDDs nutzbar, zwei beliebige HDDs dürfen ausfallen.

Bei Raid 1 hast je nach Anwendungsfall eine höhere Leseperformance und bei Raid 10 noch eine höhere Lese- & Schreibgeschwindigkeit, für ein Datengrab mit wenigen gleichzeitigen Nutzern vermutlich weniger relevant.

Bei einem Raid 5 und auch 6 hast du je nach Datenmenge noch weitere theoretische Probleme: https://www.zdnet.com/article/why-raid-6-stops-working-in-2019/
Als Mitigation dagegen wurden ja Dateisysteme entwickelt, die Checksummen verwenden zur Integritätsprüfung, wie z.B. btrfs oder zfs. Diese haben aber eben andere Limitierungen und/oder man verwendet HDDs mit einer höheren URE um die Eintrittswahrscheinlichkeit zu senken.
Beides ersetzt aber nicht die Notwendigkeit für Backups

Wenn du regelmäßige Backups machst und keine Ansprüche an eine höhere Verfügbarkeit stellst dann könntest du auch einfach alle vier HDDs mit btrfs zusammen fassen und ggf. nur die Metadaten redundant aufbewahren, btrfs ist da ja flexibel.
Oder wenn du kein btrfs möchtest: klassisch mit lvm die HDDs zusammen fassen und dann ein Dateisystem deiner Wahl.

 

[Piktogramm]

Dass das vermutlich der Grund für deinen Datenverlust ist.
Stichwort: write hole.
Lies Mal diesen Thread nochmal...

Damit das writehole zu einem Problem wird, braucht es ein Ausfall bzw. das Ausbleiben eines sauberen Deinit des Raid während eines Schreibvorgangs. Das normale Verhalten von mdadm nach einem solchen Fall sollte es sein, das Raid zu testen. Wenn OMV da nicht an der Config geschraubt hat, hätte mdadm an der Stelle Fehler geworfen und das Raid als defekt deklariert. Das wurde bereits zu Beginn des Threads ausgeschlossen.


@henfri Also vor allem lese ich, dass alle Systeme Vor- und Nachteile haben und keins perfekt ist. Btrfs hat zwar kein write hole aber andere Baustellen.[/QUOTE]
BTRFS in der Standardconfig hat Probleme mit dem WriteHole, die nachhaltige Lösung um WriteHole zu beseitigen und Verschlüsselung auf Dateisystemebene zu ermöglichen verstecken sind derzeit experimentell. Oder aber man schreibt die Metadaten auf non Raid5/6 Laufwerke bzw. Partitionen.


Alles in allem bleibe ich aber dabei und würde @Konfekt dazu raten, Raids und Laufwerke so einzurichten, wie es OMV vorsieht. Individuelle Lösungen bedingen im Zweifelsfall nur, dass man sich selber helfen können muss und die Notwendigkeit von Backups bleibt so oder so bestehen. Der Aufwand lohnt also meist einfach nicht.