[Gelöst] Luckybackup failed

[gm2601]

Hallo Gurus,

Seit heute bekomme ich bei der Dasi folgende Meldung:

.....
guenter/Filme/Sort_film

          2.50K 100%    3.00kB/s    0:00:00  
          2.50K 100%    3.00kB/s    0:00:00 (xfr#10191, to-chk=18797/29788)
guenter/Filme/avidemux_2.7.0.appImage


         32.77K   0%   39.07kB/s    0:17:14  

rsync: [sender] write error: Broken pipe (32) rsync error: error in socket IO (code 10) at io.c(829) [sender=3.1.3] 
.
    -----| Sichere Profile, Logdateien und Schnappschuss-Daten -> Fail |-----
Ausführung der Aufgabe : Back_home_SDD, beendet =====================================

Sichern und entfernen der logfiles hat nichts gebracht, im Gegenteil, die "Broken pipe" kommt von Mal zu Mal schneller.

Vielen Dank im voraus für erfolgreiche Tipps

Nachtrag: Ich hatte vergessen zu erwähnen, dass ich beim ersten Lauf das Backup-Device nicht angeschlossen hatte.

 

[Anonymous]

Danke für den Statusbericht zu deiner Sicherung, :schockiert: leider lässt sich damit nicht sehr viel anfangen ohne deine genaue Konfiguration, oder noch viel besser, den genauen rsync Befehl zu kennen bei dem der Fehler auftritt.

Mal rein aus der Interpretation der Fehlermeldung würde ich aus meiner Glaskugel orakeln, dein Dateisystem auf dem du sichern willst ist einfach nur voll, oder nicht dort gemountet wo rsync hinschreiben will.

robi

 

[gm2601]

.....habe im Web einen Hinweis auf "insufficient disk space" gefunden, was mich jedoch wundern sollte.

Kann mir das Löschen der Destination

df -h
/dev/sdd3       917G     73G  844G    8% /run/media/guenter/HD_Free

und anschließendem "jungfäulichen" Backup helfen?
Sollte mich wundern, denn Source ist /home und da sind laut filelight nur 66,9 GiB belegt. :???:

Hi Robi,
wir schrieben wohl gleichzeitig.

Ich kann Dir mangels eigenem Wissen nur das Profile von Luckybackup abkupfern
Name:Back_home_SDD
Typ:Sichere Quelle innerhalb des Ziels
Quelle:/home/guenter
Ziel:/run/media/guenter/HD_Free/Back_home_SDD/

Welche Info würdest Du noch brauchen?

 

[josef-wien]

Du bist sicher, daß das Sicherungsmedium zum Zeitpunkt der Sicherung am richtigen Ort eingehängt war?

 

[Igel1954]

.....habe im Web einen Hinweis auf "insufficient disk space" gefunden, was mich jedoch wundern sollte.

Kann mir das Löschen der Destination

df -h
/dev/sdd3       917G     73G  844G    8% /run/media/guenter/HD_Free

und anschließendem "jungfäulichen" Backup helfen?
Sollte mich wundern, denn Source ist /home und da sind laut filelight nur 66,9 GiB belegt. :???:

Auf deiner Disk sind noch 844G frei, 917G ist die Gesamtgröße der Disk, 73G sind belegt, das sind ca. 8%. Das ist die Anzeige des Commands

df -h

Ich würde wie @josef-wien darauf tippen, dass zum Zeitpunkt des rsync die Disk nicht gemounted war.

 

[gm2601]

Hallo Josef, hallo Igel

die Backupdisk mit drei Partitionen war für die Dasi noch nie an einem anderen USB-Port angeschlossen und die Daten haben. seit ich luckybackup einrichtete, ihren Weg in die Partition HD_Free stets gefunden.

Wie ich im Nachtrag zu Beitrag 1 bereits erwähnte, war die Disk beim ersten Versuch gestern nicht angeschlossen, aber der Abbruch erfolgte erst nach einer gewissen Zeit (glaube bald 30%). Gestört haben mich die Abbrüche erst ab dem zweiten Versuch, denn ich meinte, MIT Disk sollte alles funktionieren wie vorher. Denkste! :???:

lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 152d:0579 JMicron Technology Corp. / JMicron USA Technology Corp.   <------ Die Backupplatte
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 2040:8268 Hauppauge 
Bus 001 Device 003: ID 14cd:125d Super Top 
Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ich vermute, dass irgendwo dieser primäre Fehler gespeichert ist und nachfolgende Bakups verhindert, aber warum erst nach dem der Backup schon einige Zeit aktiv ist?

 

[gm2601]

Hallo Josef, hallo Igel

die Backupdisk mit drei Partitionen war für die Dasi noch nie an einem anderen USB-Port angeschlossen und die Daten haben. seit ich luckybackup einrichtete, ihren Weg in die Partition HD_Free stets gefunden.

Wie ich im Nachtrag zu Beitrag 1 bereits erwähnte, war die Disk beim ersten Versuch gestern nicht angeschlossen, aber der Abbruch erfolgte erst nach einer gewissen Zeit (glaube bald 30%). Gestört haben mich die Abbrüche erst ab dem zweiten Versuch, denn ich meinte, MIT Disk sollte alles funktionieren wie vorher. Denkste! :???:

lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 152d:0579 JMicron Technology Corp. / JMicron USA Technology Corp.   <------ Die Backupplatte
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 2040:8268 Hauppauge 
Bus 001 Device 003: ID 14cd:125d Super Top 
Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ich vermute, dass irgendwo dieser primäre Fehler gespeichert ist und nachfolgende Bakups verhindert, aber warum erst nach dem der Backup schon einige Zeit aktiv ist?

NACHTRAG:
Nachdem ich gerade ".luckyBackup/snaps/default-Back_home_SDD-20210405173817.changes.log" gelöscht habe, lief der Backup lt Ausgabe fehlerfrei durch. Ob das stimmt, muss ich erst mal prüfen.

 

[josef-wien]

/run ist üblicherweise ein tmpfs, d. h. es liegt im Hauptspeicher, und in der Standarddefinition darf es den halben Hauptspeicher belegen. rsync legt am Ziel noch nicht vorhandene Verzeichnisse an. Irgendwann ist nicht mehr genügend Platz für die nächste Datei verfügbar, und die Sicherung wird abgebrochen.

Beim darauffolgenden Anschließen der Platte stellt udisks2 fest, daß /run/media/guenter/HD_Free schon vorhanden ist, und nimmt daher /run/media/guenter/HD_Free1 als Einhängepunkt. Die Sicherung verwendet aber nach wie vor HD_Free, und nachdem es die ersten Dateien am Ziel schon in der aktuellen Version gibt, kommt das Ende schneller.

An welchem Anschluß die Platte erfolgt, ist belanglos, denn udisks2 verwendet den label des Dateisystems.

 

[gm2601]

Hallo Josef,

danke Dir für die Erklärung, auch wenn tempfs bei mir auf wenig, udisks2 auf so gut wie keinen fruchtbaren Boden fallen. Der Gedanke, dass rsync das RAM teilweise auslastet, kam mir zwar auch, aber sicher nicht aus Kenntnis dessen, was rsync en detail treibt.

Das Null-file /root/.luckyBackup/default-Back_home_SDD-20210406131644.changes.log ist dann eine Art Lock-file?

Der Backup lief nun zweimal erfolgreich und auch die neuesten Bilder meiner Enkel waren mit drin.

Ich setz die Nachfrage auf "gelöst", habe aber noch eine Frage, die nichts mit dem Ausgangsproblem zu tun hat. Kann man hin und wieder den Käse in
~/.mozilla/firefox/xvv2vufq.default-esr78/storage/default/...
löschen, ohne Ärger heraufzubeschwören?

 

[Gräfin Klara]

..Kann man hin und wieder den Käse in
~/.mozilla/firefox/xvv2vufq.default-esr78/storage/default/...
löschen, ohne Ärger heraufzubeschwören?

Hält local + session storage (ist eine dom sqlite Datenbank)
Firefox schließen, alles löschen außer about.* und *.extensions.*
Kein Problem, wird bei Besuch der Seiten aber wieder erstellt.

 

[gm2601]

[...]
Firefox schließen, alles löschen außer about.* und *.extensions.*
Kein Problem, wird bei Besuch der Seiten aber wieder erstellt.

Danke!
about.* habe ich in dem directory nicht, alles weitere hat geklappt und wenn wieder lästig viel drin ist, putze ich wieder.