Hello all, long first post, sorry.

I've been using rsync in a backup script for several years now.  The
script has been stable, and the backup system as a whole pretty much
error free for at least 2 years, the only hiccups being minor tweaks to
accommodate changes to base utilities used (lvm, namely).

In broad strokes, here is what happens for the home directory on my
notebook(s).
  0. lvcreate(8) is used to create a 128MB read-only snapshot of my
     ${HOME}.  It is mounted at /mnt/snapshots/khellman
  1. ssh-agent(1) is used with a passphrase-less identity file to setup
     an environment for pushing data to my home server
  2. my script is invoked, it traverses /mnt/snapshots/khellman creating a
     list of files to be pushed to the remove server.
  3. the push happens and all the environments are shutdown in reverse
     order

Pertinent details of the backup are logged to a file in my HOME.  This
has been my setup for at least 2 or 3 years now.  I've been very happy
with its performance.

The rsync version reported on all machines is 3.0.7 from the debian
testing package of the same version (see attached lis).

As of late, all the pushes to my home server end up with rsync exiting
with code 23 (RERR_PARTIAL).  I can't quite reconcile why this is.

  * Backing up from /mnt/snapshots/khellman means that the process
        creating the file list should see an immutable version of my HOME.
        If my fetchmail process runs from cron, it changes the logical
        volume contents mounted at my HOME, but /mnt/snapshots/khellman
        should not change.

  * Recently, I've revamped my home server using Linux software raid.
        But this is on the *destination* of the data flow, not only should
        changes to the underlying media be insulated from the rsync client
        on my notebook, my impression from the rsync code base is that
        RERR_PARTIAL is detected on the client, not the server.

  * My backup script supports multiple destinations for the data.  If
        I hook up my big external usb drive, turn my network off, I still
        get RERR_PARTIAL exit codes.  So this doesn't seem to be a network
        media or server setup issue (btw, my notebook, server, and usb drive
        all use the same file system type, ext3; the notebook and server
        both run debian testing).

  * I thought this might be an issue with LVM snapshots (new defect? not
        big enough anymore? a little bit of file meta data not being handled
        correctly?).  I've tested my back script with other LVM snapshots
        --- some exceedingly small (1/2 or 1 MB) with some extreme file
        twiddling on the write side, and I cannot raise the RERR_PARTIAL
        exit code.  Pretty basic file state inspection (using ls, du)
        doesn't show the snapshot failing either.  Despite this I've bumped
        my snapshot size to 8GB (was 128M) for my HOME.
  
I recently changed my backup script to invoke with rsync w/ -v -v and store
the output to (yet another) log file.  After a nightly backup I looked
at the results, and:
   
  1. removed all the lines ending in ' is uptodoate$'
  2. removed all the lines with a space (presumably a log message
         causing RERR_PARTIAL would have a space in it)
  3. removed all the lines w/ ' [-=]> '

I was hoping to weasel this log file down to that singlular file that is
causing the RERR_PARTIAL exit code.  No dice.  All I saw were the
2 filenames I have with a space in them. :^(

So, my questions to the rsync community are:

  1. Am I correct in assuming that rsync *would* write something to
         stdout or stderr when the RERR_PARTIAL condition is triggered?

  2. Have I missed a special flag that would detail why RERR_PARTIAL
     is the exit code?

  3. Any other suggestions to try?

TIA,
-- 
Keith Hellman                             #include <disclaimer.h>
khell...@mcprogramming.com                from disclaimer import standard
khell...@mines.edu
                                   -*-                                    
                    public key @ pgp.mit.edu 9FCF40FD 
    Y!M: mcprogramming                           AIM/ICQ: 485403897       
   gtalk (xmpp jabber): mrtu...@jabber.org, jab...@mcprogramming.com            
          
                                   -*-                                    

"XML is widespread because [a] monumentally stupid standard is still better
than no standard."

-- Alex Belits http://tech.slashdot.org/comments.pl?sid=607491&cid=24105649
CLIENT
------
$ dpkl -l |grep rsync
ii  rsync                                           3.0.7-2                     
    fast remote file copy program (like rcp)

$ rsync --version
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

SERVER
------
$ dpkl -l |grep rsync
ii  rsync                             3.0.7-2                      fast remote 
file copy program (like rcp)

$ rsync --version
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

Attachment: signature.asc
Description: Digital signature

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Reply via email to