Empfehlung Dateisystem
Empfehlung Dateisystem
Hallo zusammen,
ich baue mir hier mein erstes NAS zusammen. Grundlage bietet mir dafür zum testen mein alter PC.
Jetzt stellt sich für mich die Frage nach dem richtigen Dateisystem. Debian Stretch ist bereits auf einer seperaten SSD installiert. Derzeit sind 4 Festplatten zusätzlich verbaut mit jeweils unterschiedlichen Größen. Zuerst wollte ich alle Platten mit LVM versehen, aber bei genauerer Betrachtung kommt das für mich nicht infrage, da bei einem Ausfall einer Platte ich keinen Zugriff mehr auf die anderen Platten habe. Deswegen suche ich ein anderes Dateisystem. Wäre glusterfs ähnlich leicht zu handhaben oder gibt es Alternativen ?
Danke schonmal
ich baue mir hier mein erstes NAS zusammen. Grundlage bietet mir dafür zum testen mein alter PC.
Jetzt stellt sich für mich die Frage nach dem richtigen Dateisystem. Debian Stretch ist bereits auf einer seperaten SSD installiert. Derzeit sind 4 Festplatten zusätzlich verbaut mit jeweils unterschiedlichen Größen. Zuerst wollte ich alle Platten mit LVM versehen, aber bei genauerer Betrachtung kommt das für mich nicht infrage, da bei einem Ausfall einer Platte ich keinen Zugriff mehr auf die anderen Platten habe. Deswegen suche ich ein anderes Dateisystem. Wäre glusterfs ähnlich leicht zu handhaben oder gibt es Alternativen ?
Danke schonmal
Re: Empfehlung Dateisystem
Hallo.
GlusterFS ist etwas ganz anderes. Das ist ein verteiltes Dateisystem, welches über mehrere Rechner verteilt läuft. Theoretisch könnte man das verteilen auch in einem Rechner allein machen, jedoch ist das nicht der Sinn dahinter.
Ich würde mir mal BTRFS ansehen. Damit kannst du ein RAID aufbauen und hast gleich noch so Vorzüge wie Snapshots.
GlusterFS ist etwas ganz anderes. Das ist ein verteiltes Dateisystem, welches über mehrere Rechner verteilt läuft. Theoretisch könnte man das verteilen auch in einem Rechner allein machen, jedoch ist das nicht der Sinn dahinter.
Ich würde mir mal BTRFS ansehen. Damit kannst du ein RAID aufbauen und hast gleich noch so Vorzüge wie Snapshots.
Georg
RTFM, LMGTFY, Orakel... Ach... Warum muss man suchen...
Schrödingers Backup --- "Der Zustand eines Backups ist unbekannt, solange man es nicht wiederherstellt" --- Quelle: Nixcraft
RTFM, LMGTFY, Orakel... Ach... Warum muss man suchen...
Schrödingers Backup --- "Der Zustand eines Backups ist unbekannt, solange man es nicht wiederherstellt" --- Quelle: Nixcraft
Re: Empfehlung Dateisystem
Glusterfs ist etwas anderes - afaik bietet das gar kein Dateisystem, das Daten auf Datenträgern organisiert sondern ledigleich eines, das die Daten auf Servern organisiert - die Server verwenden dann auf den Datenträgern ein anderes, herkömliches Dateisystem wie zB xfs. (Zumindest glaube ich, dass es so ist, man möge mich bitte korrigieren, wenn ich falsch liege.)
Dafür kann man mit lvm auch gespiegelte logische volumes anlegen und zwar mit der Option "-mX" von lvcreate, wobei X die Zahl der Spiegel ist. Mit "-m2" würde sich also lvm darum kümmern, dass die Daten auf insgesamt drei verschiedenen physical volumes gespeichert werden (1 Original und 2 Spiegel).
(lvm würd ich wahrscheinlich mit ext4 kombinieren, obwohl mir sonst xfs auch immer recht gut gefallen hat.)
Abhängig davon wofür das NAS genutzt wird, könnten aber Dateisysteme mit Prüfsummen "beruhigen", also btrfs, nilfs(2) und zfs. Erfahrungen habe ich nur mit btrfs, mit dem ich sehr zufrieden bin. Nilfs kenn ich nur dem Namen nach und zfs hab ich zwar kurz ausprobiert, aber mich hat abgeschreckt, dass man entweder die fuse-Variante nehmen oder erst ein Kernelmodul bauen muss (geht automatisch, aber mich erinnert das zu sehr an die Probleme mit proprietären Grafiktreibern ☺)
Dafür kann man mit lvm auch gespiegelte logische volumes anlegen und zwar mit der Option "-mX" von lvcreate, wobei X die Zahl der Spiegel ist. Mit "-m2" würde sich also lvm darum kümmern, dass die Daten auf insgesamt drei verschiedenen physical volumes gespeichert werden (1 Original und 2 Spiegel).
(lvm würd ich wahrscheinlich mit ext4 kombinieren, obwohl mir sonst xfs auch immer recht gut gefallen hat.)
Abhängig davon wofür das NAS genutzt wird, könnten aber Dateisysteme mit Prüfsummen "beruhigen", also btrfs, nilfs(2) und zfs. Erfahrungen habe ich nur mit btrfs, mit dem ich sehr zufrieden bin. Nilfs kenn ich nur dem Namen nach und zfs hab ich zwar kurz ausprobiert, aber mich hat abgeschreckt, dass man entweder die fuse-Variante nehmen oder erst ein Kernelmodul bauen muss (geht automatisch, aber mich erinnert das zu sehr an die Probleme mit proprietären Grafiktreibern ☺)
Re: Empfehlung Dateisystem
Okay also werde ich mir mal btrfs näher anschauen. Das was ich aber bisher gelesen habe gibt es keine Möglichkeit unter btrfs alle Festplatten zu einem einzigen Volume zusammenzulegen oder ?
Re: Empfehlung Dateisystem
ZBsp.
(Vergrößern/verkleinern ( im Betrieb! ) per
Immer mal wieder ein 'btrfs device scan' einflechten,
wenn mit dem Dateisystem offline gearbeitet wird.)
Test mit loops,
wird kein '-d raid[1|5] -m raid[1|5]' angegeben,
so wird ein "single"-Data erstellt.
-->> Schalte ich vom Verbund 1 ab, bekomme ich das System nicht mehr gemountet.
Mit dieser Voraussetzung jedoch habe ich mit 'mount -o degraded' problemlos Zugang.
Für das Ersetzen eines failed resp. fehlenden device dann nach Internet.
Üben mit ein paar loop-devices.
--------------------------
Hier konnte ich single->raid wechseln, wenn das Dateisystem leer war,
nach Beschreibung funktioniert es auch mit Daten(?)
Code: Alles auswählen
mkfs.btrfs -d raid5 -m raid5 /dev/sdxy /dev/sdxy /dev/sdxy /dev/sdxy /dev/sdxy
Code: Alles auswählen
btrfs device add|delete ... ...
wenn mit dem Dateisystem offline gearbeitet wird.)
Test mit loops,
wird kein '-d raid[1|5] -m raid[1|5]' angegeben,
so wird ein "single"-Data erstellt.
-->> Schalte ich vom Verbund 1 ab, bekomme ich das System nicht mehr gemountet.
Mit dieser Voraussetzung jedoch habe ich mit 'mount -o degraded' problemlos Zugang.
Für das Ersetzen eines failed resp. fehlenden device dann nach Internet.
Üben mit ein paar loop-devices.
--------------------------
Hier konnte ich single->raid wechseln, wenn das Dateisystem leer war,
nach Beschreibung funktioniert es auch mit Daten(?)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Empfehlung Dateisystem
Ich erlaube mir mal, mich hier einzuklinken, weil ich gerade vor einem ähnlichen Problem stehe.
BTRFS sieht auf dem Papier ganz nett aus, aber ist es auch so stabil wie ext* oder gibt es noch die plötzlich auftretenden Datenverluste wie in der Anfangszeit?
BTRFS sieht auf dem Papier ganz nett aus, aber ist es auch so stabil wie ext* oder gibt es noch die plötzlich auftretenden Datenverluste wie in der Anfangszeit?
Re: Empfehlung Dateisystem
Bei mir läuft es schon lange problemlos, aber ein zwei Dinge sollte man vielleicht beachten, zum Beispiel, dass raid5/6 noch problematisch ist ([1], [2]).
Ich verwende btrfs bis jetzt nur mit single und raid1. Der Umstieg von single auf raid1 war auch mit Daten überhaupt kein Problem. Beachten sollte man vielleicht noch, dass raid1 bei btrfs nur 2 Kopien (also Original+Kopie) der Daten macht und nicht so viele wie Datenträger im Verbund sind.
Nicht ganz so kooperativ hat btrfs sich bei einmal mit einem (simulierten) Ausfall verhalten: Ich konnte zwar noch lesend auf das Dateisystem zugreifen (nach dem Mounten mit "-o degraded"), aber ich konnte das ausgefallene Laufwerk nicht ersetzen. Das war aber glaube ich nur ein Problem mit dieser speziellen btrfs-progs/-tools-Version.
[1] https://btrfs.wiki.kernel.org/index.php/RAID56
[2] https://www.phoronix.com/scan.php?page= ... -All-Clear
Ich verwende btrfs bis jetzt nur mit single und raid1. Der Umstieg von single auf raid1 war auch mit Daten überhaupt kein Problem. Beachten sollte man vielleicht noch, dass raid1 bei btrfs nur 2 Kopien (also Original+Kopie) der Daten macht und nicht so viele wie Datenträger im Verbund sind.
Nicht ganz so kooperativ hat btrfs sich bei einmal mit einem (simulierten) Ausfall verhalten: Ich konnte zwar noch lesend auf das Dateisystem zugreifen (nach dem Mounten mit "-o degraded"), aber ich konnte das ausgefallene Laufwerk nicht ersetzen. Das war aber glaube ich nur ein Problem mit dieser speziellen btrfs-progs/-tools-Version.
[1] https://btrfs.wiki.kernel.org/index.php/RAID56
[2] https://www.phoronix.com/scan.php?page= ... -All-Clear
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Empfehlung Dateisystem
Ich verwende btrfs auch schon seit es offiziell für stabil erklärt wurde.
Am Laptop hatte ich bisher noch nie ein Problem.
Wo ich allerdings Instabilitäten bemerkt habe ist bei der Verwendung auf einer externen HD zur Datensicherung der Snapshots.
Ob es daran liegt, dass ich gelegentlich irrtümlich den Stecker abziehe, während noch eine Transaktion aktiv ist, oder ob durch das Bewegen der Festplatte und damit einhergehend der Steckverbindung und einer Kontaktunterbrechung liegt, konnte ich bislang noch nicht rausfinden.
Meistens konnte ich die Daten der externen Festplatte nicht mehr wieder herstellen. Eine Zeit lang ging es mit einem balance und scrub und danach war das Dateisystem wieder verwendbar. Was aber jetzt nicht so tragisch ist, da dies "eh nur" das Backup ist. Ist das kaputt, schreib ich es neu.
Leider hab ich noch keine Möglichkeit, mir ein NAS zuzulegen und dort btrfs zu verwenden, wohin dann mein Laptop übers Netz die Daten sichern könnte... Eventuell liegt es ja auch an btrfs send/receive und nicht an der USB-Verbindung.
Ansonsten finde ich die Features von btrfs echt genial. Und die lokalen (wie auch jene auf der externen Platte) haben mir schon oft "das Leben gerettet", wenn ich mal wieder irrtümlich eine Datei gelöscht oder überschrieben habe... Oder wenn ich zuviel an der Installation geschraubt habe und mir das System kaputt gemacht habe... da reicht es dann einfach in den letzten bekannten funktionierenden Snapshot zu booten (meist lege ich so einen manuell an, bevor ich irgend eine Action vorhabe), und mache dort weiter, wo ich zuvor aufgehört habe.
lg scientific
Am Laptop hatte ich bisher noch nie ein Problem.
Wo ich allerdings Instabilitäten bemerkt habe ist bei der Verwendung auf einer externen HD zur Datensicherung der Snapshots.
Ob es daran liegt, dass ich gelegentlich irrtümlich den Stecker abziehe, während noch eine Transaktion aktiv ist, oder ob durch das Bewegen der Festplatte und damit einhergehend der Steckverbindung und einer Kontaktunterbrechung liegt, konnte ich bislang noch nicht rausfinden.
Meistens konnte ich die Daten der externen Festplatte nicht mehr wieder herstellen. Eine Zeit lang ging es mit einem balance und scrub und danach war das Dateisystem wieder verwendbar. Was aber jetzt nicht so tragisch ist, da dies "eh nur" das Backup ist. Ist das kaputt, schreib ich es neu.
Leider hab ich noch keine Möglichkeit, mir ein NAS zuzulegen und dort btrfs zu verwenden, wohin dann mein Laptop übers Netz die Daten sichern könnte... Eventuell liegt es ja auch an btrfs send/receive und nicht an der USB-Verbindung.
Ansonsten finde ich die Features von btrfs echt genial. Und die lokalen (wie auch jene auf der externen Platte) haben mir schon oft "das Leben gerettet", wenn ich mal wieder irrtümlich eine Datei gelöscht oder überschrieben habe... Oder wenn ich zuviel an der Installation geschraubt habe und mir das System kaputt gemacht habe... da reicht es dann einfach in den letzten bekannten funktionierenden Snapshot zu booten (meist lege ich so einen manuell an, bevor ich irgend eine Action vorhabe), und mache dort weiter, wo ich zuvor aufgehört habe.
lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: Empfehlung Dateisystem
Am einfachsten und bewerte Methode ist mdadm unter linux wenn du raid 5 oder 6 willst. (Oder andere)
https://wiki.ubuntuusers.de/Software-RAID/ So habe ich es momentan auch laufen.
btrfs geht zwar auch, aber gerade bei raid5/6 waere ich da sehr sehr vorsichtig.
zfs gibt es auch, weis aber nicht wie gut das under linux funktioniert.
Snapraid: Das werde ich wohl das naechstes versuchen. http://www.snapraid.it/ (Mehr dazu auf deutsch)
raid5 soll ja nicht mehr so der hamme sein auf modernen Festplatten.
Ich werde mir das ganze nochmal ueberlegen in ein paar Monaten wenn ich mein NAS neu baue.
https://wiki.ubuntuusers.de/Software-RAID/ So habe ich es momentan auch laufen.
btrfs geht zwar auch, aber gerade bei raid5/6 waere ich da sehr sehr vorsichtig.
zfs gibt es auch, weis aber nicht wie gut das under linux funktioniert.
Snapraid: Das werde ich wohl das naechstes versuchen. http://www.snapraid.it/ (Mehr dazu auf deutsch)
raid5 soll ja nicht mehr so der hamme sein auf modernen Festplatten.
Ich werde mir das ganze nochmal ueberlegen in ein paar Monaten wenn ich mein NAS neu baue.
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: Empfehlung Dateisystem
Die Wahl des Dateisystems hängt sehr vom Einsatzzweck ab. Für ein NAS sollte es in jedem Fall erprobt und absolut zuverlässig sein, in jeder Hinsicht. Ergo fällt Btrfs schon mal komplett weg, auch wenn es nützliche Funktionen beinhaltet, sind diese nicht alle reif für den Einsatz. Würde generell zu Ext4 raten, womit im Grunde nichts falsch machen kannst, im Bezug auf Zuverlässigkeit und Geschwindigkeit. Auch hier wäre Btrfs erheblich langsamer als XFS und Ext4. Wenn zuverlässiges Löschen von Daten ein Kriterium ist, dann XFS, zumal hier eine Wiederherstellung von Daten nicht vorgesehen ist. Unter Ext4 lassen sich Daten auch sicher überschreiben, doch unter Btrfs nicht wirklich. Das liegt am Design des Dateisystems, was stark auf Datensicherheit ausgelegt ist, und absolut alles wiederherstellen kann auf längere Sicht. Wird eine Datei gelöscht, ist sie nie wirklich weg, auch wenn sie überschrieben wird, wird die aktualisierte Version der Datei einen neuen Speicherplatz bekommen, ohne den originalen Datensatz unmittelbar zu überschreiben. Hier sollte man also eine komplette Festplattenverschlüsselung in Betracht ziehen wenn das relevant ist, oder man deaktiviert CoW was einen Vorteil von Btrfs wieder zunichte macht. Allerdings hätte Btrfs im Bezug auf Verschlüsselung auch Vorteile, im Vergleich zu allen anderen Dateisystemen. Nämlich die Konsistenzprüfung des Dateisystems mit CRC-Checks, und dasselbe gilt auch für die Metadaten. Somit wäre Btrfs bspw. in der Lage, Offline-Manipulationen der Datensätze zu erkennen und entsprechend mit Backups zu korrigieren. Also sollte man genau darüber nachdenken was man haben, oder vl. in Zukunft umsetzen will.trg2889 hat geschrieben:Hallo zusammen,
ich baue mir hier mein erstes NAS zusammen. Grundlage bietet mir dafür zum testen mein alter PC.
Jetzt stellt sich für mich die Frage nach dem richtigen Dateisystem. Debian Stretch ist bereits auf einer seperaten SSD installiert. Derzeit sind 4 Festplatten zusätzlich verbaut mit jeweils unterschiedlichen Größen. Zuerst wollte ich alle Platten mit LVM versehen, aber bei genauerer Betrachtung kommt das für mich nicht infrage, da bei einem Ausfall einer Platte ich keinen Zugriff mehr auf die anderen Platten habe. Deswegen suche ich ein anderes Dateisystem. Wäre glusterfs ähnlich leicht zu handhaben oder gibt es Alternativen ?
Danke schonmal
Re: Empfehlung Dateisystem
BTW. Ich laß neulich darüber dass es am sinnvollsten für alle Softwarebasierten RAID-Lösungen ist ECC-RAM zu verwenden. Der ist zwar etwas teuerer als der normale und nicht alle Boards unterstützen ihn, jedoch würde ich (falls möglich) immer nur ECC-RAM für Storages verwenden. Deswegen verwende ich Beispielsweise auch keine BilligschrottNAS-Systeme mit mehr als 2 Festplatten (RAID 1) und/oder CRC-Prüfsummen für Dateien, da diese mit nicht-ECC-RAM eher fehlerhaft sein können als mit ECC.
Bei ZFS würde ich niemals mit normalem RAM hantieren, bei BTRFS soll es angeblich nicht nötig sein. Ich würds wie gesagt nicht riskieren...
Bei ZFS würde ich niemals mit normalem RAM hantieren, bei BTRFS soll es angeblich nicht nötig sein. Ich würds wie gesagt nicht riskieren...
Georg
RTFM, LMGTFY, Orakel... Ach... Warum muss man suchen...
Schrödingers Backup --- "Der Zustand eines Backups ist unbekannt, solange man es nicht wiederherstellt" --- Quelle: Nixcraft
RTFM, LMGTFY, Orakel... Ach... Warum muss man suchen...
Schrödingers Backup --- "Der Zustand eines Backups ist unbekannt, solange man es nicht wiederherstellt" --- Quelle: Nixcraft
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: Empfehlung Dateisystem
ZFS ohne ECC ist nicht schlechter als andere datensysteme ohne ECC.
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
- schorsch_76
- Beiträge: 2559
- Registriert: 06.11.2007 16:00:42
- Lizenz eigener Beiträge: MIT Lizenz
Re: Empfehlung Dateisystem
Zu btrfs
http://blog.fefe.de/?q=btrfs
Meine klare Empfehlung ext4, lvm und drunter nach Bedarf mdadm.
http://blog.fefe.de/?q=btrfs
Meine klare Empfehlung ext4, lvm und drunter nach Bedarf mdadm.
Re: Empfehlung Dateisystem
Danke erstmal für eure zahlreichen Antworten. Wie schon eingangs erwähnt möchte ich kein LVM nutzen. Btrfs mit raid5 wie es hier vorgeschlagen worden ist läuft jetzt seid 2 Tagen ununterbrochen keine Fehler bis dato festzustellen selbst bei einem simulierten Ausfall einer Platte kam ich noch an meine anderen Daten dran. Snapraid sieht auf dem ersten Blick auch passend aus. Ich werde das mal auf einem zweiten Testsystem versuchen. In erster Linie möchte ich gerne meine Festplattensammlung reduzieren damit auch die Backups einfacher und zentralisiert werden.
Re: Empfehlung Dateisystem
In keinen Server gehört non-ECC RAM, völlig egal welche aufgaben er erfüllt... Idealerweise nutzt man auch gleich regECC, für Vollbestückung ist das ohnehin fast immer Voraussetzung.gbotti hat geschrieben: Bei ZFS würde ich niemals mit normalem RAM hantieren, bei BTRFS soll es angeblich nicht nötig sein
Wenn unterstützt, nutze ich auch auf Desktops mittlerweile nur noch ECC. Der Preisunterschied ist nur noch marginal und die Zeit- und Nervenersparnis wg. defektem/schrottigem Consumer-RAM ist unbezahlbar...
BTRFS würde ich nichtmal in die Nähe von ansatzweise wichtigen Daten lassen. ZFS und gut is - das wurde von beginn an auf "production ready" im enterprisebereich entwickelt, nicht wie BTRFS: "wir basteln mal eben ein neues FS, stabil und sicher machen wir es später". Auf Betriebssystemen bei denen ZFS ein "first class FS" ist (illumos, FreeBSD), ist die Integration ins system und viele systemtools hervorragend, was vieles vereinfacht und noch viel mehr überhaupt erst ermöglicht. Unter Linux ist das eher ein ziemliches patchwork.
Größte Schwachstelle ist nach wie vor GRUB - der fliegt ständig in die luft bzw mit ZFS noch öfter als sowieso schon. Ich habe noch ein einzelnes system mit debian und ZFS laufen - im schnitt bei jedem zweiten kernelupdate oder änderung der Plattenkonfiguration kann GRUB das system nicht mehr booten. Dem BSD loader ist komplett wurscht wo und wie die platten am system hängen - solang genug da sind um den pool zu aktivieren wird gebootet. Auf storagesystemen sollte man zudem den storagepool separat vom pool bzw den Platten fürs OS halten, das macht Migrationen wesentlich einfacher.
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: Empfehlung Dateisystem
Gerade vor ein paar Tagen die Prise fuer microATX mainboards fuer ein Intel Pentium angeguckt das auch HDMI/DP out hat. Ohne ECC kann man ein gutes fuer ~80 EUR bekommen, mit ECC konnte ich welche ab 220 EUR finden. Ist jetzt nicht gerade Marginal. Ram preise dann garnicht mehr angeguckt.r4pt0r hat geschrieben: In keinen Server gehört non-ECC RAM, völlig egal welche aufgaben er erfüllt... Idealerweise nutzt man auch gleich regECC, für Vollbestückung ist das ohnehin fast immer Voraussetzung.
Wenn unterstützt, nutze ich auch auf Desktops mittlerweile nur noch ECC. Der Preisunterschied ist nur noch marginal und die Zeit- und Nervenersparnis wg. defektem/schrottigem Consumer-RAM ist unbezahlbar...
Durch lesen von anderen Diskussionen habe ich mir sagen lassen das es wahrscheinlicher ist das man selber was loescht, als das ein bit flip eine Datei komplett unleserlich macht.
Wie siehst du das? Wie oft passiert es dir?
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
Re: Empfehlung Dateisystem
Pentium und HDMI hat nix mit Server am hutLord_Carlos hat geschrieben: Intel Pentium angeguckt das auch HDMI/DP
Die neuen Xeon D von Supermicro fangen bei <400 eur für die 2-kern Varianten an (1508). Da hat man dann sogar bereits 2x 10GBit onboard im SoC bei 25W TDP und ein vollwertiges IPMI. ASRock kommt mit noch günstigeren Varianten, ohne IPMI und ASRock-typisch eben mit billigkomponenten und vermutlich auch kaputtem UEFI
Sobald die neuen Atom C3000 kommen dürften die preislich noch etwas drunter liegen, bzw die C2xxx werden noch weiter im preis fallen (sind aber auch ziemliche krücken...).
8GB regECC DDR4-2133 RAM gibts für ~75EUR (Kingston Value), vergleichbarer non-ECC kostet gerade mal 10EUR weniger.
Für <500 EUR (exkl. platten) kann man also schon ne anständige plattform bekommen die wirklich für serverbetrieb konzipiert und geeignet ist. Da braucht man nicht lange mit Desktophardware rumbasteln. Hab das selber leider lange genug für meine Heimserver gemacht und unterm strich meistens mehr draufgezahlt. Bei Gehäusen für storagesysteme kann ich auch nur noch empfehlen nach gebrauchten servergehäusen ausschau zu halten - das ist immer noch zuverlässiger und günstiger als irgendwelche 5.25" Wechselgehäuse. Zudem ist es einfacher ein Servergehäuse, das schon einen sehr optimierten Luftstrom hat, leise zu bekommen als ein umfunktioniertes Desktopgehäuse das plötzlich die Abwärme von 8...14...20... Platten wegschaffen muss... (Bei mir läuft auch noch so eine "jugendsünde" )
Festplatten sterben und geben auch falsche daten zurück, speziell wenn daten sehr lange nicht gelesen/geschrieben wurden - da hat ZFS schon mehrfach angeschlagen bevor z.b. bei SATA irgend ein SMART-Wert auffällig gewesen wäre. Meistens reicht es dann die platte mit random i/o zu "thrashen" um fehler zu frovozieren oder sogar endgültig ins jenseits zu befördern.Durch lesen von anderen Diskussionen habe ich mir sagen lassen das es wahrscheinlicher ist das man selber was loescht, als das ein bit flip eine Datei komplett unleserlich macht.
Wie siehst du das? Wie oft passiert es dir?
Mit ZFS lasse ich von entsprechenden datasets (z.b. /usr/home) 10-minütig snapshots erstellen mit Vorhaltezeiten um ~3h (+ längere/long-term snapshots für backup / replication). Dadurch konnte ich schon oft daten die durch dicke user-finger gelöscht oder überschrieben wurden wiederherstellen (über verstecktes .zfs-verzeichniss, da brauchts nichtmal nen rollback). Auch ein cryptlocker-verseuchter client der nen netzwerkshare verschlüsseln wollte konnte aufgehalten werden bzw der letzte snapshot wurde zurückgeholt. Seitdem lasse ich überwachen ob das delta zwischen zwei snapshots einen zu großen anteil der gesamtgröße ausmacht. Dann wird der vorherige snapshot geklont, readonly gemountet und der vermeintlich kompromittierte snapshot bleibt zur analyse erhalten, den kann ich ggf zurückholen oder einfach löschen...
Re: Empfehlung Dateisystem
Hallo zusammen,
im Moment ist ein Serverboard mit reg-ECC wie Kanonen auf Spatzen schießen. Es sind keine wichtigen Daten die im NAS verteilt werden Hauptsächlich Musik, Serien und Musikvideos. Also, nichts was man vermissen würde wenn mal eine Platte seinen Dienst versagt Zumal es ja auch noch Backups gibt. Da ich noch Hardware hatte, die ehh hier langsam verstaubt, wollte ich mich mal an das Projekt heranwagen. Zumal das NAS auch nur und einen Teil für die Hausautomation darstellt.
im Moment ist ein Serverboard mit reg-ECC wie Kanonen auf Spatzen schießen. Es sind keine wichtigen Daten die im NAS verteilt werden Hauptsächlich Musik, Serien und Musikvideos. Also, nichts was man vermissen würde wenn mal eine Platte seinen Dienst versagt Zumal es ja auch noch Backups gibt. Da ich noch Hardware hatte, die ehh hier langsam verstaubt, wollte ich mich mal an das Projekt heranwagen. Zumal das NAS auch nur und einen Teil für die Hausautomation darstellt.
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Empfehlung Dateisystem
Weil grub angeblich so kaputt und instabil wäre...
Nun, ich nutze nun seit ein paar Monaten die Fähigkeiten des Linux-Kernels, sie mit UEFI selbst zu booten...
Grub hab ich zwar noch installiert, aber das fliegt bald von der Platte.
Lg scientific
Nun, ich nutze nun seit ein paar Monaten die Fähigkeiten des Linux-Kernels, sie mit UEFI selbst zu booten...
Grub hab ich zwar noch installiert, aber das fliegt bald von der Platte.
Lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
- Maik aus MS
- Beiträge: 596
- Registriert: 19.08.2005 17:01:19
- Wohnort: Greven
-
Kontaktdaten:
Re: Empfehlung Dateisystem
Bei mir habe ich es so geloest. BS auf SSD mit ext4. Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.
Die Datenplatten haben BTRFS. Habe dadurch jeweils 2 Platten zu einer Verbunden. Aber auch BTRFS verteilt die Daten so
das in einem Plattenausfall die Daten futsch sind. Also wenn wie gefordert die Platten immer ganze Dateien enthalten sollen
dann muss man es anders machen. Z.B. Platte1 - Musik, Platte2 - Video usw.
Maik
Die Datenplatten haben BTRFS. Habe dadurch jeweils 2 Platten zu einer Verbunden. Aber auch BTRFS verteilt die Daten so
das in einem Plattenausfall die Daten futsch sind. Also wenn wie gefordert die Platten immer ganze Dateien enthalten sollen
dann muss man es anders machen. Z.B. Platte1 - Musik, Platte2 - Video usw.
Maik
Die mich kennen mögen mich.
Die mich nicht mögen können mich.
Die mich nicht mögen können mich.
- DEBIANUNDANDREAS
- Beiträge: 1304
- Registriert: 01.06.2013 10:37:46
Re: Empfehlung Dateisystem
Hallo ich nutze für ubuntuserver 16.04.2 ext 4, immer nur ext4 das ist ausgereift und kein Dateisystemexot wie btrfs.
Re: Empfehlung Dateisystem
Maik aus MS hat geschrieben: Aber auch BTRFS verteilt die Daten so
das in einem Plattenausfall die Daten futsch sind.
Ups, hatte ich oben erwähnt, mir in der Brisanz gar nicht bewußt geworden
Ein mehr-device-btrfs OHNE explizite Option für raid[1|5] entspricht einem hochgefährdeten raid0.rendegast hat geschrieben: Test mit loops,
wird kein '-d raid[1|5] -m raid[1|5]' angegeben,
so wird ein "single"-Data erstellt.
-->> Schalte ich vom Verbund 1 ab, bekomme ich das System nicht mehr gemountet.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Empfehlung Dateisystem
Das kann einem ganz schnell das Wochenende retten. Hier läuft z.B. ein älteres gatewaysystem auf Intel S5000 Basis, das nicht so 100%ig dem PCIe-hotplug Standard folgt. Freitag Nachmittag noch ein Upgrade durchgeführt bei dem auch Code für PCIe-HP aktualisiert und HP per default aktiviert wurde ->system crashte beim booten und startete sofort neu (endlosschleife).Maik aus MS hat geschrieben:Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.
Dank Bootenvironments lief das System nach wenigen Minuten wieder mit Stand vor dem Update (nur OS, userdaten liegen ja nicht auf BE-relevanten datasets), die User haben mir nicht mehr die Ohren vollgejammert und ich konnte in aller ruhe noch kurz über die crashdumps schauen und dann ins Wochenende - das BE mit dem aktualisierten system (und crashdumps) konnte ich dann am Montag analysieren und mit deaktiviertem HP läuft das System seither anstandslos...
Mit BEs kann man größere upgrades auch anderst herum angehen: BE erstellen, in diesen datasets die updates installieren während das system weiterhin im normalen Betrieb weiterläuft, ggf noch configdaten überprüfen/anpassen, BE für nächsten start aktivieren und system neu starten. Hat man eine angepasste Kernelkonfiguration kann man den neuen Kernel im neuen BE auch gleich vorab bauen - im Endeffekt ist die Downtime dann selbst bei sehr umfangreichen updates nur ein einziger Neustart. Ist doch was schiefgelaufen lädt man das alte BE und kann dann ohne Zeitdruck analysieren was nicht passt...
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Empfehlung Dateisystem
Sorry für die blöde Frage... Bootenvironment? Ich hab mal gegooglet und das im Zusammenhang mit BSD gefunden.r4pt0r hat geschrieben:Das kann einem ganz schnell das Wochenende retten. Hier läuft z.B. ein älteres gatewaysystem auf Intel S5000 Basis, das nicht so 100%ig dem PCIe-hotplug Standard folgt. Freitag Nachmittag noch ein Upgrade durchgeführt bei dem auch Code für PCIe-HP aktualisiert und HP per default aktiviert wurde ->system crashte beim booten und startete sofort neu (endlosschleife).Maik aus MS hat geschrieben:Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.
Dank Bootenvironments lief das System nach wenigen Minuten wieder mit Stand vor dem Update (nur OS, userdaten liegen ja nicht auf BE-relevanten datasets), die User haben mir nicht mehr die Ohren vollgejammert und ich konnte in aller ruhe noch kurz über die crashdumps schauen und dann ins Wochenende - das BE mit dem aktualisierten system (und crashdumps) konnte ich dann am Montag analysieren und mit deaktiviertem HP läuft das System seither anstandslos...
Mit BEs kann man größere upgrades auch anderst herum angehen: BE erstellen, in diesen datasets die updates installieren während das system weiterhin im normalen Betrieb weiterläuft, ggf noch configdaten überprüfen/anpassen, BE für nächsten start aktivieren und system neu starten. Hat man eine angepasste Kernelkonfiguration kann man den neuen Kernel im neuen BE auch gleich vorab bauen - im Endeffekt ist die Downtime dann selbst bei sehr umfangreichen updates nur ein einziger Neustart. Ist doch was schiefgelaufen lädt man das alte BE und kann dann ohne Zeitdruck analysieren was nicht passt...
Ist das auch unter Linux vorhanden?
lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Empfehlung Dateisystem
Sorry, ich dachte ich hatte das eingangs erwähnt - es handelt sich um FreeBSD systeme. Ich habe mal angefangen/versucht etwas ähnliches mit einem devuan/ZFS system zu bauen, aber da debian bzw linux allgemein systemdaten relativ wild im dateisystem verteilt ist das doch recht umständlich bzw nicht im selben Umfang möglich. BSD hat hier einfach eine _sehr_ saubere trennung von systemdaten, konfiguration, laufzeitdaten und userdaten, die das konzept von BEs begünstigt bzw erst ermöglicht.
Mit etwas Aufwand und Aufräumarbeiten wäre sowas theoretisch auch unter linux mit ZFS möglich - dann bleibt aber immer noch der Kropf namens GRUB der ja schon mit 'einfachem' ZFS oft Schwierigkeiten macht. Dem auch noch das Konzept von BootEnvironments beizubringen endet wohl eher im chaos (u.a. deshalb wurde auch bei illumos GRUB rausgeworfen und der BSD-Loader portiert).
Grundsätzlich kann man aber auch manuell einen snapshot vom gesamten Pool erstellen bevor man ein größeres update durchführt. Man kann dann in grub einfach das '@snapshotname' anhängen um in den snapshot zu booten. Änderungen an userdaten werden dabei natürlich auch zurückgesetzt bzw man müsste die entsprechenden datasets ggf manuell in der neueren variante mounten oder einzelne dateien aus .zfs/snapshot kopieren. (overlay-mounts sollte man dabei erfahrungsgemäß unter linux aber vermeiden, das Konzept ist hier irgendwie nicht ganz fertiggedacht worden und funktioniert nicht wirklich)
Mit etwas Aufwand und Aufräumarbeiten wäre sowas theoretisch auch unter linux mit ZFS möglich - dann bleibt aber immer noch der Kropf namens GRUB der ja schon mit 'einfachem' ZFS oft Schwierigkeiten macht. Dem auch noch das Konzept von BootEnvironments beizubringen endet wohl eher im chaos (u.a. deshalb wurde auch bei illumos GRUB rausgeworfen und der BSD-Loader portiert).
Grundsätzlich kann man aber auch manuell einen snapshot vom gesamten Pool erstellen bevor man ein größeres update durchführt. Man kann dann in grub einfach das '@snapshotname' anhängen um in den snapshot zu booten. Änderungen an userdaten werden dabei natürlich auch zurückgesetzt bzw man müsste die entsprechenden datasets ggf manuell in der neueren variante mounten oder einzelne dateien aus .zfs/snapshot kopieren. (overlay-mounts sollte man dabei erfahrungsgemäß unter linux aber vermeiden, das Konzept ist hier irgendwie nicht ganz fertiggedacht worden und funktioniert nicht wirklich)