When I restore files using the backup job (no recreate database needed) everything is fine.
But when I restore files on another system (Direct restore from backup files) the recreate database operation fails partially (this does not seem to have a massive effect on the backup files).
I get the following warning and error:
Warnings 1
2022-10-15 09.00.04 +03 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Found 1 missing volumes; attempting to replace blocks from existing volumes
Errors 1
2022-10-15 08.59.24 +03 - [Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-bb7003aad5c8f43ba8f40f4b1199f6d77.dblock.zip.aes by duplicati-ie0ca3083d0d14b738a6889a041d1f582.dindex.zip.aes, but not found in list, registering a missing remote file
My duplicati version is 2.0.6.3_beta_2021-06-17.
Is it possible to know which files are effected.
There should be a reset option to start retention again from 1 for situations like this.
What is this error all about, is it a bug.
Is there any other solution than make a new backup job.
No files are affected
System.InvalidCastException: The defined attachment is illegitimite (freely translated from finnish) and a lot of lines starting At object (badly translated from finnish). And finally Return code 100.
The parent file(which I used as an existing file) is duplicati-ie0ca3…dblock.zip.aes and the missing file is duplicati-bb7003…dblock.zip.aes so there is no date. Does this mean that no files are effected and everything is fine.
Err… do you know that it’s possible to edit an existing post instead of spreading your reply in 3 different posts ? and about the translation, that it’s possible to actually switch your Duplicati Web UI to english to get it to translate the error messages for you ?
About your error messages, they look dire instead of fine. An existing dblock file should not return no affected file. And a missing file should not return a backtrace - it seems that this what happen, although I can’t be sure from your description.
Unless… you are not running anything other than direct restore from backup files on the ‘another system’ for sure ? Duplicati is definitely NOT intended to be running from 2 different computers targetting the same backend. So if you are trying out another computer to check on a ‘live’ backup of a working system, you should never attempt any ‘repair’ of data. This is a good way to make things worse.
If you have a working system and a damaged backup, you should repair it on the working system.
If what you want is to do some checking, ideally if space allows, you should copy the whole backup locally and try your testing from that.
If some remote file is missing, the root cause can be diverse.
If the remote backend is unreliable, the best way is probably to scrap the backend and do a new backup.
If some backup has crashed for whatever reason (target or source computer crashed, network problem) and a backup version is damaged, it’s usually the last backup version and the best way is to delete the last version and continue backups.
If some backup manager has found that backup size was exceeding backend capacity and decided to either ‘clean’ old files manually, or set up some automatic cleaning of old files, the best way is to scratch the backup and try again (deleting old files will probably damage the whole backup set beyond repair).
Maybe that’s duplicati-ie0ca3083d0d14b738a6889a041d1f582.dindex.zip.aes.
I’m not sure why you call it a parent, but it does reference a missing dblock file, so the
answer being sought is whether it’s an extra dindex or if a still-in-use dblock vanished.
Which system did you ask? This is database-based, so original system may do better
(meaning not give any odd error, if you’re saying you got an odd error after an answer).
You are right it is that dindex file and on the original system using the backup job everything is ok because you do not need to recreate the database. I guess I have to define a new backup job and hope that the error does not return.
So you still have not asked the affected command about duplicati-bb7003aad5c8f43ba8f40f4b1199f6d77.dblock.zip.aes on original system to see if you get clean reply?
You might just have an extra usless dindex pointing to a dblock that isn’t there but has no relevance…
If you mean start fresh (and lose old versions), you certainly can (and feel more secure), if you prefer it.
EDIT:
is another option, and above that you can see a difficult-and-uncertain method for checking the situation.