[Speicher-App] ...so richtig verkorkste USB Zuweisung

*kw* · July 29, 2025 at 11:48 PM

An der Stelle muss UGREEN wirklich was tun!

Ich wollte das Problem noch mal separieren, nachdem wir heute schon in mehreren Themen festgestellt haben, dass UGOS Pro fast willkürlich Laufwerksbezeichnungen (sdc1, sdd1, etc.) zuweist.

Duplicati produzierte eben bei einem USB-Backup x-beliebig nur noch warnings und steckte kurz nach Beginn in einem freeze. Währenddessen hatte ich eine zweite HDD dran, die ich aber zuerst drangesteckt hatte. Nachdem ich die auswarf, hat UGOS die aktive Duplicati-HDD einfach umbezeichnet von sdd1 auf sdc1. Damit kam der Job nicht klar.

Das Ende vom Lied, ich musste Duplicati plattmachen, die Jobs neu importieren und dann lief die ganze Sache wieder. Scheinbar war die vorhandene Datenbank komplett durch den Wind.

Den Kuddelmuddel hatte ich auch mit Tommes jarss dahingehend, dass ich bei den Dateiformat-Tests die Job-Config anpassen musste "target"=

Ende vom Lied: bei USB-Backup am besten nur ein aktives externes Laufwerk am NAS haben.

Tommes · July 30, 2025 at 8:11 AM

Moin!

Wenn ich mal ganz viel Lust und Zeit habe, kann ich gerne versuchen, jarss um eine Funktion zu erweitern, sodass ein externer Datenträger immer anhand seiner UUID erkannt wird und der Mountpoint in der aufgerufenen Konfigurationsdatei von jarss ggf. angepasst wird. Dann würde das Backup zumindest mit jarss immer funktionieren.

Ich hatte so eine Funktion damals für meine Synology App Basic Backup geschrieben, was auch problemlos funktioniert hat. Die Überprüfung sah im Protokoll dann u.a. so aus...

Code

Die Auftragskonfiguration wird eingelesen [ Backup.config ]
Der Verbindungstyp ist eine lokale Sicherung
Das Datensicherungsziel befindet sich auf einem lokal angeschlossenen USB/SATA-Datenträger.
Der Einhängepunkt des USB/SATA-Datenträgers wird anhand der Geräte UUID überprüft.
Der Einhängepunkt stimmt mit der Geräte UUID überein.
Das Datensicherungsziel wurde lokalisiert.
Start der rsync-Datensicherung...

Aber wie gesagt... das würde ich erst in Angriff nehmen, wenn ich mal ganz viel Lust und Zeit habe!

*kw* · July 30, 2025 at 8:44 AM

Ebenfalls Moin!

Dag ging gestern soweit, dass Duplicati exakt dieselben Daten....

a) fehlerfrei zur Hetzner StorageBox gesichert und auch wiederhergestellt hat

b) nicht im Stande war, diese fehlerfrei auf irgendeine USB-HDD zu schreiben. Der Job brach quasi schon bei der Prüfung der Backend-Daten ab und endete mit warnings

Ich habe mal unter /dev/diskk/ geschaut, da war ein wenig Durcheinander. Bspw. war die meine externe WD zweimal angelegt (als sdd1), usw.

Das Ende vom Lied, Dr. nas. Werksreset hat seinen Job gemacht und 10 Minuten später startete der Duplicati-Job fehlerfrei (und läuft immer noch...).

Wegen der Kompatibilität zu macOS habe ich mich für exFAT entschieden (Duplicati (Suche) empfiehlt grundsätzlich NTFS oder exFAT).

Für Duplicati gibt es noch einen Tipp, den ich später mal teste. Im Job (Ziel) diese beiden Optionen anlegen, im Ziellaufwerk eine Leerdatei mit sinnfreier/-voller Bezeichnung anlegen, bspw. inateck1.usb oder auch llauezf9dkladh.wdf. Einzig deren Vorhandensein wird vor Beginn überprüft und nur dann geht's los.

This image is exclusive to our members!
Please log in or register for free to view graphics and attachments.

Ich berichte...

karl-heinz-lnx · July 30, 2025 at 9:15 AM

Ein guter Hinweis von Tommes . sda, sdb etc. können sich halt verändern, das macht jedes Linux. Wenn man das nicht möchte, sollte man mit UUID arbeiten.

Wobei man auch die UUID ändern kann. Das muss man dann aber selber machen und dann alle UUID Änderungen natürlich in den entsprechenden Dateien, dir sich darauf beziehen, ändern. Ein Löschen der Partion und neu formatieren von dieser, löscht die UUID zum Beispiel nicht.

*kw* · July 30, 2025 at 9:24 AM

karl-heinz-lnx : schon klar.

Das 'Wirre' gestern Abend war, ich hatte einen definierten Duplicati-Job am Laufen (Ziel: sdd1, so auch in Systemsteuerung) und als ich eine andere HDD ausgeworfen habe, melde sich Duplicati mit Schreibproblemen auf Ziel 'sdc1' und lief in warning.

Und dann fing der 'Spaß' mit dem Durcheinander an. Wie gesagt, aktuell läuft's (wieder).

Edit: just finished...

This image is exclusive to our members!
Please log in or register for free to view graphics and attachments.

ACiAtuRA · July 30, 2025 at 9:26 PM

Quote from *kw*

Wegen der Kompatibilität zu macOS habe ich mich für exFAT entschieden (Duplicati (Suche) empfiehlt grundsätzlich NTFS oder exFAT).

Es gibt ein relativ neues Projekt mit Namen anylinuxfs, das so ziemlich jedes Format für MacOS bereitstellt. Ich hatte noch keine Zeit mir das anzuschauen. Ev hast du ja jetzt Zeit für ein paar neue Experimente.

Quote

mounts any filesystem supported by Linux (ext4, btrfs, xfs, ... but also NTFS and exFAT)
supports LUKS-encrypted drives
supports BitLocker-encrypted drives (using your recovery key as passphrase)
supports LVM (even volume groups spanning multiple drives)
supports LVM on LUKS (i.e. encrypted LVM)
supports Linux RAID

*kw* · July 31, 2025 at 8:43 AM

Ich könnte gerade....

Gestern erfolgreich den Duplicati Job abgewickelt (sdd1), offline
Aktuell mit der zweiten HDD (sdc1) Sync & Backup abgefrühstückt, offline
Hänge die Duplicati-Platte wieder dran...warning. Was ist? Die ist jetzt auch "sdc1"

Edit:

vermutliches Problem erkannt, zwei identische Inateck USB-Gehäuse mit identischen HDD. Die Technik geht wohl mit derselben "ID" raus und die DXP glaubt, es handelt sich nach dem Auswerfen der einen wieder um dieselbe HDD.

Es sind (natürlich) die externe db und zip-Files auf der HDD, aber er kann sie nicht zuordnen, weil der Bestand unter "sdc1" anstatt "sdd1" gelistet ist.

Edit2:

Duplicati erkennt die Daten nicht, auch wenn ich im Job das Ziel auf "sdc1" ändere. Ich meine gelesen zu haben, dass Duplicati die USB-ID egal sei, so lange der Job Daten findet.

Edit3:

...würde meine Theorie (Edit2) untermauern. Neustart DXP, HDD immer noch "sdc1", Duplicati-Job auf "sdc1" angepasst und siehe da, jetzt läuft das Backup.

*kw* · July 31, 2025 at 10:46 PM

Nur noch als abschließende Ergänzung, ich bin nicht allein.

Ein reddit Post von vor fünf Monaten

Quote from reddit

Duplicati encrypt the backups, and uses incremental backups.
The only really issue I have with this setup is this : when disconnected and reconnected, or after a NAS reboot, the DAS is mounted randomly to either /mnt/@usb/sdb1, sdc1, or sdd1. So I have to update the volume binding in the Docker compose file every week at least.

eineb · July 31, 2025 at 11:19 PM

Na wenigstens hat es einer bemerkt. Da ich das bisher nicht nutze, sichere auf eine DS und auch nur Docker, ist mir das bis jetzt noch nicht aufgefallen.

*kw* · August 1, 2025 at 6:50 AM

Aus diesem Grund hab ich für den Moment auch eine - rein funktionale - Entscheidung getroffen:

lokale Backups (2x USB) manuell mit "Sync & Backup" (kann 'tatsächlich' Jobs und HDD auseinanderhalten)
verschlüsselte Backups (der wichtigsten Daten) automatisiert zu Hetzner mit Duplicati

eineb · August 1, 2025 at 2:05 PM

Man darf allerdings nicht vergessen, die Initiativen Autopilot in Verbindung mit jars sowohl auch Duplicati, waren immerhin die Abhilfen nach nahezu fast einem Jahr, endlich ein Backup auf eine ext. USB HDD durchführen zu können.

Daß sich dann im Laufe der Zeit erst einige Unstimmigkeiten eingestellt haben war zum einen vom User und dessen Nutzungseigenschaften natürlich erst aufgefallen.

So ist es dennoch gut jetzt die Eigenschaften und evtl. Misstände der Apps zu kennen, sowohl auch mit Sync & Backup eine weitere Möglichkeit hat ein Backup auf USB HDDs zu erstellen.

[Speicher-App] ...so richtig verkorkste USB Zuweisung

Participate now!

Tags