compare phase much longer in 1.04 than in 1.02

Please check the log to a line containing "rsync" and "-dry" and attach it.
Meybe there is a problem in BIT and it always use checksum.

It looks like that the boolean is not set by default so the checksum use is random.
The following workaround seems to fix the problem :
- check the option
- quit
- launch BIT again
- uncheck the option

Once you do this does the problem vanished ? or you have to do this all the time ?
If you have to do it all the time please open a bug.

Regards,
Dan

After few days of correct and fast running, the problem is back randomly.
The hang point is still "Compare with old snapshot: ..." and there is no disk activity.
It may take 1 hour or even more.
To fix it, I should apply the previous workaround plus a reboot.

The command line in ~/.local/share/backintime/takesnapshot_.log with a"-dry" option is:
rsync -rtDH --links --no-p --no-g --no-o --delete --delete-excluded -i --dry-run --out-format="BACKINTIME: %i %n%L" --chmod=Du+wx --exclude="/mnt/Backup/Charles" --exclude="/home/sspadeu/.local/share/backintime" --include="/etc/" --include="/home/sspadeu/" --include="/home/" --include="/home/invitesu/" --include="/Home/sspade/Audio/" --include="/Home/sspade/" --include="/Home/" --include="/Home/sspade/Codes/" --include="/Home/sspade/CourrierPapier/" --include="/Home/sspade/Doc/" --include="/Home/sspade/Paiements/" --include="/Home/sspade/Scripts/" --include="/mnt/Photos/" --include="/mnt/" --include="/Home/sspade/.amsn/" --include="/Home/sspade/.config/" --include="/Home/invites/.config/" --include="/Home/invites/" --include="/Home/sspade/Download/Charles/" --include="/Home/sspade/Download/" --include="/mnt/GrosFichiers/" --include="/mnt/Partage/Logiciels/Tellico/" --include="/mnt/Partage/Logiciels/" --include="/mnt/Partage/" --include="/mnt/WinCapture/" --include="/mnt/WinData/" --include="/Home/sspade/MemotooBackup/" --exclude="*lost+found*" --exclude=".gvfs" --exclude="System Volume Information" --exclude="*RECYCLE*" --exclude="*/gvfs-metadata/*" --exclude="[Cc]ache*" --exclude="[tT]humb*" --exclude="[tT][eE]?[mM][pP]" --exclude=".pulse" --exclude="*[Tt]rash*" --exclude="*.macromedia*" --include="/etc/**" --include="/home/sspadeu/**" --include="/home/invitesu/**" --include="/Home/sspade/Audio/**" --include="/Home/sspade/Codes/**" --include="/Home/sspade/CourrierPapier/**" --include="/Home/sspade/Doc/**" --include="/Home/sspade/Paiements/**" --include="/Home/sspade/Scripts/**" --include="/mnt/Photos/**" --include="/Home/sspade/.amsn/**" --include="/Home/sspade/.config/**" --include="/Home/invites/.config/**" --include="/Home/sspade/Download/Charles/**" --include="/mnt/GrosFichiers/**" --include="/mnt/Partage/Logiciels/Tellico/**" --include="/mnt/WinCapture/**" --include="/mnt/WinData/**" --include="/Home/sspade/MemotooBackup/**" --exclude="*" / "/mnt/Backup/Charles/backintime/samspade/sspadeu/1/20101116-120001-511/backup/"

It is strange. Please check:
1. check if the checksum option is unchecked for all user and profiles (if any)
2. check ~/.config/backintime/config file
3. if/when the problem appears check again the config file
4. just to be sure: did you backup/restore BIT config file ?

Regards,
Dan

Thanks for your answer.
1. there is only one user and one profile and checksum option is unchecked
2. what should I check in ~/.config/backintime/config ?
3. I am waiting for the problem return
4. the BIT config file is included in the backup but never restored (afaik)

Regards,
Sam

2. You can check the config file for lines containing 'checksum' word (now and when the problem came back).

Regards,
Dan

In all backups I have since the 1.04 update (28 of them), I have the following line in ~/.config/backintime/config:
profile1.snapshots.use_checksum=false
The problem is that I don't know if there is at least one slow backup that have been achieved and not auto-removed. When one takes ages to run, it may never end and it prevents following ones to start, so I kill it.
The only thing I can do is to wait for the problem to occur again and check the config file before killing it. But I have no idea how to replicate it.

If you decide to kill a slow backup just copy the log file (~/local/share/backintime/take...) and check rsync command for checksum option.

Regards,
Dan

Hi,

The problem came back and I can see that:
- checksum=false in config
- there is no checksum parameter in the command line in ~/.local/share/backintime/takesnapshot_.log

The slow backup took 3 hours to run, the following one 4 minutes.

Regards,
Sam.

The good point is than the flag it is not randomly set.

1. Do you know if the check it is blocked on a specific item ?
2. Did you included new folders lately ? (or removed some excludes)
3. If you check use checksum it is as slow ?

Regards,
Dan

Le 17 nov. 2010 23:04, "spade" <email address hidden> a
écrit :

Question #133660 on Back In Time changed:
https://answers.launchpad.net/backintime/+question/133660
...

Status: Answered => Open

spade is still having a problem:
Hi,

The problem came back and I can see that:
- checksum=false in config
- there is no checksum parameter in the command line in
~/.local/share/backintime/takesnapshot_.log

The slow backup took 3 hours to run, the following one 4 minutes.

Regards,
Sam.

--
You received this question notification because you are an answer
contact for Back In Time.

1. I just see "Compare with snapshot..." in the tooltip in front of the BIT icon when it runs, as well as a line in the system log file concerning BIT. There is a big time gap with the timestamp of the following line concerning BIT. ("WARNING: Command "rsync..."")
2. no new included folder, slight modifications of excluded ones. The final exclusion list is:
*lost+found*, .gvfs, System Volume Information, *RECYCLE*, */gvfs-metadata/*, [Cc]ache*, [tT]umb*, [tT][eE]?[mM][pP], .pulse, *[Tt]rash*, *.macromedia*. Could it be simplified ?
3. I think have tried once to check the option and run the backup. i took ~30 minutes instead of few minutes. Would it be useful to try to set it for several days and check if the random slowing down effect is still there ?

Regards,
Sam.

1. What does the take snapshot log contains ?
2. Does new exclude rules exclude more than before ?
3. It could be interesting to see if it is related to use checksum or not.

Regards,
Dan

Hi,

I think I get the answer.
While debugging another soft which hung, I saw that the stop point was on a NFS mount to a hybernated remote PC. It doesn't belong neither to the sources neither to the target of the backup, but BIT looks to work fast when I delete it in fstab.
Sorry for the time spent on a such odd problem not really related with BIT, but it could be useful to other users (on any soft actually)

Regards,
Sam.