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>
khellman at mcprogramming.com from disclaimer import standard
khellman at mines.edu
-*-
public key @ pgp.mit.edu 9FCF40FD
Y!M: mcprogramming AIM/ICQ: 485403897
gtalk (xmpp jabber): mrtuple at jabber.org, jabber at 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
-------------- next part --------------
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20100617/6feb8cf8/attachment.pgp>