Re: [Duplicity-talk] Backup problems 0.6.17

[Ken Bass]

On 1/10/2012 12:09 PM, address@hidden wrote:
> can you send us the full output run with -v9 , obfuscate data that 
> seems sensitive to you in it. please post it to pastebin and send the 
> link here.
My logs are -v5 currently. I'll have to setup a -v9 run and a reduced 
dataset and try to get this to happen again.

I did have an idea earlier. One thing I noticed is that during the 
original backup I had a restart. I wonder if the restart/resume logic is 
somehow corrupting the signature files?

My collection is:

Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Sun Jan  8 14:36:16 2012
Chain end time: Tue Jan 10 01:30:05 2012
Number of contained backup sets: 3
Total number of contained volumes: 96
 Type of backup set:                                                
Time:      Num volumes:
                Full          Sun Jan  8 14:36:16 2012 
(20120108T193616Z)                61
         Incremental          Mon Jan  9 01:30:05 2012 
(20120109T063005Z)                 1
         Incremental          Tue Jan 10 01:30:05 2012 
(20120110T063005Z)                34
-------------------------
No orphaned or incomplete backup sets found.

The first incremental is where all the files under 'Documents' were 
marked as 'D' deleted for some reason.

> also please restore the same file from two different backups of which you think 
> that it was uploaded although it was already backed up. restore as root so 
> permissions and times are restored as well. please compare atime,mtime,ctime 
> and report back.
Is mtime even used in the code? I did restore as root and mtime is 
identical. I do not see that the ctime was restored - it seems to be set 
to when the restore happens. Shouldn't that be restored as you said?

stat Documents/605442/605442.ZIP Documents3/605442/605442.ZIP

  File: `Documents/605442/605442.ZIP'
  Size: 4872704         Blocks: 9544       IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 950602      Links: 1
Access: (0666/-rw-rw-rw-)  Uid: ( 1028/kbass-backup)   Gid: ( 
1028/kbass-backup)
Access: 2012-01-10 14:50:36.000000000 -0500
Modify: 1996-06-14 20:19:14.000000000 -0400
Change: 2012-01-10 14:50:36.000000000 -0500

  File: `Documents3/605442/605442.ZIP'
  Size: 4872704         Blocks: 9544       IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 950416      Links: 1
Access: (0666/-rw-rw-rw-)  Uid: ( 1028/kbass-backup)   Gid: ( 
1028/kbass-backup)
Access: 2012-01-10 14:49:54.000000000 -0500
Modify: 1996-06-14 20:19:14.000000000 -0400
Change: 2012-01-10 14:49:54.000000000 -0500

If I look at the file that is being backed up each night - the 'source' 
file:

  File: `/data/Documents/605442/605442.ZIP'
  Size: 4872704         Blocks: 9544       IO Block: 4096   regular file
Device: fd20h/64800d    Inode: 156737667   Links: 1
Access: (0666/-rw-rw-rw-)  Uid: ( 1028/kbass-backup)   Gid: ( 
1028/kbass-backup)
Access: 2012-01-10 01:52:55.000000000 -0500
Modify: 1996-06-14 20:19:14.000000000 -0400
Change: 2012-01-08 14:12:53.000000000 -0500

That ctime corresponds to when it was first created and that would be 
correct. It did not change across backups.