compare phase much longer in 1.04 than in 1.02

Asked by spade on 2010-11-11

The overall backup may be much longer in v1.04 than in v1.02. After having checked system log files, the phase "Compare with old snapshot: ..." may be ~26 minutes instead of ~26 seconds in v1.02.
I checked that the option "Use checksum to detect changes" is unchecked.

Question information

Language:
English Edit question
Status:
Solved
For:
Back In Time Edit question
Assignee:
No assignee Edit question
Solved by:
spade
Solved:
2010-11-19
Last query:
2010-11-19
Last reply:
2010-11-19

This question was reopened

Dan (danleweb) said : #1

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.

spade (sammy-spade) said : #2

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

Dan (danleweb) said : #3

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

spade (sammy-spade) said : #4

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/"

Dan (danleweb) said : #5

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

spade (sammy-spade) said : #6

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

Dan (danleweb) said : #7

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

Regards,
Dan

spade (sammy-spade) said : #8

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.

Dan (danleweb) said : #9

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

spade (sammy-spade) said : #10

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.

Dan (danleweb) said : #11

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.

spade (sammy-spade) said : #12

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.

Dan (danleweb) said : #13

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

spade (sammy-spade) said : #14

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.