Proxmox/NAS Kombination mit bestehendem Datenbestand

Lenny88

Lt. Commander
Registriert
Dez. 2002
Beiträge
1.861
Hallo,

ich betreibe hier einen, zugegebenermaßen ziemlich schwachen kleinen Proxmox "Server" (AMD A4-5000 APU mit 8 GB Ram, 750 GB HDD für Proxmox + VMs, 2x3 TB Datenplatten).

Die Datenplatten sind grundsätzlich unabhängig von Proxmox. Ich habe sie einfach per SAMBA als Netzwerklaufwerke freigegeben, sie werden aber in Proxmox nicht genutzt. Da sie schon vorher voll waren, habe ich sie per NTFS eingebunden.
Zusätzlich hatte ich noch zwei 3 TB Platten in meinem Gaming PC und habe je zwei Platten 1:1 als Backup gespiegelt.

Eine der 3 TB Platten hat nun aufgegeben, ehrlich gesagt sind die Daten aber auch nicht wirklich wichtig, ein 1:1 Backup ist definitiv nicht nötig, hatte die Platten aber halt über.

Ich überlege das Ganze nun umzugestalten und ggf. die 3 TB Platten aus meinem Gaming PC zu verbannen.

Was ich gerne hätte: die drei 3 TB Platten im Proxmox Server, als ein übergreifendes Volume mit 6 TB nutzbar und einem Laufwerk für Parität. Performance ist nicht wichtig, der Zugriff erfolgt praktisch nur über WLAN. Disk Spindown muss möglich sein, da Zugriff auf die Daten nur selten erfolgt. Zudem möchte ich es gerne in Proxmox einbinden, um z.B. Backups der VMs in Proxmox direkt dort ablegen zu können.
Im Gaming PC werden dann nur noch die wirklich wichtigen Daten gesichert.

Wie würdet ihr das lösen?

1. ZFS direkt unter Proxmox mit RaidZ-1 Konfigurationen. Hätte ich grundsätzlich das beste Gefühlt mit aufgrund der nativen Unterstützung, aber ich ja zwangsläufig formatieren und habe aktuell keinen Speicher zum Auslagern.

2. früher habe ich, allerdings im Windows PC, mal Snapraid genutzt. Zusammen mir mergefs sollte damit auch ein übergreifendes Volume möglich sein. Allerdings weiß ich nicht, ob das auch mit NTFS funktioniert unter Proxmox/Debian?Wenn nicht gibt es aus meiner Sicht keinen Vorteil ggü. 1.

3. etwas ganz anderes?

Was meint ihr dazu?

Gruß
Fabian
 
variante 1 und im bekanntenkreis mal rumfragen, ob man eine platte zum temporären auslagern bekommt. alternativ ist eine separate backup-platte sicherlich auch eine sinnvolle investition und könnte dafür genutzt werden.

den standby der platten kann man z.b. so konfigurieren:
Code:
root@proxmox:~# cat /etc/udev/rules.d/69-hdparm.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ATTRS{queue/rotational}=="1", RUN+="/usr/sbin/hdparm -B 127 -S 60 /dev/%k"

edit: es wäre möglich, das raid-z1 mit nur 2 platten und einem sparse file zu erstellen (die fake dritte platte bzw. das sparse file dann offline nehmen), die daten raufzukopieren und das sparse file durch eine reale dritte platte zu ersetzen. dann bräuchte man temporär nur zwei platten für den umzug. ein backup ist trotzdem immer angebracht :)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: snaxilian
Danke. Über HDPARM habe ich den Spindown bisher auch umgesetzt. Funktioniert also auch problemlos, wenn die Platten im raid-z1 laufen?
Und inwiefern ist in Proxmox der Zugriffauf ein ZFS Volume aus einer VM bzw. einem LXC Container möglich?

Gruß
 
spindown funktioniert auch im raidz1. du musst allerdings wissen, wozu/wie du den pool einsetzen willst. du kannst den pool direkt in proxmox erstellen oder in einer vm. bei ersterem kannst du dann den pool zum speichern der vm und deren backups nutzen. beim zweiten ansatz würde man z.b. die platten in eine vm durchreichen und dort den pool erstellen.

ich habe auf meinem system proxmox und die vms auf einer ssd installiert/gespeichert und die nas vm hat zusätzlich die hdds bekommen und macht das raidz1 selbst. der grund war, dass ich für die daten in der nas vm die snapshot-funktionalität von zfs verwenden wollte. ausserdem sind die daten so auf den hdds direkt gespeichert und nicht im image der vm. da kommt man im fall des falles einfacher ran.

idealerweise würde man den kompletten sata-controller in die vm durchreichen, allerdings funktioniert das auf meinem system aufgrund zu grosser iommu-gruppen nicht. daher habe ich die platten selbst in die vm durchgereicht. funktional macht das keinen unterschied bis auf die tatsache, dass man die smart-daten nur in proxmox und nicht in der vm sieht.

wie auf dem screenshot zu sehen ist, habe ich auch die front-usb ports in die vm reingereicht, um daten lokal auf externe usb geräte innerhalb der vm sichern zu können.
 

Anhänge

  • proxmox_hdd.png
    proxmox_hdd.png
    34,9 KB · Aufrufe: 363
  • Gefällt mir
Reaktionen: Lenny88
Ich würde den Pool direkt in Proxmox anlegen. Eine dedizierte NAS VM benötige ich nicht, einfache SAMBA Freigaben reichen mir vollkommen.
Die Daten wären damit auch bei mir unabhängig von einer VM direkt auf den Platten gespeichert.
Aber so wie du es beschreibst müsste es ja dann funktionieren. Die VMs laufen auf der kleinen SSD die ich mir noch besorgen will, die 3-täglich ausgeführten Backups der VMs/LXCs kann ich aber auf dem ZFS Pool ablegen, was bisher der einzige Grund war, warum ich ein relativ großes Laufwerk als Systemlaufwerk für den Host nutze.

EDIT: was sagt ihr zu den SMART Werten der beiden Datenplatten. Bis auf den Temperatur-Wert (Problem ist gelöst) irgendwas auffälliges was aus eurer Sicht dagegen spricht die weiter einzusetzen?
1633852847801.png
1633852806175.png
 
Lenny88 schrieb:
Ich würde den Pool direkt in Proxmox anlegen. Eine dedizierte NAS VM benötige ich nicht, einfache SAMBA Freigaben reichen mir vollkommen.
d.h. du willst samba direkt auf proxmox installieren? kann man natürlich auch machen, ich wollte bloss die funktionalitäten getrennt haben.

die platten sind ok solange "reallocated", "uncorrectable" und "pending" schön auf 0 bleiben.
 
  • Gefällt mir
Reaktionen: Lenny88
Ja genau, zu dem Thema gibt es ja auch im Netz sehr "hitzige" Diskussionen. Viele lehnen es ja auch grundsätzlich ab ein System wie TrueNAS o.ä. zu virtualisieren - da ich ein System wie TrueNAS aber nicht benötige, stellt sich mir die Frage so nicht.
Da Proxmox ja auf einem Debian basiert habe ich dort einfach Samba installiert.
 
@0x8100
ich würde das die Tage gerne angehen mit dem sparse file/degraded Pool.
Normalerweise würde ich den Poll gerne über die Proxmox GUI anlegen - ich habe das gestern zum Testen einfach mal mit einer externen Platte gemacht um auch Samba etc. zu testen. Funktioniert soweit.
Ich denke das wird dann ja aber nicht funktionieren, oder? Proxmox wird den Spare file ja nicht als Laufwerk in der Liste zur Auswahl anbieten denke ich? Wenn ich nun das den ZFS Pool über die Shell anlegen muss, kann ich ihn später trotzdem in der GUI sehen und verwalten? Bin kein Linux Profi ;-)
 
Ich bin zwar kein Proxmox experte habe aber schon einige Erfahrung mit ZFS daher gebe ich mal auch meinen Senf dazu ;)

Das mit den Degraded RaidZ1 (RAID5) funktioniert ist aber ggf. nicht die optimale Lösung.
Du reisst ein riesiges "Write Hole" mit einem Degraded RAID. Wenn während es Ursprünglichen Kopierens oder der RAID 5 Syncronisation etwas schief geht sind die Daten korrumpiert ...
Außerdem kostet RAID 5 etwas an performance - obwohl in der Praxis ist das vernachlässigbar.
Mit Mirrored (RAID1) kann man die parität mit ZFS Boardmitteln auch noch zu einem Späteren Zeitpunkt erstellen.


Andere Alternativen sind das Zeitweise auslagern der Daten auf eine andere (z.B Externe) Platte.
--> Würde ich auch unbedingt als Backup empfehlen

Zwei weitere ZFS Tipps:
  • Verwende niemals die Deduplikation (auch nicht mal kurz zum Test)! Die Performace des gesammten Pools geht in die knie bzw der Ram verbrach wird wahnsinnig!
  • Verwende unbedingt die ZSTD Komprimierung!
zfs set compression=zstd pool/system
bzw. wenn (Schreib)Geschwindigkeiteine Untergeordnete Rolle spielt
zfs set compression=zstd-19 pool/system

Und ein allgemeiner Rat: Ich würde für eine bessere Trennung die Dateifreigabe auch in einer VM machen. es muss nicht gleich TrueNAS sein
Nextcloud bieteteine menge wirklich nützlichen Funktionen (z.B syncronisation, Dropbox/GD/AmazonD integration) die ich nicht mehr missen möchte. Am besten in ner VM ausprobieren und ggf Daten dorthin verschieben :D
 
Zuletzt bearbeitet: (compression befehl korrigiert)
  • Gefällt mir
Reaktionen: Lenny88
@crossblade

Danke für deine Antwort. Könntest du auf das nachträgliche hinzufügen der Parität etwas näher eingehen?
Eine kurze Google Recherche sagt mir, das dies eigentlich nicht möglich sein sollte.
Wenn ich einen mirrored Pool erstelle fehlt habe ich doch halbe Kapazität bei zwei Platten oder?! Bei Raid0 hätte ich ja noch verstanden dass man nachträglich die Parität ergänzen könnte.
 
Gerne gehe ich darauf ein ;) Aber das Wesentliche hast du schon verstanden.
Bei Mirrored geht immer die Hälfte der Kapazität für die Redudanz verloren.
Mit 3 HDDs macht es auch keinen sinn - außer vielleicht als hot spare für einen verband.....

Bei ZFS kann man ganz einfach einen Pool auf nur einer Festplatte anlegen zum Beispiel für sda und sdb
Ich gebe hier noch gleich einen ashift an falls die Festplatte lügt und in Wahrheit 4k Sektoren unter der habe hat (haben die meisten neueren platten).
zpool create -o ashift=12 pool /dev/sda
dann gleich dass passende Dateisystem drauf (hier mal optimiert für Speichereffizenz nicht Geschwindigkeit)
zfs create compression=zstd-19 recordsize=1M atime=off pool/data
für schlecht/inkompremierbare Daten wie Filme aber besser
zfs create compression=zstd atime=off pool/data
Dann kannst du ganz entspannt die Daten von einer anderen HDD auf die Quelle kopieren.
Anschließend kannst du die zweite HDD als Mirror (also RAID1) zur ersten hinzu fügen:
zpool attach pool /dev/sda /dev/sdb
Dann wird aus der einzelplatte ein Mirror.

Die dritte Platte kannst du dann als weiteren Pool anlegen und darauf Backups ablegen.
Denn RAID ersetzt kein backup!
Dann kannst du mit zfs-send die daten ganz einfach lokal backupen

Und ganz wichtig: Mache ein Backup aller wichtigen Daten vor jeglichen Versuchen am Dateisystem!!!
Kein Datenrettungunternehmen kann die überschriebenen Daten nach einem vollständigen Resilvering wieder herstellen. Ich spreche da leider aus unglücklicher Erfahrung - zwei Festplattennamen falschrum angegeben und die Daten waren weg. Betrachte am besten alle nicht gebackupten Daten als gelöscht ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tr0nism
@crossblade

Danke, aber ich glaube da besteht ein Missverständnis von dem, was ich mir vorstelle. Ich möchte einen Pool aus 3x3 TB mit 6 TB nutzbarer Kapazität erstellen, so dass grundsätzlich erst mal eine Platte ausfallen kann, ohne das Daten verloren gehen. Das ganze soll als ein großes Volume erscheinen und nicht als separate Platten.
Ich weiß das ersetzt kein Backup, beim Großteil der Daten ist es aber auch nicht schlimm, sollte dieser Fall eintreten.
Die wirklich wichtigen Daten (ca. 200 GB) werden dann als tatsächliches Backup auf dem Gaming PC gespiegelt und zusätzlich auf externer Platte gesichert.

Daher ist deine Lösung glaube ich nicht, was ich suche.
 
So da es hier keine weiteren Antworten gibt und nach etwas Recherche doch relativ entschieden davon abgeraten wird ein "degraded" Raid zu erstellen und nach dem Befüllen die 3. Platte hinzuzufügen bleibt mir, wenn ich es so umsetzen will, wohl nur der Kauf einer weiteren 3 TB Platte (im Bekanntenkreis hat keiner eine ausreichend große Platte frei).

Wenn ich aber eh eine neue Platte besorgen müsste stellt sich mir die Frage, ob ich den Aufwand überhaupt betreibe oder doch direkt eine z.B. 6 TB Platte besorge, die mir an Platz mehr als ausreicht und dann im NAS nur ein Laufwerk (ggf. trotzdem mit ZFS) einsetze.

Ist es aus eurer Sicht vorteilhafter ein RaidZ-1 mit 3x3 TB einzusetzen oder 1x6 TB Single Drive ZFS? Parität wäre natürlich nicht gegeben, aber mindestens 1x 3 TB für das Backup der wichtigsten Daten würde ich eh behalten und die Ausfallwahrscheinlichkeit wäre bei 3 Platten ja höher als bei einer.
Zudem würde ich mir Bastelarbeiten ersparen, da mein Gehäuse eigentlich nur Platz für 2x 3,5" und 1x 2,5" bietet.
Dafür wäre es natürlich teurer als nur 1x 3 TB zu besorgen.

Was meint ihr dazu? ZFS Pool mit Parität va. Single Drive ZFS?
 
Kann mir vielleicht noch einer was zu meinem letzten Post sagen? Werde mir jetzt wohl ne 6 TB Platte besorgen, bin mir aber unschlüssig ob nun 3 im RaidZ-1 oder eben die eine große besser in den Server wandert?

Ich tendiere aktuell dazu, die 6tb extern als Backup zu nutzen und in meinem Gaming PC gar keine mehr einzubauen. Da würde dann auch der 6 TB Pool drauf passen, oder benötigt der wegen Parität als Backup dann auch 9 TB?
 
Zuletzt bearbeitet:
Es gab zwar keine weiteren Reaktionen mehr, trotzdem möchte ich euch über meine schlussendliche Vorgehensweise Bescheid geben, vllt. hilft es ja irgendwem.

Nach intensiver Recherche habe ich mich gegen ZFS mit RaidZ-1 entschieden und auf eine Ext4 Formatierung + MergerFS gesetzt.

Gründe:
  • Parität ist mir nicht wichtig - wie beschrieben handelt es sich zum Großteil um nicht wichtige Daten die auch mal ein paar Tage nicht zur Verfügung stehen können und die restlichen muss ich auch trotz Parität separat sichern
  • MergerFS kommt mit unterschiedlichsten und bereits befüllten Platten zurecht und kann sie zu einem Pool zusammenfassen
  • Die Daten auf den Platten bleiben durch MergerFS grundsätzlich unangetastet - im Notfall lässt sich eine Platte einfach ausbauen und eigenständig weiterverwenden
  • MergerFS lässt sich so steuern, dass es Daten anhand der bereits angelegten Pfade auf die Platten ablegt
  • ich kann grundsätzlich auf die Platten einzeln zugreifen, in Kombination mit dem vorherigen Punkt kann ich also gezielt wichtige Daten auf eine Platte speichern und diese auf eine externe Platte klonen
  • Performance viel besser als mit NTFS vorher

Durch diese Entscheidung konnte ich einfach die beiden 3 TB Platten im NAS nacheinander löschen und mit Ext4 neu formatieren. Vorgehensweise war also Platte1 Ext4 formatieren, Daten von NTFS Platte2 auf Platte 1 spiegeln. Platte2 auf Ext4 Formatieren und Daten von 3 TB Backup Platte3 auf Platte2 spiegeln.

Ich habe nun im NAS 2x3 TB Ext4 Platten, in einer externen Docking Station 2x3 TB Backup NTFS Platten (davon eine wie beschrieben nicht mehr so vertrauenswürdig ;-) ).
Die wichtigen Daten werden zudem noch auf die interne SSD meines Gaming Rechners gesichert (max. 100 GB).
 
  • Gefällt mir
Reaktionen: Homie2009
statt ext4 hätte man vielleicht noch btrfs für die einzelnen platten nehmen können, damit man mittels checksummen kaputte daten zumindest noch mitbekommt. nicht dass dir korrupte daten mit ins backup wandern.
 
hatte ich kurz drüber nachgedacht, aber bei meinen (zugegebenermaßen kurzen) Recherchen habe ich des öfteren negative Erfahrungen gelesen, wodurch bei mir irgendwie das Gefühl von "Beta" Status aufkam.
Ich denke, mit Ext4 bin ich auf Linux zumindest schon mal besser unterwegs als NTFS ;-)
 
Zurück
Oben