The version(s) being updated to, already exists

Hi everybody. Tell me pls what I’m doing wrong.
I am trying to restore the latest version of the copy to another computer.

Copy options:

Copies are on the WebDav server.

Source:7,78 Gb
Backup:8,54 Gb / 38 Versions

Restore
Building partial temporary database … afte TWO hours, he gives an error “The version(s) being updated to, already exists”

my log:

Duplicati.Library.Interface.UserInformationException: The version(s) being updated to, already exists
в Duplicati.Library.Main.Operation.RecreateDatabaseHandler.RunUpdate(IFilter filter, NumberedFilterFilelistDelegate filelistfilter, BlockVolumePostProcessor blockprocessor)
в Duplicati.Library.Main.Controller.<>c__DisplayClass25_0.b__0(RecreateDatabaseResults result)
в Duplicati.Library.Main.Controller.RunAction[T](T result, String& paths, IFilter& filter, Action`1 method)
в Duplicati.Library.Main.Controller.UpdateDatabaseWithVersions(IFilter filter)
в Duplicati.Server.Runner.Run(IRunnerData data, Boolean fromQueue)

Hi @BotMan, welcome to the forum!

Firstly, youb are not doing anything wrongly - it seems Duplicati is confused and for some reason is trying to update the format of the emp database it just created.

Are you restoring directly from the backup files or from a Duplicati job?

Oh, and is this a practice restore or a little more critical?

Note that I think I’ve seen this issue mentioned one before in December 2019 but I believe the user was backing up, not restoring.

Am restoring directly from the backup files.

Fortunately, I do not rely on backing up with just one program.
But I lost a lot of time trying to recover with Duplicati.
By the way, I could not recover them with help Duplicati

If I restore on the computer on which a copy of the task is being made, then everything goes well, and on another computer an error …
How to be?

UP.
The problem remains relevant. pls help.

Wouldn’t you normally restore differently? On the original source computer, you restore from the backup job, using its database (path is on job’s Databases tab), and on a different computer you won’t have that. Instead, you run direct restore option off the main screen Restore, so Duplicati makes a small database. This, I think, is what the UpdateDatabaseWithVersions name refers to. It’s a versioned form of Recreate.

Can you confirm the difference in your restores? If it’s there, it’s probably is how you got different results.

What’s hard to explain is why the final error happened. Although I’ve only just started looking, it looks like Duplicati raises the final already exists error due to some sort of clash of versions having the same time. Does the direct restore dropdown show time conflicts? How about WebDAV dlist files, if you can see? Possibly a workaround is to try direct restore on an older version or maybe even a new one newly made.

When I chose the version before the last one, it restored without errors.

Does that more or less get what you wanted? If Feb 3 is having trouble, I see you also have Feb 4 and 5.

Exactly what the problem is with Feb 3 isn’t clear without further investigation, but it was somehow there already during build of the partial temporary database which would then be used to restore from Feb 3…

So it surprised me to see this screen talking about Next scheduled task, but I see that’s at 1 P.M. and the restore is 1 A.M. Just please make sure not to backup two computers without keeping destinations apart.

Copies are restored to any date except the last (February 5).

Copying takes place from several computers to one Server, but of course in different directories.
This is my working laptop, to which I am trying to recover files from a remote server.

Of course, restoring not last copy does not solve my problem.
Tell me pls, where is the temporary database created? in a temp folder?

Sorry, I thought the screenshot Feb 3 highlight was what worked, Feb 4 had been failing, and now you had gone beyond there to Feb 5. It now sounds like “another computer” is because original got replaced, right? Getting it back (if possible) would get you the very latest files, but I guess your last backup is the next best.

Unless you set the –tempdir option or something similar, it’s in usual temporary file location, e.g. Windows C:\Users\User\AppData\Local\Temp\ unless you installed as a service, however the names of the files aren’t immediately meaningful, e.g. it’s dup- followed by a random-looking string. Sample dir dup-* /od

01/16/2019  03:17 PM               337 dup-540dfea7-eb48-45d0-ab0f-dfbd9bdfe137
01/18/2019  11:25 AM        52,500,424 dup-0a233c29-cbaf-470b-8449-8ce3634dffd2
01/18/2019  11:25 AM            30,433 dup-6753587f-455b-4d6e-85a3-8259d504e8d3
01/18/2019  11:28 AM         8,197,359 dup-e5304443-3c16-46da-8dea-649c47436470
01/18/2019  11:28 AM             4,605 dup-21f8a794-6831-4234-8ce6-89ce7f1afc9c
01/21/2019  09:02 PM               154 dup-0219dd79-de32-4033-8512-8a477b47350e
01/21/2019  09:02 PM               242 dup-8bbd1bb9-cb02-423c-8160-d530044f1541
01/24/2019  10:38 AM               338 dup-1dcb7741-ff0e-478e-8448-be193ac30355
01/25/2019  07:53 AM               336 dup-90508f02-c597-4cfc-ad7d-40e46d56e5ae
01/25/2019  07:56 AM               336 dup-863258d8-939b-4923-be5f-d727d1ce67c1
01/25/2019  08:16 AM               338 dup-b1dc9c5d-2484-4ea1-b963-175bc4c24247
01/28/2019  08:51 AM               338 dup-7623e237-9ee8-41bb-a0e7-b7f36e844e70
01/28/2019  09:00 AM               338 dup-24e2e8c9-cd4a-4fe0-9755-6035de3c720d

Sometimes people solve problems (in general) by deleting temporary files, which I suppose you could try. The random names should keep Duplicati from re-using files. If so, the problem may be at the destination.

It may really help here if you could look on the server using a WebDAV client such as FileZilla, Cyberduck, or even Windows to see what names of files (especially dlist files) were the last ones uploaded. Ordinarily such information is in the local database as well, but your database is on the (unavailable?) original laptop.

If you can’t install software, Duplicati.CommandLine.BackendTool.exe is there (but hard to use). Example.

EDIT: I tried to follow the source starting with the browser UI code all the way to this error, with little luck… Maybe it would be best to check where you are, to see if there’s another way to get as much as possible. Any history or emails from that troubled final backup, directory listings of its files, whatever, may still help. Bypassing possible date confusion might be possible with repair command to recreate –version=0 (last). Bypassing some Duplicati code might be possible with Duplicati.CommandLine.RecoveryTool.exe to get remote destination files processed locally. Recovering by using the Duplicati Recovery tool gets into use. Bypassing even more Duplicati code can by done with a Python script which has no Duplicati code at all. Basically there are many ways to try to get the last backup, if the next-to-last backup is not close enough.