ubuntuusers.de

Hallo zusammen,

ich nutze seit Langem Back In Time (BIT), um meine Daten-HDD (/data, 4 TB, NTFS für Dual Boot Kubuntu 22.04 und Windows 10) auf eine externe HDD zu sichern.

Jetzt habe ich mir einen neuen PC zusammengebaut, Kubuntu 22.04 installiert (mit neuem /home, aber gleichem Computer/Username wie früher), die alte Daten-HDD eingebaut und sie wieder unter /data eingebunden.

Als ich BIT startete, wurde die Konfiguration erfolgreich aus den alten Schnappschüssen wiederhergestellt und ich kann sie in BIT sehen. Wenn ich jetzt aber einen neuen Schnappschuss erstelle, erkennt BIT nicht, dass fast alles auf /data alt ist, und erstellt einen komplett neuen Schnappschuss mit allen Daten.

Wie kann ich BIT sagen, dass die Daten auf /data nicht neu sind?

Bin für jeden Tipp dankbar!

Hi Shogan,

wenn du BiT startest werden aber alle alten Snapshots in der GUI erkannt und aufgelistet?

Hast du mal überprüft, ob die Pfade auf dem Speichermedium identisch sind? Also mal in einen alten und einen neuen Snapshot schauen, ob der Pfad identisch ist (z.B. backintime/rechner-name/username/1/20220829-080000-123/backup)

Verwendest du backintime-root, oder ist /data mit deinen Nutzerrechten ausgestattet?

Hi san04, vielen Dank für deine Antwort!

wenn du BiT startest werden aber alle alten Snapshots in der GUI erkannt und aufgelistet?

Ja, sie werden in der GUI gelistet.

Hast du mal überprüft, ob die Pfade auf dem Speichermedium identisch sind? Also mal in einen alten und einen neuen Snapshot schauen, ob der Pfad identisch ist (z.B. backintime/rechner-name/username/1/20220829-080000-123/backup)

Ja, sieht aus meiner Sicht richtig aus:

Alt: /backintime/torge-desktop/torge/1/20220809-134520-262/backup/data
Neu: /backintime/torge-desktop/torge/1/new_snapshot/backup/data/

Verwendest du backintime-root, oder ist /data mit deinen Nutzerrechten ausgestattet?

Ich habe BIT immer regulär als User ausgeführt und habe vollen Schreibzugriff. Die Rechte sehen so aus, aber damit kenne ich mich nicht weiter aus:

1
2
3
4
5
6
7

torge@torge-desktop:/media/torge/Backup$ ls -al
insgesamt 32
drwxrwxrwx  5 root  root   4096 Mai  1 15:39 .
drwxr-x---+ 3 root  root   4096 Aug 29 18:48 ..
drwxrwxrwx  3 torge torge  4096 Mai 10  2020 backintime
drwx------  2 root  root  16384 Mai 10  2020 lost+found
drwx------  4 torge torge  4096 Mai  1 15:39 .Trash-1000

Gibt es da vielleicht eine Spur?

Nochmals danke!

Hi Shogan,

Crosspostings solltest du hier wenigstens veröffentlichen: https://askubuntu.com/questions/1425974/back-in-time-recognizes-old-snapshots-but-not-old-data-in-new-pc

Einmal schreibst du von 20.04 und einmal von 22.04, ich gehe davon aus, das ersteres stimmt?

Ich hatte dich so verstanden, dass du ein Verzeichnis data im Wurzelverzeichnis / angelegt und mit Rechten ausgestattet hast: /data. Wenn es relative Pfade sind, dann lasse den führenden Slash besser weg.

Drei Dinge wundern mich:

1. Der Ordner /media/torge/Backup sollte eigentlich dir gehören.

2. Welches Verzeichnis sicherst du genau? /home/$USER/data? Dann sieht der Sicherungspfad bei mir so aus:

   /media/$USER/Backup_Platte/backintime/$HOSTNAME/$USER/1/20220830-090002-123/backup/home/$USER/data

3. Neue Snapshots werden bei mir unter last_snapshot angelegt bzw. verlinkt, du hast new_snapshot, aber vermutlich ist dein Problem hier ursächlich.

Wenn ich wie folgt vorgehe, kann ich dein Problem leider nicht reproduzieren:

• Datensicherung mit BiT in 20.04, zu sicherndes Verzeichnis /home/$USER/data

• Jetzt habe ich den Ordner /home/$USER/data manuell nach 22.04 kopiert (also extra nicht BiT zur Wiederherstellung genutzt)

• Sicherungsplatte bei 22.04 angesteckt

• BiT in 22.04 erstmalig gestartet und den Dialog nach Wiederherstellung der Konfiguration bejaht. Den Pfad musste ich anpassen, da die Platte anders eingebunden wurde

• in der BiT-GUI den Speicherort für Schnappschüsse angepasst. Auszuwählen ist hier der übergeordnete Ordner von backintime. Alte Snapshots wurden in der GUI erkannt.

• Nach geringfügiger Änderung des Datenbestandes ein neues Backup angestoßen

• mit du -h geprüft, dass sich der Platz des Backups nicht verdoppelt hat

Bist du anders vorgegangen? Wenn ja, wie?

Wie hast du festgestellt, dass eine komplett neue Sicherung angelegt wurde? Speicherverbrauch mittels du -h geprüft?

Ist das neue Backup komplett durchgelaufen? Dann könnte ein Blick in die config-Datei einer alten und der neuen Sicherung helfen.

Wie bindest du die Sicherungsplatte ein? (Der Ordner /media/torge/Backup gehört root und nicht dir)

Hi san04,

wow, vielen Dank für deine Bemühungen!

Crosspostings solltest du hier wenigstens veröffentlichen: https://askubuntu.com/questions/1425974/back-in-time-recognizes-old-snapshots-but-not-old-data-in-new-pc

Ok, sorry! Da die Foren in verschiedenen Sprachen sind und hier nichts in den Forenregeln steht, dachte ich, dass es ausreicht, eine eventuelle Lösung dann sofort in beiden zu posten.

Einmal schreibst du von 20.04 und einmal von 22.04, ich gehe davon aus, das ersteres stimmt?

Stimmt, richtig ist 20.04 auf dem alten und 22.04 auf dem neuen PC. Ich habe es im Eingangspost korrigiert.

Ich hatte dich so verstanden, dass du ein Verzeichnis data im Wurzelverzeichnis / angelegt und mit Rechten ausgestattet hast: /data. Wenn es relative Pfade sind, dann lasse den führenden Slash besser weg.

Genau, ich habe die Daten-HDD immer direkt als /data im Wurzelverzeichnis eingebunden, damit die Pfade kurz sind. Besitzer ist root, aber ich habe komplette Schreibrechte. Sollte ich das ändern?

Drei Dinge wundern mich:

1. Der Ordner /media/torge/Backup sollte eigentlich dir gehören.

Dort habe ich auch komplette Schreibrechte und BIT schreibt auch problemlos hinein. Würdest du es trotzdem ändern?

2. Welches Verzeichnis sicherst du genau? /home/$USER/data? Dann sieht der Sicherungspfad bei mir so aus:

/media/$USER/Backup_Platte/backintime/$HOSTNAME/$USER/1/20220830-090002-123/backup/home/$USER/data

Ich sichere /data (das wie gesagt nicht in /home liegt), /home/torge und /windows/Users/Torge (also das Nutzerverzeichnis der parallelen Windows-Installation). Die vollständigen Sicherungspfade sehen also bei mir so aus:

/media/torge/Backup/backintime/torge-desktop/torge/1/20220809-134520-262/backup/data/
/media/torge/Backup/backintime/torge-desktop/torge/1/20201128-211508-275/backup/home/torge
/media/torge/Backup/backintime/torge-desktop/torge/1/20201128-211508-275/backup/windows/Users/Torge

So hat es auch auf dem alten PC immer funktioniert.

3. Neue Snapshots werden bei mir unter last_snapshot angelegt bzw. verlinkt, du hast new_snapshot, aber vermutlich ist dein Problem hier ursächlich.

last_snapshot ist bei mir immer ein Link zum letzten vollständig abgeschlossenen Snapshot (also mit Datum im Ordnernamen), während new_snapshot den unfertigen Snapshot enthält, der gerade noch erstellt wird. Nach Abschluss wird dieser Ordner dann automatisch mit Datum umbenannt.

Wenn ich wie folgt vorgehe, kann ich dein Problem leider nicht reproduzieren:

• Datensicherung mit BiT in 20.04, zu sicherndes Verzeichnis /home/$USER/data

• Jetzt habe ich den Ordner /home/$USER/data manuell nach 22.04 kopiert (also extra nicht BiT zur Wiederherstellung genutzt)

• Sicherungsplatte bei 22.04 angesteckt

• BiT in 22.04 erstmalig gestartet und den Dialog nach Wiederherstellung der Konfiguration bejaht. Den Pfad musste ich anpassen, da die Platte anders eingebunden wurde

• in der BiT-GUI den Speicherort für Schnappschüsse angepasst. Auszuwählen ist hier der übergeordnete Ordner von backintime. Alte Snapshots wurden in der GUI erkannt.

• Nach geringfügiger Änderung des Datenbestandes ein neues Backup angestoßen

• mit du -h geprüft, dass sich der Platz des Backups nicht verdoppelt hat

Danke nochmal für den Aufwand!

Bist du anders vorgegangen? Wenn ja, wie?

Aus meiner Sicht müsste das dem Szenario entsprechen. Der Unterschied ist eben nur, dass es sich bei /data nicht um einen Ordner in /home/$USER handelt, sondern um die interne HDD, die im Root-Verzeichnis unter /data eingebunden ist (wie auch auf dem alten PC). /data ist also nicht mal eine Kopie, sondern es sind wirklich physikalisch dieselben Daten.

Wie hast du festgestellt, dass eine komplett neue Sicherung angelegt wurde? Speicherverbrauch mittels du -h geprüft?

Ich habe mich gewundert, dass das Backup auf dem neuen PC, obwohl ich auf /data nichts geändert hatte, sehr lange dauert und BIT im GUI ganz unten jede einzelne Datei beim Kopieren anzeigt. Auf dem alten PC war so ein inkrementelles Backup in der Regel nach 10 Minuten fertig. Dann habe ich festgestellt, dass im new_snapshot-Ordner nicht wie sonst sehr schnell alle Links erstellt waren, sondern langsam Ordner für Ordner neu erstellt wurde. Als ich new_snapshot löschte, wurden auch hunderte GB frei anstatt der erwarteten paar MB. Eben habe ich nochmal eine Weile einen new_snapshot laufen lassen und ja, du -h zeigt auch volle Dateigrößen an (z. B. 3,5 G für das Kubuntu-Image).

Ist das neue Backup komplett durchgelaufen? Dann könnte ein Blick in die config-Datei einer alten und der neuen Sicherung helfen.

Nein, dafür ist leider auf der externen HDD wegen der unerwünschten Doppelung nicht genug Platz. Die alte config-Datei sieht so aus:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121

config.version=6
global.use_flock=false
profile1.qt.last_path=/
profile1.qt.places.SortColumn=1
profile1.qt.places.SortOrder=0
profile1.qt.settingsdialog.exclude.SortColumn=1
profile1.qt.settingsdialog.exclude.SortOrder=0
profile1.qt.settingsdialog.include.SortColumn=1
profile1.qt.settingsdialog.include.SortOrder=0
profile1.schedule.custom_time=8,12,18,23
profile1.schedule.day=1
profile1.schedule.mode=1
profile1.schedule.repeatedly.period=1
profile1.schedule.repeatedly.unit=20
profile1.schedule.time=0
profile1.schedule.weekday=7
profile1.snapshots.backup_on_restore.enabled=true
profile1.snapshots.bwlimit.enabled=false
profile1.snapshots.bwlimit.value=3000
profile1.snapshots.check_for_changes=true
profile1.snapshots.continue_on_errors=true
profile1.snapshots.copy_links=false
profile1.snapshots.copy_unsafe_links=false
profile1.snapshots.cron.ionice=true
profile1.snapshots.cron.nice=true
profile1.snapshots.cron.redirect_stderr=false
profile1.snapshots.cron.redirect_stdout=true
profile1.snapshots.dont_remove_named_snapshots=true
profile1.snapshots.exclude.1.value=.gvfs
profile1.snapshots.exclude.2.value=.cache/*
profile1.snapshots.exclude.3.value=.thumbnails*
profile1.snapshots.exclude.4.value=[Tt]rash*
profile1.snapshots.exclude.5.value=*.backup*
profile1.snapshots.exclude.6.value=*~
profile1.snapshots.exclude.7.value=.dropbox*
profile1.snapshots.exclude.8.value=/proc/*
profile1.snapshots.exclude.9.value=/sys/*
profile1.snapshots.exclude.10.value=/dev/*
profile1.snapshots.exclude.11.value=/run/*
profile1.snapshots.exclude.12.value=/etc/mtab
profile1.snapshots.exclude.13.value=/var/cache/apt/archives/*.deb
profile1.snapshots.exclude.14.value=lost+found/*
profile1.snapshots.exclude.15.value=/tmp/*
profile1.snapshots.exclude.16.value=/var/tmp/*
profile1.snapshots.exclude.17.value=/var/backups/*
profile1.snapshots.exclude.18.value=.Private
profile1.snapshots.exclude.bysize.enabled=false
profile1.snapshots.exclude.bysize.value=500
profile1.snapshots.exclude.size=27
profile1.snapshots.full_rsync=false
profile1.snapshots.include.1.type=0
profile1.snapshots.include.1.value=/home/torge
profile1.snapshots.include.2.type=0
profile1.snapshots.include.2.value=/daten
profile1.snapshots.include.3.type=0
profile1.snapshots.include.3.value=/windows/Users/Torge
profile1.snapshots.include.size=4
profile1.snapshots.local.nocache=false
profile1.snapshots.local.password.save=false
profile1.snapshots.local.password.use_cache=true
profile1.snapshots.local_encfs.path=/media/torge/Backup
profile1.snapshots.log_level=3
profile1.snapshots.min_free_inodes.enabled=true
profile1.snapshots.min_free_inodes.value=2
profile1.snapshots.min_free_space.enabled=true
profile1.snapshots.min_free_space.unit=20
profile1.snapshots.min_free_space.value=1
profile1.snapshots.mode=local
profile1.snapshots.no_on_battery=false
profile1.snapshots.notify.enabled=true
profile1.snapshots.path=/media/torge/Backup
profile1.snapshots.path.host=torge-desktop
profile1.snapshots.path.profile=1
profile1.snapshots.path.user=torge
profile1.snapshots.preserve_acl=false
profile1.snapshots.preserve_xattr=false
profile1.snapshots.remove_old_snapshots.enabled=true
profile1.snapshots.remove_old_snapshots.unit=80
profile1.snapshots.remove_old_snapshots.value=10
profile1.snapshots.rsync_options.enabled=false
profile1.snapshots.rsync_options.value=
profile1.snapshots.smart_remove=false
profile1.snapshots.smart_remove.keep_all=2
profile1.snapshots.smart_remove.keep_one_per_day=7
profile1.snapshots.smart_remove.keep_one_per_month=24
profile1.snapshots.smart_remove.keep_one_per_week=4
profile1.snapshots.smart_remove.run_remote_in_background=false
profile1.snapshots.ssh.check_commands=true
profile1.snapshots.ssh.check_ping=true
profile1.snapshots.ssh.cipher=default
profile1.snapshots.ssh.host=
profile1.snapshots.ssh.ionice=false
profile1.snapshots.ssh.nice=false
profile1.snapshots.ssh.nocache=false
profile1.snapshots.ssh.path=
profile1.snapshots.ssh.port=22
profile1.snapshots.ssh.prefix.enabled=false
profile1.snapshots.ssh.prefix.value=PATH=/opt/bin:/opt/sbin:\$PATH
profile1.snapshots.ssh.private_key_file=
profile1.snapshots.ssh.user=torge
profile1.snapshots.take_snapshot_regardless_of_changes=false
profile1.snapshots.use_checksum=false
profile1.snapshots.user_backup.ionice=false
profiles.version=1
qt.last_path=/
qt.logview.height=1365
qt.logview.width=2560
qt.main_window.files_view.date_width=100
qt.main_window.files_view.name_width=263
qt.main_window.files_view.size_width=100
qt.main_window.files_view.sort.ascending=true
qt.main_window.files_view.sort.column=0
qt.main_window.height=1007
qt.main_window.main_splitter_left_w=479
qt.main_window.main_splitter_right_w=1440
qt.main_window.second_splitter_left_w=463
qt.main_window.second_splitter_right_w=966
qt.main_window.width=1920
qt.main_window.x=0
qt.main_window.y=0
qt.show_hidden_files=false

Wie bindest du die Sicherungsplatte ein? (Der Ordner /media/torge/Backup gehört root und nicht dir)

Ich habe sie immer grafisch über das Plasma-Popup eingebunden, wenn ich sie per USB angeschlossen habe. In etc/fstab steht sie als

# <file system> <mount point>   <type>  <options>  <dump>  <pass>
/dev/sda1       /data           ntfs    defaults    0       0 

Noch zwei (möglicherweise sinnlose) Gedanken: 1. Könnte das Problem vielleicht damit zu tun haben, dass /data ja für gleichzeitigen Linux/Windows-Zugriff NTFS-formatiert ist und dadurch für Linux relevante Informationen verloren gehen? 2. Wäre vielleicht die BIT-Funktion Schnappschuss mit Prüfsummen erstellen notwendig gewesen, damit die alten Dateien bei neuer Hardware-Konstellation als identisch erkannt werden können?

Nochmals vielen Dank!

Shogan schrieb:

Wie bindest du die Sicherungsplatte ein? (Der Ordner /media/torge/Backup gehört root und nicht dir)

In etc/fstab steht sie als

# <file system> <mount point>   <type>  <options>  <dump>  <pass>
/dev/sda1       /data           ntfs    defaults    0       0 

Da komm ich jetzt gerade nicht ganz mit. Der fstab-Eintrag ist ja genau nicht deine Sicherungsplatte, sondern dein Datenplatte, oder?

Also deine Datenfestplatte unter /data ist NTFS-formatiert, so wie der obige Auszug aus der fstab, richtig? Deine Sicherungsplatte ist aber ext4-formatiert und diese bindest du über das Popup ein?

1. Könnte das Problem vielleicht damit zu tun haben, dass /data ja für gleichzeitigen Linux/Windows-Zugriff NTFS-formatiert ist und dadurch für Linux relevante Informationen verloren gehen?

Das sollte keine Probleme machen, sofern deine Sicherungsplatte ext4-formatiert ist...

2. Wäre vielleicht die BIT-Funktion Schnappschuss mit Prüfsummen erstellen notwendig gewesen, damit die alten Dateien bei neuer Hardware-Konstellation als identisch erkannt werden können?

Das sollte eigentlich nicht notwendig sein und dauert auch Ewigkeiten...

Sofern ich dich also richtig verstanden habe, kann ich da glaube ich leider nicht weiterhelfen ☹

san04 schrieb:

Shogan schrieb:

Wie bindest du die Sicherungsplatte ein? (Der Ordner /media/torge/Backup gehört root und nicht dir)

In etc/fstab steht sie als

# <file system> <mount point>   <type>  <options>  <dump>  <pass>
/dev/sda1       /data           ntfs    defaults    0       0 

Da komm ich jetzt gerade nicht ganz mit. Der fstab-Eintrag ist ja genau nicht deine Sicherungsplatte, sondern dein Datenplatte, oder?

Zurecht, das war Quatsch. Ja, das ist /data, und die Sicherungsplatte hat keinen fstab-Eintrag.

Also deine Datenfestplatte unter /data ist NTFS-formatiert, so wie der obige Auszug aus der fstab, richtig? Deine Sicherungsplatte ist aber ext4-formatiert und diese bindest du über das Popup ein?

Ja, genau. Sie ist ext4-formatiert, hängt an /dev/sdf1, heißt Backup und wird per Popup als /media/torge/Backup eingebunden.

1. Könnte das Problem vielleicht damit zu tun haben, dass /data ja für gleichzeitigen Linux/Windows-Zugriff NTFS-formatiert ist und dadurch für Linux relevante Informationen verloren gehen?

Das sollte keine Probleme machen, sofern deine Sicherungsplatte ext4-formatiert ist...

Ok, das ist sie.

2. Wäre vielleicht die BIT-Funktion Schnappschuss mit Prüfsummen erstellen notwendig gewesen, damit die alten Dateien bei neuer Hardware-Konstellation als identisch erkannt werden können?

Das sollte eigentlich nicht notwendig sein und dauert auch Ewigkeiten...

Ok, es wäre ja auch zu spät dafür.

Sofern ich dich also richtig verstanden habe, kann ich da glaube ich leider nicht weiterhelfen ☹

Ok, trotzdem vielen Dank nochmal für deine Mühen! Dann werde ich wohl die Sicherungsplatte plattmachen und mit BIT neu anfangen.