Most are likely named to be a bit self-explanatory, but for those that are less so, here’s some info:
–log-level is deprecated by rewrite. See above. Interestingly, only CLI (not GUI, or manual) says:
--log-level (Enumeration): Log information level
[DEPRECATED]: Use the log-file-log-level and console-log-level options
instead
Specifies the amount of log information to write into the file specified
by --log-file
* values: ExplicitOnly, Profiling, Verbose, Retry, Information, DryRun,
Warning, Error
* default value: Warning
and the DEPRECATED text seems like it’s code-generated, including the references to “instead”:
new CommandLineArgument(“log-level”, CommandLineArgument.ArgumentType.Enumeration, Strings.Options.LoglevelShort, Strings.Options.LoglevelLong, “Warning”, null, Enum.GetNames(typeof(Duplicati.Library.Logging.LogMessageType)), Strings.Options.LogLevelDeprecated(“log-file-log-level”, “console-log-level”)),
New log system with filters talked about some of the changes between the old and new log systems.
You’ve found one reason why there are many levels. The amount of data that’s logged varies quite a bit.
2.0.3.10_canary_2018-08-30. made default Profiling quite a bit shorter than it used to be though, due to
Removed some logging details in core performance areas (can be re-enabled with
--profile-all-database-queries)
What’s unfortunately needed to find the original cause is the --profile-all-database-queries log of issue creation. Tripping over an existing issue doesn’t say much about how the issue was created originally.
Reproducible-from-scratch breaks are debuggable, but I don’t think we have such a situation with this.
Creating a bug report can sometimes offer clues, but this too is mostly point-in-time, not a root-cause.
This was mentioned in an earlier post, which also talks about deleting a single version, which worked. Sometimes it does. Other times this problem moves. Only the first version found that fails is reported.
I’m not sure fresh start is faster. Especially if you set no-auto-compact, I think it should be quite quick, involving some marking of local database, and a remote dlist file deletion. It’s probably even reversible using file copy of the database and the dlist files (but not tested). If compact runs, that’s not reversible.
If you want to try the delete to see if it helps, set --no-auto-compact (recommended, not required) then Commandline, change Command to Delete, and change Commandline arguments box to --version=2.