Re: [rdiff-backup-users] "Found too many current_mirror incs!"

[Ron Leach]

On 04/05/2017 06:39, Dominic Raferd wrote:
> On 3 May 2017 at 22:28, Ron Leach<address@hidden>  wrote:

> > I'm assuming the script should be run from the
> > machine that initiates the backup - is that correct?  Or should I be doing
> > this differently?
>
>
> ​The script needs to run locally on the machine that hosts the repository,

Thanks, I've done that and I think there must be, after all that, a 
somewhat more-serious problem.  The regress started then aborted saying

Error 1 occurred when attempting to regress archive...
ls: cannot access 
/srv/Data/101vmail/rdiff-backup-data/mirror_metadata.2017-04-30T19:45:01+01:00.snapshot.gz: 
No such file or directory
Ended Thu May  4 08:15:45 BST 2017
address@hidden:~$

Using mc I checked for the file.  It is missing.  There's a ..diff.gz 
of that time, but no ..snapshot.gz .

For now, and for safety, I've renamed that particular backup archive 
as 101vmail.prior, and initiated a completely new backup of our 
existing mail store, which is proceeding now; I expect it will take a 
little while.  ...201 that I am backing up to is a new build, and I 
still have the previous machine, which used a different address, 
192.168.0.200, offline.  The (original) 101vmail archive is still 
there on that offline machine and I am able to replace the 
possibly-now-incomplete 101vmail.prior on our current backup machine. 
 I probably will, in case that long archival history is damaged.  I'd 
prefer, as well, to revert to increments on that because, 
operationally, it is a little easier to retrieve historic email from a 
current and continuous archive.

Footnote: Returning to the script, for a moment, I've been puzzling 
how I had not previously run into the 'run on backup machine' rule - 
as I mentioned, I'd used the script a few times before, and all our 
backups are onto other physical machines.  I've realised the 
difference.  This particular backup sequence is the *only* instance 
that employs address@hidden::/destination/path; all the others use nfs to 
reach the other machines. And because the nfs destination behaves as a 
local destination on the machine that initiates the backup, so the 
regress script always runs 'locally' in the other instances I've used it.

Dominic, thank you very much for the insights and the script,

regards, Ron