The exact commands are logged in your messages log (Command "..." returns 0) Between " " is the command that is issued (it might be better to have a look in the syslog, as in messages the commands can be truncated. You can also run it from the command line: backintime -b than all the messages are also displayed in your terminal. The return code should be 0, a known issue is the .gvfs that gives an error code 5888
If you want to adept the rsync command to invoke debug information: open the /usr/share/backintime/common/snapshot.py file, search for the rsync_prefix: you can add additional arguments there. (would be good to add an option debug or something...) If you could have a thorough look, that would be great, if you find something keep us posted... Cheers, Bart 2009/11/9 Andreas <andr...@welcomes-you.com> > I can confirm the bug, however it only shows up under specific > conditions. > > - If BiT takes snapshots of my small Temp directory (/home/andreas/Temp) > it behaves as expected (meaning files which are deleted before the next > snapshot are not anymore visible in the snapshot taken after the > deletion of the file. > > - BUT if BiT has to backup my complete home directory (/home/andreas) > which hosts 30GB, it keeps in the snapshots deleted files. Example: I > have a file called foo in ~/Temp. I make a snapshot1. It appears in > snapshot1. I delete the file foo. I make a snapshot2. When I browse in > BiT in snapshot2, I still see the file foo, althought in "Now" it > doesn't show up anymore. > > Maybe it depends on the size of the to be backuped directory? > > Question: > - How can we trace, what commands are issued by BiT to rsync when making a > snapshot? Please let me know, how I can look at these traces (debug output > of rsync including command line invocation). > > My environment: > Ubuntu 9.04, rsync version 3.0.5 protocol version 30, BiT 0.9.26 installed > via "apt-get". Backup is made on a NAS and is mounted as a NFS on my > machine. > > Note: > Excluding ".gvfs" makes no difference. > > -- > Deleted Files are stored in snapshots forever > https://bugs.launchpad.net/bugs/406092 > You received this bug notification because you are a direct subscriber > of the bug. > -- Deleted Files are stored in snapshots forever https://bugs.launchpad.net/bugs/406092 You received this bug notification because you are a member of Back In Time Team, which is the registrant for Back In Time. Status in Back In Time: Confirmed Bug description: The classic example of this is when Back In Time backs up your desktop. For example. I create a file called 'foo' on my desktop to write some quick notes in. I create a snapshot, and '~/Desktop/foo' is now stored in 'Snapshot1'. I delete 'foo' from my Desktop, as I no longer need the file. I create another snapshot 'Snapshot2'. 'Foo' is still listed in 'Snapshot2' as a file (although obviously it hasn't changed). For each snapshot that is taken after this, 'foo' will always be listed as a file in the snapshot, and never removed from the series of backups. What should happen is, 'foo' should be stored in 'Snapshot1', but should not be stored in 'Snapshot2'. When 'Snapshot1' is deleted (either manually or automatically), 'foo' is no longer backed up through back in time, as it no longer exists on the system. The only current workaround I have found, is manually deleting the files I want to be removed from snapshots, so they are not included in the next sync. _______________________________________________ Mailing list: https://launchpad.net/~bit-team Post to : bit-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~bit-team More help : https://help.launchpad.net/ListHelp
