Cyanrider

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.

rsync fasst wohl gerne die Quelldaten an: https://serverfault.com/questions/456368/how-to-tell-rsync-not-to-touch-the-destination-directory-permissions Außerdem scheint es ja an der Option zu liegen, die ich gesetzt habe: Die Originale sind damals von einem Synology Dateisystem auf eine NTFS USB Platte kopiert worden um anschließend dann wieder auf die neuen Shares in Unraid kopiert zu werden. Das ist nun auch schon Jahre her und hat bisher prima funktioniert. Die Timestamps wurden von LuckyBackup gesetzt. Kein Zweifel. Auch mein voriger Testjob beweist das. Verstehe daher diese Zweifel garnicht. Habe ja auch unwichtige Daten/Shares nicht gesichert, diese haben ja auch noch ihre richtigen Timestamps behalten.

Ja das mit der XFS Disk ist ja nun auch zu spät. Die Vorteile von NTFS hatte ich ja vorhin genannt (Plug&Play für einen schnellen Restore-Zugriff auf einem beliebigen Windows-System). Tatsächlich hatte ich die Platte direkt in Unraid gemountet und als NTFS formatiert. Unraid unterstützt das also auch ohne Probleme. CA Backup? Ich kenne nur CA Appdata Backup. Das sichert nur Appdata aber keine Shares. Fakt ist ja anscheinend, dass man es nicht ändern kann. Also egal. Trotzdem: Vielen Dank für die schnelle Reaktion und Anteilnahme. Tolle Community 😊

Sorry aber wie kommst du denn darauf? Wie gesagt: Ich arbeite immer mit Änderungsdatum in Windows. Sowas fällt sofort auf. Was soll denn da vorher fehlerhaft gewesen sein?

Unraid xfs Ja, ganz sicher. So sieht es auf meinen ganzen Shares aus, die vom Backup-Job betroffen waren. Ich arbeite immer mit "nach Änderungsdatum" sortieren im Windows-Explorer. Deswegen fällt mir sowas dann auf.

Ja, wie gesagt. Mir seit 2003 nicht passiert. Wieviele verschiedene PCs, DVDs, Betriebsssyteme, Dateisysteme, NAS-Laufwerke usw. diese Dateien überlebt haben... und nun sowas... LuckyBackup = rsync mit GUI Von Archiv Bit habe ich auch schon gelesen und gegoogelt aber das setzt ja nur einen Haken und enthält kein Datum, richtig? Ich hätte doch lieber bei Unraid > abgespeckte Win10-VM > DirSync Pro bleiben sollen. War zwar völlig unnötig eine ganze Win10 VM nur für einen Backupjob für den Fileserver-Teil meines Unraid-Servers laufen zu haben aber es hat wenigstens sauber funktioniert. Never change a ... Schade, dass es keine "Backup-App" von/für Unraid gibt.

Entschuldigung. Du hast vollkommen Recht aber in dem Fall dachte ich danach einfach: Welchen Sinn hat so eine Option/Funktion. Welche beim Sichern/Synchronisieren das Erstell- sowie Änderungsdatum der Quelle bearbeitet. Ich war schon so vorsichtig aber wohl nicht vorsichtig genug... Absolut meine Schuld, weil ich noch mehr hätte testen müssen, dann wäre mir das mit den Timestamps vielleicht auch noch eingefallen, womit ich nie gerechnet hätte. Ich sollte mehr zum gewöhnlichen "User" mutieren. Gibt es irgendeinen Weg die Timestamps ohne Backup vor dem Backup wiederherzustellen? Irgendeine Datenbank oder sowas, von der ich nichts weiß, wo vielleicht diese Infos noch stecken? Bei Fotos hätte ich eine Idee: Das Erstellungsdatum aus den Meta-Daten irgendwie als Datei-Erstellungs- bzw. letztes Änderungsdatum setzen. Geht mit FastStone Image Viewer aber da muss man alle Fotos "einzeln" auswählen. Ich würde gerne meinen ganzen Fotoordner damit einmal drüber laufen lassen, auch wenn das meinen Dokumenten, meiner Musik und meinen Videos nicht mehr hilft...

Ja ich synchronisiere auf eine mit Unraid formatierte NTFS USB HDD, damit ich diese im Notfall schnell einfach an irgendeinen Rechner klemmen kann und dort kein Linux-Dateisystem läuft und ja ich habe diesen Haken gesetzt und vorhin erst das Popup gelesen, welches darauf hinweist. Aber: Warum wird beim Sichern überhaupt die Quelle berührt? 😥 Ohne Backup vor dem Backup gibts keinen Trick um die Timestamps zurückzuholen oder? Irgendwelche versteckten DBs wo sowas noch gespeichert wird oder so? Ein "undo" von LuckyBackup oder so? 19 Jahre, alles "futsch".

Ist dir aufgefallen, dass dabei alle Quelldateien ihren Timestamp auf JETZT geändert haben? Alle meine Dateien, die ich sorgfältig seit 2003 immer sauber umgezogen habe, haben nun einen Timestamp von 2022. Danke an Unraid, Luckybackup und generell die Linux-Community für so einen Schwachsinn. Ich hatte zudem noch die Angst, dass beim Synchronisieren einfach die Quelle gelöscht wird und alles weg ist. Das wäre es gewesen.