Cyanrider

Danke nochmal. Steige jetzt von XFS auf BTRFS um, nachdem die Platte nun ein wenig gestreikt hat, da das mit dem BTRFS Treiber unter Windows einfach Plug&Play anzustöpseln gehen sollte bei Bedarf.

Es geht ja doch das was ich möchte:

Ist bei einer neuen Config nicht ALLES weg?

Problem ist nur, dass ich 4x SATA-Slots habe und davon eine vom Cache Drive genutzt wird. Hätte sonst gerade folgende Idee: Ich würde eine der neuen Festplatten als Parity2 zuweisen, die Parität aufbauen lassen und dann die alte Parity1 als Datenlaufwerk zuweisen. So bleiben Parität und Array-Zugriff erhalten. Dann die Paritäts-Swap-Prozedur durchführen. Oder bin ich gerade auf dem Holzweg?

Hallo liebe Unraid-Community. Ich habe folgendes Problem bzw. Szenario: Parity = WD-RED 3 TB DISK 1 = WD-RED 3 TB defekt DISK 2 = WD-RED 3 TB Da ich schon insgesamt 6 von den WD-RED HDDs habe (eine davon hat allerdings nur 2TB und die anderen "freien" 3TB Platten haben alle Defekte), wollte ich die Gelegenheit nutzen und mein Array verändern. Dazu habe ich 2x 12TB Toshiba HDDs gekauft. Das Array soll am Ende so aussehen: Parity = Toshiba 12TB DISK 1 = Toshiba 12TB Es soll also keine DISK 2 mehr geben. Nun wollte ich erstmal die defekte DISK1 austauschen, danach die Parity-Platte und dann zusehen, wie ich DISK2 los werden (habe schon über unBalance gelesen.). Beim Versuch die 12TB Platte einzusetzen kommt nur: "Stopped. Disk in parity slot is not biggest." <<< Warum legt Unraid mir Steine in den Weg, wenn ich die Platte ersetzen möchte? Danach kommt doch auch die Parity dran aber zunächst einmal muss doch die defekte ausgetauscht werden. Beim Versuch meine einzige nicht eingebaute und noch funktionierende WD-RED mit nur 2TB einzusetzen kommt: "Stopped. Replacement disk is too small.The replacement disk must be as big or bigger than the original." Obwohl die defekte Platte mit nur 1,99 TB belegt "ist". Hätte ja klappen können mit etwas Glück. Habt ihr einen Lösungsvorschlag für mich? Es muss doch möglich sein eine größere HDD-DISK einzusetzen und selbstverständlich temporär auf den Mehr-Speicherplatz zu verzichten, bis man eine Parity-Platte eingebaut hat, die mindestens die Größe hat oder nicht? Grüße, Cyan

Does not work for me. After using it, it wants to update via HTTP and get that message: Exception: Updates between multiple major versions and downgrades are unsupported.

Can anyone help me please how to change the repository for nextcloud updates? Same issue here: This version of Nextcloud is not compatible with > PHP 7.4. You are currently running 8.0.18.

ext geht ja so direkt in Unraid über Unassigned Devices nicht zu formatieren. Ich probiere mal exFAT bevor ich XFS nehme. Hat Alex von den GeekFreaks auch gerade gesagt. edit: Mit exFAT gibts auch nur haufenweise Errors. Entweder werden nur die Ordner gesynct und der Inhalt ist leer (rsync: [generator] chgrp failed: Operation not permitted (1)) oder es werden wieder die Daten der Quelle verändert. Mit XFS laufen die Backup-Jobs nun ohne Errors im Log!

Dann formatiere ich die USB Backup HDD nun in XFS und wiederhole den Backup-Job. Paragon Linux File Systems for Windows kann XFS und Btrfs nur lesen. Schreiben ist nur auf Ext2, 3 und 4 möglich. Darf ich die USB-HDD dann auch in Ext formatieren? Wenn ja, welches am Besten?

Ok. Sorry & Danke nochmal.

Ja? Ok. Das klingt nach einem Plan. Sind halt einzelne Ordner verteilt auf verschiedene Festplatten. So ein Script wäre interessant.

Trotzdem vielen Dank für den Vorschlag, die Idee und den Versuch 😊

Ich find's bisschen fies, dass mir hier nicht geglaubt wird und dass wir damit jetzt unsere Zeit damit verschwenden, zu beweisen, dass es nicht an früheren Kopiervorgängen lag: Nochmal: 1. Der Umzug vom Synology zum Unraid war damals super erfolgreich. Ich war froh und hab damals genau davor Angst gehabt und genau das überprüft, weil ich eben immer auf das Änderungsdatum achte und damit arbeite. <<< (Das soll hier auch gar nicht das Thema sein) 2. Kann ich es beweisen, weil ich nicht alles gesichert und unwichtige Dateien und Verzeichnisse ausgeschlossen habe, die damals beim Umzug ja auch übertragen worden sind. Mit denen ist alles in Ordnung, weil diese nicht von Luckybackup bzw. rsync berührt wurden. 3. Zweiter Beweis durch Wiederholung des Jobs jederzeit möglich. Das Erstellungsdatum wurde wie bereits oben geschrieben genau wie das Änderungsdatum von Luckybackup überschrieben. Hier das Beispiel Anhand einer alten Datei die leider von LuckyBackup misshandelt wurde. Sie hatte vorher das Datum 14.02.2007 (kann ich auf einem alten unbrauchbaren Chaosbackup sehen): File: mathe.docx Size: 15040 Blocks: 32 IO Block: 4096 regular file Device: 30h/48d Inode: 648799827789915136 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 99/ nobody) Gid: ( 100/ users) Access: 2022-03-08 05:27:57.462093599 +0100 Modify: 2022-03-08 04:42:26.048396300 +0100 Change: 2022-03-08 05:27:57.462093599 +0100 Birth: -

Leider ja

Ok. Werde es dann bei der nächsten Gelegenheit auf ein Linuxdateisystem ändern. Welche Empfehlung würdest du aussprechen? Erstellungsdatum wurde ebenfalls geändert. Wurde alles auf "jetzt" gesetzt. Also die Zeit wann die Datei vom Backup angefasst wurde.