Hello @UliM and welcome to the forum!
If “delete and recover” (löschen und wiederherstellen) was actually more like the below, then you were in database management, which wouldn’t affect the backup itself, only the database that tracks what’s in it.
msgid "Recreate (delete and repair)"
msgstr "Wiederherstellen (löschen und reparieren)"
I’d suggest slowing down, and turning off scheduled backups because more attempts may make things worse. Unless you’ve already run a compact, then generally changes to backup files are just added files with names like dblock and dindex (in pairs, and many), with a dlist file uploaded to show what’s present.
You can look at your backup files with something that shows dates, to see if it looks like that, or if you got newer dates on dlist files with old dates in the name. The job logs will also show whether a compact ran.
EDIT:
When looking at the actual files, please also check sizes. I see some complaints such as the below that make me wonder if there’s confusion about FTP transfer mode (ASCII versus binary). Got a server log?
“Die Datei duplicati-b87766ae87b7f476890655b1d68ee1547.dblock.zip.aes wurde heruntergeladen und hat die Größe 52602839, erwartet war allerdings die Größe 52398301”
FTP Binary and ASCII Transfer Types And The Case of Corrupt Files
EDIT 2:
The way the math behind that works is that if you assume an encrypted file is very random, the expected chance of something looking like a single-character line ending for your FRITZ!Box OS (perhaps Linux?) would be 1 in 256, so changing a file into the network-standard two-character line ending is expansion of 1.00390625 original file size. That breaks decryption, and is what you got in the two files with size errors:
“was downloaded and has the size 57060, but was expected the size 56845” got 1.003782214794617
“was downloaded and its size is 52602839, but it was expected to be 52398301” got 1.0039035235131
Duplicati code looks like it sets UseBinary = true for backup data transfers, and false for a directory listing, assuming your “Storage Type” is set to “FTP”. If you’re on “FTP (Alternative)”, this concerns me:
DownloadDataType Binary value ignored on ASCII-configured FTP servers #318 but I need to look more. Meanwhile please check your FTP server configuration settings to see if it has one for its transfer mode.
On Duplicati’s end, this Feb 17, 2019 commit looks like it updated its alternative FTP client to a new one.
EDIT 3:
I don’t have the exact right versions to spot the change, but comparing 2.0.4.5 beta to latest canary gets:
2.0.4.5 beta
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> TYPE I
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> 200 Type set to I
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> SIZE duplicati-20181205T233136Z.dlist.zip
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> 213 624
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> EPSV
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> 229 Entering Extended Passive Mode (|||49562|)
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> RETR duplicati-20181205T233136Z.dlist.zip
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> 150 Opening data channel for file download from server of "/ftp_test_1/duplicati-20181205T233136Z.dlist.zip"
(000077)7/3/2019 21:19:43 PM - duplicati (127.0.0.1)> 226 Successfully transferred "/ftp_test_1/duplicati-20181205T233136Z.dlist.zip"
2.0.4.22 canary
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> TYPE I
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> 200 Type set to I
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> SIZE duplicati-20181205T233136Z.dlist.zip
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> 213 624
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> TYPE A
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> 200 Type set to A
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> EPSV
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> 229 Entering Extended Passive Mode (|||49906|)
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> RETR duplicati-20181205T233136Z.dlist.zip
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> 150 Opening data channel for file download from server of "/ftp_test_1/duplicati-20181205T233136Z.dlist.zip"
(000080)7/3/2019 21:22:47 PM - duplicati (127.0.0.1)> 226 Successfully transferred "/ftp_test_1/duplicati-20181205T233136Z.dlist.zip"
testing a “direct restore” from an old FTP backup I had laying around. Notice it now sets ASCII mode then downloads a binary file… Surprisingly, it’s still able to deal with the file, but some FTP servers lie that they actually set ASCII mode. Possibly FileZilla Server does. Or maybe a larger file would expand and break…
@UliM could possibly try the same direct restore experiment, switching from “FTP (Alternative)” to “FTP” if “FTP (Alternative)” has trouble. Which storage type was used before upgrade was done. Is it still in use?