-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Holger Parplies wrote:
> Hi,
>
> just saw the e-Mail in passing. I'll try to take a closer look tonight.
Thanks for your attention, please see additional information below:
> Adam Goryachev wrote on 2009-08-06 22:58:59 +1000 [[BackupPC-users] Possible
> bug in rsyncp]:
>> [...]
>> The problem portion of the log file is:
>> pool 644 18/544 3760613 PHOTOS/111/IMG_0766.JPG
>> pool 644 18/544 3808103 PHOTOS/111/IMG_0773.JPG
>> pool 644 18/544 3922850 PHOTOS/111/IMG_0774.JPG
>> pool 644 18/544 4189728 PHOTOS/111/IMG_0775.JPG
>> Read EOF:
>> Tried again: got 0 bytes
>> finish: removing in-process file PHOTOS/111/IMG_0776.JPG
>> delete d 755 18/544 0 PHOTOS/S
>> delete d 755 18/544 0 PHOTOS/ZZZZ_PROBLEM_PHOTOS
>> [...]
>
> That looks familiar. Wait - "delete d"? Are there also files that are deleted,
> or only directories?
- From memory, all files and directories (though the majority of this
share is subdirectories) were deleted.
>> and so on to the end of the backup:
>> Child is aborting
>> Got fatal error from child: Unable to read 4 bytes
>
> So, apparently the error is passed on to the parent. At least that much
> works :). Is the backup marked as successful?
No, it was marked as failed, which is good, but also it has attempted a
new backup, so I no longer have access to that backup log....
>> Got fatal error during xfer (Unable to read 4 bytes)
>> Backup aborted (Unable to read 4 bytes)
>
> As I said, I can't look closer right now. What I would have expected to happen
> is that the backup is marked as unsuccessful and discarded (or kept as a
> partial if it's a full). I didn't think much further than that. Deleting files
> past the point of failure doesn't make any difference for a backup that will
> be discarded, but it's a bad idea for a partial, so I might have to think of
> something better. Was your backup actually a full?
This one was an incremental backup, and so was simply discarded. In the
past, the problem was (I think) that the backup was marked successful
and so saved with the missing files/directories. So, discarding the incr
is right, but *if* this was a full, then we shouldn't delete the
remaining files, we should just fail immediately and save it as a
partial....
> One possibly unrelated thing I notice is that the files quoted above are
> marked "pool", not "same". Is that what you expect (moved or copied photos),
> or is it the result of a previous partial which failed in a similar way (but
> then there should be nothing left to delete, should there)?
The previous backup was a full backup, and this one was an incremental.
I do expect some images to be renamed. Unfortunately these are
re-transferred over the WAN, but that is offtopic for this message :)
The work process is to dump the images from the camera memory card into
a "unknown" folder, and then later they are moved to a folder for the
subject. Often this happens some number of days (or weeks) afterwards.
So, it looks like the patch is working quite well for now, just need to
find out what happens if this failure happened on a full backup (and
created a partial with lots of folders deleted).
Regards,
Adam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp68HwACgkQGyoxogrTyiXTUACePCYTDmFtLZd39ffQPceRqsNC
XFAAn0kAOPC7huUtvHtOQMorRshqYogr
=se4Y
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
