Re: [rdiff-backup-users] How to cope with missing 'rdiff-backup-data' in destination directory

[Dominic Raferd]

Hello rdiez,

I have done a simple test of this scenario but when I run rdiff-backup --verify I don't see any warning messages. (I believe the SHA1 digests are held in the rdiff-backup-data/mirror_metadata.* files.)

See some postings here and bug report (with proposed fix) here: similar messages were generated by files with more than one hardlink.  (Note to Sol1: even if this is not the cause of OP's problem here, it seems like a good bug to fix...)

IMO it would be worth the initial hours to do a 'proper' initial rdiff-backup run and start with a clean repository that verifies without any warnings.

Dominic

On 18 February 2016 at 09:05, R. Diez <address@hidden> wrote:

Hallo Dominic:

Some time ago I posted this question:

https://lists.nongnu.org/archive/html/rdiff-backup-users/2016-01/msg00006.html

And your answer was:

> If you do as it suggests and run rdiff-backup with --force option, it > should complete successfully and convert the destination directory in > an rdiff-backup repository.

Like I said, I found what the problem in my script was:

Ah, now I understand. My script was doing a first sweep with "--force",

> but also with "--remove-older-than", which of course will fail in
> this scenario. I wrote the thing some time ago. Thanks for your help.

However, I have just realised that "--force" is not a "complete" solution, because it does not actually regenerate the metadata inside the 'rdiff-backup-data'. I noticed because my script does a verification step at the end, which then issues the following warnings:

rdiff-backup --verify --no-acls "dest"
Warning: Cannot find SHA1 digest for file file1.txt,
perhaps because this feature was added in v1.1.1
Warning: Cannot find SHA1 digest for file file2.txt,
perhaps because this feature was added in v1.1.1
Every file verified successfully.

As mentioned, I am taking over a previous rsync backup with a huge number of files, and there are too many warnings like that. Copying all files again from an external, very slow USB drive would take many hours.

Is there a way to regenerate the SHA1 digests for all files in the destination directory?

Regards,
  rdiez