[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ron Leach
Subject: Re: [rdiff-backup-users] "Found too many current_mirror incs!"
Date: Thu, 04 May 2017 09:44:57 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10

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

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,, 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]