Gorosch

Gibt es aktuell wirklich noch jemanden, der über einen neuen Heimserver nachdenkt oder über ein Disk-/Hardware-Upgrade? In meinem System gibt noch ein Xenon E3-1230 v6 den Takt an zusammen mit 64 GB DDR4 ECC auf einem Supermicro X11SSM-F - gekauft und gebaut 2018 oder 2019. In manchen Momenten dachte ich schon mal, dass jetzt noch etwas mehr RAM (geht nur max 64 GB auf dem Board/CPU), ein paar Cores mehr oder der eine oder andere weitere PCI-E Slot doch noch von Vorteil wären. Im großen Ganzen macht das Setup aber nach acht Jahren eigentlich immer noch das, was es soll: ein paar Cloud und Mediendienste sowie ab und zu mal den einen oder anderen Gameserver. Und das gut und Zuverlässig - von ein paar einzelnen selbstverschuldeten Misskonfigurationen mal abgesehen. Ich kann es daher nicht oft genug sagen: Danke an diese Forum und die Community. Da acht Jahre für Serverhardware jetzt noch kein wirliches Alter ist, wird die Kiste hoffentlich noch ein paar Sonnenumrundungen seinen Dienst verrichten. Q2 2025 habe ich meine alten 4TB und 8 TB WD Red HDDs im Array gegen gegen 16 TB IronWolf Pro aufgerüstet bzw. erweitert. Also alle 4 TB HDD raus und gegen 16 TB getauscht. Da lagen die in dem Moment bei knapp 300 Euro. Macht aktuell 68 TB auf dem Array, wobei davon knapp 60% belegt sind. Wenn ich den aktuellen Film und Musikmarkt bezogen auf BluRay und CDs beachte, wird das wohl (leider) noch eine Weile reichen. Da somit die neueren, größeren Platten noch die nächsten 4 Jahre Garantie haben, werde ich diesbezüglich hoffentlich keine böseren Überaschungen erleben und hoffe einfach, dass sich der Markt bis dahin wieder halbwegs normalisieren wird. Was ich demnächchst auf Grund des Alters evtl. mal tauschen werde, ist das Netzteil. Dafür zahlt man aber im Moment noch keine Niere. Habt ihr gar schon mal überlegt Disks/RAM eures vorhanden Server zu verkaufen und erst in 2 Jahren (oder so ^^) wieder neu einzusteigen? Ich habe vor ein paar Tagen erst 32 GB RAM Set von G.Skill in meiner "Sammelkiste" gefunden, welche noch vom Upgrade auf 64 GB vor zwei Jahren meines AM4 Gaming PCs übrig geblieben ist. Gekauft damals für ca. 150 Euro, geht nun beu EBay für um die 300 Euro weg. Habe tatsächlich überlegt, die zu Geld zu machen. Aber Murphy sagt, wenn ich die jetzt verkaufe, gehen bestimmt meine jetztigen Riegel über den Jordan und habe dann keinen Ersatz. Somit bleiben die erst Mal auf Vorrat. Den Rest verkaufen? Niemals. So Geldgeil bin ich nicht, als dass ich mein Hobby zuhause verkaufen würde - auch wenn ich jeden Tag beruflich mit Servern und Netzwerken zu tun habe. Mit Kauf warten bis ... 2027? 2028? Die Playstation 6 soll ja doch 2027 kommen, vielleicht ein positives Signal? Keine Ahnung, ob das ein positives Signal ist. Vielleicht bin ich da zu pessimistisch. Andererseits sind Pessimisten ja Optimisten mit Erfahrung. ;) Sony hat nicht wirklich Einfluss auf die Preise von RAM. Wer weiß, ob ne PS6 nacher nicht schon die 1.000,- Euro Marke sprengt. Da es keine wirkliche Konkurenz mehr für Sony im Konsolenmarkt gibt (Steam Machine mal bewusst außen vor gelassen), können die da mittlerweile tun und machen, wie sie wollen. Ebenso könnte Sony auf die Idee kommen, die Kiste mit gerade soviel RAM auszurüsten, dass das eigene OS läuft und den Rest Modular zu machen - ähnlich wie das N64 früher mit dem Expansion Pack für mehr RAM. Also eben auch "Bring your own RAM" like - nur eben teuerer, weil vorgefertigte Module, die direkt in die Konsole geschoben werden können. Bei der PS5 Pro ist das optische Laufwerk mittlerweile ja auch nur noch optional. Meine Urpsprünglichen Pläne, meinen AM4 Gaming PC (5700X3D, 64 GB RAM, RTX 3080ti) dieses Jahr mal auf AM5 zu bringen, sind jedenfalls erst Mal auf Eis gelegt. Da ich aber auch nur in 2K spiele, ist das erst Mal nicht ganz so tragisch.

Alles richtig. Nichts anderes sag ich ja (5 MB/s mal hin oder her). ;) Wollte nur zum ausdruck bringen, dass die 80 MB/s beim schreiben nach einer Weile direkt aufs Array normal sind, wenn kein Cache oder RW genutzt werden. Deswegen auch der Verdacht, dass entweder der Cache und/oder der Share falsch konfiguriert sind. Zudem wurden wohl die Default Werte von Unraid bzgl. "vm.dirty" verändert. Denn zumindest am Anfang müsste er fast das ganze 1Gbit Limit erreichen (die von dir oben genannten Overheads usw. mal ausgenommen), da normalerweiße erst Mal in den RAM geschrieben wird, bevor es auf die Datenträger weiter geht und der Speed sich dann bei +/- 80 MB/s einpendelt (ohne RW/Cache). Wenn ich es richtig lese, startet der Transfer jedoch direkt bei 80 MB/s und fällt dann auf 15 MB/s ab. Daher der Verdacht mit SMR Array und evtl. SATA Port Multipliers. Das alles natürlich vorrausgesetzt, dass mit dem 1Gbit Netzwerk wirklich alles passt, nicht mit MTU rumgespielt wurde, usw.

Liest sich im Ganzen für mich so, als ob beim Upload auf Unraid die Daten nicht über den Cache laufen sondern direkt aufs Array gehen. Fehlerhafte Share Config usw. Da sind 80 MB/s für den Anfang je nach HDD "OK", aber immer noch weit weg von der 1Gbit auslastung (sollten um die 130 MB/s sein). Daher Tippe ich mal auf eine SMR HDD im Array - im dümmsten Falls als Parity. Oder aber irgendwelche billigen SATA Controller Karten, welche mit Port Multipliers arbeiten. Oder beides zusammen. Würde dann zumindest den Einbruch auf 15 MB/s erklären.

Sorry, konnte ich mir nicht verkeifen. Wer kennts noch? Um doch halbwegs was produktives bei zu tragen: Folgende Punkte schon gegen geprüft? https://docs.unraid.net/unraid-os/troubleshooting/common-issues/unclean-shutdowns/

Vorsicht, Scrutiny ist zwar toll, hat aber ab und zu eine komsiche Logik beim interpretieren der Werte (Seagate und Command Timeout 4295032833). Dennoch: bei Reallocated Sectors Count bei Samsung beobachten, ob die Werte steigen. Bisschen Schwund ist immer, sollte aber bei einer neuen SSD nicht der Fall sein. Ich hatte auch eine 1TB Samsung PM893 im Unraid Pool (single, xfs, Transcoding / Ripping Cache für MakeMKV. Emby und Tdarr), welche nach ein paar Wochen 20 Reallocated Sectors gemeldet hat, mit gerade mal 0,8 TBW. Dieser Wert stieg innerhalb eines Monats nach und und nach an. Am Ende hatte die SSD gerade mal 1.7 TBW und ist dann irgendwann mit über 190 Reallocated Sectors ausgestiegen. Abends noch gelaufen, am nächsten Tag kein Filesystem mehr gehabt (nur noch 1 GB). Da keine wichtigen Daten drauf lagen, habe ich es erst Mal gewähren lassen. Dennoch direkt am Anfang RMA beantragt mit bitte um Vorabtausch. Händler wollte natürlich erst die SSD haben, nur um dann zu erfahren, dass eine Reparatur nicht möglich ist und ich das Geld zurück bekomme. War im August/September diesen Jahres. Also evtl. eine Faule Charge oderm so, keine Ahnung. So oder so: Wenn der Wert steigt, wichtige Daten von der Platte runter und auf jeden Fall RMA beantragen. Unraid meldet dies übrigens auch - auch ohne Scrutiny.

Was nutzt du als Firewall?

Das ist etwas heftig. Was sind das für Platten und wo sind die angeschlossen? Das sollte nach nem nem knappen Tag erledigt sein. 68 TB dauern bei mir ca. 1 1/2 Tage mit normalen SATA HDDs.

Deswegen ja der Punkt mit den "gewissen Diensten und Daten". Alles, was auf dem Cache ist, ist natürlich weg, wenn keine Redundanz vorhanden ist. Sowohl Appdata, Docker und Daten, welche noch nicht im Array liegen oder bewusst nur um Cache liegen. Zu deinen Fragen und wie es bei mir ist: habt ihr keinen Schreibcache auf den Shares für "wichtige" Daten konfiguriert? Ich habe zwei Cache Pools: 2x 256 GB SSDs für Docker und Appdata, 2x 4TB SSDs als Cache für das Array (alles SATA SSD mit jeweils RAID1 pro Pool Alle Shares führen immer zuerst auf den großen Cache. Manche Shares liegen auch nur auf dem Cache, wie z.B. meine Musik Sammlung für den Roon Server. Ziel ist es, so wenig wie möglich die Plattten hoch drehen zu lassen. wenn doch, wie oft läuft euer Mover oder ein anderes Backup solcher Daten? ich Nutze das Mover Tuning Plugin. Sobald der Cache auf 85% Vollläuft, werden die älteren Daten auf dem Cache in Array geschoben, bis der Cache wieder auf unter 60% fällt. Dies wird jeden Tag geprüft. Alle drei Monate wird jedoch alles immer zum 28. des Monats auf das Array verschoben, was da hin soll. Somit blieben neue Daten länger im Cache liegen, womit sie schneller abrufbar sind und ebenfalls wieder Spinups vermeidet. verschiebt ihr keine Daten auf den Server, sondern kopiert erstmal nur und löscht später auf der Quelle, wenn die Daten sicher(er) auf dem Array oder im Backup liegen? Ich verschiebe immer. Sowohl Linux als auch Windows kopiert ja im Hintergund dennoch erst mal nur und löscht die Quelle erst dann, wenn der "kopier" Vorgang erfolgreich war. Spart einem das manuelle löschen. oder ist unraid bei euch eh nur Backup für Daten, die noch woanders liegen? (DANN wäre mir die Schreibcache Redundanz auch egal, aber dann hätte ich auch keine parity) Unraid läuft bei als Datengrab für Mediensammlung, Bilder und Dokumente und auch als Medienserver. Somit sind für mich alle Daten wichtig, wen manche auch wichtiger, als andere. Gehen mal ein paar Filme verloren, kommt die BluRay aus dem Keller und wird neu gerippt. Bilder und Dokumente sind daher für mich wichtiger, da diese nicht einfach "neu" gemacht werden können. oder habt ihr keine für euch "wichtigen" Dateien? Wie oben schon erwähnt, ist für mich alles wichtig. Daher fahre ich diverse Backups, welche sich an die 3-2-1 Regel orentieren: 1 Backup auf einen extra NAS bei mir Zuhause - komplettes Array - jeden tag 1 Backup auf eine NAS bei meinen Eltern - Nur Dokumente, Bilder und Musiksammlung - jeden Tag 1 Backup verschlüsselt auf B2 Backblaze - Wöchentlich 1 Backup auf eine 5 TB USB HDD, ebenfalls jeden Tag. Wenn es im Notfall schnell gehen muss, wird die eben abgezogen und mitgenommen. Leicht Paranoid, wird hoffentlich nie solch einen Notfall geben. :)

Also auf die Begründung bin ich jetzt aber gespannt, warum die zweite Platte bei einem RAID 1 "Grütze" schreiben sollte, wenn es es die erste tut. Vorab: Ein RAID (außer RAID0) dient immer nur der Redundanz und ist kein Backup! Ein RAID Verbund immer von einem Controller gesteuert. Ob Hardware- oder Softwarebasis ist dabei erst Mal egal. Der Controller verteilt die Daten auf die Platten gemäß RAID Config (RAID1 = spieglen, RAID5 usw. = Striping. Wenn jetzt eine Platte aus welchen Gründen auch immer nur noch "Grütze" schreibt, erkennt dass der RAID Controller und schmeißt diese Platte aus dem RAID, womit dieser "degraded" ist. Die Daten sind jedoch immer noch durch die anderen Platten verfügbar. Nach deiner Logik (sofern ich dies richtig verstanden habe) werden die Daten erst auf eine Platte geschrieben und dann von dort auf die zweite Platte kopiert. Dies ist nicht der Fall. Macht ein RAID Pool für den Cache Sinn? Wenn es einem Wichtig ist, dass Docker, VMs und Daten verfügbar bleiben, wenn ein Cache Drive ausfällt, dann definitiv ja (dennoch nie die Backups vergessen!). Wenn es einem egal ist, dass für die Zeit bis zum Austausch der defekten Cache Disk und dem zurückspielen des Backups gewisse Dienste und Daten solange nicht verfügbar sind, dann brauch man definitiv keinen RAID. Bei einem RAID ist zudem noch eine USV zu empfehlen. BTRFS und RAID reagieren gerne empfindlich bei plötzlichem Stromverlust.

Also Energiesparen in allen Ehren, aber manche Sparen sich ihre Server zu Tode. Ich weiß nicht, wie Sinnvoll es ist, ein Grundlegendes Monitoring einer Serverkomponente abzuschalten, um 2,63 Euro im Jahr Strom zu sparen...ich weiß nicht. Prüfe lieber mal deine HDD Settings in Unraid.

Nutze seit Jahren B2 Backblaze mit Duplicacy als eine meiner Lösungen. Läuft seit Jahren ohne Probleme und regelmäßige Test Restores liefen auch immer sauber durch.

Unter "Apps -> Previous Apps -> Docker" kannst du bereits Installierte Docker wieder herstellen: Es wird dann jeweils das Docker Image der einzelnen Container geladen. Da die eigentlichen Konfigs unter appdata liegen und die Parameter der jeweiligen Conatiner in xml Dateien auf dem Stick liegen, bleiben die Einstellungen erhalten. Dennoch sei zu empfehlen, dass du prüfst, warum dir ein einzelner Docker alle anderen Docker Images zerschießen kann.

Servus, grundsätzlich ist die Parity kein Ersatz für ein Backup. Da du jedoch ein Backup hast, hast du dir Grundlegend schon mal die richtigen Gedanken dazu gemacht. Betrachte die Parity in deinem Falls als zusätzlichen Luxus. Die Gründe wurden schon genannt, daher nur zusammenfassend: Auch bei Ausfalls einer durch die Parity abgedeckten Festplatte bleiben alle Daten verfügbar. Du hast also keine längere Downtime durch den Austausch der Festplatte und dem zurück sichern Unraid weiß, welche Daten auf welcher Festplatte liegen. Also für dich ein "run and forget" System. Fällt eine Platte aus und wird ersetzt, stellt Unraid aus der Parity die fehlenden Daten der defekten Festplatte ohne dein zu tun wieder her. Du muss also nicht selber prüfen, welche Daten wo liegen und welche nun wieder aus einem Backup wiederhergestellt werden müssen. Genauso wenig muss du dir dadurch komplexe Backup Strategien überlegen, damit du selbst den Durchblick nicht verlierst. Selbst wenn ein Restore aus einem Backup schneller sein sollte als ein Rebuild aus der Parity, würde für mich immer der Rebuild der klare Gewinner sein, da ich mich um nichts weiter kümmern muss und auch während des Rebuilds auf alle Daten zugreifen kann. Work smart, not hard. Dein System kann die Daten effektiv selbst verwalten. Lass deine Kiste für dich arbeiten und nicht anders herum. Wenn man Backups hat (welche man immer haben sollte!), braucht es nicht zwingend eine Parity zu haben. Wenn man auf die obigen Vorteile verzichten kann und dafür entweder eine weitere Festplatte einsparen kann oder mehr Speicher haben kann, braucht es keine Parity. Aber das musst du für dich abwägen. Noch ein paar zusätzliche Tipps: 36 Stunden für einen Parity Check oder Rebuild sind definitiv zu lang. Wenn Parity weiter genutzt werden soll, dann bei den Parity Disks darauf achten, dass diese CMR Platten sind und keine SMR. Datendisk können alternativ SMR sein, wenn man etwas Geld sparen möchte. Wird SATA 3 6 Gb/s genutzt? Evtl. SATA Karten mit Multiplizierer verbaut? Für deine Appdata solltest du wirklich eine SSD im XFS Pool nehmen. SATA SSD reicht dicke, muss also keine NVME sein. Willst du Redundanz, nimm zwei SSDs im btrfs oder ZFS Pool (RAID1). Dadurch werden deine Docker deutlich performanter und deine Festplatten im Array können sich abschalten. Liegt Appdata im Array, hast du nämlich ständig Disk Aktivitäten und auch eine bescheidene Performance. Auch hier gilt dennoch: Backup fahren (CA Appdata Backup) Zusatztipp: Solltest du für dich entscheiden, auf die Parity verzichten zu können und auch keine SSD im System einbauen wollen, kannst du auch auf das Array komplett verzichten. Stattdessen könntest du alle Festplatten in einen Pool packen. Ob btrfs oder ZFS obliegt deiner jeweiligen Konfession. Entweder als RAID5 (Ausfallschutz/Redundanz) oder RAID0 (max. Speicher/Performance, jedoch kompletter Datenverlust bei Ausfall einer Platte). In beidem Varianten werden die Daten jedoch RAID typisch gestrippt, was zu einer besseren Performance führt als bei einzelnen Disks im Array, gerade wenn dein Appdata nicht auf eine SSD ausgelagert werden kann. Dennoch nochmal zum Abschluss, auch wenn du Backups hast: RAID/Parity =/= Backup (!!!)

SSD im Array macht keinen Sinn. Beim Schreiben kann deine SSD nämlich nur so schnell arbeiten, wie deine Parrity Disk. Du bremst also dein ganzes System ungemein aus. Pack die SSD in einen Pool. Wenn dir Redundanz wichtig ist, nimm zwei SSDs in einen Pool. Mit USV Support als BTRFS, ohne USV ZFS (overlay2 in den Docker Settings setzen). Wenn Redundanz nicht wichtig ist, reicht eine SSD. So oder so mit CA_Appdata_Backup Backups fahren. Denn: RAID im Pool =/= Backup! Dein Share, welches den SSD Cache nutzen soll, sollte so eingestellt werden: Primary Storage: deine SSD, wie auch immer der Pool heißen mag. Secondary Storage: dein Array. Restliche Werte obliegen deiner jeweiligen Religion und Glauben. Mover Action: Von der SSD zum Array. Dein appdata, system und domain Share sollte final so aussehen: Copy-on-Write (COW) für den Anfang auf default "auto" lassen (nur bei btrfs/zfs). Wichtig: Der Mover kann nicht direkt von einem Pool in einen anderen Pool verschieben. Hier entweder mit dem File Manger, Unbalance, Krusader, usw. arbeiten. Wenn du appdata, system und domains vom Mover (oder manuell) verschieben lassen willst, davor den Docker Dienst als auch den VM Dienst deaktivieren. Wenn du Zeit beim verschieben sparen willst, kannst du das Docker Image oder Directory vor dem verschieben löschen, was nur geht, wenn der Docker Dienst deaktiviert ist. Du kannst die Docker danach aus dem "App Store" mit deinen aktuellen Einstellungen erneut installieren. Daten gehen dadurch nicht verloren, da die wichtigen per Default in Appdata liegen.

Ohne Logs wird es schwer, das was zu sagen.

Dein Dupli läuft mit Root rechten, was nur beim Sichern vom USB Stick notwendig ist. Normal sollte USR_ID=99 and GRP_ID=100 (nobody:users) für Dupli reichen. Mit WD NAS kenn ich mich leider nicht aus. Bei QNAP und Synology gibt es jedoch für NFS Freigaben den Punkt "Sqash". In deinem Fall teste Mal diese Option, sofern es das in dieser Art auch bei deiner WD NAS gibt: Dann sollte das erst Mal funktioneren und du weist, dass du ein Beretigungsproblem hast. Ob du das auf Dauer so lassen willst, musst du dann für dich selbst entscheiden. Im lokalen Netz spricht da eigentlich nicht viel dagegen.

Unraid gehört nicht ins Internet! Niemals! Also wirklich niemals! Ernsthaft: es gibt keinen einzigen legitimen Grund, Unraid direkt im Internet erreichbar zu machen. Daher die Ports am besten ganz schnell wieder dicht machen. Willst du die Kiste über das Netz erreichbar machen, nutze VPN, Unraid Connect oder was auch immer. Aber niemals direkt den Server ins Internet stellen.

Das sollte hier kein "das eine ist besser als das andere" werden. Denn das ist es nicht. Sowohl Borg als auch Duplicacy sind beides gute Tools, um verlässlich Backups zu fahren. Wenn du mit Borg zufrieden bist, gibt es keinen Grund außer der eigenen Neugier, sich Duplicacy anzuschauen. Ich wollte dir nur aufzeigen, dass es völlig normal ist, dass gute Backupprogramme generell immer mit Metadaten arbeiten, welche auch irgendwo abgelegt sind und diese ebenfalls in ein Backup einfließen sollten. Im Falle von Borg am besten nicht im gleichen Backup.

Na sag das mal nicht Veeam oder anderen Backup Programmen auf Enterprise Basis. Klar, es gibt auch Programme, wie Borg Backup, welche keine Datenbank benötigen. Diese brauchen dafür um einiges länger beim gezielten Wiederherstellen von einzelnen Daten, da diese meist das ganze Backup nach diesen Daten dursuchen müssen. Der Vorteil einer Datenbank bei Backupprogrammen sind solche Dinge wie Metadatenverwaltung, Deduplizierung & Komprimierung, inkrementelle und differenzielle Backups, Konsistenzprüfung & Integrität als auch die bereits erwähnte schnelle Wiederherstellung. Aber auch Borgbackup ist von anderen Daten abhängig, in dem Fall seinen Repositorys. Und wenn diese versehentlich (oder absichtlich zum testen) gelöscht werden, sind die Backups unbrauchbar. Da freut man sich dann doch über Tools wie Veeam oder Duplicacy, welche die Datenbank anhand der Backupdaten einfach wieder aufbauen.

Mal abgesehen davon, dass das zwei verschiedene SSDs sind (unterschiedliche Seriennummer - SSD vertauscht oder evtl. über USB verbunden?), was hast du den vor? SSDs im Array gemsicht mit HDDs machen eigentlich keinen Sinn, da es im Array keinen TRIM Support gibt. Ist das dein erstes System und du bist noch am basteln?

Es werden diverse Festplatten vermisst. Also am besten mal prüfen, warum diese Disks als fehlend angeprangert werden. Evtl. die NVME vertauscht oder falsch zugeordnet?

Aber sicher doch.

Hallo Zusammen. Seit ein paar Tagen sehe ich folgende Meldung im Log von Unraid 7.0.1: Das ist soweit auch OK, da es sich um ein Intel Xeon System handelt. Die Frage ist nun, was verursacht diese Meldung? Es tretten soweit keine Probleme auf, bis auf eine geringe Verwirrung. VMs sind auf dem System ebenfalls keine aktiv (VM Manager deaktiviert), nur Docker. Es sind auch keine falschen Kernel-Module geladen: Im BIOS sind die üblichen Intel VT Geschichten alle aktiv.

Das ist richtig, da gibt es elegantere Lösungen. Für den Einstieg aber sicher erst Mal ok, da am Anfang nicht allzuviel gebastelt werden muss. Ich selbst nutze es wirklich nur für die wichtigsten Daten, welche ich nicht mehr wiederherstellen kann, wenn die Seuche sich auch in die Backups einschleicht. Also Bilder, Dokumente und so, was den kleinsten Teil an Speicherplatz bei mir ausmacht. Wenn mir mal nen Film verrecken sollte, ist das nicht weiter tragsich für mich. Wird die Bluray/DVD eben wieder aus dem Keller geholt und neu gerippt. Mediendaten lasse ich daher nicht überwachen. Ich habe jedoch auch im Vergleich ein noch eher kleines System mit 40 TB und für mich ist dieser Weg so ok. Evtl. die Inodes Limits anpassen und testen:

ZFS bei HDDs ist so ne Sache mit der Performance. Wenn möglich, vermeiden und mit XFS und Checksum arbeiten. ZFS bei SSD kann für ein erhöhten Verschleiß sorgen. Ob du dass am Ende wirklich merkst, sei dahin gestellt. Dagegen kannst du jedoch mit Kompression arbeiten, was dann die Schreiblast auf den SSDs wiederrum veringert. Bei einer guten CPU dürfte dies dann auch nicht wirklich auffallen. Nachtrag Checksum mit Blake3: