Cannon

CPU-Stresstest hatte ich schon gemacht und damals beim Zusammenbau vor ein paar Wochen auch noch mit Prime95 inkl. Memory. Wenn das anhält, muss ich aber memtest noch mal machen. Ich habe aber gestern 2 Sachen gemacht: Zum einen das Netzteil getauscht und zum anderen ist mir in der Windows VM aufgefallen, dass die bei Machine noch auf Q35-7.2 eingestellt war. Das habe ich dann auf Q35-9.1 umgestellt. Ich hatte ohnehin irgendwie das Gefühl, dass die Reboots was mit der Windows VM zu tun hatten. Denn wenn es das Netzteil wäreklich wäre, hätte sicherlich die CPU-Stresstest als auch das gleichzeitige anlaufen aller Platten auch schon zu einem Crash geführt. Bis jetzt hatte ich allerdings auch keinen Reboot mehr. Nun allerdings das Problem, dass 4 Disks nach mehreren Stunden nun schon das 2. Mal offline waren , während der Paritätsprüfung. Nur ein Neustart des Systems aktivierte die wieder. Die 4 hängen allerdings auch direkt am Mainboard - die anderen, die nicht offline waren an einem extra Controller. Also irgendwas stimmt da nicht. Das offline-Problem hatte ich aber vorher noch nicht. Ich habe jetzt mal im nächsten Schritt NFS deaktiviert, Spin Down deaktiviert. Mal schauen, was passiert.

Ist da was in UnRaid dazu einzustellen?. Ich finde da nichts zu Energiesparoptionen, außer den Ernergiemodus.

Ich habe mein System jetzt komplett eingerichtet, sprich Windows Server in eine VM umgezogen, die ganzen ehemaligen NTFS-Platten ins Array eingebunden, als xfs und umkopiert. Im letzten Schritt wollte ich nun die Paritätsplatte einbinden und habe vorher noch ein Update auf UnRaid 7 gemacht. Das Problem ist, dass das System nach mehreren Stunden, manchmal auch erst nach einem Tag neu startet. Dabei wird auch das Array nicht automatisch wieder hochgefahren, was noch schlimmer ist. Ich vermute das passiert, weil die Paritätsprüfung noch nicht abgeschlossen ist. Die Frage ist eigentlich, wo kann ich mit der Fehlersuche anfangen? Auf Unraid 6 geht nicht, weil mein Pool mit zfs läuft und laut Doku ist das dann nicht mehr möglich. Ich habe nun noch ein Netzteil bestellt, vielleicht könnte es daran liegen. Vor ein paar Wochen lief das ganze System als reiner Windows Server aber fehlerfrei und ob das Problem mit dem Wechsel zu Unraid 6/7 zu tun hat, kann ich nicht genau beurteilen, weil das System auch noch nicht so richtig fertig war und ohnehin immer mal wieder durch die Erweiterung des Array neu gestartet werden musste.

Aber dann verstehe ich nicht, warum das rsync-backup z.B. vom Pool zum Array funktioniert. Das ist ja auch eine andere Platte. Und ich vermute mal, dass erst mal ein Vollbackup macht und beim nächsten Backup dann die Hardlinks gesetzt werden. Also auch auf einer anderen Platte. Denn das erste Backup wäre quasi das Original. Damit erschließe ich mal einfach, dass beim NFS-Ziel einfach nicht hardlink-fähig ist. Nur die Frage warum und wie man das testen kann, weiß ich leider nicht.

Die Frage ist, ob das mit den hardlinks überhaupt funktioniert, wenn das Laufwerk über NFS ganz woanders ist. Wenn ich hardlinks richtig verstanden habe, müsste doch die Kopie erst mal im NFS angelegt werden und von da dann die hardlinks erstellt werden. Theoretisch wären doch NFS-übergreifen sonst gar keine hardlinks möglich oder?

ext4

Ich würde ja gerne mit dem rsync-skript von mgutt arbeiten. Von der Sache her ist das sehr einfach, weil man einfach die Quell- und Zielpfade einstellt und gut ist. Die Frage, die aber bleibt ist doch folgende: Wieso unterstützt mein remote NFS am raspberry (und genau deshalb habe ich ja umgebaut) keine Hardlinks? Wenn das gehen würde, sind die ganzen Probleme mit den Backups eigentlich gelöst.

Ich habs umgebaut. Leider funktioniert die Lösung auch nicht. Gestern mühsam die Festplatte über die Befehlszeile, partitioniert, gemounted, als NFS freigeben. Voller Freude wartete ich heute auf das geplante Backup. Leider wieder die gleiche Meldung, dass mein remote keine Hardlinks unterstützt. Warum nicht? Ich dächte mit NFS geht das.

Wenn du auf eine kaputte Platte rauf kopierst (mit verschieben), dann ist das natürlich nicht gerade optimal. Aber selbst wenn die Platte an der Stelle abschmiert, dann wird ja die Datei auf der Quellplatte auch nicht gelöscht. Und wenn deine Zielplatte abschmiert, wenn du die Quellplatte gerade gelöscht hast, dann hast du die Quelldaten auch nicht mehr.

Aber es wird doch erst dann gelöscht, wenn es erfolgreich verschoben ist. Ich finde das sogar besser mit dem sofortigen Verschieben. Denn, wenn was kaputt ist, bleiben nur noch die Dateien übrig, die Probleme machen und ich muss nicht erst suchen. Der Abgleich macht sich damit deutlich leichter.

Aber das kann doch Unraid durchaus unterscheiden. Im WebInterface sehe ich das Array und den Pool. Das Array besteht aus einzelnen Disks. Wenn alle Unterordner der einzelnen Disks verglichen würden, dann habe ich doch das Problem gar nicht. Beispiel: Ich habe ein Share namens Daten. Das Share liegt auf Disk1 und Disk2. Jetzt ist es doch easy zu prüfen, ob unter mnt/disk1/Daten und mnt/Disk2/Daten Dubletten liegen. Der Pool hat doch damit nichts zu tun. Wie gesagt aber nur unter der Voraussetzung, dass ich das Share Daten verwende und nicht direkt auf mnt/disk1/Daten und /mnt/disk2/Daten schreibe. Selbst, wenn ich die Dubletten nun nicht lösche, habe ich da aus meiner Sicht irgendwie eine Inkonsistenz. Denn wenn 2 Dateien mit gleichem Namen aber unterschiedlichen Inhalts im Share liegen, zeigt mir Unraid nur eine der Dateien im Share Daten an. In diesem Fall stellt sich wiederum durchaus die Frage, warum er die Datei dann eben auch nicht 2x anzeigt, wenn das Ganze durchaus erlaubt werden soll. Mein Ansatz geht eigentlich nicht mehr darum die Dateien einfach zu löschen, sondern klar zu entscheiden: Möchte ich Dubletten durchgehend erlauben oder nicht. Und wenn ja, dann sollten doppelte Dateien auch im Share angezeigt werden. Ja durch einen Fehlerfall ... leider. Was auch erst zu diesem Thema führte. Warum sollte das System das ablehnen? Das war nie mein Ansatz. Der Ansatz ist, entweder: Variante 1: per Notification/Log warnen, dass Dubletten gefunden wurden Variante 2: doppelte Dateien in einen Unterordner schieben + Notification/Log Variante 3: doppelte Dateien gnadenlos löschen + Notification/Log

Gemeint war mit fehlerhafter Mover-Aktion, dass die nicht beendet wurde, weil er möglicherweise die Datei nach dem schieben nicht löschen konnte. Es ist ja nur fiktiv. Ob das wirklich auftreten kann, sei mal dahin gestellt. Das ein Fall, den ich nicht beachten würde und auch in der Realität gar nicht so umsetzen würde. Ich sehe da wenig Sinn drin mit User-Shares zu arbeiten und dann wieder auf Disk-Ebene zu arbeiten. Das widerspricht, zumindest für mich, dem ganzen System als solches. Ich verstehe zwar das Problem mit den Rechten, weil UnRaid keine Möglichkeit bietet Shares in bereits vorhandene Shares anzulegen, aber so richtig toll ist das nicht auf Diskebene zu arbeiten, wenn man die User-Shares nutzt. Kann ich nicht nachvollziehen. Der Mover schiebt doch nur von Pool<->Array und nicht von Array<->Array. Dann sollte es auch keine Dubletten auf dem Array geben. In den Notifications von UnRaid. Nicht der User, sondern der Admin/root sollen informiert werden.

Naja man müsste überlegen, wie sowas passieren kann. Evtl. durch eine fehlerhafte Mover-Aktion, dass eine Datei gar nicht gelöscht wurde. Der Mover schiebt ja auch nur zwischen Pool und Array und nicht innerhalb der Arrays. Deshalb sollte da gar kein Risiko sein. Das sollte nicht wirklich notwendig sein. Der Inhalt sollte ja immer gleich sein, wenn ich nur über das user-Verzeichnis kopiere. Außer wie gesagt der Umstand, dass das System abstürzt. Aber auch das ließe sich ja in einer "Datenbank" nachvollziehen, welche Datei die richtige ist. Aber hashen halte ich persönlich für unnötig. Was aber evtl. Sinn macht ist wirklich eine Bereinigung der Daten (siehe Punkt a). Also im Scheduler eingestellt, wann das geprüft werden soll. Ich stelle mir das so vor, dass alle Shares auf Diskebene einmal geprüft und auf den Dateinamen verglichen werden. Gibt es doppelte Dateien, werden die entweder sofort gelöscht, man wird gewarnt oder die werden in einen temporären Unterordner mit selbiger Struktur verschoben. Also z.B. /mnt/user/cleanup/meinefreigabe/unterordner1/Datei1.

Ja aber es schwingt schon die Angst mit, dass man was falsches löscht. Die Frage ist ja, warum UnRaid das nicht irgendwie selbst konsolidieren kann? Denn wenn ich im gleichen Ordner nur auf einer anderen Disk die gleiche Datei habe, dann müssten doch spätestens an der Stelle irgendwas nicht konsistent sein oder ich hätte im user-Share die Datei 2x drin. Mir leuchtet nicht so richtig ein, warum Unraid das eigentlich gar nicht merkt und welche Datei er auf einer Disk er überhaupt dem Share zuordnet.

Als bei mir hat unbalance nicht funktioniert. Ich habe alles verschoben. Die Quelldisk war dann aber noch voll, sprich er hat nichts gelöscht. Und dann habe ich den Prozess noch mal gestartet und er kopierte dann die Daten natürlich auf eine andere Disk. Jetzt habe ich auf mehrere Disks die gleichen Daten. Die Frage ist nun, wie ich die Dubletten bereinigen kann?

Brauche ich auch eigentlich nicht, da ein Teil der Backups aus Windows heraus gemacht werden und damit sowieso schon fix und fertig sind. Das heißt ich habe ohnehin nur das, was auch weggesichert werden muss und muss einfach stumpf kopieren. Aber das scheiterte schon, weil eine Internetverbindung langsam und nicht sehr stabil ist. Langsam ist natürlich relativ. Aber ein komplettes Windows-Systembackup ist ja auch riesig. Die Lösung freut mich aber.

Genial! Auf die Idee wäre nicht gekommen. Ich habe 3 externe Standorte, wo ich die Daten hinsichern kann. Und alle haben auch einen Raspberry PI 4b laufen. Dann muss ich die HD nur von der Fritz!Box ab machen und an den Raspi hängen. Was dann aber die Einrichtung betrifft: Auch da haperts dann wohl gedanklich: Ich muss im ersten Schritt die USB-Festplatte mounten, einrichten, formatieren usw. Und dann den Raspi als NFS-Server einrichten? Und im letzten Schritt die Verbindung mit Unraid, das heißt als NFS mounten.

Ja die Erfahrung habe ich jetzt auch gemacht. SMB geht zwar zu verbinden, aber bietet keine rsync-Möglichkeit wegen der Hardlinks. NFS wird aber von der Fritz!Box nicht unterstützt. Und die Sicherungsplatte hängt per USB an meiner Fritz!Box. Unterm Strich habe ich noch keine Lösung, wie ich die Daten über Glasfaser/DSL sichern soll. Weder mit Script von mgutt (rsync) geht das, noch Duplicati ist das sehr zuverlässig. Das Thema Backup ist unter Linux/Unraid deutlicher kompliziert als ich dachte.

Ich ging davon aus, dass ich das dann als Linux formatieren muss und dann geht das auch mit den Hardlinks. Aber offensichtlich ist das nicht so. Wie kann ich denn ermitteln, ob mein Ziel Hardlinkfähig ist? Du schreibst auch, dass du nicht mit Hardlinks. Welche Optionen gibt es dann? Einfach normale Vollbackups mit einer anderen Software machen?

Das Skript an sich läuft, wenn ich die Sicherungen lokal anlege. Sobald ich die Sicherung aber über ein gemountetes SMB durchführe erhalte ich eine Fehlermeldung: Error: Your destination /mnt/remotes/FritzBox-MAF/BACKUP/SERVER does not support hardlinks! Die Backup-Platte an dem SMB war vorher auf NTFS, dann habe ich die extra auf Ext4 formatiert und das Problem ist dennoch nicht gelöst. Wie schaffe ich das denn dann die Backups dort zu erstellen? Hintergrund der ganze Sache, warum ich das so mache ist folgendes: Ich lege lokale Backups in Unraid an und möchte dann dieses Backup noch zusätzlich extern an einen anderen Standort sichern, falls mal was abbrennt.

Ja, konnte das so lösen. Das temporäre Verzeichnis muss man irgendwo in den Profi-Einstellungen entsprechend konfigurieren.

Ja, danke für die großartigen Hinweise!

Ich habe mich eigentlich mit dem Thema nie wirklich befasst. Aber seit ich vor einer Woche UnRaid eingerichtet habe, sehe ich mal die ganzen Smart-Fehler der Festplatten. Ich möchte eigentlich die Datenplatten, die hier alle einzeln bespielt wurden und nur im Wechselrahmen ab und zu mal drin waren ins Array packen. Das dauert auch ein bisschen, weil man die ja auch Stück für Stück ins Array kopieren, dann löschen und dann leer ins Array einfügen kann. Bzw. dann, wenn man nicht unendlich Überschuss an Kapazität hat. Grundsätzlich sind die Platten wenig gelaufen haben aber fast alle Smart-Fehler. Ist das denn normal? Ich rede hier von 20 Platten von 2-20 TB, wovon vielleicht 7 fehlerfrei sind. Hier mal die Auszüge der Fehler: 5 Reallocated sector count 184 End-to-end error 187 Reported uncorrect 197 Current pending sector 198 Offline uncorrectable 199 UDMA CRC error count Im Prinzip haben fast alle den Fehler 199 oder den Fehler 197 und 198. Ein paar wenige, haben dann die anderen Fehler. Eine Paritätsplatte ist noch nicht drin, weil die erst dann einbaue, wenn das gesamte Array fertig ist.

Ich konnte den Fehler jetzt reproduzieren. Ich habe gestern Duplicati als Docker installiert. Sobald ich mit Duplicati ein Backup starte macht der den Dockerspeicher voll und wenn der dann 100% erreicht hat ist das Image futsch, auch mit xfs. Deshalb stellt sich die Frage, wieso Duplicati das Image überhaupt voll macht und dann, wie man das verhindert kann.

Naja ich bin neu in UnRaid und haben den Standard, der vorgewählt war gelassen. Allerdings hatte ich vorher dennoch recherchiert und das Array läuft auf xfs. Der Pool allerdings auf zfs, weil man da xfs nicht wählen kann. Jetzt läuft aber der Docker auch auf xfs. Danke für dei schnelle Hilfe. Ich war schon leicht gestresst. Dann frage ich noch mal kurz (offtopic) zur VM (Windows) nach img lassen oder cow2 verwenden?