[SOLVED] Frage zu den Snapshots und dem Backup-Server

[Renegade33]

Wenn man die Komprimierung einschaltet, was per Default der Fall ist, dann werden abgespeicherte Dateien (und auch virtuelle Festplatten per ZVOL) automatisch komprimiert. Das geschieht komplett transparent, also unsichtbar für den Nutzer. Der Erfolg hängt natürlich drastisch von den Daten ab: reiner Text lässt sich auf ~50% zusammenquetschen, übliche Mediendateien gar nicht.

OK, wusste gar nicht, dass die per default an ist. Wie ist die So vom Ressourcenverbrauch? Bei mir liegen auf dem Datengrab sehr viele pdf, Fotos und Office Dokumente. Das sind eigentlich die Hauptdaten.

"Unterhalb" von dem LXC muss ja trotzdem echter, zuverlässiger Speicher liegen.

Ach so..., einen Storage und den dann sharen. Ja, kann man machen. Aber dieser Storage darf dann eigentlich nicht von einem Cluster-Member kommen. Sonst fällt ja der ganze Cluster aus, wenn dieser eine Node ein Problem hat --> Single Point of Failure.

Ja OK, so gesehen hast du natürlich absolut recht. OK bei mir wäre es ja quasi ein NAS, welches über Backups/Snapshots auf einer weiteren Ressource gesichert ist. Somit kann mir zwar der Node, die SSD oder eine HDD abrauchen, aber ich kann es immer wieder herstellen. Brauche da jetzt keine absolute Hochverfügbarkeit. Wichtig ist mir nur, dass ich im Ernstfall innerhalb von max. 48h Stunden wieder Zugriff bekomme. Nicht wie bei meinem jetzigen System. Rebuild brauchte ganze 2 Wochen und so lange stand alles auf degraded und war geblockt.

Mein Plan ist ja node1 hält die UCS und den LXC, node2 den Backupserver. Im Ernstfall sollte die Domain auf die node 2 migrieren oder eben da mit UCS-Backup Domain gearbeitet, um das Netzwerk am laufen zu halten.
Wenn die Laufwerke dann mal nicht da sind, geht die Welt nicht unter. Hab dann 24h Zeit die Hard/Software zu fixen und aus einem Backup wieder herzustelln. Entweder provisorisch auf der jetzigen Kiste oder eben direkt das aktuelle System wieder herstellen.

 

[Falk R.]

Warum so selten Backups? Klar kann man alle paar Minuten Replizieren, aber auch andere mit kleinen Umgebungen, nehmen lieber nur 1 Host und machen stündlich Backups. Das funktioniert ebenfalls.

 

[Renegade33]

Warum so selten Backups? Klar kann man alle paar Minuten Replizieren, aber auch andere mit kleinen Umgebungen, nehmen lieber nur 1 Host und machen stündlich Backups. Das funktioniert ebenfalls.

Die 2 Hosts hab ich ja sowieso und die sind auch in anderen Brandabschnitten, galvanisch getrennt und auf verschiedenen Stromkreisen, damit sie nicht gleichzeitig kaputt gehen. Ich muss mir das noch genau ansehen, aber will ja auch alle 30 min-1h snapshots ziehen und eben 1x täglich alles auf die Backupmaschine.

 

[Dunuin]

deshalb mache ich lieber mehr Backups. Wenn der PBS schnell ist, stören die 5 Sekunden nicht und du kannst jeden Restorepunkt frei nutzen.
Für viele ist Snapshot das Allheilmittel, ich sehe das etwas anders. Nett wenn es da ist, aber kein Must Have für mich.

Ja und spart Platz. wie hoffentlich jeder weiß ersetzen Snapshots keine Backups. Also brauch ich Platz für Snapshots + Backups. Aber dank Deduplikation ist PBS so effizient, wenn man viele Backups hat, ein paar mehr eigentlich keinen nennenswerten zusätzlichen Platz wegnehmen. Da kann ich die Snapshots dann auch gleich ganz weglassen, wenn kein super schneller Restore nötig ist. 10x Snapshots + 10x Backups nehmen hier mehr Platz weg als wenn ich einfach gleich 20x Backups mache. Gerade wenn die Snapshots als Langzeitbackup missbraucht und nicht nach wenigen Tagen gelöscht werden.

 

[Renegade33]

Ja und spart Platz. wie hoffentlich jeder weiß ersetzen Snapshots keine Backups. Also brauch ich Platz für Snapshots + Backups. Aber dank Deduplikation ist PBS so effizient, wenn man viele Backups hat, ein paar mehr eigentlich keinen nennenswerten zusätzlichen Platz wegnehmen. Da kann ich die Snapshots dann auch gleich ganz weglassen, wenn kein super schneller Restore nötig ist. 10x Snapshots + 10x Backups nehmen hier mehr Platz weg als wenn ich einfach gleich 20x Backups mache. Gerade wenn die Snapshots als Langzeitbackup missbraucht und nicht nach wenigen Tagen gelöscht werden.

Ja ich möchte ja nur die 30 min snapshots machen oder eben 1h. davon max 24 und ab 1 Tag sind dann sowieso backups dran. Sprich alles unter 24h Restore von snapshot und alles drüber Backup.

 

[Dunuin]

Ja ich möchte ja nur die 30 min snapshots machen oder eben 1h. davon max 24 und ab 1 Tag sind dann sowieso backups dran. Sprich alles unter 24h Restore von snapshot und alles drüber Backup.

Du musst halt gucken wie schnell sich deine Daten ändern. Sagen wir ich habe eine 100GB vDisk, dann lade ich 5 verschiedene 50GB Zips runter, entpacke die und lösche alles wieder, weil ich das z.B. irgendwo auf ein NAS schiebe. Dann verbrät der Snapshot 500GB bis er irgendwann gelöscht wird. Auch das kann schon nervig werden, selbst wenn man die nur einen Tag behält, wenn die vDisk dann auf 600% Größe anwächst.
Kann natürlich bei wichtigen Daten trotzdem sinnvoll sein. Muss man halt nur entsprechend extra Storage einplanen.
Im TrueNAS halte ich die Snapshots wegen Ransomware, Replikation und Shadowcopy 2 Monate vor. Da verbrät das schon TBs ohne Ende.

 

[UdoB]

Komprimierung:

Wie ist die So vom Ressourcenverbrauch?

"Ganz früher" konnte man das spüren, meine ich mich erinnern zu können. Aber seit vielen Jahren ist der zusätzliche Aufwand so gering, dass er praktisch nicht wahrnehmbar ist. Darum ist Compression per Default eingeschaltet.
Bei Datenbeständen, von denen man im Voraus weiß, dass das sinnlos ist - wie bei bereits im Vorfeld komprimierten Dateien - kann man dieses Verhalten (pro Dataset oder ZVol) explizit abschalten.

 

[Renegade33]

Du musst halt gucken wie schnell sich deine Daten ändern. Sagen wir ich habe eine 100GB vDisk, dann lade ich 5 verschiedene 50GB Zips runter, entpacke die und lösche alles wieder, weil ich das z.B. irgendwo auf ein NAS schiebe. Dann verbrät der Snapshot 500GB bis er irgendwann gelöscht wird. Auch das kann schon nervig werden, selbst wenn man die nur einen Tag behält, wenn die vDisk dann auf 600% Größe anwächst.
Kann natürlich bei wichtigen Daten trotzdem sinnvoll sein. Muss man halt nur entsprechend extra Storage einplanen.
Im TrueNAS halte ich die Snapshots wegen Ransomware, Replikation und Shadowcopy 2 Monate vor. Da verbrät das schon TBs ohne Ende.

Das ist ein echt guter Einwand. Ich denke, da werde ich bei den Daten 2 zVols machen. Eines für den Arbeitsbereich mit kleinen Daten und snapshots und einen für große Lagerdaten die nur 1x täglich gesichert werden. Danke Dir.

"Ganz früher" konnte man das spüren, meine ich mich erinnern zu können. Aber seit vielen Jahren ist der zusätzliche Aufwand so gering, dass er praktisch nicht wahrnehmbar ist. Darum ist Compression per Default eingeschaltet.
Bei Datenbeständen, von denen man im Voraus weiß, dass das sinnlos ist - wie bei bereits im Vorfeld komprimierten Dateien - kann man dieses Verhalten (pro Dataset oder ZVol) explizit abschalten.

OK, dann habe ich meine Konfiguration fast fertig.

2x NVMe im Mirror mit 500GB für OS, VMs und snapshots(12x 30 min), in 3 zVols gesplittet. Auf den selben Platten lass ich noch Luft für ein LVM-Thin und eine eventuelle SWAP.
2x Enterprise SSD mit 480GB als "special-device" im Mirror.
Nur bei den 6x HDD wie sollte ich die anlegen?

Liegen bei der LXC-Toolbox die Daten eigentlich im Container oder wo legt er die Daten der SMB ab?

 

[UdoB]

Nur bei den 6x HDD wie sollte ich die anlegen?

Wir drehen uns im Kreis. Ich hatte oben generell Mirror empfohlen. (Obwohl ich je nach Zweck auch RaidZ2 verwende; hingegen ist bei den aktuellen Festplattengrößen RaidZ1 generell ein no-go.)

Liegen bei der LXC-Toolbox die Daten eigentlich im Container oder wo legt er die Daten der SMB ab?

Ein Container sieht ja nur die Daten, die "innen" gemountet wurden. Wenn man also einen Moint-Point eines Datasets des Nodes in den LXC hinein konfiguriert, stehen diese Daten dem Container zur Verfügung.

Viele Grüße

 

[Renegade33]

Wir drehen uns im Kreis. Ich hatte oben generell Mirror empfohlen. (Obwohl ich je nach Zweck auch RaidZ2 verwende; hingegen ist bei den aktuellen Festplattengrößen RaidZ1 generell ein no-go.)

Mirror ist doch aber 50% effektive Kapazität oder? Dazu zfs, dann bleibt ja nicht mehr viel Nettokapazität über?
Bei 5TB a Platte sind das 30TB gesammt. Bei Mirror 15GB und durch zfs bleiben nur noch max 12 über. Oder rechne ich da irgendwo komplett falsch?

Ein Container sieht ja nur die Daten, die "innen" gemountet wurden. Wenn man also einen Moint-Point eines Datasets des Nodes in den LXC hinein konfiguriert, stehen diese Daten dem Container zur Verfügung.

Ah OK, jetzt komm ich mit. Also liegen sie direkt im zfs Pool und nicht in auf einem virtuellen Laufwerk.

 

[Dunuin]

Bei 5TB a Platte sind das 30TB gesammt. Bei Mirror 15GB und durch zfs bleiben nur noch max 12 über. Oder rechne ich da irgendwo komplett falsch?

Genau (also mal abgesehen von TB statt GB ).

Ob Raidz1/2 eine Option für dich ist hängt von verschiedenem ab:
- Willst du einfach Disks hinzufügen können? Bei Raidz schwierig.
- Willst du Disks entfernen können? Bei Raidz nicht möglich.
- Willst du viele kleine Dateien speichern? Mit Raidz nur 1/3 der IOPS Performance
- Willst du bei Problemen schnell deinen Pool resilvert bekommen? Bei Raidz echt langsam.
- Soll das Scrubben, was den Pool echt unnutzbar macht, über Nacht fertig werden, damit er am Tag voll nutzbar ist? Bei Raidz wird das eher 20 Stunden laufen.
- Willst du Dinge wie DBs benutzen die kleine IO lesen/schreiben? Dann ist Raidz echt ungeeignet, da du bei Raidz1 z.B. deine Blockgröße auf mindestens 32K anheben müsstest da du sonst auch nicht mehr Platz hättest als mit einem Raid10 (Stichpunkt: Padding Overhead).

Also Raidz1/2 kann man schon machen (habe ich hier selbst auch weil das Budget für Raid10 nicht drinne war) aber ideal ist das halt auch nicht. Die bessere Kapazitätsausnutzung erkaufst du dir mit ganz vielen Nachteilen.

 

[Renegade33]

Genau (also mal abgesehen von TB statt GB ).

Upsi. Sry

Also aktuell sind es 6 3TB Platten. Diese sollen natürlich später mal ausgetauscht werden in größere. Es werden aber nie mehr als 6, da das System nicht mehr her gibt. Wie gesagt hauptsächlich liegen da Office-Dokumente, Pdf und Images rum. Quasi der ganze Plunder, der unter eigene Dateien steckt.
Meine Überlegung war halt 2 vDevs a 3 Platten im Raidz1 und beide zusammen in einen zpool packen. Soll angeblich auch Geschwindigkeit bringen. Vor allem, weil ja da noch das special-device ist.

- Willst du Dinge wie DBs benutzen die kleine IO lesen/schreiben? Dann ist Raidz echt ungeeignet, da du bei Raidz1 z.B. deine Blockgröße auf mindestens 32K anheben müsstest da du sonst auch nicht mehr Platz hättest als mit einem Raid10 (Stichpunkt: Padding Overhead).

Meine DBs laufen in einer kleinen VM auf den NVMe Mirror oder im LVM-Thin Bereich.
Ich dachte Blockgröße 16k bei Raidz1/2. Hab ich zumindest bei zfs.rocks usw. gehört.

 

[Dunuin]

Ich dachte Blockgröße 16k bei Raidz1/2. Hab ich zumindest bei zfs.rocks usw. gehört.

Das hängt ganz von der Anzahl der Disks, der ashift, wieviel Kapazität du bereit bist für eine kleinere Blockgröße zu opfern sowie der Anzahl der Paritätsdisks ab. Bei einem Raidz1-Vdev aus 6 Disks bei ashift=12 und wo man nur 20% an Kapazität verlieren will müsste man schon auf 32K Volblocksize gehen. Bei 3 Disks 16K. Wie das mit 2x 3 Disk Raidz1 im Stripe ist bin ich nicht ganz sicher. Denke da geht dann auch 16K aber vielleicht mit besserer Performance wenn man 32K nutzt?

 

[UdoB]

Mirror ist doch aber 50% effektive Kapazität oder? Dazu zfs, dann bleibt ja nicht mehr viel Nettokapazität über?

Korrekt. Das muss man halt abwägen...

Ah OK, jetzt komm ich mit. Also liegen sie direkt im zfs Pool und nicht in auf einem virtuellen Laufwerk.

Korrekt. Das ist der "Trick" bei dieser Konstruktion.

Viele Grüße

 

[Renegade33]

(Obwohl ich je nach Zweck auch RaidZ2 verwende; hingegen ist bei den aktuellen Festplattengrößen RaidZ1 generell ein no-go.)

Warum ist Raidz1 ein No-Go? Das höre ich zum ersten mal?

Korrekt. Das muss man halt abwägen...

puh ja das ist mir ehrlich gesagt etwas zu viel. 65% hätte ich chon gerne. zumal da noch die 20% für zfs abgehen, mit denen ich mich schon abgefunden habe.

 

[UdoB]

Warum ist Raidz1 ein No-Go? Das höre ich zum ersten mal?

Das wird schon sehr lange so "verkündet", seit 2007 für 2009: https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/

Offensichtlich ist das übertrieben (oder gar falsch?) gewesen und sicher gibt es Folgeartikel mit einer neueren Einschätzung.

Die Überlegung geht jedenfalls ungefähr so: übliche Platten haben eine Fehlerrate von etwa 10^-15 = 1 bit in 1000000000000000 wird falsch zurückgeliefert. Normale Filesysteme bemerken das nicht. Das sind 1000 TeraBIT, also 125 TByte. (Mir ist gerade unklar, ob ich an dieser Stelle mit Bit oder mit Blöcken rechnen sollte, eventuell liege ich also um einen Faktor 512 oder 4K daneben. Man möge mich korrigieren.) Jedenfalls kann das bei Multi-Terabyte-Platten schon mal alle paar Jahre oder so vorkommen.

In einem RaidZ1/Raid5 müssen nach Verlust einer Platte alle Platten fehlerfrei(!) eingelesen werden, um die korrekten Daten und die Checksumme zu rekonstruieren.

Bei einem RaidZ mit 6 Platten müssen dazu alle verbleibenden fünf Platten fehlerfrei gelesen werden. Die Wahrscheinlichkeit, dass das fehlschlägt ist um ein vielfaches höher als mit einer einzelnen Platte. (Zu sehr vereinfacht?)

Falls noch eine zweite Parity-Platte, also die eines RaidZ2, korrekt funktioniert, sinkt die Fehlerwahrscheinlichkeit um den Faktor 10^15. (Es gibt dann noch das Geburtstagsparadoxon, das ignoriere ich hier.)

Dies habe ich gerade ohne Recherche (trotz des Links oben) geschrieben, mag sein, dass meine Darstellung etwas daneben liegt. Aber ein Raid mit nur einer Platte für Redundanz ist sicher nicht immer hinreichend.


Und natürlich nutze ich fast überall "nur" Mirrors, darf also nur ein Device verlieren. Daher schrieb ich "choose your poison".

Viele Grüße

Nachtrag: da stecken wohl falsche Darstellungen im Text: Lesefehler, die als solche gemeldet werden sind etwas anderes als Bitfehler, die unerkannt falsche Daten liefern. Ich lasse das trotzdem erstmal so stehen, meine Grundaussage ist sicher dennoch erkennbar.

 

[Falk R.]

Das wird schon sehr lange so "verkündet", seit 2007 für 2009: https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/

Offensichtlich ist das übertrieben (oder gar falsch?) gewesen und sicher gibt es Folgeartikel mit einer neueren Einschätzung.

Die Überlegung geht jedenfalls ungefähr so: übliche Platten haben eine Fehlerrate von etwa 10^-15 = 1 bit in 1000000000000000 wird falsch zurückgeliefert. Normale Filesysteme bemerken das nicht. Das sind 1000 TeraBIT, also 125 TByte. (Mir ist gerade unklar, ob ich an dieser Stelle mit Bit oder mit Blöcken rechnen sollte, eventuell liege ich also um einen Faktor 512 oder 4K daneben. Man möge mich korrigieren.) Jedenfalls kann das bei Multi-Terabyte-Platten schon mal alle paar Jahre oder so vorkommen.

In einem RaidZ1/Raid5 müssen nach Verlust einer Platte alle Platten fehlerfrei(!) eingelesen werden, um die korrekten Daten und die Checksumme zu rekonstruieren.

Bei einem RaidZ mit 6 Platten müssen dazu alle verbleibenden fünf Platten fehlerfrei gelesen werden. Die Wahrscheinlichkeit, dass das fehlschlägt ist um ein vielfaches höher als mit einer einzelnen Platte. (Zu sehr vereinfacht?)

Falls noch eine zweite Parity-Platte, also die eines RaidZ2, korrekt funktioniert, sinkt die Fehlerwahrscheinlichkeit um den Faktor 10^15. (Es gibt dann noch das Geburtstagsparadoxon, das ignoriere ich hier.)

Dies habe ich gerade ohne Recherche (trotz des Links oben) geschrieben, mag sein, dass meine Darstellung etwas daneben liegt. Aber ein Raid mit nur einer Platte für Redundanz ist sicher nicht immer hinreichend.


Und natürlich nutze ich fast überall "nur" Mirrors, darf also nur ein Device verlieren. Daher schrieb ich "choose your poison".

Viele Grüße

Deine Einschätzung ist richtig, aber die Zahlen kann eh niemand ernsthaft verifizieren. Schon Mitte der 2000er Jahre haben ein die HP Raidcontroller angemeckert wenn man 12 oder mehr Disks in ein RAID5 packen wollte. Das war zu 36/72 GB Diskzeiten. RAID5 ist zwar besser als Raid0 aber trotzdem bei großen Disks kein echter Schutz. Ich habe in meiner IT Laufbahn schon viele korrupte RAID5 gesehen.

 

[UdoB]

Deine Einschätzung ist richtig
...
Ich habe in meiner IT Laufbahn schon viele korrupte RAID5 gesehen.

Danke für die Bestätigung.
Ich habe mehrmals regelrecht geschwitzt, wenn ein Rebuild länger dauerte, als ich eigentlich erwartete. Auf diesen zusätzlichen Stress kann ich jedenfalls gerne verzichten. Zumal die klassischen PERC ja auch viele, viele Stunden für einen Rebuild brauchten (und immer Backups vorhanden sind).

Viele Grüße

 

[Falk R.]

Danke für die Bestätigung.
Ich habe mehrmals regelrecht geschwitzt, wenn ein Rebuild länger dauerte, als ich eigentlich erwartete. Auf diesen zusätzlichen Stress kann ich jedenfalls gerne verzichten. Zumal die klassischen PERC ja auch viele, viele Stunden für einen Rebuild brauchten (und immer Backups vorhanden sind).

Viele Grüße

Der längste Rebuild den ich gesehen habe waren 2 Wochen. 17x16TB HDDs zum Glück mit Raid6 aber auch dauerhaft Last auf dem System. Bei einem RAID5 wäre die Wahrscheinlichkeit extrem hoch, dass es schief geht.

 

[Renegade33]

Und natürlich nutze ich fast überall "nur" Mirrors, darf also nur ein Device verlieren. Daher schrieb ich "choose your poison".

Klar bei Mirror darf nur eine Platte kaputt gehen. Das Problem mit dem "Lesefehler" ist hier ja auch gegeben, aber halt nur mit Faktor 1 Platte. Dieser muss ja logischerweise je weitere Platte multipliziert werden. Verstehe ich das so richtig?

Deine Einschätzung ist richtig, aber die Zahlen kann eh niemand ernsthaft verifizieren. Schon Mitte der 2000er Jahre haben ein die HP Raidcontroller angemeckert wenn man 12 oder mehr Disks in ein RAID5 packen wollte. Das war zu 36/72 GB Diskzeiten. RAID5 ist zwar besser als Raid0 aber trotzdem bei großen Disks kein echter Schutz. Ich habe in meiner IT Laufbahn schon viele korrupte RAID5 gesehen.

Das Zahlenspiel ist ja immer eine schöne Theorie, aber ich denke auch, dass die meisten sich sowieso nichts genaues darunter vorstellen können.
Gehe ich mit meiner Annahme richtig, dass Raidz1 mit RAID5 gleichzusetzen ist, was diesen Fehler angeht? Auch wenn es ein zfs Filesystem ist?