[Sammelthread] ZFS Stammtisch

Code: 
zpool import
no pools available to import

und

Code: 
zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
rpool   222G   167G  54.7G         -    21%    75%  1.00x  ONLINE  -

Auch habe ich auf local-ZFS einige virtuelle Disks, die ich gerne löschen möchte. Über die Webgui geht das nicht (Entfernen ist ausgegraut). Wie lösche ich diese?

edit:

Code: 
zpool get all rpool
NAME   PROPERTY                    VALUE                       SOURCE
rpool  size                        222G                        -
rpool  capacity                    56%                         -
rpool  altroot                     -                           default
rpool  health                      ONLINE                      -
rpool  guid                        7553587338168940999         default
rpool  version                     -                           default
rpool  bootfs                      rpool/ROOT/pve-1            local
rpool  delegation                  on                          default
rpool  autoreplace                 off                         default
rpool  cachefile                   -                           default
rpool  failmode                    wait                        default
rpool  listsnapshots               off                         default
rpool  autoexpand                  off                         default
rpool  dedupditto                  0                           default
rpool  dedupratio                  1.00x                       -
rpool  free                        96.7G                       -
rpool  allocated                   125G                        -
rpool  readonly                    off                         -
rpool  ashift                      12                          local
rpool  comment                     -                           default
rpool  expandsize                  -                           -
rpool  freeing                     0                           default
rpool  fragmentation               18%                         -
rpool  leaked                      0                           default
rpool  feature@async_destroy       enabled                     local
rpool  feature@empty_bpobj         active                      local
rpool  feature@lz4_compress        active                      local
rpool  feature@spacemap_histogram  active                      local
rpool  feature@enabled_txg         active                      local
rpool  feature@hole_birth          active                      local
rpool  feature@extensible_dataset  enabled                     local
rpool  feature@embedded_data       active                      local
rpool  feature@bookmarks           enabled                     local
rpool  feature@filesystem_limits   enabled                     local
rpool  feature@large_blocks        enabled                     local

autoexpand ist deaktiviert. Wie kann ich das aktivieren?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
bisl selber denken könnt nicht schaden...

zpool get autoexpand rpool
liefert den Zustand
zpool set autoexpand=on rpool
aktiviert das Flag
 
bevor ich was kaputt mache, frage ich nach :)
ausserdem habe ich "zpool get all rpool" ja selbst erdacht ;)

wie kann man herausfinden, ob compression aktiviert ist? zpool get compress rpool?
 
Zuletzt bearbeitet:
das geht mit
zfs get compression rpool
bzw.
zfs get compression rpool/filesystem

setzen mit set compression=on | off | lzjb | gzip | gzip-[1-9] | zle | lz4
 
okay danke :) Dass man es aktivieren soll, weiß ich mittlerweile. Nur auf was?

edit: war schon aktiviert
 
Zuletzt bearbeitet:
Ich habe jetzt 2 napp-it Hosts (Fileserver + Backupserver) am laufen und würde gerne meine ZFS Filesysteme des Fileservers auf dem Backupserver speichern.

Autosnaps auf dem Fileserver hab ich eingestellt. Wenn ich jetzt in Napp-it einen Replications Job starte, werden dann eigene Snapshots erstellt für den Replications Job?

Um noch sicher zu gehen: Der Replications Job ist schon ein richtiges Backup wie mit ZFS send / receive?
 
Autosnaps kann man nur auf dem Fileserver, nicht auf dem Backupsystem machen.
Grund: Bei einer inkrementellen Replikation wird das Ziel Dateisystem per rollback auf den gleichen Stand wie der letzte Quellsnap zurückgesetzt. Eventuell danach angelegte Snapshots gehen dabei verloren.

Napp-it sorgt daher dafür, dass man Replikationssnaps per Jobpameter behalten kann, z.B. letzte n Snaps, letzte n Tage oder in der aktuellen Version ein Snap jeweils je letzte n Stunden/Tage/Monate/Jahre.

Replikation ist inkrementelles zfs send > zfs receive übers Netzwerk um beide Dateisysteme identisch zu halten.
 
Hallo Zusammen,


kann mir einen von euch sagen, wie ich es schaffe, ein SunOS 5.11 oi_151a9 May 2015 auf ein OI Hipster zu bringen ?
Alle Versuche sind bisher gescheitert.

Danke und Gruß,

_xymos.

Edit:

ich habe den publisher geändert. ( Hipster - OpenIndiana - OpenIndiana Wiki )


Aktuell bricht der upgrade Prozess aber immer mit diesen Fehlermeldungen ab.

pkg update: Folgende Pakete stellen widersprüchliche Aktionstypen in usr/lib/amd64/libgomp.so.1 bereit:

link:
pkg://opensolaris.org/developer/gcc/gcc-libgomp@4.3.3,5.11-0.133:20100306T002124Z
file:
pkg://openindiana.org/system/library/gcc-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101449Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Folgende Pakete stellen Aktionen des Typs file für usr/lib/libgcc_s.so.1 bereit:

pkg://opensolaris.org/developer/gcc/gcc-libgcc@4.3.3,5.11-0.133:20100306T002102Z
pkg://openindiana.org/system/library/gcc-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101449Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Folgende Pakete stellen Aktionen des Typs file für usr/lib/amd64/libgfortran.so.3.0.0 bereit:

pkg://openindiana.org/system/library/gfortran-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101439Z
pkg://opensolaris.org/developer/gcc/gcc-libgfortran@4.3.3,5.11-0.133:20100306T002113Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Folgende Pakete stellen Aktionen des Typs file für usr/lib/libssp.so.0.0.0 bereit:

pkg://openindiana.org/system/library/g++-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101714Z
pkg://opensolaris.org/developer/gcc/gcc-libssp@4.3.3,5.11-0.133:20100306T002146Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Folgende Pakete stellen widersprüchliche Aktionstypen in usr/lib/libgomp.so.1 bereit:

link:
pkg://opensolaris.org/developer/gcc/gcc-libgomp@4.3.3,5.11-0.133:20100306T002124Z
file:
pkg://openindiana.org/system/library/gcc-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101449Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Aufgrund der angeforderten Änderung am System wird versucht, mehrere Aktionen
für link 'usr/lib/libstdc++.so.6' mit widersprüchlichen Attributen zu installieren:

1 Paket stellt 'link path=usr/lib/libstdc++.so.6 target=libstdc++.so.6.0.10' bereit:
pkg://opensolaris.org/developer/gcc/gcc-libstdc@4.3.3,5.11-0.133:20100306T002156Z
1 Paket stellt 'link path=usr/lib/libstdc++.so.6 target=libstdc++.so.6.0.20' bereit:
pkg://openindiana.org/system/library/g++-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101714Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Folgende Pakete stellen Aktionen des Typs file für usr/lib/amd64/libssp.so.0.0.0 bereit:

pkg://opensolaris.org/developer/gcc/gcc-libssp@4.3.3,5.11-0.133:20100306T002146Z
pkg://openindiana.org/system/library/g++-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101714Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Folgende Pakete stellen Aktionen des Typs file für usr/lib/amd64/libgcc_s.so.1 bereit:

pkg://openindiana.org/system/library/gcc-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101449Z
pkg://opensolaris.org/developer/gcc/gcc-libgcc@4.3.3,5.11-0.133:20100306T002102Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Folgende Pakete stellen Aktionen des Typs file für usr/lib/libgfortran.so.3.0.0 bereit:

pkg://openindiana.org/system/library/gfortran-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101439Z
pkg://opensolaris.org/developer/gcc/gcc-libgfortran@4.3.3,5.11-0.133:20100306T002113Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.

Aufgrund der angeforderten Änderung am System wird versucht, mehrere Aktionen
für link 'usr/lib/amd64/libstdc++.so.6' mit widersprüchlichen Attributen zu installieren:

1 Paket stellt 'link path=usr/lib/amd64/libstdc++.so.6 target=libstdc++.so.6.0.10' bereit:
pkg://opensolaris.org/developer/gcc/gcc-libstdc@4.3.3,5.11-0.133:20100306T002156Z
1 Paket stellt 'link path=usr/lib/amd64/libstdc++.so.6 target=libstdc++.so.6.0.20' bereit:
pkg://openindiana.org/system/library/g++-4-runtime@4.9.4,5.11-2017.0.0.1:20170315T101714Z

Diese Pakete dürfen nicht zusammen installiert werden. Sofern die Pakete nicht widersprüchlich sind, dürfen
sie gemeinsam installiert werden. Andernfalls müssen die Pakete vor der Installation berichtigt werden.
 
Zuletzt bearbeitet:
Hat jemand Omnios / napp-it unter Proxmox in Betrieb?
Ich habe seit Jahren einen ESXi-Server mit Omnios und ZFS-Storage mit napp-it im Einsatz. Auf dem ESXi läuft auch eine VM mit durchgereichter DVB-S-Karte als TV-Server. Nach der Erweiterung von 2 auf 4 Tuner habe ich nun mit der Sat-Karte bzw. den zusätzlichen Tunern Probleme mit der Stabilität. Geplant ist daher, mal die Variante "Proxmox" mit dem TV-Server im LXC zu testen.
Gibt es zur genannten Kombination unter Proxmox hier Erfahrungswerte, insb. zum Durchreichen der Hostadapters? Omnios unter ESXi wird ja reichlich diskutiert, zu Proxmox / KVM konnte ich aber nicht so viel finden...
 
Ein andere (mögliche) Variante wäre, wenn du omnios als reines Storage OS nutzt (ZFS) deinen bisherigen pool nativ unter proxmox zu importieren und dort nutzen (ZFSonLinux).
Sollte eigentlich problemlos funktionieren. Am besten vorher nochmal in der ZoL mailing list nachhaken mit Angaben deiner jetztigen omnios version, zpool config etc.
 
Ah, gut zu wissen; danke. Hatte die letzten Tage mit Corral rumgespielt. Damit bleibts bei mir erstmal bei mir Nas4free.
 
bogomil22 schrieb:
Ein andere (mögliche) Variante wäre, wenn du omnios als reines Storage OS nutzt (ZFS) deinen bisherigen pool nativ unter proxmox zu importieren und dort nutzen (ZFSonLinux).
[...]
Zum Vergrößern anklicken....
Danke, das hatte ich mir auch schon überlegt - dann könnte ich sogar ein paar Watt Strom sparen, weil ich die internen SATA-Ports anstelle des LSI-Adapters verwenden könnte. Allerdings habe ich mich sehr an napp-it gewöhnt und würde das ungern wieder hergeben...
 
negotiator schrieb:
Danke, das hatte ich mir auch schon überlegt - dann könnte ich sogar ein paar Watt Strom sparen, weil ich die internen SATA-Ports anstelle des LSI-Adapters verwenden könnte. Allerdings habe ich mich sehr an napp-it gewöhnt und würde das ungern wieder hergeben...
Zum Vergrößern anklicken....

Ja, napp-it für debian (ZoL) wäre spitze. Ein vergleichbares zfs webinterface für linux fällt mir nicht ein. Genau die überlegung mit dem weglassen des HBA Adapters hatte ich auch. Meine frage wäre hier ob es später, falls man auf omnios oder ähnliches wechselt und einen HBA einsetzen muss, dies mit dem vordanenen pool problem funktioniert? Sprich erstellen des zpool auf internen sata ports, export, hba einsetzen, platten vom internen sata an hba, import. ?!
 
Zuletzt bearbeitet:
Napp-it gibts ja für Linux -
allerdings nur mit der Grundfunktionalität ZFS, Snap und Jobmanagement.

Die restlichen Funktionen um eine komplette Storage Appliance zu realisieren - und da steckt der eigentliche Aufwand drin - gibts nur für die Solarish Version. Diese Funktionen werde ich nie nach Linux portieren, einerseits weil vieles unter Solaris so viel einfacher ist und da ganz einfach tut ohne was zu konfigurieren oder zu installieren. Oracle oder Illumos liefern und pflegen halt eigene iSCSI, NFS und SMB Storagedienste die perfekt mit ZFS und dem OS harmonieren. Linux im Vergleich ist da eine Baustelle und Baukasten ohne Ende mit all den verschiedenen Distributionen, Ideen und Diensten.
 
Hallo zusammen,

da ich jetzt über 10 Monate meinen Fileserver mit Napp It im Einsatz habe, möchte ich diesen Ausbauen und einen "über eine Netzwerksteckdose zuschaltbaren" zweiten Pool als Backup Medium nutzen.

Dazu habe ich mir Zrep => zrep - zfs based replication and failover system angeschaut.

Nun zu meiner Frage wie bekomme ich das Script eingebunden ?

Kann mir jemand behilflich sein ?

Danke
 
ich habe 10 Festplatten a 2TB: Soll ein reiner "Backup-Server" werden, eine 1:1 Kopie eines bestehenden Servers mit ZFS. Gewissensfrage RaidZ1 oder Z2?? Ich brauche eigentlich die 18 TB netto... Wichtiges kommt zusätzlich auf USB-Medien
 
Als Backup reicht eigentlich ein Raidz1, da die Originaldaten ja auf dem andeem Sys vorhanden bleiben.
- Das Backupsys sollte ja nur während des Backups laufen (Einschalten kann man scriptgesteuert via IPMI oder WOL, Herunterfahren ebenfalls scriptgesteuert)

ABER: Wenn eine Mehrgenerationensicherung gefahren wird, gehen die im Falle eines Ausfalls des Raidz1 natürlich verloren, die Wahrscheinlichkeit ist bei einem Raidz1 aus 10 HDDs relativ hoch >> ein Raidz2 wäre hier die bessere Variante!
 
Jemand ne Ahnung warum der Replikationsjob mit napp-it nicht ausgeführt wird? Geht hier um einen SSD Pool auf dem die meisten VMs des Hosts liegen. Den HDD Pool kann ich problemlos replizieren.

Screen Shot 2017-04-17 at 14.38.17.jpg
 
Auf dem Backupserver wird ein zfs receive gestartet.
Auf dem Fileserver wird versucht remote einen snapshot anzulegen und per zfs send übers Netzwerk zu schicken.

Der Receiver meldet "failed to read from stream" da zfs send den Snapshot nicht öffnen kann
da es das Dateisystem ssdpool oder den Snapshot _nr1 nicht gibt

Ist das Dateisystem ssdpool denn vorhanden, hat genau diesen Namen und es gibt Platz für Snapshots?
Eventuell den Job löschen und nochmal anlegen.
 
gea schrieb:
Auf dem Backupserver wird ein zfs receive gestartet.
Auf dem Fileserver wird versucht remote einen snapshot anzulegen und per zfs send übers Netzwerk zu schicken.

Der Receiver meldet "failed to read from stream" da zfs send den Snapshot nicht öffnen kann
da es das Dateisystem ssdpool oder den Snapshot _nr1 nicht gibt

Ist das Dateisystem ssdpool denn vorhanden, hat genau diesen Namen und es gibt Platz für Snapshots?
Eventuell den Job löschen und nochmal anlegen.
Zum Vergrößern anklicken....

Danke für den Input, Speicher des Pools war voll, dementsprechend konnte auch kein Snapshot erstellt werden. Hab vergessen die alten VMDKs zu löschen...
 
Hallo,
ich habe eine schnelle Frage:
Wenn ich einen ZFS Pool mit (vorerst) einer HDD erstelle und darauf in FreeNAS Datensätze anlege, kann ich dann noch nachträglich eine exakt gleich große HDD hinzufügen und spiegeln?

Viele Grüße
 
sollte man irgendwelche Wartungsarbeiten bei ZFS durchführen alá scrub oder so?
 
Durch die Ende zu Ende Prüfsummen (OS->Treiber->HBA->Kabel, Backplane -> Platte) nicht nur der Metadaten sondern auch der eigentlichen Daten erkennt ZFS zuverlässig beim Lesen jeden eingetretenen Schaden. Falls Redundanz vorhanden ist wird der Fehler auch sofort repariert (Selbstheilung) bzw eine fehlerhafte Platte aus dem Pool entfernt. Sofern man eine Hotspare Platte hat, wird diese automatisch ersetzt.

Manchmal ist es aber hilfreich so früh wir möglich über mögliche Probleme informiert zu werden. ZFS-Scrub beispielsweise liest alle Daten und verifiziert deren Prüfsumme. Dadurch werden mögliche Dateifehler gefunden und repariert. Dateifehler können zwar ab und an von alleine auf dem Storage passieren (Silent Errors, Datenrost), eine größere Anzahl derartiger Fehler ist aber ein Indiz auf ein Hardwareproblem.

Genau so verhält es sich mit iostat das Treiberprobleme (soft/hard/transfer errors) seit dem letzten Start protokolliert. Nehmen die plötzlich zu ist das ein Indiz für mögliche künftige Probleme. Auch die Smartmontools können manchmal frühzeitig über Plattenprobleme informieren.
 
Ist die Datenintegrität am Ziel eigentlich gewährleistet/abgesichert, wenn ich ein Snap von Maschine A nach B per ZFS send/receive über Netcat schicke?

Hatte letzte Woche den Effekt, dass ich mehrere Snaps von meiner Produktivmaschine zum Backupserver verschickt hatte, Ausgangssnaps waren völlig intakt. Beim Empfang eines der Snaps hatte ich zuerst 2-3* Abbruch wg. Checksum-Fehlern auf der Empfängerseite (und entsprechend natürlich auch Abbruch des Sendens), bei dann nochmal wiederholtem Send/Receive war kein Abbruch mehr. Die anderen Snaps liefen problemlos beim ersten Mal.
Insofern hab ich mir nix dabei gedacht ausser "ah ok. Fehler is weg, passt".

Am nächsten Tag hatte dieses eine betroffene Snap dann bei 6-7 Files Datacorruption auf der Backupmaschine. Alle anderen Snaps auf der Maschine sind unauffällig. Ist mir nur dadurch aufgefallen, da ich den Pool auf der Produktivmaschine platt gemacht und neu aufgesetzt hatte und dann vom Backup die Snaps wieder zurückschieben wollte. Beide Pools waren RAIDZ2.

Resilvern ging nicht mehr, die Fehler blieben. Vor dem Plattmachen auf der Produktivmaschine hab ich die Backups nicht nochmal geprüft, weil ich dachte "ist ja alles abgesichert, kann kein Fehler vorhanden sein".
Am Ende ist nix passiert, weil die betroffenen Files a ) mehrfach vorhanden waren und b ) es nur etwas ältere Backups von VM-Images waren die ich jederzeit wieder Backuppen kann.

Aber jetzt bin ich natürlich etwas beunruhigt bzgl. Zuverlässigkeit solcher Aktionen und wo die Fehlerquelle gewesen ist.
- Im LAN kann doch eigentlich nichts passieren, bei Übertragungsfehler müssten korrupte Pakete doch neu übertragen werden.
- ZFS send/receive müsste doch auch gesichert sein., oder?
- Macht es bzgl. Datenintegrität einen Unterschied mit SSH statt Netcat? (läuft alles nur innerhalb Wohnungs-LAN, Verschlüsselung daher nicht notwendig)
- RAM als Feher schliesse ich aus, beide Maschinen sind Xeons mit ECC-Ram.
= > kann doch IMO eigentlich nur am Backup-Server _nach_ dem Erhalt des betroffenen Snaps was passiert sein, was mehr als 2 Platten betroffen hat und die Daten noch nicht committed waren.
 
Zuletzt bearbeitet:
Bei der Übertragung greift alles was tcp/ip an Sicherheitsmassnahmen bereitstellt. Darüberhinaus ist zfs send ein Datenstream eines Snapshots. Sind die Daten mit Prüfsummen versehen, so sollte ein Übertragungsfehler auch damit erkannt werden. Letztendlich bietet zfs send auch Prüfsummen, siehe Do I need to md5sum replicated data? (Oracle Storage Ops)

Ein Fehler der durch zfs send/receive erzeugt wird ist also extrem unwahrscheinlich. Netcat oder SSH macht da auch keinen Unterschied. SSH verschlüsselt die Daten lediglich auf Kosten der Performance.

Wenn mehrere Fehler dann auf dem Storage entdeckt werden ist das Problem eher bei Platten, Verkabelung, Backplane, PSU, RAM etc zu suchen. ZFS Z2 kann die Fehler reparieren sofern nicht meht als zwei Platten betroffen sind. Sind mehr Platten betroffen, kann es aber auch sein dass die Daten auf der Platte valide sind und die Fehler bei der Übertragung Platten -> OS auftreten.

Gewissheit hätte man wenn man den Pool in einen Server einbaut der keine Probleme zeigt.
 
Zuletzt bearbeitet:
Die nächste OmniOS 151022 long term stable edition (vorraussichtlich als final June 2017) gibts als Public-Beta
ReleaseNotes/r151022


Update von der jetzigen OmniOS 151020 stable erfolgt mittels
- Umswitchen des omnios Repository auf die neue Version
- Update
- Reboot

Am Einfachsten gehts mit Putty als root. Da kann man die Befehle per Maus-Rechtsklick (Copy/paste) einfügen

Code: 
pkg unset-publisher omnios
pkg set-publisher -P --set-property signature-policy=require-signatures -g package repository omnios
pkg update
reboot

Das setup erzeugt ein Bootenvironment, man kann also zurück


Update von älteren OmniOS Versionen
https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux OmniOS Update


napp-it

Vor dem Update muss man napp-it auf eine April 2017 Version updaten
Ein älteres napp-it ist nicht kompatibel (Tty Problem des Perl module Expect)


Sonstige Probleme

Ich hatte ein Loader Problem unter VMware. Bei der Installation per ISO 151021 oder einem Reboot
geht das System in den maintenance Modus. Nach einem ctrl-d geht es aber weiter.

Unter ESXi 6.5 wird dabei ein Refresh der Web-Console ausgelöst.
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
981
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
649
sandreas
S
AG1M
[Kaufberatung] Neuer ZFS Homeserver
Antworten
16
Aufrufe
782
pwnbert
pwnbert
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
579
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
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