Gelöst: Back In Time macht keinen Schnappschuss; Festplattenfehler

[fee701]

Hallo,
seit 1.10.23, vielleicht auch 6.10.23, läuft Back In Time bei mir nicht mehr, d.h. es werden die Backups nicht mehr geschrieben. Auszug der Fehlermeldungen im Back In Time-Protokoll:

========== Take snapshot (profile 1): Fri Oct 6 11:30:01 2023 ==========

[E] Schnappschussordner konnte nicht gefunden werden.
Wenn es ein Wechsellaufwerk ist, bitte verbinden!
30 Sekunden wird gewartet.
Last snapshot didn't finish but can be continued.

======== continue snapshot (profile 1): Fri Oct 6 11:45:01 2023 ========

[C] >f.st...... home/x/.config/digikamrc
[C] >f.st...... home/x/.config/dolphinrc
[C] >f.st...... home/x/.config/katemetainfos
[C] >f..t...... home/x/.config/katerc
[E] Error: rsync: [generator] recv_generator: mkdir "/media/x/baab6efb-6293-4d19-8844-dfb7361cfe33/BackInTime/backintime/debian9/x/1/new_snapshot/backup/home/x/.config/RawTherapee/profiles" failed: Read-only file system (30)

[...]

[E] Error: rsync: [receiver] mkstemp "/media/x/baab6efb-6293-4d19-8844-dfb7361cfe33/BackInTime/backintime/debian9/x/1/new_snapshot/backup/home/x/.config/RawTherapee/.options.sj18DM" failed: Read-only file system (30)

Last snapshot didn't finish but can be continued.


======== continue snapshot (profile 1): Sat Oct 7 09:15:01 2023 ========


Last snapshot didn't finish but can be continued.

========
continue snapshot (profile 1): Sat Oct 7 09:30:01 2023
========

Last snapshot didn't finish but can be continued.

[...]

======== continue snapshot (profile 1): Sun Oct 8 08:45:01 2023 ========

[C] >f.st...... home/x/.config/QtProject.conf
[C] >f.st...... home/x/.config/digikamrc
[C] >f.st...... home/x/.config/dolphinrc
[C] >f.st...... home/x/.config/gwenviewrc
[C] >f.st...... home/x/.config/katemetainfos
[C] >f..t...... home/x/.config/katerc
[C] >f.st...... home/x/.config/GIMP/2.10/action-history
[C] >f..t...... home/x/.config/GIMP/2.10/colorrc
[C] >f.st...... home/x/.config/GIMP/2.10/contextrc
[C] >f..t...... home/x/.config/GIMP/2.10/controllerrc
[C] >f.st...... home/x/.config/GIMP/2.10/devicerc
[C] >f..t...... home/x/.config/GIMP/2.10/dockrc
[C] >f..t...... home/x/.config/GIMP/2.10/menurc
[C] >f..t...... home/x/.config/GIMP/2.10/parasiterc
[C] >f..t...... home/x/.config/GIMP/2.10/pluginrc
[C] >f..t...... home/x/.config/GIMP/2.10/sessionrc
[C] >f..t...... home/x/.config/GIMP/2.10/tags.xml
[E] Error: rsync: [generator] recv_generator: mkdir "/media/x/baab6efb-6293-4d19-8844-dfb7361cfe33/BackInTime/backintime/debian9/x/1/new_snapshot/backup/home/x/.config/RawTherapee/profiles" failed: Read-only file system (30)
[C] >f..t...... home/x/.config/GIMP/2.10/templaterc
[C] >f..t...... home/x/.config/GIMP/2.10/themerc
[C] >f.st...... home/x/.config/GIMP/2.10/toolrc
[C] >f..t...... home/x/.config/GIMP/2.10/unitrc
[C] >f..t...... home/x/.config/GIMP/2.10/internal-data/custom.ggr
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-airbrush-tool
[C] >f..t...... home/x/.config/GIMP/2.10/tool-options/gimp-align-tool
[C] >f..t...... home/x/.config/GIMP/2.10/tool-options/gimp-brightness-contrast-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-bucket-fill-tool
[C] >f..t...... home/x/.config/GIMP/2.10/tool-options/gimp-by-color-select-tool
[C] >f..t...... home/x/.config/GIMP/2.10/tool-options/gimp-cage-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-clone-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-color-picker-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-convolve-tool
[C] >f..t...... home/x/.config/GIMP/2.10/tool-options/gimp-crop-tool
[C] >f..t...... home/x/.config/GIMP/2.10/tool-options/gimp-curves-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-dodge-burn-tool
[C] >f..t...... home/x/.config/GIMP/2.10/tool-options/gimp-ellipse-select-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-eraser-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-flip-tool
[C] >f.st...... home/x/.config/GIMP/2.10/tool-options/gimp-foreground-select-tool
[E] Error: rsync: [generator] recv_generator: mkdir "/media/x/baab6efb-6293-4d19-8844-dfb7361cfe33/BackInTime/backintime/debian9/x/1/new_snapshot/backup/home/x/.config/Webcamoid" failed: Read-only file system (30)

Danach folgt die read only Meldung für viele weitere Dateien. Das wiederholt sich im Wesentlichen bis heute. Mir scheint es an Schreibrechten im Sicherung-Laufwerk zu liegen, die von Back In Time verändert werden.

Ich konnte aber keine Auffälligkeiten erkennen, d.h. formal sind Schreib- und Änderungsrechte für den Nutzer gegeben. Allerdings kann ich keine neuen Verzeichnisse (mkdir oder über Dateimanager) erstellen.

Ich habe das Laufwerk mit der Sicherung heute mal "sicher entfernt", den Computer runter gefahren, wieder eingesteckt und neu gestartet. Jetzt war mir das Erstellen von Verzeichnissen wieder möglich - bis ich Back In Time gestartet habe. Dann war die Möglichkeit auf dem Laufwerk wieder blockiert.

Gestern habe ich noch Folgendes gefrickelt:

Code: Alles auswählen

find ~ -user root -ls

und

Code: Alles auswählen

sudo chown -R -v $USER:$USER /home/$USER/

War aber auch nur im Nebel stochern und hat nichts gebracht.

Vielleicht noch folgender Gedanke: Ausgangspunkt für den Fehler scheint ja gewesen zu sein, dass das Laufwerk mal nicht zur Verfügung stand. Ich glaube, das kann passieren, wenn sich ein anderer Nutzer auf meinem Rechner anmeldet und nicht abmeldet und ich mich dann mit meinem Account anmelde - das könnte durchaus passiert sein. Inzwischen ist der andere Nutzer aber definitiv abgemeldet, möglicherweise hat er aber irgendwas hinterlassen?

Hat jemand eine Idee?

[Livingston]

Ich glaube, unser Forenkollege buhtz kann da am Besten weiterhelfen. Der entwickelt backintime kräftig mit.

[aryoda]

> Ausgangspunkt für den Fehler scheint ja gewesen zu sein, dass das Laufwerk mal nicht zur Verfügung stand.
> Ich glaube, das kann passieren, wenn sich ein anderer Nutzer auf meinem Rechner anmeldet und nicht abmeldet und ich mich dann mit meinem Account anmelde - das könnte durchaus passiert sein.
> Inzwischen ist der andere Nutzer aber definitiv abgemeldet, möglicherweise hat er aber irgendwas hinterlassen?

@fee701 Ich bin auch einer der (neuen) Entwickler für die Wartung und Bugfixing von BackInTime. Könntest du bitte

• den Mountpunkt prüfen (wenn er immer der selbe ist):
  Bist du noch Owner und hast Schreibrechte (BTW: Das "x" in "/media/x/" ist seltsam, aber ich gehe davon aus, dass hier ein sensitiver Name stehen würde und daher durch einen Platzhalter ersetzt wurde...)

  Code: Alles auswählen

  ls -l /media/x/

• Einen Dateisystem-Check der ext. HDD durchführen (wurde sie vielleicht getrennt, bevor der Schreibcache geleert wurde?): Disk Manager ("Disks") > ext. HDD auswählen > Zahnrad > Dateisystem überprüfen
• Falls das nicht hilft: Könntest du bitte deine BackInTime-Konfiguration hier als Screenshot posten (sensitive Daten anonymisieren und schwärzen; ich muss verstehe, wie gemountet wird).

[fee701]

Ich bin der mysteriöse Mr. x

Also

Code: Alles auswählen

ls -l /media/x/

(ohne ~) ergibt

insgesamt 4
drwxr-xr-x 6 x x 4096 18. Okt 08:20 baab6efb-6293-4d19-8844-dfb7361cfe33

Dateisystem überprüfen ergab Fehler:

Error checking filesystem on /dev/sdc1: Process reported exit code 12:
e2fsck 1.46.2 (28-Feb-2021)
e2fsck: aborted
(udisks-error-quark, 0)

Äh, dumme Frage: Wie kriege ich einen Screenshot in meine Antwort? Ich bekomme keine Bilder in die Galerie geladen.

[Livingston]

Die Bildergallerie zickt im Moment ein bisschen -> viewtopic.php?t=188144

[fee701]

Anbei ein Link zum ersten Screenshot. Werden Screenshots aller Registerkarten gebraucht? Oder gibt es vielleicht auch irgendwo eine config-Datei?
https://ibb.co/Xkx7Mjg

[aryoda]

Der Mountpunkt sieht OK aus von den Rechten.

Dateisystem überprüfen ergab Fehler:

Error checking filesystem on /dev/sdc1: Process reported exit code 12:
e2fsck 1.46.2 (28-Feb-2021)
e2fsck: aborted
(udisks-error-quark, 0)

Der Fehler sagt, das Ergebnis wäre 12 (= 8 + 4):
4 = Filesystem errors left uncorrected
8 = Operational error

Ich denke, dass du jetzt dringend erst mal irgendwie das Dateisystem voll reparieren musst, bevor die Schreibrechte wieder richtig funktionieren (das Dateisystem versucht, sich selbst zu schützen, wenn es korrupt ist).
Das kann alles sein, vom harmlosen Stecker abziehen ohne unmount bis hin zu einem angehenden Hardware-Defekt (bitte führe mal einen SMART-Test aus über die "Disks"-App)...

Dann kannst du (zuerst ohne, und dann mit Back In Time) prüfen, ob du wieder Dateien schreiben kannst, ohne dass dann (oder beim nächsten Mount wieder Dateisystemfehler auftreten...

Edit: Welches Dateisystem ist auf dem ext. Laufwerk eingerichtet? Wirklich EXT2/3/4 (weil e2fsck verwendet wurde) oder NTFS? Und wird das Laufwerk auch unter Windows genutzt?

[fee701]

Danke schon mal für alle Eure Antworten!
Auf der Platte ist Ext4, keine Windows-Nutzung.

Mache gerade den SMART-Test über

Code: Alles auswählen

sudo smartctl -t long /dev/sdc

Das dauert jetzt bis in die Nacht.

[fee701]

Ich glaube, dass ist in Ordnung:

Code: Alles auswählen

sudo smartctl -H /dev/sdc

ergibt:

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-26-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

[aryoda]

> SMART overall-health self-assessment test result: PASSED

Sehr schön, das macht einen Hardware-Defekt unwahrscheinlich.

Jetzt wäre es hilfreich, wenn du das Dateisystem irgendwie reparieren könntest (mal verschiedene fsck-Optionen ausprobieren...)

[fee701]

Tip Top
Habe die Platte mit gnome-disk-utility repariert und der neue Schnappschuss ist erstellt.
Danke!

[aryoda]

Habe die Platte mit gnome-disk-utility repariert und der neue Schnappschuss ist erstellt.

Perfekt, danke für die Rückmeldung!

Falls doch wieder Probleme auftauchen: Vor dem "Auswerfen" (unmount) und Abstecken der Platte hilft im Terminal ein "sync", damit der Schreib-Cache geleert wird
(das Kommando blockiert, bis alles echt physisch geschrieben wurde).

[fee701]

Danke. sync umount wäre ja vielleicht was für ein kurzes bash-script

[MSfree]

Danke. sync umount wäre ja vielleicht was für ein kurzes bash-script

umount sorgt bereits dafür, daß alle gecachten Daten auf dem Datenträger landen. sync ist hier also doppelt gemoppelt und damit überflüssig.

[aryoda]

> umount sorgt bereits dafür, daß alle gecachten Daten auf dem Datenträger landen. sync ist hier also doppelt gemoppelt und damit überflüssig.

Guter Hinweis, danke!

Ich habe mir einfach ein manuelles sync im Terminal vor dem Auswerfen (via GUI) angewöhnt, weil ich manchmal nur auf "Auswerfen" geklickt und das Laufwerk abgesteckt habe, ohne
genauer hinzusehen, ob der unmount schon fertig ist. Bei manuellem sync merke ich eindeutig, wann alles geschrieben wurde (und sehe auch, wie lange das manchmal noch dauert, v. a. bei langsamen USB-Sticks).

[MSfree]

Ich habe mir einfach ein manuelles sync im Terminal vor dem Auswerfen (via GUI) angewöhnt, weil ich manchmal nur auf "Auswerfen" geklickt und das Laufwerk abgesteckt habe

sync schreibt nicht nur den Cache das USB-Sticks zurück sondern auch die Caches aller gemounteten Festplatten und/oder SSDs. Da wird also letztlich "zu viel" gesyct, was dann länger als nötig dauert.

Wenn man schon das Terminal bemüht, um einen Befehl abzusetzen, kann man auch gleich umount eingeben. Das synct dann auch nur die Caches für das zu unmountende Gerät und beläßt alle anderen Caches im RAM.