Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › ZFS ausprobiert: Ein Dateisystem…

Snapshot vs. Backup

Anzeige
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Snapshot vs. Backup

    Autor: Luckysh0t 11.10.17 - 14:26

    Man sollte dringend ergänzen dass ein Snapshot kein Backup (nach "allgemein definierter Form ist") ist.ZFS verhindert zwar das Datasets gelöscht werden können, sofern diese einen Snapshot haben,aber genau das zeigt ja schon wo es hapert - einem Backup ist es egal wenn ich die zugrundeliegenden Daten lösche, einem Snapshot nicht.

  2. Re: Snapshot vs. Backup

    Autor: Stormking 11.10.17 - 15:23

    Luckysh0t schrieb:
    --------------------------------------------------------------------------------
    > ZFS verhindert zwar das Datasets gelöscht werden
    > können, sofern diese einen Snapshot haben,aber genau das zeigt ja schon wo
    > es hapert - einem Backup ist es egal wenn ich die zugrundeliegenden Daten
    > lösche, einem Snapshot nicht.

    Sorry, verstehe ich nicht. Sinn eines Snapshots ist doch, daß der aktuelle Zustand des Dateisystems eingefroren wird und alle weiteren Änderungen in einen neuen Baum Binärbaum wandern. Daß man dann auch das Dataset nicht mehr einfach so löschen kann, ist doch nur ein Nebeneffekt.

    Klar sollte man zusätzlich auch noch Backups haben, falls mal das ganze System abraucht. Aber für einen typischen Anwendungsfall eines Backups – man will eine Datei wiederhaben, die man irgendwann aus Versehen gelöscht, überschrieben oder sonstwie geändert hat – sind Snapshots ideal.

  3. Re: Snapshot vs. Backup

    Autor: pumok 11.10.17 - 15:35

    Stormking schrieb:
    --------------------------------------------------------------------------------
    > Aber für einen typischen Anwendungsfall eines Backups
    > - man will eine Datei wiederhaben, die man irgendwann aus Versehen
    > gelöscht, überschrieben oder sonstwie geändert hat - sind Snapshots
    > ideal.
    Korrekt. Und wenn man die Snapshots noch auf ein anderes Gerät kopiert, ist man sogar noch vor Hardwareausfällen und versehentlichem Dataset-Löschen geschützt.

  4. Re: Snapshot vs. Backup

    Autor: LiPo 11.10.17 - 16:56

    Stormking schrieb:
    > Klar sollte man zusätzlich auch noch Backups haben,

    nicht zusätzlich, snapshots und backups sind nicht vergleichbar.
    wir benutzen snapshots *um* backups zu machen: datenbanken herunter fahren (dauert ein paar minuten), snapshot machen (1 sec), datenbanken hochfahren (paar minuten), snapshot auf band sichern (paar stunden), snapshot zerstören (um COW performance-einbruch zu beenden), bänder zu externem dienstleiter schicken.

  5. Re: Snapshot vs. Backup

    Autor: nicoledos 11.10.17 - 17:10

    Die Daten auf der Platte können sich in einem beliebigen inkonsistenten Zustand befinden. Eine Anwendung greift gerade auf die Daten zu oder Änderungen liegen erst im Arbeitsspeicher vor und wurden noch nicht auf die Festplatte geschrieben. Deshalb kann ein Snapshot sehr nützlich sein, ersetzt jedoch keine richtigen Backups.

  6. Re: Snapshot vs. Backup

    Autor: kayozz 11.10.17 - 17:28

    Stormking schrieb:
    --------------------------------------------------------------------------------
    > Sorry, verstehe ich nicht. Sinn eines Snapshots ist doch, daß der aktuelle
    > Zustand des Dateisystems eingefroren wird und alle weiteren Änderungen in
    > einen neuen Baum Binärbaum wandern. Daß man dann auch das Dataset nicht
    > mehr einfach so löschen kann, ist doch nur ein Nebeneffekt.

    Bleibt die Gefahr der Kryptotrojaner, die würden die Daten verschlüsseln und die Snapshots löschen.

    Wer sich also denkt: Was soll schon passieren? Ich habe ein RaidZ3 und Snapshots steht mitunter ohne Daten da.

  7. Re: Snapshot vs. Backup

    Autor: wittiko 11.10.17 - 17:43

    Ich sehe die Definition von Backups etwas anders.

    Als Backup verstehe eine Sicherung gegen versehentliches menschliches Versagen oder mutwillige Zerstörung. Weiters natürlich auch die ganzen Cryptotrojaner.
    Das ist auch nur sinnvoll mit Snapshots realisierbar. Hier müssen die Server bzw die Daten schnell wieder verfügbar sein. Es kommen somit nur Snapshots in Frage.

    Alles andere fallt für mich unter Disaster Recovery.
    Damit meine ich die Speicherung der Daten auf einem anderen Standort der ausreichend entfernt ist. Dies sollten mindestens 5km sein.
    Hier soll der Schutz gegen einen Hardwareschaden oder Naturgewalten oder auch Anschläge gegeben sein.
    Meistens nimmt man langsame Datengräber dafür.
    Ein Restore dauert erheblich länger.

    Bezüglich Cryptotrojaner:
    Snapshots haben readonly zu sein sonst machen diese keinen Sinn. Wir arbeiten mit NetApp FAS Controllern die WAFL verwenden das einige Gemeinsamkeiten mit ZFS hat.
    Snapshots sind außer auf der CLI oder dem Webinterface des Clusters nicht löschbar.
    Wenn sich ein System anders verhält würde ich mich fragen ob ich soetwas überhaupt für Snapshots einsetze.

  8. Re: Snapshot vs. Backup

    Autor: jonbae 11.10.17 - 17:54

    kayozz schrieb:
    > Bleibt die Gefahr der Kryptotrojaner, die würden die Daten verschlüsseln
    > und die Snapshots löschen.
    >
    > Wer sich also denkt: Was soll schon passieren? Ich habe ein RaidZ3 und
    > Snapshots steht mitunter ohne Daten da.

    Der Kryptotrojaner macht da gar nichts. Standardmäßig sind die snapshots erst gar nicht sichtbar. Selbst wenn sie sichtbar gemacht werden, sind sie, wie mein Vorredner schon sagte, read only. Der Trojaner müsste schon speziell für zfs geschrieben worden sein und Root Rechte haben um Schaden anrichten zu können.

  9. Re: Snapshot vs. Backup

    Autor: FalschesEnde 11.10.17 - 18:11

    Luckysh0t schrieb:
    --------------------------------------------------------------------------------
    > Man sollte dringend ergänzen dass ein Snapshot kein Backup (nach "allgemein
    > definierter Form ist") ist.ZFS verhindert zwar das Datasets gelöscht werden
    > können, sofern diese einen Snapshot haben,aber genau das zeigt ja schon wo
    > es hapert - einem Backup ist es egal wenn ich die zugrundeliegenden Daten
    > lösche, einem Snapshot nicht.

    Dem stimme ich zu. Ein Snapshot ist kein Backup, und umgekehrt. Leider hat irgendjemand dieses Märchen in die weite Welt getragen.

  10. Re: Snapshot vs. Backup

    Autor: wittiko 11.10.17 - 18:23

    FalschesEnde schrieb:
    --------------------------------------------------------------------------------
    > Luckysh0t schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Man sollte dringend ergänzen dass ein Snapshot kein Backup (nach
    > "allgemein
    > > definierter Form ist") ist.ZFS verhindert zwar das Datasets gelöscht
    > werden
    > > können, sofern diese einen Snapshot haben,aber genau das zeigt ja schon
    > wo
    > > es hapert - einem Backup ist es egal wenn ich die zugrundeliegenden
    > Daten
    > > lösche, einem Snapshot nicht.
    >
    > Dem stimme ich zu. Ein Snapshot ist kein Backup, und umgekehrt. Leider hat
    > irgendjemand dieses Märchen in die weite Welt getragen.

    Was verstehst du unter einem Backup und wofür willst du es verwenden?

    Nur mal so eine Frage an die Backupverfechter die ja die Dateien offensichtlich kopieren:
    Wie oft testet ihr ob die Backups auch restorebar und funktionell sind?

  11. Re: Snapshot vs. Backup

    Autor: Luckysh0t 11.10.17 - 18:39

    wittiko schrieb:
    --------------------------------------------------------------------------------
    > FalschesEnde schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Luckysh0t schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Man sollte dringend ergänzen dass ein Snapshot kein Backup (nach
    > > "allgemein
    > > > definierter Form ist") ist.ZFS verhindert zwar das Datasets gelöscht
    > > werden
    > > > können, sofern diese einen Snapshot haben,aber genau das zeigt ja
    > schon
    > > wo
    > > > es hapert - einem Backup ist es egal wenn ich die zugrundeliegenden
    > > Daten
    > > > lösche, einem Snapshot nicht.
    > >
    > > Dem stimme ich zu. Ein Snapshot ist kein Backup, und umgekehrt. Leider
    > hat
    > > irgendjemand dieses Märchen in die weite Welt getragen.
    >
    > Was verstehst du unter einem Backup und wofür willst du es verwenden?
    >
    > Nur mal so eine Frage an die Backupverfechter die ja die Dateien
    > offensichtlich kopieren:
    > Wie oft testet ihr ob die Backups auch restorebar und funktionell sind?


    Ein Backup ist eine komplette Kopie einer Datei und nicht die Speicherung des Zustandes einer Datei in einer eigenen Datei (Snapshot).Kommt ähnlich daher hat aber eben andere Spielregeln, als würde man Granny Smith und Pink Lady darauf reduzieren dass es Äpfel sind und die jeweiligen Unterschiede vernachlässigt.

    Mein OS ist aktuell ohne Backup, meine (wichtigen) Daten befinden sich auf mehreren HDDs und verschlüsselt bei einem Cloudanbieter.Nach der Erstellung werden diese Daten wird ein Checksummen vergleich gemacht und stichprobernartig von mir die Daten auch geöffnet (wichtige Daten).Da die Daten recht unveränderlich sind werden die nicht regelmäßig gesichert und auch nur "sporadisch" auf konsitenz geprüft.

    Allerdings wird meine Storageinfrastruktur nächstes Jahr ein Wechsel erfahren, sodass manches anders abläuft als es aktuell der Fall ist.

    Das nur um deine Frage zu beantworten. Mein Post soll nicht jemanden "verurteilen" wer wann wie oft kein Backup macht etc.(Das bleibt jedem selbst überlassen), sondern nur klarstellen das es zwischen Snapshots und einem Backup tatsächliche Unterschiede gibt.Sowas sollte man in so einem Artikel schon richtig differenzieren.

    Bei dem ZIL hat er Autor ja auch gemerkt, das dieses zu komplex werden kann und auch entsprechend ausgespart.

  12. Re: Snapshot vs. Backup

    Autor: ldlx 11.10.17 - 18:54

    wittiko schrieb:
    --------------------------------------------------------------------------------
    > Ich sehe die Definition von Backups etwas anders.
    >
    > Als Backup verstehe eine Sicherung gegen versehentliches menschliches
    > Versagen oder mutwillige Zerstörung. Weiters natürlich auch die ganzen
    > Cryptotrojaner.
    > Das ist auch nur sinnvoll mit Snapshots realisierbar. Hier müssen die
    > Server bzw die Daten schnell wieder verfügbar sein. Es kommen somit nur
    > Snapshots in Frage.
    >
    > Alles andere fallt für mich unter Disaster Recovery.
    > Damit meine ich die Speicherung der Daten auf einem anderen Standort der
    > ausreichend entfernt ist. Dies sollten mindestens 5km sein.
    > Hier soll der Schutz gegen einen Hardwareschaden oder Naturgewalten oder
    > auch Anschläge gegeben sein.
    > Meistens nimmt man langsame Datengräber dafür.
    > Ein Restore dauert erheblich länger.
    >
    > Bezüglich Cryptotrojaner:
    > Snapshots haben readonly zu sein sonst machen diese keinen Sinn. Wir
    > arbeiten mit NetApp FAS Controllern die WAFL verwenden das einige
    > Gemeinsamkeiten mit ZFS hat.
    > Snapshots sind außer auf der CLI oder dem Webinterface des Clusters nicht
    > löschbar.
    > Wenn sich ein System anders verhält würde ich mich fragen ob ich soetwas
    > überhaupt für Snapshots einsetze.

    Jedes vernünftige Backup erstellt zunächst einen Snapshot (unter Windows mit VSS, je nach Anwendungsfall über mehrere Partitionen hinweg), sichert dann den Zustand vor dem Snapshot und führt anschließend ein "Roll-Forward" aus, also das Schreiben der in der Zwischenzeit angefallenen Daten.

    Wenn du dich nun Tag für Tag von Snapshot zu Snapshot hangelst und dann mal ausgehend von einem alten Stand (du nennst es Disaster Recovery, ich nenne es Backup ;-)) einspielen musst, dauert der "Roll-Forward" deiner ganzen Snapshots je nach Menge ne ganze Weile, da ja auch die Änderungen der Änderungen erst wieder blockbasiert eingespielt werden müssen.
    Sinnvoller wäre dann vielleicht ein inkrementelles oder auch differentielles Backup (welches zur Erstellung natürlich auch Snapshots nutzt), aber bei der Wiederherstellung auf einer höheren Ebene als blockbasiert wiederhergestellt wird, also z. B. einzelne Dateien als Ganzes (auch aus einem inkrementellen Backup!) wiederherstellen kann, auch auf einem anderen Computersystem, auch ohne Wiederherstellung des kompletten Datenträgers, weil vielleicht das Originalsystem nicht mehr zur Verfügung steht.

  13. Re: Snapshot vs. Backup

    Autor: wittiko 11.10.17 - 22:39

    Ich würde einfach aus dem Snapshot einen Flexclone erzeugen und fertig.

    Wie gesagt wir arbeiten bei uns als auch bei unseren Kunden eigentlich nur mit NetApp Systemen.

    Soviel ich sehe kann ZFS auch Clone erzeugen. Ein Restore von Snapshots ist eigentlich selten notwendig wobei dies zumindest bei NetApp auch nur Sekunden dauert. Dafür bin ich aber auf 250 Snapshots limitiert.

    Wenn man mal Anforderungen an stündliche Backups hat wird man nur mehr Snapshots ziehen können. Diese kann man natürlich auf eine DR Site kopieren aber das auf Tape oder sonst was zu speichern ist einfach unmöglich wenn es um größere Datenmengen geht.

  14. Re: Snapshot vs. Backup

    Autor: ldlx 11.10.17 - 22:55

    Wie wird das gegen Verschlüsselungstrojaner, Brand und Co. geschützt? Was/In welchen Intervallen haltet ihr noch Backups im eigentlichen Sinne vor, welche ohne das Quellsystem wiederherstellbar sind? Kurz: Wenn mal die Hütte brennt, ist der Kunde überhaupt noch zu retten?

  15. Re: Snapshot vs. Backup

    Autor: simcrack 11.10.17 - 23:58

    Um das nochmals klarzustellen, mit Snapshots kann man sehr wohl Backups machen, auch das Desaster Recovery ist mit ZFS realisierbar. Ich finde das sogar eine sehr gute Vorgehensweise.

    Der Autor hat es erwähnt, mittels ZFS send/recieve kann man seinen pool jederzeit an einen Backup-Server senden (resp sendet man idR einen inkrementellen Snapshot). Das schöne an ZFS ist ja auch, dass man alle paar Minuten einen Snapshot machen kann, ohne Performanceverluste zu haben.

    Falls ein Backupserver nicht reicht, kann man die Datasets auf dem Backupserver (welcher sich hoffentlich an einem anderen Standort befindet) auch noch auf ein beliebiges Medium speichern.

  16. Re: Snapshot vs. Backup

    Autor: wittiko 12.10.17 - 00:03

    Entweder wir setzen MetroCluster ein das heißt alle Daten werden synchron auf 2 Standorte geschrieben oder eben wir übertragen die Daten auf einen Backupstandort mit Snapmirror.

    Mit einem MetroCluster können wir auch einfach im Betrieb zwischen 2 DCs umschalten. Es gibt eben nur einen kurzen IO Freeze.

    Bezüglich Backuprentations hängt das immer von den Kunden ab was benötigt wird aber bis zu einem Jahr ist mit Snapshots kein Problem. Wobei natürlich dann die Dichte abnimmt. Wir kombinieren da hourly, nightly und weekly snapshots.

    Also zb 100 Hourly Snapshots, 14 Nightly, und 52 Weekly das ergibt 166 Snapshots.
    Natürlich kosten die Snapshots auch Platz das ist auch klar aber besser ausreichend Snapshots als fehlende Daten.

    Das ist alles mit einem MetroCluster und auch über eine Nearstore auf einem Backupstandort gesichert.

    Somit habe ich bei einem Verschlüsselungstrojaner maximal 1h Datenverlust.
    Es gibt bei NetApp aber auch über eine Schnittstelle die Möglichkeit eine Software zu verwenden, die solche Verschlüsselungsvorgänge erkennt und unterbindet.

  17. Re: Snapshot vs. Backup

    Autor: ldlx 12.10.17 - 00:48

    1000 Buzzwords. Was machst du im DR-Fall, wenn du von der grünen Wiese aus die komplette Umgebung wiederherstellen musst? Dann ist das DR-Medium bei Acronis oder die Windows Server-Installations-DVD mit Wiederherstellungssoftware dein bester Freund - oder wie stellt sich das mit eurer Appliance dar? Wieviel Zeit vergeht vom Worst-Case bis zur lauffähigen Umgebung?

  18. Re: Snapshot vs. Backup

    Autor: wittiko 12.10.17 - 10:14

    Bei MetroCluster muss ich einfach nur auf den anderen Standort umschalten. Dauer max. 180 Sekunden.

    Im Falle mit nur einer Backupmaschine und der Annahme von NL-SAS Platten muss ich die die Resourcen erst aktivieren das dauert etwa 10min.

    Bei einem MetroCluster liegt ja der Vorteil im synchronen Speichern der Daten. Dadurch kommen diese "grüne Wiese Szenarios" nicht vor. Wie ich oben schon geschrieben habe setzt dies natürlich eine geografische Distanz von mehreren Kilometern voraus.

    Ein Umschalten ist nur durch einen kurzen IO Freeze zu bemerken. Alle Systeme laufen weiter. Falls ein DC komplett abraucht müssen eben die VMs neu gestartet werden. Dies würde natürlich ein paar Minuten dauern aber da reden wir nicht von Stunden oder Tage.

    Ein MetroCluster ist schon etwas teurer da man FC Switches und FC/SAS Bridges braucht. Bei einem MetroCluster ist wirklich jede Komponente redundant ausgeführt.

  19. Re: Snapshot vs. Backup

    Autor: ldlx 12.10.17 - 18:21

    Was passiert, wenn du einen Fehler bemerkst, der sich vor Tagen oder Wochen eingeschlichen hat? Kannst du dann auch selektiv zurückrollen oder immer nur alles?

    Ansonsten: das klingt zu schön um wahr zu sein, was kostet sowas in der Anschaffung? Sprich: ab welchem Budget/Unternehmensgröße kommt das überhaupt in Betracht?

  20. Re: Snapshot vs. Backup

    Autor: wittiko 12.10.17 - 19:05

    Bei NFS und CIFS kann man die Dateien einfach herauskopieren. Bei NFS sieht man ein .snapshot Verzeichnis bei CIFS ist es ~snapshot bzw unter Windows einfach vorherige Versionen.

    Bei Block also iSCSI oder FC würde man einfach einen Clone aus dem Snapshot erstellen und Mounten.

    Es kommt immer drauf an wieviele IOPs man machen will und wie viel Kapazität man braucht.

    Bei einem Cluster mit 2 Controllern mit etwa 10TB wären das inkl. aller Lizenzen sind das etwa 15-20k¤. Allerdings wäre das alles auf SSDs.

    Ein Metrocluster kostet weil hier größere Controller benötigt werden und noch dazu 4 FC Switches und 4 Bridges schon mal 100k oder noch mehr.

    Wir haben durchaus Kunden mit 20 oder 30 Mitarbeiter die auch schon NetApp Systeme haben. Das IT Budget hat nicht immer was mit der Mitarbeiteranzahl zu tun. Meist geht es hier um die Datensicherheit.

    Falls Interesse besteht kann ich das gerne mal auch in einer Teamviewer Session zeigen wie das funktioniert.

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. CPP Creating Profitable Partnerships GmbH, Hamburg
  2. Bosch Sicherheitssysteme GmbH, Grasbrunn bei München
  3. PROMETEC GmbH, Aachen
  4. Robert Bosch GmbH, Stuttgart-Vaihingen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. bei Caseking


Haben wir etwas übersehen?

E-Mail an news@golem.de


APFS in High Sierra 10.13 im Test: Apple hat die MacOS-Dateisystem-Werkzeuge vergessen
APFS in High Sierra 10.13 im Test
Apple hat die MacOS-Dateisystem-Werkzeuge vergessen
  1. MacOS 10.13 Apple gibt High Sierra frei
  2. MacOS 10.13 High Sierra Wer eine SSD hat, muss auf APFS umstellen

Elex im Test: Schroffe Schale und postapokalyptischer Kern
Elex im Test
Schroffe Schale und postapokalyptischer Kern

Indiegames-Rundschau: Fantastische Fantasy und das Echo der Doppelgänger
Indiegames-Rundschau
Fantastische Fantasy und das Echo der Doppelgänger
  1. Verlag IGN übernimmt Indiegames-Anbieter Humble Bundle
  2. Indiegames-Rundschau Cyberpunk, Knetmännchen und Kampfsportkünstler
  3. Indiegames-Rundschau Fantasysport, Burgbelagerungen und ein amorpher Blob

  1. TK-Marktstudie: Telekom kann ihre Glasfaseranschlüsse nur schwer verkaufen
    TK-Marktstudie
    Telekom kann ihre Glasfaseranschlüsse nur schwer verkaufen

    Während Telekom-Konkurrenten 33,1 Prozent ihrer Glasfaseranschlüsse auch wirklich verkaufen können, sieht das beim Festnetzmarktführer nicht so gut aus. Doch die Studie beruht auf Recherchen, nicht auf Angaben der Telekom.

  2. Messenger: Whatsapp lässt Aufenthaltsort über längere Zeiträume teilen
    Messenger
    Whatsapp lässt Aufenthaltsort über längere Zeiträume teilen

    Wer ist wo auf dem Musikfestival oder beim Shoppen? Das können Nutzer von Whatsapp nun kontinuierlich live verfolgen. Der Hersteller sagt, dass der Datenschutz dabei gewährleistet sei.

  3. ZBook x2: HPs mobile Workstation macht Wacom und Surface Konkurrenz
    ZBook x2
    HPs mobile Workstation macht Wacom und Surface Konkurrenz

    HPs neues ZBook x2 ist mit Quadro-Grafikkarte und Vierkernprozessor für Grafiker konzipiert. Die Makrotasten und der passive Eingabestift erinnern an Wacom, der Klappständer und die Anstecktastatur an Microsofts Surface Pro.


  1. 11:21

  2. 11:09

  3. 11:01

  4. 10:48

  5. 10:46

  6. 10:20

  7. 09:01

  8. 08:36