Rollback-Funktion - Immer gefährlich oder generell nutzbar?

[saveZFS]

Hallo,
ich würde gerne die Rollback-Funktion öfters nutzen um meine VMs bei Testzwecken zurückzusetzen.
Leider bin ich nach dem Lesen der Anleitung zu Snapshots stark verunsichert.

Rollback is a dangerous operation that causes any configured replication tasks to fail. Replications use the existing snapshot when doing an incremental backup, and rolling back can put the snapshots ‘out of order’. To restore the data within a snapshot, the recommended steps are:

1. Clone the desired snapshot.
2. Share the clone with the share type or service running on the TrueNAS system.
3. Allow users to recover their needed data.
4. Delete the clone from Storage.

This approach does not destroy any on-disk data or impact replication.

Nutz ihr die Funktion und muss ich mir hier sorgen machen oder darf man die Funktion nur dann nicht nutzen, wenn man Replikation nutzt?
Aber auch hier mal die Frage in den Raum ... kann es auch bei Replikation funktionieren oder ist es da ein absolutes NoGo?

 

[mistermanko]

Die Doku erklärt doch ganz genau worauf du aufpassen musst. Nutzt du Replication-Tasks für deine Test-VMs? Wenn nein, dann kannst du mit rollbacks wunderbar auf einen snapshot deiner Wahl zurücksetzen.

 

[saveZFS]

Nutzt du Replication-Tasks für deine Test-VMs?

Aktuell noch nicht, aber wenn mein Backup Server endlich aus der Testphase raus ist, dann würde ich das schon gerne nutzten!
Ist das dann auch mit gewissen Vorsichtsmaßnahmen noch möglich die "Rollback-Funktion" zu nutzen oder sollte man dann definitiv die Finger von lassen?

 

[Patrick M. Hausen]

Warum sollte man von Rollback die Finger lassen? Dazu sind Snapshots doch da.

Ein Snapshot von einer laufenden VM ist ein Abbild als hättest du einer phys. Maschine zum Zeitpunkt X den Stecker gezogen. Was rausgeschrieben ist, ist drin, was noch im Cache des Gastbetriebssystems war, ist weg. Aber natürlich verliert man bei jeder Backup-Strategie innerhalb einer gewissen Granularität offene Transaktionen. Für 100% konsistente Snapshots musst du die VM vorher runter und danach wieder hoch fahren.

Machst du es live, wäre nach dem Rollback im Gast ein Filesystem-Check und ggf. auch ein Datenbank-Check zu empfehlen. Und ganz wichtig: beim Rollback muss die VM aus sein. Du kannst einem Gastbetriebssystem nicht "unter dem Hintern" die Festplatte zurückspulen - das denkt ja es hat Zustand X und noch Dinge im Cache etc.

Unter den geschilderten Einschränkungen sind Snapshots und Rollbacks das Mittel der Wahl. Beispiel: Major Upgrade des Gastbetriebssystems. Runterfahren, Snapshot (der ist garantiert konsistent), hochfahren, Upgrade. Easy Peasy.

 

[saveZFS]

Warum sollte man von Rollback die Finger lassen? Dazu sind Snapshots doch da.

Ja ich finde das auch sehr komisch. Aber wenn ich die Anleitung lese, dann scheint Replication mit Snapshot-Rollback wohl ein großes Gefahrenpotential zu haben. Aber leider habe ich noch nicht verstanden wo hier die Gefahr genau wäre.
Später will ich nämlich Replication nutzen und deshalb wäre es mir schon wichtig zu verstehen, wo es hier beim Rollback die Probleme geben könnte.

Für 100% konsistente Snapshots musst du die VM vorher runter und danach wieder hoch fahren.

Vielen Dank für den Hinweis.
Das mache ich schon per SSH-Skript. VMs die nicht dauerverfügbar sein müssen täglich herunterfahren dann Snapshot per Truenas und dann VMs wieder starten.
Allerdings habe ich bisher meine Snapshots immer per Windows Shadow Copy wiederhergestellt, weil ich mich bisher nicht an die Rollback-Funktion rangetraut habe.
Allerdings denke ich das Rollback wesentlich schneller und auch komfortabler sein sollte, vor allem wenn man für jede VM ein separates Dataset anlegt!

 

[Patrick M. Hausen]

Was hat Rollback mit Replikation zu tun? Rollback ist immer "in place". Und weshalb willst du ein Dataset pro VM? Was du zurückrollen musst, ist das zvol der virtuellen Platte.

 

[saveZFS]

Was hat Rollback mit Replikation zu tun?

Das ist leider die Sache die ich auch nicht verstehe.
Unter https://www.ixsystems.com/documentation/freenas/11.2/storage.html Punkt 9.3 steht:

Rollback is a potentially dangerous operation and causes any configured replication tasks to fail as the replication system uses the existing snapshot when doing an incremental backup. To restore the data within a snapshot, the recommended steps are:

1. Clone the desired snapshot.
2. Share the clone with the share type or service running on the FreeNAS® system.
3. After users have recovered the needed data, delete the clone in the Active Pools tab.

This approach does not destroy any on-disk data and has no impact on replication.

Und weshalb willst du ein Dataset pro VM?

Ich habe meine VMs auf einem Dataset liegen und teile das per NFS an ESXi, also auf Dateiebene nicht als zvol via iSCSI.
Aktuell liegen alle VMs in einen Dataset. Somit müsste ich bei einem Rollback alle VMs auf den Stand des Snapshots setzten.
Mit einzelnen Datasets pro VM war die Idee, dass ich einfach die gewünschte VM mit der Rollback Funktion zurücksetzten könnte.
Mache ich hier einen Denkfehler oder ist das gar keine so schlechte Idee?

 

[Patrick M. Hausen]

Ach, du sprichst von VM Storage für ESXi ...

Ich bin natürlich davon ausgegangen, dass hier von VMs in TrueNAS die Rede ist. So ergeben deine Fragen schon mehr Sinn.

Erstens ist der Link zu der Doku völlig veraltet, es sei denn, du benutzt allen Ernstes noch 11.2. Da würde ich schleunigst ein Upgrade einplanen, 5 Jahre alte oder noch ältere Gammelsoftware in Produktion ist nicht gut, das beißt einen irgendwann. Spätestens, wenn man nach einem Hardware-Defekt den Server austauscht und das System auf einem modernen Rechner nicht mehr bootet.

Wovon hier die Rede ist, ist folgendes: die Replikation benutzt inkrementelles zfs send|zfs receive von Snapshots. Dazu ist es wichtig, dass Quelle und Ziel denselben Zustand haben. Machst du nun auf dem Live-System, also normalerweise der Quelle, ein Rollback, existieren auf dem Ziel neuere Snapshots als auf der Quelle. (Ein Rollback dreht wörtlich die Zeit zurück, alle neueren Snapshots werden entfernt.) Der nächste Snapshot der Quelle kann dann nicht mehr repliziert werden, weil es da einen Konflikt gibt. Man muss also auf dem Ziel manuell aufräumen, damit beide denselben Zustand haben. Dazu braucht man aber eine gemeinsame Historie - wenn man auf dem Ziel keinen Snapshot mehr haben sollte, weil man auf der Quelle weiter zurückgedreht hat, dann muss man eben von vorne anfangen mit der Replikation.

Wenn du NFS und nicht iSCSI verwendest, dann reden wir ja von VMDK Files. Die kannst du natürlich auch aus dem .zfs Verzeichnis einzeln rauspfriemeln, über das du auf alle Snapshotdaten zugreifen kannst. Ganz ohne Rollback.

 

[saveZFS]

Die kannst du natürlich auch aus dem .zfs Verzeichnis einzeln rauspfriemeln, über das du auf alle Snapshotdaten zugreifen kannst. Ganz ohne Rollback.

Sorry, aber jetzt muss ich denke ich wirklich ganz blöd nachfragen. :(
Wo finde ich das .zfs Verzeichnis und wie kann ich darauf zugreifen?

 

[Patrick M. Hausen]

Code:

root@freenas[~]# zfs list -t snap hdd/share/medien
NAME                                     USED  AVAIL     REFER  MOUNTPOINT
hdd/share/medien@auto-2022-03-08_20-00     0B      -      971G  -
hdd/share/medien@auto-2022-03-08_21-00     0B      -      971G  -
hdd/share/medien@auto-2022-03-08_22-00     0B      -      971G  -
hdd/share/medien@auto-2022-03-08_23-00     0B      -      971G  -
hdd/share/medien@auto-2022-03-09_00-00     0B      -      971G  -
[...]
root@freenas[~]# cd /mnt/hdd/share/medien/.zfs/snapshot
root@freenas[/mnt/hdd/share/medien/.zfs/snapshot]# ls -l
total 4044
drwxr-xr-x  8 nobody  nogroup  9 Sep 18  2021 auto-2022-03-08_20-00
drwxr-xr-x  8 nobody  nogroup  9 Sep 18  2021 auto-2022-03-08_21-00
drwxr-xr-x  8 nobody  nogroup  9 Sep 18  2021 auto-2022-03-08_22-00
drwxr-xr-x  8 nobody  nogroup  9 Sep 18  2021 auto-2022-03-08_23-00
drwxr-xr-x  8 nobody  nogroup  9 Sep 18  2021 auto-2022-03-09_00-00
[...]
root@freenas[/mnt/hdd/share/medien/.zfs/snapshot]# cd auto-2022-03-08_20-00
root@freenas[...n/.zfs/snapshot/auto-2022-03-08_20-00]# ls -l
total 102
-rw-r--r--   1 nobody  nogroup  8196 Sep 10  2020 .DS_Store
drwxr-xr-x   7 nobody  nogroup     9 Jul 16  2020 Dokus
drwxr-xr-x  14 nobody  nogroup    16 Sep  8  2021 Filme
drwxr-xr-x   9 nobody  nogroup    11 Jun 23  2021 Musik
drwxr-xr-x   2 nobody  nogroup     9 Sep 18  2021 New
drwxr-xr-x  16 nobody  nogroup    19 Jun 23  2019 Old
drwxr-xr-x  12 nobody  nogroup    14 Nov  4  2019 Serien

Das funktioniert auch mit deinem NFS-Share ... da sind dann die VMDK-Dateien (und alles andere natürlich auch) zu dem Stand drin als der Snapshot angefertigt wurde.

Das Verzeichnis .zfs wird mit ls nicht angezeigt. Du kannst trotzdem einfach nach /mnt/<pool>/some/dataset/.zfs/snapshot wechseln mit cd.

HTH,
Patrick

 

[saveZFS]

Vielen Dank. :)

Generell noch eine Frage zur späteren Replikation.

Ist es besser wenn die Snapshots egal welches Dataset immer folgendermaßen heißen:
auto-%Y-%m-%d_%H-%M

oder wäre es so besser:

dataset1-auto-%Y-%m-%d_%H-%M-lifetime
dataset2-auto-%Y-%m-%d_%H-%M-lifetime
dataset2-auto-%Y-%m-%d_%H-%M-lifetime
......

 

[Patrick M. Hausen]

Das TrueNAS verlässt sich auf ein gewisses Namensschema, um die älteren Snapshots wieder zu entfernen. Es geht hier nicht nach dem Erstelldatum vor sondern nach dem Snapshot-Namen. Ich würde es daher so lassen wie vorgeschlagen. Weiteres kannst du evtl. der Doku entnehmen, auswendig weiß ich das auch nicht.

Warum solltest du den Dataset-Namen in den Snapshot-Namen mit einbauen? Du replizierst ja hinterher das gesamte Dataset mit allen oder einem Teil der Snapshots. Da werden keine "Snapshost repliziert" sondern dein Dataset zu einem gegebenen Zeitpunkt. In exakt der Struktur wie auch auf der Quelle.

 

[saveZFS]

Warum solltest du den Dataset-Namen in den Snapshot-Namen mit einbauen?

Ich dachte genau aus Grund, dass es Truenas unterscheiden kann.

Angenommen ich habe 3 Datasets und mache von allen drei Datasets um 03:00 Uhr täglich einen Snapshot.
Dann würde die Snapshots folgendermaßen heißen (Beispiel für den 22.03.2022):

Fall 1:
dataset1: auto-2022-03-22_03-00
dataset2: auto-2022-03-22_03-00
dataset3: auto-2022-03-22_03-00


Mit dem vorgestelltem Dataset folgendermaßen:
Fall 2:
dataset1: dataset1-auto-2022-03-22_03-00
dataset2: dataset2-auto-2022-03-22_03-00
dataset3: dataset3-auto-2022-03-22_03-00

Ich dachte, dass in Fall 1 Truenas ggf. ein Problem hätte, weil eben alle Snapshots gleich heißen.
Und in Fall 2 wäre sie eindeutig unterschiedlich benannt.

Das war meine Idee hinter der Frage! :)

 

[Patrick M. Hausen]

Nein, die heißen "dataset1@auto-...", "dataset2@auto-...", etc. Die liegen auch nirgendwo gemeinsam sondern sind Bestandteil des Datasets. Mach doch mal ein zfs list -t snap, dann siehst du's. Ansonsten solltest du, glaube ich, wirklich mal den ZFS-Primer lesen