rdiff-backup-users
[Top][All Lists]
Advanced

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

Re: corrupted metadata


From: Robert Nichols
Subject: Re: corrupted metadata
Date: Mon, 7 Sep 2020 22:11:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 9/7/20 10:47 AM, Marco Strullato wrote:
Il giorno dom 6 set 2020 alle ore 23:07 Robert Nichols <
rnicholsNOSPAM@comcast.net> ha scritto:

On 9/6/20 1:42 PM, Marco Strullato wrote:
Hi all,

it's my turn, metadata got corrupted. From the log I see:

"*Error: Warning, could not find mirror_metadata file. Metadata will be
read from filesystem instead.*"

I did follow the faq in the guide, but the trick is unsuccessful.
https://rdiff-backup.net/docs/FAQ.html#regress_failure

That FAQ section really isn't relevant to your problem. What do you see if
you go to the rdiff-backup-data directory in the archive and run "ls -l
mirror_metadata* | tail" ?

Hi Robert,
actually that file doesn't exist...

This is what I see:
ls -l rdiff-backup-data/

total 252
-rw------- 1 pi pi 222513 Sep  6 20:32 backup.log
-rw------- 1 pi pi      0 May 16 15:20 chars_to_quote
-rw------- 1 pi pi     10 Sep  5 09:45 
current_mirror.2020-09-05T09:45:28+02:00.data
-rw------- 1 pi pi    144 Sep  5 02:31 
file_statistics.2020-09-05T01:01:42+02:00.data.gz
-rw------- 1 pi pi    144 Sep  6 20:06 
file_statistics.2020-09-06T19:53:22+02:00.data.gz
-rw------- 1 pi pi    144 Sep  6 20:31 
file_statistics.2020-09-06T20:18:25+02:00.data.gz
-rw------- 1 pi pi    144 Sep  6 20:45 
file_statistics.2020-09-06T20:32:46+02:00.data.gz
drwx------ 3 pi pi   4096 Sep  6 17:56 increments
-rwxr-xr-x 1 pi pi      0 Jun 27 06:09 increments.2020-09-05T01:01:42+02:00.dir
-rwxr-xr-x 1 pi pi      0 Jun 27 06:09 increments.2020-09-05T09:45:28+02:00.dir
-rw------- 1 pi pi    242 Aug 15 15:58 restore.log

Since all of the mirror_metadata files appear to have been deleted, there isn't
much left besides the current mirror and the attributes that are attached to the
files and directories there. If those backups actually completed successfully,
I don't know how those metadata files could have been lost except by manual
deletion. In any event, unless there is something in particular you need to
recover from this damaged backup, I would suggest just throwing it away and
starting fresh.

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




reply via email to

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