neue Platte, ext4 oder btrfs?

[ren22]

Hallo,

eine neue, zusätzliche (/dev/sdb) Platte soll ins System mit nur einer Partition, ich bin am überlegen was besser wäre als Dateisystem für Dateien aller Art von 0-bytes bis xyz-GB auf einem 8.5 Debian System mit 4.8x Kernel.
BTRFS oder doch lieber EXT4 ? Wie würde eure Wahl aussehen.

Danke

[sbruder]

eine neue, zusätzliche (/dev/sdb) Platte soll ins System mit nur einer Partition, ich bin am überlegen was besser wäre als Dateisystem für Dateien aller Art von 0-bytes bis xyz-GB auf einem 8.5 Debian System mit 4.8x Kernel.
BTRFS oder doch lieber EXT4 ? Wie würde eure Wahl aussehen.

Ich würde ext4 oder xfs nehmen, weil ich btrfs noch nicht ganz traue. XFS halt nur, wenn genug RAM da ist.
Um snapshots benutzen zu können gibt es ja noch lvm und für raid ganz normales MD-RAID, was (zumindest jetzt) noch stabiler ist. Wenn Du btrfs nehmen willst, musst Du halt immer im Klaren sein, dass manche Funktionen noch relativ unerprobt sind.

[smutbert]

Snapshots mit lvm und einem „normalen“ Dateisystem (jfs, ext3, ext4, xfs,…) würd ich mir nicht mehr antun, das funktioniert bei btrfs (und natürlich zfs) um so vieles eleganter und ohne Performance-Einbußen, dass es verglichen mit lvm eine Freude ist. Ähnliches gilt für RAID.

Wenn man Snapshots, (Sub)Volumes und RAID nicht braucht oder will, dann bliebe bei btrfs der Vorteil der Prüfsummen, mit denen (Lese)Fehler oder aus anderem Grund verfälschte Daten erkannt werden (soweit es halt möglich ist).

Mich überzeugt btrfs jedenfalls seit Jahren und Probleme hat es bei mir schon sehr lange keine mehr verursacht (ganz am Anfang hatte ich ein paar Schwierigkeiten mit Images von virtuellen Maschinen, aber das ist einige Jahre und viele Kernelversionen her). Das soll aber natürlich nicht heißen, dass es nicht trotzdem noch Fehler geben könnte und es gibt auch greifbare Nachteile, wie zB die Tatsache, dass keine sparse-Files (Dateien mit „Löchern“), also etwa keine swap-Dateien unterstützt werden.

[scientific]

Bis Kernel 4.6 hatte ich mit btrfs send|btrfs receive auf der externen Platte immer wieder Probleme. Im Endeffekt konnte ich diese dann mit balance und scrub wieder beheben. btrfs check rühr ich nie mehr an.

Jetzt bin ich bei Kernel 4.9. Keine Probleme mehr mit btrfs.

Lg scientific

[wanne]

Prinzipiell ist ext4 oder xfs halt performanter. btrfs hat dafür halt tolle features wie snapshots (toll für backups), subvolumes (damit kannst du beispiesweise /var/log eine maximale Größe geben) und transparente Kompression.
Von btrfs-RAIDs würde ich noch die Finger lassen. Beta und langsam. Da würde ich besser bei mdraid bleiben.

[BenutzerGa4gooPh]

Hatte mal mit OpenSuse rumprobiert. Auf meinem Multibootsystem stießen mich die vielen Subvolumes ab. Wegen Durchblick. Würde heute auch noch so sein.
Singlebootsystem oder extra Platte? Nur zu!
OpenSuse nutzt es schon lange und wenn man in entsprechenden Foren liest, haben die Privatnutzer keine Probleme. Jedenfalls nicht mit btrfs.
Eher weitreichende Vorteile durch Snapshots.
https://kofler.info/opensuse-13-2-ausprobiert/

Irgendwie erinnere ich mich, dass manche "klassischen" Befehle (parted -l?) mit btrfs Probleme hatten (haben)?! Hhhmmm... Muss man sich mit speziellen btrfs-Kommandos beschäftigen. Oder YAST benutzen. Duck und wech.

[scientific]

Hatte mal mit OpenSuse rumprobiert. Auf meinem Multibootsystem stießen mich die vielen Subvolumes ab. Wegen Durchblick. Würde heute auch noch so sein.
Singlebootsystem oder extra Platte? Nur zu!
OpenSuse nutzt es schon lange und wenn man in entsprechenden Foren liest, haben die Privatnutzer keine Probleme. Jedenfalls nicht mit btrfs.
Eher weitreichende Vorteile durch Snapshots.
https://kofler.info/opensuse-13-2-ausprobiert/

Irgendwie erinnere ich mich, dass manche "klassischen" Befehle (parted -l?) mit btrfs Probleme hatten (haben)?! Hhhmmm... Muss man sich mit speziellen btrfs-Kommandos beschäftigen. Oder YAST benutzen. Duck und wech.

Ich las mal eine gute Einführung in snapper von SuSE, wo die vielen Subvolumes erklärt wurden... Die haben sich dabei schon etwas gedacht, und ich hab das Konzept auch so ähnlich für mein BTRFS-Backup-Tool übernommen.

Der Grund der vielen Subvolumes ist folgender:
Wenn ich heute einen Mailserver, einen Webserver und ähnliche Services laufen habe, die immer "auf Stand" sein müssen, oder auch nur das Home-Verzeichnis, welches auch aktuell bleiben soll, und ich setze mein System auf einen früheren Zeitpunkt zurück, dann würde ich all diese Daten verlieren... Durch die gezielt ausgewählten Subvolumes, die extra gemountet werden, kann ich mein System zurücksetzen, indem ich in einen älteren Snapshot boote. Die Subvolumes werden aus dem aktuell gehaltenen Subvolume-Subvolume (die sind in einem extra Subvolume neben dem, wo die Snapshots des Systems leben) gemountet und bleiben damit auf aktuellem Stand. Eine misslungene Systemaktualisierung kann damit zurückgerollt werden, und eventuell in der Zwischenzeit abgerufene Emails gehen nicht verloren oder müssen nicht mühsam gesucht und kopiert werden.

Je einfacher es für den User/Admin sein soll, umso mehr muss man sich im Vorfeld Gedanken machen.

lg scientific

[BenutzerGa4gooPh]

Danke scientific, für die Erklärungen.
Snapshots sind eigentlich kein Ersatz für Backups. In Firmen dauert eine (Band-)Ruecksicherung sehr lange, privat eher nicht. Hhmm, nun doch kein so großer Vorteil für Privatpersonen - im Gegensatz zu Firmen/Serverbetreibern? Die Häufigkeit/Aktualität der privaten Sicherungen könnte mit btrfs vlt. etwas verringert werden?

[scientific]

Snapshots sind in der Tat kein Ersatz für Backups. Denn die Snapshots bei btrfs sind wie jene mit rsnapshot(rsync) so ähnlich wie Hardlinks... und wenn eine Datei in 1000 Snapshots vorhanden ist und sich nie geändert hat, dann ist sie genau 1x auf der Platte. Geht die Platte an genau dieser Stelle kaputt, ist die Datei meier. Und alle 1000 Snapshots davon ebenfalls.

Aber Btrfs-Snapshots stellen eine super Grundlage für Backups dar. Wenn ich eine Backupstrategie habe, dass ich täglich auf eine andere Platte sichere, 7x die Woche, so ist das zu übertragende Datenvolumen pro Sicherung sehr gering. Und das alle 8 Platten kaputt gehen ist doch eher unwahrscheinlich (außer natürlich im Brandfalle, Wasserschaden, Erdbeben, Diebstahl...).

Die Snapshots mit btrfs am Lokalen Rechner erlauben aber eine wunderbare Datenwiederherstellung, wenn man mal versehentlich etwas löscht, falsch abspeichert oder wenn eben gar ein Systemupgrade fehlgeschlagen ist.

In meiner Backup-Suite (mkbackup-btrfs) hab ich die Möglichkeit, dass ich per Gnome-Shell-Extension die Intervalle (10-minütig, stündlich, täglich, wöchentlich, monatlich, jährlich, nach dem Boot, nach dem Einstecken der externen Platte) mit einem Klick (de)aktivieren kann. Auf einer SSD sind die Snapshots auch so gut wie unspürbar schnell erstellt.
Außerdem kann ich im Konfigfile noch angeben, welche dieser Intervall-Snapshots auf die externe Platte übertragen werden (so eingesteckt), und welche nur lokal erstellt werden.

Die 10-minütigen Snapshots z.B. bleiben nur lokal. Wenn ich mal viele Daten zu bearbeiten habe (z.B. meine Fotos wieder einmal sortiere, herumschiebe und beschrifte - mit digikam), aktiviere ich die 10-minütigen Snapshots. So geht mir maximal 10 Minuten meiner Arbeit verloren, sollte ich aus versehen etwas löschen oder falsch verschieben. Hab ich die Arbeit beendet, deaktiviere ich über die Shell-Extension die 10-minütigen Snapshots wieder.

Außerdem wird vor jedem Systemupgrade ein Snapshot nur des System-Subvolumes gemacht (home, /var/spool... und die anderen Verzeichnisse/Subvolumes sind davon ja unabhängig). Das geht sehr flott (auch auf einer HDD) - und der Snapshot bleibt lokal am Rechner. Stündlich werden die Snapshots ohnehin auf die externe Platte geschoben.

Was mir noch fehlt ist eine komfortable Funktion, um in einem Verzeichnis einfach in die Vergangenheit zu hüpfen und dann von dort aus die Datei wieder herzustellen.

lg scientific

[Colttt]

@scientific: klingt interessant, kannst du da mal ein volume-bespiel für nen mailserver posten?

[scientific]

Ich habe folgende Verzeichnisse in __ALWAYSCURRENT__ als Subvolumes angelegt.
Die Schreibweise der Subvolumes hab ich an jene für systemd angelehnt.

Code: Alles auswählen

SUBS="boot-grub-x86_64-efi home opt srv subs usr-local var-cache var-lib-mpd var-lib-named var-log var-opt var-spool var-spool-dovecot var-tmp var-virutal_machines var-www"

Kannst du damit was anfangen?

lg scientific