[Sammelthread] ZFS Stammtisch

dstockm schrieb:
Ok. Ich habe mich aus Kostengründen vorerst für die USB-Variante entschieden. HBA, Gehäuse, Backplane das sind ja locker 300€... Falls jemand eine Idee hat wie ich das günstiger umsetzen kann, bin ich für Vorschläge dankbar.
...
Viele Grüße
Dirk
Zum Vergrößern anklicken....

So USB-Variante ist einfach zu instabil gewesen. Wie immer zeigt sich: Am besten doch gleich richtig...
Habe nun einen gebrauchten M1015 (35€) und ein gebrauchtes Rackmax RM-324 (25€).

Nach der Aktion mit dem vorübergehend nicht verfügbaren Pool im Server und dem dadurch erhöhten Risikobewußtsein hinsichtlich der alten Platten im Backupserver, habe ich meinen Backupserver mit 3 neuen 10TB Ironwolf ausgestattet. Den Pool mit den alten Platten hatte ich exportiert. Sie sollen nun das Off-Site-Backup werden. Die sind ja bereits per Replikationsjob befüllt - das spart mir eine Neubefüllung.

Also die alten 3 Platten in die RM-324 eingebaut, Pool import und schon wieder Probleme (s.u.).
Dass nun alle drei Platten 'ne Macke haben dürfte genauso unwahrscheinlich sein, wie vor einem Monat bei meinem Server:
https://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-380.html#post26878621

Wie ist denn das korrekte Vorgehen, wenn OmniOS meint da gäbe es einen Fehler? Ich hatte das zwischendurch auch mal bei einer der USB-Platten. Zu früh abgestöpselt und von da an wurde mir die mit I/O Error gelistet.
Das muss man doch irgendwie "zurücksetzen" können.
fmadm sagt alles ok. Ich glaube ich bin zu blöd...

Code: 
root@backupserver:~# zpool import
   pool: tank
     id: 5183899436177886595
  state: FAULTED
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
   see: http://illumos.org/msg/ZFS-8000-5E
 config:

        tank                     FAULTED  corrupted data
          c0t5000C5007ACF0BDAd0  FAULTED  corrupted data
          c0t5000C500AFE03558d0  FAULTED  corrupted data
          c0t50014EE2B3C9E872d0  FAULTED  corrupted data


root@backupserver:~# zpool import -F tank
cannot import 'tank': one or more devices is currently unavailable
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Den Pool Fehlerstatus kann man mit Menü Pools > clear (zpool clear pool) löschen.
Das hilft aber nur wenn die Platten ansonst in Ordnung sind.

Wenn der Fehler Management Dienst ein defektes Device entdeckt, nimmt er es aus dem System.
Rücksetzen kann man das im Menu System > Faults > repair

Wenn die Platten IDs nicht stimmen (meist mit Sata) hilft ein Export + Import

Hier in diesme Fall würde ich im Menü Disks schauen, ob die Platten erkannt werden.
Dann ausschalten und Verkabelung prüfen (Strom, Sata/SAS, Backplane), booten und erneut import versuchen.

Dann an einem anderen Conroller anschließen z.B. Sata
 
gea schrieb:
Den Pool Fehlerstatus kann man mit Menü Pools > clear (zpool clear pool) löschen.
Das hilft aber nur wenn die Platten ansonst in Ordnung sind.

Wenn der Fehler Management Dienst ein defektes Device entdeckt, nimmt er es aus dem System.
Rücksetzen kann man das im Menu System > Faults > repair

Wenn die Platten IDs nicht stimmen (meist mit Sata) hilft ein Export + Import

Hier in diesme Fall würde ich im Menü Disks schauen, ob die Platten erkannt werden.
Dann ausschalten und Verkabelung prüfen (Strom, Sata/SAS, Backplane), booten und erneut import versuchen.

Dann an einem anderen Conroller anschließen z.B. Sata
Zum Vergrößern anklicken....

Die alten Platten werden angezeigt. Sie hängen jetzt nur am SAS-Controller und der Backplane anstatt am internen SATA, da sind nun die Neuen dran.

Der Controller und die Backplane funktionierten bei einem ersten Test mit einer einzelnen anderen, alten Platte. Allerings habe ich nur einen Schacht ausprobiert. Ich konnte dort einen neuen Pool erstellen.
Ich kann die Platten natürlich testweise wieder an den SATA hängen, aber mehr als Import+erneuter Export kann ich dann ja auch nicht machen. Exportiert hatte ich den Pool bevor ich die Platten aus dem System genommen habe.

Allerdings dauert das Booten mindestens 10 Minuten. Irgendwo klemmt's also noch, ich weiß nur nicht wo. Im Log-0 ist kein Eintrag von heute.
Export+Import geht nicht, weil ja bereits vor dem Plattentausch der alte Pool exportiert war. zpool clear geht deswegen auch nicht. "fmdam faulty" gibt keine Meldung aus. Ich habe bei allen Platten "repaired" ausprobiert: "not known to be faulty".




Code: 
 id                         	 part  	 identify  	 stat  	 diskcap  	 partcap  	 error  	 vendor  	 product  	 sn 
 c0t5000C5007ACF0BDAd0  	 single  	 via dd   	 ok  	    	 8 TB  	  S:0 H:0 T:0  	 ATA  	 ST8000AS0002-1NA  	 Z8402F0A 
 c0t5000C500AFE03558d0  	 single  	 via dd   	 ok  	    	 8 TB  	  S:0 H:0 T:0  	 ATA  	 ST8000AS0002-1NA  	 Z8417BWG 
 c0t50014EE2B3C9E872d0  	 single  	 via dd   	 ok  	    	 4 TB  	  S:0 H:0 T:0  	 ATA  	 WDC WD40EFRX-68W  	 WDWCC4E0170785 


root@backupserver:~# zpool clear tank
cannot open 'tank': no such pool
root@backupserver:~# zpool clear -F tank
cannot open 'tank': no such pool
root@backupserver:~# zpool import -F tank
cannot import 'tank': one or more devices is currently unavailable
root@backupserver:~# fmadm repaired c0t50014EE2B3C9E872d0
fmadm: failed to record repair to c0t50014EE2B3C9E872d0: specified resource is not known to be faulty


EDIT:
Wie letztes Mal: Ich habe Platten an den anderen Server gehängt. Import ging dort problemlos. Export, dann wieder umbauen und nun ging auch der Import im Backupserver.

Beim Export und Import auf dem gleichen System, aber mit evtl. veränderten Anschlüssen/Controllern, klappt das irgendwie nicht.
Ich habe vorhin testweise jeweils nur eine der 3 Platten im System gehabt. zpool import hat dann etwas in der Art angezeigt:
Code: 
        tank                
          c0t5000C5007ACF0BDAd0
          c1t1d0
          c1t3d0

Sprich das System wußte noch, dass die beiden fehlenden Platten zuletzt (ohne Fehler) an den SATA-Ports liefen. Dort hängen nun aber die neuen dran...
Das muss also irgendwo gespeichert sein und beim Export nicht vollständig gelöscht werden.
 
Zuletzt bearbeitet:
Wie verhält es sich mit den scrub Jobs. Werden diese im Standard von selbst bei auftretenden Fehlern etc. ausgeführt, oder muss da der Anwender per Job selbst Sorge für tragen?
Wie oft sollte solch ein scrub Job im besten Falle ausgeführt werden?
 
Die Scrubs erfolgen regelmäßig nach Zeitablauf und nicht „anlassbezogen“. Ich hab bei meinen HDD-Datengräbern das 1x im Monat gemacht und zwar nach einem ebenso regelmäßigen Snapshot auf dem Pool.

Etwaige bei einem Scrub auftauchende Daten-Fehler werden dann beim Scrub-Run automatisch korrigiert. Wirft ein Scrub Fehler, ist nähere Beobachtung und Ursachenforschung angesagt.

Edit: standardmäßig werden die m.W. in keinem OS ausgeführt, sondern müssen einmalig konfiguriert werden.
 
dstockm schrieb:
Sprich das System wußte noch, dass die beiden fehlenden Platten zuletzt (ohne Fehler) an den SATA-Ports liefen. Dort hängen nun aber die neuen dran...
Das muss also irgendwo gespeichert sein und beim Export nicht vollständig gelöscht werden.
Zum Vergrößern anklicken....

Ein zpool destroy oder export löscht den Pool aus dem Gedächtnis des Betriebssystems (/etc/zfs/zpool.cache). Da man den Pool in beiden Fällen wieder importieren kann, bleiben die Infos wie die Platten aus denen der Pool besteht auf den Platten besteht.

Ein zpool import liest dann alle Platten, zeigt importierbare Pools und deren beteiligte Platten an sowie den Status dieser Pools.
 
Leider etwas Off-Topic, welches OS würde denn sowohl ZFS vernünftig unterstützen als auch mit QDR Infiniband Adaptern zurechtkommen?
Interessant wäre auch die Unterstützung von NVME devices zumindest als SLOG.
Wie gut ist denn mittlerweile ZFS unter Linux?
 
gea schrieb:
Ein zpool destroy oder export löscht den Pool aus dem Gedächtnis des Betriebssystems (/etc/zfs/zpool.cache). Da man den Pool in beiden Fällen wieder importieren kann, bleiben die Infos wie die Platten aus denen der Pool besteht auf den Platten besteht.

Ein zpool import liest dann alle Platten, zeigt importierbare Pools und deren beteiligte Platten an sowie den Status dieser Pools.
Zum Vergrößern anklicken....
Ja das verstehe ich. Nur warum lassen sie sich mit dem einen, "unbekannten" System ohne Pribleme importieren und mit dem anderen "bekannten" nicht?
Ich werde da mal ein wenig herumprobieren um es näher einzugrenzen.
 
Wenn es an einem Kontroller geht und an einem anderen nicht ist vermutlich der Kontroller, die Verkabelung oder die Backplane das Problem.
 
besterino schrieb:
Edit: standardmäßig werden die m.W. in keinem OS ausgeführt, sondern müssen einmalig konfiguriert werden.
Zum Vergrößern anklicken....

Da ich grade auf FreeNAS gewechselt bin und dort schon ein Scrub Task definiert war, hab ich mal in die Doku geschaut:

"By default, Scrub Tasks are run once a month by an automatically-created task. S.M.A.R.T. Tests and Periodic Snapshot Tasks must be set up manually."
 
Na guck' mal, wieder was gelernt. :) Hab' selbst keine hands on Erfahrung mit FreeNAS.
 
Scrub sollte man bei Desktop Platten häufiger machen als bei Enterprise Platten. Ein Scrub alle 1-3 Monate würde ich bei Desktop Platten als üblich sehen. Wie oft und vor allem wann man das macht, hängt auch von der Situation ab. Ein Scrub erzeugt ja durchaus eine Menge Last, kann viele Stunden dauern und kosted in der Zeit Performance. Bei einem Produktivsystem sollte das daher in einer low use Zeit z.B. am Wochenende erfolgen. Bei einem Cold-Archiv/Backup Storage sollte man das auch machen - mindestens jährlich besser halbjährlich.

Ansonsten ist es ja so. ZFS wertet bei jedem Lese-Zugriff die Prüfsummen der Daten und Metadaten aus. Wird ein Datenfehler - warum auch immer entdeckt, repariert ZFS den on the fly beim Lesen (selbstheilendes Dateisystem). Ein Scrub macht gleiches, liest aber alle Dateien, nicht nur die gerade aktiven. Das Scrub dient daher vorzugsweise dazu, größere Probleme frühzeitig zu erkennen bevor die Fehlerrate auf dem Pool so hoch wird, dass auch die ZFS Redundanz nicht mehr zum Reparieren ausreicht.
 
Moin,

ich habe eine Verständnisfrage zu den ACL in Verbindung mit nfs und smb. Für NFS gehe ich für meinen Fall bei gea's oftmals formulierter Meinung des sicheren Netzes mit. Da habe ich kein Problem die Shares mit @everyone and meine Linux-Clients durchzureichen, da die gewünschten Einschränkungen auf den Clients geregelt werden. Nun möchte ich aber die selben Shares mit smb für Windows-Clients in einer Workgroup bereitstellen. Und dort soll eben nicht jeder alles sehen. Was ist für diese Konstellation der sinnvollste Ansatz?
 
Zuletzt bearbeitet:
gea schrieb:
Wenn es an einem Kontroller geht und an einem anderen nicht ist vermutlich der Kontroller, die Verkabelung oder die Backplane das Problem.
Zum Vergrößern anklicken....
An der Hardware liegt es m.M. nach nicht.
Zum Wiederbeleben des Pools mussten die Platten ja nur temporär woanders importiert und exportiert werden. Danach habe ich sie wieder dort angeschlossen wo sie zuvor nicht liefen und dann funktionierte es auf Anhieb.
Im Moment kann ich es aber nicht mehr nachstellen bzw. erzwingen. Ich habe die Ports und auch die Controller vertauscht. Selbst bei Einbau in USB-Gehäuse hat es funktioniert.

Nun ja, jetzt habe ich 2 vollständige Backups und die persönlichen Daten noch ein 3. Mal gesichert. Das sollte wohl reichen.[emoji16]
 
Ich erstelle von einer Ubuntu-VM täglich eine Sicherung mit XSIBackup und schreibe diese in ein ZFS-Dataset, welches ich per NFS an ESXi durchgereicht habe. Für dieses Dataset habe ich in napp-it eine tägliche Snapshot-Erstellung eingerichtet.

Allerdings belegen die Snapshots jeweils die volle Größe:

Code: 
NAME                                                   USED  AVAIL  REFER  MOUNTPOINT
tank/backup_vms@daily-1556454795_2019.04.28.14.45.14  14.5G      -  14.5G  -
tank/backup_vms@daily-1556454795_2019.04.29.06.00.14  14.7G      -  14.7G  -
tank/backup_vms@daily-1556454795_2019.04.30.06.00.15  14.8G      -  14.8G  -
tank/backup_vms@daily-1556454795_2019.05.01.06.00.14  14.9G      -  14.9G  -
tank/backup_vms@daily-1556454795_2019.05.02.06.00.14  15.2G      -  15.2G  -
tank/backup_vms@daily-1556454795_2019.05.03.06.00.15      0      -  15.3G  -

Ist es in dieser Konstellation aussichtslos, zu erwarten, dass nur die geänderten Blöcke zusätzlichen Platz verbrauchen?

Dieser Beitrag hört sich für mich so an, als wenn das grundsätzlich möglich sein müsste:

you schrieb:
Mehrgenerationen-Backups mache ich jetzt aber nicht mehr mit XSIBACKUP. Da ist die job-basierte ZFS Snapshot-Funktion von napp-it ungleicher einfacher, schneller und, ganz wichtig, im zusätzlichen Datenkonsum gegen null gehend. Top.
Zum Vergrößern anklicken....
 
Das sind doch nur die Größen des betroffenen Dateisystems, oder? Schau dir mal die Größen bei den Snaps an.
 
Das ist die Ausgabe von zfs list -t snapshot, also sollte es sich um Größe der Snapshots handeln. Oder verstehe ich dich falsch?
 
Der durch einen Snap belegte Platz steht in "used" und da steht ca 15G je Snap.
Ist aber auch klar. Die Größe eines Snaps entspricht den geänderten Daten. Wenn man zwischen den Snaps je 15G draufkopiert...

Lösen könnte man das durch dedup da die Daten ja weitgehend gleich sind. Das schafft aber andere Problem - auch nicht gut..

Ich würde ganz einfach das Dateisystem auf dem die VMs liegen snappen. Deren Unterschied/ Größe dürfte minimal sein. Man kann dann auch ganz einfach per Rollback, Copy oder Windows "vorherige Version" und SMB auf einen früheren Stand des Dateisystems und der VM gehen.

Das einzige was ein Backupprogramm für ESXi mehr kann, ist dass es die VM anhält und/oder den Speicherstand der VM einfriert. Ein einfacher ZFS Snap ist ja wie Strom ausschalten. Das kann man aber einfach dadurch lösen, indem man vor dem ZFS Snap manuell oder per Script (napp-it autosnap kann das auch) einen ESXi Snap anlegt und dennach dem ZFS Snap anschließend löscht.

Bei einem Rollback kann man dann in ESXi auf den Hotsnap gehen. Da es im normalen Betrieb keine ESXi Snaps gibt hat man auch nicht deren Performance Probleme.
 
Hi zusammen,

Ich hab ein Problem unter ZOL in Ubuntu. Hab die VM ubuntu im ESXI.
Leider verliert ein mirror Pool jedesmal die Zuordnung der Festplatten. Quasi bei jedem Neustart. Die anderen Pools bleiben bestehen.

Hat jemand eine Idee woran das ganze liegen kann?
 
Moin Moin zusammen,

ich habe in Napp-IT mehrere SMB freigaben die auf unterschiedlichen WD-Red Platten liegen. Da mir langsam der Platz ausgeht muss ich Dateien umkopieren. Wie kann ich unter Napp-IT dies am einfachsten lösen ohne das ich den Weg über den SMB-Share gehen muss. Das würde bei einer befüllten 3TB Platte gefühlte ewigkeiten dauern. Kann ich nicht intern unter Napp-IT Daten kopieren/verschieben?

Vielen Dank für eure Unterstützung für einen Unwissenden....
Fiesta26
 
Was spricht dagegen, dass du dich per SSH verbindest und die Dateien über die Kommandozeile umkopierst? :) Alternativ kann man sicherlich auch ein Tool wie WinSCP einsetzen, wenn eine GUI besser gefällt.
 
Die drei Hauptmethoden zum lokalen Kopieren (nicht übers Netz) dürften sein

- Unix Kopier Befehl cp auf der Konsole

- napp-it und einen Datamover definieren (Menü ZFS Dateisysteme)
interessant aber eher für wiederkehrende Aktionen

- midnight commander auf der Konsole
Nach dem Start per mc hat man zwei Fenster zwischen denen man Daten kopieren/verschieben kann

Ich würde die letzte Variante bevorzugen und mc als root starten.
 
Ein Phänomen, das ich mir nicht erklären kann

...aber vielleicht hat hier ja jemand eine Erklärung.

Ich betreibe einen alten HP N36L als Backupserver. Den fahre ich etwa 1x wöchentlich hoch und das System (OmniOS) SYSPOOL liegt auf 2 mirrored 32GB USB-Sticks, da ich die Schächte für die 3,5" Backup-Platten brauche.

Letzte Woche gab es bei einem "zpool status" folgende Ausgabe:

Code: 
        NAME          STATE     READ WRITE CKSUM
        syspool       DEGRADED     0     0     0
          mirror-0    DEGRADED     0     0     0
            c2t0d0s0  DEGRADED     0     0     0  too many errors
            c4t0d0s0  FAULTED      0     0     0  corrupted data

Nun, da hab ich mal testweise einen weiteren 32GB USB-Stick eingestöpselt und mit

Code: 
fdisk -B c3t0d0p0
prtvtoc /dev/rdsk/c2t0d0s0 | fmthard -s - /dev/rdsk/c3t0d0s0
zpool attach -f syspool c4t0d0s0 c3t0d0s0
installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t0d0s0

daraus einen 3-way mirror gemacht.

Nach dem Resilver ergab "zpool status":

Code: 
  pool: syspool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: resilvered 5.69G in 0h37m with 14 errors on Sun May  5 13:36:25 2019
config:

        NAME          STATE     READ WRITE CKSUM
        syspool       DEGRADED     0     0     0
          mirror-0    DEGRADED     0     0     0
            c2t0d0s0  ONLINE       0     0     0
            c4t0d0s0  FAULTED      0     0     0  corrupted data
            c3t0d0s0  ONLINE       0     0     0

errors: 12 data errors, use '-v' for a list

Anschließend habe ich die beiden ursprünglichen USB-Sticks abgezogen und neu gestartet. Eigentlich wollte ich damit nur testen, ob der neu eingerichtete Stick auch sauber bootet. Das tat er, aber als ich erneut einen "zpool status" eingegeben habe, hat mich das Ergebnis erstaunt:

Code: 
  pool: syspool
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sun May  5 14:22:08 2019
    213M scanned out of 5.69G at 2.51M/s, 0h37m to go
    6.86M resilvered, 3.66% done
config:

        NAME          STATE     READ WRITE CKSUM
        syspool       DEGRADED     0     0     0
          mirror-0    DEGRADED     0     0     0
            c2t0d0s0  UNAVAIL      0     0     0  cannot open
            c4t0d0s0  UNAVAIL      0     0     0  cannot open
            c3t0d0s0  ONLINE       0     0     0  (resilvering)

errors: No known data errors

Wie kann ein pool resilvern, wenn dazu keine Datenquellen mehr verfügbar sind (es hängt ja nur noch ein Stick im Server)?

EDIT: Die Property "copies" steht übrigens auf 1. Möglicherweise würde das ja eine Erklärung sein, wenn diese auf > 1 stehen würde.
 
Zuletzt bearbeitet:
Ganz unsinnig ist das nicht.

Einerseits ist das jetzt sowas wie ein Zwangs-Scrub, andererseits stehen ja die Metadaten immer noch doppelt zur Verfügung. Ein Fehler in den Matadaten könnte also trotz copies=1 gefunden und repariert werden.
 
rigel schrieb:
Was spricht dagegen, dass du dich per SSH verbindest und die Dateien über die Kommandozeile umkopierst? :) Alternativ kann man sicherlich auch ein Tool wie WinSCP einsetzen, wenn eine GUI besser gefällt.
Zum Vergrößern anklicken....

Vielen Dank!
Dagegen spricht meine Kenntnisse über die Kommandozeile. Per SSH ein loggen und verbinden geht dann noch, aber beim hin/her Kopieren von Dateien hört es defintiv auf. Habe WinSCP mal getestet, auf die Shares kann ich zugreifen über root, jedoch habe ich dann auf der linken Seite nur den lokalen Rechner....?!?

gea schrieb:
Die drei Hauptmethoden zum lokalen Kopieren (nicht übers Netz) dürften sein

- Unix Kopier Befehl cp auf der Konsole

- napp-it und einen Datamover definieren (Menü ZFS Dateisysteme)
interessant aber eher für wiederkehrende Aktionen

- midnight commander auf der Konsole
Nach dem Start per mc hat man zwei Fenster zwischen denen man Daten kopieren/verschieben kann

Ich würde die letzte Variante bevorzugen und mc als root starten.
Zum Vergrößern anklicken....

Auch dir vielen Dank, ebenfalls hier hören meine Kommandozeilen-Kenntnisse aber auf.... gibt es den keine anderen Methoden um das Kopieren über das Netzwerk zu verneiden?
 
gea schrieb:
Ganz unsinnig ist das nicht.

Einerseits ist das jetzt sowas wie ein Zwangs-Scrub, andererseits stehen ja die Metadaten immer noch doppelt zur Verfügung. Ein Fehler in den Matadaten könnte also trotz copies=1 gefunden und repariert werden.
Zum Vergrößern anklicken....

OK, dass die Metadaten immer doppelt (unabhängig von "copies") da sind, das hatte ich nicht auf dem Schirm. Nach ein wenig Rumprobiererei bin ich zu dem Schluss gekommen, das System ganz neu zu installieren. Denn ein "zpool detach" um die beiden ursprünglichen USB-Sticks auszuhängen klappt nicht, da gibt es dann z. B. die Meldung "cannot detach c4t0d0s0: no valid replicas". Ein "zpool clear syspool" löst genauso wie jeder Reboot sofort einen erneuten Resilver aus. Sieht nach einer "Endlosschleife" aus, da kann ich die Sticks auch gleich grillen :-)

Aber Danke trotzdem für Deinen Hinweis.
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
689
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
394
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
422
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
8K
gea
G
G
[Übersicht] Windows NAS mit Web-Gui, SMB direkt, (Tiered) Storage Spaces, ReFS (und ZFS)
2
Antworten
48
Aufrufe
2K
gea
G
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh