Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
18.10.2021, 12:56:52

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
  • Mitglieder insgesamt: 25993
  • Letzte: KappaAR
Statistiken
  • Beiträge insgesamt: 758419
  • Themen insgesamt: 60950
  • Heute online: 431
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema:  qt-fsarchiver  (Gelesen 8582 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Re: qt-fsarchiver
« Antwort #135 am: 19.09.2021, 17:43:47 »
Bin aus dem Kurzurlaub zurück.

Ich kann jetzt endlich den Fehler nachvollziehen. Die Datei zahlen.txt ist der Übeltäter. In der Zeile 11 ist Zahl 10 und p eingetragen. Diese Zahl wird in dem Moment geschrieben, wenn von qt-fsarchiver-terminal die Rückmeldung kommt: Sicherung beendet.
Wenn die Datei zahlen.txt nicht gelöscht ist, wird diese Datei so ausgewertet, dass die Sicherung beendet ist und zeigt dann sofort die 100% an und dass die Sicherung erfolgreich gewesen ist.

Dieses Problem habe ich schon lange erkannt und am Anfang des Programms sollten auch alle txt-Dateien in /.conf/qt-fsarchiver gelöscht werden.
Was bei mir auch der Fall ist. Wobei ich Bedenken habe, dass dies auf manchen Rechner nicht funktioniert. Diese Problem müsste eigentlich lösbar sein.

Ich habe unter dem bereits bekannten Link https://sourceforge.net/projects/qt-fsarchiver/files/deb%20packages/Mint/test/ drei neue Testdateien veröffentlicht. Die eingebauten Pausen sind wieder weg, Ganz am Anfang des Programms erscheint ein Hinweis mit der Frage, ob alle txt-Dateien gelöscht sind. Bitte in dem Ordner /.conf/qt-fsarchiver nachsehen, ob es tatsächlich so ist.
Wenn die Sicherung beginnt, wird nochmals nachgefragt, ob eine zahlen.txt-Datei vorhanden ist. Zweckmäßig ist es auch, den Inhalt des /.conf/qt-fsarchiver Ordners in einem Dateimanager zu verfolgen. Wichtig ist, dass alle Dateien außer der conf-Datei bei Programmende gelöscht werden.

Ich habe beim Testen heute 30 mal und mehr Linux-Mint gesichert. Habe allerdings immer gewartet, bis im Terminal angezeigt wurde, dass die Sicherung erfolgreich war. Erst dann habe ich qt-fsarchiver geschlossen, auch dann, wenn es nicht korrekt beendet wurde.

Hallo rj5156:
Das ist natürlich nicht schön, was Dir da passiert ist.
Wie hast Du qt-fsarchiver beendet? Mit dem roten Kreuz oder mit Escape oder mit dem Button Programm beenden?
Ein Warnhinweis bei dem roten Kreuz ist sicherlich sinnvoll. Habe ein Warnhinweis testweise eingebaut, aber egal, ob ich tatsächlich beenden will oder nicht, die Oberfläche schließt sich. Weiß im Moment nicht, ob sich das Schließen der Oberfläche nach Betätigung des roten Kreuzes irgendwie aufhalten lässt. Vielleicht kennt sich jemand aus und hat einen Tipp.

Wenn der Startsektor im Legacy-Modus defekt ist, lässt sich der sehr einfach wiederherstellen: Wenn Du mit qt-fsarchiver den MBR gesichert hast, schreibst Du einfach mit einer Live-DVD den MBR und den verborgenen Bereich zurück. Die Partitionstabelle schreibe ich normalerweise nicht zurück, da ich nicht sicher bin, ob ich an der Aufteilung der Festplatte sich was geändert hat.

Beim UEFI Modus habe ich folgende Entdeckung gemacht:

Bei einer alten Festplatte habe ich den GPT (auch mit qt-fsarchiver) gesichert. Es war ein altes Windowssystem darauf. Ich habe mit gparted eine neue GPT-Partition erstellt, die gesamte Festplatte mit ext4 formatiert. Danach habe ich den gesicherten GPT zurückgeschrieben. Die vorherige Aufteilung der Festplatte war wieder vorhanden. Und da sich an den Inhalten zwischen dem Sichern und Zurückschreiben sich nichts geändert hat, waren auch alle Daten noch vorhanden!!

Ich könnte mir in Deinem Fall die Wiederherstellung so vorstellen. GPT zurückschreiben. Dann zusätzlich die Efi-Boot-Partition zurückschreiben. (normalerweise /dev/sda1, auch mit qt-fsarchiver gesichert). Und zusätzlich die Betriebssystempartition.

Wenn das Hauptproblem gelöst ist, werde ich mich noch um die anderen Dinge kümmern, die hier angesprochen wurden.

Grüße aus Südbaden






Re: qt-fsarchiver
« Antwort #136 am: 19.09.2021, 18:00:36 »
schnelle Rückmeldung zu den neu veröffentlichen Testdateien
- Datei(en) downloaden
- Datei "ausführbar" machen
- Datei umbenennen in "qt-fsarchiver"
- dann im Terminal starten

Re: qt-fsarchiver
« Antwort #137 am: 19.09.2021, 18:23:28 »
@Mint-Dieter
ah es geht weiter.

Testbedingungen aktuelles LM20.2 Cinnamon und qt-fsarchiver 0.8.6-4 Testversion.
kuehhe1@LM20-2-Test:~$ inxi -S
System:    Host: LM20-2-Test Kernel: 5.4.0-84-generic x86_64 bits: 64 Desktop: Cinnamon 5.0.5 Distro: Linux Mint 20.2 Uma
kuehhe1@LM20-2-Test:~$

Unter Beobachtung des Verzeichnises: ~/.config/qt-fsarchiver/ mit einer darin befindlichen qt-fsarchiver.conf hab ich die nachfolgenden Schritte ausgeführt.

Nach Download, Umbenennen und Ausführbar setzen den neuen Version 0.8.6-4 lässt sie sich im Terminal Starten, zeigt einen Hinweis auf das Entfernen der *.txt Dateien, erstellt die Datei: den.nfo.cpt, nach Klick auf OK werden die Dateien: disk2.txt  und: running.txt erstellt dabei wird die vorhandene:  qt-fsarchiver.conf  eingelesen und das GUI öffnet sich.

Terminal Rückmeldung kuehhe1@LM20-2-Test:~$ '/home/kuehhe1/Schreibtisch/qt-fsarchiver'
qt5ct: using qt5ct plugin
qt5ct: D-Bus global menu: no
befehl "/usr/sbin/qt-fsarchiver.sh  5 /home/kuehhe1/.config/qt-fsarchiver *.txt 2>/dev/null"
conf einlesen korrekt sleepfaktor 4

Sicherung in Arbeit.....

Sicherung einer /home Partition erfolgreich durchlaufen.
Es wurde ein Warhinweis (Popup) wegen der möglicherweise vorhandenen Datei: zahlen.txt eingeblendet. Nach Kontrolle im Verzeichnis; Datei nicht vorhanden und Klick auf OK gings weiter. Die Sicherung begann, Dateien wurden gezählt und im GUI angezeigt. Am Ende erfolgte der 100% Fertig-Popup Hinweis.

Die Terminalrückmeldungen der Sicherung:kuehhe1@LM20-2-Test:~$ '/home/kuehhe1/Schreibtisch/qt-fsarchiver'
qt5ct: using qt5ct plugin
qt5ct: D-Bus global menu: no
befehl "/usr/sbin/qt-fsarchiver.sh  5 /home/kuehhe1/.config/qt-fsarchiver *.txt 2>/dev/null"
conf einlesen korrekt sleepfaktor 4
befehl "/usr/sbin/qt-fsarchiver.sh  5 /home/kuehhe1/.config/qt-fsarchiver/zahlen.txt 2>/dev/null"
umount: /dev/nvme0n1p8: nicht eingehängt.
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes kopiert, 0,000327169 s, 1,6 MB/s
Befehl parameter "fsarchiver" "savefs" "-z3" "-j4" "-o" "--exclude=.snapshots" "/mnt/Recover-Mint/MintBackUpFiles/qt-fsarchiver-HP470/nvme0n1p8-lm20.2-home-19-9-2021.fsa" "/dev/nvme0n1p8" "" "" "" 8
Legacy compression methods (-z) are deprecated.
It is recommended to switch to zstd using the -Z option.
Please read "http://www.fsarchiver.org/Compression" for more details.
src/filesys.c#140,devcmp(): Warning: [/dev/fuse] is not a block device
Es müssen insgesamt 47760  Verzeichnisse bzw. Dateien gesichert werden.
[ Anzahl Dateien  prozentualer Anteil
 Statistics for filesystem 0           
* files successfully processed:....regfiles=43516, directories=4205, symlinks=27, hardlinks=13, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
thread1Ready
Programm korrekt beendet
kuehhe1@LM20-2-Test:~$

Nach der Sicherung habe ich erneut eine Sicherung gestartet und testhalber auf den Schliessen Knopf in der Menüleiste des GUI geklickt, worauf hin sich das GUI schloss, im Terminal und über die Systemverwaltung war aber weiterhin Aktivität vorhanden. Die Sicherung wurde auch im Sicherungsverzeichnis erstellt, anschließend war in der Systemüberwachung keine Aktivität von qt-fsarchiver ersichtlich, anscheinend automatisch beendet.
Terminalrückmeldungen nach Klick auf Beenden:kuehhe1@LM20-2-Test:~$ '/home/kuehhe1/Schreibtisch/qt-fsarchiver'
qt5ct: using qt5ct plugin
qt5ct: D-Bus global menu: no
befehl "/usr/sbin/qt-fsarchiver.sh  5 /home/kuehhe1/.config/qt-fsarchiver *.txt 2>/dev/null"
conf einlesen korrekt sleepfaktor 4
befehl "/usr/sbin/qt-fsarchiver.sh  5 /home/kuehhe1/.config/qt-fsarchiver/zahlen.txt 2>/dev/null"
umount: /dev/nvme0n1p8: nicht eingehängt.
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes kopiert, 0,000404659 s, 1,3 MB/s
Befehl parameter "fsarchiver" "savefs" "-z3" "-j4" "-o" "--exclude=.snapshots" "/mnt/Recover-Mint/MintBackUpFiles/qt-fsarchiver-HP470/nvme0n1p8-lm20.2-home-19-9-2021.fsa" "/dev/nvme0n1p8" "" "" "" 8
Legacy compression methods (-z) are deprecated.
It is recommended to switch to zstd using the -Z option.
Please read "http://www.fsarchiver.org/Compression" for more details.
src/filesys.c#140,devcmp(): Warning: [/dev/fuse] is not a block device
Es müssen insgesamt 47760  Verzeichnisse bzw. Dateien gesichert werden.
[ Anzahl Dateien  prozentualer Anteil
      bin in del_mediafolder           
 Statistics for filesystem 0            0%             
* files successfully processed:....regfiles=43516, directories=4205, symlinks=27, hardlinks=13, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0


Das Sicherungsverzeichnis, relevant sind nur die Dateien vom 19.09.2021kuehhe1@LM20-2-Test:/mnt/Recover-Mint/MintBackUpFiles/qt-fsarchiver-HP470$ ls -la
insgesamt 27593036
drwxrwxrwx 2 kuehhe1 kuehhe1        4096 Sep 19 18:30 .
drwxrwxrwx 4 kuehhe1 kuehhe1        4096 Jul 24  2020 ..
-rw-r--r-- 1 root    root       42353398 Sep 17 20:06 nvme0n1p1-UEFI-17-9-2021.fsa
-rw-r--r-- 1 root    root            512 Sep 17 20:06 nvme0n1p1-UEFI-17-9-2021.pbr
-rw-rw-r-- 1 kuehhe1 kuehhe1         296 Sep 17 20:06 nvme0n1p1-UEFI-17-9-2021.txt
-rw-r--r-- 1 root    root    14033200027 Sep 17 19:47 nvme0n1p6-lm20.2-root-17-9-2021.fsa
-rw-r--r-- 1 root    root            512 Sep 17 19:39 nvme0n1p6-lm20.2-root-17-9-2021.pbr
-rw-rw-r-- 1 kuehhe1 kuehhe1         347 Sep 17 19:39 nvme0n1p6-lm20.2-root-17-9-2021.txt
-rw-r--r-- 1 root    root     2601446998 Sep 17 19:11 nvme0n1p8-lm20.2-home-17-9-2021.fsa
-rw-r--r-- 1 root    root            512 Sep 17 19:09 nvme0n1p8-lm20.2-home-17-9-2021.pbr
-rw-rw-r-- 1 kuehhe1 kuehhe1         344 Sep 17 19:09 nvme0n1p8-lm20.2-home-17-9-2021.txt
-rw-r--r-- 1 root    root     2597838256 Sep 19 18:51 nvme0n1p8-lm20.2-home-19-9-2021.fsa
-rw-r--r-- 1 root    root            512 Sep 19 18:49 nvme0n1p8-lm20.2-home-19-9-2021.pbr
-rw-rw-r-- 1 kuehhe1 kuehhe1         344 Sep 19 18:49 nvme0n1p8-lm20.2-home-19-9-2021.txt
-rw-r--r-- 1 root    root     8980356477 Sep 17 20:20 nvme0n1p9-lm20.2-test-17-9-2021.fsa
-rw-r--r-- 1 root    root            512 Sep 17 20:12 nvme0n1p9-lm20.2-test-17-9-2021.pbr
-rw-rw-r-- 1 kuehhe1 kuehhe1         347 Sep 17 20:12 nvme0n1p9-lm20.2-test-17-9-2021.txt
kuehhe1@LM20-2-Test:/mnt/Recover-Mint/MintBackUpFiles/qt-fsarchiver-HP470$
« Letzte Änderung: 19.09.2021, 19:24:27 von kuehhe1 »

Re: qt-fsarchiver
« Antwort #138 am: 19.09.2021, 18:24:13 »
hier bei LM 20.2 Cinnamon hat sich nur geringfügig etwas zu meinen o.g. Aussagen geändert - siehe Antwort #99
- aktuell wird ein korrekter Start nur ausgeführt wenn die Datei "den.nfo.cpt" im Ordner vorhanden ist ODER der Ordner leer ist.

EDIT:
- bei Debian11 Cinnamon verhält es sich hier exakt wie für LM 20.2 Cinnamon beschrieben
 
« Letzte Änderung: 19.09.2021, 18:41:58 von billyfox05 »

Re: qt-fsarchiver
« Antwort #139 am: 19.09.2021, 22:48:47 »
Wenn ich das richtig verstanden habe, sind das ja gute Reaktionen.

Die Wiederherstellung der GPT-Partition wollte ich testen, ging aber gründlich daneben.
Ich startete eine Live-DVD mit qt-fsarchiver.
Bei meiner  Festplatte mit 6 Betriebssystemen legte ich mit gparted eine neue GPT-Partitionstabelle an. Natürlich alle Daten futsch.
Dann schrieb ich die zuvor gesicherte GPT-Partionstabelle zurück. In gparted konnte ich erkennen, dass die ehemalige Aufteilung noch vorhanden waren, aber die Daten waren nicht mehr vorhanden.
Die Partitionsaufteilung war zwar korrekt vorhanden, ich musste aber die einzelnen Partitionen neu formatieren. Wenn ich es noch richtig in Erinnerung war, konnten die Partitionen von qt-fsarchiver ohne Formatierung nicht erkannt werden.
Dennoch ging die Wiederherstellung schnell.
Efi-Boot-Partition zurückschreiben, dann die 6 Betriebssysteme, insgesamt 9 Partitionen.
So hatte ich es mir nicht vorgestellt. Dennoch in knapp 1 Stunde war der vorherige Zustand wieder da.

Grüße aus Südbaden

Re: qt-fsarchiver
« Antwort #140 am: 19.09.2021, 23:03:05 »
Habe noch etwas Wichtiges vergessen.
Nachdem die Platte komplett leer war, konnte ich die GPT-Partitionstabelle nicht zurückschreiben. Da qt-fsarchiver keine GPT-Formatierung erkennen konnte, konnte das Programm mit der gesicherten Partitionstabelle nichts anfangen.
Ich musste zunächst mit gparted eine GPT-Partionstabelle erstellen und die gesamte Festplatte mit einer Partition formatieren.
Nun klappte das Zurückschreiben der gesicherten "alten" Partitionstabelle.

Re: qt-fsarchiver
« Antwort #141 am: 20.09.2021, 04:59:13 »
...Da qt-fsarchiver keine GPT-Formatierung erkennen konnte, konnte das Programm mit der gesicherten Partitionstabelle nichts anfangen...

Als vorsichtiger mensch sichere ich mir die partitionsdaten mit
"sfdisk -d /dev/sda > part_table_sda"
Und schreiben sie mit "sfdisk /dev/sda < part_table_sda" zurück.

Vor einer sicherung bereinigt man das system mit z.b. BleachBit, und führt ein
manuelles trim aus (zeitersparnis).

Re: qt-fsarchiver
« Antwort #142 am: 22.09.2021, 17:03:23 »
Hallo Coin,

qt-fsarchiver verwendet den gleichen Befehl. Und wenn /dev/sda (beispielweise) erkannt wird, kann die Partitionstabelle auch zurückgeschrieben werden.

Bin dabei in Kürze eine neue Version herausgeben. Dabei wird unterbunden zu sichern oder zurückzuschreiben, wenn die Datei zahlen.txt existiert.
Das Programm wird beendet. Es gibt allerdings den Hinweis, die Datei.txt manuell zu entfernen.

Ich denke, dass somit die Systemabstürze nicht mehr vorkommen können.

Grüße aus Südbaden

Re: qt-fsarchiver
« Antwort #143 am: 22.09.2021, 18:21:54 »
Hallo Mint_Dieter,
Der Hinweis zum Löschen einer existierenden "zahlen.txt" ist schon mal ein Schritt in die richtige Richtung.

Aber wenn doch jetzt bekanntermaßen eine vorhandene Datei: "~/.conf/qt-fsarchiver/zahlen.txt" einen sauberen Programmstart verhindert bzw. zu Fehlern führt wäre es doch sinnvoller einen Befehl in qt-fsarchiver zu integrieren um das Löschen von: ~/.conf/qt-fsarchiver/*.txt Dateien zu automatisieren. Wobei die qt-fsarchiver.conf vom Löschen auszuschließen ist da sie die Benutzereinstellungen beinhaltet und normalerweise einen Start von qt-fsarchiver nicht negativ beeinflußt.
« Letzte Änderung: 22.09.2021, 18:35:29 von kuehhe1 »

Re: qt-fsarchiver
« Antwort #144 am: 22.09.2021, 18:50:14 »
Wobei die qt-fsarchiver.conf vom Löschen auszuschließen ist da sie die Benutzereinstellungen beinhaltet und normalerweise einen Start von qt-fsarchiver nicht negativ beeinflußt. 
bei dir - bei mir beeinflußt sie negativ  :-X
ABER - ich kann damit leben - da ich den Ordner vor dem Programmstart komplett leere.
« Letzte Änderung: 22.09.2021, 18:59:37 von billyfox05 »

Re: qt-fsarchiver
« Antwort #145 am: 22.09.2021, 19:35:45 »
@billyfox05
Sicher das die qt-fsarchiver.conf Probleme bereitet? Denn in deiner Antwort #99 sind ne Menge anderer Dateien beim Beenden übrig die wenn sie beim nächsten Start vorhanden sind auch Hier mit Antwort #103 zu Fehlern führten.

Wenn ein Programm über seine eigene *.conf stolpert wäre generell etwas faul.
« Letzte Änderung: 22.09.2021, 19:41:25 von kuehhe1 »

Re: qt-fsarchiver
« Antwort #146 am: 22.09.2021, 19:39:18 »
Sicher das die qt-fsarchiver.conf Probleme bereitet?
Hier JA - lies einmal Antwort #98

EDIT: lies mal die Eröffnung dieses Themas von @Lucie
damit du nicht soviel scrollen musst
https://www.linuxmintusers.de/index.php?topic=70382.msg910341#msg910341
« Letzte Änderung: 22.09.2021, 19:43:33 von billyfox05 »

Re: qt-fsarchiver
« Antwort #147 am: 22.09.2021, 19:46:48 »
Merkwürdig, dass es auf einigen Systemen nicht funktioniert, aber vielleicht liegt die Ursache ganz woanders:
Andererseits wird hier im Bord laut SuFu Ergebnisse qt5-fsarchiver bzw. seit 2020 über qt-fsarchiver diskutiert aber in den gefundenen Beiträgen wurde nie über eine mangelhafte Funktion geklagt. Kann es sein das diese neue Problematik am LM Unterbau oder qt liegt?
« Letzte Änderung: 22.09.2021, 19:52:06 von kuehhe1 »

Re: qt-fsarchiver
« Antwort #148 am: 22.09.2021, 23:23:05 »
Ich bin überzeugt davon, dass alleine das Vorhandensein von der Datei zahlen.txt Probleme macht. Alle anderen Dateien können keine Probleme machen.

Ansonsten ist es mir ein Rätsel, weshalb der Befehl
sudo /home/username/.config/qt-fsarchiver/*.txtam Anfang des Programms die Dateien nicht löscht. (Dieser Befehl war schon immer vorhanden und wurde nicht erst jetzt eingefügt):

Vor dem Beginn der Sicherung oder vor dem  Beginn des Zurückschreibens wird ein weiterer Versuch gemacht, die zahlen.txt Datei zu löschen. Und wenn sie existiert, wird eben fsarchiver nicht aufgerufen und somit auch nicht gesichert, um Abstürze zu vermeiden.

qt-fsarchiver existiert seit dem 12. November 2018  und es hat mit dem Code in diesem Bereich keinerlei Probleme gegeben. Warum jetzt auf einmal?

Bei wiederholten Aufrufen des Programms kam, wie geschildert, es zu Systemverlusten. Und so was muss unbedingt vermieden werden. Deshalb gebe ich die neue Version kurzfristig heraus, um solche schwer wiegenden Dinge zu vermeiden. Weitere Wünsche werden in dieser Version aus Zeitgründen nicht einprogrammiert.

Wenn es mal weitere Erkenntnisse gibt, warum das Löschen der Dateien nicht funktioniert, kann es ja in eine weitere Version eingebaut werden.


Re: qt-fsarchiver
« Antwort #149 am: 23.09.2021, 09:11:21 »
qt-fsarchiver existiert seit dem 12. November 2018  und es hat mit dem Code in diesem Bereich keinerlei Probleme gegeben. Warum jetzt auf einmal?
SORRY - aber das kann nicht stimmen  :-X

Wenn im Programm tatsächlich
sudo /home/username/.config/qt-fsarchiver/*.txteingetragen ist - funktioniert es aus zwei Gründen nicht
1. es fehlt der Löschbefehl (remove - rm )
2. "username" müsste in der Konstellation manuell geändert werden - bei mir z.B. auf "billyfox" 

In meinem "Scriptchen" benutze ich
rm -r $HOME/.config/qt-fsarchiver/*.*("$HOME" siehe @aexe weiter oben und "*.*" weil hier auch die "conf-Datei" Probleme macht)

$HOME ist nicht gleich /home ?!
« Letzte Änderung: 23.09.2021, 09:34:30 von billyfox05 »