After almost 2 years, a new Beta has taken its time, but it’s finally
there. It’s a roll-up of all the fixes since the last beta build and is
expected to cause very few issues when upgrading. This release is almost
identical to Canary 106.
It involves a better UI for dark mode, better support for Dropbox,
Jottacloud, S3, Tencent backends, add IDrive backend, TLS modernization,
bug fixes, upgrades to libraries.
Points of attention:
database upgrade from 11 to 12: Downgrade from this version requires
manually adjusting the version
number in the database. The additions can be re-applied if the database is
upgraded again later.
Further to my previous post, I just removed Duplicati as a service, pointed to the same database (moved to user folder), ran Duplicati as an application and restore worked fine. Therefore, it seems that the Xamarin.Mac.dll error relates to running it as a service.
You will have to be more explicit as to what you are doing exactly, I created a test backup on a WIn11 VM with the SFTP backend, used it for a few files, tried to restore 1 of them into a different directory: success. Deleted them from the original directory, tried to restore them in place: success. In short, I can’t repro from your description.
Edit: on second thought, I just noticed that Alternate FTP was missing from my install on this Win11 VM. The FluentFTP.dll file is just missing. However, having installed the same beta on a Win10 VM, the very same dll is present, it’s not a problem with the release. So your problem may be related to some newfangled ‘security’ feature of Win11, corrupting files and messing with everything it can. Try to disable all you can of ‘smart’ features of Win11 and install again. I have uninstalled everything in the Win11 VM, removed the service manually and installed again the same .msi for Duplicati 2.0.7 beta and the Alternate FTP backend was back on the menu. Maybe a hardware failure, maybe a Win11 mess.
I’m not sure where I started, but I was using Canary for a long time as a service. Backing up to Wasabi (S3 compatable). I was recently trying to restore a few files, and found I was waiting a LONG time for the restore to list files from database. Thinking something might be wrong with my backup, I checked for updates to see if that might fix my problem. I upgraded to 188.8.131.52, to no avail. At that point, I noticed the Xamarin message referenced above, so I figured it might be helpful in troubleshooting. Either it appeared in 184.108.40.206, or it was there before, but I didn’t notice it. If it’s a log message and not an error, it seems confusing to have the string “error message” in the line.
Is there a reason I wouldn’t be able to run restores when running Duplicati as a service, but can restore properly when running as an application? I’m even using the same database, so it’s not a database corruption. I’ll try to switch back to a service and test. It seems that when running as an application, it doesn’t properly deal with files that are in use (ie. throws an error). I’ll let you know what I find.
I see the message with Duplicati launched as an application.
Your problems are confusing. You say first that you are waiting a long time (how long is long ? 10s ? 10’ ? 10h ?) but don’t say that it does not work. Then you say that it does not work as a service. Then you say that when running as an application it does not work because files are in use (that’s pretty much to be expected., backing up in use files is done with snapshots that are supported only when run as system / administrator).
For the record if Duplicati has a delay before displaying a file version in a restore operation, I see no reason for the delay to be different between running as a service and as an application. Delays are happening when there is a lot of files in the accessed directory, because the query is not well optimized.
Edit: you can remove the ‘error’ message by deleting/moving elsewhere the Dll. It is not used on Windows.
Do you use GUI or command line? Either one should be notifying you by now, and offering this update.
If it doesn’t, then I guess you can do it by hand, but that’s less convenient than letting autoupdate do it.
For Docker users, I think the preferred practice is to update the whole container to the updated version.
sigh. The problem is that with new Fedora versions, default compression is changing to newer shining methods and to actually keep compression methods that are compatible with old bangers like Centos 7, it’s necessary to change the existing .spec files. This was signaled for apt format, but never for rpm, so the spec file was not upgraded for Duplicati.
You can rebuild the rpm following the wisdom fount here:
I was able to complete the build under Fedora 38 and install the resulting rpm with rpm -ivh --nodeps
I could start the server with duplicati-server and it does not crash immediately, and duplicati-cli display the default help. I did not test further.
Hope this helps.
It’d be worth figuring out how you managed to be on 220.127.116.11. Maybe it was with Duplicati autoupdater.
About → System info will show the BaseVersionName which would have been an installation by RPM. ServerVersionName could be different, e.g. if someone did About and clicked Check for updates now.
Duplicati autoupdater doesn’t use RPM, so isn’t bothered by Red Hat’s evolving compression choices.
Usually Duplicati is quite noisy about leading you to updates. Are you on CLI? That might be quieter… Duplicati.Library.AutoUpdater.exe would be the CLI updater. Run it as whatever user Duplicati is using.