I have done some restores directly from backup files (both from OneDrive storage and a local external disk), on the canary build. One of the jobs generated one warning, but I was unable to view the warning. I looked for the warning in different places:
- The message that reported the warning for the job (the usual one when the job finishes) did not have a “Show” button. I do not know if this is the usual behaviour for direct restores, or only happens when there are warnings, but 0 errors.
- The “View Log” web interface (which apparently does not list logs for direct restores).
- Browsing the SQLLite databases in either Duplicati’s AppData or Temp folder did not uncover any stored log on the database regarding this job (I browsed through Duplicati Server’s database as well as the job specific databases).
I was eventually able to view the warning by turning on live logging and running the direct restore again.
A related issue was reported here. Although my situation seems to imply that at least warnings for direct restores are not persistently logged at all.
Is there any official way, currently, to view these logs aside from live logging (which needs some foresight to activate, if you do not expect any errors or warnings)?
I don’t believe there is a way other that what you used (Live logs) or manually adding a log file parameter while setting up the direct restore.
Part of the reason for this is that much of the logging goes into the job database, and with direct restores a temporary database is created then deleted (along with any login that might have happened).
I also couldn’t think of anything that required no foresight, but I did discover that manually typing in Advanced options such as –log-file worked on step 2 “Encryption”, while step 1 “Backup location” choked on that option. Not sure if that was a quoting bug, or a slap-on-the-hand for choosing inappropriate options for that screen…
Because this is already filed as a feature request, I’ll raise the question of whether the UI can make this nicer, because if databases are ruled out, logging to the plain old text file is the only alternative I know of to live log. Perhaps this could also be categorized as UX, because it’s kind of a letdown at what might be a critical time…
I would say that one way to implement that feature (from the user experience angle) would be to guarantee consistency between how the “Show/Dismiss” window works for normal jobs and direct restores from backup files.
That is to say that there would be a “Show” option (now absent for direct restores) in the “You got warnings/errors” notification. That option could then be used by the user to view logs generated during the restore.
From a funcional angle, that would probably mean not deleting the logs/database right away when the job completes (or saving them to another location, or defaulting to a log-file, etc.)
Maybe this can get done as an additional consideration to the current logging issues of too many logs, with the Show button only going to the job log, leaving the user to find the server log. There are forum posts about that, along with possible future plans. Things do move slowly because there’s a lot of need in a lot of different areas.