Discussion:
Vorteile von Ext4 bei externer festplatte?
Add Reply
Thomas Lichter
2024-10-15 23:04:15 UTC
Antworten
Permalink
Hallo NG!

Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.

Da die Platte (4T) etwa 1T Daten enthält,die natürlich vorher gesichert
werden müssten, ein nicht ganz unerheblicher Aufwand.

Hat einer/eine von Euch damit Erfahrung? Gibt es dadurch tatsächlich
messbare Geschwindigkeits- oder andere Vorteile?

Vielen Dank für Eure Hinweise und Tipps!

Gruß

Thomas
Marc Haber
2024-10-16 05:56:47 UTC
Antworten
Permalink
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Da die Platte (4T) etwa 1T Daten enthält,die natürlich vorher gesichert
werden müssten, ein nicht ganz unerheblicher Aufwand.
Hat einer/eine von Euch damit Erfahrung? Gibt es dadurch tatsächlich
messbare Geschwindigkeits- oder andere Vorteile?
ext4 ist unter Linux einfach sicherer. NTFS ist nicht dokumentiert,
das musste alles reverse engineered werden. Ich würde NTFS unter Linux
nur im Notfall verwenden, aber das ist Baugefühl.

Wie gut funktoniert die Integration eines NTFS-Mediums in das
Unix-Rechtesystem?

Ich lese gerade dass Du die Platte an der Fritzbox hast. Das Risiko
"NTFS an Linux" hast Du also schon seit Jahren. Und langsamer als
"Rotierender Rost an Fritzbox" wird es auch nicht mehr.

Wie wäre es die Gelegenheit zu nutzen und die Platte durch etwas
größeres, zeitgemäßeres zu ersetzen? Die Platte hat doch bestimmt
schon einige Stunden auf der Uhr. 4 TB ist hier die kleinste Platte,
die noch da bleiben darf. alles kleinere fliegt direkt raus.
Andererseits kosten 8 TB neu auch schon über 120 Euro.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Hermann Riemann
2024-10-16 06:55:29 UTC
Antworten
Permalink
Post by Marc Haber
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Da die Platte (4T) etwa 1T Daten enthält,die natürlich vorher gesichert
werden müssten, ein nicht ganz unerheblicher Aufwand.
Hat einer/eine von Euch damit Erfahrung? Gibt es dadurch tatsächlich
messbare Geschwindigkeits- oder andere Vorteile?
ext4 ist unter Linux einfach sicherer. NTFS ist nicht dokumentiert,
das musste alles reverse engineered werden. Ich würde NTFS unter Linux
nur im Notfall verwenden, aber das ist Baugefühl.
NTFS ( oder FAT* außer bei efi boot) verwende ich nur für externe
Geräte, die darauf bestehen, und zum Transport bezüglich windows 11.
Post by Marc Haber
Wie gut funktoniert die Integration eines NTFS-Mediums in das
Unix-Rechtesystem?
Vermutlich muss root, group und users angepasst werden.
Also rekursiv mit chmod 644 bzw chmod 755 anpassen.
Post by Marc Haber
Ich lese gerade dass Du die Platte an der Fritzbox hast. Das Risiko
"NTFS an Linux" hast Du also schon seit Jahren. Und langsamer als
"Rotierender Rost an Fritzbox" wird es auch nicht mehr.
Ich müsste bei Samba nachschauen.
Bei NFS auf Synology,
bei Datentransfer zwischen Linux PCs
und bei Datensicherung verwende ich nur ext4
Post by Marc Haber
Wie wäre es die Gelegenheit zu nutzen und die Platte durch etwas
größeres, zeitgemäßeres zu ersetzen? Die Platte hat doch bestimmt
schon einige Stunden auf der Uhr. 4 TB ist hier die kleinste Platte,
die noch da bleiben darf. alles kleinere fliegt direkt raus.
Andererseits kosten 8 TB neu auch schon über 120 Euro.
Aber externe Platten > 5 TB
brauchen eigene Stromversorgung und brauchen daher mehr Strom.

Daher habe ich Platten > 5 TB nur innerhalb Desktop PCs
und für Datensicherung.

Hermann
immer noch von einer externen SSD Platte träumend,
die alle Installations USB-sticks ersetzt.
--
<http://www.hermann-riemann.de>
Claus Reibenstein
2024-10-16 14:39:15 UTC
Antworten
Permalink
Post by Hermann Riemann
Vermutlich muss root, group und users angepasst werden.
root kannst Du nicht anpassen, nur users, group und others.

Gruß
Claus
Marte Schwarz
2024-10-16 14:47:19 UTC
Antworten
Permalink
Hi Hermann,
Post by Thomas Lichter
Hat einer/eine von Euch damit Erfahrung? Gibt es dadurch tatsächlich
messbare Geschwindigkeits- oder andere Vorteile?
Als NAS-Platte an der FB würde ich da keine Vorteile an Geschwindigkeit
erhoffen, der Flaschenhals liegt in der FB.
   immer noch von einer externen SSD Platte träumend,
   die alle Installations USB-sticks ersetzt.
Was hält Dich auf? Multiboot-Umgebungen existieren. Seit ich mit Ventoy
arbeite fehlt mir nichts. Ich hab alles auf einem 128 GB-Stick.

Marte
Sieghard Schicktanz
2024-10-16 18:18:14 UTC
Antworten
Permalink
Hallo Marc,
Post by Marc Haber
ext4 ist unter Linux einfach sicherer. NTFS ist nicht dokumentiert,
Funktioniert aber trotzdem recht gut, solange keine gröberen Fehler
auftreten. Dann muß doch ein Windows zur Reparatur ran.
...
Post by Marc Haber
Wie gut funktoniert die Integration eines NTFS-Mediums in das
Unix-Rechtesystem?
Garnicht. Da wird alles nach mount-Einstellungen auf einen festen Benutzer
mit festen Rechten gemappt. Bei manuellem mount von root also für den.
Post by Marc Haber
Ich lese gerade dass Du die Platte an der Fritzbox hast. Das Risiko
"NTFS an Linux" hast Du also schon seit Jahren. Und langsamer als
Wundert mich eh, daß das überhaupt so einfach geht - die Fritz-Boxen laufen
ja unter einem Linux. Das macht aber eher nichts, weil die ja sowieso
mounts nur per cifs exportieren, und da geht die Rechteverwaltung sowieso
"den Bach runter".

...
Post by Marc Haber
Wie wäre es die Gelegenheit zu nutzen und die Platte durch etwas
größeres, zeitgemäßeres zu ersetzen? Die Platte hat doch bestimmt
NOCH größer? Er hat da doch eh bloß ein Viertel belegt.
Post by Marc Haber
schon einige Stunden auf der Uhr. 4 TB ist hier die kleinste Platte,
die noch da bleiben darf. alles kleinere fliegt direkt raus.
Na, da bin ich ja quasi "digitaler Schmalhans im Extrem", ich hab' jetzt so
anderthalb Tera _insgesamt_ in Benutzung, und davon ist noch mindestens 50%
uralter Daten-Restmüll. Und das ist meine Arbeitsmaschin zur Programmierung
auch für Kunden - halt nur Steuerungsanwendungen für Mikrocontroller und
"embedded systems".
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Marc Haber
2024-10-17 05:28:26 UTC
Antworten
Permalink
Post by Sieghard Schicktanz
Post by Marc Haber
ext4 ist unter Linux einfach sicherer. NTFS ist nicht dokumentiert,
Funktioniert aber trotzdem recht gut, solange keine gröberen Fehler
auftreten. Dann muß doch ein Windows zur Reparatur ran.
=> Tonne.
Post by Sieghard Schicktanz
Post by Marc Haber
Wie gut funktoniert die Integration eines NTFS-Mediums in das
Unix-Rechtesystem?
Garnicht. Da wird alles nach mount-Einstellungen auf einen festen Benutzer
mit festen Rechten gemappt. Bei manuellem mount von root also für den.
=> Nicht ernstzunehmen. => Tonne. Kann man gleich FAT nehmen.
Post by Sieghard Schicktanz
Post by Marc Haber
Ich lese gerade dass Du die Platte an der Fritzbox hast. Das Risiko
"NTFS an Linux" hast Du also schon seit Jahren. Und langsamer als
Wundert mich eh, daß das überhaupt so einfach geht - die Fritz-Boxen laufen
ja unter einem Linux. Das macht aber eher nichts, weil die ja sowieso
mounts nur per cifs exportieren, und da geht die Rechteverwaltung sowieso
"den Bach runter".
Das stimmt freilich. Aber warum dann das NTFS-Risiko eingehen?
Post by Sieghard Schicktanz
Post by Marc Haber
Wie wäre es die Gelegenheit zu nutzen und die Platte durch etwas
größeres, zeitgemäßeres zu ersetzen? Die Platte hat doch bestimmt
NOCH größer? Er hat da doch eh bloß ein Viertel belegt.
Das ist ein Argument.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Marcel Mueller
2024-10-17 06:25:03 UTC
Antworten
Permalink
Post by Sieghard Schicktanz
Wundert mich eh, daß das überhaupt so einfach geht - die Fritz-Boxen laufen
ja unter einem Linux. Das macht aber eher nichts, weil die ja sowieso
mounts nur per cifs exportieren, und da geht die Rechteverwaltung sowieso
"den Bach runter".
Nicht notwendigerweise. Samba kann schon lange Erweiterungen, um Rechte
über CIFS abzubilden. Die sind halt nur aktiv, wenn beide Endpunkte das
können. Es würde mich aber wundern, wen Fritzboxen das tun, denn dazu
bräuchte es ja erst mal die passende User- und Gruppenverwaltung.
Post by Sieghard Schicktanz
Post by Marc Haber
Wie wäre es die Gelegenheit zu nutzen und die Platte durch etwas
größeres, zeitgemäßeres zu ersetzen? Die Platte hat doch bestimmt
NOCH größer? Er hat da doch eh bloß ein Viertel belegt.
Ich würde auch die Finger von den großen Datengräbern lassen, wenn ich
sie nicht unbedingt brauche. Die Dinger unterbieten sich gegenseitig in
Zuverlässigkeit (uncorrectable errors) und Geschwindigkeit (SMR). Und ob
das Helium länger als ein paar Jahre in den ganzen Platten bleibt, weiß
auch noch keiner. Aus dem Labor weiß ich, dass Helium nur schwer
einzuhegen ist, weil es selbst durch Metalle durch kommt. Klassische
Dichtungen sowieso.
Post by Sieghard Schicktanz
Post by Marc Haber
schon einige Stunden auf der Uhr. 4 TB ist hier die kleinste Platte,
die noch da bleiben darf. alles kleinere fliegt direkt raus.
Na, da bin ich ja quasi "digitaler Schmalhans im Extrem", ich hab' jetzt so
anderthalb Tera _insgesamt_ in Benutzung, und davon ist noch mindestens 50%
uralter Daten-Restmüll.
Die größten hier sind auch "nur" 8TB. Und das sind schon die Backups von
2 Haushalten (wegen Off-Site wird immer mal getauscht). Und die sind
auch weit von voll entfernt. Selbst die Filmaufnahmen sind im Backup
schon mit dabei und wohl der größte Einzelposten.


Marcel
Ulli Horlacher
2024-10-16 06:17:31 UTC
Antworten
Permalink
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Das FritzOS ist zwar Linux-basiert, du hast da aber keinen shell oder gar
root Zugang. Du kannst nur das verwenden, was die FritzOS Weboberflaeche
anbietet. Ich wuerde daher bei AVM nachschauen was die empfehlen bzw was
moeglich ist.

Eher Augenmerk wuerde ich auf die Hardware lenken:

3.5 Zoll USB-Magnetfestplatten benoetigen ein extra Netzteil, die
Stromversorgung via USB reicht da nicht.

2.5 Zoll USB-Magnetfestplatten benoetigen zwar kein extra Netzteil, die
gibt es ab spaetestens ab 4 (2?) TB nur noch mit SMR Aufzeichnung, was sie
bei Schreiboperationen extrem langsam macht.

SSD sind stromsparend, schnell (lohnt sich nicht bei NAS, das Netz ist
langsamer) und teuer :-}
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marcel Mueller
2024-10-16 13:06:52 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Das FritzOS ist zwar Linux-basiert, du hast da aber keinen shell oder gar
root Zugang. Du kannst nur das verwenden, was die FritzOS Weboberflaeche
anbietet. Ich wuerde daher bei AVM nachschauen was die empfehlen bzw was
moeglich ist.
Es würde mich wundern, wenn FritzOS kein ext kann. Aber dabei stellen
sich ja noch weitere Fragen. Unter welchen User erfolgt der Zugriff?

Ext verwendet intern ausschließlich uid/gid. Wenn man damit Daten von
einem Rechner zum anderen schafft. passieren oft lustige Dinge, wenn
deren Benutzeraccounts nicht übereinstimmen. Üblicherweise äußert sich
das darin dass man Dateien in bestimmten Verzeichnissen nicht anlegen
oder ändern kann. Das klappt also nur innerhalb eines Netzes gut, wo die
User-IDs überall gleich sind.

Keine Ahnung mit welcher uid/gid eine FB auf die Platte zugreift. Ich
vermute aber, das nur gelegentliche Anschließen einer Platte an eine FB
ist keine sinnvolle Option.
Ehrlich gesagt finde ich FBs auch kein sinnvolles NAS. Unter anderem
sind sie angeblich relativ langsam in der Disziplin.
Post by Ulli Horlacher
SSD sind stromsparend, schnell (lohnt sich nicht bei NAS, das Netz ist
langsamer) und teuer :-}
Das stimmt nicht. Aktuelle Festplatten verbringen über 90% ihrer
Nicht-Idle-Lebenszeit mit Daten suchen. Diese Zeit geht bei SSDs auf nahe 0.
Die lineare Übertragungsrate wird nur dann interessant, wenn man riesige
Dateien kopiert und kaum was fragmentiert ist (auch nicht der freie Platz).


Marcel
Rupert Haselbeck
2024-10-16 15:10:05 UTC
Antworten
Permalink
Post by Marcel Mueller
Post by Ulli Horlacher
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Das FritzOS ist zwar Linux-basiert, du hast da aber keinen shell oder gar
root Zugang. Du kannst nur das verwenden, was die FritzOS Weboberflaeche
anbietet. Ich wuerde daher bei AVM nachschauen was die empfehlen bzw was
moeglich ist.
Es würde mich wundern, wenn FritzOS kein ext kann.
Dann wirst du dich wundern müssen...
Ich hab gerade eben eine 1TB-SSD, frisch formatiert mit ext3 an eine
Fritzbox 7490 mit aktuellem OS (7.57) angestöpselt. Die Box meint dazu
"Das USB-Gerät enthält keinen Datenträger"

MfG
Rupert
Diedrich Ehlerding
2024-10-16 06:43:46 UTC
Antworten
Permalink
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Soll die POlatte denn weiter an der Fritzbox blieiben? Wenn ja: Kann
denn die Fritzbox inzwischen mit ext4 umgehen?

Ich habe das vor einiger Zeit, war aber noch Firmware 7.30, mal
probiert; da ging das nicht.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Diedrich Ehlerding
2024-10-16 06:50:01 UTC
Antworten
Permalink
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Soll die Platte denn weiter an der Fritzbox bleiben? Wenn ja: Kann
denn die Fritzbox inzwischen mit ext4 umgehen?

Ich habe das vor einiger Zeit, war aber noch Firmware 7.30, mal
probiert; da ging das nicht.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Hans Crauel
2024-10-17 00:32:26 UTC
Antworten
Permalink
Diedrich Ehlerding schrieb
Post by Diedrich Ehlerding
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Soll die Platte denn weiter an der Fritzbox bleiben? Wenn ja: Kann
denn die Fritzbox inzwischen mit ext4 umgehen?
Ich habe das vor einiger Zeit, war aber noch Firmware 7.30, mal
probiert; da ging das nicht.
AVM meint, dass 7590 mit ext4 klar käme, bei 7490 jedoch
nicht mehr als ext3 gingen (jeweils mit aktuellem 7.59):

<https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7590/26_USB-Speicher-an-FRITZ-Box-einrichten/>

<https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7490/26_USB-Speicher-an-FRITZ-Box-einrichten/>

Hans
Başar Alabay
2024-10-17 16:08:55 UTC
Antworten
Permalink
Post by Hans Crauel
Diedrich Ehlerding schrieb
Post by Diedrich Ehlerding
Post by Thomas Lichter
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Soll die Platte denn weiter an der Fritzbox bleiben? Wenn ja: Kann
denn die Fritzbox inzwischen mit ext4 umgehen?
Ich habe das vor einiger Zeit, war aber noch Firmware 7.30, mal
probiert; da ging das nicht.
AVM meint, dass 7590 mit ext4 klar käme, bei 7490 jedoch
<https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7590/26_USB-Speicher-an-FRITZ-Box-einrichten/>
Ja, die FB kann einiges. Aber eine kleine Erfahrung von mir war, daß der
Mediaserver (warum auch immer) nur mit FAT zuverlässig funktionierte.
Ich nutze zwar keine Platte/SSD, sondern nur einen (großen) USB-Stick,
aber das war schon auffällig.

Hat zwar nichts mit dem Thema zu tun, aber Technisat kann sogar mehr …
nämlich hfs+. Und auch da war FAT das zuverlässigste zum Aufnehmen.
Obwohl es mit FAT durchaus blöde Einschränkungen gibt.

Also, NAS hin, NAS her … das ist nicht so wirklich ausgegoren. Dann ggf.
ein dediziertes Gerät, das dann ext4 kann.

B. Alabay
Stefan Reuther
2024-10-16 14:50:17 UTC
Antworten
Permalink
Post by Thomas Lichter
Da die Platte (4T) etwa 1T Daten enthält,die natürlich vorher gesichert
werden müssten, ein nicht ganz unerheblicher Aufwand.
Hat einer/eine von Euch damit Erfahrung? Gibt es dadurch tatsächlich
messbare Geschwindigkeits- oder andere Vorteile?
Das Backup-Konzept für meinen Desktop-PC lautet: immer mal am
Grabbeltisch eine externe Platte mitnehmen, 'rsync' auf eine solche
Platte, immer durchrotieren. Manche Platten mit NTFS, manche mit ext4,
folglich hab ich da den direkten Vergleich:

NTFS vs. ext4 ist ein deutlicher Unterschied der Geschwindigkeit, 2-3h
vs. <1h, und auch ein deutlicher Unterschied in der Benutzbarkeit
während des Backups (beim Backup auf NTFS klemmt zwischendrin
gelegentlich mal die GUI).

Das wird vor allem dadurch verursacht, dass der NTFS-3g-Treiber mit FUSE
implementiert ist. Wenn du einen Kernel-NTFS-Treiber hast, dürfte es
deutlich besser funktionieren.


Stefan
Ulli Horlacher
2024-10-16 16:07:13 UTC
Antworten
Permalink
Post by Stefan Reuther
Das Backup-Konzept für meinen Desktop-PC lautet: immer mal am
Grabbeltisch eine externe Platte mitnehmen, 'rsync' auf eine solche
Platte
Dann ist die aber nicht boot-faehig, also hast du kein desaster-recovery.
Ok, "besser als nix", aber ich bervorzuge boot-faehige backups.
So hab ich dann innerhalb von Minuten mein System wieder am laufen.
Post by Stefan Reuther
immer durchrotieren.
Dann brauchst du fuer x backups auch x externe Platten (oder zumindest x
Partitionen).
Ich mach das ueber snapshots, so brauch ich nur eine externe Platte und
viel weniger Speicherplatz.

Fuer den GAU-Fall (Wohnungsbrand) sollte man allerdings ein backup
ausserhaus haben.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Stefan Reuther
2024-10-17 16:00:47 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Stefan Reuther
Das Backup-Konzept für meinen Desktop-PC lautet: immer mal am
Grabbeltisch eine externe Platte mitnehmen, 'rsync' auf eine solche
Platte
Dann ist die aber nicht boot-faehig, also hast du kein desaster-recovery.
Ok, "besser als nix", aber ich bervorzuge boot-faehige backups.
So hab ich dann innerhalb von Minuten mein System wieder am laufen.
Der erste Schritt nach dem Backup-Fall ist eh der Weg zum lokalen
Computerladen. Da kommt's auf die 20 Minuten für die Debian-Installation
dann auch nicht mehr an.

Note to self: endlich mal das Urlaubsgeld in neue Hardware umsetzen.
Post by Ulli Horlacher
Post by Stefan Reuther
immer durchrotieren.
Dann brauchst du fuer x backups auch x externe Platten (oder zumindest x
Partitionen).
Richtig.

Aber hätte ich das nicht, hätte ich nicht den Vergleich zwischen ext4
und NTFS, der hier gefragt war :)
Post by Ulli Horlacher
Ich mach das ueber snapshots, so brauch ich nur eine externe Platte und
viel weniger Speicherplatz.
Externe Platten sterben halt auch immer mal, und ansonsten bin ich bei
Filesystemen konservativ. Auch wenn es eine Weile her ist, aber ich hab
schon mit debugfs Daten zusammengeklaubt. Mit den Novelty-Dateisystemen
bring ich das nicht hin.


Stefan
Marcel Mueller
2024-10-17 17:58:22 UTC
Antworten
Permalink
Post by Stefan Reuther
Post by Ulli Horlacher
Dann ist die aber nicht boot-faehig, also hast du kein desaster-recovery.
Ok, "besser als nix", aber ich bervorzuge boot-faehige backups.
So hab ich dann innerhalb von Minuten mein System wieder am laufen.
Der erste Schritt nach dem Backup-Fall ist eh der Weg zum lokalen
Computerladen. Da kommt's auf die 20 Minuten für die Debian-Installation
dann auch nicht mehr an.
Die Nackte Installation ist kein Problem, aber bis ich alle Dienste
wieder zu meiner Zufriedenheit konfiguriert habe, vergeht dann doch ein
Vielfaches der Zeit. Ich scheue schon immer die Release-Upgrades aus
diesem Grund.
Post by Stefan Reuther
Note to self: endlich mal das Urlaubsgeld in neue Hardware umsetzen.
Wenn es denn notwendig ist.
Post by Stefan Reuther
Post by Ulli Horlacher
Ich mach das ueber snapshots, so brauch ich nur eine externe Platte und
viel weniger Speicherplatz.
Externe Platten sterben halt auch immer mal, und ansonsten bin ich bei
Filesystemen konservativ. Auch wenn es eine Weile her ist, aber ich hab
schon mit debugfs Daten zusammengeklaubt. Mit den Novelty-Dateisystemen
bring ich das nicht hin.
Da hatte ich bisher mit allen brauchbaren Dateisystemen bisher keine
größeren Probleme. Mindestens mal xfs, ext4 und früher HPFS und auch
NTFS haben sich allesamt bewährt. Und in über 30 Jahren ist auch schon
so einiges passiert. Unter Linux nutze ich natürlich nur die ersten
beiden.


Marcel
Ulli Horlacher
2024-10-17 22:22:35 UTC
Antworten
Permalink
Post by Marcel Mueller
Da hatte ich bisher mit allen brauchbaren Dateisystemen bisher keine
größeren Probleme. Mindestens mal xfs, ext4 und früher HPFS und auch
NTFS haben sich allesamt bewährt. Und in über 30 Jahren ist auch schon
so einiges passiert. Unter Linux nutze ich natürlich nur die ersten
beiden.
Damit verzichtest du auf Snapshots, der wichtigsten Neuentwicklung der
letzten 20 Jahre.
Snapshots haben mich mehr als nur einmal gerettet.
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
durchfuehrbar, weshalb man sie problemlos stuendlich machen kann.

Klar, snapshots ersetzen kein full-backup fuer den GAU-Fall, aber
fuer gut 95% aller recovery-Faelle sind sie DIE Loesung:
Versehentlich File oder Directory geloescht oder ueberschrieben.
Hab mir kuerzlich 1 TB Daten zerstoert durch einen Tippfehler mit rsync
--delete ...
Der snapshot restore war dann in 10 s erledigt.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Stefan Reuther
2024-10-18 15:25:16 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Marcel Mueller
Da hatte ich bisher mit allen brauchbaren Dateisystemen bisher keine
größeren Probleme. Mindestens mal xfs, ext4 und früher HPFS und auch
NTFS haben sich allesamt bewährt. Und in über 30 Jahren ist auch schon
so einiges passiert. Unter Linux nutze ich natürlich nur die ersten
beiden.
Damit verzichtest du auf Snapshots, der wichtigsten Neuentwicklung der
letzten 20 Jahre.
Snapshots haben mich mehr als nur einmal gerettet.
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
durchfuehrbar, weshalb man sie problemlos stuendlich machen kann.
Ein Snapshot auf Applikations-Ebene wäre ein git-Repository. Davon hab
ich hier Unmengen. (Und auch die krieg ich im Notfall mit einem
Hexeditor repariert.)
Post by Ulli Horlacher
Klar, snapshots ersetzen kein full-backup fuer den GAU-Fall, aber
Versehentlich File oder Directory geloescht oder ueberschrieben.
Passiert mir halt äußerst selten bis nie. Ich hab daher meine Workflows
so organisiert, dass die wichtigen Dinge in git- oder (historisch) CVS-
Repositories liegen. Arbeitsbereich auf dem neuen Rechner aufsetzen?
Home einhängen, Repo auschecken, ab geht's.

Und umräumen findet mit dem Midnight Commander statt, da gibt's bei
versehentlichem Überschreiben genug Warnungen.

Menschen sind halt verschieden.


Stefan
Ulli Horlacher
2024-10-19 10:34:12 UTC
Antworten
Permalink
Post by Stefan Reuther
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
durchfuehrbar, weshalb man sie problemlos stuendlich machen kann.
Ein Snapshot auf Applikations-Ebene wäre ein git-Repository.
git kommt mit GROSSEN (Binaer-Dateien) nicht zurecht, ausserdem benoetigt
es Unmengen an Speicherplatz weil file-basiert.
Wenn sich in einem 10 GB file auch nur 1 byte aendert, muss git die ganzen
10 GB kopieren. das kostet Zeit und Platz.
Ein Snapshot davon geht quasi in Nullzeit und verbraucht erstmal nur
wenige kB.
Post by Stefan Reuther
Post by Ulli Horlacher
Klar, snapshots ersetzen kein full-backup fuer den GAU-Fall, aber
Versehentlich File oder Directory geloescht oder ueberschrieben.
Passiert mir halt äußerst selten bis nie.
Nie was versehentlich geloescht oder ueberschrieben?
Was fuer Selbstbeherrschung! :-)
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Stefan Reuther
2024-10-20 08:57:25 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Stefan Reuther
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
durchfuehrbar, weshalb man sie problemlos stuendlich machen kann.
Ein Snapshot auf Applikations-Ebene wäre ein git-Repository.
git kommt mit GROSSEN (Binaer-Dateien) nicht zurecht, ausserdem benoetigt
es Unmengen an Speicherplatz weil file-basiert.
Wenn sich in einem 10 GB file auch nur 1 byte aendert, muss git die ganzen
10 GB kopieren. das kostet Zeit und Platz.
Ein Snapshot davon geht quasi in Nullzeit und verbraucht erstmal nur
wenige kB.
Den Anwendungsfall (in einer gigantischen Datei was ändern) gibt's bei
mir halt quasi nicht.

Dafür dedupliziert mir git die 500 Kopien der GPL weg, und 'git gc'
schafft es auch, große ähnliche Dateien als "Basis + Patch" auszudrücken.
Post by Ulli Horlacher
Post by Stefan Reuther
Post by Ulli Horlacher
Klar, snapshots ersetzen kein full-backup fuer den GAU-Fall, aber
Versehentlich File oder Directory geloescht oder ueberschrieben.
Passiert mir halt äußerst selten bis nie.
Nie was versehentlich geloescht oder ueberschrieben?
Was fuer Selbstbeherrschung! :-)
Selten genug, dass ich mich nicht dran erinnere.

Tools wie 'mc' helfen da, indem sie die Operationen sichtbar machen und
per Default Fragen stellen.


Stefan
Marcel Mueller
2024-10-18 16:12:01 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Marcel Mueller
Da hatte ich bisher mit allen brauchbaren Dateisystemen bisher keine
größeren Probleme. Mindestens mal xfs, ext4 und früher HPFS und auch
NTFS haben sich allesamt bewährt. Und in über 30 Jahren ist auch schon
so einiges passiert. Unter Linux nutze ich natürlich nur die ersten
beiden.
Damit verzichtest du auf Snapshots, der wichtigsten Neuentwicklung der
letzten 20 Jahre.
Ja, das war mir bisher noch kein btrfs-Experiment wert.

Außerdem hat btrfs noch immer das 4kB Limit bei den erweiterten
Attributen. Das nenne ich mal einen Anachronismus. Das gibt bei
einzelnen Dateien hässliche und nicht sinnvoll behandelbare Fehlermeldungen.
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Backup habe ich auch so. Und einen Snap muss man im entscheidenden
Moment auch erst mal vorher gemacht haben.
Post by Ulli Horlacher
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
durchfuehrbar, weshalb man sie problemlos stuendlich machen kann.
Rsnapshot läuft hier auf dem Server auch nur ein paar Minuten, wenn es
nicht gerade der erste Lauf ist, und da ist das Datengrab, was noch
nicht SSD ist, schon mit dabei. Da würde ich aber auch nicht wollen, das
einmal die Stunde die Spindel anläuft.
Früher mit DLT bzw. LTO hat das alles noch mehr weh getan.

Aber klar Snap ist immer schneller. Allerdings will ich auch da
üblicherweise nicht komplett zum alten Stand zurück, und vllt. die in
der Zeit eingetrudelten Mails verzichten, sondern muss doch einzelne
Dateien aus dem Backup raus kratzen.

Das interessanteste an Snaps ist, dass man damit einigermaßen
konsistente Backups bekommt. Das geht auf die klassische Tour nur, wenn
gerade nichts groß los ist.
Post by Ulli Horlacher
Klar, snapshots ersetzen kein full-backup fuer den GAU-Fall, aber
Also, so oft brauche ich das Backup auch nicht. Alle paar Jahre mal, und
wenn dann dringend, aber dass ich jetzt ständig irgendwelche Änderungen
rückgängig machen würde, kann ich nicht sagen. Selbst wenn eine Änderung
mal Probleme macht, will ich in den allermeisten Fällen trotzdem die
Flucht nach vorne, denn ich habe ja die Änderung nicht aus Spaß gemacht.
Post by Ulli Horlacher
Versehentlich File oder Directory geloescht oder ueberschrieben.
Einzelnes File, kam schon mal vor, aber ganze Verzeichnisbäume habe ich
noch nicht geschafft.
Post by Ulli Horlacher
Hab mir kuerzlich 1 TB Daten zerstoert durch einen Tippfehler mit rsync
--delete ...
Aua. Falsch rum Syncen ist wohl so ein Klassiker.


Marcel
Marc Haber
2024-10-19 07:09:35 UTC
Antworten
Permalink
Post by Marcel Mueller
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Backup habe ich auch so. Und einen Snap muss man im entscheidenden
Moment auch erst mal vorher gemacht haben.
Dafür gibt es software. Hab ich auch noch auf der Liste stehen. Ich
glaub das mach ich heute mal.
Post by Marcel Mueller
Aber klar Snap ist immer schneller. Allerdings will ich auch da
üblicherweise nicht komplett zum alten Stand zurück, und vllt. die in
der Zeit eingetrudelten Mails verzichten, sondern muss doch einzelne
Dateien aus dem Backup raus kratzen.
Das geht bei btrfs-Snapshots problemlos.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Ulli Horlacher
2024-10-19 10:46:14 UTC
Antworten
Permalink
Post by Marcel Mueller
Post by Ulli Horlacher
Damit verzichtest du auf Snapshots, der wichtigsten Neuentwicklung der
letzten 20 Jahre.
Ja, das war mir bisher noch kein btrfs-Experiment wert.
Snapshots gibts auch mit ZFS.
Und SLES setzt btrfs seit gut 10 Jahren als Standard Dateisystem ein.
Man koennte also eher so rum argumentieren: btrfs ist fuer den
professionellen Einsatz, ext* fuer den Heimwerker.
Post by Marcel Mueller
Außerdem hat btrfs noch immer das 4kB Limit bei den erweiterten
Attributen. Das nenne ich mal einen Anachronismus. Das gibt bei
einzelnen Dateien hässliche und nicht sinnvoll behandelbare Fehlermeldungen.
DAS ist mir noch nie passiert.
Welches Programm verwendet denn derart viel extended attributes?
Post by Marcel Mueller
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Backup habe ich auch so. Und einen Snap muss man im entscheidenden
Moment auch erst mal vorher gemacht haben.
Schon mal was von cron gehoert? :-)
Ich mach stuendlich snapshots. Kostet so gut wie nichts.
Post by Marcel Mueller
Post by Ulli Horlacher
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
durchfuehrbar, weshalb man sie problemlos stuendlich machen kann.
Rsnapshot läuft hier auf dem Server auch nur ein paar Minuten, wenn es
nicht gerade der erste Lauf ist
Dann hast du nur sehr kleine Dateien, insbesondere keine VMs.
Und rsnapshot ist nicht Datei-konsistent. Wenn sich beim Kopieren die
Datei aendert, ist die Kopie kaputt. Snapshots haben das Problem nicht.
rsnapshot ist halt Technologie ausm letzten Jahrtausend, wobei IBM schon
1990 snapshots hatte.
Post by Marcel Mueller
und da ist das Datengrab, was noch nicht SSD ist, schon mit dabei. Da
würde ich aber auch nicht wollen, das einmal die Stunde die Spindel
anläuft.
Snapshots laufen IMMER ins selbe Filesystem, da muss keine "Spindel
anlaufen".
Post by Marcel Mueller
Aber klar Snap ist immer schneller. Allerdings will ich auch da
üblicherweise nicht komplett zum alten Stand zurück, und vllt. die in
der Zeit eingetrudelten Mails verzichten, sondern muss doch einzelne
Dateien aus dem Backup raus kratzen.
Genau das geht mit snapshots. Du hast das wohl nie ausprobiert?
Post by Marcel Mueller
Post by Ulli Horlacher
Versehentlich File oder Directory geloescht oder ueberschrieben.
Einzelnes File, kam schon mal vor, aber ganze Verzeichnisbäume habe ich
noch nicht geschafft.
Noch nie ein rm -rf im falschen Fenster bzw shell getippt?
Post by Marcel Mueller
Post by Ulli Horlacher
Hab mir kuerzlich 1 TB Daten zerstoert durch einen Tippfehler mit rsync
--delete ...
Aua. Falsch rum Syncen ist wohl so ein Klassiker.
War nicht falsch rum. Ich hatte nur das falsche Directory kopiert, das
--delete erledigte dann den Rest :-}
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Hergen Lehmann
2024-10-19 11:38:28 UTC
Antworten
Permalink
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Das allerdings ist unter Linux wirklich als experimentell einzustufen.
Post by Ulli Horlacher
Und SLES setzt btrfs seit gut 10 Jahren als Standard Dateisystem ein.
Waren das die, die eine Zeitlang im Alleingang auf das exotische
ReiserFS als Standard gesetzt hatten?
Post by Ulli Horlacher
Man koennte also eher so rum argumentieren: btrfs ist fuer den
professionellen Einsatz, ext* fuer den Heimwerker.
ext4 ist bewährt und robust, skaliert von Embedded bis zum
Enterprise-Server, und ist für viele Dinge einfach ausreichend. btrfs
ist, wo der Zug hinfährt, und wo man mitfahren sollte, wenn man moderne
Features benötigt.
Dietz Proepper
2024-10-19 12:09:32 UTC
Antworten
Permalink
Post by Hergen Lehmann
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Das allerdings ist unter Linux wirklich als experimentell einzustufen.
Hmm. Ich verwende es seit guten 10a produktiv.
Post by Hergen Lehmann
Post by Ulli Horlacher
Und SLES setzt btrfs seit gut 10 Jahren als Standard Dateisystem ein.
Waren das die, die eine Zeitlang im Alleingang auf das exotische
ReiserFS als Standard gesetzt hatten?
Ja.
Post by Hergen Lehmann
Post by Ulli Horlacher
Man koennte also eher so rum argumentieren: btrfs ist fuer den
professionellen Einsatz, ext* fuer den Heimwerker.
ext4 ist bewährt und robust, skaliert von Embedded bis zum
Enterprise-Server, und ist für viele Dinge einfach ausreichend. btrfs
ist, wo der Zug hinfährt, und wo man mitfahren sollte, wenn man
moderne Features benötigt.
Und zfs ist btrfs in "funktioniert"? ;-)
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987
Hergen Lehmann
2024-10-19 17:15:21 UTC
Antworten
Permalink
Post by Dietz Proepper
Post by Hergen Lehmann
[ZFS]
Das allerdings ist unter Linux wirklich als experimentell einzustufen.
Hmm. Ich verwende es seit guten 10a produktiv.
Ich verwende es auch auf zwei Maschinen produktiv.

Aber eine bootfähige Linux-Installation auf ZFS ist eine Wissenschaft.
Ich habe schließlich kapituliert, als root-fs doch eine kleine
ext4-Partition genommen und nur /home auf ZFS gelegt.

Man merkt an allen Ecken und Enden (beginnend bereits mit dem
Installer), das Integration fehlt.

OpenZFS hinkte lange Zeit stark und auch heute immer noch ein wenig
hinter dem Original hinterher.

Die Performance ist spürbar schlechter als ext4, mindestens bei
wahlfreiem Zugriff auf viele kleine Dateien.
Post by Dietz Proepper
Post by Hergen Lehmann
btrfs
ist, wo der Zug hinfährt, und wo man mitfahren sollte, wenn man
moderne Features benötigt.
Und zfs ist btrfs in "funktioniert"? ;-)
Da mehrere große Distributionen inzwischen auf btrfs und NICHT auf zfs
setzen, scheinen die Profis da anderer Ansicht zu sein.
Dietz Proepper
2024-10-20 05:18:56 UTC
Antworten
Permalink
Post by Hergen Lehmann
Post by Dietz Proepper
Post by Hergen Lehmann
[ZFS]
Das allerdings ist unter Linux wirklich als experimentell
einzustufen.
Hmm. Ich verwende es seit guten 10a produktiv.
Ich verwende es auch auf zwei Maschinen produktiv.
Aber eine bootfähige Linux-Installation auf ZFS ist eine
Wissenschaft. Ich habe schließlich kapituliert, als root-fs doch eine
kleine ext4-Partition genommen und nur /home auf ZFS gelegt.
In aktuellem Debian stale geht's halbwegs.
Post by Hergen Lehmann
Man merkt an allen Ecken und Enden (beginnend bereits mit dem
Installer), das Integration fehlt.
Das ist allerdings eher ein Distributionsproblem, oder?
Post by Hergen Lehmann
OpenZFS hinkte lange Zeit stark und auch heute immer noch ein wenig
hinter dem Original hinterher.
Nahe genug, ymmv.
Post by Hergen Lehmann
Die Performance ist spürbar schlechter als ext4, mindestens bei
wahlfreiem Zugriff auf viele kleine Dateien.
Kann ich so nicht bestätigen. Bzw. vllt. 10% Unterschied. Mein
"heimisches" ZFS (sechs Platten, raidz2) bedient bei großen Dateien so
ca. 500MB/s. Bei kleinen Dateien ("compilierter Linux-Sourcetree") fällt
das auf um die 25MB/s zusammen. Ext4 liefert vielleicht 30. Alles
auf rotierendem Rost.
Post by Hergen Lehmann
Post by Dietz Proepper
Post by Hergen Lehmann
btrfs
ist, wo der Zug hinfährt, und wo man mitfahren sollte, wenn man
moderne Features benötigt.
Und zfs ist btrfs in "funktioniert"? ;-)
Da mehrere große Distributionen inzwischen auf btrfs und NICHT auf
zfs setzen, scheinen die Profis da anderer Ansicht zu sein.
Du solltest die "Profis" nach ihren Gründen fragen. Iirc 99,999% "legal
issues". Du willst Dir 'orrible halt nur wenn es gar nicht anders geht
ans Bein binden ...

Kann btrfs inzwischen eigentlich anständiges balancing oder muss man
da nachwievor regelmäßig händisch nachputzen?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. - Richard P. Feynman, 1987
Peter J. Holzer
2024-10-19 12:25:47 UTC
Antworten
Permalink
Post by Hergen Lehmann
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Das allerdings ist unter Linux wirklich als experimentell einzustufen.
Bei Ubuntu ist es eine der bei der Installation vorgeschlagenen
Optionen.
Post by Hergen Lehmann
Post by Ulli Horlacher
Man koennte also eher so rum argumentieren: btrfs ist fuer den
professionellen Einsatz, ext* fuer den Heimwerker.
ext4 ist bewährt und robust, skaliert von Embedded bis zum
Enterprise-Server, und ist für viele Dinge einfach ausreichend.
ACK. Ich bräuchte einen guten Grund, um meine Server auf Btrfs oder ZFS
umzustellen. Die features dieser Filesysteme sehe ich - zumindest für
meine Anwendungszwecke - eher als Nice to have.
Post by Hergen Lehmann
btrfs ist, wo der Zug hinfährt, und wo man mitfahren sollte, wenn man
moderne Features benötigt.
Er fährt hals schon ziemlich lange.

hp
Hergen Lehmann
2024-10-19 17:23:34 UTC
Antworten
Permalink
Post by Peter J. Holzer
Post by Hergen Lehmann
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Das allerdings ist unter Linux wirklich als experimentell einzustufen.
Bei Ubuntu ist es eine der bei der Installation vorgeschlagenen
Optionen.
s/ist/war/

Mit der einzigen Option "ganze Platte ZFS" und mit einer ziemlich
konfusen, fest vorgegeben Aufteilung in rund ein Dutzend separierte
Filesysteme für jeden Scheiss.

Man hat wohl eingesehen, das das *SO* keinen Sinn machte, und im
aktuellen Installer ist die Option konsequent wieder rausgeflogen.
Post by Peter J. Holzer
Post by Hergen Lehmann
btrfs ist, wo der Zug hinfährt, und wo man mitfahren sollte, wenn man
moderne Features benötigt.
Er fährt hals schon ziemlich lange.
Ja, mei, der ext-Zug fuhr auch ziemlich lange bis er bei der Endstation
ext4 angekommen war, und selbst diese Endstation wird noch weiterentwickelt.
Peter J. Holzer
2024-10-19 18:59:48 UTC
Antworten
Permalink
Post by Hergen Lehmann
Post by Peter J. Holzer
Post by Hergen Lehmann
btrfs ist, wo der Zug hinfährt, und wo man mitfahren sollte, wenn man
moderne Features benötigt.
Er fährt hals schon ziemlich lange.
Ja, mei, der ext-Zug fuhr auch ziemlich lange bis er bei der Endstation
ext4 angekommen war, und selbst diese Endstation wird noch weiterentwickelt.
Der Unterschied ist halt, dass Rémy Card nicht 1992 verkündet hat, er
möchte ein Filesystem mit Journalling, ACLs, gehashten Directorys,
48-Bit-Blocknummern, etc. implementieren. Sondern er hat (gemeinsam mit
T'so und Tweedie) ein Filesystem entwickelt, das das konnte, was man
damals von einem Unix-Filesystem erwartet hat. Und das war dann erstmal
fertig und wurde verwendet und niemand hat auf ext3 oder gar ext4
gewartet. Und dann gab es ein paar kleinere Weiterentwicklungen und
viele Jahre später gab es dann mit ext3 eine größere Iteration, die aber
meiner Erinnerung nach auch ziemlich schnell fertiggestellt war. Und das
Spiel hat sich dann noch einmal wiederholt. Bei ext4 kommen auch noch
immer wieder mal neue Features dazu, aber es gibt keinen großen Plan. Ob
es mal ein ext5 geben wird, wissen wir nicht.

Bei Btrfs gab es hingegen von Anfang an einen großen Plan, was das
Filesystem alles können sollte, wenn es fertig ist. Und manche dieser
Features sind 17 Jahre nach der Erstveröffentlichung immer noch nicht
implementiert. In der Praxis macht es natürlich keinen Unterschied, ob
ein Feature nicht existiert, weil es nie geplant war, oder weil es zwar
geplant, aber nicht umgesetzt wurde, aber in den Köpfen der User ist
Btrfs eine ewige Baustelle und wird nie fertig.

hp
Hergen Lehmann
2024-10-19 19:36:36 UTC
Antworten
Permalink
Post by Peter J. Holzer
implementiert. In der Praxis macht es natürlich keinen Unterschied, ob
ein Feature nicht existiert, weil es nie geplant war, oder weil es zwar
geplant, aber nicht umgesetzt wurde, aber in den Köpfen der User ist
Btrfs eine ewige Baustelle und wird nie fertig.
Das ist aber halt nur ein Bauchgefühl und nicht etwas, das den
praktischen Einsatz verhindert.

Ein Flughafen kann nach Fertigstellung von Flugfeld, Tower und einem
ersten Terminal auch schon mal in den harten Praxisbetrieb gehen,
während die im Masterplan vorgesehenen Erweiterungsbauten Jahrzehnte
später oder niemals umgesetzt werden.
Andreas M. Kirchwitz
2024-10-19 21:53:08 UTC
Antworten
Permalink
Post by Hergen Lehmann
Post by Peter J. Holzer
implementiert. In der Praxis macht es natürlich keinen Unterschied, ob
ein Feature nicht existiert, weil es nie geplant war, oder weil es zwar
geplant, aber nicht umgesetzt wurde, aber in den Köpfen der User ist
Btrfs eine ewige Baustelle und wird nie fertig.
Das ist aber halt nur ein Bauchgefühl und nicht etwas, das den
praktischen Einsatz verhindert.
Na ja, wenn jenes Bauchgefühl den praktischen Einsatz blockiert,
weil die Leute Angst um ihre Daten haben, wie soll es weitergehen?

Btrfs hat nun mal eine jahrelange Geschichte, dass Anwender
geglaubt haben, nach all den Jahren müsse so ein Filesystem
doch wenigstens die Basics vollumfänglich unterstützen, denn
schließlich ist die IT-Welt sehr vielfältig. Doch dann erfährt
man - mit etwas Pech erst, wenn es zu spät ist - was alles in
Btrfs nur eingeschränkt funktioniert, obwohl klassische
Filesysteme oder Volumemanager das seit Ewigkeiten können.

Das ist ja okay, kann man so machen, aber ein massentaugliches
Filesystem ist Btrfs mit so einem Verständnis der Entwickler
dann eben einfach nicht.

Fedora hat es vor einer Weile als Default auf die Massen
losgelassen. Fraglich ist allerdings, wer mit Fedora ein
komplexes Storage-Setup baut. Für den 08/15-Anwender,
der sowieso 99% der Zeit nur im Webbrowser rumklickt,
ist das Filesystem natürlich völlig egal, das kriegt
sogar Btrfs mühelos hin.

Wo Storage wichtig ist, sehe ich in der Praxis sehr oft ZFS,
obwohl das unter Linux wegen der Lizenz nicht stressfrei ist.
Das sind dann freilich eher Gesamtlösungen inklusive OS,
die ZFS bereits einschließen. Dadurch entfällt der Stress
für den Anwender, ZFS mit der jeweiligen Distribution in
Einklang zu bringen.

Btrfs mag inzwischen ganz okay sein, aber im harten Alltag
bleibt es bisher den Beweis der echten Massentauglichkeit
schuldig. Das böse Bauchgefühl...

Grüße, Andreas
Ulli Horlacher
2024-10-19 22:41:05 UTC
Antworten
Permalink
Post by Andreas M. Kirchwitz
Btrfs hat nun mal eine jahrelange Geschichte, dass Anwender
geglaubt haben, nach all den Jahren müsse so ein Filesystem
doch wenigstens die Basics vollumfänglich unterstützen, denn
schließlich ist die IT-Welt sehr vielfältig. Doch dann erfährt
man - mit etwas Pech erst, wenn es zu spät ist - was alles in
Btrfs nur eingeschränkt funktioniert
Was funktioniert in btrfs nur eingeschraenkt?
Ich setz das seit gut 10 Jahren ein und hab noch nichts vermisst, was bei
ext3 oder xfs gaebe.
Post by Andreas M. Kirchwitz
Btrfs mag inzwischen ganz okay sein, aber im harten Alltag
bleibt es bisher den Beweis der echten Massentauglichkeit
schuldig. Das böse Bauchgefühl...
SLES ist also nichts fuer die Massen?
Das sehen die zahlenden Industriekunden aber ganz anders.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marc Haber
2024-10-19 12:44:44 UTC
Antworten
Permalink
Post by Hergen Lehmann
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Das allerdings ist unter Linux wirklich als experimentell einzustufen.
Ohoh, das gibt jetzt einen Sturm an Fanbois, die jetzt aus der Hecke
gesprungen kommen.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Ulli Horlacher
2024-10-19 12:51:58 UTC
Antworten
Permalink
Post by Hergen Lehmann
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Das allerdings ist unter Linux wirklich als experimentell einzustufen.
Bei Ubuntu ist das mit vollen Support dabei, nicht experimentell.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marcel Mueller
2024-10-19 12:48:23 UTC
Antworten
Permalink
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Und SLES setzt btrfs seit gut 10 Jahren als Standard Dateisystem ein.
Man koennte also eher so rum argumentieren: btrfs ist fuer den
professionellen Einsatz, ext* fuer den Heimwerker.
Ich nutze XFS für größere Datenmengen.
Das ist vor allem historisch gewachsen, denn als es vor gut 20 Jahren
mit Linux los ging, war die Auswahl brauchbarer Dateisysteme begrenzt.
AFAIR konnte Debian da noch nicht mal ext4. Und ext2/3 war für große
Dateien schon immer unbrauchbar. Und erweiterte Attribute über Samba war
auch so eine Sache.
Post by Ulli Horlacher
Post by Marcel Mueller
Außerdem hat btrfs noch immer das 4kB Limit bei den erweiterten
Attributen. Das nenne ich mal einen Anachronismus. Das gibt bei
einzelnen Dateien hässliche und nicht sinnvoll behandelbare Fehlermeldungen.
DAS ist mir noch nie passiert.
Welches Programm verwendet denn derart viel extended attributes?
OS/2 macht das z.B. gerne mal. Skript-Interpreter speichern ihr Kompilat
in EAs. Wenn dann die Quelldatei groß ist wird natürlich auch dieses
groß. Thumbnails in EAs können das Limit auch mal reißen.

Ich habe vor einer Weile mal über btrfs nachgedacht, aber warum ein
funktionierendes System ändern? Und das 4k EA Limit hat mir dann den
Rest gegeben.
Und XFS scheint mit etwas Verzögerung auch die Features von btrfs zu
lernen. Snaps gehen wohl mittlerweile auch. Aber es würde mich wundern,
wenn mein abgehangenes Debian das schon kann. Nächstes Jahr vllt. Da
muss ich den Server sowieso mal aktualisieren.
Post by Ulli Horlacher
Post by Marcel Mueller
Post by Ulli Horlacher
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
durchfuehrbar, weshalb man sie problemlos stuendlich machen kann.
Rsnapshot läuft hier auf dem Server auch nur ein paar Minuten, wenn es
nicht gerade der erste Lauf ist
Dann hast du nur sehr kleine Dateien, insbesondere keine VMs.
Doch, klar habe ich (ein paar) VMs. Allerdings haben die keine
mördergroßen VDisks, da die Userdaten direkt auf dem Server liegen.

Für die VMs habe ich aber (zusätzlich) eine andere (ältere)
Vorgehensweise. VM-Snap ziehen, Virtuelle Disk kopieren, VM-Snap weg.
Das läuft nachts. Die Kopie ist dann genau so konsistent wie eine
abgestürzte VM. Besser wäre ein Dateisystem-Snap auch nicht.
Post by Ulli Horlacher
Und rsnapshot ist nicht Datei-konsistent. Wenn sich beim Kopieren die
Datei aendert, ist die Kopie kaputt.
Das gilt für so ziemlich jedes Backup ohne weitere Maßnahmen.
Post by Ulli Horlacher
Snapshots haben das Problem nicht.
Ack. Das wäre auch mein primärer Einsatzzweck, wenn ich sie hätte. Snap
ziehen, Backup, Snap löschen.

Ständig mit Snaps arbeiten, finde ich nicht so gut, da das die
Fragmentierung stark fördert.
Post by Ulli Horlacher
rsnapshot ist halt Technologie ausm letzten Jahrtausend,
Weiß gar nicht, ob das so alt ist.
Es ist einfach nur ein Frontend für rsync.
Post by Ulli Horlacher
Post by Marcel Mueller
und da ist das Datengrab, was noch nicht SSD ist, schon mit dabei. Da
würde ich aber auch nicht wollen, das einmal die Stunde die Spindel
anläuft.
Snapshots laufen IMMER ins selbe Filesystem, da muss keine "Spindel
anlaufen".
Doch. Ich kann doch keinen Snap von einem Volume ziehen, ohne dass
dieses Online ist. Die Festplatte ist hier aus Stromspargründen die
meiste Zeit im Standby. Da sind im wesentlichen nur Filme und ein paar
Disk-Images drauf.
Post by Ulli Horlacher
Post by Marcel Mueller
Aber klar Snap ist immer schneller. Allerdings will ich auch da
üblicherweise nicht komplett zum alten Stand zurück, und vllt. die in
der Zeit eingetrudelten Mails verzichten, sondern muss doch einzelne
Dateien aus dem Backup raus kratzen.
Genau das geht mit snapshots. Du hast das wohl nie ausprobiert?
Weiß ich. Ich meinte der Aufwand ist das "kratzen" und nicht der Zugriff
auf das Backup.
Post by Ulli Horlacher
Post by Marcel Mueller
Post by Ulli Horlacher
Versehentlich File oder Directory geloescht oder ueberschrieben.
Einzelnes File, kam schon mal vor, aber ganze Verzeichnisbäume habe ich
noch nicht geschafft.
Noch nie ein rm -rf im falschen Fenster bzw shell getippt?
Nein, tatsächlich noch nie.


Marcel
Ulli Horlacher
2024-10-19 13:01:01 UTC
Antworten
Permalink
Post by Marcel Mueller
Das ist vor allem historisch gewachsen, denn als es vor gut 20 Jahren
mit Linux los ging
... hast du die ersten 10 Jahre Linux verschlafen :-)
Post by Marcel Mueller
Post by Ulli Horlacher
Post by Marcel Mueller
Außerdem hat btrfs noch immer das 4kB Limit bei den erweiterten
Attributen. Das nenne ich mal einen Anachronismus. Das gibt bei
einzelnen Dateien hässliche und nicht sinnvoll behandelbare Fehlermeldungen.
DAS ist mir noch nie passiert.
Welches Programm verwendet denn derart viel extended attributes?
OS/2 macht das z.B. gerne mal.
Und welche Linux Relevanz hat das?
Soll ich mal aufzaehlen was das VMS Filesystem FILES-11 schon 1980 alles
konnte und kein Linux Filesystem immer noch nicht?
Post by Marcel Mueller
Und XFS scheint mit etwas Verzögerung auch die Features von btrfs zu
lernen. Snaps gehen wohl mittlerweile auch.
Nein.
Post by Marcel Mueller
Post by Ulli Horlacher
Und rsnapshot ist nicht Datei-konsistent. Wenn sich beim Kopieren die
Datei aendert, ist die Kopie kaputt.
Das gilt für so ziemlich jedes Backup ohne weitere Maßnahmen.
Nicht bei snapshots (wenn man die als "backup" durchgehen laesst).
Post by Marcel Mueller
Ständig mit Snaps arbeiten, finde ich nicht so gut, da das die
Fragmentierung stark fördert.
Ist im Zeitalter von SSDs ein Nullargument.
Post by Marcel Mueller
Post by Ulli Horlacher
rsnapshot ist halt Technologie ausm letzten Jahrtausend,
Weiß gar nicht, ob das so alt ist.
Es ist einfach nur ein Frontend für rsync.
Die Technologie dahinter ist halt so alt.
Post by Marcel Mueller
Post by Ulli Horlacher
Post by Marcel Mueller
und da ist das Datengrab, was noch nicht SSD ist, schon mit dabei. Da
würde ich aber auch nicht wollen, das einmal die Stunde die Spindel
anläuft.
Snapshots laufen IMMER ins selbe Filesystem, da muss keine "Spindel
anlaufen".
Doch. Ich kann doch keinen Snap von einem Volume ziehen, ohne dass
dieses Online ist. Die Festplatte ist hier aus Stromspargründen die
meiste Zeit im Standby. Da sind im wesentlichen nur Filme und ein paar
Disk-Images drauf.
Wenn die Platte aus ist, dann brauchst du auch keine stuendlichen Snapshots.
Dann passt man halt den cronjob an.
Post by Marcel Mueller
Post by Ulli Horlacher
Post by Marcel Mueller
Aber klar Snap ist immer schneller. Allerdings will ich auch da
üblicherweise nicht komplett zum alten Stand zurück, und vllt. die in
der Zeit eingetrudelten Mails verzichten, sondern muss doch einzelne
Dateien aus dem Backup raus kratzen.
Genau das geht mit snapshots. Du hast das wohl nie ausprobiert?
Weiß ich. Ich meinte der Aufwand ist das "kratzen" und nicht der Zugriff
auf das Backup.
Was ist an rsync oder cp so aufwaendig?
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marcel Mueller
2024-10-20 07:59:32 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Marcel Mueller
Das ist vor allem historisch gewachsen, denn als es vor gut 20 Jahren
mit Linux los ging
... hast du die ersten 10 Jahre Linux verschlafen :-)
Nein, hatte seit meinem ersten x86 PC Anfang der 90er OS/2, startend mit
2.1β, das auch schon Win 3.1 konnte.
Aber Warp Advanced Server war mir dann doch eine Nummer zu groß, und da
habe ich mir einen Debian Server als "NAS" mit DLT-Backup aufgesetzt.
Später kamen dann Clients dazu. Die alten Kisten sind dann in VMs auf
dem Server gewandert.

[EAs]
Post by Ulli Horlacher
Post by Marcel Mueller
OS/2 macht das z.B. gerne mal.
Und welche Linux Relevanz hat das?
Ich habe noch solche Dateien.
Und eine OS/2 VM (eigentlich eCS) lebt auch noch. Es gibt noch eine
Sache, die ich nicht ablösen konnte. Die Digitale Raumkorrektur für die
Audiowiedergabe funktioniert unter Linux nicht mit vernünftiger Latenz.
Das stottert immer wieder, nicht gerade audiophil. Das PA-Modul für
LADSPA kann mit dem latency-Parameter nichts anfangen. Unter OS/2 ist
das nahezu latenzfrei, weil durch Prefetch kompensiert; selbst dann,
wenn die eigentliche Wiedergabe über PulseAudio über's Netz läuft.
Und ich habe auch einige Workflows und Scripte, die Metadaten in EAs
ablegen.
Post by Ulli Horlacher
Soll ich mal aufzaehlen was das VMS Filesystem FILES-11 schon 1980 alles
konnte und kein Linux Filesystem immer noch nicht?
Weiß ich. Dateiversionen zum Beispiel. Wir hatten mal so eine Kiste. War
so Anfang der 80er, wo man keinen Starkstromanschluss mehr brauchte.
Das mit den Versionen hat z.T. aber auch genervt, weil man immer
aufpassen musste, dass die Platte dadurch nicht voll wird. Block-Level
Deduplication gehörte nämlich nicht zu den Features.
Post by Ulli Horlacher
Post by Marcel Mueller
Und XFS scheint mit etwas Verzögerung auch die Features von btrfs zu
lernen. Snaps gehen wohl mittlerweile auch.
Nein.
Man liest anderes. Ich habe es aber nicht probiert. Und es ist wohl auch
eher vergleichbar mit VM-Snaps. Würde mir aber reichen.
Post by Ulli Horlacher
Post by Marcel Mueller
Post by Ulli Horlacher
Und rsnapshot ist nicht Datei-konsistent. Wenn sich beim Kopieren die
Datei aendert, ist die Kopie kaputt.
Das gilt für so ziemlich jedes Backup ohne weitere Maßnahmen.
Nicht bei snapshots (wenn man die als "backup" durchgehen laesst).
Snapshots alleine sind mitnichten ein Backup. Es gibt ja keinerlei
Redundanz bei den eigentlichen Daten.
Sie sind nur eine solide Grundlage, mit der man gute Backups anfertigen
kann.
Post by Ulli Horlacher
Post by Marcel Mueller
Ständig mit Snaps arbeiten, finde ich nicht so gut, da das die
Fragmentierung stark fördert.
Ist im Zeitalter von SSDs ein Nullargument.
Die Verwaltungsstrukturen brauchst du trotzdem.
Und als wirkliches Datengrab sind mir SSDs dann doch zu teuer. Dafür
gibt es noch eine Platte.
Post by Ulli Horlacher
Post by Marcel Mueller
Post by Ulli Horlacher
rsnapshot ist halt Technologie ausm letzten Jahrtausend,
Weiß gar nicht, ob das so alt ist.
Es ist einfach nur ein Frontend für rsync.
Die Technologie dahinter ist halt so alt.
In den 90-ern habe ich auch so gesynct. Ich hatte sogar eine Variante,
die mit Wechseldatenträgern als Zwischenspeicher umgehen konnte und
trotzdem in beide Richtungen Inkrementell Syncen konnte.
Post by Ulli Horlacher
Post by Marcel Mueller
Doch. Ich kann doch keinen Snap von einem Volume ziehen, ohne dass
dieses Online ist. Die Festplatte ist hier aus Stromspargründen die
meiste Zeit im Standby. Da sind im wesentlichen nur Filme und ein paar
Disk-Images drauf.
Wenn die Platte aus ist, dann brauchst du auch keine stuendlichen Snapshots.
Dann passt man halt den cronjob an.
Ja, OK einmal am Tag wäre kein Problem. Aber die will ich auch nicht
fragmentieren. Die Transferrate ist so schon manchmal knapp wenn während
einer Aufnahme ein Videoschnitt läuft.


[restore]
Post by Ulli Horlacher
Post by Marcel Mueller
Weiß ich. Ich meinte der Aufwand ist das "kratzen" und nicht der Zugriff
auf das Backup.
Was ist an rsync oder cp so aufwaendig?
Wir reden aneinander vorbei. Ich meine der inhaltliche Restore-Vorgang
braucht viel mehr meiner Zeit als alles andere. Und der Rest, ob nun
RSync oder was auch immer ist vernachlässigbar.


Marcel
Andreas M. Kirchwitz
2024-10-19 13:05:17 UTC
Antworten
Permalink
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Und SLES setzt btrfs seit gut 10 Jahren als Standard Dateisystem ein.
Man koennte also eher so rum argumentieren: btrfs ist fuer den
professionellen Einsatz, ext* fuer den Heimwerker.
ZFS, btrfs, ReiserFS und wie sie sonst noch heißen, die sind für
den Spezialeinsatz, wenn jemand bestimmte Sonderfeatures möchte
und dafür auf universelle Nutzbarkeit und Robustheit verzichten
kann, weil er genau überblickt, was er braucht und was nicht.

Das mag vielleicht ein professioneller Einsatz sein, aber ebenso
ist im professionellen Einsatz von solchen Dateisystemen zugleich
überdeutlich abzuraten, weil man sich auch ganz klar Nachteile bis
hin zu Datenverlusten ins Haus holt, wenn man sie fälschlicherweise
einfach so wie "normale" Filesysteme nutzt.

Bitte nicht als Kritik verstehen, sonst gäbe es ja nie neue
Filesysteme, wenn man immer nur am Alten kleben würde, aber
an den genannten Filesystemen wird/wurde ewig rumgebastelt,
Stabilität und Robustheit sind nebensächlich, es stand nie
eine breite Nutzung im Fokus, Zielgruppe ist eine enge Nische,
es gibt zuweilen Hardware-Voraussetzungen aus dem Server-Bereich,
und wenn das alles nicht genug abschreckt, packt man noch eine
einschränkende Lizenz drauf. :-(

Trotz des öffentlichen Hypes läuft die Entwicklung solcher
Über-Filesysteme seit Jahrzehnten stets überraschend schleppend.
Jahrelang passiert dann mal nichts, fundamentale Features bleiben
ewig auf der To-Do-Liste. Die Dinger sind allesamt für die Nische.

Mit (optional) LVM und darauf Ext4 oder vielleicht auch XFS kommt
man im Allgemeinen erheblich weiter, und vor allem frustfreier.
Ja, komfortabel und bequem ist anders, aber sehr gut dokumentiert,
läuft vor allem überall und ohne überraschende Nebenwirkungen.

Snapshots sind nett, aber eben eine Nische. Mir würden sie im
Alltag wenig bringen, egal ob privat oder beruflich. Da brauche
ich Backups, und das vor allem nicht auf der gleichen Hardware
wie das Filesystem.

Wer Snapshots zwingend benötigt (und dafür kenne ich durchaus
Fälle aus der Praxis), sollte dann lieber zu professionellen
Lösungen greifen, da habe ich früher gern NetApps genutzt.
Ist aber inzwischen selten geworden. Technik darf ja nirgendwo
noch was kosten. Das meiste landet sowieso in der Cloud, ist
zwar am Ende doch wieder teurer, aber gleichmäßiger verteilt
über die Zeit, was den Entscheidern meist besser gefällt.
Post by Ulli Horlacher
Dann hast du nur sehr kleine Dateien, insbesondere keine VMs.
Und rsnapshot ist nicht Datei-konsistent. Wenn sich beim Kopieren die
Datei aendert, ist die Kopie kaputt. Snapshots haben das Problem nicht.
Was auch immer Datei-konsistent genau ist... jede Form von Backup
oder Snapshot hat am Ende in irgendeiner Form das Problem, dass bei
gerade laufenden Schreibvorgängen die Daten aus Applikations-Sicht
leider Schrott sind, auch bei Snapshots.

Snapshots sind natürlich dann nett, wenn man einer Anwendung sagen
kann, sie soll mal kurz die Füße still halten. Snapshot. Weiter geht's.
Dann kann man im Hintergrund in Ruhe das Backup vom Snapshot machen.
Datenbanken können das meist. Aber ansonsten ist das eher selten.

Snapshots haben an Popularität verloren, seit viele Abläufe
nicht mehr direkt im Filesystem stattfinden, sondern man oftmals
Schnittstellen hat, die für Konsistenz sorgen und eine Versionierung
bieten. Da verliert versehentliches Löschen den Schrecken.

Grüße, Andreas
Ralph Aichinger
2024-10-19 14:49:07 UTC
Antworten
Permalink
Post by Andreas M. Kirchwitz
ZFS, btrfs, ReiserFS und wie sie sonst noch heißen, die sind für
den Spezialeinsatz, wenn jemand bestimmte Sonderfeatures möchte
Also ReiserFS ist definitiv für gar keinen Einsatz mehr, außer
noch nicht umkopierte Altbestände.

/ralph
Alexander Schreiber
2024-10-19 19:58:54 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Andreas M. Kirchwitz
ZFS, btrfs, ReiserFS und wie sie sonst noch heißen, die sind für
den Spezialeinsatz, wenn jemand bestimmte Sonderfeatures möchte
Also ReiserFS ist definitiv für gar keinen Einsatz mehr, außer
noch nicht umkopierte Altbestände.
Es gibt noch einen guten Einsatzzweck für ReiserFS: Als "plausible
deniability" warum auf einmal lästige Daten verschwunden sind ...

SCNR,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Ulli Horlacher
2024-10-19 15:38:16 UTC
Antworten
Permalink
Post by Andreas M. Kirchwitz
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Und SLES setzt btrfs seit gut 10 Jahren als Standard Dateisystem ein.
Man koennte also eher so rum argumentieren: btrfs ist fuer den
professionellen Einsatz, ext* fuer den Heimwerker.
ZFS, btrfs, ReiserFS und wie sie sonst noch heißen, die sind für
den Spezialeinsatz, wenn jemand bestimmte Sonderfeatures möchte
und dafür auf universelle Nutzbarkeit und Robustheit verzichten
kann
Solaris hatte 15 Jahre lang NUR noch ZFS und das war universell nutzbar
und extrem robust.
Post by Andreas M. Kirchwitz
Die Dinger sind allesamt für die Nische.
SLES ist also ein Nischen-OS?
Ok, wenn man die Anzahl an Installationen nimmt, mag das stimmen.
Dann trifft dann auch auf RHEL zu, AIX und alle andere kommerzielle UNIXe
sowieso.
Post by Andreas M. Kirchwitz
Mit (optional) LVM und darauf Ext4 oder vielleicht auch XFS kommt
man im Allgemeinen erheblich weiter
Nein.
Bei LVM braucht man fuer jeden snapshot ein eigenes Volume, dem man
explizit Platz zuweisen muss. Da verzettelt (fragmentiert) man schneller
als einem lieb ist. BTDT.
Ausserdem kann nur root LVM snapshots erstellen und es geht nur auf
Volume-Ebene. Zum Zugriff auf die Dateien muss man den snapshot explizit
mounten. Laestig.
Post by Andreas M. Kirchwitz
läuft vor allem überall und ohne überraschende Nebenwirkungen.
Bei LVM snapshots hat man auf einmal filesysteme mit gleicher UUID, was zu
boesen Ueberraschungen und Bootproblemen fuehren kann.
Post by Andreas M. Kirchwitz
Post by Ulli Horlacher
Dann hast du nur sehr kleine Dateien, insbesondere keine VMs.
Und rsnapshot ist nicht Datei-konsistent. Wenn sich beim Kopieren die
Datei aendert, ist die Kopie kaputt. Snapshots haben das Problem nicht.
Was auch immer Datei-konsistent genau ist...
Beim Anlegen eines Snapshots kann die Datei nicht veraendert werden, im
Gegensatz zu User tools wie rsync, cp, tar, cpio, ...
Da ist die Datei dann auf jeden Fall kaputt wenn waehrend des Kopierens
rein geschrieben wird.
Kopier zB mal eine laufende VM mit cp. Du wirst keine Freude damit haben.
Post by Andreas M. Kirchwitz
jede Form von Backup oder Snapshot hat am Ende in irgendeiner Form das
Problem, dass bei gerade laufenden Schreibvorgängen die Daten aus
Applikations-Sicht leider Schrott sind, auch bei Snapshots.
Eine Applikation, die einen Stromausfall nicht uebersteht ist per
Definition kaputt.
Sie darf zwar Daten(saetze) verlieren aber nicht ihre Datenbasis so kaputt
machen, dass sie nicht mehr startet.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marc Haber
2024-10-19 17:27:50 UTC
Antworten
Permalink
Post by Ulli Horlacher
Bei LVM braucht man fuer jeden snapshot ein eigenes Volume, dem man
explizit Platz zuweisen muss. Da verzettelt (fragmentiert) man schneller
als einem lieb ist. BTDT.
Ausserdem kann nur root LVM snapshots erstellen und es geht nur auf
Volume-Ebene. Zum Zugriff auf die Dateien muss man den snapshot explizit
mounten. Laestig.
Dafür haben btrfs-Snapshots andere Haken: Macht man den Snapshot
read-write, stehen die einzelnen Dateien einfach da und können auch
aus versehen oder von einem Angreifer gelöscht werden. Oder kann man
einen Snapshot in eine andere Subvolume machen die nicht ständig
eingehängt sein muss? Macht man den Snapshot read-only, kann man ihn
nur komplett löschen, was echt ärgerlich ist wenn aus Versehen mal ein
großes File wie ein DVD-Image mit rein gerutscht ist.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Ulli Horlacher
2024-10-19 22:47:06 UTC
Antworten
Permalink
Post by Marc Haber
Post by Ulli Horlacher
Bei LVM braucht man fuer jeden snapshot ein eigenes Volume, dem man
explizit Platz zuweisen muss. Da verzettelt (fragmentiert) man schneller
als einem lieb ist. BTDT.
Ausserdem kann nur root LVM snapshots erstellen und es geht nur auf
Volume-Ebene. Zum Zugriff auf die Dateien muss man den snapshot explizit
mounten. Laestig.
Dafür haben btrfs-Snapshots andere Haken: Macht man den Snapshot
read-write, stehen die einzelnen Dateien einfach da und können auch
aus versehen oder von einem Angreifer gelöscht werden.
Wo ist da der Unterschied zu LVM?
Willst du nicht loeschbare snapshots, musst du NFS einsetzen.
Post by Marc Haber
Oder kann man einen Snapshot in eine andere Subvolume machen die nicht
ständig eingehängt sein muss?
Ja. Aber was hilft dir das?
Post by Marc Haber
Macht man den Snapshot read-only, kann man ihn nur komplett löschen, was
echt ärgerlich ist wenn aus Versehen mal ein großes File wie ein
DVD-Image mit rein gerutscht ist.
Niemand hindert dich einen ro subvolume zu rw zu machen, einzelne Dateuen
zu loeschen und dann das subvolume wieder ro zu machen.
Man muss es nur wollen und auch tun.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marc Haber
2024-10-20 08:52:45 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Marc Haber
Macht man den Snapshot read-only, kann man ihn nur komplett löschen, was
echt ärgerlich ist wenn aus Versehen mal ein großes File wie ein
DVD-Image mit rein gerutscht ist.
Niemand hindert dich einen ro subvolume zu rw zu machen, einzelne Dateuen
zu loeschen und dann das subvolume wieder ro zu machen.
Man muss es nur wollen und auch tun.
Und das geht auch bei einem Snapshot der von vornherein als read-only
angelegt wurde? Da gibt es doch extra eine Option für?

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Ulli Horlacher
2024-10-20 08:53:43 UTC
Antworten
Permalink
Post by Marc Haber
Post by Ulli Horlacher
Post by Marc Haber
Macht man den Snapshot read-only, kann man ihn nur komplett löschen, was
echt ärgerlich ist wenn aus Versehen mal ein großes File wie ein
DVD-Image mit rein gerutscht ist.
Niemand hindert dich einen ro subvolume zu rw zu machen, einzelne Dateuen
zu loeschen und dann das subvolume wieder ro zu machen.
Man muss es nur wollen und auch tun.
Und das geht auch bei einem Snapshot der von vornherein als read-only
angelegt wurde?
Ja.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Andreas M. Kirchwitz
2024-10-20 02:53:00 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Andreas M. Kirchwitz
ZFS, btrfs, ReiserFS und wie sie sonst noch heißen, die sind für
den Spezialeinsatz, wenn jemand bestimmte Sonderfeatures möchte
und dafür auf universelle Nutzbarkeit und Robustheit verzichten
kann
Solaris hatte 15 Jahre lang NUR noch ZFS und das war universell nutzbar
und extrem robust.
Hüstel. ZFS kenne ich von Anfang an, deutlich vor Markteinführung,
und natürlich dann in den Jahren, als SUN sich selbst ganz dick im
Storage Business sah mit Maschinen wie Sun Fire X4500 (Thumper).
Das war ein totales Desaster. Kunden waren stinksauer und wollten
ganz schnell wieder zurück zu klassischem UFS und SVM, und für den
großen Storage hatte man wieder die alten NetApps und EMC-Schränke
entstaubt.

ZFS hatte zwar zu Beginn viele Features, aber das Konstrukt war
superempfindlich gegenüber Disk-Ausfällen. ZFS hat sich immer
wieder die Verwaltungsinformationen selbst zerschossen. Saubere
Wiederherstellung nur unter Gesamtverlust aller Daten.

Robust war an ZFS über viele Jahre überhaupt nichts. Im Gegenteil.

ZFS war zudem damals lange Zeit extrem (extremst :-) RAM-hungrig,
sonst brach die Performance drastisch ein.

Universelle Nutzbarkeit nicht gegeben. ZFS war nur für Spezialfälle.

Vielleicht wurde ZFS viele Jahre später noch ganz toll, aber da
wir an die großen Kunden (das waren bis dahin Top-10-Kunden)
keine Sun-Server und auch kein Solaris mit ZFS mehr vermitteln
konnten, habe ich den Niedergang nicht mehr so direkt miterlebt.

OpenZFS mag total anders sein. Nach den Erlebnissen mit dem
Original-ZFS war auf jeden Fall klar, dass ein Über-FS, das alles
in sich vereint und an der sogar eine damals große Bude wie SUN
gescheitert ist, nicht so einfach vom Himmel fallen wird, sondern
gaaanz viel Entwicklungsarbeit benötigt und vor allem Reifezeit.
Post by Ulli Horlacher
Bei LVM braucht man fuer jeden snapshot ein eigenes Volume, dem man
explizit Platz zuweisen muss. Da verzettelt (fragmentiert) man schneller
als einem lieb ist. BTDT.
Mit allerhöchstem Respekt, aber Du hast einen Snapshot-Fetisch. :-)
Post by Ulli Horlacher
Post by Andreas M. Kirchwitz
Was auch immer Datei-konsistent genau ist...
Beim Anlegen eines Snapshots kann die Datei nicht veraendert werden, im
Gegensatz zu User tools wie rsync, cp, tar, cpio, ...
Da ist die Datei dann auf jeden Fall kaputt wenn waehrend des Kopierens
rein geschrieben wird.
Kopier zB mal eine laufende VM mit cp. Du wirst keine Freude damit haben.
Mit dem Snapshot einer VM wird man ebenfalls nicht bedingungslos
Freude haben. Auch ein Snapshot einer MySQL/MariaDB-Datenbank im
klassischen Storage-Format wird oft nicht sauber sein.

Snapshots lindern zwar viele Probleme, aber keineswegs bedeutet
Snapshot, dass für die Anwendungen danach alles konsistent ist.
Post by Ulli Horlacher
Eine Applikation, die einen Stromausfall nicht uebersteht ist per
Definition kaputt.
Puh, dann ist so gut wie alles kaputt, das Ende ist nah. :-)

Bitte sieh meinen Artikel locker. Jeder soll verwenden, was ihn
glücklich macht. Mein einziges Anliegen ist, dass ZFS damals
unreifer Mist gewesen ist. Wer das hochjubelt, war damals nicht
dabei oder hat es nicht wirklich intensiv genutzt. ZFS war
ursprünglich leider kein großer Wurf, sondern das war - neben
anderen Problemen - eher einer der Sargnägel für die Sun-Sparte
bei Oracle.

OpenZFS heutzutage mag ganz toll sein. Das bewerte ich gar nicht.

Grüße, Andreas
Peter J. Holzer
2024-10-19 16:08:17 UTC
Antworten
Permalink
Post by Andreas M. Kirchwitz
Post by Ulli Horlacher
Snapshots gibts auch mit ZFS.
Und SLES setzt btrfs seit gut 10 Jahren als Standard Dateisystem ein.
[...]
Post by Andreas M. Kirchwitz
Bitte nicht als Kritik verstehen, sonst gäbe es ja nie neue
Filesysteme, wenn man immer nur am Alten kleben würde, aber
an den genannten Filesystemen wird/wurde ewig rumgebastelt,
Stabilität und Robustheit sind nebensächlich, es stand nie
eine breite Nutzung im Fokus,
Das würde ich jetzt mal bei ZFS auf Solaris in Abrede stellen. Da waren
Stabilität und Robustheit ganz sicher nicht nebensächlich, sondern
zentral. Und eine breite Nutzung hätte Sun sicher auch gerne gehabt,
aber es hat halt nicht wollen sein.
Post by Andreas M. Kirchwitz
Trotz des öffentlichen Hypes läuft die Entwicklung solcher
Über-Filesysteme seit Jahrzehnten stets überraschend schleppend.
Jahrelang passiert dann mal nichts, fundamentale Features bleiben
ewig auf der To-Do-Liste.
Über ZFS für Linux schwebte natürlich von Anfang an das Damoklesschwert
der Lizenzproblematik. Oracle scheint gegen die Nutzung in Ubuntu keine
Einwände zu haben, aber es gibt auch keine Hinweise, dass sie eine
Integration in den Kernel unterstützen oder auch nur erlauben würden.
Das limitiert natürlich die Verbreitung in Linux.

BtrFS wurde/wird wohl von einem zu kleinen Team gepflegt, und/oder man
hatte zu ambitionierte Pläne. Marketingtechnisch wäre es vielleicht
besser gewesen, mit einem überschaubaren aber brauchbaren Subset
anzufangen und nach der Version 1 immer nur neue Features anzukündigen,
die man auch in absehbarer Zeit ankündigen kann. Zu Stabilität und
Robustheit von BtrFS kann ich nichts sagen. Nicht nur verwende ich es
selbst nicht, ich würde mir auch nur ein Urteil erlauben, wenn ich Daten
von zigtausenden Systemen hätte. Ein Rechner (oder auch ein Dutzend) ist
bestenfalls Anecdata.
Post by Andreas M. Kirchwitz
Post by Ulli Horlacher
Dann hast du nur sehr kleine Dateien, insbesondere keine VMs.
Und rsnapshot ist nicht Datei-konsistent. Wenn sich beim Kopieren die
Datei aendert, ist die Kopie kaputt. Snapshots haben das Problem nicht.
Was auch immer Datei-konsistent genau ist... jede Form von Backup
oder Snapshot hat am Ende in irgendeiner Form das Problem, dass bei
gerade laufenden Schreibvorgängen die Daten aus Applikations-Sicht
leider Schrott sind, auch bei Snapshots.
Das hängt von der Applikation ab. Es ist sehr wohl möglich, Daten
crash-proof zu speichern (ein Snapshot ist im Prinzip ein besonders
gutmütiger Crash). Die meisten Applikationsentwickler tun sich den
Aufwand nicht an, aber manche schon. Bekanntestes Beispiel sind
Datenbanksysteme.
Post by Andreas M. Kirchwitz
Snapshots sind natürlich dann nett, wenn man einer Anwendung sagen
kann, sie soll mal kurz die Füße still halten. Snapshot. Weiter geht's.
Dann kann man im Hintergrund in Ruhe das Backup vom Snapshot machen.
Datenbanken können das meist.
Gerade bei Datenbanken ist das nicht notwendig. Die speichern ihre Daten
so, dass sie auch bei einem Snapshot zu einem beliebigen Zeitpunkt
konsistent sind. Das "halt mal kurz die Füße still" Feature haben sie,
weil man von einer laufenden Datenbank auch ohne Snapshots ein Backup
machen können will.[1]

hp

[1] Ich habe gerade ein Dé­jà-vu. Hatten wir das Theme nicht erst
kürzlich[2]
[2] Meine Definition von "kürzlich" ist ähnlich flexibel wie Elon
Musks Definition von "bald".
Ulli Horlacher
2024-10-19 16:32:49 UTC
Antworten
Permalink
Post by Peter J. Holzer
Robustheit von BtrFS kann ich nichts sagen. Nicht nur verwende ich es
selbst nicht, ich würde mir auch nur ein Urteil erlauben, wenn ich Daten
von zigtausenden Systemen hätte. Ein Rechner (oder auch ein Dutzend) ist
bestenfalls Anecdata.
Wir setzen das auf mehreren hundert Systemen ein, seit vielen Jahren.
Keinerlei Probleme damit.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Sieghard Schicktanz
2024-10-18 19:00:21 UTC
Antworten
Permalink
Hallo Ulli,
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
Dumme Frage nebenbei: Wie steht das bei den "Snapshots" mit den Ressourcen,
die Du gegenüber dem Zeitbedarf leider nicht erwähnst? Ist da der Bedarf
auch 0? Oder zumindest "quasi 0"?
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Peter J. Holzer
2024-10-19 07:43:38 UTC
Antworten
Permalink
Post by Sieghard Schicktanz
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
Dumme Frage nebenbei: Wie steht das bei den "Snapshots" mit den Ressourcen,
die Du gegenüber dem Zeitbedarf leider nicht erwähnst? Ist da der Bedarf
auch 0? Oder zumindest "quasi 0"?
Platzbedarf auf Disk ergibt sich aus den Änderungen zwischen einem
Snapshot und dem nächsten bzw. der aktuellen Version. Wenn Du ein File
löschst, dann belegt es im Snapshot weiterhin Platz. Wenn Du es änderst,
bleiben (mindestens) die alten Datenblöcke erhalten.

Dazu kommt ein bisschen Overhead für Datenstrukturen, um die alten Daten
auch wieder zu finden (den Preis zahlt man aber bei COW-Filesystemen auf
jeden Fall, ob man Snapshots nutzt oder nicht).

CPU und RAM kann ich nicht einschätzen. Ich vermute, dass das "quasi 0"
ist: Ein COW-Filesystem ist komplexer als ein traditionelles
Unix-Filesystem, aber ob du Snapshots dann tatsächlich nutzt oder nicht,
sollte keinen großen Unterschied machen.

hp
Ralph Aichinger
2024-10-19 14:51:07 UTC
Antworten
Permalink
Post by Peter J. Holzer
Platzbedarf auf Disk ergibt sich aus den Änderungen zwischen einem
Snapshot und dem nächsten bzw. der aktuellen Version. Wenn Du ein File
löschst, dann belegt es im Snapshot weiterhin Platz. Wenn Du es änderst,
bleiben (mindestens) die alten Datenblöcke erhalten.
Das ist auch ein praktisches Problem mit Snapshots: Sie können
"vollaufen", selbst wenn ihr zugrundeligendes Filesystem noch Platz
hätte.

/ralph
Peter J. Holzer
2024-10-19 15:10:30 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Peter J. Holzer
Platzbedarf auf Disk ergibt sich aus den Änderungen zwischen einem
Snapshot und dem nächsten bzw. der aktuellen Version. Wenn Du ein File
löschst, dann belegt es im Snapshot weiterhin Platz. Wenn Du es änderst,
bleiben (mindestens) die alten Datenblöcke erhalten.
Das ist auch ein praktisches Problem mit Snapshots: Sie können
"vollaufen", selbst wenn ihr zugrundeligendes Filesystem noch Platz
hätte.
Das könnte man dadurch lösen, indem man automatisieret jeweils den
ältesten Snapshot freigibt, wenn der freie Platz unter x% fällt[1]. Ist
natürlich Abwägungssache, was man im Zweifelsfall lieber riskiert: Einen
Systemstillstand wegen einer vollen Disk oder die Unfähigkeit, auf
Snapshots zurückzugreifen.

hp

[1] Ganz ohne Snapshots mache ich das z.B. bei manchen Logfiles so.
Siehe https://github.com/hjp/keepfree (Hmm, zumindest ein Minimum an
Doku würde nicht schaden).
Ulli Horlacher
2024-10-19 15:11:12 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Peter J. Holzer
Platzbedarf auf Disk ergibt sich aus den Änderungen zwischen einem
Snapshot und dem nächsten bzw. der aktuellen Version. Wenn Du ein File
löschst, dann belegt es im Snapshot weiterhin Platz. Wenn Du es änderst,
bleiben (mindestens) die alten Datenblöcke erhalten.
Das ist auch ein praktisches Problem mit Snapshots: Sie können
"vollaufen", selbst wenn ihr zugrundeligendes Filesystem noch Platz
hätte.
Nein.
df zeigt immer den realen freien Platzan.
Was allerdings zutrifft: ein einfaches rm schafft nicht unbedingt
zusaetzlichen freien Platz. Da muss dann u.U. snapshots geloescht werden.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Ralph Aichinger
2024-10-19 15:19:14 UTC
Antworten
Permalink
Post by Ulli Horlacher
Nein.
df zeigt immer den realen freien Platzan.
Je nach verwendetem Filesystem und Art des Snapshots. Bei LVM-Snapshots
z.B. kann das gesnapshottete Filesystem noch genug Platz frei haben,
und das auch anzeigen, aber der Snapshot trotzdem vollaufen, weil man
nicht genug Platz dafür reserviert hat, siehe z.B.:

https://askubuntu.com/questions/809581/how-do-i-find-out-how-full-an-lvm-snapshot-really-is

/ralph
Ulli Horlacher
2024-10-19 15:48:07 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Ulli Horlacher
Nein.
df zeigt immer den realen freien Platzan.
Je nach verwendetem Filesystem und Art des Snapshots. Bei LVM-Snapshots
z.B. kann das gesnapshottete Filesystem noch genug Platz frei haben,
und das auch anzeigen, aber der Snapshot trotzdem vollaufen, weil man
nicht genug Platz dafür reserviert hat
Einer der vielen Gruende warum ich LVM nicht mag und auch nicht verwende.
LVM nimmt man nur, wenn man ein Filesystem verwenden muss, das selber
keine Snapshot-Funktionalitet bietet, zb bei Redhat.
LVM ist veraltete Technologie ausm letzten Jahrtausend, erfunden von IBM
in den 1980ern.
Sun hatte was aehnliches mit Solstice Disk Suite und hat dann folgerichtig
dessen Funktionalitaet ins Filesystem (ZFS) integriert, wo es auch
hingehoert.
LVM ist also eine Kruecke, im besten Fall ein Workaround fuer veraltete
Filesysteme.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marc Haber
2024-10-19 17:29:39 UTC
Antworten
Permalink
Post by Ulli Horlacher
Einer der vielen Gruende warum ich LVM nicht mag und auch nicht verwende.
LVM nimmt man nur, wenn man ein Filesystem verwenden muss, das selber
keine Snapshot-Funktionalitet bietet, zb bei Redhat.
Du hast also auf jedem System nur EIN ZFS?

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Ulli Horlacher
2024-10-19 22:50:03 UTC
Antworten
Permalink
Post by Marc Haber
Post by Ulli Horlacher
Einer der vielen Gruende warum ich LVM nicht mag und auch nicht verwende.
LVM nimmt man nur, wenn man ein Filesystem verwenden muss, das selber
keine Snapshot-Funktionalitet bietet, zb bei Redhat.
Du hast also auf jedem System nur EIN ZFS?
2 x btrfs: / und /local

ZFS bietet mir zuwenig Zusatzfeatures, als dass es den Mehraufwand wert
waere.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Peter J. Holzer
2024-10-19 16:27:06 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Ulli Horlacher
df zeigt immer den realen freien Platzan.
Je nach verwendetem Filesystem und Art des Snapshots. Bei LVM-Snapshots
z.B. kann das gesnapshottete Filesystem noch genug Platz frei haben,
und das auch anzeigen, aber der Snapshot trotzdem vollaufen, weil man
Da ist der Snapshot aber nicht Bestandteil des Filesystems, sondern der
darunterliegenden Storage. Da muss man natürlich diese monitoren.

Das ist jetzt auch nicht spezifisch für Snapshots, sondern gilt z.B.
auch für Sparse Storage - ob nun für VMs oder bei Storage-Systemen (EMC,
NetApp und Co haben das Feature seinerzeit recht enthusiastisch
beworben). Bei einer VM haben wir das Problem in unregelmäßigen
Abständen: Das Image wurde vom zuständigen Admin nicht nur viel größer
als notwendig sondern auch größer als das darunterliegende Filesystem
angelegt. Macht nichts, braucht ja keinen Platz. Nur vergisst er dann
immer vor größeren Aktionen, nachzusehen, ob das Filesystem darunter
noch genug freien Platz hat ...

hp
Ulli Horlacher
2024-10-19 10:48:01 UTC
Antworten
Permalink
Post by Sieghard Schicktanz
Post by Ulli Horlacher
Snapshots haben mich mehr als nur einmal gerettet.
Im Gegensatz zum klassischen backup, das man maximal taeglich macht und
das Zeit und massiv Ressourcen benoetigt sind Snapshots in quasi Nullzeit
Dumme Frage nebenbei: Wie steht das bei den "Snapshots" mit den Ressourcen,
die Du gegenüber dem Zeitbedarf leider nicht erwähnst? Ist da der Bedarf
auch 0? Oder zumindest "quasi 0"?
Zum Zeitpunkt des Anlegens: ja.
Erst wenn sich spaeter was aendert, belegen diese Aenderungen Platz.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Ulli Horlacher
2024-10-17 22:09:05 UTC
Antworten
Permalink
Post by Stefan Reuther
Post by Ulli Horlacher
Dann ist die aber nicht boot-faehig, also hast du kein desaster-recovery.
Ok, "besser als nix", aber ich bervorzuge boot-faehige backups.
So hab ich dann innerhalb von Minuten mein System wieder am laufen.
Der erste Schritt nach dem Backup-Fall ist eh der Weg zum lokalen
Computerladen. Da kommt's auf die 20 Minuten für die Debian-Installation
dann auch nicht mehr an.
Ersatzplatten hab ich sowieso vorraetig, notfalls kann ich sogar direkt
mit dem Backup-Medium weiterarbeiten, es ist ja bootfaehig.

Eine Neuinstallation ist ja nicht mal 10% von der Arbeit bis man wieder ein
funktionierendes System hat.
Post by Stefan Reuther
Post by Ulli Horlacher
Ich mach das ueber snapshots, so brauch ich nur eine externe Platte und
viel weniger Speicherplatz.
Externe Platten sterben halt auch immer mal
Das merkt man beim backup schreiben. Dann nimmt man halt ein anderes Medium.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marcel Mueller
2024-10-16 17:59:46 UTC
Antworten
Permalink
Post by Stefan Reuther
Das Backup-Konzept für meinen Desktop-PC lautet: immer mal am
Grabbeltisch eine externe Platte mitnehmen, 'rsync' auf eine solche
Platte, immer durchrotieren. Manche Platten mit NTFS, manche mit ext4,
Von NTFS kannst du ein Linux-System aber nicht wiederherstellen. Da
fehlen doch etliche Features, beginnend mit den Rechten über
Device-Dateien bis zu den verschiedenen Link-Sorten manche gehen
mittlerweile, aber geht das auch durch alle Schichten durch?
Post by Stefan Reuther
NTFS vs. ext4 ist ein deutlicher Unterschied der Geschwindigkeit, 2-3h
vs. <1h, und auch ein deutlicher Unterschied in der Benutzbarkeit
während des Backups (beim Backup auf NTFS klemmt zwischendrin
gelegentlich mal die GUI).
Ich denke über eine Fritz-Box würde es deutlich länger dauern. Man hört
immer wieder, dass deren File-Sharing eher lahm ist. Da dürfte einfach
die CPU etwas begrenzt sein. Kann natürlich auch an NTFS-3g liegen.
Aber ein TB über GBit LAN sind ohnehin schon Netto 3 Stunden.
Post by Stefan Reuther
Das wird vor allem dadurch verursacht, dass der NTFS-3g-Treiber mit FUSE
implementiert ist. Wenn du einen Kernel-NTFS-Treiber hast, dürfte es
deutlich besser funktionieren.
Die Option ist wohl eher theoretisch.

Tatsächlich nehme ich eher rsnapshot (setzt auf rsync). Die
Deduplizierung beschleunigt das Backup drastisch. Das dauert hier eher
10-15 Minuten. (SSD -> USB3 -> IronWolf Pro)
Jetzt kann man zwar argumentieren, dass dadurch ja gerade die Redundanz
untergraben wird. Aber als Redundanz zählt für mich eigentlich nur die
Anzahl der unterschiedlichen Datenträger und nicht x Kopien auf
demselben Datenträger.


Marcel
Ralph Aichinger
2024-10-16 18:01:28 UTC
Antworten
Permalink
Post by Marcel Mueller
Von NTFS kannst du ein Linux-System aber nicht wiederherstellen. Da
fehlen doch etliche Features, beginnend mit den Rechten über
Device-Dateien bis zu den verschiedenen Link-Sorten manche gehen
mittlerweile, aber geht das auch durch alle Schichten durch?
Man kann z.B. tar oder ein Backup-Format verwenden.

/ralph
Bonita Montero
2024-10-19 12:48:04 UTC
Antworten
Permalink
Post by Stefan Reuther
Das wird vor allem dadurch verursacht, dass der NTFS-3g-Treiber mit
FUSE implementiert ist. Wenn du einen Kernel-NTFS-Treiber hast, dürfte
es deutlich besser funktionieren.
Das macht sich aber nur bei Operationen bemerkbar die aus dem Cache
bedient werden. Sonst ist die Verzögerung durch das I/O maßgeblich.
Bernd Mayer
2024-10-16 15:16:10 UTC
Antworten
Permalink
Post by Thomas Lichter
Hallo NG!
Seit einiger Zeit habe ich alle meine PC`s auf Linux umgestellt.
Nun überlege ich die per USB3 an meine Fritzbox angeklemmte Externe
Festplatte (Die Platte fungiert also als NAS) von NTFS auf Ext4 zu
formatieren.
Da die Platte (4T) etwa 1T Daten enthält,die natürlich vorher gesichert
werden müssten, ein nicht ganz unerheblicher Aufwand.
Hallo,

bleibt bei NTFS denn das Erstellungs- und Änderungsdatum einer Datei
erhalten wenn die von einem Linux-PC kommt?


Bernd Mayer
Joerg Walther
2024-10-17 09:21:02 UTC
Antworten
Permalink
Post by Bernd Mayer
bleibt bei NTFS denn das Erstellungs- und Änderungsdatum einer Datei
erhalten wenn die von einem Linux-PC kommt?
Das kommt darauf an, mit welchem Programm kopiert wird, bei cp kann man
das zb mit --preserve=timestamps erzwingen, Ähnliches dürfte es bei
anderen Programmen geben.

-jw-
--
And now for something completely different...
Bernd Mayer
2024-10-17 09:38:21 UTC
Antworten
Permalink
Post by Joerg Walther
Post by Bernd Mayer
bleibt bei NTFS denn das Erstellungs- und Änderungsdatum einer Datei
erhalten wenn die von einem Linux-PC kommt?
Das kommt darauf an, mit welchem Programm kopiert wird, bei cp kann man
das zb mit --preserve=timestamps erzwingen, Ähnliches dürfte es bei
anderen Programmen geben.
-jw-
Hallo,

bei rsync habe ich jetzt auch mehrere Optionen dafür gefunden.
Die muss ich noch antesten.

Externe Festplatten für Backupzwecke habe ich alle mit
Linux-Dateisystemen neu formatiert.

Danke


Bernd Mayer
Michael Logies
2024-10-19 11:25:43 UTC
Antworten
Permalink
Ich nutze unter MX Linux Timeshift zur Sicherung auf eine direkt
angeschlossene USB-SSD. Timeshift sichert nur auf Ext4, nicht auf
NTFS.
Marc Haber
2024-10-19 12:45:22 UTC
Antworten
Permalink
Post by Michael Logies
Ich nutze unter MX Linux Timeshift zur Sicherung auf eine direkt
angeschlossene USB-SSD. Timeshift sichert nur auf Ext4, nicht auf
NTFS.
Was genau ist dann der Vorteil von Timeshift?
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Michael Logies
2024-10-19 13:10:06 UTC
Antworten
Permalink
On Sat, 19 Oct 2024 14:45:22 +0200, Marc Haber
Post by Marc Haber
Post by Michael Logies
Ich nutze unter MX Linux Timeshift zur Sicherung auf eine direkt
angeschlossene USB-SSD. Timeshift sichert nur auf Ext4, nicht auf
NTFS.
Was genau ist dann der Vorteil von Timeshift?
Timeshift (fürs System) wird neben Luckybackup (Nutzerdaten) von MX
Linux mitgeliefert. Sind offenkundig die bevorzugten
Sicherungsprogramme der Distribution. Habe mit Timeshift auch schon
mehrmals mein MX Linux erfolgreich in einen früheren Zustand
zurückgesetzt.

Grüße

M.
Marc Haber
2024-10-19 17:30:50 UTC
Antworten
Permalink
Post by Michael Logies
On Sat, 19 Oct 2024 14:45:22 +0200, Marc Haber
Post by Marc Haber
Post by Michael Logies
Ich nutze unter MX Linux Timeshift zur Sicherung auf eine direkt
angeschlossene USB-SSD. Timeshift sichert nur auf Ext4, nicht auf
NTFS.
Was genau ist dann der Vorteil von Timeshift?
Timeshift (fürs System) wird neben Luckybackup (Nutzerdaten) von MX
Linux mitgeliefert. Sind offenkundig die bevorzugten
Sicherungsprogramme der Distribution. Habe mit Timeshift auch schon
mehrmals mein MX Linux erfolgreich in einen früheren Zustand
zurückgesetzt.
Also noch eine NIH-Lösung.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Michael Logies
2024-10-19 21:20:50 UTC
Antworten
Permalink
On Sat, 19 Oct 2024 19:30:50 +0200, Marc Haber
Post by Marc Haber
Post by Michael Logies
Post by Marc Haber
Was genau ist dann der Vorteil von Timeshift?
Timeshift (fürs System) wird neben Luckybackup (Nutzerdaten) von MX
Linux mitgeliefert. Sind offenkundig die bevorzugten
Sicherungsprogramme der Distribution. Habe mit Timeshift auch schon
mehrmals mein MX Linux erfolgreich in einen früheren Zustand
zurückgesetzt.
Also noch eine NIH-Lösung.
Timeshift gibt es seit diversen Jahren, wohl ursprünglich für Linux
Mint: https://wiki.archlinux.org/title/Timeshift

Ich weiß nicht, was daran in Bezug auf MX Linux dann darauf verweisen
würde, daß MX Linux am NIH-Syndrom leiden würde.

Timeshift ist wie Luckybackup eine anfängerfreundliche Lösung, was man
von Lösungen auf Dateisystemebene (Btrfs, ZFS) nun wirklich nicht
behaupten kann, weshalb ich auch aufgegeben habe, mich mit letzteren
zu beschäftigen.

Grüße

M.
Ralph Aichinger
2024-10-20 08:27:47 UTC
Antworten
Permalink
Post by Michael Logies
Timeshift ist wie Luckybackup eine anfängerfreundliche Lösung, was man
Timeshift ist halt eine von etlichen Lösungen die genau das gleiche
implementieren (und ich weiß nicht, ob rsnapshot oder Apple dieses
Prinzip zuerst popularisiert hat). Andere sind rsnapshot, restic, borg,
duplicity, duplicati, ...

Es gibt einfach zu viel Backupsoftware unter Linux, und zu wenig gute,
zu wenig Standardisierung, zu wenig Integration in andere Projekte.

https://github.com/restic/others

Das Problem bei Backupsoftware ist, das es fast jeder hinkriegt, ein
MVP für Backup hinkriegt, und 90% der Lösungen genau dort stehenbleiben.

/ralph
Ulli Horlacher
2024-10-20 08:51:58 UTC
Antworten
Permalink
Post by Ralph Aichinger
Timeshift ist halt eine von etlichen Lösungen die genau das gleiche
implementieren (und ich weiß nicht, ob rsnapshot oder Apple dieses
Prinzip zuerst popularisiert hat). Andere sind rsnapshot, restic, borg,
duplicity, duplicati, ...
Das Hauptproblem ist, dass keines dieser Open Source backup tools alle
Linux Dateiattribute sichern und restaurieren kann.
Ausserdem ist keines snapshot-konsistent. d.h. Dateien die waehrend des
backup-Laufs beschrieben werden sind unweigerlich kaputt (im Backup).
Diese Programme machen also alle nur "so ein bisschen backup".

https://fex.belwue.de/Vortrag/backup/programme.html
Post by Ralph Aichinger
Es gibt einfach zu viel Backupsoftware unter Linux, und zu wenig gute,
zu wenig Standardisierung, zu wenig Integration in andere Projekte.
https://github.com/restic/others
Fuer restic hab ich (notgedrungen) einen wrapper geschrieben der auch die
chattr Attribute sichern+restaurieren kann:

https://fex.belwue.de/restix.html
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Ralph Aichinger
2024-10-20 09:57:20 UTC
Antworten
Permalink
Post by Ulli Horlacher
Das Hauptproblem ist, dass keines dieser Open Source backup tools alle
Linux Dateiattribute sichern und restaurieren kann.
Das ist IMHO ein eher theoretisches Problem. Welche Attribute die nicht
gesichert werden sind für dich praktisch relevant? Ich seh Leute
"chattr" z.B. immer nur für genau eine einzige Sache verwenden,
nämlich als Workaround für Dateien die vor dem Überschreiben durch den
Besitzer oder schlecht designte Programme bewahrt werden sollen.

Oder geht es dir um so Sachen wie das Zugriffsdatum?
Post by Ulli Horlacher
Ausserdem ist keines snapshot-konsistent. d.h. Dateien die waehrend des
backup-Laufs beschrieben werden sind unweigerlich kaputt (im Backup).
Diese Programme machen also alle nur "so ein bisschen backup".
Ja, aber ist das ein *praktisches* Problem? Die Praxis Backups ohne
Snapshots zu machen wir von vielen seit Ewigkeiten verwendet, ohne
schlimme Konsequenzen. Ja, Datenbanken sollte man u.U. separat dumpen,
und den Dump dann backuppen.
Post by Ulli Horlacher
Fuer restic hab ich (notgedrungen) einen wrapper geschrieben der auch die
https://fex.belwue.de/restix.html
Wo sind die in der Praxis relevant?

/ralph
Ulli Horlacher
2024-10-20 21:49:59 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Ulli Horlacher
Das Hauptproblem ist, dass keines dieser Open Source backup tools alle
Linux Dateiattribute sichern und restaurieren kann.
Das ist IMHO ein eher theoretisches Problem. Welche Attribute die nicht
gesichert werden sind für dich praktisch relevant?
Die Frage ist irrelevant, Linux bietet 24 chattr Attribute und ein
vollwertiges Backup-Programm sollte die auch alle sichern+restaurieren
koennen.

Genauso gut koennte man fragen, wozu braucht es mehr als alphanumerische
Zeichen fuer Dateinamen.
Post by Ralph Aichinger
Post by Ulli Horlacher
Ausserdem ist keines snapshot-konsistent. d.h. Dateien die waehrend des
backup-Laufs beschrieben werden sind unweigerlich kaputt (im Backup).
Diese Programme machen also alle nur "so ein bisschen backup".
Ja, aber ist das ein *praktisches* Problem?
JA!
Post by Ralph Aichinger
Post by Ulli Horlacher
Fuer restic hab ich (notgedrungen) einen wrapper geschrieben der auch die
https://fex.belwue.de/restix.html
Wo sind die in der Praxis relevant?
Bei meinen Usern.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Arno Welzel
2024-10-20 23:24:37 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Ralph Aichinger
Post by Ulli Horlacher
Das Hauptproblem ist, dass keines dieser Open Source backup tools alle
Linux Dateiattribute sichern und restaurieren kann.
Das ist IMHO ein eher theoretisches Problem. Welche Attribute die nicht
gesichert werden sind für dich praktisch relevant?
Die Frage ist irrelevant, Linux bietet 24 chattr Attribute und ein
vollwertiges Backup-Programm sollte die auch alle sichern+restaurieren
koennen.
Da nicht alle Attribute durch Programme gesetzt werden können (z.B. x
oder Z), ist diese Forderung so pauschal wenig sinnvoll.
Post by Ulli Horlacher
Genauso gut koennte man fragen, wozu braucht es mehr als alphanumerische
Zeichen fuer Dateinamen.
Ja, das frage ich mich in der Tat. Sowas macht gerade beim Austausch von
Dateien zwischen verschiedenen Systemen enorm Probleme. Ebenso, wenn
nicht klar ist, wie Zeichen mit nationalen Symbolen codiert wurden.

Wenn man regelmäßig Dateien zwischen Linux, Windows und macOS
austauschen muss, sieht man das etwas strikter.
--
Arno Welzel
https://arnowelzel.de
Ralph Aichinger
2024-10-21 05:07:40 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Ralph Aichinger
Wo sind die in der Praxis relevant?
Bei meinen Usern.
Und welche Software/welche konkrete Anwendung betrifft das?

/ralph
Arno Welzel
2024-10-20 14:00:35 UTC
Antworten
Permalink
Post by Ulli Horlacher
Post by Ralph Aichinger
Timeshift ist halt eine von etlichen Lösungen die genau das gleiche
implementieren (und ich weiß nicht, ob rsnapshot oder Apple dieses
Prinzip zuerst popularisiert hat). Andere sind rsnapshot, restic, borg,
duplicity, duplicati, ...
Das Hauptproblem ist, dass keines dieser Open Source backup tools alle
Linux Dateiattribute sichern und restaurieren kann.
Ausserdem ist keines snapshot-konsistent. d.h. Dateien die waehrend des
backup-Laufs beschrieben werden sind unweigerlich kaputt (im Backup).
Diese Programme machen also alle nur "so ein bisschen backup".
https://fex.belwue.de/Vortrag/backup/programme.html
Genau deshalb sorgt man bei diesen Dateien dafür, dass sie anderweitig
in einem konsistenten Zustand gesichert werden - primär Datenbanken oder
Mailserver.

Von einer Datenbank wird man selbstverständlich das dort vorgesehene
Tool zur Sicherung nehmen und dann die so erzeugten Daten sichern und
nicht die Datenbankdateien selbst im laufenden Betrieb. Daran ändert
auch ein Dateisystem mit Snapshot nichts, denn auch da darf man nicht
einfach irgendeinen Zustand der Datenbank einfrieren und dann so tun,
als wäre das eine "Sicherung".

Ebenso ist es auch oft sinnvoll, Infrastruktur automatisiert aufzubauen,
z.B. mit Terraform oder Ansible, anstatt Server vom Hand
zusammenzubasteln und dann nachträglich zu versuchen, das möglichst
vollständig zu sichern. In die gleiche Kerbe schlagen Docker und
Kubernetes - weg von manuelle Administration einzelner Server hin zu
definierten Umgebungen, deren vorgesehener Zustand schon *vor* dem
Betrieb festgelegt wird.
--
Arno Welzel
https://arnowelzel.de
Diedrich Ehlerding
2024-10-20 14:39:27 UTC
Antworten
Permalink
Post by Arno Welzel
Von einer Datenbank wird man selbstverständlich das dort vorgesehene
Tool zur Sicherung nehmen und dann die so erzeugten Daten sichern und
nicht die Datenbankdateien selbst im laufenden Betrieb. Daran ändert
auch ein Dateisystem mit Snapshot nichts, denn auch da darf man nicht
einfach irgendeinen Zustand der Datenbank einfrieren und dann so tun,
als wäre das eine "Sicherung".
Je nach Datenbanksystem geht das durchaus. (BTDT mit Oracle-
Datenbanken).
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Ralph Aichinger
2024-10-20 16:15:27 UTC
Antworten
Permalink
Post by Diedrich Ehlerding
Post by Arno Welzel
auch ein Dateisystem mit Snapshot nichts, denn auch da darf man nicht
einfach irgendeinen Zustand der Datenbank einfrieren und dann so tun,
als wäre das eine "Sicherung".
Je nach Datenbanksystem geht das durchaus. (BTDT mit Oracle-
Datenbanken).
Ja, nur warum sollte man das absichtlich tun? Bei jeder halbwegs
wichtigen Datenbank die ich jemals in Firmen gesehen hab, war irgendeine
Form von nächtlichem/wöchentlichem Dump-Job implementiert, der das
ganze in eine Datei rausgeschrieben hat. Zumindest bei den relationalen,
mit SQL.

/ralph
Peter J. Holzer
2024-10-20 17:04:36 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Diedrich Ehlerding
Post by Arno Welzel
auch ein Dateisystem mit Snapshot nichts, denn auch da darf man nicht
einfach irgendeinen Zustand der Datenbank einfrieren und dann so tun,
als wäre das eine "Sicherung".
Je nach Datenbanksystem geht das durchaus. (BTDT mit Oracle-
Datenbanken).
Wobei "ich habe das schon mal gemacht und es hat funktioniert" keine
Garantie ist, dass es immer funktioniert. Aber ja, Oracle, PostgreSQL
und Co. garantieren auch, dass das funktioniert, da ist man nicht nur
auf Glück angewiesen.
Post by Ralph Aichinger
Ja, nur warum sollte man das absichtlich tun? Bei jeder halbwegs
wichtigen Datenbank die ich jemals in Firmen gesehen hab, war irgendeine
Form von nächtlichem/wöchentlichem Dump-Job implementiert, der das
ganze in eine Datei rausgeschrieben hat.
Ich dachte immer, wir sind altmodisch, weil wir das so machen ;-)

Jede Nacht einen kompletten Dump zu schreiben, dauert halt und das
Restore dauert noch länger (Bei der größten von "meinen" Datenbanken
dauert der Dump derzeit 2¾ Stunden. Und mit 1.5TB ist die jetzt noch
nicht wirklich groß).

Ein Snapshot hingegen ist in nahezu Nullzeit gezogen und (fast) sofort
einsatzbereit (die Datenbank muss beim Start das Journal nachziehen aber
das sollte in den meisten Fällen Sekunden oder höchstens ein paar
Minuten dauern). Wenn man im Fall des Falles Downtime minimieren will,
ist das nicht zu verachten. Die Snapshots kann man auch z.B. zum Testen
verwenden.
Post by Ralph Aichinger
Zumindest bei den relationalen, mit SQL.
Da gibt es oft (zumindest bei Oracle und PostgreSQL) noch eine weitere
Möglichkeit: Ein regelmäßiger Snapshot (mit Datenbank-Mitteln, *kein*
Filesystem-Snapshot) kombiniert mit den kontinuierlich weggesicherten
Journals. Das erlaubt Point in Time Recovery auf jeden beliebigen
Zeitpunkt. Wenn man also den Zustand herstellen will, der eine
Zehntel-Sekunde vor dem verhängnisvollen Klick auf den falschen Button
geherrscht hat, ist das das Mittel der Wahl. Hier geht das Backup auch
sehr schnell, aber das Restore kann dauern.

hp
Andreas M. Kirchwitz
2024-10-20 19:34:58 UTC
Antworten
Permalink
Post by Peter J. Holzer
Wobei "ich habe das schon mal gemacht und es hat funktioniert" keine
Garantie ist, dass es immer funktioniert. Aber ja, Oracle, PostgreSQL
und Co. garantieren auch, dass das funktioniert, da ist man nicht nur
auf Glück angewiesen.
Kann man das nachlesen? Ich finde spontan, man solle die
Datenbank in den Backup-Modus oder etwas Vergleichbares setzen,
ansonsten geht zwar nicht die Datenbank den Bach runter, aber die
letzten Operationen können problematisch sein, außer der Storage
ist auf eine ganz bestimmte Weise organisiert.

Eine pauschale Garantie kann ich bei Oracle, PostgreSQL und Co.
nicht finden, dass Snapshots immer problemlos funktionieren,
eher im Gegenteil finde ich Einschränkungen und Warnungen.
Vor allem Oracle ist in seiner Dokumentation überhaupt kein
großer Fan von Filesystem-Snapshots.

Ja, Snapshots können viel größere Katastrophen verhindern,
das wissen wir aus dem Alltag, aber ganz sauber ist das in
der Regel trotzdem nicht.

Grüße, Andreas
Diedrich Ehlerding
2024-10-21 06:57:20 UTC
Antworten
Permalink
Post by Andreas M. Kirchwitz
Kann man das nachlesen? Ich finde spontan, man solle die
Datenbank in den Backup-Modus oder etwas Vergleichbares setzen,
ansonsten geht zwar nicht die Datenbank den Bach runter, aber die
letzten Operationen können problematisch sein, außer der Storage
ist auf eine ganz bestimmte Weise organisiert.
Das Ganze ist ca 10 Jahre her. Ob/Wo das nachzulesen ist/war, kann ich
dir nicht sagen; es war damals aber mit Oracle abgesprochen, dass es
geht. Ich war der, der das Raidsystem verwaltet hat; den Oracle-Teil und
auch die Diskussion mit Oracle haben andere gemacht.

Ja, natürlich muss man sich Gedanken machen, was gesnapshottet wird und
was nicht. Und ja, man muss natürlich alles zeitlich atomar snapshotten,
nicht Datenbankfile für Datenbankfile, also entweder einen Snapshot für
das ganze Filesystem oder einen zeitlich atomar gleichzeitigen Snapshot
für alle Devices, auf denen die Datenbank liegt; dafür hatten wir damals
sauteure EMC-Boxen, aber die konnten das.
Ja, man muss sich dafür überlegen, welche Daten man wohin legt und
welche man snapshottet und welche nicht - die Archive-Logs will man zum
Beiuspiel nicht auf den Snapshotzeitpunkt zurücksetzen
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Peter J. Holzer
2024-10-21 10:11:07 UTC
Antworten
Permalink
Post by Andreas M. Kirchwitz
Post by Peter J. Holzer
Wobei "ich habe das schon mal gemacht und es hat funktioniert" keine
Garantie ist, dass es immer funktioniert. Aber ja, Oracle, PostgreSQL
und Co. garantieren auch, dass das funktioniert, da ist man nicht nur
auf Glück angewiesen.
Kann man das nachlesen? Ich finde spontan, man solle die
Datenbank in den Backup-Modus oder etwas Vergleichbares setzen,
ansonsten geht zwar nicht die Datenbank den Bach runter, aber die
letzten Operationen können problematisch sein, außer der Storage
ist auf eine ganz bestimmte Weise organisiert.
Eine pauschale Garantie kann ich bei Oracle, PostgreSQL und Co.
nicht finden, dass Snapshots immer problemlos funktionieren,
Sie garantieren, dass die Datenbank nach einem System-Crash wieder in
einem konsistenten Zustand hochkommen.

Z.B. https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-FSYNC
| This ensures that the database cluster can recover to a consistent
| state after an operating system or hardware crash.

Ein Snapshot ist im Prinzip das gleiche wie ein Crash, aber
kontrollierter, weil da nur das Betriebssystem das richtige tun muss,
und man nicht noch darauf angewiesen ist, dass Controller und Disks auch
das machen, was sie sollten.

Wichtiges Caveat: Der Snapshot muss *alle* Dateien enthalten, die man
für das Recovery braucht. Wenn man z.B. die WALs auf einem anderen
Filesystem hat als die Datenfiles, oder die Daten auf verschiedene
Tablespaces auf verschiedenen Filesystemem aufgeteilt hat, dann gilt die
Garantie nur dann, wenn das System einen atomaren Snapshot über alle
betroffenen Filesysteme machen kann. (Wir hatten mal den Fall dass eine
Datenbank auf zwei Volume Groups aufgeteilt war. Der Backup-Admin konnte
nicht belegen, dass VEEAM in diesem Fall einen atomaren Snapshot machen
kann, also habe ich ein Image-basiertes Backup abgelehnt.)

hp
Diedrich Ehlerding
2024-10-20 19:05:40 UTC
Antworten
Permalink
Post by Ralph Aichinger
Ja, nur warum sollte man das absichtlich tun? Bei jeder halbwegs
wichtigen Datenbank die ich jemals in Firmen gesehen hab, war
irgendeine Form von nächtlichem/wöchentlichem Dump-Job implementiert,
der das ganze in eine Datei rausgeschrieben hat. Zumindest bei den
relationalen, mit SQL.
Es gab dafür einen Grund, nämlich dass der Restore schnell sein sollte.
Auf einen Restore der Datenbank aus so einem Dump hätte man im Ernstfall
nicht warten können; die Datenbanken waren etwas größer. Ursprünglich
lief das Ganze auf Solaris, später auch auf Linux, Umfeld war SAP (noch
nicht HANA). Und natürlich war von "nachts hat man ja Zeit zum Backup"
keine Rede, der Betrieb lief auch nachts.

Erzeugt wurden da Snapshots auf Hardware-Basis in einem externen
Raidsystem, mehrere Generationen im Raisdystem (meiner Erinnerung nach 2
oder 3 Generationen pro Standort, und die Daten waren (auch über die
Raidsystemne) standortübergreifend gespiegelt - auch im Fall eines
Brandes sollte es schnell weitergehen können). Nicht täglich, nicht
wöchentlich, mehrmals am Tag - auch die im Ernstfall noch anfallenden
Rollforward-Zeiten mussten in Grenzen gehalten werden, wenn man
tatsächlich restoren musste. Das Raidsystem konnte zeitlich "atomare"
Snapshots über mehrere logische Platten, die es dem Host rausreichte,
erzeugen. Anfangs haben wir die Oracle-Datenbamk dazu noch in den
Backupmopde versetzt, aber nach einiger Diskussion mit Oracle waren sich
alle darüber einig: wenn man das geschickt organisiert, also Redologs
und Archivelogs auf die richtigen Platten verteilt (die Archivelogs
wurden natürlich nicht in diesen zeitlich atomaren Snapshot einbezogen),
dann kann man auf so einem Snapshot genb´auso wieder anlaufen wie auf
einem Zustand bei Stromausfall, und die Oraclianer haben es auch
hinbekommen, auf diesem Zustand später angefallene redologs
nachzufahren.

Der Witz des Ganzen war, dass das Raidsystem bei einem SNap-Rollback
sofort wieder auf dem alten Stand war (vom Host aus gesehen), wenn auch
ggf. etwas langsamer (d.h. der Restore lief im Backend des
Rauidsystems,für den Server wars dann etwas langsamer, das Raidsystem
hatte ja damit zu tun, die Snaps zurückzufahren; aber der Rollforward
konnte schon beginnen). Damit waren wir damals dann in der Lage, eine
Datenbank von mehreren Terabyte innerhalb von ca 5-10 Minuten soweit zu
restoren, so dass der Rollforward von Logfiles anfangen konnte.

Ja, auf den ersten Blick klingt das gruselig. Aber das Verfahren wurde
regelmäßig getestet, nämlich einfach dadurch, dass aus diesen Snapshots
auch die SAP-Quaitätssicherungssysteme erzeugt wurden. Und tatsächlich
ist auch einmal ein Fall vorgekommen, wo die SAPler kreidebleich zu den
Admins dieses Verfahrens kamen und sagten "wir haben uns unsere
Datenbank zerschossen, wie schnell könnt ihr welchen Stand wieder
einspielen, wie alt ist die Sicherung?". Die Antwort war "dauert maximal
15 Minuten, ist dann der Stand von vor zwei Stunden". Es war zwar nur
irgendein SAP-Entwicklungssystem, aber die rechneten damit, dass sie
mehrere Zeitverlust hätten hinnehmen müssen ...

Ja, das war eine extrem teure Lösung. Aber Restore innerhalb von 15 min
unabhängig von der Datenbankgröße kostet halt Geld. Und nachdem ich
wusste, wieviel Geld die SAP-Consultants da bekamen, die in Heerscharen
die Kundenlösung bastelten, hatte ich kein schlechtes Gewissen mehr,
teure Hardware zu verwenden, um so was zu bauen.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Andreas M. Kirchwitz
2024-10-20 19:20:11 UTC
Antworten
Permalink
Post by Diedrich Ehlerding
Post by Arno Welzel
Von einer Datenbank wird man selbstverständlich das dort vorgesehene
Tool zur Sicherung nehmen und dann die so erzeugten Daten sichern und
nicht die Datenbankdateien selbst im laufenden Betrieb. Daran ändert
auch ein Dateisystem mit Snapshot nichts, denn auch da darf man nicht
einfach irgendeinen Zustand der Datenbank einfrieren und dann so tun,
als wäre das eine "Sicherung".
Je nach Datenbanksystem geht das durchaus. (BTDT mit Oracle-
Datenbanken).
Eher je nach gewählten Speicherformat, keineswegs pauschal für
ein Datenbanksystem. Wo genau kann man bei Oracle nachlesen,
dass Snapshots unterstützt werden, ohne die Datenbank in den
Backup-Modus zu setzen? Ich lese dort Warnungen, weil Snapshots
auf Filesystem-Level keine Ahnung von der Bedeutung der internen
Strukturen der Datenbank haben.

In der Praxis mag sich eine Oracle-Datenbank davon erholen,
wenn man ihr einen Snapshots vorsetzt. Vielleicht sind einige
der letzten Operation verloren und Daten inkonistent, sofern
Anwendungen sich nicht mit Transaktionen abgesichert haben.

Grüße, Andreas
Arno Welzel
2024-10-20 23:25:47 UTC
Antworten
Permalink
Post by Diedrich Ehlerding
Post by Arno Welzel
Von einer Datenbank wird man selbstverständlich das dort vorgesehene
Tool zur Sicherung nehmen und dann die so erzeugten Daten sichern und
nicht die Datenbankdateien selbst im laufenden Betrieb. Daran ändert
auch ein Dateisystem mit Snapshot nichts, denn auch da darf man nicht
einfach irgendeinen Zustand der Datenbank einfrieren und dann so tun,
als wäre das eine "Sicherung".
Je nach Datenbanksystem geht das durchaus. (BTDT mit Oracle-
Datenbanken).
Gerade bei Oracle würde ich das nicht tun.
--
Arno Welzel
https://arnowelzel.de
Marc Haber
2024-10-21 06:54:25 UTC
Antworten
Permalink
Post by Ralph Aichinger
Post by Michael Logies
Timeshift ist wie Luckybackup eine anfängerfreundliche Lösung, was man
Timeshift ist halt eine von etlichen Lösungen die genau das gleiche
implementieren (und ich weiß nicht, ob rsnapshot oder Apple dieses
Prinzip zuerst popularisiert hat). Andere sind rsnapshot, restic, borg,
duplicity, duplicati, ...
Es gibt einfach zu viel Backupsoftware unter Linux, und zu wenig gute,
zu wenig Standardisierung, zu wenig Integration in andere Projekte.
https://github.com/restic/others
Das Problem bei Backupsoftware ist, das es fast jeder hinkriegt, ein
MVP für Backup hinkriegt, und 90% der Lösungen genau dort stehenbleiben.
Amen. Wir brauchen keine weiteren Backuplösungen, sondern EINE die
funktioniert, und zwar am besten in allen Lebenslagen.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Marc Haber
2024-10-20 08:55:49 UTC
Antworten
Permalink
Post by Michael Logies
Timeshift ist wie Luckybackup eine anfängerfreundliche Lösung, was man
von Lösungen auf Dateisystemebene (Btrfs, ZFS) nun wirklich nicht
behaupten kann, weshalb ich auch aufgegeben habe, mich mit letzteren
zu beschäftigen.
Wie funktioniert timeshift denn genau?
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Michael Logies
2024-10-20 09:06:02 UTC
Antworten
Permalink
On Sun, 20 Oct 2024 10:55:49 +0200, Marc Haber
Post by Marc Haber
Post by Michael Logies
Timeshift ist wie Luckybackup eine anfängerfreundliche Lösung, was man
von Lösungen auf Dateisystemebene (Btrfs, ZFS) nun wirklich nicht
behaupten kann, weshalb ich auch aufgegeben habe, mich mit letzteren
zu beschäftigen.
Wie funktioniert timeshift denn genau?
Das ist eine der vielen GUIs für rsync. Hier mehr:
https://www.linux-community.de/ausgaben/linuxuser/2019/06/zeitsprung/
Aus LinuxUser 06/2019
Snapshots mit Timeshift erstellen
(...)
Timeshift wurde vor sechs Jahren erstmals veröffentlicht und verwendet
zum Erstellen von Snapshots unter der grafischen Oberfläche zwei
Techniken. Basiert die Installation des Betriebssystems auf
herkömmlichen Dateisystemen, greift es zum Spiegeln auf das mächtige
Rsync-Protokoll zurück. Daneben beherrscht die Software aber auch
Snapshots mit Btrfs. Dazu muss das Betriebssystem das Layout mit
Btrfs-Subvolumes [4] unterstützen. Wir testen beide Ansätze.
(...)

Grüße

M.
Marc Haber
2024-10-21 06:56:57 UTC
Antworten
Permalink
Post by Michael Logies
Das ist eine der vielen GUIs für rsync.
Okay. Also immerhin mal beim restore kompatibel mit dem Rest der Welt,
vermutlich ohne Verschlüsselung. Braucht niemand.
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Bernd Mayer
2024-10-20 22:35:44 UTC
Antworten
Permalink
Post by Marc Haber
Post by Michael Logies
Ich nutze unter MX Linux Timeshift zur Sicherung auf eine direkt
angeschlossene USB-SSD. Timeshift sichert nur auf Ext4, nicht auf
NTFS.
Was genau ist dann der Vorteil von Timeshift?
Hallo,

Timeshift ist *sehr* einfach einzustellen über eine GUI.

Die manpage ist auch übersichtlich:
https://commandmasters.com/commands/timeshift-linux/

Bei linuxmint ist das Aktivieren von Timeshift Voraussetzung für ein
dist-upgrade auf eine neuen Version.

Das hatte mich schon mal gestört wegen Platzmangel.
Ich hatte dann Timeshift gestartet und bald danach die Backupdateien von
Timeshift aus gelöscht und konnte dann das dist-upgrade durchführen.


Bernd Mayer
Werner Dominikowski
2024-10-21 06:18:53 UTC
Antworten
Permalink
Post by Bernd Mayer
Bei linuxmint ist das Aktivieren von Timeshift Voraussetzung für ein
dist-upgrade auf eine neuen Version.
nur wenn man die Überpüfung nicht abwählt
Post by Bernd Mayer
Das hatte mich schon mal gestört wegen Platzmangel.
Ich hatte dann Timeshift gestartet und bald danach die Backupdateien von
Timeshift aus gelöscht und konnte dann das dist-upgrade durchführen.
unnötig

Servus, werner
Bernd Mayer
2024-10-21 11:25:22 UTC
Antworten
Permalink
Post by Werner Dominikowski
Post by Bernd Mayer
Bei linuxmint ist das Aktivieren von Timeshift Voraussetzung für ein
dist-upgrade auf eine neuen Version.
nur wenn man die Überpüfung nicht abwählt
Hallo,

wo kann man ds da denn abwählen?


Bernd Mayer
Bernd Mayer
2024-10-21 11:27:58 UTC
Antworten
Permalink
Post by Werner Dominikowski
Post by Bernd Mayer
Bei linuxmint ist das Aktivieren von Timeshift Voraussetzung für ein
dist-upgrade auf eine neuen Version.
nur wenn man die Überpüfung nicht abwählt
Hallo,

wo kann man das denn abwählen?


Bernd Mayer
Werner Dominikowski
2024-10-21 13:14:27 UTC
Antworten
Permalink
Post by Bernd Mayer
Post by Werner Dominikowski
Post by Bernd Mayer
Bei linuxmint ist das Aktivieren von Timeshift Voraussetzung für ein
dist-upgrade auf eine neuen Version.
nur wenn man die Überpüfung nicht abwählt
wo kann man das denn abwählen?
oben, "Hamburgermenü" (drei Striche) Einstellungen

Servus, Werner

Lesen Sie weiter auf narkive:
Loading...