Attempting to recover files recovered from an old backup for which I no longer have the local database. When attempting to restore from the local files, I receive the following error for each file the restore encounters:
“Unable to create zip_ … decompressor on file …”
I should note that I receive the same error when using the “verify files” command. I can see temp “dup…” files of the same size being created in the temp directory.
I confirmed using the command line that the encryption passphrase is correct, and that the result manually decompressed files (using zip) show details that would seem to indicate that the backup files should be valid.
I attempted to move the temp file from the C drive (in case of rights issues) to the D drive (no restraints) to no avail.
Thanks in advance for your thoughts on a potential resolution.
There are lots of ways to attempt this. Could you clarify which way or ways you’re attempting so far?
Is this “Verify files” the click-to-run in the GUI of a configured job? If so, how did that job get configured, especially since it has no local database (which also makes me wonder how “Verify files” is possible)?
EDIT:
If you’re doing this in the GUI, either as a job created somehow, or as Direct restore from backup files, About → System information will tell you which compressors you have installed. Hopefully it looks like
Thanks much for the response. Turns out that the issue was a matter of file naming. The restores were from long-term storage on OneDrive. It would seem the recovery process added a code to each file name, but before the .aes suffix. USed some external code to parse the fillenames and remname the files and, viola! the process works…if only for backups prior to 01.30.21
Now I just have to figure out if it’s possible to restore more recent backups (recovered from a different local location) for which I have only the dindex and dblock files (I image the dlist files were deleted in some database cleanup steps?)
For your other questions, I used the command line to remove the encryption, then turned the GUI on the resolved files. The GUI presently is rebuilding the local database. Keeping my fingers crossed that the process proceeds to completion…
What recovery process, and what sort of code? Duplicati likely wanted name ends of .zip.aes.
These are the names that the OneDrive web UI should show, and I’d hope they downloaded OK.
There should never be no dlist files even with a bad configuration, unless the “safety” is also removed.
--allow-full-removal = false
By default, the last fileset cannot be removed. This is a safeguard to make sure that all remote data is not deleted by a configuration mistake. Use this flag to disable that protection, such that all filesets can be deleted.
If you truly have no dlist files (check carefully), and no copy of the local database, then all that’s left is a bunch of blocks from the files, with no information on what the files were, or how to rebuild from blocks…
I should add that this means in terms of cleanup steps. If first backup never finished, dlist won’t be there.
If the Duplicati-server.sqlite or job database still exist (sounds unlikely), either one can give an indication.
Sorting files by time can allow one to guess. Does it look like a single run that suddenly stopped upload?
A finished backup will probably also upload a few less-than-full-size (default 50 MB) dblock files as ends.
Thanks for the clarification. Yes…confirmed again that, for whatever reason (likely some manner of attempt to delete an old configuration, I imagine), I have a range of paired dblock and dindex files with no accompanying dindex.
The recovery process mentioned earlier is from Microsoft 365 eDiscovery export process. That process searches retained files for specific features requested in the search. I requested a sweep for files associated with the backup configuration.
As for the files I was able to retrieve from that recovery process, I now am in the “recreating database…” phase, which has been running for about 15 hours or so. Imagining that all will be well once that process (hopefully) completes.
