Here's a challenging one:
One of my hosts now fails when performing an incremental backup. It seems
to always choke on the same file, which is a file that was recently moved
from one directory to another.
All other hosts (including others that actually back up other trees on the
same physical host) are working fine. Creating a new host that backs up
the same data as the one that fails works fine.
I thought I'd post here in case someone else has come across this, before
I post to the developers.
More details below, if it helps anyone.
Regards, Msquared...
WHAT I DID
Either allowed an incremental backup to occur on normal hourly wakeup, or
manually started an incremental backup.
WHAT I EXPECTED TO HAPPEN
I expected that the incremental backup would succeed.
WHAT ACTUALLY HAPPENED
The incremental backup failed with:
Got fatal error during xfer (aborted by signal=PIPE)
WHAT I'VE TRIED
I've tried running the backup manually to see what happens:
sudo -u backuppc BackupPC_dump -v -i sliderule-www
It seems that only the 'sliderule-www' backup set is doing this. All
other backups sets (including two others that are actually back up
different parts of the same host) work fine.
I've tried:
* Renaming the file that it appears to choke the incremental backup:
the backup still chokes on the same file;
* Creating a new file (that will not exist in the pool) with a
filename that will be backed up before the one that chokes:
the new file is backed up OK (marked as 'create' in the xferlog),
but then the original file that's in the pool still chokes;
* Creating a new file (that *does* exist in the pool) with a filename
that will be backed up before the one that chokes: the new file is
backed up OK (marked as 'pool' in the xferlog), but then the
original file that's in the pool chokes;
* Renaming the file that chokes (but making sure it's still in the
same position in the directory listing): the backup still chokes on
that file;
* Changing the mode of the file that chokes: the backup still chokes
on that file;
I have not yet tried to perform a full backup; if this is a bug that is
hard to replicate and a full backup 'fixes' it, then we might lose an
opportunity to find and fix the bug.
WHEN THE PROBLEM STARTED
I think the problem started when I renamed one folder named 'old-stats' to
'old-old-stats', renamed 'stats' to 'old-stats', then created a new folder
called 'stats'. The backup chokes on the first file in 'old-old-stats'.
MY CONFIGURATION
I'm running BackupPC 3.1.0 from the CentOS test repository on a Xen guest.
I was originally running 3.0.0, which also exhibited this problem.
The BackupPC pool (/var/lib/backuppc) is mounted from an NFS share on the
Xen server's Dom0.
The Xen guest is CentOS 5, the Xen host is CentOS 5, and the remote host
is also CentOS 5.
The communications protocol is rsync (via SSH).
WHAT I THINK IS WRONG
The incremental backup seems to stall on the first file that it comes to
that has been moved since the last full backup, yet still exists in the
pool. I'm not sure what the cause is. Perhaps there's something wrong at
the rsync level.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
