Backup Central

On 01/23/06 21:58, Kevin Horton wrote:

I'm running rdiff-backup 1.1.5 on OS X 10.4.4. I'm getting eight
errors like:

Cannot read carbonfile information from /Users/kwh/Desktop/RV_Stuff/
POH archive/graphs/all-3.gp
UpdateError Desktop/RV_Stuff/POH archive/graphs/all-3.gp Updated
mirror temp file /Volumes/Maxtor_300/bu/PowerMac/Desktop/RV_Stuff/POH
archive/graphs/rdiff-backup.tmp.2 does not match source

These errors are consistent - I see the same errors for the same
files every time I backup. The backup finishes apparently normally,
with no errors listed in the session statistics. The files that have
the UpdateErrors have apparently not changed since I first started
using rdiff-backup. They have modification times of March 2005, or
earlier. If I look in the backup directory, those files do not
appear. I.e. they are not backed up.

What do these errors mean?

What could have caused the situation that triggers these errors?

I think it would be better if rdiff-backup somehow made it very clear
to the user that some files were not backed up. I picked it up by
studying the output, but I would have missed them if I only looked at
the number of errors at the end of the session statistics. The fact
that some files are not backed up could be very important, depending
on what the files are.

Kevin Horton
Ottawa, Canada


It's kind of a late reply on my part, but I agree. Your situation is
kind of unique, because your file in question hasn't changed, but even
under valid changed-conditions, the file is skipped during backup.

I think that at least, rdiff-backup shouldn't just say that the file was
changed during backup, but also that it's not backed up this run. I
think an option to rdiff-backup like "--retries-on-file-change [number]"
would be welcome as well, perhaps with a 2 second (or so) pause between
each try. And, an option to queue the files which have changed for
retrying at the end of the backup would be convinient as well, because
an immediate retry could still result in a file-has-changed situation.
This option could be "--queue-retry-changed-files" or something.

In any case, the changed-file behaviour needs some reconsideration, in
my opinion, to prevent data-loss.

Wiebe Cazemier <halfgaar < at > gmail.com>
wrote the following on Sat, 11 Feb 2006 12:48:07 +0100
On 01/23/06 21:58, Kevin Horton wrote:

I'm running rdiff-backup 1.1.5 on OS X 10.4.4. I'm getting eight
errors like:

Cannot read carbonfile information from /Users/kwh/Desktop/RV_Stuff/
POH archive/graphs/all-3.gp
UpdateError Desktop/RV_Stuff/POH archive/graphs/all-3.gp Updated
mirror temp file /Volumes/Maxtor_300/bu/PowerMac/Desktop/RV_Stuff/POH
archive/graphs/rdiff-backup.tmp.2 does not match source
...
I think it would be better if rdiff-backup somehow made it very clear
to the user that some files were not backed up. I picked it up by
studying the output, but I would have missed them if I only looked at
the number of errors at the end of the session statistics. The fact
that some files are not backed up could be very important, depending
on what the files are.

It's kind of a late reply on my part, but I agree. Your situation is
kind of unique, because your file in question hasn't changed, but even
under valid changed-conditions, the file is skipped during backup.

I think that at least, rdiff-backup shouldn't just say that the file was
changed during backup, but also that it's not backed up this run. I
think an option to rdiff-backup like "--retries-on-file-change [number]"
would be welcome as well, perhaps with a 2 second (or so) pause between
each try. And, an option to queue the files which have changed for
retrying at the end of the backup would be convinient as well, because
an immediate retry could still result in a file-has-changed situation.
This option could be "--queue-retry-changed-files" or something.

This might be more difficult to implement than it first appears
because of rdiff-backup's pipelined design. At any given moment the
client and server can be processing 3 different files (e.g. the client
could be listing one directory, and patching a file in a different
directory, and the server could be computing the signature of a third
file).

In any case, the changed-file behaviour needs some reconsideration, in
my opinion, to prevent data-loss.

It's not perfect, but note this is not a case of "file changing while
rdiff-backup is running". There is some problem on Mac OS X with
reading carbonfile information, so rdiff-backup is getting OS errors
while trying to read the file's information. Under these conditions
skipping the file seems appropriate behavior.


--
Ben Escoto

On 02/23/06 04:11, Ben Escoto wrote:


This might be more difficult to implement than it first appears
because of rdiff-backup's pipelined design. At any given moment the
client and server can be processing 3 different files (e.g. the client
could be listing one directory, and patching a file in a different
directory, and the server could be computing the signature of a third
file).


Is storing it in a queue for later processing also difficult because of
this? I can image retrying a file immediatly would disrupt the pipeline,
but I would guess that the queue idea doesn't give that much problems
with that.

But, it was only a suggestion. I could live without it.



In any case, the changed-file behaviour needs some reconsideration, in
my opinion, to prevent data-loss.



It's not perfect, but note this is not a case of "file changing while
rdiff-backup is running". There is some problem on Mac OS X with
reading carbonfile information, so rdiff-backup is getting OS errors
while trying to read the file's information. Under these conditions
skipping the file seems appropriate behavior.

But rdiff-backup skips any file on any system when a change is detected,
right? I would say this is not desirable behaviour.