I am trying to adopt a backup archive, i.e. I have an archive (in the cloud) to which I previously backed up my drive D. But I don’t have any traces of that backup job locally anymore. So I created a new backup job and pointed it at the folder in the cloud that contains the previous backup archive. Then I ran repair, but all I get is this error:
I also tried Recreate (delete and repair) but with the same result.
Why can duplicati not parse its own files? (I did copy them from one cloud to another using rclone, but that would hardly have corrupted the files?)
The “files at the remote storage, but none that could be parsed” message exists in two places in the code. In both cases it appears it is shown only if any of the file NAMES found don’t match up with the names associated with the backup job.
So I THINK it’s complaining that it found archive files for what it thinks is a different backup (likely due to the the “unique” internal GUID assigned when the new backup was created).
I’m pretty sure this is recoverable, but I’m not sure how to do it - hopefully @kenkendk or @kees-z while have a suggestion on the right way to handle it.
Here is some additional information: when I try to browse the files in the backup via “Direct restore from backup files …”, I get the error
No filesets found on remote target
and when I then click on “Show”, I get another error
Failed to connect: SQL logic error or missing database no such table: LogData
And when I go to the logs, it seems stuck on “Loading …”
I might add that even though duplicati does not seem to do anything with this backup archive, it nevertheless seems to have somehow figured out how big the archive is and how many versions it contains:
That means that no
.dlist files were found.
That is just because the database is not yet created. Stupid error message, I know, but you can ignore it.
Same problem as the other one. Safe to ignore.
Can you show a few filenames? I am guessing that they do not match what Duplicati expects. It should be “duplicati-.<dblock|dindex>.zip.aes”
Good point! My files don’t look like that at all. So this must be some test backup I did with another software last year…