Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't

[Robert Nichols]

On 11/20/2012 02:53 AM, address@hidden wrote:
> I also think problem is definitely LDAP, more precisely that machine is not able
> to get access to LDAP server during a time lap.
> And I think I found the reason (actually when waking up on this morning (seems
> it was good to sleep on it). ;-)
> The 2 machines are starting their respective backup at the same hour and the one
> with the LDAP server is shutting it down during backup (voluntarily) to prevent
> partial/corrupted data backup.
> Thus the other machine is probably not able to resolve user names during a small
> time.
>
> So a good way to fix the issue will probably to postpone one the backup to an
> hour where I'm sure that the other one is no more running.

I would say there is no "probably" about it.  Another option might be to put the
database in read-only mode during the backup and then restart the server in
read/write mode afterward, but that would still leave a momentary gap in service
while the server is being restarted.  You might need to delay the restart until
_both_ backups were complete.  I'm no LDAP expert (never used it, in fact), so
take that with a grain (or two) of salt.

> However I think that the "--preserve-numerical-ids" option that you suggested
> can also do the job. So I have add it to the rdiff-backup so it will be tested
> during next backup.
> Then only I will time shift one of the backup, but if the option is well
> working, that will be an extra data-safety feature.

As I said, I have doubts about whether that will help.  The names are still
recorded in the mirror_metadata file even when "--preserve-numerical-ids" is
used.

> So I'm more than very thankful to you for all your complete and helpful answers.
> ;-)

No problem.  Those of us who lurk on this list do it because we enjoy
tracking down issues like this.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.