Dem muss ich leider widersprechen *klick*
Ok...heißt UGREEN setzt im UGOS Pro das Backup-Tool "restic" ein, wenn ich das jetzt beim Überfliegen korrekt verstanden habe, richtig? Das ist auf jeden Fall ein sehr wertvoller Hinweis!
Wie verhält sich das dann mit den Inkrementen? Anscheinend kann man ja aktuell die inkrementellen Backups mit der UGREEN Backup-App nicht deaktivieren. Hast du da denn auch irgendwas rausfinden können?
Ich hab keine Synology mehr, bin wegen deren Festplattenzwang kurz vor DSM 7.3 zu UGREEN gewechselt.
Aus meiner Sicht kann man das inkrementelle Backup nicht deaktivieren, auch mit mir 1 zu haltenden. Version nicht.
Was aus meiner jedoch absolut gegen das UGOS Backup spricht, ist der Fakt, dass das Backup sogar anscheinend verschlüsselt wird. Ohne UGOS kommst Du da nicht mehr dran. Das ist absolut inakzeptabel!
Ich verschlüssele meine rsync Zielfestplatten selbst mit LUKS. Setz den rsync-Dämon drüber und werde mein Backup jetzt selbst auf dem NAS via rsync Kommando anstoßen und die „Sync & Backup“ App meiden.
Das schmälert meine Euphorie über das NAS gerade etwas…
Jetzt, wo du es sagst. Das merkwürdige, ich habe beim rsync Job die Versionierung beim Erstellen deaktiviert.
Bei der testweisen Wiederherstellung bekam ich dennoch in der Menüführung eine Auswahl von Versionen angezeigt. 🤔
Ich will halt nicht im Fall der Fälle auf eine spezifische Hardware angewiesen sein, um an meine Daten zu kommen. Das ist für nicht ein no-Go.
Hi zusammen, ich bin anscheinend blind. Ich habe soeben ein Backup auf einen rsync-Server eingerichtet und das Backup tut soweit.
Allerdings wird automatisch "Sicherung mehrerer Versionen" aktiviert. Wo kann ich das deaktivieren?
Auf der Synology wurden auch "Rohdaten" gesichert, so dass ich das Ziel eigentlich einfach an einem anderen Rechner hätte auslesen können. Hier wird irgendwelcher kryptischer Kram gesichert (config, data, index, keys, locks, snapshots). Möchte ich eigentlich alles nicht.
Klar muss man sich erst einmal selbst fragen für was man die NVMe Slots generell nutzen möchte. Caching habe ich bei nem Datengrab wie bei mir erstmal für sinnfrei angesehen. RAID nutze ich nicht, genauso wenig wie zweiten Speicher über die NVMes. Der festverlötete emmc war irgendwie ne „Red Flag“ für mich bei der Überlegung mir eine DXP2800 anzuschaffen, die ich so umschiffen konnte.
Apple btw. nutzt in seinen iPhones seit dem iPhone 6 NVMe Speicher.
Genau das „schonen“ war eigentlich einer der Hauptgründe. Es beruhigt mich einfach zu Wissen, dass ich nicht auf den emmc angewiesen bin. Im schlimmsten Fall neue NVMe rein und gut. Das ist bei Synology schon etwas „besser“ gelöst.
Üblicherweise hat ein emmc weniger P/E-Zyklen als eine NVMe. Gleiches gilt für TBW und MTBF. Die Datenrate ist natürlich bei der NVMe um Welten besser. In wie weit das natürlich merklich ist? Gefühlt vielleicht ein bisschen schneller beim Booten.
Backup des emmc würde ich eh jedem raten, da man so nicht beim Support nachfragen muss. Man weiß ja nie in welche Richtung die Reise hier die nächsten Jahre mit UGREEN geht.
Kannst Du den die selbe NVME jetzt auch für Apps, Docker, VMM und andere Dinge nutzen oder nur für das OS ?
Mit den Standardpartitionen bisher nicht. Auf dem emmc sind etwa sieben Partitionen. Sind glaub 32GB. Da ich die 1:1 auf eine 512GB NVMe geklont habe, verschenke ich natürlich aktuell 480GB. Fraglich ist, was passiert wenn ich den „Rest“ nun partitioniere und mounte. Das hab ich bisher noch nicht ausprobiert.
Als ich die DXP2800 bekommen habe, habe ich den Watchdog deaktiviert, die Ersteinrichtung abgeschlossen und danach das emmc mit Clonezilla gesichert. Diese Sicherung habe ich dann auf eine NVMe geclont und den emmc deaktiviert. Heißt mein NAS läuft komplett von der NVMe - soweit auch komplett ohne irgendwelche Nebeneffekte. Hab sogar schon ein Update auf die letzte Version durch.
Nutzt hier noch jemand ein UGOS von einer NVMe statt dem emmc?
Das sind alles grundlegende Linux-Kommandos. Wenn du nicht weißt, was damit und mit den Files, die UGREEN dir geschickt hat, zu tun ist bzw. wie du überhaupt an die Stelle kommst, wo du den Kram eingibst, ist es hier im Forum leider relativ schwierig da in ein zwei Sätzen die ganzen fehlenden Grundlagen zu vermitteln.
In Kürze:
* Dateien aufs NAS kopieren
* ssh auf das NAS mit admin User
* wechsel zu root
* Berechtigungen für smrbin anpassen
* smrbin ausführen
Wenn das für dich problematisch ist, würde ich ehrlicherweise ehr zu einem anderen NAS raten.
was hat der Post #386 jetzt mit dem sudo-Befehl zu tun?
Deshalb habe ich (gefühlt x-Seiten vorher) den Slot 2 als mögliche "Fehlkonstruktion/Schwachstelle" in den Raum geworfen und an den Support gemeldet, weil es immer nur "hard drive 2: failed" war, nie 1.
das erklärt doch dann aber nicht, dass es mit einer Ironwolf funktioniert?
Ich habe zu diesem Thema noch etwas weiter Recherchiert und es gab die genannten Probleme auch schon im TrueNAS Forum vor mehr als vier Jahren - auch dort kam man zu dem Entschluss, dass es hauptsächlich WD Platten und davon EFAX oder EFRX sind.
Auch hier wird noch einmal bestätigt, dass im Stresstest mit gesetztem libata.force Parameter und forcierten 3.0G keine Fehler mehr auftraten.
Also, man kann das ganze Problem wie bereits vermutet zumindest umgehen, indem man die Festplatte(n) auf SATA 3.0G zwingt, statt der ursprünglichen SATA 6.0G.
Das Ganze funktioniert über einen Kernelparameter:
libata.force=1:3.0G,2:3.0G
Dadurch werden beide Festplatten in Port 1 und Port 2 auf SATA 3.0G gezwungen.
Sieht man dann auch in der Ausgabe:
ohne Parameter:
root@DXP2800:~# dmesg | grep -E "ata[0-9]\.00|link up"
[ 1.444864] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.445960] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.449474] ata2.00: ATA-10: WDC WD40EFRX-68N32N0, 82.00A82, max UDMA/133
[ 1.450659] ata1.00: ATA-10: ST8000VN002-2ZM188, SC60, max UDMA/133mit Parameter:
root@DXP2800:~# dmesg | grep -E "ata[0-9]\.00|link up"
[ 1.453165] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[ 1.454249] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[ 1.455471] ata2.00: ATA-10: WDC WD40EFRX-68N32N0, 82.00A82, max UDMA/133
[ 1.457519] ata2.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[ 1.458761] ata1.00: ATA-10: ST8000VN002-2ZM188, SC60, max UDMA/133
[ 1.459695] ata1.00: 15628053168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[ 1.461044] ata2.00: configured for UDMA/133
[ 1.463629] ata1.00: configured for UDMA/133Eintragen muss man die Parameter entweder im grub Menu zum Testen (nicht persistent) oder in /boot/EFI/debian/grub.cfg
Letzteres ist dann zumindest erstmal so lange persistent, bis irgendwann jemand update-grub ausführt und die grub.cfg überschrieben wird - potenziell durch ein Kernelupdate.
Ja, der Modus SATA 3.0 ist erst einmal "langsamer". Allerdings spielt das bei den hier in der Regel verbauten Festplatten mit Transferraten weit unter den theoretischen 285 MB/s keine Rolle. Im kabelgebundenen 1G LAN kommen hier bei mir im Test immer noch die 110MB/s an, wie schon zuvor auch.
ACHTUNG: dieses Vorgehen greift in das UGOS PRO System ein und ich übernehme hier keine Haftung für irgendwelche Schäden oder Datenverluste
Ich glaube nicht, daß die EFRX von den Problemen betroffen ist. Bisher waren es immer EPFX HDDs.
Schau mal hier https://ugreen-forum.de/kompatibilitaet/
Auf den Seiten vorher gabs auch irgendwo ne Mail vom UGREEN Support, bei der explizit von RX die Rede war.
Das Problem scheint auch nicht direkt beim Start des NAS evident zu werden. Ich hab grad mal durchgestartet - keine Logeinträge, Verbindung mit 6.0 Gb/s. Dann eine 6GB Datei kopiert, Fehler im Protokoll, nur noch 3.0 Gb/s. Sieht man auch im syslog:
ata2: hard resetting link
...
ata2: SATA link up 6.0 Gbps
...
ata2: limiting SATA link speed to 3.0 Gbps
...
ata2: SATA link up 3.0 Gbps
Prinzipiell sind die 3.0 Gb/s für Festplatten mehr als ausreichend, da die Transferraten, die SATA hier bietet sowieso nicht erreicht werden.
Früher gab es mal Jumper an den Festplatten mit denen man einen Modus forcieren konnte. Die WD40EFRX hat diese zwar auch, ich finde allerdings keine Info darüber, in wie weit hier was gejumpert werden muss. Dann wäre es ggf. ein Ansatz die Platten in den 3.0 Gb/s Modus zu zwingen.
Zudem hab ich die Datei, bei der dieser Fehler beim Kopieren aufgetreten ist nochmal zurückkopiert und die Checksummen verglichen. Hier gibt es erstmal keine Abweichung im Sinne von fehlerhaft geschriebenen Daten.
*kw* danke für deine ausführliche Analyse zu dem Thema soweit, ich reihe mich dann mal in die Problematik hier mit ein...
bin jetzt mit der Migration meiner Daten von einer DS718+ (nur 1-bay Betrieb) auf die DXP2800 durch. In die DXP2800 kam eine neue Seagate Ironwolf (ST8000VN002). Die alte Platte aus der Synology sollte dann eigentlich in das zweite Bay der DXP2800:
eine WD40EFRX, Firmware 82.00A82, 2683 Betriebsstunden aus dem Jahr 2020
Das dürfte dann auch erstmal die Chargen-Theorie bei WD widerlegen.
In der DXP2800 hatte ich bisher keine Probleme im Protokoll, bis auf heute morgen, als ich die WRITE FPDMA QUEUED Fehler für die Hard Disk 2 sah. Erstmal Backups checken und die Daten vom Volume 2 via ssh auf das Volume 1 gesichert. Eingebaut hatte ich die WD erst gestern, bis dahin eigentlich keine Probleme mit der Seagate.
Die WD40EFRX steht eigentlich in der Kompatibilitätsliste der UGREEN - von daher finde ich es echt schlecht, dass man diese - obwohl man sich aktuell des Problems bewußt ist - ohne weiteres in der Liste stehen lässt.
Ich hab jetzt eigentlich die vollen 20 Seiten dieses Beitrags durchgelesen, aber mir ist immer noch nicht ganz die Symptomatik klar. Kommt der Fehler wirklich nur beim Boot des NAS und ansatt der vollen 6Gb/s gibts dann nur 3Gb/s? Einige User berichten ja, dass es auch im späteren Betrieb zu den Fehlermeldungen kommt.
Bei mir übrigens gleiches Bild:
Seagate: SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
WD: SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Ich denke ich werde es jetzt wie *kw* handhaben und die WD durch eine weitere Seagate austauschen, die WD wird dann zur Backupplatte.
Ein ungutes Gefühl hab ich trotzdem irgendwo.
*kw* ich bin mit meinem MacBook Pro (M3 Pro) auf macOS 15.7.1 unterwegs. Mittlerweile ist die Verbindung zu meinem DXP2800 eigentlich identisch wie zu meiner alten Syno: ~106 MB/s.
Das Einzige was ich gemacht habe, da mir die ganzen .DS_Store Files auf dem Netzlaufwerk sowieso auf den Zeiger gegangen sind, war
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true
Neustart des Macbook, neustart des NAS.
Verstehe dann aber die Abweichung trotzdem irgendwie nicht. Wenn du sagst es liegt nicht an der DXP, wieso habe ich unter der Syno bessere Werte? Klar, dort gibt es ggf. Optimierungen. Ich bin aktuell auch noch komplett auf Standard und habe bisher nix an den smb Settings der DXP geändert.
Ich hab ein ähnliches Problem. Transfer von 5GB von macOS zur DXP2800 ~3 Minuten. Gleiches file zur Synology DS718+ ~1 Minute. Bin am Testen ob ich meine Syno ersetze und eigentlich begeistert von den Möglichkeiten, allerdings ist das hier ein Todeskriterium.
Da es von macOS zur Syno einwandfrei funktioniert sind Änderungen am macOS Client keine Option. Die DXP muss hier was anders machen.