takesnapshot_log can grow to ridiculous sisez

Bug #1164619 reported by Nils Herde
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Back In Time
Confirmed
Medium
Unassigned

Bug Description

My /.local/share/backintime/takesnapshot_log file has grown to 22.5 GB. Regardless of what happens on my side this should not be possible and should, in my oppinion, be considered a bug.

And no, I won't be uploading that particular file as a whole ;-)

Tags: file log size space
Revision history for this message
Germar (germar) wrote :

Wow. That's huge. Was this an initial backup of some 100 million files?
I'll consider to use bz2 to store the log.

Regards,
Germar

Changed in backintime:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Nils Herde (hernil) wrote :

It's a backup of my home folder containing about 33 000 files. And no, not the initial backup, even though it has been a while. I'm not quite sure what that file actually does so it's hard for me to guess what might be the reason.

Nils

Revision history for this message
Germar (germar) wrote :

If you did not delete the file yet, could you please run
'grep -e "^\[E\]" ~/.local/share/backintime/takesnapshot_log | bzip2 > error.bz2'

and send me the error.bz2 to germar DOT reitze HOSTED ON gmail DOT com

Regards,
Germar

Revision history for this message
Nils Herde (hernil) wrote :

I'm sorry, I kept it in just this case, but it appears to have been removed somehow by something else.

Revision history for this message
Nils Herde (hernil) wrote :

Happened again. I don't know why. I sent you the grep :-)

Revision history for this message
Nils Herde (hernil) wrote :

I discovered the source of the problem. It was a teamviewer-folder with some sort of infinite symlink recursion that didn't play well with rsync. Don't know if there is any way to check for these sorts of things before doing the actual backup?

Revision history for this message
Germar (germar) wrote :

A quick search on google showed me that the supposed workaround for this is to use rsync with --copy-links (in BIT: Expert Options > Copy links). But I would rather remove or exclude the symlink.
To check for this we would have to scan the entire source folder. I don't think this is worth to do. The better solution would be if rsync could check for this. You can file a bug on rsyncs wishlist if you want.

Revision history for this message
buhtz (buhtz) wrote :

Dear Nils,
your Issue is still open and active at the "new" repository.

https://github.com/bit-team/backintime/issues/118

Can you give us some feedback about the current state of it.
Did you use Back In Time? Maybe you find a solution for your symlink problem with the TeamViewer folder?

If you filled a bug report at rsync (which I strongly recommend!) please link it here.

Please report us back at our Microsoft GitHub Issue section:
https://github.com/bit-team/backintime/issues/118

Kind
Christian

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.