Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8556
|
Naja, das ist recht einfach:
Das habe ich dann wohl falsch verstanden. Ich fand das eben nicht so einfach zu lesen. Vergrößern hat leider auch nicht geholfen. Es wurde zu einem grünen "Brei" mit dunklem "Schleim". Achtung Ironie: Das mit den Codeblock scheint wohl immer wieder so ein Problem zu sein. Vllt finden die User die Zeichen { } nicht oder kennen den Unterschied zwischen Alt und Alt Gr nicht. Es ist schon ein Graus. Ende von Ironie Noch sinnfreier als Bilder von Terminal-Ausgaben geht kaum.
sinnfreier ist sehr sehr diplomatisch ausgedrückt 👍
☺
|
Golgivesikel
(Themenstarter)
Anmeldungsdatum: 10. Juli 2017
Beiträge: 117
|
tut mir leid, aber Bilder sind meiner Meinung nach zumindest authentischer als der codeblock. In den kann man ja sonstwas reinkopieren.
Schade, dass es so mit Frust bei allen Beteiligten enden muss. Trotzdem vielen Dank bis hierher. Gruß MrGolgi
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8556
|
Golgivesikel schrieb: tut mir leid, aber Bilder sind meiner Meinung nach zumindest authentischer als der codeblock. In den kann man ja sonstwas reinkopieren.
Dann schadet man sich doch selber, aber die Lesbarkeit ist deutlich besser. Das Forum gibt es schon etwas länger und es hat sich so wirklich bewehrt. Und drei Terminal- Ausgaben auf einer Seite macht das auch unübersichtlich. Wenn die Bilder dann noch auf einen anderen Server abgelegt sind, ist der Thread schnell unbrauchbar, wenn die Bilder hier abgelegt sind, kann das Forum auch von anderen genutzt werden, Befehle können kopiert und ins Terminal übernommen werden. Von eine Serverseite lange Befehle fehlerfrei ist auch nicht so gut. Nur ein Paar Punkte die für unsere Arbeitsweise sprechen.
Schade, dass es so mit Frust bei allen Beteiligten enden muss.
liegt doch an dir, ob es endet. Poste doch bitte "im Codeblock" und bitte diese mal nur das. mount -l | grep -i /dev/sd Mit den beiden externen Festplatten anschlossen.
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8556
|
Viel Freude beim fehlerfreien abschreiben, wenn überhaupt geht das wenn du beides Terminal und Serverbild geöffnet sind. 😳 sudo lsblk -o NAME,FSTYPE,UUID,RO,RM,SIZE,STATE,OWNER,GROUP,MODE,TYPE,MOUNTPOINT,LABEL,MODEL Aus dem Codeblock kannst du es kopieren. Mein Beispiel ist noch lange nicht das längste.
|
MrGolgi
Anmeldungsdatum: 10. März 2017
Beiträge: 7
|
Berlin_1946 schrieb: Dann schadet man sich doch selber
Ich meine nat[rlich nicht absichtlich
liegt doch an dir, ob es endet.
Ich hatte nicht gedacht, dass ich noch Hilfe bekomme, nachdem ich so viele Widerworte gesagt habe 😉 Danke
Poste doch bitte "im Codeblock" und bitte diese mal nur das. mount -l | grep -i /dev/sd Mit den beiden externen Festplatten anschlossen.
Es waere sehr hilfreich fuer mich, wenn Du Deinen Vorschlaegen eine kurze Erlaerung anfuegen koenntest, was Du damit genau erreichen willst. Ich koennte dann viel yiegerichteter arbeiten und meine Antworten haetten fuer Dich eine bessere Trefferqute.
Hier z.B.: Geht es generell um die Platten, dann koennte ich das aus dem normalen Linux machen.
Geht es darum ob das Live/Szstem die Platten irgendwie anders mountet.
Kann man daran irgendwas ueber meinen Versuch .cache zu mounten erkennen. ubuntu@ubuntu:~$ mount -l | grep -i /dev/sd
/dev/sdb2 on /media/ubuntu/Seagate Backup Plus Drive type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) [Seagate Backup Plus Drive]
/dev/sdc1 on /media/ubuntu/MyDrive type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) [MyDrive]
ubuntu@ubuntu:~$ Das Backup liegt auf Seagate und das Ziel f[r die Wiederherstellung liegt auf MyDrive. Dort hatte ich auch versucht .cache zu mounten. Gruss MrGolgi
|
Golgivesikel
(Themenstarter)
Anmeldungsdatum: 10. Juli 2017
Beiträge: 117
|
Nachtrag:
ich habe noch mal weiter geforscht und mit googles Hilfe folgenden Artikel gefunden:
https://bugs.launchpad.net/duplicity/+bug/662442
Mein Englisch ist zwar sehr eingerostet und ich bin mit dem Fach-slang nicht vertraut, aber ich meine folgendes verstanden zu haben:
Genau der Fehler "end of file" der bei mir auftritt ist seit 2013 bekannt. Es gibt/gab anscheinend einen patch für duplicity den man selbst einspielen (und compilieren?) musste. Das bezieht aber nur darauf, dass der Prozess nicht abbricht. Die kaputten Archive sind trotzdem verloren. Insofern sind meine Mails wohl endgültig verloren. Gruß MrGolgi
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8556
|
MrGolgi schrieb: Berlin_1946 schrieb: Dann schadet man sich doch selber
Ich meine natürlich nicht absichtlich
Wenn du das so machst, ist das kaum möglich. Die Ergebnisse aus dem Terminal nicht abschreiben, sondern per „copy + paste“ einfügen Mit "copy+paste" ist gemeint das Markieren eines Textes bzw. Kommandos mit der Maus, anschließendes Kopieren und Einfügen an eine andere Stelle. Diese Methode ist oft einfacher zu handhaben als Kommandos neu ein zu tippen.
Sry, aber das hatte ich mehrfach gefragt und leider erst jetzt hast du geantwortet: Schwamm drüber, der Befehl hat den Sinn genau das abzufragen und zu schauen, ob die Mountpounts gesetzt sind.
Das Backup liegt auf Seagate und das Ziel für die Wiederherstellung liegt auf MyDrive.
Die Umstellung auf eine deutsche Tastatur im Livesystem kann über das Terminal (Tastenkombination
Strg +
Alt +
T ) erfolgen und zwar mit dem Befehl: setxkbmap de erfolgen. Du hast 3 Haupt- Sicherungen
duplicity-full.20190108T140155Z.manifest
duplicity-full.20190415T160948Z.manifest
duplicity-full.20190715T071739Z.manifest
Mein Englisch ist zwar sehr eingerostet
Da haben wir etwas gemeinsames. 😇 😊
Achtung bitte auf 2 Fragen auch 2 Antworten.
|
Golgivesikel
(Themenstarter)
Anmeldungsdatum: 10. Juli 2017
Beiträge: 117
|
Berlin_1946 schrieb: Du hast 3 Haupt- Sicherungen
duplicity-full.20190108T140155Z.manifest
duplicity-full.20190415T160948Z.manifest
duplicity-full.20190715T071739Z.manifest
Achtung bitte auf 2 Fragen auch 2 Antworten.
Mir werden alle Sicherungen seit dem 1.8.2019 angeboten. Die 3 von Dir genannten Vollsicherungen sind dabei. Ausprobiert hatte ich aber nur die inkrementellen vom 10.9. und 6.9. weil ältere für mich wenig Sinn machen. Die Sicherung auf Seagate ist das Original. Ich hatte diesen kompletten Ordner auch schon auf die andere Festplatte (MyDrive) kopiert und von dort die Wiederherstellung versucht. Genau das selbe Resultat. Gruß MrGolgi PS. Ich habe anscheinend 2 Accounts hier. Einer muss sehr viel älter sein. Ist jetzt durch Zufall bei der Anmeldung aus dem Livesystem aufgefallen. Da hatte ich erst Probleme mit dem Passwort wegen der Tastatur. Und nein, da ist kein y oder z drin.
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8556
|
Hallo Golgivesikel, du kannst auf die Zielfestplatte "MyDrive" schreiben? Im Thread waren die Test (wenn ich mich erinnere) immer nur auf die "VFAT" Platte. Sry, kann mich auch falsch erinnern. Wenn ja, beginne mal mit dem ältesten Datum.
|
Golgivesikel
(Themenstarter)
Anmeldungsdatum: 10. Juli 2017
Beiträge: 117
|
Hallo Berlin_1946, soll (muss ☹ )das im Livesystem sein? Der Versuch mit VFAT war nur einmal. Das scheitert vermutlich ja allein schon an den langen Pfadnamen und Leerzeichen darin. Wohl keine gute Idee. Ich kann auf alle Platten schreiben, auch im Livesystem. Dort hatte ich allerdings alles aus der root-shell gemacht. Ich glaube der Grund war, dass ich ja .cache auf MyDrive kopieren und dann mounten sollte. Das ging nur als root. Nicht wundern, wenn meine Antworten jetzt nicht mehr so schnell kommen. Ich habe jetzt seit Wochen fast nichts anderes am Rechner geschafft und noch wichtige andere Projekte. Da muss ich auch mal weiter kommen.
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8556
|
Golgivesikel schrieb:
Nicht wundern, wenn meine Antworten jetzt nicht mehr so schnell kommen. Ich habe jetzt seit Wochen fast nichts anderes am Rechner geschafft und noch wichtige andere Projekte. Da muss ich auch mal weiter kommen.
Kein Problem. Den Tipp mit dem Cach von Vej solltest du auch im installieren System nutzen. Denke bitte an die Einhänge1 und -2.
soll (muss ☹ )das im Livesystem sein?
Nee, war nur eine Idee zum Test, da die aus dem Live- System im "Urzustand" ist und damit vllt. besser funktioniert.
|
Golgivesikel
(Themenstarter)
Anmeldungsdatum: 10. Juli 2017
Beiträge: 117
|
Berlin_1946 schrieb: Den Tipp mit dem Cach von Vej solltest du auch im installieren System nutzen. Denke bitte an die Einhänge1 und -2.
soll (muss ☹ )das im Livesystem sein?
Nee, war nur eine Idee zum Test, da die aus dem Live- System im "Urzustand" ist und damit vllt. besser funktioniert.
Leider muss ich noch mal nachfragen: Was meinst Du mit "Einhänge1 und -2"?
Und das mit dem cache war doch nur für das Live-System nötig. Nachdem ich auf der internen Linux-Partition 110GB frei gemacht hatte liefen alle Versuche ohne irgendwelche Platzprobleme durch. Sollte man die Versuche lieber nicht noch durch einen umgemounteten cache verkomplizieren? Wie gesagt glaube ich, dass der einzige echte Fehler dieser hier war:
Fehler »librsync error 103 while in patch cycle« beim Reparieren von home/rolf/.config/google-chrome/Default/Extension State/000003.log
Fehler »First patch in sequence [<duplicity.path.ROPath instance at 0x7f7d0921ff80>] was a diff« beim Reparieren von home/rolf/.config/google-chrome/Default/Extension State/000004.log
python2: ERROR: (rs_file_copy_cb) unexpected eof on fd56
python2: ERROR: (rs_job_complete) patch job failed: unexpected end of input
Das wäre natürlich schon interessant zu sehen, ob das Archiv auch schon in der ersten Vollsicherung kaputt war. Gruß MrGolgi
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8556
|
Golgivesikel schrieb: Leider muss ich noch mal nachfragen: Was meinst Du mit "Einhänge1 und -2"?
mein Hinweis:
Den Tipp mit dem Cach von Vej solltest du auch im installieren System nutzen. Denke bitte an die Einhänge1 und -2. Vej schrieb:
Du könntest versuchen einen Ordner cache auf einem deiner externen Laufwerke zu erstellen, den Inhalt von ~/.cache dorthin zu kopieren und dann mit mount -B diesen an ~/.cache einzubinden. Das sollte dir mehr Platz im Cache verschaffen.
Siehe auch mount (Abschnitt „Einzelne-Ordner-einbinden“) und mount (Abschnitt „Einhaengepunkt“) So verstehe ich das, was Vej schrieb.
|
Golgivesikel
(Themenstarter)
Anmeldungsdatum: 10. Juli 2017
Beiträge: 117
|
Hallo Berlin_1946, mit der ältesten Vollsicherung funktioniert die Wiederherstellung einwandfrei. Auch alle Ordner von Thunderbird werden im Programm wieder korrekt angezeigt. Allerdings natürlich mit völlig veraltetem Inhalt. Insofern hilft mir das noch nicht.
Ich werde noch mal die 2. Vollsicherung probieren. Nur interessehalber. Es gibt ja leider keine Vollsicherung, die mir hilft. Ich habe allerdings eine Befürchtung bezüglich des Grundes, warum meine Archive defekt sein könnten. Deja-Dup arbeitet ja weitgehend unbemerkt im Hintergrund und braucht manchmal auch recht lange. Es ist sicher oft vorgekommen, dass ich den Rechner in Bereitschaft geschickt habe, während Deja-Dup noch aktiv war. Möglich, dass das Programm damit nicht umgehen kann. Gruß MrGolgi Nachtrag:
Auch die erste inkrementelle Sicherung nach der jüngsten Vollsicherung funktioniert. Es ist also mindestens eine inkrementelle Sicherung zwischen der und der vom 6.9. defekt.
|
Golgivesikel
(Themenstarter)
Anmeldungsdatum: 10. Juli 2017
Beiträge: 117
|
Golgivesikel schrieb:
Ich habe allerdings eine Befürchtung bezüglich des Grundes, warum meine Archive defekt sein könnten. Deja-Dup arbeitet ja weitgehend unbemerkt im Hintergrund und braucht manchmal auch recht lange. Es ist sicher oft vorgekommen, dass ich den Rechner in Bereitschaft geschickt habe, während Deja-Dup noch aktiv war. Möglich, dass das Programm damit nicht umgehen kann.
Ganz so einfach scheint es doch nicht zu sein. Inzwischen habe ich mich durch die 49 inkrementellen Sicherungen durchgearbeitet und festgestellt, dass alle bis zum 30.08.2019 offensichtlich intakt sind. Defekt ist also mindestens die vom 1.9. Ob danach noch weitere bis zum 10.9. defekt sind lässt sich natürlich nicht feststellen, da eine defekte Sicherung in der Kette vermutlich reicht, damit die Wiederherstellung scheitert. Was bleibt ist die Erkenntnis, das Deja-Dup offensichtlich defekte Archive erzeugen kann ohne den Anwender zu warnen. Bei der Wiederherstellung wird in diesem Falle eine falsche und Irreführende Meldung erzeugt, obwohl intern der tatsächliche Fehler bekannt wäre. Die Wiederherstellung funktioniert dann nur von der letzten intakten Vollsicherung bis zur ersten defekten inkrementellen Sicherung. Auch wenn in diesem Thread fast alles ein Irrweg war, so hat mir der letzte Tipp doch noch einige zusätzliche Mails (bis zum 1.9.) gerettet. Dafür noch mal vielen Dank Gruß MrGolgi alias Golgivesikel PS. Den Doppelaccount MrGolgi habe ich deaktiviert
|