*New 12.1 series Release:
2019-11-08: XigmaNAS 12.1.0.4.7091 - released!

*New 11.3 series Release:
2019-10-19: XigmaNAS 11.3.0.4.7014 - released


We really need "Your" help on XigmaNAS https://translations.launchpad.net/xigmanas translations. Please help today!

Producing and hosting XigmaNAS costs money. Please consider donating for our project so that we can continue to offer you the best.
We need your support! eg: PAYPAL

Snapshots und RSYNC...oder wiedermal Backups

German community

Moderators: b0ssman, apollo567, crowi, Princo

Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Snapshots und RSYNC...oder wiedermal Backups

#1

Post by NasBar » 26 Oct 2018 12:57

Hallo Zusammen,

nun sitzt ich schon eine ganze Weile mit zwei hübschen XigmaNAS Systemen rum und bin irgendwie noch nicht so ganz zufrieden mit dem Ergebnis.

Aber erstmal die Fakten: zwei XigmaNAS, nahezu identisch in den Merkmalen. In dem einen ist ein Pool in dem sich drei LUN's und noch normale Freigaben tummeln. Die LUN's werden per iSCSI von einem VM-Host genutzt um das heimische Netzwerk mit Fileserver, Mail und Cloud zu versorgen. Nun möchte ich die LUN's und die Shares eben zum zweiten NAS sichern...die Backup's, da ist es wieder.
Hatte zuerst auch die Idee das die in den LUN's liegenden Systeme sich selber auf das andere NAS per rsync sichern könnten...aber das ist der schlechte zweite Plan.
Alles ist per ZFS aufgesetzt. Mit send/recv habe ich Snapshots schon mal kopiert bekommen, aber das dauert ganz schön lange (4TB LUN braucht eben etwas Zeit) .... wenn auch nur von der Kommandozeile, also nicht automatisiert.
Das aktiv genutzte NAS erzeugt Snapshots, mit Datumsliteral in einem Verzeichnis welches sich das passive dann per rsync holen soll ODER den Snapshot irgendwie anders von A nach B bekommen. Das mit dem "Klonen" ist mit über die GUI noch nicht gelungen weil er bei Angabe von Pfad das "\" oder "/" anmeckert...blöd, weil wie bekomme ich den Pfad da eingestellt? Per rsync habe ich zumindest was vom Aktiven "gesynct" bekommen aber hier ist das Problem da komme ich nicht auf das .zfs Verzeichnis.

Ich möchte ja eigentlich nur von dem aktuellen System, eine Vollbackup, super wäre natürlich auch noch ein Differentielles...aber mit dem Snapshot sollte dies eigentlich ja geboten sein.
Ich bin mir sicher, das das System das sicher beherrscht nur ich finde nicht die Tür....womöglich trägt das System aber auch andere Möglichkeiten die ich einfach nicht sehe...über Anregungen und Ideen würde ich mich sehr freuen.

Lander
Starter
Starter
Posts: 71
Joined: 26 Feb 2015 16:15
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#2

Post by Lander » 31 Oct 2018 12:57

Hast du dir mal die Anleitung angeschaut ab dem Punkt send/recv ? https://wiki.ubuntuusers.de/ZFS_on_Linux/

In dem Verzeichnis .zfs die die Snapshots beinhalten, kannst du nicht schreiben weil das ein Readonly Filesystem ist ... was auch gut so ist. Waere schon bloed wenn man sich die eigenen Snapshots ueberbuegel koennte. Hab immo leider wenig Zeit hier genauer drauf einzugehen.

Ich hoffe der Link traegt ein bisschen zum Verstaendniss bei.

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#3

Post by NasBar » 01 Nov 2018 11:50

Ja danke, den kannte ich schon und natürlich ist das Konzept so schon prima, aber es geht ja nicht um die lokalen Snapshots...sondern diese einfach "spiegeln", als Backup...nicht Snapshot.
Also die Idee soll sowas sein...das produktive System erzeugt automatische Snapshots...soweit so gut. - und nun soll der Datenbestand sagen wir täglich einfach von diesem System auf ein anderes gebracht werden. Also Möglichkeit a.) den Snapshot per send/recv spiegeln auf das andere System. Geht aber aktuell nur über Kommandozeile...nicht aus der GUI heraus. Meine erste Eingebung war den lokalen Snapshot über die Option "Klonen" auf das andere System bringen. Aber das "Klonen" ist mir darüber noch nicht geglückt. Ich habe da einfach eine gedankliche Lücke und finde nicht wie man denn da was "editieren" kann...wenn ich einen Snapshot habe, kann ich den bearbeiten...dort findet man das Klonen...ich bin gedanklich da, das dies quasi die GUI Umsetzung der send/recv Geschichte ist.
Aber ich kann da eben keinen Pfad oder sowas eintragen ohne das er mir sagt das da nicht erlaubte Zeichen enthalten sind. Die Doku ist da was schwach.
Also ich suche einen Weg Daten von einem NAS zu sichern, dies möglichst generisch und auf einen anderen Ort...weil Snapshots lokal sind nett aber stellen kein Backup dar. Also ich will doch im Falle eines Falles Daten restaurieren können ... was mit send/recv geht...daher dieser Weg. Wenn es eine andere Option gibt die ich nicht auf dem Schirm habe...immer her damit.

User avatar
Princo
Forum Moderator
Forum Moderator
Posts: 1081
Joined: 15 Jul 2012 01:21
Location: Berlin, Germany
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#4

Post by Princo » 02 Nov 2018 02:42

Dein Fehler beginnt schon bei "(4TB LUN braucht eben etwas Zeit)".

Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#5

Post by NasBar » 05 Nov 2018 17:24

Na Prima....damit kann ich arbeiten.
Sorry Princo, aber was ist das für ne Antwort?

Dann Frage ich anders, und das ist eigentlich das worum es sich hier dreht:
Wie kriege ich denn wohl Daten aus dem ZFS Verbund raus auf ein anderes Speicher-Medium?
Was bringt mir die ganze Snapshot Geschichte wenn diese auf dem gleichen physikalischen Gerät liegen?
Ich suche eine Backup Lösung und nichts weiter...wenn ich mit dem Ansatz die LUN per Snapshot zu sichern, wo ich weiß das sich der Datenbestand nicht dramatisch ändert dann war ich, meine ich doch offen für andere Lösungen. Kann darin nicht den Fehler erkennen.
Ist meine Annahme falsch das es effizienter ist die LUN zu sichern, dann kann man das diskutieren....

User avatar
ms49434
Developer
Developer
Posts: 747
Joined: 03 Sep 2015 18:49
Location: Neuenkirchen-Vörden, Germany - GMT+1
Contact:
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#6

Post by ms49434 » 05 Nov 2018 18:38

Die Antwort auf Deine Fragen ist immer ZFS send / receive.

ZFS ist es völlig egal ob du Snapshots von einem filesystem oder von einem volume erstellst. Die Parameter bei zfs send / receive sind aber entscheidend was aus Deinen Daten auf dem Zielrechner wird.

Teil 1 - Volles Backup:
1. Erstelle den ersten Snapshot deines ZFS Volumes (source).
2. Benutze zfs send -R source-pool/source-volume@snapshotname | ssh destination-ip zfs recv -v destination-pool/destination-volume.
Damit wird dein erster Snapshot über ssh an deinen Backup-Server übertragen. Dies ist ein Vollbackup und benötigt halt seine Zeit.

Teil 2 - Inkrementelles Backup:
1. Erstelle einen weiteren Snapshot deines ZFS Volumes
2. Übertrage die Differenz aus dem letzten übertragenen Snapshot und diesem Snapshot an deinen Backup Server (benutze dazu zfs send -i)
3. Über zfs rollback den übertragenden Snapshot auf dem Backup Server wiederherstellen.
Das geht in der Regel etwas schneller, da ja nur die Veränderungen innerhalb des Volumes übertragen werden.

Du solltest zu jeder Zeit wissen welche Snapshots auf welchem Server vorhanden sind und nur die Snapshots löschen die Du wirklich nicht mehr brauchst. Geht was in die Hose fängst Du wieder mit einem vollen Backup an.
Nur zur Info, JEDE ordentliche Backup Software setzt auf Snapshots auf, selbst das Backup von Winzigweich nutzt es, da heißt es halt volume shadow copy.

Nachtrag: Ein bisschen Lektüre über ZFS: https://www.freebsd.org/doc/de/books/ha ... s-zfs.html
1) XigmaNAS 12.0.0.4 amd64-embedded on a Dell T20 running in a VM on ESXi 6.7U2, 22GB out of 32GB ECC RAM, LSI 9300-8i IT mode in passthrough mode. Pool 1: 2x HGST 10TB, mirrored, SLOG: Samsung 850 Pro, L2ARC: Samsung 850 Pro, Pool 2: 1x Samsung 860 EVO 1TB , services: Samba AD, CIFS/SMB, ftp, ctld, rsync, syncthing, zfs snapshots.
2) XigmaNAS 12.0.0.4 amd64-embedded on a Dell T20 running in a VM on ESXi 6.7U2, 8GB out of 32GB ECC RAM, IBM M1215 crossflashed, IT mode, passthrough mode, 2x HGST 10TB , services: rsync.

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#7

Post by NasBar » 05 Nov 2018 19:18

Das kann ich lesen, danke erstmal dafür.

Ich habe dann aber nochmal Fragen...

Annahme System A ist die Quelle, von dem ein Snapshot erstellt wird....welches Initial als Voll Backup auf System B übertragen worden ist
dann werden auf System A weitere Snapshots erstellt....
Fall A.) manuell
Fall B.) automatsiche Snapshots

Jetzt kommt der spannende Punkt.
Fall A, manuell kann es mit der Kommandozeile synchronisiert werden..auch für den Fall B.
...nun ja die Automatsichen Snapshots erhalten generische Namen...bleibt dann nur der Spaß entweder immer einen "festen" Namen zu nehmen den man der Script mit dem System B synchronisiert...dann umbenennt was aber sicherlich nicht so toll ist ...bezüglich Datenintegrität. Also dann doch ein Script welches in dem .ZFS Ordner sein bestes gibt und versucht hier mit der Datums-/Uhrzeitangaben den Snapshot mit System B zu synchronisieren? Sehe ich doch korrekt das die GUI hier nur die automatischen Snapshots erstellt bekommt...der Rest ist dann in Batchdateien zu parken?
Das Klonen in der GUI ist demnach für...? Ich dachte das dies genau das "Vollbackup" umsetzt...aber wie gesagt da kann kriege ich keine Konfiguration rein die dem System gefällt (Verbotene Zeichen im Pfad...aber wie ohne "/")? Ich bin da nur verunsichert was über die GUI geht und was man dann schlussendlich lieber doch zu Fuß macht.

Snapshot's sind gut, da sage ich nichts gegen...ich denke nur das Aufgrund dessen das man eben nicht mehr die Daten "klar" identifiziert bekommt wie bei einem konventionellen Backup auf DAT/DVD/USB oder oder eben ein gewisses Mass an Skepsis durchaus gerechtfertigt ist...was aber nicht dem System sondern der Unwissenheit des Anwenders geschuldet ist.
Und hier kommen dann Foren ins Spiel...freie Software eben.
Und bevor man Datenpools anlegt und drauf vertraut...würde ich es zum Einen gerne verstehen und auch erstmal ausprobieren ;-)

..und Winzigweich....sehr nett, kannte ich noch nicht.

User avatar
Princo
Forum Moderator
Forum Moderator
Posts: 1081
Joined: 15 Jul 2012 01:21
Location: Berlin, Germany
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#8

Post by Princo » 07 Nov 2018 04:09

Hallo NasBar,

entschuldige bitte meinen flapsigen Kommentar. Ich hätte ihn näher erläutern sollen, denn der Einsatz von LUNs bringt gewisse Nachteile mit sich, besonders wenn sie in einer Größenordnung liegen, wie du sie genannt hast (4TB).

"Nachteile" ist dabei aber nicht richtig passend, "weniger Vorteile" trifft es eher. Da es aber mehr eine Design-Frage deiner Systemkonfiguration betrifft, lasse ich das jetzt mal beiseite.

Ich beziehe mich jetzt auf dein letztes Posting.

Es ist richtig, daß es bei XigmaNAS nur sehr rudimentäre GUI-Funktionen gibt, welche sich um die Behandlung von Snapshots kümmern.

Es gibt die Möglichkeit, sich automatisierte Snapshots zu bestimmten Zeitpunkten erstellen zu lassen (und alte Snapshots zu löschen), aber die funktioniert nur dann, wennn das System zu dem Zeitpunkt auch eingeschaltet ist. Fährst du das System z.B. zum Wochenende herunter, dann werden nicht nur keine neuen Snapshots für diesen Zeitraum erstellt, sondern es werden auch keine alten Snapshots gelöscht. Die bleiben dann solange im System, bis du sie manuell löschst.

Es gibt Tools, welche dieses Problem beheben, und welche dir sogar ein automatisiertes Backup deiner Daten auf ein anderes System ermöglichen.

Du findest sie hier: viewtopic.php?f=70&t=2197

Allerdings kann ich wirklich nur jedem davon abraten, durchgehend alle Systeme automatisch zu backuppen. Die letzte Instanz einer Backup-Kette sollte IMMER manuell (nach vorheriger ausführlicher Prüfung) ausgelöst werden.

Auch der Einsatz jeglicher Scripte (wie die von mir verlinkten), will wirklich sehr gut überlegt sein. Solche Scripte funktionieren nur unter bestimmten Bedingungen, und sie sind auch nicht frei von echten Fehlern (ja, auch die von mir verlinkten Skripte haben unangenehme Fehler).

Ich weiß, daß das seltsam klingt, und daß viele Administratoren das Thema Backup als lästig empfinden, und es daher gerne wegautomatisieren, aber ich kann nur ausdrücklich davor warnen. Automatisierte Backups übernehmen sämtliche Fehler des zu sichernden Datenbestandes, und das hat fatale Folgen.

Zum Thema "Klonen":

Hier befindest du dich tatsächlich auf einem gedanklichen Irrweg.
"Klonen" in Verbindung mit ZFS-Snapshots bezeichnet nicht das Übertragen von Daten auf ein anderes System, sondern nur die Bereitstellung der Daten eines Snapshots in beschreibbarer Form. Dafür mußt du einen gültigen Mountpoint angeben, und dafür muß die Notation im Dateisystem von XigmaNAS natürlich korrekt sein.

Beispiel:
Du hast taglich Snapshots von einem LUN erstellt.
Jetzt gibt es ein Problem mit den Daten darauf.
Von dem LUN gibt es mehrere Unterverzeichnisse (Snapshots) unterhalb von .zfs des LUNS.
Diese sind allerdings nur Readonly mountbar.
Deine Applikation verlangt aber zwingend, daß du diesen historischen Datenbestand mountbar zur Verfügung stellst, damit du ihn überhaupt öffnen kannst.
Genau dafür ist "Klonen" da.
Du mußt beim Einsatz festlegen, wohin dieser Datenbestand in XigmaNAS gemountet werden soll (z.B. nach /mnt/wichtigerKlon).
Anschließend mußt du natürlich deine LUN-Konfiguration dahingehend abändern (oder duplizieren), damit dein System mit diesem geklonten Datenbestand arbeitet.
Nach Abschluß der Arbeiten mußt du die Konfiguration natürlich wieder zurück ändern, und natürlich auch den Kloneintrag löschen, falls du wieder mit dem aktuellen Datenbestand arbeiten möchtest.
Es ist eine ganz simple Lösung für ein ziemlich komplexes Problem. Ich hoffe, daß ich es verständlich genug dargestellt habe (nein, das wird nicht so sein, aber evtl. bekommst du eine gewisse Ahnung davon, daß man mit ZFS ziemlich geile Sachen machen kann).

Es gäbe noch einiges mehr zu sagen, aber ich schicke das jetzt einfach mal ab.

Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.

defcon999
Advanced User
Advanced User
Posts: 151
Joined: 07 Dec 2013 10:55
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#9

Post by defcon999 » 07 Nov 2018 08:32

@Princo

Wie immer ein ausführlicher Post, der gut in die Problematik einführt.

Dem aufmerksamen Leser stellen sich aber dennoch Nachfragen.

ZFS gilt ja nun gerade wegen seiner "Robustheit" als äusserst sicher, was Datenverluste angeht. DAS ist ja gerade der entscheidende Punkt dieses System zu nutzen.

Wenn Du etwas von "ausführlicher Prüfung", vor dem manuellen Update, schreibst, so erschliesst sich mir dies nicht so richtig. Sollen die Dateien - Deiner Meinung nach - einzeln "gesichtet" werden?!

Es gibt doch den SCRUB, um den Pool auf Fehler zu testen?! Wenn der Durchlauf keine Fehler meldet (ggf. per Mail), dann kann doch auch ein darauf folgendes automatisiertes Backup keine Fehler produzieren??!!

...oder sehe ich den Wald vor lauter Bäumen wieder nicht?! ;-)

defcon999

Gesendet von meinem SM-T900 mit Tapatalk

NAS: HP MicroServer Gen8 - CPU: Intel Xeon E3-1230 V2 - QuadCore 3,3 GHz ** 16 GB ECC RAM ** 4 x 2 TB WD Red RaidZ1 ** Samsung 840 120 GB SSD RootOnZFS-System ** 1 x 6 TB WD Red RClone lokal via USB 3.0 Inateck USB 3.0 Dualschacht Festplatten-Dockingstation ** Cloning mit 1 x 6 TB WD RED im 2. Schacht der Docking-Station ** 12.0.0.4 - Reticulus (revision 6928)** Embedded-Installation ** OneButtonInstaller: Plex & RClone -- VirtualBox: Ubuntu-Server with Pi-Hole

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#10

Post by NasBar » 08 Nov 2018 19:24

@Princo..., alles gut!
Naja das mit den LUN's ist so ne Sache...aber vielleicht mal kurze Darstellung weil es den einen oder anderen womöglich auch Interessieren könnte.
Ich hatte am Anfang einen Debian Server DC, File/Druck & Mail, ist es ja nur ein Heimnetz...und durch das Upgrade auf Samba4 als AD darf und kann der DC nicht gleichzeitig Druck-; Fileserver sein (hat etwas gebraucht das zu erkennen, danke an einen Buchautor zu dem Thema...das propagieren der Druckertreiber war mein Problem). Aber damit war dann die Überlegung zwei dezidierte Rechner oder was anderes... schlussendlich ist es dann ein VM Host geworden der per LUN's File/Druck, Mail & Co eben einbindet (ökologische Gründe, weil ist ja nur Hausnetz). Einfach "gespiegelte" Platten in die VM, geht aber nicht. Dazu brauchte ich dann ebne iSCSI also ich nutzte das NAS als IP-SAN, was auch einer der Gründe FÜR XigmaNas war.
So ist das halt gewachsen. Bei mir läuft alles 24/7 daher bin ich nicht so Anfällig für die Themen nach Neustart oder dergleichen, das hatte ich schon auf dem Plan. Alles wird auch noch USV gestützt um hässlichen Aussetzern vorzubeugen, auch hier war ich froh über den out-of the box UPS Support der XigmaNAS. Nur wie schon am Anfang gesagt, Snapshot hin und her...Daten müssen nichts desto trotz an mindestens zwei Orten liegen und sich bewegen. Denn immer kann ein Sytem ausfallen, ob konsistent oder inkonsistent!

Die Scriptsammlung dazu hatte ich mir dazu auch schon angeschaut und habe es zumindest nun denke ich soweit auch verstanden...also für meine Belange. Ich lasse mir erstmal die automatischen Snapshots erzeugen (dem Umlauf wegen). Dann mal sehen was so an Datenmenge so ausgewiesen wird...finde ich schwierig da ein Daumenmaß vorher zu bestimmen. Dann werde ich mal sehen ob ich womöglich aus dem virtualisierten Rechner Daten selber raus schiebe (Delta) oder doch das LUN als ganzes nehme (Voll) oder womöglich dann doch wieder per rsync. Nur mal gut das die Kistchen alles drin haben. Ganz andere Methode wäre auch nur die VM direkt zu sichern, aber die braucht dann eben auch echt lange dafür und ist nicht wirklich günstig; Lizenz und nur mit dem HPE Zeugs ist das schon echt mühselig als "freie" Version. Es gibt eben nicht DIE eine Lösung sondern immer nur für sich selber passende..die zu finden ist aber eben nicht immer so leicht.
Ich habe mich extrem schwer getan wie man optimaler weise die Platten zusammenlegt... bei 5 Platten alles zusammen- als ein vg in Z1; Nachteil der Erweiterbarkeit in einem 6-Bay Gehäuse bis man da alle Platten auf "größer" durch hat ist es eine teure und langwierige Angelegenheit. Dann doch lieber 2x3 Platten als zwei vg's in Z1, damit man zumindest immer im Pack von drei Platten erweitern kann...oder doch lieber 3x2 Platten, damit drei vg's aber dann nur als mirror...gibt es hier sowas wie "best practice"?
So...nun sag ich mal Danke und ich freue mich auch über andere Ideen oder Anregungen.

User avatar
Princo
Forum Moderator
Forum Moderator
Posts: 1081
Joined: 15 Jul 2012 01:21
Location: Berlin, Germany
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#11

Post by Princo » 08 Nov 2018 23:33

Hallo NasBar,

dein XigmaNAS läuft selbst aber nicht in einer virtuellen Umgebung, oder?

Zur Erweiterung der Kapazität:

Deinen Ausführungen entnehme ich, daß du von einem schrittweisen Austausch aller einzelnen Platten durch solche mit höherer Kapazität ausgehst.

Das ist z.B. "Bad-Practise". Wenn man ein richtiges Backup hat, dann geht das viel schneller, eleganter und wesentlich sicherer.

Da dein NAS 24/7 läuft, fallen schon ein paar potentielle Probleme weg. Da zudem noch ein zweites, fast identisches NAS vorhanden ist, macht das die Sache noch mal leichter.

Ich kann dir gerne die einzelnen Schritte beschreiben, wie du ein "händisches" Backup hinbekommst. Ich weiß, daß du in der Richtung schon mal etwas gemacht hast (Snapshots übertragen), aber ich weiß nicht, ob sich das auf den gesamten Pool bezog, oder nur auf einzelne Volumes oder Datasets. Ich weiß noch nicht einmal, ob du überhaupt Datasets angelegt hast.

All das würden wir aber herausfinden, wenn wir einfach mal ein komplettes "händisches" Backup durchführen (initiales Vollbackup und danach inkrementelle Backups). Das ist meiner Meinung nach der einfachste Weg, um herauszufinden, ob diese Backup-Methode für dich tatsächlich brauchbar ist.

"händisch" bedeutet nicht, daß man es nicht auch automatisieren könnte, aber so bekommst du den besten Eindruck darüber, wie das Ganze überhaupt funktioniert, und was man dabei alles beachten muß.

Sag einfach bescheid, ob du das möchtest.

Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.

User avatar
Princo
Forum Moderator
Forum Moderator
Posts: 1081
Joined: 15 Jul 2012 01:21
Location: Berlin, Germany
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#12

Post by Princo » 09 Nov 2018 01:25

Hallo defcon999,
defcon999 wrote:
07 Nov 2018 08:32
Wenn Du etwas von "ausführlicher Prüfung", vor dem manuellen Update, schreibst, so erschliesst sich mir dies nicht so richtig. Sollen die Dateien - Deiner Meinung nach - einzeln "gesichtet" werden?!

Es gibt doch den SCRUB, um den Pool auf Fehler zu testen?! Wenn der Durchlauf keine Fehler meldet (ggf. per Mail), dann kann doch auch ein darauf folgendes automatisiertes Backup keine Fehler produzieren??!!
Der SCRUB dient dazu, einfach mal ALLE Dateien darauf zu überprüfen, ob Teile davon auf Plattenbereichen liegen, welche vom "Bit-Rot" betroffen sind, und korrigiert das dann. Ansonsten wird diese Überprüfung sowieso bei JEDEM Zugriff auf eine Datei im ZFS-Dateisystem durchgeführt.

Da bei einem (inkrementellen) Backup nur die neuen Dateien bewegt werden, erfolgt dabei logischerweise auch immer diese Überprüfung.

Ein SCRUB hat daher keine Auswirkung auf einen (späteren) Backup-Vorgang (es sei denn, er erfolgt während des Backups, dann kann er das Backup u.U. etwas ausbremsen).

Nein, das ist auch nicht das, was ich meinte.

Mit der ausführlichen Prüfung der Daten vor dem Backup meinte ich etwas ganz anderes. Es geht darum, ob die Menge der zu übertragenden Daten überhaupt plausibel ist..

Beispiel:
Ich verwende mein NAS hauptsächlich zur Aufbewahrung meiner selbst geschossenen Fotos. Wenn ich von einem Shooting komme, dann ist meine erste Aktion, die Bilder auf das NAS zu überspielen. Da das meistens am Wochenende stattfindet, mache ich bei der Gelegenheit auch gleich ein Backup meines NAS.

Dazu mache ich einen rekursiven Snapshot meines Pools, und bevor ich die Daten tatsächlich backuppe, schaue ich mir die Ausgabe des Befehls (Beispiel)

Code: Select all

zfs send -vnRi Daten@2018-11-01 Daten@2018-11-08
an. Dabei geht es um die Parameter "-vnRi".

"-vn" bedeutet, daß ich eine ausführliche Ausgabe der zu übertragenden Datenmenge für jedes Dataset bekomme, ohne daß der Vorgang tatsächlich ausgeführt wird.

Wenn ich dabei sehe, daß im Dataset "Bilder" z.B. 20.5 GB an Daten übertragen werden sollen, und bei allen anderen Datasets jeweils nur wenige kB, dann wäre das in meinem Fall ein plausibler Wert, weil ich vorher ca. 20 GB an Bildateien auf das System übertragen habe, und ich würde die echte Übertragung starten.

Würde die Ausgabe aber eine viel höheren Wert ergeben (z.B. 800 GB), dann wäre das nicht mehr plausibel, und ich würde nachforschen, wie das zustande kommt.

Das könnte z.B. ein Hinweis darauf sein, daß man sich einen Verschlüsselungstrojaner eingefangen hat, um nur mal eine der aktuell gängigen Bedrohungen zu erwähnen.

Des weiteren kann man nach der Übertragung prüfen, ob auf der Quell-NAS und den Ziel-NAS (oder dem Backup-Pool) die gleiche Anzahl von Datasets/Volumes/Snapshots vorhanden ist..

Diese Überprüfungen nehmen kaum Zeit in Anspruch, aber man hat einfach eine bessere Gewissheit darüber, daß das Backup auch tatsächlich so funktioniert, wie man es geplant hat.

Das Backup ist quasi die letzte Bastion, um sich gegen schädlich Einflüsse von außen, und auch vor der eigenen Dämlichkeit zu schützen.

Das funktioniert hier natürlich nur bis zu einer gewissen Grenze. Wenn man z.B. auf den Quell-NAS ein Dataset löschst, dann ist es nach dem nächsten Abgleich-Vorgang auch auf den Backup weg (inkl. der vorherigen Backups). Ich würde ein überflüssiges Dataset daher einfach noch eine Weile leer weiter laufen lassen, bevor ich es tatsächlich lösche (dann schleicht es sich langsam auf dem Backup raus), aber das ist natürlich eine Frage des persönliches Stils.

Zusammengefasst: es schadet nicht, die eigenen Aktionen immer zu hinterfragen. Gerade beim Thema Backup ist es wichtig, die einzelnen Schritte zu verstehen. Es ist riskant sich dabei auf Skripte zu verlassen, deren Funktionsweise man nicht versteht.

Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#13

Post by NasBar » 10 Nov 2018 13:42

Hallo,

ja richtig mein NAS ist nicht virtuell und läßt sich anfassen ;-).
Bei allem was die Virtualisierung mit sich bringt, auch die Vorteile hat aber eben auch einige Nachteile und ich selber halte nicht viel davon alles sinnlos & wild zu virtualisieren. Ein Speichersystem ist für mich wie eine Firewall die auch nichts in einer virtuellen Welt zu suchen hat.
Der "Ausbau" war eher für die Zukunftsaussichten gedacht...und als Einsprung zum jetzigen Zeitpunkt..wie Du schon richtig erkannt hast...habe nur für mich halt gerechnet denn jetzt ein VG mit 5 Platten und wenn es später "eng" wird diese zu erhöhen...nach ja 5 Platten größer zu bekommen ist nicht mal eben so gemacht...Kostenfaktor und Resilvering eben. Daher die Idee die VG's anders aufzubauen mit 3x4 und 3x3 ...meine Gehäuse fassen eben 6 Platten. Fotos...gutes Stichwort; RAW braucht Platz...und eben auch die Option der Erweiterung denn ich will ja nichts, gerade die alten Fotos, wegtun ;-).
Und gerne nehme ich Dein Hilfestellung an! Als kurzen Umriss: habe aktuell Datasets die per SMB freigegeben werden, 2 Stück; plus die besagten LUN's, derer 3.
Die LUN's hatte ich mal mit send/recv komplett übertragen zum Test, einzeln. Mit den Datasets habe ich was mit rsync probiert, was ganz gut lief/läuft (war so als Backup Sync. gedacht, weil ich das mit den Snapshots nicht hinbekommen habe). Alles zwischen den beiden NAS-Systemen ... alles so zum reinschauen und verstehen oder sagen wir mal lernen. Aktuell erzeugt mir das "operative" System von den LUN's und Dataset's einen automatischen Snapshot (täglich), den ich nur so laufen lasse um einfach zu schauen was an Volumen er mir da so auswirft. Bin in so einer Art Findungs-Phase oder Restrukturierung, denn ich philosophiere halt drüber die LUN des aktuell Fileservers kleiner zu machen und ihm direkt per iSCSI die Laufwerke rein zu schieben...was den Vorteil hätte das Problem der "Vergrößerung" mit einfach "neuen" LUN's bereitzustellen und ich hätte jetzt am Anfang nicht immer so einen riesen Ballon den ich mitschleppe....

User avatar
Princo
Forum Moderator
Forum Moderator
Posts: 1081
Joined: 15 Jul 2012 01:21
Location: Berlin, Germany
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#14

Post by Princo » 22 Nov 2018 03:43

Hallo NasBar,

du schrubst, daß du zwei nahezu identische XigmaNAS betreibst. Dazu hätte ich noch ein paar Fragen, damit ich dir eine passende Anleitung geben kann.

1. Welche Version von XigmaNAS setzt du ein?
2. Hast du die "embedded"-Version installiert?
3. Welche RAM-Ausstattung haben deine Systeme?
4. Hat das Backup-System die gleiche Plattenkapazität wie dein Haupt-NAS?
5. Wie viele Daten sind auf dem Haupt-NAS gespeichert? Gib dafür bitte den ersten Eintrag von "Used" im Bereich von "Disks|ZFS|Datasets|Information" an.
6. Wie machst du deine automatischen Snapshots? Hier wäre ein Screenshot von "Disks|ZFS|Snapshots|Auto Snapshot" hilfreich.

Erklärung zu den Fragen:
Im Idealfall haben beide Systeme die gleiche RAM-Ausstattung und die gleiche Festplattenkapazität. Es ist aber kein Problem für das Backup, wenn das Backup-NAS weniger RAM und mehr Festplattenkapazität hat (das ist für Kapazitätserweiterungen interessant).

Der konsequente Einsatz der "embedded"-Version von XigmaNAS sorgt dafür, daß Betriebssystem und Daten streng getrennt betrachtet werden können. Umkonfigurationen und Erweiterungen werden dadurch wesentlich vereinfacht.

Die Frage nach den automatischen Snapshots ist etwas diffiziler. Im Idealfall hast du bereits einen einzigen rekursiven Snapshot-Job auf den gesamten Pool eingerichtet. Im weniger idealen Fall hast du dafür nur einzelne Volumes/Datasets ausgewählt.. Ändere bitte nichts an deinen bereits gewählten Einstellungen! Sollten deine Einstellungen nicht optimal sein, werden wir das kontrolliert ändern.

Die Frage nach der Datenmenge hat den Hintergrund, daß ich gerne abschätzen möchte, in welcher Zeit das initiale (erstmalige) Vollbackup abgeschlossen werden kann. Dazu erkläre ich später mehr.

Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#15

Post by NasBar » 25 Nov 2018 15:26

Hallo Princo,

prima das es weitergeht :-)

1. Welche Version von XigmaNAS setzt du ein?
In dem "produktiven" ist aktuell 11.2.0.4 - Omnius (Revision 6026), das "Standby" ist aktueller 11.2.0.4 - Omnius (Revision 6195). Geschuldet dem Umstand der Verschlüsselung. Weil update, Neustart und "manuelle" Eingabe....so gewollt. Beide Systeme sind so aufgesetzt. Wunschgemäß versuche ich die Systeme aktuell zu halten.

2. Hast du die "embedded"-Version installiert?
Beide auf einem USB Stick drauf, daher ja. Installationsstand ist/war XigmaNAS-x64-LiveUSB-11.2.0.4.5774.

3. Welche RAM-Ausstattung haben deine Systeme?
Beide nur 8GB ECC, erkenne aktuell aber keine Einbrüche in der Performance, weiß aber das hier womöglich auch Nachgerüstet werden kann.

4. Hat das Backup-System die gleiche Plattenkapazität wie dein Haupt-NAS?
Hier sind die beiden aktuell nicht gleich, wegen der Thematik der Erweiterbarkeit...das Produktive trägt aktuell 5x4TB in einem VG. Das Standby 3x3T und 3x4TB; in zwei VG's (jeweils gleiche Plattengössen zusammen). Gehäuse beide identisch mit max. 6 Slots. Ich schrieb ja das ich aber auch gerne irgendwie umbauen kann wenn es hilft...aber die existenten Platten nutzen will.

5. Wie viele Daten sind auf dem Haupt-NAS gespeichert? Gib dafür bitte den ersten Eintrag von "Used" im Bereich von "Disks|ZFS|Datasets|Information" an.
Ich habe hier ja nicht nur Dataset's, daher womöglich eine "witzige" Anzeige: Used 10.8T bei 3.24T AVAIL.
Laut Konfiguration sind zwei Datasets erstellt worden mit je 4T im Kontingent.
Zu diesen dann noch die Datenträger (LUN's) die zeigen da auch (zumindest für mich eher verwirrende Werte an)
Storage/LUN_FS 4.60T 6.24T
Storage/LUN_MX 1.01T 4.24T
Storage/LUN_NC 4.19T 7.37T
Die LUN'S NC und FS wurden mit 4T erstellt die MX mit 1T...warum er das daraus macht, kann ich nicht beantworten.

6. Wie machst du deine automatischen Snapshots? Hier wäre ein Screenshot von "Disks|ZFS|Snapshots|Auto Snapshot" hilfreich.
Die lasse ich ja nur so laufen um zu sehen was da so an Menge zusammenkommt....
Ich habe aktuell (bis auf die LUN's) nicht wirklich wichtiges Zeugs drauf...oder besser es wird aktuell per mobiler Datenträger jongliert; oder aus den "Gastsystemen" der LUN'S heraus gesichert … das will ich ja eben abschaffen. Bin ja in der Lernphase und will erstmal mich selber sicher fühlen, mit dem System.
Ich habe mir jetzt da die zwei "Kistchen" hingesetzt und denke das die ihren Job fantastisch machen werden wenn man denn mal erkannt hat was, wie und warum passiert … alles noch eher in der Probephase.
Per RSYNC läuft zum Beispiel der Fotokatalog (der auch in den Auto.Snapshots drin ist), der nicht üppig ist und nur zum testen erstmal drauf gekommen ist. LUN's und Datasets laufen über eigene Schnittstellen...LAGGed für das Management und die LUN'S über einen eigenen exklusiven iSCSI Adapter. So, hoffe das es nicht alles zu absurd ist. Wobei ich dann schon den ersten Fail erkannt habe das der Auto-Snapshot nicht immer Rekursiv sein soll/muss. Wie siehst du die Betrachtung bei den Backup's eher auf einzelne zu gehen und nicht komplett immer alles in einem Großen?
Gerade bei den LUN's bin ich mir da nicht ganz klar drüber....für den Fall der Restrukturierung denke ich das eine einzelne passender wäre um nur diesen wieder zu beleben? Daher meine Vereinzelung auch bei den Snapshots.

Grüße und eine erfolgreiche Woche!
You do not have the required permissions to view the files attached to this post.

User avatar
Princo
Forum Moderator
Forum Moderator
Posts: 1081
Joined: 15 Jul 2012 01:21
Location: Berlin, Germany
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#16

Post by Princo » 12 Dec 2018 02:48

Hallo NasBar,

entschuldige bitte, daß ich z.Z. ein paar Tage für eine Antwort brauche, aber derzeit bin ich viel mit Photographieren beschäftigt (die Weihnachtszeit rückt näher).

Vielen Dank für deine Antworten. Es war gut, daß ich nachgefragt habe, denn dadurch sind noch ein paar wichtige Informationen aufgetaucht, welche berücksichtigt werden müssen (z.B. die Verschlüsselung).

Deine RAM-Ausstattung ist völlig ausreichend. Wenn du bis jetzt damit keine Probleme hattest, besteht da keine Notwendigkeit für eine Aufrüstung. Im Netz findet sich manchmal die Faustregel 1GB RAM pro 1TB Diskkapazität, aber eine echte Grundlage für diese Aussage habe ich bisher nicht finden können. Diese Faustregel scheint eher für echte Serversysteme mit tausenden Benutzern zu gelten. Für den Einsatz mit wenigen Nutzern spielt das, meiner Erfahrung nach, gar keine Rolle.

Etwas anders stellt sich die Situation dar, wenn du auf dem NAS selbst virtuelle Maschinen betreiben würdest. Das scheint bei dir aber nicht der Fall zu sein, denn dein VM-Host läuft bei dir ja wohl auf einem externen Rechner, der nur die ISCSI-Volumes deines NAS nutzt.

Ein guter Indikator dafür ist, ob dein NAS (Haupt-NAS) im normlen Betrieb ins Swapping gerät. Schau mal nach, ob dein "Swap Usage" beim Eintrag "Used" auf 0 steht (auf der normalen Status-Seite). Dafür sollte das System aber schon eine ganze Weile laufen, damit man tatsächlich einen sinnvollen Wert erhält.

Auf deinem Haupt-NAS hast du 5x4TB (wahrscheinlich als RaidZ1). Das ergibt eine nutzbare Kapazität von 14,05TB

Auf deinem Backup-NAS hast du 3x3TB und 3x4TB, jeweils als einzelne Pools (also zwei Pools). Diese könntest du allerdings zu einem großen Pool konfigurieren, wobei die kleinste Plattenkapazität maßgeblich ist.

Daraus folgt, daß du im Backup-NAS mit 6x3TB (RaidZ1) rechnen müßtest. Das ergäbe eine nutzbare Kapazität von 12,59TB.

Das ist theoretisch ungünstig, da das Backup-NAS in dieser Konfiguration weniger Kapazität hat, als das Haupt-NAS.

Allerdings hast du ja geschrieben, daß dein Haupt-NAS noch 3,24TB freien Speicherplatz hat.

Es wird also durchaus möglich sein, dein Haupt-NAS auf das Backup-NAS zu sichern, obwohl das Backup-NAS eine geringere Kapazität hat.

Das ist als Dauerlösung sicher nicht geeignet, aber derzeit bist du damit noch in der Lage eine Sicherung durchzuführen, und hast dadurch die Möglichkeit, gefahrlos auch umfangreiche Systemänderungen durchzuführen (z.B. Verkleinerung der LUNS).

Ich persönlich würde ja den Einsatz von ISCI nach Möglichkeit vermeiden, und eher mit Freigaben (oder anderen Diensten) arbeiten, aber für solche tiefgreifenden Umstrukturierungen ist ein gutes Backup eine fundamentale Grundlage, und daher möchte ich das vorerst ausklammern.

Zu deiner Snapshot-Konfiguration:

Du hast hier zwei Auto-Snapshots für zwei Datasets und zwei Snapshots für Volumes eingerichtet. In den vorherigen Postings hast du aber mindestens drei Volumes erwähnt.
Falls dich der Ausdruck "Volumes" irritiert, sei auf meine Signatur verwiesen, in der steht, daß ich mich immer auf das englischsprachige GUI beziehe. Leider haben einige Übersetzer nicht berücksichtigt, daß man Begriffe wie Pool, Dataset, Volume, Snapshot nicht mit Schwimmbecken, Datensatz, Datenträger und Schnappschuß übersetzen darf, weil das in sämtlichen (auch deutschsprachigen) Dokumentationen zu ZFS auch nicht gemacht wird.

Deine Snapshot-Konfiguration ist suboptimal. Du sicherst damit Teile deines Datenbestandes zu unterschiedlichen Zeiten. Das wird aber nicht das sein, was du tatsächlich möchtest.

Es ist sehr viel wahrscheinlicher, daß du deinen gesamten Datenbestand zun Zeitpunkt X sichern möchtest.

Du dachtest wahrscheinlich, daß beim Anlegen eines Snapshots zur Sicherung umfragreiche Datentransferaktionen stattfinden, und hast deshalb einen Abstand von jeweils einer Stunde zwischen diesen Aktionen eingeplant, damit genug Zeit für die Durchführung bleibt.

Aber so funktioniert das mit den Snapshots nicht. Wenn man einen Snapshot anlegt, dann bedeutet das etwas ganz Simples: "Bitte friere mir den aktuellen Zustands des Dateisystems zum aktuellen Zeitpunkt für eine spätere Verwendung ein!".

Im Web-GUI kann man nur tägliche Snapshots zu bestimmten Zeiten einrichten. In der Praxis ist man darauf aber nicht beschränkt. Über spezielle Befehle ist es durchaus möglich, alle paar Minuten diverse Snapshots zu erzeugen. Im Allgemeinen reicht aber meistens ein täglicher Gesamt-Snapshot des Systems aus.

Du brauchst das jetzt nicht ändern, dazu kommen wir später, denn diese Art der Konfiguration hat durchaus Auswirkungen auf den Erstabgleich der Daten.

Welche Möglichkeiten ergeben sich jetzt?
Wir können ein manuelles Backup-System einrichten, bei dem alle Daten deines Haupt-NAS auf das Backup-System 1:1 übertragen werden.
Danach kann dein Backup-System jederzeit die Funktion deines Haupt-NAS übernehmen (indem man die Konfigurationsdatei des Haupt-NAS auf dem Backup-NAS einspielt).
Oder du kannst die Datentrager des Backup-NAS im Haupt-NAS einbauen, und so den Betrieb aufrecht erhalten.
Natürlich kannst du auch einzelne Datasets/Volumes vom Backup-NAS auf das Haupt-NAS überspielen, falls dies einmal nötig sein sollte.

Im realen Einsatz wirst du diese Funktionalität allerdings nie brauchen müssen, denn auf alte Daten (z.B. irrtümlich gelöschte Dateien) kannst du bereits über die lokalen Snapshots zugreifen, und singuläre Festplattenausfälle werden über die RaidZ-Funktionalität abgefangen.

Wozu also noch ein Backup-NAS?
1. Ein Raid(Z) ist kein Backup. Fällt mehr als eine Festplatte im Haupt-NAS aus, wären alle Daten weg.
2. Für Kapazitätserweiterungen. Die Systeme können auf den jeweils akteullen Platzbedarf berechnet werden. Upgrades der Plattenkapazität profitieren von sinkenden Plattenpreisen, oder dem Einsatz von neuen Speichertechniken.
3. Zur Defragmentierung. ZFS bietet von Hause aus noch keine eigene Defragmentierung an. Aber wie bei allen Dateisystemen, können Daten durch Umkopieren auf ein anderes Dateisystem (in dem Fall auf einen anderen ZFS-Pool) defragmentiert werden. Je nach Nutzungsart des NAS, kann das Defragmentieren durchaus enorme Auswirkungen auf die Gesamtperformance des Systems haben.
4. Für den seltenen Fall, daß man ein Downgrade des ZFS-Dateisystems durchführen muß, z.B. weil man auf ein anderes NAS-OS wechseln möchte.

All diese Aufgaben lassen sich mit den gleichen simplen Befehlen ausführen.

Wie geht es jetzt weiter?
Wir werden im nächsten Schritt zuerst das Backup-NAS einrichten. Dazu werden wir die dortigen Festplatten zu einem großen Pool konfigurieren.
Auf dem Backup-NAS wird NUR der SSH-Dienst aktiviert werden (ausgehend von der XigmaNAS-Grundkonfiguration). Das Backup-NAS wird ansonsten keine weiteren Dienste bereitstellen, und ist dadurch quasi "unsichtbar" im Netz.

Dann werden wir einen sogenannten "Erstabgleich" vom Haupt-NAS auf das Backup-NAS durchführen. Dieser Vorgang kann durchaus mehrere Tage in Anspruch nehmen, da du einen sehr großen Datenbestand hast (durch die ISCSI-Laufwerke). Da hierbei eine Vielzahl von Faktoren mit im Spiel sind, läßt sich die ungefähre Dauer leider nicht vorab bestimmen. Es gibt bestimmte Verfahrensweisen, diesen Vorgang zu optimieren, aber das würde momentan hier den Rahmen sprengen.

Während des "Erstabgleichs" kannst du übrigens ganz normal mit deinen Daten weiter arbeiten. Möglicherweise wirst du dabei eine gewisse Performance-Einbuße feststellen, denn der Abgleich wird mit der technisch maximalen Geschwindigkeit durchgeführt werden. Das ist gleichzeitig auch ein halbwegs brauchbarer Belastungstest der Systeme.

Nach dem Erstabgleich folgt dann ein weiterer Abgleich, der die zwischenzeitlich geänderten Daten überträgt. Die Werte des zweiten Abgleichs sind von ganz besonderem Interesse, denn sie geben einen Hinweis darauf, in welchen Abständen man einen Abgleich durchführen sollte. Dazu später mehr.

Entschuldige nochmals bitte die etwas längere Zeit für meine Antwort, aber dein Einsatzszenario ist etwas komplexer als üblich, und daher muß ich bei meinen Antworten einen erweiterten Themenkreis berücksichtigen.

Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.

XPUser
experienced User
experienced User
Posts: 118
Joined: 04 Nov 2013 16:45
Location: Bei Köln
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#17

Post by XPUser » 15 Dec 2018 21:39

An dieser Stelle möchte ich mich hier mal einklinken.
Hintergrund: ich habe in den letzten Wochen mein HauptNAS mal ordentlich entrümpelt und dadurch über 600GB eingespart.
Damit aber bin ich bei weitem noch nicht am Ende und denke es wird sich noch bis in Januar/Februar hinziehen.
Danach möchte ich dann mit identischer Hardware/Datasets den Backup Server neu aufsetzen und vom HauptNAS mit einem Erstabgleich
defragmentiert neu befüllen. Anschliessend dann das gleiche dann vom Backup zum Haupt Server.
Da es darauf hinausläuft wie von Princo im letzen Post in Aussicht gestellt, würde ich halt gerne wissen wie man schnell und effizient die Server neu aufsetzt?
Mein Plan ist es dann zu machen wenn ich mit der Entrümpelung fertig bin und es dann ein Update zu der Zeit von Xigmanas gibt mit dem ich dann auch die Sticks neu aufsetze.

MfG XPUser
NAS-A HP N54L 16GBECC-Ram 4x4TB WD-Red RaidZ1 XigmaNAS 12.0.0.4.6881 embedded
NAS-B HP N54L 8GBECC-Ram 4x4TB WD-Red RaidZ1 XigmaNAS 12.0.0.4.6881 embedded

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#18

Post by NasBar » 21 Dec 2018 19:18

Hallo …

Weihnachten ist immer die Hölle los, und man ist immer was beschäftigt…also von daher hatte auch ich nicht immer so die Zeit, alles gut also.
Zunächst danke Princo für die ausführlichen Beschreibungen und ich habe zu danken. Nun aber mal weiter…

Also gestern ist es passiert…Systemfehler, Totalausfall! USB Stick hat aufgegeben…man war ich schlecht gelaunt. Also nicht lange rumgejammert, neuen USB Stick gefüllt und komplett neu installiert. Bei der Möglichkeit direkt noch das Board upgedatet und dann alles wieder zusammen, dank ZFS genial einfach Konfiguration zurück gelesen, trotz der Verschlüsselung alles prima und ohne Probleme. Das hat also schon mal geklappt, wenn auch unfreiwillig. Bei dem Turn auch direkt noch mal Xigma auf den letzten Stand gebracht. Aber nun auch klar, zu dem Swap Thema kann ich heute noch nichts sagen. Reiche ich dann mal nach wenn es paar Tage gelaufen ist.
Princo deine Vermutungen stimmen soweit alle also HauptNas 5x4TB als RaidZ1 nur mit den gezeigten Werten da bin ich überfordert, das hatte ich Eingangs schon mal erwähnt…denn ich kriege die Werte nicht gut sortiert. Ein Beispiel aus dem HauptNAS:
Festplatten>ZFS>Pools>Management: Ein Pool wir hier mit 19,92 TB ausgewiesen, auf dem 16,25TB „Frei“ zu sein scheinen…was natürlich nicht stimmen kann. Pool wird aus einem virtuellen Gerät mit 5x4TB gestellt.
Unter Festplatten>ZFS>Datasets>Informationen finde ich das:
NAME USED AVAIL REFER
Storage 10.8T 3.23T 141K
…/Backup 996G 3.03T 996G
…/Fotokatalog 8.32G 3.23T 8.32G
Dazu dann noch meine Datenträger (LUN’S) Festplatten>ZFS>Datenträger>Informationen
NAME USED AVAIL REFER
Storage/LUN_FS 4.61T 6.23T 1.55T
Storage/LUN_MX 1.01T 4.23T 5.37G
Storage/LUN_NC 4.19T 7.36T 68.0G
Das kriege ich irgendwie nicht zusammen…Bei den LUN’s Used undAvail…was rechnet der da? Sind das die Snapshots? Bei QNAP und Co kann man den Speicher prozentual für Snapshots reservieren gibt es sowas auch hier…oder was wie und wann schlagen da zu Buche?
Auf dem BackupNAS wird es besser (wohl aber auch weil noch nicht viel los)…dennoch, auch hier habe ich so ein paar Verständnisprobleme mit den Anzeigen. Gleiche Sortierung wie oben: Ein Pool mit 20,89TB, wo 20,6 TB frei sein sollen. Hier wird der Pool aus zwei virtuellen Geräten gestellt…einmal die drei 4TB und dann noch die drei 3TB zu je einem Gerät verschweißt. Hier war ja der Gedanke die dann gegen größere „Poolweise“ zu erhöhen um den gesamten Speicher ausbauen zu können. Wenn ich jetzt alle 6 zusammen in ein virtuelles Gerät aufnehme, würde ich dann einen Speicher Upgrade auch so hinbekommen? Also wenn ich dann nach und nach die 3TB gegen 4 TB tausche…nur wenn ich dann noch weiter wachsen will dann müsste ich ja genau 6 Platten austauschen, korrekt? Nur erkenne ich, dass mein Szenario nicht so aufgeht. Es gibt diese Imaginäre Grenze von 12TB aktuell…die ich mir nicht so erklären kann. Wo kommen die her?
Denn auf dem vermeintlich größeren Pool bekomme ich weniger zugeordnet.
Festplatten>ZFS>Datasets>Informationen finde ich das:
NAME USED AVAIL REFER
Storage 693G 11.6T 117K
…/Backup 4.45G 11.6T 4.45G
…/VM Backup 173G 11.6T 173G
Dazu dann noch eine Datenträger zum Testen, Festplatten>ZFS>Datenträger>Informationen
NAME USED AVAIL REFER
Storage/TestLUN 516G 12.1T 74.6K

Und jetzt kommt ja das Gute, weil ich ja eben noch offen bin was Konfiguration und Anwendung angeht…nehme ich jede Idee, Hinweis gerne auf. Ich möchte wenn möglich ein System, was mich nach Jahren nicht zwingt „neu formatiert“ zu werden weil sich das Array ändert…das hatte ich bei QNAP schon so paarmal hinter mir.

Also wenn ich jetzt mal so eine Idee bekomme was wirklich Sinnvoll zu nutzen ist und dann noch das HauptNAS synchronisiert ist das für mich wie Weihnachten.
Bei einem send/receive wird ja wohl voll synchronisiert nehme ich an. Also Quelle und Ziel werden gleich groß...gibt es auch eine Möglichkeit bei einem solchen Vorgang quasi reine Netto Daten in ein "kleineren" Dataset zu bekommen? Bei den Datenträgern denke ich geht das nicht...oder? Bei den Datasets wohl...was ja schon auch nur manuell gehen würde.

Durch den Vorfall habe ich die Snapshots erstmal ausgesetzt.

@XPUser, eine Sicherung der Konfiguration deines bestehenden Systems…da ist doch alles drin. Das Installieren vom NAS selber ist ja nur ein paar Minuten Arbeit. Ich selber bin aber auch ein Freund einer frischen Installation … schon immer.

So dann wünsche ich allen eine ruhige Weihnachtszeit und ich hoffe man liest sich …

User avatar
Princo
Forum Moderator
Forum Moderator
Posts: 1081
Joined: 15 Jul 2012 01:21
Location: Berlin, Germany
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#19

Post by Princo » 27 Feb 2019 00:03

Hallo NasBar,

es ist leider doch mehr Zeit vergangen als gedacht, aber vielleicht bist du ja doch noch am Ball.

Eine kurze Rückmeldung wäre gut, dann würde ich dazu etwas weiter ausführen.

Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.

NasBar
Starter
Starter
Posts: 18
Joined: 23 Sep 2017 18:28
Status: Offline

Re: Snapshots und RSYNC...oder wiedermal Backups

#20

Post by NasBar » 10 Mar 2019 13:57

Hallo Princo,

uhh das sind ja echt Zeitsprünge in unserem Verlauf hier....;-) aber nicht schlimm.
Ja also natürlich bin ich noch dran, so schnell gebe ich nicht auf. Allerdings haben sich in der Zeit ein paar Änderungen ergeben. Also das "Ur-NAS" ist unverändert...11.2.0.4 - Omnius (Revision 6229) mit 5x4TB, nennen wir es einfach mal NAS-A. Dann habe ich das vormalige Backup NAS mit der 3x3TB und 3x4TB abgelöst gegen 6x3TB, alles in einem VG & Pool, was wir nun mal NAS-B nennen. In der Zeit habe ich dann noch eher per Zufall dann noch ein drittes Gerät in dem 6x4TB in einem VG & Pool drehen, welches nun NAS-C benannt wird.
Also Plan ist wie folgt:
Alles von NAS-A nach NAS-B, möglichst NUR Nettodaten. Dann von dem NAS-B Sicherung der Daten nach NAS-C. Damit ich das NAS-A freibekomme und dieses dann updaten...Soft-; als auch Hardware mäßig... Just in case :-)

Den Snapshot einer 3TB LUN (rekursiv in der GUI erstellt) habe ich per <zfs send Storage/LUN_FS@LUN_FS | ssh NAS-B zfs recv Storage/LUN_FS> initial mal laufen lassen...was echt seeeeehr lange gedauert hat, nicht komplett vor gesessen...aber denke waren so > 20 Stunden. Aber final hat es geklappt. Auf dem NAS-B dann ZFS synchronisiert damit stand die LUN auch drin. Dann eine Woche später nochmal per <zfs send -i Storage/LUN_FS@LUN_FS-20190227 Storage/LUN_FS@LUN_FS-20190307 | ssh NAS-B zfs recv Storage/LUN_FS> was dann zeitlich total entspannt war. Also denke ich über ein Script in diese Richtung nach..Umlauf Snapshots und jeweils das Delta wie beschrieben zu sichern. Habe ich was übersehen?
Ich habe in einem Beitrag von Dir gesehen das du SSH als Mittel bei großen Datenmengen nicht als "best choice" nennst...was bietet sich dann an, so out of the box und kompatibel ist?

Auf geht's ....und happy coding...

Grüße

Post Reply

Return to “Deutsch”