backup fails, no reason given

Bug #610399 reported by Vreemde eend
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Back In Time
Fix Released
Medium
Unassigned

Bug Description

Lately me backups started to fail. I can't figure ou why. The error message in the log:

***********************
========== Take snapshot (profile 1): Tue 27 Jul 2010 11:54:29 AM ==========

[E] Error: rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
[E] Failed to take snapshot 07/27/2010 11:54:29 !!!
***********************

Commandline output:

***********************
backintime -b

Back In Time
Version: 0.9.99.64

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

INFO: Lock
INFO: [GnomePlugin.Systray.run]
 INFO: on process begins
INFO: [GnomePlugin.Systray.run] begin loop
INFO: Profile_id: 1
INFO: Compare with old snapshot: 20100701-160002-429
INFO: Command "rsync -rltDH --no-p --no-g --no-o --delete --delete-excluded -i --dry-run --out-format="BACKINTIME: %i %n%L" --chmod=Da+w --exclude="/media/Fruitmand/Backup" --exclude="/home/pieter/.local/share/backintime" --include="/home/pieter/" --include="/home/" --exclude=".gvfs" --exclude=".cache*" --exclude="[Cc]ache*" --exclude=".thumbnails*" --exclude="[Tt]rash*" --exclude="*.backup*" --exclude="*~" --exclude="/home/pieter/Music/Library" --exclude="/home/pieter/Downloads/Tucan" --exclude="/home/pieter/.VirtualBox" --exclude="*/tmp/*" --exclude="/home/pieter/zimbra" --include="/home/pieter/**" --exclude="*" / "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/20100701-160002-429/backup/"" returns 0
INFO: Create hard-links
INFO: Command "cp -al "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/20100701-160002-429/backup/"* "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/new_snapshot/backup/"" returns 0
INFO: Command "find "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/new_snapshot" -type d -exec chmod u+wx {} \;" returns 0
INFO: Call rsync to take the snapshot
WARNING: Command "rsync -rltDH --no-p --no-g --no-o --delete --delete-excluded -v --chmod=Da+w --exclude="/media/Fruitmand/Backup" --exclude="/home/pieter/.local/share/backintime" --include="/home/pieter/" --include="/home/" --exclude=".gvfs" --exclude=".cache*" --exclude="[Cc]ache*" --exclude=".thumbnails*" --exclude="[Tt]rash*" --exclude="*.backup*" --exclude="*~" --exclude="/home/pieter/Music/Library" --exclude="/home/pieter/Downloads/Tucan" --exclude="/home/pieter/.VirtualBox" --exclude="*/tmp/*" --exclude="/home/pieter/zimbra" --include="/home/pieter/**" --exclude="*" / "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/new_snapshot/backup/" 2>&1" returns 3072
INFO: Command "find "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/new_snapshot" -type d -exec chmod u+wx {} \;" returns 0
INFO: Command "rm -rf "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/new_snapshot"" returns 0
INFO: Command "rm -rf "/media/Fruitmand/Backup/backintime/fruitsla/pieter/1/20100727-100302-429"" returns 0
ERROR: Failed to take snapshot !!!
INFO: [GnomePlugin.Systray.run] end loop
INFO: Unlock

** (backintime.py:29899): CRITICAL **: dbus_g_proxy_disconnect_signal: assertion `DBUS_IS_G_PROXY (proxy)' failed

** (backintime.py:29899): CRITICAL **: dbus_g_proxy_disconnect_signal: assertion `DBUS_IS_G_PROXY (proxy)' failed

***********************

CVE References

Revision history for this message
Vreemde eend (pieter-cogghe) wrote :

I found the problem, two folders were causing BIT trouble:

/home/pieter/zimbra
/home/pieter/.config/google-chrome

I guess there is something wrong with the permissions.

Changed in backintime:
status: New → Invalid
Revision history for this message
Calcipher (calcipher) wrote :

I am getting the same error, might I ask how you figured out what was causing the problems?

Revision history for this message
Vreemde eend (pieter-cogghe) wrote : Re: [Bug 610399] Re: backup fails, no reason given

I checked the logs and ignored the files/folders on which were mentioned last.

2010/8/9 Zachary Braun <email address hidden>:
> I am getting the same error, might I ask how you figured out what was
> causing the problems?
>
> --
> backup fails, no reason given
> https://bugs.launchpad.net/bugs/610399
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Pieter Cogghe
Iepenstraat 43
9000 Gent
0487 10 14 21

Revision history for this message
Artem Yakimenko (temik) wrote :

For people who might be suffering from the same bug.
This should fix it:
1) Run "find /your_backup_directory -not -readable" in console.
2) Exclude all files found by that command from the backup.

Hope it helps.

Dan (danleweb)
Changed in backintime:
status: Invalid → Confirmed
importance: Undecided → Medium
Revision history for this message
David Schneider (dnschneid) wrote :

Actually, it looks like it might be due to a bug in rsync.
I've been unable to do a full backup for a while now thanks to the "broken pipe" error of rsync (which is caused by a failed assert in the hardlink code).
Turns out rsync had a bugfix release 3.0.8 that came out a month ago and features fixes such as:
"Fixed a data-corruption issue when preserving hard-links without
      preserving file ownership, and doing deletions either before or during
      the transfer (CVE-2011-1097). This fixes some assert errors in the
      hard-linking code, and some potential failed checksums (via -c) that
      should have matched."
which seemed right on the money (full list here: http://rsync.samba.org/ftp/rsync/src/rsync-3.0.8-NEWS )

Anyway, I compiled and installed that version and was immediately able to do a full backup without any issue.

Add that to the list of things to try if Artem's solution doesn't fix it for you.

Revision history for this message
timuckun (timuckun) wrote :

I too am effected by this bug.

Sometime towards the middle of last month the backups stopped happening (no notifications!!). I did a search for non readable files and there were a bunch of broken symlinks, I cleared them but that didn't solve the problem because various applications (geany, firefox etc) tend to create symlinks they don't keep track of.

The error message is very cryptic basically that rsync returns 3072

I think the greater problem is that the existance of even one file that rsync has a problem with cancels the entire backup and that's not a good thing at all.

Revision history for this message
Beurt (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553) wrote :

Hi,

While moving from Mandriva to Mageia I updated BIT to 1.0.6 (rsync 3.0.8).

And I have the same problem. BIT fails to make every snapshot because of permissions' problems. The end of the BIT logs are for instance:

[I] Sauvegarder (rsync: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1052) [sender=3.0.8])
[E] Impossible d'effectuer la sauvegarde 10/23/11 23:15:45 !!!

Are the files/attrs so important that it can make the whole process failed (when it was almost done!)?

Revision history for this message
Dan (danleweb) wrote :

For some peoples they are important, sore some others not.
You can always check "Continue on errors" option. I think I'll make it checked by default (it is better to have "partial snapshots" marked with "errors" than nothing).

Regards,
Dan

Revision history for this message
Jon Bevan (jon-jonbevan) wrote :

Even with "Continue on errors" I still get partial backups.

The end of the log file looks like this:

[I] Take snapshot (rsync: var/clients/company spy/free data/ch_database_pre_cleanup.sql)
[I] Take snapshot (rsync: rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32))
[E] Error: rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
[I] Take snapshot (rsync: rsync: write failed on "/media/BACKUP_01/backintime/eotw-server/eotw/1/new_snapshot/backup/var/clients/company spy/free data/ch_database_pre_cleanup.sql": File too large (27))
[E] Error: rsync: write failed on "/media/BACKUP_01/backintime/eotw-server/eotw/1/new_snapshot/backup/var/clients/company spy/free data/ch_database_pre_cleanup.sql": File too large (27)
[I] Take snapshot (rsync: rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7])
[I] Take snapshot (rsync: rsync: connection unexpectedly closed (2500600 bytes received so far) [sender])
[I] Take snapshot (rsync: rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7])
[I] Ayar dosyasını kaydet...
[I] Save permission ...

I too am running rsync 3.0.7 so I'll update that and post any performance difference.
Jon

Revision history for this message
Dan (danleweb) wrote :

"Continue on errors" means "keep partial backups".

In you case the error is:

Error: rsync: write failed on "/media/BACKUP_01/backintime/eotw-server/eotw/1/new_snapshot/backup/var/clients/company spy/free data/ch_database_pre_cleanup.sql": File too large (27)

What is your destination file system ?
Do you have enought free space ?
How big is this file ?

Reagards,
Dan

Revision history for this message
Jon Bevan (jon-jonbevan) wrote :

Destination is FAT32 and there is enough space on it.

That particular file was 6GB I think, but I've removed it now and there is another file causing the same error which is just over 4GB, but I just remembered that FAT32 can only cope with a max filesize of 4GB... bummer!

Guess I need to either split the files into chunks or change file system! Any chance of incorporating a feature like that into backintime? :)

Revision history for this message
Dan (danleweb) wrote :

No, but if you want to use your drive on windows too you can format it with NTFS.

Regards,
Dan

Revision history for this message
Dan (danleweb) wrote :

Backup logs give more informations if backup fails, so i'll pass this bug to fixed.

Changed in backintime:
status: Confirmed → Triaged
status: Triaged → Fix Released
Revision history for this message
vkapas (vkapas) wrote :

In my case, the problem was caused by a lack of disk space (on backup destination).

There is "Can't do backup" error in BackInTime GUI and "writefd_unbuffered failed to write" rsync error in BackInTime log. No words about "disk space is exhausted".

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.