Keine Snapshots mehr möglich 😮

Zitat von friend_of_root

Das ist äußerst attraktiv. Würdest du hier bitte die Schritte noch einmal genauer beschreiben um ZFS zu nutzen.
Im SCP kann man ja ein neues Image mit z.B. Debian aufspielen. Aber an welcher Stelle kann man sich das Dateisystem aussuchen?

Kann man zu jeder Zeit ein dd machen, oder geht dies dann mit einer ZFS Funktionalität?

Hier gibt es zwei kurze Videos, die mir spontan einfallen, um zunächst die Fragen einzuordnen: Grundlegende Hilfestellung/Ausblick und DIY-Voraussetzungen – Diese sollte man keinesfalls überspringen, zumal sie erstaunlicherweise nicht mit den vermuteten Suchbegriffen (ZFS, Dateisystem, Administration) verknüpft sind! (Und das meine ich ernst, falls die Hervorhebung der beiden Worte in diesem Absatz aus irgendeinem Grund nicht gut sichtbar wurde – die beiden Videos setzen den perfekten Ton.)

Während die Nutzung von grundlegenden ZFS-Features wie Snapshots/zusätzlichen Dateikopien/Komprimierung wirklich einfach ist und bei konsequenter Umsetzung unternehmenskritische Vorteile mit sich bringt (Windows-Ransomeware verliert den Schrecken, wenn alle wichtigen Daten nur über NFS-/CIFS-Mounts zugreifbar sind, die von abgeschotteten Nicht-Windows-Servern mit ZFS-Dateisystemen und automatischen Snapshots bedient werden), trifft das auf die Installation in Verbindung mit Linux nicht ganz zu. Die Administration/Wartung ist als durchaus aufwendig einzuschätzen, und die vollständige Planung, Analyse/Bewertung und Umsetzung einer entsprechenden Strategie für den professionellen Einsatz (egal ob privat oder beruflich), welche auch die Nutzung von entfernten virtuellen KVM-Instanzen beinhaltet, kann eine Herausforderung sein – einfach, weil es zu viele zu beachtende Details/Wahlmöglichkeiten gibt, welche anwendungs-/einsatzspezifische Erfahrungswerte bedingen, oder sonst … sind ganz schnell die gespeicherten Informationen verloren. [*]

Nach diesen Vorbemerkungen nun zu den beiden Fragen (man kann hier dutzende von weiterführenden Links einfügen, aber das würde mich jetzt noch eine Stunde kosten):

1. "Dateisystem aussuchen": Hier muss man unterscheiden, ob ZFS direkt auf dem Wurzelverzeichnis "/" zum Einsatz kommen soll (ZFS-on-Root) oder nicht:
   1. Wenn nicht, dann ist der Einsatz grundsätzlich jederzeit möglich, wenn man eine entsprechende Partition oder ein Block-Device hierfür zur Verfügung stellt (eine Dateisystemkonvertierung von bspw. ext4, wie sie Btrfs anbietet, gibt es standardmäßig nicht – die Dateien müssen umkopiert werden!)
   2. ZFS ist bei FreeBSD quasi "direkt an Bord", bei Linux hingegen haben die OpenZFS-Entwickler permanent mit den Linux-Schnittstellen zu kämpfen, sodass die Nutzung der Kombination von Kernel- und ZFS-Paketen eine sorgfältige Planung erfordert und generell nur zeitversetzt erfolgen kann (Fedora-Nutzer wissen hiervon ein Lied zu singen). Die Linux-Distribution, welche hier die beste Unterstützung für die Einbindung der Upstream-OpenZFS-Versionen bietet, ist Ubuntu, welche auch einen entsprechenden Installer mitbringt. Jetzt das große ABER: Canonical passt die Upstream-Versionen (mehr oder weniger zugegebenermaßen notgedrungen) an und hat in der Vergangenheit mit ZSYS ein Hilfswerkzeug erstellt, welches den Nutzer unterstützt, was das Booten von älteren Sicherheitskopien (via Snapshots) erleichtern soll – das wird aber nicht mehr adäquat gewartet. Da es insbesondere bei Dateisystemen wichtig ist, dass man bei Problemen andere Nutzer (derselben/einer vergleichbaren Konfiguration) fragen kann, empfiehlt es sich, die jeweilige stabile Upstream-Version (vor Erscheinen von v2.2.2 wäre das immer noch v2.1.3, wenn der Einstieg zum jetzigen Zeitpunkt erfolgen muss!) zu nutzen – diese ist in der Regel für die eigene Distribution selbst zu übersetzen (und zwar besser in einem isolierten Container oder einer dedizierten Build-Maschine). Ebenfalls zu beachten: Das Netcup-Rettungssystem kann mit ZFS-on-Root nicht umgehen – spätestens an dieser Stelle ist ein eigenes "Rettungs-/Installations-ISO" erforderlich, welches man stattdessen bootet (für Ubuntu bietet sich hier die Modifikation des Standard-Desktop-ISO-Abbilds mittels "cubic" an).
2. "dd oder ZFS-Funktionalität": Im Katastrophenfall, wenn nichts mehr geht, würde man natürlich zunächst vor jeglichen Reparaturbemühungen via "dd" ein 1:1-Abbild wegspeichern – wie in jedem anderen Fall auch; ansonsten bietet ZFS hier alle erforderlichen Werkzeuge, um die Inhalte von Datasets/ZVOLs(=ZFS-Block-Devices) zu sichern/restaurieren. (Da ZFS und Btrfs COW-Dateisysteme sind, ist die interne Dateisystemorganisation natürlich ungleich komplexer, was man bei der Analyse im vorgenannten Katastrophenfall berücksichtigen muss!) Ein "zfs send"-Datenstrom lässt sich hierbei grundsätzlich natürlich auch auf einem Nicht-ZFS-Dateisystem ablegen von dort via "zfs recv" wieder einlesen, eine belastbare Integritätsprüfung ist aber logischerweise immer nur bei/nach dem "zfs recv" möglich.

Bevor man erste Erfahrungen mit der Konfiguration eines eigenen (Linux-)Systems sammelt, empfiehlt es sich unter Umständen, "Komplettlösungen" wie TrueNAS oder Proxmox ins Auge zu fassen, die ZFS "mitbringen", um erste Erfahrungen mit der Nutzung/Konfigurationsanpassung zu sammeln, wodurch man nicht auf die aufwendige eigene Bewertung von möglichen Updates (und deren Anpassung/Installation) angewiesen ist – vorzugsweise auf lokaler, eigener Hardware. Hierfür sollte man die anbietereigenen Foren/Mailinglisten/Anleitungen verfolgen (parallel zu denen von OpenZFS).

Aus dem Obigen sollte man als interessierter Leser/zukünftiger ZFS-Nutzer mitnehmen, dass man sehr viel lesen/lernen muss; direkt ein einzelnes Howto zu verlinken wäre mbMn an dieser Stelle grob fahrlässig und kontraproduktiv.

[*] KMU(-Repräsentanten), welche sich dieser Herausforderung stellen wollen und/oder müssen, aber insbesondere auch die Chancen nutzen wollen, kann ich beruflich gerne zu den branchenüblichen Tagessätzen von der Erstberatung bis zur Umsetzung (ohne "vendor lock-in") unterstützen.

Zitat von m_ueberall

Hier gibt es zwei kurze Videos, die mir spontan einfallen, um zunächst die Fragen einzuordnen: Grundlegende Hilfestellung/Ausblick und DIY-Voraussetzungen – Diese sollte man keinesfalls überspringen, zumal sie erstaunlicherweise nicht mit den vermuteten Suchbegriffen (ZFS, Dateisystem, Administration) verknüpft sind! (Und das meine ich ernst, falls die Hervorhebung der beiden Worte in diesem Absatz aus irgendeinem Grund nicht gut sichtbar wurde – die beiden Videos setzen den perfekten Ton.)

Während die Nutzung von grundlegenden ZFS-Features wie Snapshots/zusätzlichen Dateikopien/Komprimierung wirklich einfach ist und bei konsequenter Umsetzung unternehmenskritische Vorteile mit sich bringt (Windows-Ransomeware verliert den Schrecken, wenn alle wichtigen Daten nur über NFS-/CIFS-Mounts zugreifbar sind, die von abgeschotteten Nicht-Windows-Servern mit ZFS-Dateisystemen und automatischen Snapshots bedient werden), trifft das auf die Installation in Verbindung mit Linux nicht ganz zu. Die Administration/Wartung ist als durchaus aufwendig einzuschätzen, und die vollständige Planung, Analyse/Bewertung und Umsetzung einer entsprechenden Strategie für den professionellen Einsatz (egal ob privat oder beruflich), welche auch die Nutzung von entfernten virtuellen KVM-Instanzen beinhaltet, kann eine Herausforderung sein – einfach, weil es zu viele zu beachtende Details/Wahlmöglichkeiten gibt, welche anwendungs-/einsatzspezifische Erfahrungswerte bedingen, oder sonst … sind ganz schnell die gespeicherten Informationen verloren. [*]

Nach diesen Vorbemerkungen nun zu den beiden Fragen (man kann hier dutzende von weiterführenden Links einfügen, aber das würde mich jetzt noch eine Stunde kosten):

1. "Dateisystem aussuchen": Hier muss man unterscheiden, ob ZFS direkt auf dem Wurzelverzeichnis "/" zum Einsatz kommen soll (ZFS-on-Root) oder nicht:
   1. Wenn nicht, dann ist der Einsatz grundsätzlich jederzeit möglich, wenn man eine entsprechende Partition oder ein Block-Device hierfür zur Verfügung stellt (eine Dateisystemkonvertierung von bspw. ext4, wie sie Btrfs anbietet, gibt es standardmäßig nicht – die Dateien müssen umkopiert werden!)
   2. ZFS ist bei FreeBSD quasi "direkt an Bord", bei Linux hingegen haben die OpenZFS-Entwickler permanent mit den Linux-Schnittstellen zu kämpfen, sodass die Nutzung der Kombination von Kernel- und ZFS-Paketen eine sorgfältige Planung erfordert und generell nur zeitversetzt erfolgen kann (Fedora-Nutzer wissen hiervon ein Lied zu singen). Die Linux-Distribution, welche hier die beste Unterstützung für die Einbindung der Upstream-OpenZFS-Versionen bietet, ist Ubuntu, welche auch einen entsprechenden Installer mitbringt. Jetzt das große ABER: Canonical passt die Upstream-Versionen (mehr oder weniger zugegebenermaßen notgedrungen) an und hat in der Vergangenheit mit ZSYS ein Hilfswerkzeug erstellt, welches den Nutzer unterstützt, was das Booten von älteren Sicherheitskopien (via Snapshots) erleichtern soll – das wird aber nicht mehr adäquat gewartet. Da es insbesondere bei Dateisystemen wichtig ist, dass man bei Problemen andere Nutzer (derselben/einer vergleichbaren Konfiguration) fragen kann, empfiehlt es sich, die jeweilige stabile Upstream-Version (vor Erscheinen von v2.2.2 wäre das immer noch v2.1.3, wenn der Einstieg zum jetzigen Zeitpunkt erfolgen muss!) zu nutzen – diese ist in der Regel für die eigene Distribution selbst zu übersetzen (und zwar besser in einem isolierten Container oder einer dedizierten Build-Maschine). Ebenfalls zu beachten: Das Netcup-Rettungssystem kann mit ZFS-on-Root nicht umgehen – spätestens an dieser Stelle ist ein eigenes "Rettungs-/Installations-ISO" erforderlich, welches man stattdessen bootet (für Ubuntu bietet sich hier die Modifikation des Standard-Desktop-ISO-Abbilds mittels "cubic" an).
2. "dd oder ZFS-Funktionalität": Im Katastrophenfall, wenn nichts mehr geht, würde man natürlich zunächst vor jeglichen Reparaturbemühungen via "dd" ein 1:1-Abbild wegspeichern – wie in jedem anderen Fall auch; ansonsten bietet ZFS hier alle erforderlichen Werkzeuge, um die Inhalte von Datasets/ZVOLs(=ZFS-Block-Devices) zu sichern/restaurieren. (Da ZFS und Btrfs COW-Dateisysteme sind, ist die interne Dateisystemorganisation natürlich ungleich komplexer, was man bei der Analyse im vorgenannten Katastrophenfall berücksichtigen muss!) Ein "zfs send"-Datenstrom lässt sich hierbei grundsätzlich natürlich auch auf einem Nicht-ZFS-Dateisystem ablegen von dort via "zfs recv" wieder einlesen, eine belastbare Integritätsprüfung ist aber logischerweise immer nur bei/nach dem "zfs recv" möglich.

Bevor man erste Erfahrungen mit der Konfiguration eines eigenen (Linux-)Systems sammelt, empfiehlt es sich unter Umständen, "Komplettlösungen" wie TrueNAS oder Proxmox ins Auge zu fassen, die ZFS "mitbringen", um erste Erfahrungen mit der Nutzung/Konfigurationsanpassung zu sammeln, wodurch man nicht auf die aufwendige eigene Bewertung von möglichen Updates (und deren Anpassung/Installation) angewiesen ist – vorzugsweise auf lokaler, eigener Hardware. Hierfür sollte man die anbietereigenen Foren/Mailinglisten/Anleitungen verfolgen (parallel zu denen von OpenZFS).

Aus dem Obigen sollte man als interessierter Leser/zukünftiger ZFS-Nutzer mitnehmen, dass man sehr viel lesen/lernen muss; direkt ein einzelnes Howto zu verlinken wäre mbMn an dieser Stelle grob fahrlässig und kontraproduktiv.

[*] KMU(-Repräsentanten), welche sich dieser Herausforderung stellen wollen und/oder müssen, aber insbesondere auch die Chancen nutzen wollen, kann ich beruflich gerne zu den branchenüblichen Tagessätzen von der Erstberatung bis zur Umsetzung (ohne "vendor lock-in") unterstützen.

Alles anzeigen

Mach bitte eine Anleitung aus dem Post und reich sie für einen Tutorial-Gutschein ein, wenn das noch nicht passiert sein sollte. Das ist wichtig!

Meine Motivation dabei ist:

ZFS Snapshots anstatt den standard KVM Snapshots!

Vorteile:
- Im Laufenden Betrieb möglich

- Benötigt weniger Speicherplatz, weil nur das delta gespeichert wird
- Leichter Wegkopieren, ohne kostenpflichtigen und langsamen FTP Export
- Keine Downtime
- Keine Speicheroptimierung
- Keine 50% muss frei sein Regel
- Proxmox eventuell nicht notwendig
- Komprimierung

Nachteile:
- Installation von DVD
- Man sollte es auf ein 2tes System kopieren, damit der Snapshot nicht auf demselben Host ist.
- Eventuell Probleme durch ungünstige Kombination von Kernel- und ZFS-Paketen
- Probleme mit Rettungssystemen: Speziell genannt wird das Netcup-Rettungssystem, das nicht mit ZFS-on-Root umgehen kann. Dies erfordert die Erstellung eines eigenen Rettungs-/Installations-ISO, für Ubuntu z.B. durch Modifikation des Standard-Desktop-ISO-Abbilds mit Tools wie "cubic".

Letztlich sollte man wohl trotzdem gleich auf Proxmox setzen, vor allem wenn man sich die 2 Tutorial Videos anschaut.

Unter Debian musste ich

sudo /sbin/fstrim -v /


laufen lassen



nur fstrim hat nicht funktioniert, aber der obige Befehl hat mir auch geholfen das Problem zu lösen.

Es wäre gut das im Wiki oder im SCP zu erwähnen, das man evtl. fstrim benötigt wenn die Anzeige im SCP nicht richtig ist.

Neptunius

liegt es daran, dass Du evtl. nicht vom Image sondern vom ISO installiert hast?

evtl. in der crontab od. ähnlich nachsehen, da findet sich dann evtl.

im File /etc/cron.d/kernel (bei meinen vServern)

34 0 * * * root /sbin/fstrim / >/dev/null 2>&1

(installiert man vom ISO ist das nicht)

Zitat von mainziman

Neptunius

liegt es daran, dass Du evtl. nicht vom Image sondern vom ISO installiert hast?

evtl. in der crontab od. ähnlich nachsehen, da findet sich dann evtl.

im File /etc/cron.d/kernel (bei meinen vServern)

34 0 * * * root /sbin/fstrim / >/dev/null 2>&1

(installiert man vom ISO ist das nicht)

Alles anzeigen

richtig, ich hab eine ISO benutzt. Danke für den Tipp.