Ich nutze BachInTime für Backups. Mir ist aufgefallen dass seit langem gelöschte Dateien in Backup immer wieder auftauchen und zwar in allen Snapshots bis Heute. Mussen die eigentlich nicht verschwinden und nur in alten Backups vorhanden sein? Ist das ein Bug oder eine Feature?
BackInTime und Gelöschte Dateien
Anmeldungsdatum: Beiträge: Zähle... |
|
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
Kommt auf deine Einstellungen an - BiT nutzt intern rsync und da muss die Option -delete gesetzt sein. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 24 |
Danke, und wo genau: BackInTime > Einstellungen > ??? |
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
Ich sitze am Phone, aber streng dich an - du schaffst das..... |
(Themenstarter)
Anmeldungsdatum: Beiträge: 24 |
Es gibt keine solche Option in BiT 1.0.34. |
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
Da hast du Recht... Nachträglich willkommen, hab deinen Beitragszähler auf dem Ubuntu Phone nicht gesehen. Schauen wir erst mal, ob die Option --delete überhaupt gesetzt wurde. Wenn du in den letzten Stunden ein Backup laufen hattest, gibt es hier normalerweise eine Ausgabe des rsync-Befehls, den BiT nutzt: grep rsync ~/.xsession-errors Ist das Verhalten reproduzierbar? Dazu kannst du eine Testdatei anlegen, Ordner sichern, löschen, nochmal den Ordner sichern, schauen, ob die gelöschte Testdatei noch im neuen Backup ist. Wo soll die eigentlich herkommen, wenn sie ja gelöscht ist? Aus den älteren Backups in die neueren gehuscht? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 24 |
Es ist so: BiT GUI zeigt Datei test.txt in Ordner /mnt/win/Users/Igor/Documents in alle vorherige Snapshots. Es gibt keine solche Datei in "Jetzt". Und 'ls' zeigt dasselbe: es gibt solche Datei (eher hardlink) in Snapshots und es gibt keine Datei in Ordner selbst. Ich erzeuge neue Snapshot. Dann BiT GUI zeight test.txt in neuem Snapshot und nichts in "Jetzt". grep rsync ~/.xsession-errors zeigt nichts. Das ist ein Known Bug und es sieht so dass es aufgegeben ist (Won't Fix) https://bugs.launchpad.net/backintime/+bug/406092 Ein dort beschriebene Workaround, 2 separate Profile zu erstellen für /home/igor und für /mnt/win/Users/Igor/Documents ist nicht optimal im Sinne ich kann nicht beide simultan mit einem Knopfdruck sichern. Und es funktioniert nur teilweise. Nähmlich, nach der Erstellung von 2 Profilen kann ich nun unter /mnt/win/Users/Igor/Documents Datei test.txt löschen und es ist auch in neuem Backup gelöscht. Aber wenn ich dasselbe unter /home/igor tue, dann die gelöschte Datei test.txt ist immer noch in neuem Backup vorhanden. Eine dort beschriebene Empfehlung .gvfs Ordner vom Backup zu befreien ist jetzt Standardeinstellung und bringt nichts. Eine dort beschriebene Situation mit verändertem Profileinstellung ist mir ähnlich: ich habe /media/igor/<UUID> zu /mnt/win verändert. Jetzt habe ich in Snapshots sowohl die alte /media/igor/<UUID> als auch die neue /mnt/win. Nach neue Profileinstellung habe ich noch /mnt/win in Profil 1 und /mnt/win in Profil 2. Und nichts ist in Snapshots gelöscht, weder die alte mounting points als auch die Testdateien. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 24 |
Hab etwas gefunden: in Logs für die letzte Backup für "funktionierende" Profil /mnt/win steht [C] *deleting mnt/win/Users/Igor/Documents/test2.txt in Logs für die letzte Backup für "nicht-funktionierende" Profil /home/igor steht [E] Error: rsync: opendir "/home/igor/.config/enchant" failed: Permission denied (13) [E] Error: rsync: send_files failed to open "/home/igor/Downloads/sudoers.tmp": Permission denied (13) also einige Datein haben falsche Zugriffsrechte und das ist vermutlich die Grund um die weitere Löschung von Hardlinks in Snaphot zu verhindern. Zumindest BackInTime als Root hat keine solche Probleme. Ich kann eine Datei löschen und es verschwindet auch in Backup. Entweder gibt's genug Zugriffsrechte oder hat es die erste "saubere" Snapshot ohne /media/igor/<UUID> usw nicht vorhandene Ordnern erstellt. Trotzdem ist es ein Bug. Ich würde erwarten dass BiT problematische Dateien ignoriert und einfach weiter geht. Nicht alle haben Root Zugriffsrechte um diese Lösung zu erzwingen. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 24 |
Ich habe noch getestet: wenn alle Dateien haben richtige Zugriffsrechte, alles funtioniert prima (Problem gelöst). Nebenfrage: weißt jemand wo BiT(root) seine Profile speichert? Es ist nicht in /root/.config/backintime. |
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
Finde es gerade auch nicht und in der man ebenso wenig, aber grundsätzlich kannst du sowas ganz einfach rausfinden, indem du etwas änderst/ speicherst und schnell binnen 1 min mit find nachschaust, welche Dateien sich in der letzen min gerade geändert haben: sudo find /home -mmin -1 sudo find /etc -mmin -1 |