NAS UGreen DXP4800 Plus

Und der wiederum ist wohl nicht kompatibel mit der UGreen-LED-Steuerung (https://github.com/miskcoo/ugreen_leds_controller), die ich eingebunden habe.
Unabhängig vom RAM, war die LED-Steuerung denn essentiell?


Das soll dann mein nächstes Projekt werden, allerdings habe ich bisher um Docker (Compose) / Portainer / Container / LXC / Kubernetes oder was es da sonst noch alles gibt einen weiten Bogen gemacht.
Dann einfach mal Proxmox auf dem dedizierten Server installieren und eine Linux-VM aufsetzen und dort Docker + Dockhand (mein Portainer + Watchtower Ersatz) installieren und lernen, übeb, spielen :)
 
Last edited:
Ja, ZFS wäre für einen Backup-Server eigentlich erste Wahl, denn es bietet Deduplizierung. ABER dafür braucht man bei ZFS viel viel RAM und der ist im Moment unbezahlbar (und die UGreen hat DDR5!). Außerdem scheinen einige auch hier im Forum vor dieser Funktion zurückzuschrecken.
Du vermischt hier zwei verschiedene Themen.

Das eine ist ZFS dedup. Die dedup Table kann heutzutage auf svdev (also SSD) ausgelagert werden und muss nicht mehr im RAM sein.
Das andere ist dedup mit PBS. Das braucht so ziemlich gar nix an RAM.

Allerdings is halt PBS ein blockstorage Backup dedup, während ZFS dedup gut für grosse datasets funktioniert, weniger gut für blockstorage.

Ist eigentlich auch logisch, PBS arbeitet mit 4MB chunks per default.
ZFS hat per default 16k für blockstorage.

Bei ZFS gilt zu 99% Finger weg von dedup, es sei denn du hast einen ganz seltsamen edge case.
Bei PBS ist dedup hingegen nicht "live" und hat damit auch keine grossen Hardware Anforderungen.
 
Du vermischt hier zwei verschiedene Themen.
Danke für den Hinweis.

Ich bin ja auch nicht gegen Dedup. Bei meiner letzten Firma hatten wir die tägliche Veeam-Sicherung von ca. 50 VMs mit Dedup laufen. Wahnsinn, was da auf den Backup-Server passte, die Vorhaltezeit der Backups lag wohl so bei 60 Tagen. Täglich ging es dann noch auf einen zweiten Backup-Server und auf Tape.
 
  • Like
Reactions: IsThisThingOn
Ergänzend zu IsThingOn: Der PBS setzt für seine ganze Magie keine speziellen Features des Dateisystems heraus, man kann darum so ziemlich jedes Dateisystem nehmen, was von Linux unterstützt wird und Posix-Semantiken unterstützt (also zfs, btrfs, ext4, xfs), selbst wenn das aus anderen Gründen (Netzwerkfreigaben wie nfs oder cifs sind beispielsweise von der Performance suboptimal) nicht sinnvoll sein mag. Ich würde also die Finger von einer mit ntfs oder vfat formatierte Platten lassen.

Warum nun zfs für den BackupServer statt zum Beispiel xfs oder ext4? Weil man damit die zfs-Features nutzen kann, die der PBS selbst eben nicht mitbringt, wie die zfs-Fähigkeiten zur bitrot-Detection und Autoheilung oder die Möglichkeit rotierende Platten (HDDs) und SSDs als Kompromiss zwischen bezahlbarer, hoher Kapazität und vernünftiger Performance nutzen zu können. YMMV
Danke für den Hinweis.

Ich bin ja auch nicht gegen Dedup. Bei meiner letzten Firma hatten wir die tägliche Veeam-Sicherung von ca. 50 VMs mit Dedup laufen. Wahnsinn, was da auf den Backup-Server passte, die Vorhaltezeit der Backups lag wohl so bei 60 Tagen. Täglich ging es dann noch auf einen zweiten Backup-Server und auf Tape.

Genau das lässt sich auch sehr gut mit dem PBS umsetzen (sowohl für Tape als auch syncen auf einen offsite-PBS oder eine externe Festplatte), der bietet dafür nativen Support. Und braucht (wie gesagt) nicht ZFS dafür, das hat halt andere Vorteile.
 
Last edited:
Unabhängig vom RAM, war die die LED-Steuerung denn essentiell?
Nein, natürlich nicht. Ist aber nice to have.

Wie bereits erwähnt, hatte ich mich gedanklich vorher schon von ZFS (und TrueNAS) verabschiedet. Für einen VM-Datastore braucht man die Vorteile von ZFS nicht unbedingt (Snapshots macht die Hypervisor-Software, ZFS-Dedup ist so eine Sache und die Prüfsummen benötige ich auch nicht unbedingt - die VMs werden ja noch gesichert). Für den Backup-Server wären Dedup und die Prüfsummen hilfreich, aber ein Enterprise-Filesystem erfordert auch Enterprise Hardware. Und das ist mein UGreen-NAS beim besten Willen nicht.