Snapshot im Falle von ZFS: bedient sicht des COW (copy on write) verfahrens welches in ZFS generell für Schreibzugriffe verwendet wird. Wird eine Datei geändert
werden diese Änderungen auf einem freien Speicherbereich erneut abgelegt. Bei einem Snapshot passiert nix anderes, diese alten Bereiche nicht wieder zu überschreiben und an den Stempel des Snapshots zu binden. Der große Vorteil von ZFS gegeübern anderen Dateisystemen, ist dass der Snapshot, einfach und Ressourcenschonend und ohne vorherige Reservierung von Speicher erstellt wird.
Da das COW Verfahren Blockweise angewendet wird, ist der Speicher Overhead gering, allerdings anhängig vom gespeicherten Datentyp - Bsp Datenbank Daten- oder gar Logfiles erzeugen einen gewaltigen Overhead durch snapshots, Programmdateien und Dokumente einen sehr geringen.
Snapshots können in ZFS lesend gemounted werden, daraus kann ein Clone erzeugt werden, welcher auch beschreibar ist.
NORMALERWEISE nutzt man Snapshots als 1. Step im Laufe eines Backups.
Diese Snapshots werden gesichert und ermöglichen es auf einfachem Wege and die gewünschten Stellen der Snapshots zurückzukehren.
-> frei zusammengeschrieben
Die Crux an der ganzen Geschichte ist, dass sich Snapshots immer auf den zu sichernden Datenbestand beziehen. Wesshalb sie per Definition nicht ein Backup ersetzten können. In Kombination mit einer Replication sieht das ganze dann schon etwas anders aus -> aber das geht dann schon in Richtung CDP (Continuos Data Protection).
ZFS bietet ein paar sehr gute Ansätze, zb die Hardwareunabhängigkeit, oder des integrieren der Volumeinformations in das Filesystem.
Daraus zu schließen, dass man vor Fehlerhafter Hardware geschützt ist, wäre voreilig. Ein Disk-Controller kann durchwegs fehlerhaft sein, und weiterhin Daten schreiben und lesen...
Aber ZFS bietet ja Checksummen, genau, und sogar recht clevere, während die meisten Dateisysteme Checksummen in den entsprechenden Datenblock schreiben, geht ZFS hier einen anderen Weg und schreibt diese Checksummen in einen anderen Block, welcher ja seinerseits von einem weiteren in seiner konsistens bestätigt wird. Dadurch wir garantiert, dass der Datenblock der im Ram landet integer ist (wichtiger Punkt wesshalb ECC-Ram in ein ordentliches ZFS-System gehören). schützt dich dieser Prozess vor fehlerhaften Schreibvorgängen - nein.
Warum ECC - nach einer Studio von Google gibt es eine 8% Chance dass ein Arbeitsspeicherriegel innerhalb des 1. Jahres im 24/7 einen Single-bit Fehler erfährt,
pro Riegel....
The chain ist not stronger than its weakest link....
Das ganze könnte man noch weiter ausführen indem man die URE-Quote von SATA-Consumer Disks mit in die Rechnung zieht.
URE - Unrecoverable Read Error, da gibts ein nettes Dokument von Oracle über das Thema (Raid Mathematics for DBAs), in welchem dargelegt wird, dass du statistisch bei 10TB lesend von normalesn SATA-Disks mindestens 1 Nichtkompensiebaren Lesefehler erleidest.
Es gibt Gründe warum Leute ein klassisches Backup (oder CDP mit Snapshots) einsetzten.
Backup ist wie Hubraum
Deine Antwort aufs Backup war folgende:
"Na darum läuft's ja im Raid und im ZFS statt Hardware Raid um auch mit anderer Hardware das ganze wieder online zu bekommen wenn da mal schief läuft..."
und das ist einfach nicht richtig.
Bei 6TB Projektdaten ging ich von einem produktiven Einsatz aus, nein? OK mein Fehler -> sorry
(15 Euro je 10 GB...)
)
