[Sammelthread] ZFS Stammtisch

[Kurzschluss[A]]

Mein System besteht im Detail aus
- Gigabyte mc12 le0
- AMD ryzen 4350 GE
- 1x32 GB Kingston ECC RAM 3200 mhz
- 1xKingston dc600m 960gb Systemplatte
- 2x seagate Ironwolf 4 TB 5900rpm

Ist so ein Backup denn grundsätzlich möglich ohne eine Festplatte händisch jedes Mal Anstecken zu müssen?
Und dass sie nur für den Zweck des Backups läuft und dannach selbstständig in den Standby geht ? Festplatte dafür per USB oder Ethernet in einem eigenen Gehäuse untergebracht

 

[sandreas]

Im Prinzip, einfach eine externe Platte mit einem ZFS Pool auf einer einzelnen Platte anstecken (SAS,Sata,USB),
dann Pool importieren und ein Replikationsjob manuell starten.

Ob man dazu ein eigenständiges Script oder die Replikationsfunktion von napp-it oder TrueNAS nimmt, ist egal
Anschließend (ganz wichtig) den Pool exportieren und die Platte dann erst abstecken.

@Kurzschluss[A]
Ich habe ein Script dazu geschrieben. Das schaltet via Tasmota Steckdose eine externe Festplatte an und synchronisiert alle ZFS snapshots, die auf dem USB Zielvolume (`rpoolbak`) noch nicht vorhanden sind rüber. Anschließend wartet es 5 sekunden, exportiert rpoolbak und schaltet die Tasmota-Steckdose wieder ab.

Achtung: Das ganze setzt einen Pool auf der USB-Platte mit Namen `rpoolbak` voraus, läuft ohne Rückfrage und ist sehr stark für meine eigenen Zwecke optimiert. Es geht nur um das Prinzip - ich würde das keinesfalls einfach für ein Produktivsystem so ohne Anpassung übernehmen.
Das tool `pv` dient übrigens zur Überwachung des Fortschritts und der Geschwindigkeit - man kann das weglassen, aber grade für die ersten Versuche ist das sehr nützlich.
Die Befehle in den Kommentaren am Anfang sind teilweise einfach nützlich gewesen und haben mit dem Script nicht zwingend was zu tun.

Unterm Strich geht es um diese beiden Befehle hier:

# sende den gesamten pool bis zum angegebenen Snapshot auf die externe Festplatte (Vollbackup)
zfs send --raw -R "rpool@backup-2024-01-01" | pv | zfs recv -Fdu "rpoolbak"

# Oder sende alles zwischen zwei snapshots (inkrementell)
zfs send --raw -RI "rpool@backup-2024-01-01" "rpool@backup-2024-01-02" | pv | zfs recv -Fdu "rpoolbak"

Wichtig ist, dass die Snapshots von Quelle und Ziel sich zeitlich nicht unterscheiden dürfen. Erstellst du also auf der USB-Festplatte einen Snapshot, der auf dem Quellpool nicht existiert, klappt das Backup so nicht mehr. Da ich zfs-auto-snapshot verwende, nutze ich daher ein ZFS property (`zfs set com.sun:auto-snapshot=false`) um automatische Snapshots auf `rpoolbak` zu vermeiden.


Das ganze script:

#!/bin/sh
SRC_POOL="rpool"
DST_POOL="rpoolbak"
TASMOTA_HOST="http://192.168.1.193"


DATE="$(date +%F)"
BACKUP_PREFIX="backup-"
NEW_SNAP_NAME="$BACKUP_PREFIX$DATE"
NEW_POOL_SNAP="$SRC_POOL@$NEW_SNAP_NAME"

# destroy all backups and start with a fresh full backup
# zpool destroy rpoolbak
# zpool create rpoolbak /dev/sdb

# list all snapshots
# zfs list -H -o name -t snapshot -r rpoolbak
# zfs list -H -o name -t snapshot -r rpoolbak | xargs -n1 zfs destroy

# destroy datasets recursively
# zfs destroy -R -f rpoolbak/ROOT

# control tasmota power switch
# curl http://192.168.1.193/cm?cmnd=POWER+TOGGLE

echo "starting backup $NEW_POOL_SNAP"

echo "switching on tasmota: $TASMOTA_HOST"
curl "$TASMOTA_HOST/cm?cmnd=POWER+ON"
echo ""

# import destination pool, but do not mount
LAST_IMPORT_POOL="$(zpool list -o name | tail -1)"
if ! [ "$LAST_IMPORT_POOL" = "$DST_POOL" ]; then
    echo "importing $DST_POOL in 30 seconds..."
    sleep 30
    zpool import -N "$DST_POOL"
fi

LAST_IMPORT_POOL="$(zpool list -o name | tail -1)"
if ! [ "$LAST_IMPORT_POOL" = "$DST_POOL" ]; then
    echo "ERROR: failed to import $DST_POOL"
    exit 1
fi

# disable auto-snapshot for destination pool, if not done
DST_POOL_AUTO_STATE="$(zfs get com.sun:auto-snapshot $DST_POOL -o value | tail -1)"
# echo "zfs-auto-snapshot state for $DST_POOL: $DST_POOL_AUTO_STATE"
if ! [ "$DST_POOL_AUTO_STATE" = "false" ]; then
    echo "disabling zfs-auto-snapshot for $DST_POOL"
    zfs set com.sun:auto-snapshot=false "$DST_POOL"
fi
# create daily snapshot, if not exists
DAILY_SRC_SNAP="$(zfs list -H -o name -t snapshot "$SRC_POOL" | grep "@$NEW_SNAP_NAME")"
if [ "$DAILY_SRC_SNAP" = "" ]; then
    echo "creating backup snapshot: $NEW_POOLSNAP"
    zfs snapshot -r "$NEW_POOL_SNAP"
fi

# check last snapshot, that has been synced
LAST_DST_SNAP="$(zfs list -H -o name -t snapshot "$DST_POOL" | grep "@$BACKUP_PREFIX" | tail -1 | cut -d '@' -f 2)"
if [ "$LAST_DST_SNAP" = "" ]; then
    echo "no existing snapshot found, full backup required"
    # no existing snapshot, full send
    # zfs send -R --raw "$SRC_POOL@$NEW_SNAP_NAME" | pv | zfs recv -Fdu "$DST_POOL"

    zfs send --raw -R "$SRC_POOL@$NEW_SNAP_NAME" | pv | zfs recv -Fdu "$DST_POOL"
else
    BACKUP_FROM_SNAPSHOT="$SRC_POOL@$LAST_DST_SNAP"
    BACKUP_UNTIL_SNAPSHOT="$SRC_POOL@$NEW_SNAP_NAME"

    if [ "$LAST_DST_SNAP" = "$NEW_SNAP_NAME" ]; then
        echo "backup snapshot already exists on target, skipping"
    else
        echo "newest existing snapshot found: $SRC_POOL@$LAST_DST_SNAP"
        echo "incremental backup $BACKUP_FROM_SNAPSHOT -> $BACKUP_UNTIL_SNAPSHOT"
        # zfs send -RI --raw "$SRC_POOL@$LAST_DST_SNAP" "$SRC_POOL@$NEW_SNAP_NAME" | pv | zfs recv -Fdu "$DST_POOL"
        zfs send --raw -RI "$BACKUP_FROM_SNAPSHOT" "$BACKUP_UNTIL_SNAPSHOT" | pv | zfs recv -Fdu "$DST_POOL"
    fi
fi

echo "exporting pool and power off tasmota in 5 seconds..."
sleep 5
zpool export "$DST_POOL" && sleep 5 && curl "$TASMOTA_HOST/cm?cmnd=POWER+OFF"
echo ""
echo "done"

 

[you]

Ist so ein Backup denn grundsätzlich möglich ohne eine Festplatte händisch jedes Mal Anstecken zu müssen?

Ich habe ein OmniOS NAS mit hotplug-fähigen Festplatteneinschüben.

Eine verschlüsselte Backup-Platte A ist immer mit drin und auf diese wird per napp-it nächtens per Job repliziert.

Eine weitere, verschlüsselte Backup-Platte B habe ich separat im Haus liegen. Die schiebe ich so alle x Wochen rein und repliziere dann das Delta vom letzten Mal auf diese zweite Platte. Grund: Falls mir das NAS zerbröselt, habe ich wenigstens eine Kopie separat im Haus.

Als drittes mache ich von meinen wichtigsten Daten regelmäßig mittels Duplicati ein verschlüsseltes Offsite-Backup auf meine Hetzner Storage Box. Grund: Falls mir das Haus zerbröselt, habe ich noch einen letzten Strohhalm in der Cloud.

 

[gea]

Mein System besteht im Detail aus
- Gigabyte mc12 le0
- AMD ryzen 4350 GE
- 1x32 GB Kingston ECC RAM 3200 mhz
- 1xKingston dc600m 960gb Systemplatte
- 2x seagate Ironwolf 4 TB 5900rpm

Ist so ein Backup denn grundsätzlich möglich ohne eine Festplatte händisch jedes Mal Anstecken zu müssen?
Und dass sie nur für den Zweck des Backups läuft und dannach selbstständig in den Standby geht ? Festplatte dafür per USB oder Ethernet in einem eigenen Gehäuse untergebracht

Es gibt zwei Arten von Datensicherung

1. Alltagsbackup
Da geht es darum, einen Plattenausfalll zu überstehen oder versehentlich gelöschte Dateien zurückzuholen oder den Stand vor einem Ransomware Angriff. Im einfachsten Fall reicht da gute Raid-Redundanz wo eine Platte ausfallen darf, bei kritischen Daten sollten zwei Platten ausfallen dürfen (Z2, 3way Mirror), dazu readonly Versionierungen der Daten mit ZFS Snaps (stündlich, behalte 24, täglich behalte 7, wöchentlich... usw). Dann hat man gute Chancen Daten wiederherzustellen auch für ältere Datenstände.

2. Disasterbackup
Diebstahl, Blitzschlag, Feuer, Amokhardware, Sabotage oder menschliche Fehler ist damit nicht abzudecken. Dazu brauchts externes offine Backup. Eine Backupplatte die noch am Rechner hängt selbst stromlos nützt nichts. Wenn man also nicht an anderem Ort ein Backupsystem hat, dann sollte man die Backupplatte abstecken und sicher lagern z.B im Safe. Für Backupplatten empfiehlt sich copies=2 und Features zu deaktivieren damit man relativ sicher vor den kürzlich aufgedeckten Open-ZFS Bugs zumindest unter Linux ist. Solaris und Illumos ist ist da etwas beständiger.

 

[sandreas]

@gea

Schön zusammen gefasst. Neben dem automatischen Script gibt es noch eins, was meinen Docker-Mount auf eine ext4 Platte sichert (nach dem ZFS Disaster war mir reines ZFS irgendwie auch nicht mehr 100% geheuer

dazu readonly Versionierungen der Daten mit ZFS Snaps (stündlich, behalte 24, täglich behalte 7, wöchentlich... usw).

Das lässt sich übrigens unter Proxmox (und vielen anderen Systemen) hervorragend mit dem Paket

zfs-auto-snapshot

lösen. Damit kann man sogar über einen Umweg SMB Shares so einstellen, dass man unter Windows bequem über die Versionshistorie snapshots zurückrollen kann (siehe auch das Projekt Zamba Server vom Bashclub).

Dazu brauchts externes offine Backup.

Meine allerwichtigsten Daten brenne ich mir hin und wieder mal auf eine Bluray, weil Ransomware-Sicher (die schönsten Kinderfotos, Steuerunterlagen, etc.) und lagere diese dann nach einer Integritätsprüfung in einem anderen Haushalt.
Ich habe auch mal über ein revisionssicheres Cloud-Backup nachgedacht, aber dafür ist die Menge an WIRKLICH WICHTIGEN Daten mir noch zu klein

 

[asche77]

Eine Nebenwirkung des neuen Perl Releases in 151050.
Behoben in allen aktuellen Versionen: About > Update mit Download sollte das Problem beheben

Update gemacht auf 22.03d, jetzt gibt's eine neue Fehlermeldung:

Betreff: Cron <root@omniosce>

perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/auto.pl Tty.c: loadable library and perl binaries are mismatched (got first handshake key 12400080, needed 12a80080)

 

[gea]

Die Meldung kommt vom Perl Modul Expect. Sollte eigentlich nicht auftreten (Habs gerade bei mir getestet, da gehts).
Das richtige Perl Modul wird beimersten Login geladen, also auch nach update. Gehts denn nach Logout/Login?

 

[asche77]

Das richtige Perl Modul wird beimersten Login geladen, also auch nach update. Gehts denn nach Logout/Login?

Reboot half nicht, Login hat aber offenbar geholfen. Danke!

 

[Kurzschluss[A]]

Danke an alle für eure Beiträge zum Thema automatisierte Backups. Ich bin mir nach wie vor unschlüssig was wohl die richtige Basis für mich ist... Proxmox und truenas vm oder truenas direkt

 

[you]

Tipp: Einfach ausprobieren. Am Ende kommt es immer auf den eigenen Geschmack an. Wenn Du hier fragst, bekommst Du am Ende eh alle möglichen Kombinationen angeboten 😁

Ich habe Proxmox als Hypervisor und fürs NAS OmniOS/napp-it. Beides Spezialisten auf ihrem Gebiet. Beide in Minuten wieder herstellbar. Letzteres habe ich schon einige Male machen (müssen) 😊

Truenas empfinde ich als eierlegende Wollmichsau - ähnlich Nextcloud/HomeAssistant. Da weiß ich nie so genau, was da im Hintergrund so alles passiert und in welchen Dateien, welche Konfigurationen abgelegt werden, auf die ich im Havariefall ja wieder zurückgreifen müsste. Daher meide ich solche Allrounder.

 

[gea]

Reboot half nicht, Login hat aber offenbar geholfen. Danke!

Napp-it soll copy and run sein und das bei einer Reihe von Server Betriebssystemen inkl. Up und Downgrade zwischen verschiedenen napp-it und OS Versionen. Dazu liefere ich alles mit was jeweils benötigt wird. Beim Login wird dann geprüft was aktuell gebraucht wird. Bei einem Update ohne Login können falsche Module z.B. bei cron Jobs der vorherigen OS Umgebung benutzt werden so wie hier.

Die Alternative wäre eine Liste von Programmen und Modulen die man selbst installieren muss oder die Beschränkung auf ein OS mit einer bestimmten Umgebung.

Beitrag automatisch zusammengeführt: 10.05.2024

Ich beschäftige mich gerade wegen napp-it cs mit den unterschiedlichsten ZFS Plattformen mit SMB Sharing und deren Management. Den "ZFS tut einfach und ist pflegeleicht" Eindruck von Solaris und Illumos insbesondere mit dem in da ins OS und ZFS eingebauten SMB Server vermisse ich bei den anderen Optionen stets aufs neue. Free-BSD 14 erscheint mir bei ZFS neben Solaris/ Illumos am stabilsten. Bei den Linux Optionen empfinde ich Proxmox als Linux der Wahl. Das ist zwar auf Virtualisierung optimiert, ist aber auch als Storageplattform eine perfekte Wahl wenn es primär um einfaches ZFS Storage z.B. für NFS oder SMB geht und man "komplexere" Dienste in VMs auslagert. Dafür brauchts dann auch keine Storage VM wenn man bei LInux mit SAMBA SMB bleiben möchte. Nach einem apt install samba hat man alles was man braucht. Lediglich die Proxmox GUI ist für ZFS Mamagement noch zu wenig ausgebaut. Da braucht man dann entwder CLI Kenntnisse rund um zfs und zpool oder als Ergänzung eine der ZFS Gui Optionen.

Proxmox sehe ich daher als die eierlegende Wollmichsau, sehr flexibel und ohne große Scwächen egel ob es um Virtualisierung oder ZFS Basis Storage geht.

 

[sandreas]

Proxmox sehe ich daher als die eierlegende Wollmichsau

Ich bin mir nach wie vor unschlüssig was wohl die richtige Basis für mich ist...

Ich habe auch viel mit den verschiedenen Möglichkeiten rumprobiert und bin dann nach OpenMediaVault, TrueNAS Core und TrueNAS Scale wieder bei Proxmox gelandet. Meine Begründung war, dass ich mit Virtualisierung wesentlich mehr machen muss, als mit Storage. Einmal eingerichtet und der Storage läuft bei mir fast unverändert weiter. Aber VMs verwalten und Anlegen mach ich öfter mal.

Ich habe mich dann dazu entschieden, SMB per LXC im Docker nachzurüsten, läuft bisher sehr stabil, keine Probleme. Alternativ kann man den Hauptstorage (pool / datasets) auch mit Proxmox verwalten und OpenMediaVault über VM oder LXC nachrüsten, damit man ne GUI für Samba oder NFS hat.

Proxmox ist aber nix für Anfänger, da muss man sich schon ein paar Tage (Minimum) reindenken.

 

[Sakura_Kira]

Ich habe auch viel mit den verschiedenen Möglichkeiten rumprobiert und bin dann nach OpenMediaVault, TrueNAS Core und TrueNAS Scale wieder bei Proxmox gelandet. Meine Begründung war, dass ich mit Virtualisierung wesentlich mehr machen muss, als mit Storage. Einmal eingerichtet und der Storage läuft bei mir fast unverändert weiter. Aber VMs verwalten und Anlegen mach ich öfter mal.

Ich habe mich dann dazu entschieden, SMB per LXC im Docker nachzurüsten, läuft bisher sehr stabil, keine Probleme. Alternativ kann man den Hauptstorage (pool / datasets) auch mit Proxmox verwalten und OpenMediaVault über VM oder LXC nachrüsten, damit man ne GUI für Samba oder NFS hat.

Proxmox ist aber nix für Anfänger, da muss man sich schon ein paar Tage (Minimum) reindenken.

Bin grad vieles am testen und interessant ist OMV mit Proxmox Kernel. Aber ich bin mir noch nicht ganz klar was als Nächstes kommt.

 

[besterino]

Ich hab mein Solaris 11.4 (mit napp-it) mit "pkg update" auf den aktuellen Stand gebracht (weil ich musste, um einen pool von einem aktuellen Solaris zu importieren). Seitdem spammt mich aber der Main-Screen mit folgender Dauer-Fehlermeldung (schneller als Sekundentakt) zu:

Was soll ich dagegen tun? Konfigurationsdatei löschen (welche?) oder das Modul neu installieren (wie?)? Bin für alle weiterführenden Informationen dankbar.

 

[gea]

Ich würde mal schauen ob man mit den tipps der Google Gemini KI oder Bing KI weiterkommt
"wie kann ich folgende konsole warnungen in solaris 11.4 unterdrücken sudo : libpam ignoring missing legacy entry /usr/lib/security//64/pam_dhkeys.so.1 in /etc/pam.d/other!

 

[sandreas]

Ich würde mal schauen ob man mit den tipps der Google Gemini KI oder Bing KI weiterkommt

Ist es nicht das?

Solars 11.4 OS upgrade breaks authentication, users cannot login. Install the supported version 4.1.7.23754 prior to upgrading the Solaris OS to 11.4 (4249363)

After upgrading to the Solaris OS from 11.3 to 11.4 with a version of Authentication Services older than 4.1.7.23754 users can no longer 4249363

support.oneidentity.com

Scheint die Datei /usr/lib/security/pam_authtok_common zu sein, die ist nicht "Standard".

 

[besterino]

@sandreas: klingt ähnlich, aber ich hab von schon von 11.4 aus das Update laufen lassen, nicht von 11.3. Werde evtl. trotzdem mal mein Glück in der Richtung versuchen.

@gea: verwendet napp-it das irgendwie?

 

[gea]

Das einzige was napp-it benötigt, ist ein funktionierendes sudo mit Anpassung der /etc/sudoers

 

[besterino]

Hmmm... das komische ist, es funktioniert anscheinend alles, werde eben nur extrem zugespammt. Gerade läuft leider ein längerer replication Job, den will ich ungern unterbrechen. Danach schau' ich mal. Oder setze einfach das System neu auf.

 

[gea]

oder einfach mal die pam datei /etc/pam.d/other kontrollieren.

Eventuell das Modul pam_dhk. auskommentieren oder schauen warum ein ungültiger Pfad benutzt wird (/usr/lib/security//64/..). Damit kann das Modul nicht gefunden werden.

 

[besterino]

Ich hab mein Solaris 11.4 (mit napp-it) mit "pkg update" auf den aktuellen Stand gebracht (weil ich musste, um einen pool von einem aktuellen Solaris zu importieren). Seitdem spammt mich aber der Main-Screen mit folgender Dauer-Fehlermeldung (schneller als Sekundentakt) zu:

Anhang anzeigen 998063

Was soll ich dagegen tun? Konfigurationsdatei löschen (welche?) oder das Modul neu installieren (wie?)? Bin für alle weiterführenden Informationen dankbar.

Vorläufige Lösung: in /etc/pam.d/other die Zeile auth required pam_dhkeys.so.1 auskommentiert.

#auth required          pam_dhkeys.so.1

Verhindert zumindest den error-Spam. Mal beobachten, ob sonstige Themen aufpoppen.

 

[HisN]

Hehe ja auf ARM mit 2 GB läuft ZFS zwar aber naja das ist halt mehr was man so mal aus Spass macht um zu schauen ob es überhaupt geht

Die Frage wird hier ja oft gestellt. Aber scheinbar eher zu den alten langsamen Modellen mit wenig RAM. Jedenfalls kam mir das bei den Ergebnissen der Sufu so vor.
Hat jemand das schon mit eineem Pi 5 und 8GB RAM versucht?
Ich bin ja der Null-Checker wenn es um ZFS geht, aber mir ist gerade langweilig und einen Pi5/8GB mit 4-Fach NVMe-Head (16TB) wäre doch ganz witzig. So könnte ich ich meinen Horizont erweitern und was lernen.
Oder lieber bei den alteingesessenen Filesystemen bleiben?

 

[gea]

ZFS bietet eine Datensicherheit die von "alteingesessenen" Dateisystemen nichtmal annähernd erreicht wird. Es nutzt dazu Prüfsummen auf Daten und Metadaten (mehr Daten) und Copy on Write (nochmal mehr Daten und höhere Fragmentierung). Daten werden dazu gleichmäßig über einen Pool verteilt. Das ergibt relativ konstante Performance auch bei seht vielen Dateien und Nutzern. Das kostet Performance da man auf Platten iops mehr angewiesen ist als auf sequentielle Plattenleistung und da schwächeln mechanische Platten. Ausgleichen kann man das durch den überragenden Schreib/ Lesecache in ZFS und dafür braucht man den RAM in erster Linie. Bei NVMe Storage ist das nicht so wichtig. Der ist auch ohne Cache Unterstützung schnell.

4GB sollte man aber schon haben und eine 64bit CPU

 

[HisN]

Danke Dir, das hört sich doch ganz gut an.
Dann fange ich mal an zu experimentieren und schaue wie weit ich komme.

Der Pi5 ist 64 bit und OS inzwischen auch

 

[mrpasc]

Hat jemand das schon mit eineem Pi 5 und 8GB RAM versucht?
Ich bin ja der Null-Checker wenn es um ZFS geht, aber mir ist gerade langweilig und einen Pi5/8GB mit 4-Fach NVMe-Head (16TB) wäre doch ganz witzig. So könnte ich ich meinen Horizont erweitern und was lernen.

Zum lernen sicher witzig, wird aber im Preis/Leistungsverhältnis teuer. Die PCIE vom Pi5 ist PCIE 2.0 x1, d.h. 5Gbit. Die vier NVME teilen sich also das bisschen Bandbreite, real dann unter SATA SSD Werten. Ob sich das für echte Anwendungsfälle lohnt, 4x 4TB NVME die sich zu Tode langweilen?

 

[HisN]

Das stört mich nicht weiter.
Es soll ultrakompakt, ultraleise und mit wenig Strombezug laufen und nebenbei meinen Basteltrieb befriedigen. Toll wäre es, wenn ich komplett ohne mechanische Komponenten auskommen würde.
Ich hätte gerne ein NAS für 24/7 mit relativ schnellem Zugriff auf viele kleine Dateien und ein oder zwei Datenbanken und ... für die Zukunft.. eine Option/Grundlage um meinen großen 136TB-Filer umzubauen, der dann nicht mehr dauerhaft laufen müsste. Angebunden wird das ganze sowieso nur mit Gigabit-Lan, es sei denn ich teste mal einen 2.5GBit-USB-Adapter, der sich dann die USB-Bandbreite mit der USB-System-NVME teilen müsste, was ja auch nicht gerade die Krönung der Schöpfung darstellt.
Und ja ... das könnte man bestimmt auch preiswerter mit einem NUC/Mini-PC und einer 20TB-Festplatte lösen^^
Aber wo bleibt denn da der Spaß bei der Sache? )))

 

[gea]

Für ein Basteltrieb Mini-NAS gibts nette Teile mit 8/16 GB RAM, 4 x M.2, 2,5G nic und dazu ein 64GB Bootlaufwerk,

CM3588

www.friendlyelec.com

Nur schade dass die Arm Variante von OmniOS nicht fertig ist.
Intel N100 Boards sind aber auch sehr gut und da ist man erheblich flexibler was Hardware und OS angeht..

 

[HisN]

@gea
Nice. Wenn das mit dem P5 zu lahm ist, probiere ich die Variante.

Nen N100-Board mit 4x NVME hab ich allerdings auch noch nicht gesehen.
Wobei .. ein 4x NVME-Adapter für PCie x16 hab ich auch noch rumzufliegen (Asus Hypercard oder wie die Dinger sich nannten). Auch gar keine so blöde Idee. Wobei dann ultrakompakt schon mal flach fällt. Wobei das scheinbar auf N100-Boards auch nicht vorhanden ist :-(

 

[gea]

Wenn man sich von 5W und Ultra Mini für 100 Euro verabschiedet kommen halt ganz schnell die AMD uATX AM4 Boards. Da hat man dann flexible CPU Auswahl, mehr RAM mit ECC Option und 3 PCI-Steckplätze für einen überschaubaren Aufpreis. Das ist dann ein universell einsetzbarer Computer,

 

[HisN]

Ja.. aber an sich zu viel des guten^^
Schauen wir mal wo die Reise hingeht.