Replikation und eigene snapshots

[bforpc]

Hallo ,

die Replikation läuft in den vorgegebenen Rahmen. Bevor die Nodes zu einem Cluster verbunden waren, hatten wir sanoid zum snapshotting verwendet.
Dies ist ja jetzt eher kontraproduktiv, da von den replizierten Maschinen auch snapshots erzeugt werden würden.

Ist es überhaupt sinnvoll, weitere Snapshots - unterhalb von proxmox Replikaten - zu erzeugen?

Bfo

 

[LnxBil]

Ist es überhaupt sinnvoll, weitere Snapshots - unterhalb von proxmox Replikaten - zu erzeugen?

Naja, die Sinnhaftigkeit ist schwer zu beurteilen, da ich nicht weiß was ihr mit Snapshots vor habt. Das Problem bei ZFS-Snapshots ist ja, dass ihr nur auf einen Snapshot zurück könnt, wenn ihr alle Snapshots, die im Weg sind wegschmeißt. Je mehr es dann sind desto blöder ist das wenn ihr den falschen erwischt habt. Alternativ ist es immer ratsam den Snapshot zu klonen und darauf zu arbeiten, aber IMHO ist das nicht direkt über die GUI möglich. Die Frage ist also wie euer Recovery-Prozess aussieht um Fehler auszubügeln.

 

[bforpc]

Letztendlich haben wir bis heute (auf Holz klopf) nie das Problem eines Recovery gebraucht.
Somit sind die Snapshots tatsächlich nur verschiedene Versionen eines Backups. Wenn der Fall eintritt, gehen wir hat stückchenweise zurück.

bfo

 

[LnxBil]

Letztendlich haben wir bis heute (auf Holz klopf) nie das Problem eines Recovery gebraucht.
Somit sind die Snapshots tatsächlich nur verschiedene Versionen eines Backups. Wenn der Fall eintritt, gehen wir hat stückchenweise zurück.

Okay, nur wichtig einen Plan zu haben und auch die Nachteile zu kennen, bevor es dann "Ernst" wird.

 

[bforpc]

Ich musste die Replikation beenden, bzw. weil wir mit großen Problemen bezüglich des Clusters kämpften, haben wir dieses aufgelöst. Somit auch keine Proxmox Replikation. Aber das ist ein anderes Thema.

 

[hackmann]

Naja, die Sinnhaftigkeit ist schwer zu beurteilen, da ich nicht weiß was ihr mit Snapshots vor habt. Das Problem bei ZFS-Snapshots ist ja, dass ihr nur auf einen Snapshot zurück könnt, wenn ihr alle Snapshots, die im Weg sind wegschmeißt.

Das stimmt so glaube ich nicht.

Wenn man snapshots hat, dann gibt es ein Verzeichnis .zfs. Gehe in dieses und kopiere die VM oder die Daten von einem Server in eine neue Umgebung.


Je mehr es dann sind desto blöder ist das wenn ihr den falschen erwischt habt.

Ich kann da nicht zustimmen!

Lege eine VM an / Storage/Directory

Installiere deine VM darauf. Dann führe zfsnap aus "maximal 5 Tage"

Gehe in das Verzeichnis .zfs und ziehe Dir alles was du brauchts.

Alternativ ist es immer ratsam den Snapshot zu klonen und darauf zu arbeiten, aber IMHO ist das nicht direkt über die GUI möglich. Die Frage ist also wie euer Recovery-Prozess aussieht um Fehler auszubügeln.

Mit einem CLONE auf dem selben POOL würde ich vorsichtig sein, da dieser Clone vom Elternteil abhängig ist, ich habe dadurch schon einige VMS verloren.

Lange Rede, es ist vieles möglich, aber schaue Dir mal das Video https://vimeo.com/8666489 an.

Und dein Kommentar
Je mehr es dann sind desto blöder ist das wenn ihr den falschen erwischt habt.

was dann?

 

[LnxBil]

Mal abgesehen davon, dass man deine Antwort nicht richtig lesen kann ...

Das stimmt so glaube ich nicht.

Wenn man snapshots hat, dann gibt es ein Verzeichnis .zfs. Gehe in dieses und kopiere die VM oder die Daten von einem Server in eine neue Umgebung.

Doch! Es gibt das Verzeichnis .zfs grundsätzlich nicht für KVM-basierte VMs, sondern nur für Container, da dies ein Feature eines datasets ist, nicht eines ZVOLs und VMs werden standardmäßig auf ZVOLs ablegt, da dies die beste Technologie im ZFS-Umfeld hierfür ist.

Ich kann da nicht zustimmen!

Lege eine VM an / Storage/Directory

Installiere deine VM darauf. Dann führe zfsnap aus "maximal 5 Tage"

Gehe in das Verzeichnis .zfs und ziehe Dir alles was du brauchts.

Das QCOW2 auf ZFS nicht sinnvoll ist hat mittlerweile jeder Proxmox Mitarbeiter bereits mindestens einmal geschrieben und es macht auch überhaupt keinen Sinn VMs als Dateien abzulegen, die sich eine Snapshothierarchie teilen. Aber natürlich kann jeder sein System so bauen wie es ihm selbst gefällt, nur geht es dann eben nicht so wie PVE konstruiert ist.

Mit einem CLONE auf dem selben POOL würde ich vorsichtig sein, da dieser Clone vom Elternteil abhängig ist, ich habe dadurch schon einige VMS verloren.

Lange Rede, es ist vieles möglich, aber schaue Dir mal das Video https://vimeo.com/8666489 an.

Ohne mir das Video jetzt anzuschauen ... klar muss man da aufpassen (wie überall), dann muss man ein promote durchführen und alles ist wieder so wie es sein soll.


Und meine Antwort zielte auf deine Frage ab (mit der PVE Brille auf) und nicht von einzelnen Dateien wiederherstellen - klar geht das immer und ist völlig unabhängig von der Snapshot-Hierarchie in ZFS. Wenn du dann aber einen Snapshot über die GUI wiederherstellen möchtest (sprich: Rollback) zum Zeitpunkt X und zwischen X und heute andere Snapshots liegen (z.B. durch externe Programme) kannst du das nur tun wenn du alles dazwischen wegwirfst. So ist ZFS aufgebaut und wenn ihr dann auf einen Zwischenschritt nach vorne gehen wollt ist dies nicht mehr möglich (wenn ihr kein Backup irgendwo habt).

 

[hackmann]

Sorry, abwr

Mal abgesehen davon, dass man deine Antwort nicht richtig lesen kann ...



Doch! Es gibt das Verzeichnis .zfs grundsätzlich nicht für KVM-basierte VMs, sondern nur für Container, da dies ein Feature eines datasets ist, nicht eines ZVOLs und VMs werden standardmäßig auf ZVOLs ablegt, da dies die beste Technologie im ZFS-Umfeld hierfür ist.



Das QCOW2 auf ZFS nicht sinnvoll ist hat mittlerweile jeder Proxmox Mitarbeiter bereits mindestens einmal geschrieben und es macht auch überhaupt keinen Sinn VMs als Dateien abzulegen, die sich eine Snapshothierarchie teilen. Aber natürlich kann jeder sein System so bauen wie es ihm selbst gefällt, nur geht es dann eben nicht so wie PVE konstruiert ist.



Ohne mir das Video jetzt anzuschauen ... klar muss man da aufpassen (wie überall), dann muss man ein promote durchführen und alles ist wieder so wie es sein soll.


Und meine Antwort zielte auf deine Frage ab (mit der PVE Brille auf) und nicht von einzelnen Dateien wiederherstellen - klar geht das immer und ist völlig unabhängig von der Snapshot-Hierarchie in ZFS. Wenn du dann aber einen Snapshot über die GUI wiederherstellen möchtest (sprich: Rollback) zum Zeitpunkt X und zwischen X und heute andere Snapshots liegen (z.B. durch externe Programme) kannst du das nur tun wenn du alles dazwischen wegwirfst.

ich rede So ist ZFS aufgebaut und wenn ihr dann auf einen Zwischenschritt nach vorne gehen wollt ist dies nicht mehr möglich (wenn ihr kein Backup irgendwo habt).

Mal abgesehen davon, dass man deine Antwort nicht richtig lesen kann ...



Doch! Es gibt das Verzeichnis .zfs grundsätzlich nicht für KVM-basierte VMs, sondern nur für Container, da dies ein Feature eines datasets ist, nicht eines ZVOLs und VMs werden standardmäßig auf ZVOLs ablegt, da dies die beste Technologie im ZFS-Umfeld hierfür ist.



Das QCOW2 auf ZFS nicht sinnvoll ist hat mittlerweile jeder Proxmox Mitarbeiter bereits mindestens einmal geschrieben und es macht auch überhaupt keinen Sinn VMs als Dateien abzulegen, die sich eine Snapshothierarchie teilen. Aber natürlich kann jeder sein System so bauen wie es ihm selbst gefällt, nur geht es dann eben nicht so wie PVE konstruiert ist.



Ohne mir das Video jetzt anzuschauen ... klar muss man da aufpassen (wie überall), dann muss man ein promote durchführen und alles ist wieder so wie es sein soll.


Und meine Antwort zielte auf deine Frage ab (mit der PVE Brille auf)

Es geht hier nicht um das Webgui "BRILLE AB"
"Das QCOW2 auf ZFS nicht sinnvoll ist hat mittlerweile jeder Proxmox Mitarbeiter bereits mindestens einmal geschrieben"
bei mir läuft es seit Jahren!






und nicht von einzelnen Dateien wiederherstellen - klar geht das immer und ist völlig unabhängig von der Snapshot-Hierarchie in ZFS. Wenn du dann aber einen Snapshot über die GUI wiederherstellen möchtest (sprich: Rollback) zum Zeitpunkt X und zwischen X und heute andere Snapshots liegen (z.B. durch externe Programme) kannst du das nur tun wenn du alles dazwischen wegwirfst. So ist ZFS aufgebaut und wenn ihr dann auf einen Zwischenschritt nach vorne gehen wollt ist dies nicht mehr möglich (wenn ihr kein Backup irgendwo habt).

 

[hackmann]

danke für deine Antwort, sorry, ich hatte die PVE-Brille nicht auf.

 

[bforpc]

Und meine Antwort zielte auf deine Frage ab (mit der PVE Brille auf) und nicht von einzelnen Dateien wiederherstellen - klar geht das immer und ist völlig unabhängig von der Snapshot-Hierarchie in ZFS.

Wie kann ich von einer qemu (kein lxc Container) einzelne Dateien aus ZFS Snapshots wieder herstellen?
Die VM's sind doch qemu devices und keine Files, unabhängig davon, dass die Snapshots ja auch nicht im Dateisystem lesbar liegen.

Bfo

 

[LnxBil]

Sorry für meine späte Antwort ... bin am Backlog aufarbeiten.

Wie kann ich von einer qemu (kein lxc Container) einzelne Dateien aus ZFS Snapshots wieder herstellen?

So.

Die VM's sind doch qemu devices und keine Files, unabhängig davon, dass die Snapshots ja auch nicht im Dateisystem lesbar liegen.

Erstmal ist in Linux/Unix alles eine Datei. Hier ist es ein Blockgerät und da ZFS immer nur den aktuellen Stand als Blockgerät nach außen gibt musst du einfach den Snapshot in ein zvol clonen (zfs clone <dataset>@snapshotname <restore>) und dann hast du ein Gerät mit dem du das machen kannst was ich oben verlinkt habe.

 

[fabian]

es gibt auch das 'snapdev' property für zvols (analog zum 'snapdir' für filesysteme, das den .zfs ordner einschaltet) das alle snapshots als eigene blockdevices sichtbar macht - ganz ohne clone (aber halt nur read-only).