D2 stuck in delete and create local DB

[avmaksimov]

I had an error in DB with my backup so I decided to delete and create DB.
But now I see that progress stuck in one state. It’s almost done (may be 97%) and nothing’s happened neither in ExplicitOnly Logs in About\Logs nor with DB file.
Before I see that dbname.journal was created, but now it’s absent. So I think everything was commited to DB.

I have a big backup and I don’t want to do it again. And I think there is a big probability that it will happened again.
D2 ver is: 2.0.7.1_beta_2023-05-25 (x64).
Windows Server 2019 x64.
So… What should I do with it?

P.S. I put log text and ‘Failed to load assembly’ I see every time I refresh the page. But I think the problem is not in it.

* Sep 6, 2023 7:35 AM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 6, 2023 7:35 AM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 6, 2023 7:35 AM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 6, 2023 7:35 AM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:55 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:55 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:55 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:55 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:11 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:11 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:11 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 10:11 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 8:57 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 8:57 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 8:57 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 8:57 PM: Failed to load assembly C:\Program Files\Duplicati 2\Xamarin.Mac.dll, error message: Неабстрактный метод, не являющийся методом .cctor в интерфейсе.

* Sep 5, 2023 5:16 PM: CommitRestoredBlocklist took 0:00:00:00.003

* Sep 5, 2023 5:16 PM: Starting - CommitRestoredBlocklist

* Sep 5, 2023 5:16 PM: ExecuteNonQuery: INSERT INTO "BlocksetEntry" ("BlocksetID", "Index", "BlockID") SELECT DISTINCT "H"."BlocksetID", "H"."Index", "H"."BlockID" FROM (SELECT "E"."BlocksetID" AS "BlocksetID", "D"."FullIndex" AS "Index", "F"."ID" AS "BlockID" FROM ( SELECT "E"."BlocksetID", "F"."Index" + ("E"."BlocklistIndex" * 3200) AS "FullIndex", "F"."BlockHash", MIN(102400, "E"."Length" - (("F"."Index" + ("E"."BlocklistIndex" * 3200)) * 102400)) AS "BlockSize", "E"."Hash", "E"."BlocklistSize", "E"."BlocklistHash" FROM ( SELECT * FROM ( SELECT "A"."BlocksetID", "A"."Index" AS "BlocklistIndex", MIN(3200 * 32, ((("B"."Length" + 102400 - 1) / 102400) - ("A"."Index" * (3200))) * 32) AS "BlocklistSize", "A"."Hash" AS "BlocklistHash", "B"."Length" FROM "BlocklistHash" A, "Blockset" B WHERE "B"."ID" = "A"."BlocksetID" ) C, "Block" D WHERE "C"."BlocklistHash" = "D"."Hash" AND "C"."BlocklistSize" = "D"."Size" ) E, "TempBlocklist-D6D3ACCEBEBADC4EB70F991DBD7A7B69" F WHERE "F"."BlocklistHash" = "E"."Hash" ORDER BY "E"."BlocksetID", "FullIndex" ) D, "BlocklistHash" E, "Block" F, "Block" G WHERE "D"."BlocksetID" = "E"."BlocksetID" AND "D"."BlocklistHash" = "E"."Hash" AND "D"."BlocklistSize" = "G"."Size" AND "D"."BlocklistHash" = "G"."Hash" AND "D"."Blockhash" = "F"."Hash" AND "D"."BlockSize" = "F"."Size" UNION SELECT "Blockset"."ID" AS "BlocksetID", 0 AS "Index", "Block"."ID" AS "BlockID" FROM "Blockset", "Block", "TempSmalllist-14A3B0B131B8B0448474829DBF32C5D3" S WHERE "Blockset"."Fullhash" = "S"."FileHash" AND "S"."BlockHash" = "Block"."Hash" AND "S"."BlockSize" = "Block"."Size" AND "Blockset"."Length" = "S"."BlockSize" AND "Blockset"."Length" <= 102400 ) H WHERE ("H"."BlocksetID" || ':' || "H"."Index") NOT IN (SELECT ("ExistingBlocksetEntries"."BlocksetID" || ':' || "ExistingBlocksetEntries"."Index") FROM "BlocksetEntry" "ExistingBlocksetEntries" ) took 0:00:05:47.415

[gpatel-fr]

Hello

Your backend has become very damaged and is causing Duplicati to be very slow in rebuilding.
There is an experimental workaround to make it faster and you can (if you have a Github account) download it from there:

try run update db query for every block file only when needed

[avmaksimov]

Thanks for your answer. So is it correct that about 12 hours D2 is not stucked but waiting backend?
My backend (via WebDAV), I think is good but Internet at the office may be not so good as expects.

But my D2 ver is 2.0.7.1 beta. Is it correct to install 2.0.6.3 canary from you? Why it has so strange number with build today?

[gpatel-fr]

@avmaksimov

So is it correct that about 12 hours D2 is not stucked but waiting backend?

It is working but very slow, this has nothing to do with the backend.

@avmaksimov

Is it correct to install 2.0.6.3 canary from you? Why it has so strange number with build today?

Well, if you don’t trust a binary coming from the Duplicati source repo,

[avmaksimov]

@gpatel-fr

Well, if you don’t trust a binary coming from the Duplicati source repo

It’s not about trust. It’s about good working after this upgrade. Ok. I’ll try later and write results.

[avmaksimov]

@gpatel-fr

It is working but very slow, this has nothing to do with the backend.

Why do you think so? There are no information in log for about 18 hours.

[gpatel-fr]

@avmaksimov

Why do you think so?

because it’s a well known problem, see this thread for example:

Duplicati Database Recreate running for a week

Running 2.0.7.1_beta_2023-05-25 Had an issue with the machine I run Duplicati on I have a backup of the Backup Config from when I set up the job,and the files to date,but when importing the job and connecting it to the folder it gives an Out of Sync warning and repairing doesn’t want to proceed Recreating the database is running for days now with no end in sight on 2 different test machines

[avmaksimov]

Hello! The new version is much better. And I saw DNS Server didn’t work properly one time. I don’t know why but may be it was a reason in D2 stucking…
But! Now I have another problem: “database disk image is malformed”. I tried 2 or 3 times with the same result.
And BTW I started deleting and creating DB after this message. The disk is good. May be there are some limits in files or DB? I don’t undestand. But I have a DB much more than this.

[gpatel-fr]

Can you provide a trace of the db recreation ?

Duplicati.CommandLine.exe repair your-connection-string --dbpath=/path/to/your/db  --console-log-level=verbose --compression-module=zip >/path/to/logfile.txt

you can get the connection string from exporting the job as command line, and the db path from the job (you can set any path you want of course). Add “” to surround the parameters as needed (it is needed for the connection string)

You have either to include --no-encryption=true or add your encryption key using the --passphrase parameter and --encryption-module=aes if your backend is crypted.

Then attach the logfile here after stropping out the private info.

[avmaksimov]

Thanks for your answer but I solved this problem by another way. I exported to json and imported on another computer (ver. 2.0.7.3) this backup, created DB and replaced DB on the target computer. Everything is good now. May be reason in bad Internet. I don’t think there is a bad disk because it’s a system disk and everything is good (chkdsk said the same).