Backup-Strategie NAS

[brummpl]

Hallo zusammen, ich hoffe, ich habe diesen Beitrag jetzt im richtigen Unterforum erstellt -- wenn nicht, bitte verschieben!

Ich habe vor, mir für meine Backups ein NAS zu bauen. Aus welcher Hardware soll hier (vorerst) nicht Thema sein, sondern die Strategie, mit der ich das NAS für meine Backups verwenden kann. Wichtig, ich möchte ZFS verwenden (z.B. ein RAIDZ), damit mit der Zeit entstehende Fehler (Silent Data Corruption, siehe unten) automatisch behoben werden können.

Was ich sichern möchte:
1) Komplett-Images. Die sind sehr groß und brauchen lange, also hätte ich sie eher selten gemacht.
2) Meine Daten. Natürlich möglichst oft. =)

Was dabei problematisch ist:
1) Viren, sonstiger böser Code, meine eigene Dummheit
Wenn ich die Backup-Verzeichnisse einfach so per Netzwerk beschreibbar einbinde, können die Daten jederzeit kaputtgemacht werden.
2) Silent Data Corruption
Mit der Zeit können Bits kippen und Daten kaputt gehen. Auf dem NAS beuge ich dem mit der Verwendung von ZFS mit Redundanz vor. Aber auf meinen Rechnern? Dieser Punkt stellt mich vor große Probleme, denn solche Dinge wie z.B. Backup-Ketten, die mit der Zeit alte Versionen löschen, halten nach einiger Zeit nur noch die kaputt gegangenen Dateien vor! Alle Versionen behalten braucht aber auf die Dauer unendlich viel Platz...

Mein Ansatz eines Ansatzes:
1) NAS mit drei unterschiedlichen Bereichen (IMAGES, ARCHIV, BACKUP).
2) In den Bereich IMAGES mache ich z.B. mit Acronis Images. Eine Kette, und täglich einen Snapshot gemacht. Die letzten paar hebt man auf, die davor löscht man von Zeit zu Zeit.
3) In den Bereich BACKUP mache ich täglich Backups meiner Daten. Das gleiche Snapshot-Schema wie in 2).
4) In den Bereich ARCHIV mache ich täglich Backups meiner Daten, aber nur derer, die sich schon einige Zeit nicht mehr geändert haben. Das schließt schon mal solche Monsterdatenfresser aus wie z.B. die outlook-PST. Außerdem gibt es manuelle Ausschlüsse von Daten, die ich nicht archiviert brauche. Klassischer Ausschluss: Der Mirror-Ordner vom Smartphone, in dem die installierten Apps liegen. Klassischer Nicht-Aussschluss: Die Fotosammlung. Von diesem Bereich werden auch täglich Snapshots gemacht, diese werden NIE mehr gelöscht ("das ewige Archiv"). Sollte auch gar nicht nötig sein, weil nur die Daten drin liegen, die sich eh nicht mehr ändern.

Jetzt mal ganz unabhängig von dem genauen Wie: Was haltet ihr von diesem unkonkreten Ansatz-Ansatz? Hab ich irgendwelche schwerwiegenden Denkfehler drin oder wie würdet ihr es machen?

Viele Grüße!

 

[Katharsas]

Also in Macrium Reflect kann man das z.B. so machen:

- Als Backup-Typ reines inkrementelles Backup nehmen (es wird dann einmalig ein volles Backup gemacht und dann nur noch die inkrementellen Änderungen)
- Die gewünschte Zeitspanne einstellen ab wann die alten inkrementellen Backups in das volle Backup integriert werden sollen (zum Beispiel 2 Jahre)
- Einstellen wie oft die inkrementellen Backups gemacht werden sollen (z.B. jede Stunde/ jeder Tag)

Fertig.
Dann hast du IMMER ein 2 Jahre altes Komplett-Backup und die Änderungen von jedem Tag / jeder Stunde zwischen dem vollen Backup und dem aktuellen Zustand deiner Dateien. Also bei einem Backup pro Tag hast du dann 2 * 365 inkrementelle Backups und das älteste davon wird jeden Tag in das volle Backup übertragen und gelöscht und das neue Backup vom aktuellen Tag kommt dazu.

Sprich du hast die komplette Historie von vor 2 Jahren bis jetzt.

Theoretisches Problem hierbeit ist, dass es ne Weile dauern kann, bis Macrium die ganzen Änderungen aufsummiert hat wenn du wissen willst wie ne Datei zum Zeitpunkt X aussah. Um das zu lösen kann man statt inkrementellen auch differenzielle Backups machen (da wird dann z.B. jeden Tag der Unterschied zum VOLLEN Backup gespeichert, nicht der Unterschied zum letzten Tag), was aber mehr Speicherplaytz kostet.

Vorteil:
Speicherplatzverbrauch ist EXTREM gering. Wenn nicht allzu oft allzu viele Dateien verändert werden kann man locker mit 200% Speicherplatz für alle Backups im Vergleich zu den jetzigen Daten hinkommen.

 

[octo124]

Kenne obige Software nicht, aber schon der beschriebene Weg - erst inkrementuelle ins Grundimage einbinden, um dann erst ein verfügbares Restoremedium zu haben - okay wer Zeit hat...
True Image - Grundsicherung, Planung der Intervalle, jeweils ein inkrementuelles auf Basis des letzten inkrementuellen. TI ist es nun egal, welches Image restauriert werden soll = das anvisierte Inkrementuelle liefert im Ergebnis das damals vorhandene Komplettsystem.
Ist z.B. ein Buchungsjahr rum, erstellt man ein neues Grundimage und weiter wie oben.
Nicht zu vergessen, dass man auch gezielt nur einzelne Dateien/Ordner recovern kann - ganz nach Wunsch.
Voraussetzung, man versteht ein Handbuch zu lesen inkl. erlernt vor dem Ernstfall, wie das alles in der Praxis funktioniert.
Gibt noch andere gleichwertige Progs, muss jeder nach der Wichtigkeit seiner Daten selbst beurteilen, was es ihm wert ist.

Nun zu deiner Hardwarelösung:
Was passiert, wenn der Controller des NAS das zeitliche segnet? Glaub das solltest du für tägliche Update nutzen und in anderen Zeitabständen extern sichern und dort die alten im Intervall x löschen.
Zum möglichen Stromausfall käme dann evt. noch eine USV usw..

Gibt viele Wege, die nach Rom führen....

 

[Ilsan]

Dafür brauchste keine Software ZFS kann genau das von Haus aus, einfach mal beschäftigen mit Snapshots und Replication.

Machst einfach nen Snapshot von deinen Daten und sendest den dann zu einem anderen Pool, dem Backup halt. Muss man sich aber bisschen mit beschäftigen.

 

[Katharsas]

Es sei noch erwähnt, dass ich bei mir einfach das inkrementelle Backup bzw. den Tag auswähle den ich haben will und dann auf "Image einbinden" klicke. Die Software mountet dann das Backup in ein virtuelles Laufwerk und macht das ganze zusammenrechnen automatisch unter der Haube.

Jetzt fällt mir auch wieder ein, was das eigentliche Problem war (gilt auch für andere Software):
Wenn eines der inkrementellen Updates kaputt geht (was eigentlich nicht passieren sollte aber ok), sind auch alle nachfolgenden fürn Arsch. Aber deswegen gibts ja auch andere Strategien zur Auswahl (z.B. jedes Jahr ein volles Backup, jeden Monat ein differenzielles und jeden Tag ein inkrementelles. so verliert man bei Korruption nur einen Monat Historie, nachfolgende Monate nicht betroffen).

 

[Ilsan]

Naja ist warscheinlich genau das Problem weil das Tool auf Dateiebene arbeitet. Mit ZFS haste das Problem so nicht, weil es direkt im Dateisystem implementiert ist. Auf spezielle Software zurückgreifen sollte man eigentlich nur dann machen wenn das was man vorhat von "Haus aus" nicht geht. Mit ZFS bekommste das aber hin. Nachteil: Du musst dich ein wenig auskennen, ist halt nicht umbedingt diese typische 2-clicks-und-fertig Lösung.

 

[Katharsas]

Ja bei Backups gehe ich absichtlich zu einem Software-Hersteller und kaufe ein Produkt. Weil ich dann nämlich erwarten kann, eine super-simple Klickibunit-GUI zu bekommen, bei der man (hoffentlich) nix falsch machen kann.
Außerdem habe ich dann einen Kontakt, dem ich die Hölle heiß machen kann, wenn es Probleme gibt (Wen motz ich voll wenn ZFS Bugs hat oder inkorrekte Dokumentation? ). Ist halt in Sachen Support schon was anderes.

Und was Kosten betrifft:
Wenn man mal 800 Euro für ne Festplatten-Rettung bezahlt hat, rückt das die Preise von Backup-Software in ein ganz anderes Licht. Und mit inkrementellen Updates spart man wie gesagt massive Platten ein.

 

[Ilsan]

Und mit inkrementellen Updates spart man wie gesagt massive Platten ein.

Richtig, ich wollte nur anmerken dass eine Softwarelösung auf einem Dateisystem eben nur genau das ist. Die Fähigkeiten von ZFS gehen halt viel weiter da dies alles direkt im Dateisystem schon mit integriert ist.

Support von "ZFS" bzw dem OS bekommt man auch, nur arbeitet niemand ohne Geld, sollte bekannt sein, wenn man gewillt ist Geld zu bezahlen findet man da aber Möglichkeiten. Ob sie was für Homeuse sind mag dann wieder auf einem anderen Blatt stehen.

Das ZFS Bugs besitzt, wie alles im IT Bereich ist nicht auszuschließen dennoch sei angemerkt dass ZFS auch in Rechenzentren eingesetzt wird mit vielen Tausenden Kunden auf unzähligen Servern. Das Interesse einen Bug zu fixen sofern es ihn den gibt ist damit ausgesprochen hoch.
Ferner gab es bei bislang kein offizieles Release mit einem Bug der Datenverlust verursacht. Von daher bewegt man sich hier was Datensicherheit angeht auf einem ausgesprochen hohen Niveau. Höher als das mit klassischen Raid Systemen und Dateisystemen wie ext4 oder NTFS der Fall ist.
ZFS ist auch ausgiebig getestet worden und Funktioniert schon seit Jahren.
Da sehe ich persönlich die Gefahr für Datenverlust durch einen Bug bei irgendeinem Backuptool schon für höher ein.
Letztendlich bleibt es natürlich jedem selber überlassen wie und womit er seine Daten schützt vor Verlust.

Im Bezug auf ZFS ist der ZFS-Stammtisch im Hardwareluxxforum zumindest im Deutschsprachigen Raum aber die erste Anlaufstelle. Ehrlich gesagt habe ich hier in diesem Forum noch keinen gesehen der wirklich viel Ahnung von ZFS hat, aber viele Halbwahrheiten. Das Forum hier hat sicher auch seine Stärken, ZFS gehört aber eher nicht dazu.

Der typische NAS Nutzer setzt es halt nicht ein bzw kennt es nichtmal.

 

[brummpl]

Wow, so viele Antworten. Dankeschön! :-)

Also in Macrium Reflect kann man das z.B. so machen: (...)

(...)
True Image - Grundsicherung, Planung der Intervalle, jeweils ein inkrementuelles auf Basis des letzten inkrementuellen. (...)

Diese beiden Lösungen haben den Pferdefuß, dass sie nicht vor silent data corruption schützen, und das ist mir extrem wichtig. Was haltet ihr denn nun von meinem Ansatz-Ansatz?

Was passiert, wenn der Controller des NAS das zeitliche segnet?

Dann würde ich die Platten in ein anderes NAS einbauen. Da ich keinen RAID-Controller benutze, sollte das meines Wissens kein Problem darstellen. (Oder?) Für den Fall, dass einzelne Platten kaputt gehen, habe ich das RAIDZ, für den Fall, dass ich das ganze Kistl runterwerfe oder beim Skat verspiele, würde ich alle paar Monate eine externe Festplatte anschließen und per ZFS send ein Backup-Backup nur von ARCHIV machen.

Dafür brauchste keine Software ZFS kann genau das von Haus aus, einfach mal beschäftigen mit Snapshots und Replication.

Leider arbeite ich noch mit Windows. Also schon mal kein ZFS für die täglichen Daten. :-(

Im Bezug auf ZFS ist der ZFS-Stammtisch im Hardwareluxxforum zumindest im Deutschsprachigen Raum aber die erste Anlaufstelle.

Wo finde ich das? Habe unter dem Namen nur einen Sammelthread gefunden, meinst du den?

Der typische NAS Nutzer setzt es halt nicht ein bzw kennt es nichtmal.

Dabei ist es doch gefühlt das coolste überhaupt!!

 

[Bagbag]

Diese beiden Lösungen haben den Pferdefuß, dass sie nicht vor silent data corruption schützen, und das ist mir extrem wichtig.

Das hast du doch, indem du die Images auf dem auf ZFS lagerst.

Für ein Backup auf Dateiebene kann ich dir wärmstens restic empfehlen.

 

[brummpl]

Das hast du doch, indem du die Images auf dem auf ZFS lagerst.

Moment, warte mal. Auf dem NAS ist ZFS in Verwendung, nicht auf meinen Rechnern! Wenn ich jetzt immer vom Rechner auf das NAS sichere und irgendwann die alten Versionen wegwerfe, gibt es einen Tag X, an dem eine Datei auf dem Rechner unbemerkt kaputt geht, einen Tag Y, an dem diese kaputte Version ins Backup wandert und einen Tag Z, an dem die letzte nicht-kaputte Version aus dem Backup gelöscht wird.

Oder sitze ich da einem Denkfehler auf? Denn das ist ja der Grund, dass ich den Tanz mit ARCHIV mache...

 

[Bagbag]

Du hast recht. Die Denklücke liegt bei mir.

 

[Katharsas]

Wenn ich jetzt immer vom Rechner auf das NAS sichere und irgendwann die alten Versionen wegwerfe, gibt es einen Tag X, an dem eine Datei auf dem Rechner unbemerkt kaputt geht, einen Tag Y, an dem diese kaputte Version ins Backup wandert und einen Tag Z, an dem die letzte nicht-kaputte Version aus dem Backup gelöscht wird.

Anmerkung:
Wie weit Tag Z von Tag Y entfernt ist (Unterschied X -> Y ist wohl vernachlässigbar) ist ja letztendlich lediglich eine Frage der Speicherplatzeffizienz. Und ich denke, dass man mit den Standardstrategien die jede ordentliche Software zur Verfügung stellen sollte (voll vs differentiell vs inkrementell) effizient genug fährt, um sich da keine großen Gedanken mehr machen zu müssen.

Mal zu deinen Ideen:
Die sind leider nicht wirklich verständlich solange man nicht weiß von welcher Art von Backup du sprichst (vollbackup vs andere Arten). Man kann also nur vermuten:

IMAGES:
Ich nehme an du meinst mit "Kette" ein Vollbackup gefolgt von täglichen inkrementellen Updates die ab einer gewissen Anzahl ins Vollbackup übergehen, wie von mir beschrieben oben. Soweit ok, macht Sinn.
BACKUP:
Ist ja laut deiner Bezeichung exakt das gleiche wie IMAGES, nur für andere Daten. Kannst du also auch eigentlich im selben Backup wie IMAGES machen.
ARCHIV:
Das soll ja anscheinend irgendwie das gleiche wie IMAGES/BACKUP sein, nur dass du die inkrementellen Updates nie ins Vollbackup mergst bzw. wo die Zeitspanne dafür so lang gewählt ist, dass es nie passiert? Warum machst du nicht einfach die Zeitspanne für IMAGES/BACKUP länger, dann kannst du dir das hier komplett sparen.
Ich bin mir ziemlich sicher, dass die Duplikation von Daten in mehreren Backups dir mehr Speicherplatz kostet als wenn du einfach die inkrementellen Backups länger behälst. Außer natürlich du hast mehrer 100 Gigabyte Daten die andauern verändert werden.

 

[Ilsan]

Warum machst du nicht einfach Snapshots je nachdem wieviele du benötigst in den entsprechenden ZFS Datasets und holst dir ne USB Platte als Backup Medium und benutzt dann ZFS replication?

Für etwas mehr Sicherheit beim Backup könntest du copies=2 setzen, dann werden die Datenblöcke der Userdaten 2mal geschrieben auf das Medium, sprich wenn mal ein Sektor defekt ist, kann ZFS einfach die Kopie lesen. Nachteil du benötigst dann natürlich den doppelten Platz, sprich auf ner 8TB Platte würdest nur 4TB Daten, also Netto, speichern können. Müsstest nur checken ob copies=2 mit replication funktioniert, aber ich denke schon.

Bei mir mache ich Snapshots wie folgt: Alle 15Minuten und behalte die letzten 4. Jede Stunde und behalte die letzten 24. Jeden Tag und behalte die letzten 30, Jede Woche und behalte die letzten 6, Jeden Monat und behalte die letzten 12.

Wenn keine Änderungen stattgefunden haben ist die größe eines Snapshots automatisch 0Byte, da der Snapshot nur die Veränderung zum aktuellen Zustand festhält.

 

[brummpl]

Wie weit Tag Z von Tag Y entfernt ist (Unterschied X -> Y ist wohl vernachlässigbar) ist ja letztendlich lediglich eine Frage der Speicherplatzeffizienz. Und ich denke, dass man mit den Standardstrategien die jede ordentliche Software zur Verfügung stellen sollte (voll vs differentiell vs inkrementell) effizient genug fährt, um sich da keine großen Gedanken mehr machen zu müssen.

Mein Denkansatz war der folgende: Silent Data Corruption ist so schlimm, weil sie nicht auffällt. Also erst nach x Jahren. Deshalb ist die Anforderung an ARCHIV, dass die alten Versionen NIE weggeworfen werden, um hier auf der sicheren Seite zu sein. Und das ist nur dann möglich, wenn nur Dateien hineinkommen, die sich nicht mehr ändern -- denn nur dann brauchen sie auch keine neuen Versionen! Die einzigen neuen Versionen entstehen, wenn was kaputtgegangen ist, und genau dann ist es auch super.

Ich nehme an du meinst mit "Kette" ein Vollbackup gefolgt von täglichen inkrementellen Updates die ab einer gewissen Anzahl ins Vollbackup übergehen, wie von mir beschrieben oben. Soweit ok, macht Sinn.

Genau, z.B. Images mit Acronis, das dann eben zur Zeitersparnis mit inkrementellen Addita. Ab und zu ein neues Vollbackup, damit auch Dateien mitgesichert sind, die das Programm nicht als geändert wahrnimmt.

Ist ja laut deiner Bezeichung exakt das gleiche wie IMAGES, nur für andere Daten. Kannst du also auch eigentlich im selben Backup wie IMAGES machen.

Seeeeeeehr guter Punkt!!! Herzlichen Dank dafür. Ursprünglich, als ich noch kein ZFS mit Snapshots in der Planung drin hatte, war eine Anforderung: Kein schreibender Zugriff aufs Backupmedium, wenn das System läuft! Sonst löscht das Würmchen die Backups mit. Das fällt mit den Snapshots weg. Insofern: Ja, da hast du vollkommen recht!

Das soll ja anscheinend irgendwie das gleiche wie IMAGES/BACKUP sein, nur dass du die inkrementellen Updates nie ins Vollbackup mergst bzw. wo die Zeitspanne dafür so lang gewählt ist, dass es nie passiert? Warum machst du nicht einfach die Zeitspanne für IMAGES/BACKUP länger, dann kannst du dir das hier komplett sparen.

Nein, siehe oben.

Ich bin mir ziemlich sicher, dass die Duplikation von Daten in mehreren Backups dir mehr Speicherplatz kostet als wenn du einfach die inkrementellen Backups länger behälst. Außer natürlich du hast mehrer 100 Gigabyte Daten die andauern verändert werden.

Schon alleine die ganzen PST-Dateien brauchen irre viel Platz. Und ich mache regelmäßig Backups z.B. vom Smartphone, die brauchen viele Gigabytes an Daten! Die möchte ich mitsichern, aber definitiv nicht für immer.

Warum machst du nicht einfach Snapshots je nachdem wieviele du benötigst in den entsprechenden ZFS Datasets und holst dir ne USB Platte als Backup Medium und benutzt dann ZFS replication?

Weil ich keine ZFS Datasets habe. Ich habe nur Windows- und Linux-Computer ohne jegliches ZFS. Oder verstehe ich dich falsch?

Für etwas mehr Sicherheit beim Backup könntest du copies=2 setzen...

Die Option kenne ich, aber hat die nicht den Nachteil, dass auch beide cop-- Kopien auf der gleichen Platte liegen können? Ich hab copies=... bislang immer nur für einen Notnagel gehalten, wenn man aus irgendeinem Grund keine Redundanzplatte bzw. ein RAIDZ machen kann. Und letzteres soll ja sogar in irgendeiner Zukunft expansion unterstützen. :-)

Bei mir mache ich Snapshots wie folgt: Alle 15Minuten und behalte die letzten 4. Jede Stunde und behalte die letzten 24. Jeden Tag und behalte die letzten 30, Jede Woche und behalte die letzten 6, Jeden Monat und behalte die letzten 12.

Dabei wirfst du ja auch was weg. Solange die Herkunft der Daten keine Silent Data Corruption verhindert, verhindert das auch keine Silent Data Corruption.

Wenn keine Änderungen stattgefunden haben ist die größe eines Snapshots automatisch 0Byte, da der Snapshot nur die Veränderung zum aktuellen Zustand festhält.

0 Byte? Das kann ich mir nicht vorstellen. Aber dass der verwendete Platz zu vernachlässigen ist, denke ich schon.

 

[Ilsan]

Die Option kenne ich, aber hat die nicht den Nachteil, dass auch beide cop-- Kopien auf der gleichen Platte liegen können? Ich hab copies=... bislang immer nur für einen Notnagel gehalten, wenn man aus irgendeinem Grund keine Redundanzplatte bzw. ein RAIDZ machen kann. Und letzteres soll ja sogar in irgendeiner Zukunft expansion unterstützen. :-)

Soweit ich weiß speichert ZFS die Blöcke wenn man copies=2 oder 3 setzt so ab dass sie immer maximal auseinander liegen. Bei 2 Platten natürlich dann auf jeder dann eine, auf einer Platte in den Sektoren die maximal auseinander liegen. Aber dieses Feature ist meiner Meinung nach eher für einzelne Platten gedacht zB wenn man eine Große Platte hat, aber nur wenig Daten, da macht es natürlich Sinn die Datenblöcke doppelt zu speichern, sodass wenn manche Sektoren dann nicht gelesen werden können es immer noch ne Kopie gibt.
Metadaten sind immer Anzahl=copieszahl+1 und Metadaten über das Dataset und den Pool sogar copieszahl+2 gespeichert. Also selbst bei Copies=1, was der Defaultwert ist, sind wichtige Daten für den Pool sowieso mehrfach gespeichert. ZFS selbst soll auch damit klarkommen wenn bis zu 1/8 der Oberfläche der Platte überschrieben wurde, sprich das ZFS Dataset ist dann immer noch intakt nur die überschriebenen Dateien sind weg, aber die Platte wird weiterhin noch erkannt.

Dabei wirfst du ja auch was weg. Solange die Herkunft der Daten keine Silent Data Corruption verhindert, verhindert das auch keine Silent Data Corruption.

Snapshots haben damit nix zu tun. Um die Integrität der Daten kümmert sich ZFS. Snapshots halten im Grunde nur die Blöcke fest die quasi zum löschen freigegeben wurden. Was du damit meinst verstehe ich nicht. ZFS arbeitet ja nicht auf Dateiebene sondern auf Blockebene. Für jeden Block gibt es eine Prüfsumme, von der es sogar noch ne Kopie gibt, selbst bei Pools mit nur eine Platte. Beim Scrub passiert zB folgendes: ZFS berechnet die Prüfsumme des Blockes und vergleicht sie mit der abgelegten Prüfsumme, stimmen die nicht über ein kann ZFS sich auch noch die Kopie der Prüfsumme angucken. Und selbst die Prüfsummen der Blöcke sind nochmal durch Prüfsummen gesichert.
Nachteil ist natürlich der Overhead, glaube 1/64 der Größe der Datenplatte, was schon bei ein paar GB sind bei Datenplatten. Und was wegwerfen tue ich ja, weil ich keine Auflösung von 15Minuten brauche Monate oder Jahre in der Vergangenheit. Es reicht mir wenn ich die letzte Stunde mit 15Minuten Genauigkeit zurückgehen kann. Mit Silent Date Corruption hat das aber nix zu tun, dieser Schutz ist gewährleistet sobald die Daten auf die Platte geschrieben sind.

0 Byte? Das kann ich mir nicht vorstellen. Aber dass der verwendete Platz zu vernachlässigen ist, denke ich schon.

Sie sind wirklich "0 Byte". Wenn du 2GB drauf hast, dann einen Snapshot machst ist der 0 Byte groß, löscht du dann 1GB, ist der Snapshot 1GB groß, weil er die entsprechenden Sektoren ja "festhalten" muss.
ZFS selber gibt aber nur an wieviel Platz durch das Löschen des Snapshots freiwerden würde, halten mehrere Snapshots dieselben Daten fest, dann wird mit 0 Byte gerechnet, weil beim löschen eines Snapshots dann keine Daten freigegeben werden können. Ein Snapshot ist quasi das "eingefrorene" Dataset zu dem jeweiligen Zeitpunkt.

Ergänzung (14. Oktober 2018)

Weil ich keine ZFS Datasets habe. Ich habe nur Windows- und Linux-Computer ohne jegliches ZFS. Oder verstehe ich dich falsch?

Bei ZFS gibt es vdev, ein vdev selber kann, muss es aber nicht, redundant aufgebaut sein. zB Mirror sein, RaidZ1 usw sein. Ein Pool beinhaltet mindestens ein vdev. Und auf diesem Pool liegen die "ZFS Ordner" oder auch "ZFS Datasets" genannt. Und in dem liegen die Daten.

Ob es genau das ist was du suchst weiß ich nicht, ZFS arbeitet wie gesagt Blockbasiert und nicht Filebasiert. ZFS "weiß" auch nicht was du genau mit den Dateien gemacht hast weil es ein CoW Dateisystem ist. Veränderst du etwas schreibst du neue Blöcke und verändert die alten Blöcke nicht "in Place" wie bei anderen Dateisystemen. Der Block der dann ungültig ist wie als freimarkiert, Ausnahme, ein Snapshot hält ihn fest und schützt ihn so davor überschrieben zu werden.

 

[brummpl]

Hallo Ilsan, vielen Dank für deine Beiträge, die sind echt eine große Bereicherung für mich. :-)

Soweit ich weiß speichert ZFS die Blöcke wenn man copies=2 oder 3 setzt so ab dass sie immer maximal auseinander liegen. Bei 2 Platten natürlich dann auf jeder dann eine, auf einer Platte in den Sektoren die maximal auseinander liegen. Aber dieses Feature ist meiner Meinung nach eher für einzelne Platten gedacht zB wenn man eine Große Platte hat, aber nur wenig Daten, da macht es natürlich Sinn die Datenblöcke doppelt zu speichern, sodass wenn manche Sektoren dann nicht gelesen werden können es immer noch ne Kopie gibt.
Metadaten sind immer Anzahl=copieszahl+1 und Metadaten über das Dataset und den Pool sogar copieszahl+2 gespeichert. Also selbst bei Copies=1, was der Defaultwert ist, sind wichtige Daten für den Pool sowieso mehrfach gespeichert. ZFS selbst soll auch damit klarkommen wenn bis zu 1/8 der Oberfläche der Platte überschrieben wurde, sprich das ZFS Dataset ist dann immer noch intakt nur die überschriebenen Dateien sind weg, aber die Platte wird weiterhin noch erkannt.

Ich hätte da jetzt aber trotzdem ein RAIDZ (1 oder 2) dem Wert copies den Vorzug gegeben, ganz einfach weil man da einfach Platten austauschen kann.

[Erklärung zu Snapshots und Scrubbing]

Danke für die Erklärung :-)

Snapshots haben damit nix zu tun. Um die Integrität der Daten kümmert sich ZFS. [...] Und was wegwerfen tue ich ja, weil ich keine Auflösung von 15Minuten brauche Monate oder Jahre in der Vergangenheit. Es reicht mir wenn ich die letzte Stunde mit 15Minuten Genauigkeit zurückgehen kann. Mit Silent Date Corruption hat das aber nix zu tun, dieser Schutz ist gewährleistet sobald die Daten auf die Platte geschrieben sind.

Ich glaube, hier ist der große Knackpunkt, wo wir noch aneinander vorbeireden: Das Backup aufs NAS soll mich vor Silent Data Corruption auf der Quelle schützen, also auf den Rechnern, auf denen kein ZFS, sondern ein NTFS oder schlimmer verwendet wird. Wenn ich von da auf das NAS Backups mache und die alten Versionen irgendwann wegwerfe, dann ist irgendwann von einer Datei, die auf der Quelle kaputt gegangen ist, nur noch die kaputte Version im Backup!

Sie sind wirklich "0 Byte". Wenn du 2GB drauf hast, dann einen Snapshot machst ist der 0 Byte groß, löscht du dann 1GB, ist der Snapshot 1GB groß, weil er die entsprechenden Sektoren ja "festhalten" muss.
ZFS selber gibt aber nur an wieviel Platz durch das Löschen des Snapshots freiwerden würde, halten mehrere Snapshots dieselben Daten fest, dann wird mit 0 Byte gerechnet, weil beim löschen eines Snapshots dann keine Daten freigegeben werden können. Ein Snapshot ist quasi das "eingefrorene" Dataset zu dem jeweiligen Zeitpunkt.

Wie viel Platz brauchen denn die Metadaten des Snapshots? Das hatte ich mit dem, dass ich 0 Byte bezweifle, gemeint. ;-)

Ob es genau das ist was du suchst weiß ich nicht, ZFS arbeitet wie gesagt Blockbasiert und nicht Filebasiert. ZFS "weiß" auch nicht was du genau mit den Dateien gemacht hast weil es ein CoW Dateisystem ist. Veränderst du etwas schreibst du neue Blöcke und verändert die alten Blöcke nicht "in Place" wie bei anderen Dateisystemen. Der Block der dann ungültig ist wie als freimarkiert, Ausnahme, ein Snapshot hält ihn fest und schützt ihn so davor überschrieben zu werden.

Das ist auch noch ein Punkt, den ich adressieren muss: Nur das ersetzen (in ARCHIV!), was geändert wurde. Dabei dachte ich an rsync oder vergleichbares (https://unix.stackexchange.com/ques...gz-files-to-zfs-filesystem-and-snapshot-later), aber so weit bin ich noch nicht, momentan bin ich noch dabei, zu eruieren, ob mein Konzept mit dem ARCHIV denn überhaupt taugt. :-)

 

[Ilsan]

Wie viel Platz brauchen denn die Metadaten des Snapshots? Das hatte ich mit dem, dass ich 0 Byte bezweifle, gemeint. ;-)

Das weiß ich nicht, kann aber auch sein dass dieser minimale Platz auch schon vorher längst reserviert wurde. Spielt aber auch keine Rolle, so oder so sind Snapshots daher 0 Byte solange keine Blöcke gelöscht worden sind die der Snapshot festhalten müsste.

Ich glaube, hier ist der große Knackpunkt, wo wir noch aneinander vorbeireden: Das Backup aufs NAS soll mich vor Silent Data Corruption auf der Quelle schützen, also auf den Rechnern, auf denen kein ZFS, sondern ein NTFS oder schlimmer verwendet wird. Wenn ich von da auf das NAS Backups mache und die alten Versionen irgendwann wegwerfe, dann ist irgendwann von einer Datei, die auf der Quelle kaputt gegangen ist, nur noch die kaputte Version im Backup!

Aber was spricht dagegen die Dateien generell auf dem NAS zu speichern? Also meine Dokumente zuhause liegen auf dem NAS und nicht auf dem einzelnen PCs, außer unwichtiges Zeug wie irgendwelche Downloads von Datenblättern.
Obendrein musst du ja auch nicht jeden Snapshot löschen, du kannst ja jede Woche welche machen die du dann "ewig" behälst.
Es gibt wenn man Napp-It als Webinterface benutzt auch die Möglichkeit Snapshots zu löschen mit der Größe 0Byte. Sprich wenn du nix änderst sind die ja quasi leer, und können dann automatisch gelöscht werden, dann hat man nicht unmengen von Snapshots die quasi alle den gleichen Datenbestand gespeichert haben.
Mal angenommen ich mache jede Stunde einen Snapshot für einen Tag, verändere aber nix dran, dann hätte ich 24 Snapshots mit der Größe 0 Byte, in dem Fall würden dann alle bis den aktuellste gelöscht. Ich mein ZFS stellt halt nur sicher dass die Daten die du abgelegt hast irgendwann genau bit für bit auch genau so wieder gelesen werden. Wenn Windows von außen Mist baut und was überschreibt kann ZFS dafür ja nix. Das Problem ist ja auch zu erkennen ob das überschreiben jetzt gewollt oder nicht gewollt ist. Zusätzliche Tools kannst du ja auch noch einsetzen wenn die dir einen Mehrwert bringen.

Ich hätte da jetzt aber trotzdem ein RAIDZ (1 oder 2) dem Wert copies den Vorzug gegeben, ganz einfach weil man da einfach Platten austauschen kann.

Ja copies macht imo nur Sinn wenn man nur eine Platte hat, zB in Laptops, als NAS oder Server ist die Option eher uninteresant weil ein Mirror oder sonstiges mehr Sinn macht.

 

[brummpl]

Aber was spricht dagegen die Dateien generell auf dem NAS zu speichern? Also meine Dokumente zuhause liegen auf dem NAS und nicht auf dem einzelnen PCs, außer unwichtiges Zeug wie irgendwelche Downloads von Datenblättern.

Dass ich es als Backupmedium möchte. Ich möchte möglichst regelmäßig/oft Backups machen und wiederherstellen können, wenn mir ein Gerät beim Putzen vom Tisch fällt.

Obendrein musst du ja auch nicht jeden Snapshot löschen, du kannst ja jede Woche welche machen die du dann "ewig" behälst.

Dann darf ich aber nicht alles reintun, also ergibt die Aufteilung in IMAGE (alles, mit Wegwerfen) und ARCHIV (nur Daten, die sich nicht mehr ändern) schon Sinn, oder?

Es gibt wenn man Napp-It als Webinterface benutzt auch die Möglichkeit Snapshots zu löschen mit der Größe 0Byte. Sprich wenn du nix änderst sind die ja quasi leer, und können dann automatisch gelöscht werden, dann hat man nicht unmengen von Snapshots die quasi alle den gleichen Datenbestand gespeichert haben. Mal angenommen ich mache jede Stunde einen Snapshot für einen Tag, verändere aber nix dran, dann hätte ich 24 Snapshots mit der Größe 0 Byte, in dem Fall würden dann alle bis den aktuellste gelöscht.

Das ist eine gute Idee, danke! Ich hätte das die ersten paar Tausend Snapshots erstmal ignoriert. :-D

Ich mein ZFS stellt halt nur sicher dass die Daten die du abgelegt hast irgendwann genau bit für bit auch genau so wieder gelesen werden. Wenn Windows von außen Mist baut und was überschreibt kann ZFS dafür ja nix.

Richtig, da muss ich selber mit der richtigen Strategie ran.

Das Problem ist ja auch zu erkennen ob das überschreiben jetzt gewollt oder nicht gewollt ist.

Mein Ansatz wäre da gewesen, dass ich ins ARCHIV nur die Dateien nehme, die seit >30 Tagen nicht mehr geändert wurden (und nicht manuell ausgeschlossen wurden, sei es per Pfad oder Extension). Das eine oder andere wird wohl doch nochmal geändert, das ist dann halt Pech. Und ansonsten ist es nur die Silent Data Corruption, die was ändert, die sollte aber hoffentlich auch nur selten zuschlagen. Rsync mit dem in-place sollte nur die geänderten Blöcke überschreiben.

Zusätzliche Tools kannst du ja auch noch einsetzen wenn die dir einen Mehrwert bringen.

Meinst du was Bestimmtes, was ich mir anschauen sollte?

Ja copies macht imo nur Sinn wenn man nur eine Platte hat, zB in Laptops, als NAS oder Server ist die Option eher uninteresant weil ein Mirror oder sonstiges mehr Sinn macht.

RAIDZ?

 

[Katharsas]

Schon alleine die ganzen PST-Dateien brauchen irre viel Platz. Und ich mache regelmäßig Backups z.B. vom Smartphone, die brauchen viele Gigabytes an Daten! Die möchte ich mitsichern, aber definitiv nicht für immer.

Das Problem das ich mit deinem Ansatz habe ist dein "was sich 14 Tage lang nicht ändert kommt ins unendliche Archiv" Algorithmus. Der wirft einige Fragen auf:
- Was passiert wenn du mal 14 Tage im Urlaub bist und sich deswegen nichts ändert? Wirft der Algorithmus dann alle deine Daten ins unendliche Archiv?
- Was passiert wenn sich Daten wieder ändern, also eigentlich nicht ins Archiv rein sollten, aber schon drin sind weil sie sich mal ne weile nicht geändert haben?
- Woher genau weißt du denn welche Daten zu welchen Zeitpunkten ins Archiv übernommen wurden? Du musst ja irgendwie wissen ob sie drin sind, und du kannst ja nicht jedes inkrementelle Update im Archiv per Hand überprüfen.

Solange du alle diese Punkte nicht gelöst hast, ist das nicht wirklich sinnvoll. Und selbst wenn du das regelst, wird es eine sehr komplexe Angelegenheit.

Alternative:
Man kann ja im Prinzip die Auflösung/Granularität der Datenveränderung verändern. Aber ok, das wird dann auch komplizierter und kann vlt. nicht jede Software.
Zum Beispiel wirst du ja für 10 Jahre alte Daten nicht die täglichen Veränderungen brauchen, sondern vlt. nur die monatlichen oder sogar den jährlichen Stand. Man könnte also auch drüber nachdenken, nur ein Backup zu haben, dass nach einer gewissen Zeit die Granularität reduziert.

Beispiel:
Nehmen wir mal an du änderst jeden Tag 1 GB an Daten. Wenn du jetzt jeden Tag inkrementelle machst, kommst du auf 30 pro Monat. Aber wenn du nur jeden Monat inkrementelle machst, ist das weniger (weil erstellte und wieder gelöschte DInge rausfallen), nehmen wir mal an 25GB pro Monat, und pro Jahr noch weniger, sagen wir mal 20*12 = 240 GB pro Jahr.
Backup-Schema:
2 Jahre lang die Änderungen von jedem Tag speichern, für die nachfolgenden 4 Jahre nur jeden Monat und für weitere 9 Jahre nur jährlich, dann kommst du auf 2*365 + 4*12*25 + 9*240 GB = 4 TB an benötigten Speicherplatz, um ALLE deine Dateien für 15 Jahre zu speichern (dazu kommt natürlich noch der Anfangsbestand deiner Daten).