Hi,
On 21/04/2020 13:46, Dominic Raferd wrote:
> Despite the failed verifications, I have successfully recovered a largish
> (>150MB) file from December 2008 in the impacted repository. As there are
> 2806 later versions of this file (with changes in this file occurring
> between most of these
Hello Brian,
Following up with you. Did you get all the information you need to fix your
initial problem ? Does the migration document contain all the information
you need in order to fix your issue ? If not please let us know so we can
update the documentation.
On Sat, Apr 18, 2020 at 2:19
On Tue, 21 Apr 2020 at 07:17, Eric Lavarde wrote:
>
>
> On 20/04/2020 22:54, Gregor Zattler wrote:
> > Hi Eric,
> > * "Eric L. Zolf" [2020-04-20; 07:43]:
> >> How to detect (under Linux): run `cd MY_BACKUP_REPO; ls -1
> >> rdiff-backup-data/mirror_metadata.* | sed -e 's/^.*mirror_metadata\.//'
On 20/04/2020 22:54, Gregor Zattler wrote:
> Hi Eric,
> * "Eric L. Zolf" [2020-04-20; 07:43]:
>> How to detect (under Linux): run `cd MY_BACKUP_REPO; ls -1
>> rdiff-backup-data/mirror_metadata.* | sed -e 's/^.*mirror_metadata\.//'
>> -e 's/\.[a-z]*.gz$//' | uniq -cd` -> if the output is NOT
Hi,
I've created a fix for the issue at [328], in case someone is willing to
test it on an impacted repo, or rather on a _copy_ of it.
On 20/04/2020 22:04, Dominic Raferd wrote:
>> How do you mean, it fails? A repository not touched since 2013 fails on
>> --verify, or all your repositories fail
