RAID5-Verbund erstellen unter Ubuntu (bessere Alternative?)

[Banned]

Hallo,

ich habe vor, mir in Kürze ein zweites NAS zwecks Backup zu bauen (Backup bisher auf externer HDD). Der Hintergrund ist einerseits, dass ich mein Backup auf diese Weise gestalten will, und andererseits, dass ich bei meinem primären NAS von einzelnen RAID1-Verbünden (die dich über die Zeit angesammelt haben) auf RAID6 bzw. RAIDZ2 umsteigen will. Dafür benötige ich einen Speicherort, an den ich die Daten vom primären NAS kopieren und dann später wieder von diesem in das RAIDZ2 kopieren kann.

Für das Backup-NAS benötige ich nun ein geeignetes Betriebssystem, über das ich leicht (am besten einfach aus dem Desktop-Betrieb heraus) die Daten vom NAS ziehen kann; von dem ich aber auch später die Daten wieder auf das primäre NAS kopieren kann.

Ich dachte hierbei an Ubuntu (Client reicht aus, oder?) und habe im Netz diese Anleitung gefunden:

https://wiki.ubuntuusers.de/Software-RAID/

Ist das alles so noch up to date bzw. der beste Weg? Sollte ich etwas beachten, was u.U. dort nicht genannt ist?

Gibt es evtl. bessere Alternativen, als es über Ubuntu zu machen?


PS: Auf dem primären NAS läuft FreeNAS bzw. in Zukunft TrueNAS Core.

 

[Cool Master]

Passt alles, da hat sich die letzten Jahre nichts geändert.

 

[Skudrinka]

Dafür benötige ich einen Speicherort, an den ich die Daten vom primären NAS kopieren und dann später wieder von diesem in das RAIDZ2 kopieren kann.

Hier wäre mir ein Backup zu wenig.
Also generell ein Backup ist zu wenig.
Aber gerade bei solchen Umbauarbeiten kann schnell was schief gehen.
Würde also mindestens 2 Kopien anfertigen und diese auch verifizieren/prüfen.
Gerade wenn die Platte neu ist, auf dem die einzige Kopie erstellt werden soll, wäre mir das zu riskant. Denn Platten gehen meistens ganz am Anfang oder am Ende im Alter kaputt. Badewanne und so.

 

[Banned]

Gerade wenn die Platte neu ist, auf dem die einzige Kopie erstellt werden soll, wäre mir das zu riskant.

Ich werde ja ein RAID5 aus drei HDDs erstellen, also mit Parität, und zwei der HDDs sind nicht neu. Somit würde ich das Risiko als recht gering einschätzen, aber klar, schiefgehen kann immer was. Das Leben ist voller Gefahren und ich fahre auch immer noch Auto.

 

[Cool Master]

Evtl. kannst du ja am Primär NAS neue HDD/SSD kaufen und hast die alten Daten dann noch auf den alten HDD/SSD. Wäre ggf. eine Möglichkeit noch sicherer zu sein und man könnte es mit einem Kapazität-Upgrade verbinden. Ich schiele auch schon seit einigen Wochen auf die 870 QVOs mit 8 TB

 

[Banned]

Ja, wäre schön. Bei 12TB aber immer so ne Sache. Noch sicherer geht immer. Hab mir vor kurzem erst ne 8TB-HDD gekauft, um das RAID5 verwirklichen zu können (die hat mich da schon 30€ mehr gekostet als die beiden älteren davon damals jeweils, da war ich schon recht bedient. )

Ganz wichtige Daten habe ich auch noch an anderer Stelle. Der Großteil ist halt Multimedia. Wäre zwar bitter, wenn was schief gehen würde, aber auch keine komplette Tragödie für mein Leben.

Ich denke, mit RAID5 und ECC-RAM beim Backup bin ich da schon recht sicher unterwegs. Also zumindest so sicher, dass es mein Sicherheitsempfinden befriedigt.

Theoretisch müsste mir ja mehr als eine Platte ausfallen (bei Betrieb oder Rebuild) oder das komplette System inklusive HDDs abrauchen. Das Risiko werde ich eingehen.

 

[TechX]

Gibt es evtl. bessere Alternativen, als es über Ubuntu zu machen?

PS: Auf dem primären NAS läuft FreeNAS bzw. in Zukunft TrueNAS Core.

Was spricht dagegen dein zukünftiges Backup-NAS ebenfalls mit TrueNAS zu machen?

 

[Banned]

Dass ich "nur" 8GB RAM gekauft habe und dass Hin- und Her-Kopieren damit aus meiner Sicht umständlicher wäre als es einfach über den Dateimanager in Ubuntu zu steuern.

 

[snaxilian]

Wenn du schon bei einem NAS auf ZFS setzen willst, dann mach das doch direkt bei beiden Systemen. Dann kannst die Sicherungen als Snapshot & Replikation umsetzen.

Dass ich "nur" 8GB RAM gekauft habe

Auch damit kommt ZFS klar. Ja, es gibt die Empfehlungen mit deutlich mehr RAM bzw. 1 GB RAM pro 1 TB Storage aber diese Empfehlung ist vorrangig für größere Storages und nicht für den Privatanwender, der da >90% "Multimedia" drauf liegen hat. Du wirst daher kaum vom ARC profitieren können und Deduplikation wird dir auch bei Mediendateien kaum bis nix bringen. Solange also du Dedup deaktiviert lässt und nicht doch noch andere Anforderungen an dein NAS hast die du aber nicht erwähnt hast, dann kannst du auch ZFS mit 8 GB Ram verwenden.

https://wiki.ubuntuusers.de/Software-RAID/

Ist das alles so noch up to date bzw. der beste Weg? Sollte ich etwas beachten, was u.U. dort nicht genannt ist?

Ja, passt soweit. Musst es halt trotzdem an deine Situation anpassen und nicht blind 1:1 abtippen.

Gibt es evtl. bessere Alternativen, als es über Ubuntu zu machen?

Entweder 2x TrueNAS Core oder halt weiterhin mit Ubuntu aber auch da ZFS verwenden für einfachere Sicherungen.
Nachteil von ZFS ist halt die vergleichsweise schlechte Flexibilität wenn du deine Pools nachträglich vergrößern willst.

 

[Banned]

Auch damit kommt ZFS klar. Ja, es gibt die Empfehlungen mit deutlich mehr RAM bzw. 1 GB RAM pro 1 TB Storage

Die 1GB pro 1TB sind übertrieben, das ist mir klar. Es gab dazu auch mal (bzw. gibt es sicherlich immer noch irgendwo) einen Blog-Artikel eines FreeNAS-Entwicklers, wo, soweit ich mich erinnere, erst ab 100TB Gesamtkapazität überhaupt dringend zu 32GB RAM geraten wurde (wenn man keine Deduplizierung verwendet). Bei meinem Primär-NAS habe ich 16GB für 24TB.
Aber ZFS frisst ja gerne RAM und was da ist, wird idR auch gut voll gemacht, darum ist es immer etwas schwierig, zu beurteilen, was wirklich nötig ist.

Ich war nur davon ausgegangen, dass 8TB evtl. etwas knapp bemessen wäre, da dies oft als Mindestmenge genannt wird.

Musst es halt trotzdem an deine Situation anpassen und nicht blind 1:1 abtippen.

Das ist klar.



EDIT:

"FreeNAS requires 8 GB of RAM for the base configuration. If you are using plugins and/or jails, 12 GB is a better starting point. There’s a lot of advice about how RAM hungry ZFS is, how it requires massive amounts of RAM, an oft quoted number is 1GB RAM per TB of storage. The reality is, it’s complicated. ZFS does require a base level of RAM to be stable, and the amount of RAM it needs to be stable does grow with the size of the storage. 8GB of RAM will get you through the 24TB range. Beyond that 16GB is a safer minimum, and once you get past 100TB of storage, 32GB is recommended. However, that’s just to satisfy the stability side of things. ZFS performance lives and dies by its caching."
(https://www.truenas.com/community/threads/home-setup-memory-requirements.74443/#post-516557)

 

[snaxilian]

evtl. etwas knapp bemessen wäre, da dies oft als Mindestmenge genannt wird.

Ja, damit das System nicht direkt auf dem letzten Loch pfeift und andauernd swappen muss sobald man mal 2 Dateien verschiebt oder ggf. die diversen Plugins ausprobiert. Sonst hast nämlich alle Foren voll von ahnungslosen Freizeitadmins die laut jammern, dass $hier-beliebiges-System-in-dem-Fall-Truenas ja doof sei weil es so langsam sei.
Wenn es ein reines NAS werden soll ohne große Zusatzfeatures wirst auch mit 8 GB arbeiten können.

 

[Banned]

Nachdem ich mich noch mal etwas eingehender mit der Thematik beschäftigt habe, werde ich es wohl das Backup-NAS auch als TrueNAS aufsetzen und die Daten per Replication kopieren, dies erscheint mir die einfachste Variante zu sein, und Rsync ist wohl für große Transfers recht lahm, wie ich häufiger gelesen habe.


Falls jemand mal vor der gleichen Frage steht, ich finde dieses Video hier recht hilfreich:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Danke für Eure Anregungen.

 

[Bohnenhans]

naja ich habe auch einen unserer beiden Server - beide mit 9 * 16 TByte also jeweils 144 TByte Brutto auch schon mit 8 Gbyte RAM betrieben das überhaupt kein Problem (ohne Deduplication aber mit OpenZFS Crypt)

Aktuell habe ich jeweils 24 Gbyte drin und arc min / max auf 8 und 16 Gbyte eingestellt das läuft dann nach meinem Empfinden recht flüssig (Swap ist aus)

Viel RAM ist vor allem dann sinnvoll wenn viel gleichzeitig zugegriffen wird - bei 1-3 Personen ist alles ab 8 Gbyte denke ich ok ohne dass man noch sooooo viel merkt.

Das wird wohl vielleicht auch darauf ankommen wie man rsync nutzt - ob per SSH oder "native"

Ich nutze rsync native, da ich Filesystem unabhänig bleiben will - "native" also mit "rsync Server Daemon" und komme in einem 10 GBit Netzwerk bei grossen Dateien auf > 900 Mbyte / sec bei (sehr) kleinen Dateien dann meist noch auf 350 Mbyte / sec - das denke ich geht anders auch nicht schneller.

Glaube dass bei grossen Dateien evtl schon das 10 GBit Netzwerk limitiert bei sehr kleinen das Filesystem.

Aber alles > 10 Gbit Netzwerk ist ja dann $$$^$$$ und da ist das dann auch spätestens mit passiv gekühlten Switches vorbei.

ZFS ist denke ich viel genügsamer als man glaubt, die Speicherempfehlungen schätze ich kommen eher daher, dass bis vor ein paar Jahren ZFS eher im "gewerblichen" Multi-User Umfeld eingesetzt wurde - FreeBSD war doch bis vor 5 Jahren im Heimbereich nicht so verbreitet und ZFS kam damit für viele erst mit OpenZFS in den Heimbereich.

Ich habe auch darauf schon ZFS kompiliert und am Laufen gehabt https://www.hardkernel.com/shop/odroid-c2/

 

[Banned]

Schon ohne SSH. Hat mich auch gewundert.

Ich bin auf Folgendes gestoßen, und das könnte die Sache erklären:

"Rsync is slow. It's not really intended for high speed LAN links. It makes a full file checksum on both sides, then copies the files, then checksums again. Most of the time is spent on checksums, not file copying."

(https://www.reddit.com/r/synology/comments/dz987t/rsync_worked_but_seemed_really_really_really_slow/)


Dabei kommt es dann darauf an, wie stark die CPU ist (gut, das wäre bei mir dann wahrscheinlich kein so großes Problem), denn wenn bei RSync die Prüfsummen für ganz Dateien erzeugt werden, ist das aufwendiger, als bei Replication, die m.W. Block-basiert und nicht Datei-basiert arbeitet.

Dort wird auch dazu geraten, Rsync als Daemon laufen zu lassen, wie du es tust. Aber das geht mir alles etwas zu weit. So tief bin ich in der Materie nicht drinnen. Ich will im Grunde nur möglichst einfach meine Dateien hin und her kopieren. Mit ZFS send/receive habe ich mich auch kurz beschäftigt, aber das war dann alles recht komplex bzw. zu wenig dokumentiert für meinen Kenntnisstand.

 

[andy_m4]

Mit ZFS send/receive habe ich mich auch kurz beschäftigt, aber das war dann alles recht komplex bzw. zu wenig dokumentiert für meinen Kenntnisstand.

Das send-receive-Mechanismus ist ja nun wirklich simpel. Der Status wird einfach serialisiert und kann dann sogar ge-piped werden usw. Einfacher gehts schon gar nicht mehr.

Möglicherweise hilft Dir ja die Doku von FreeBSD weiter:

• Deutsch:
  https://docs.freebsd.org/de/books/handbook/zfs/#zfs-zfs-send
• Englisch:
  https://docs.freebsd.org/en/books/handbook/zfs/#zfs-zfs-send
• Manpage zfs send:
  https://man.freebsd.org/cgi/man.cgi?query=zfs-send&apropos=0
• Manpage zfs receive:
  https://man.freebsd.org/cgi/man.cgi?query=zfs-receive&sektion=8&apropos=0

 

[Banned]

Das mit Send ist daraus verständlich, danke.

Für mich würde sich dann aber erst mal die Frage stellen, wie ich da den Pool von meinem zweiten NAS überhaupt erst mal in die Ansicht der zfs Pools hinzufüge, sodass sich dahin senden kann, die Rechte müssten dann ja auch sicherlich verwaltet werden, damit man das überhaupt kann, wenn sich die Pools nicht auf demselben System befinden.
Dafür müsste ich dann ja wahrscheinlich den Pool irgendwie importieren von der Adresse über das Netzwerk. Könnte ich sicherlich auch alles nachlesen, aber mit der Methode über die Oberfläche ist das dann doch wesentlich einfacher für jemanden mit meinem Kenntnisstand.

 

[andy_m4]

erst mal in die Ansicht der zfs Pools hinzufüge
...
aber mit der Methode über die Oberfläche ist das dann doch wesentlich einfacher

Die Methode über die GUI finde ich sogar komplizierter, weil man sich erstmal mit solchen Sachen herumschlagen muss wie "wie kriege ich den Pool in die Ansicht" usw.

Für die Replikation per Kommandozeile tut es einfach ssh (wenn man die Verschlüsselung nicht braucht, tut es im Prinzip sogar netcat und das optional noch kombiniert mit mbuffer, was der Performance gut tun kann) und fertig.

 

[Banned]

Wenn man da drinnen ist, geht einem das sicher leicht von der Hand. Mir z.B. sind netcat und mbuffer komplett fremd. Sieht auch nicht ultra kompliziert aus, aber muss man sich auch einlesen. Und SSH habe ich das letzte mal vor einigen Jahren verwendet und da muss ich dann ja erst mal auf dem einem Gerät den Server erstellen und meine Erinnerungen dafür auch erst mal etwas auffrischen.

Deshalb für mich eher komplizierter, als es über die GUI zu machen. Aber wie gesagt, wenn man da fit drinnen ist, mag das durchaus einfacher sein, das will ich nicht bestreiten.

 

[Bohnenhans]

Hmm bei mir wird garantiert keine Checksumme erstellt bei x0 Terabyte würde das sicher viele Stunden dauern. Ich rufe rsynce mit -avx auf - das dauert ein paar Minuten bis er dann anfängt mit Abgleichen auch auf einem raspberry (rsync nutzt glaube ich dann nur Dateinname, Grösse und Zugriffszeit der Datei als Kriterium)

Es spricht doch überhaupt nichts dagegen das über die Oberfläche zu machen - sich in rsync und Co einzuarbeiten macht eigentlich nur dann Sinn wenn man die Sachen so oft macht, dass man das z.B. automatisieren will.

Aber wegen 1x oder auch 2x lohnt der Aufwand doch nicht wirklich sich wo einzuarbeiten.

GUI hat ja auch den Vorteil dass man sich keine Gedanken über Umlaute und User Rechte etc Co machen muss - auch wenn heutzutage ja alles UTF-8 ist xD

 

[HITCHER_I]

Wenn man die Standard Cache-Größe ändert, kann das Software-RAID schneller laufen.
https://askubuntu.com/questions/20852/making-stripe-cache-size-permanent