v2.0.5.110-2.0.5.110_canary_2020-08-10 version on Linux got some strange issues when using multiple --source statements. It basically ends up “deleting everything” from the backup. Around 4% of data remained in the last backup set , rest was deleted from the version. Of course it wasn’t that bad, because the block files remained and I’m using versioning. But in general that means that the data was deleted from most recent backup.
108 version works without that problem.
Maybe related, maybe not:
Failed to load process type System.Reactive.Concurrency.DispatcherScheduler assembly /usr/lib/duplicati/System.Reactive.dll, error message: Could not load type of field ‘System.Reactive.Concurrency.DispatcherScheduler:k__BackingField’ (0) due to: Could not load file or assembly ‘WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. => Could not load type of field ‘System.Reactive.Concurrency.DispatcherScheduler:k__BackingField’ (0) due to: Could not load file or assembly ‘WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies.
Failed to load process type Duplicati.Library.Backend.Tardigrade.Tardigrade assembly /usr/lib/duplicati/Duplicati.Library.Backend.Tardigrade.dll, error message: Could not load type of field ‘Duplicati.Library.Backend.Tardigrade.Tardigrade:_access’ (14) due to: Could not load file or assembly ‘netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ or one of its dependencies. => Could not load type of field ‘Duplicati.Library.Backend.Tardigrade.Tardigrade:_access’ (14) due to: Could not load file or assembly ‘netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ or one of its dependencies.
Just warning, that always check out the backup after backup is completed. You might be missing almost all of your data. Luckily I checked and found out that for some reason data isn’t getting backed up.
This is likely the problem. Supporting the Tardigrade and TencentCOS backends (which are built on .NET Standard) required us to move to .NET 4.7.1 (and hence Mono 5.10.0 or greater). However, it seems that there is an issue with mono packaging in Debian-based distributions:
This also causes a problem with our official Docker image:
So far, it seems the solution is to install mono-complete, or the equivalent.
Yeah, seems that it’s not great situation at all. - Thank you so much for the references.
Yet, I’m slightly worried that the application continued to work incorrectly. Afaik, in situation where seriously incorrect operation is expected due to some dependency failing, program should abort.
On some level, I’m curious why that happened, but I believe that it’s enough that the risk is acknowledged, and the program should stop operation in this case. I’m sure that over 90% of people wouldn’t realize that happening. I do always check the end stats, plus diff the 1 vs 0 backupsets. So I wondered the huge number of deleted files. This is again one of things which can become as big surprise to some users and they might get pretty annoyed.
Yes, I’m surprised that the program didn’t abort after the first error. In my testing of the “Could not load file or assembly ‘netstandard’” error, the program did halt immediately. Are you using the command-line to run the backup? Was only one statement executed, or were there many?
Nothing more complex than that, no, I haven’t specified any parameters which should change error handling. I even rechecked for that, so I don’t have any exceptions or debug features in play, which should allow program to continue and ignore some serious errors.