This is purely a "straw man" approach, entirely built using my limited
knowledge of Notes on the server side, and my *nix skills :-)
Notes "compacts" and updates indexes for databases, typically using
server agents, which (typically) run at night. If you have archiving -
or expiration management (which automatically deletes documents, such as
email messages) after a certain time has passed, then the compaction
will result in a much smaller file.
If backups are running at the same time, then consider: what would
happen to any software that was reading a file for backup? This is not
random access but from start to finish, treating it as a series of
bytes. At some point, a read could very well return failure because the
file has been deleted. This is because Notes "compacts" files by
writing to a new file, then deleting the old one. Index files (in a
subdir called "<database-base-filename>.ft/") can vanish the same way,
when an index is rebuilt.
Quite aside from the individual compaction of files, there's this to
consider: If rsync first enumerates inodes (is this a *nix box?) on a
largish file system, then attempts to read those inodes, the entire
directory could be "gone" (with new files in place of the old ones).
You can see the same thing using "find . | cpio" when the files exist
when 'find' runs but are gone when 'cpio' goes to read them...
Issues with this straw man:
a) it's hard to believe that out of 100 files, only one would be
backed up. That's the perfect storm. Is your issue repeatable? If it
is, then there is something else going on too.
b) You state that the backups were working at some point. This
implies a change that brought about the issue(s) - did you upgrade
notes? Upgrade the templates used for your databases? Implement agents
that run at night, where before there were no agents?
This is how I'd approach it. If you turn on file listing in your
rsyncd.conf you may see that those files are listed. If they are not
even listed in your rsyncd logs, then you know it's on the client side,
not the backuppc server.
Hope this helps.
Tony Nelson wrote:
Hi All,
I'm running BackupPC-2.1.2 quite successfully on my network. Over the past
couple of days something very odd has happened backing up Lotus Notes mail
files on one particular server. Looking at the transfer log I find:
[snip]
create 644 400/401 163053568 mail/cbotwin.nsf
create 644 400/401 39583744 mail/cfrierso.nsf
mail/ckienle.nsf: md4 doesn't match: will retry in phase 1; file removed
create 644 400/401 815529984 mail/claforge.nsf
create 644 400/401 132120576 mail/dfischer.nsf
[snip]
and further down
[snip]
create 644 400/401 919076864 mail/ckienle.nsf
delete 644 400/401 33030144 mail/spursley.nsf
delete 644 400/401 409468928 mail/nrivera.nsf
[snip]
When viewing the backup in the GUI, the only file I find is this directory is
mail/ckienle.nsf, where there should be around 100 files. All the rest are
listed as having been deleted (as above).
Any ideas what might be going wrong?
This backup has been working fine for well over a year, using rsncd to
cygwin-rsyncd running on a win2003 server.
Any help would be greatly appreciated.
Tony Nelson
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
BackupPC-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
