Works well here except for the known bugs that hit occasionally and which Beta has too, but YMMV.
I don’t know any reason why you would have to. If the format was too new, it would have complained.
If you’d prefer not to do anything I suggested above for debugging, you can certainly do that if you like.
If it works, at least things are as you wish, but a mystery remains. I would suggest at least setting up additional logging in case it occurs again someday: log-file=<path> and log-file-log-level=Information.
This will record files that Duplicati uploads, although it’s not the full path. All this information is in your database currently, but if you will neither look nor provide, there’s nothing more that I can do with that.
I created the database bug report (769mo in a zip) and when I open it in “DB Browser for SQLite” software I can see the structure but not the content of the database.
I don’t understand correctly how to use the affected command even with your link probaly because of my poor english.
i’m not sure create a new backup will work like i already did it when i switched to beta version, was just an idea because of the Duplicati-server.sqlite file.
Those were two separate options,with the first being a privacy-preserving one to give away per manual, which explains what is obfuscated. What’s not obfuscated (but is not private) are destination filenames.
If you mean
then click to
and try some of your 181 files to see if Filter by Name finds any knowledge about them (row appears).
Do the same thing in RemoteOperation table, except the column name to enter as a Filter here is Path.
If rows show up, you can screenshot or right-click Copy. If nothing shows up, source of file is a mystery. Possibly they were from some other backup, or maybe from some other time if you ever used top folder.
Having it only be dblock files would be odd for that. You would usually also get at least some dindex files.
The database records are not as reliable as the log-file would be because backup error may undo them.
Undoing (known as rollback) is good for consistency when changes half-complete, but not good for logs.
Browsing the database by hand as above is in some ways better and in some ways worse than affected command. It’s a little more certain if one wants to show that the database has no knowledge of your files, however doing the whole affected command by hand would be very complicated and better left to code…
I didn’t post whole database structure view because it’s irrelevant. Click parcourir les données and go.
You’re on the wrong tab. Notice how highlighting (yours and mine) shows which tab is currently active.
If you’re talking about the tiny “Tables (21)” bit I posted, the difference is because yours is a bug report.
The FixedFile table is the privacy-protected version of what is ordinarily in two tables (one for prefixes).
Then they’re probably irrelevant, although their source is a mystery, although I haven’t heard anything back about how pCloud works, or the possibility of earlier testing. Best path forward might be to look at extra file dates to see if they fall within a backup log timeframe from a current backup configuration. If outside of all, that’s more evidence that they’re no longer useful. This also assumes that date on pCloud can be trusted.
Best proof that they’re not relevant is also a test that’s good to run occasionally anyway, to prove database recreation from destination files works smoothly. The simple form is the Recreate button on the Database screen, however to be more careful and get a good look, I suggest instead you copy the database by hand before letting Recreate button delete it. This allows going back, or further research if bug report is needed. Similarly, move the 181 files elsewhere to see how things go without them. If all goes well, then do deletes.
To see how things are going, if you can stand to look at status bar progress, 70% is a good finish. If it gets beyond that, especially in 90% to 100% range, it’s downloading the dblock files in search of missing blocks.
For a live view of actual downloads, you can watch About → Show log → Live → Information, switching to Verbose level if you want more details. For unwatched tests, set log-file=<path> log-file-log-level=verbose then look later with a text editor. This will also log any errors and warnings well, if any occur. Those matter.
It’s unclear how well Recreate ran because of no report back on anything asked in my last two paragraphs.
Fortunately you can still look retroactively at <job> → Show log → Remote. Is top line dindex or dblock file?
If final get was dindex file, that means everything was clean, no dblock search needed, so delete your 181.
If you see dblock downloads, situation is more complicated since some issue caused the extra downloads.
You can either live with slower recreate (which wound up OK in the end – good), or we can do more things.
EDIT:
An alternative way to examine download volume is from recreate log’s Complete log “FilesDownloaded”.
If it’s something like 6994, that’s bad. If it’s about half that, you probably had a clean run with the Recreate.
I forgot activate verbose in about > show logs > distant, so if i do it now i show only today
do you want I do it and restart the operation on database ?
Your recreate log said it ended at 13:31:36, and latest screenshot shows last get at 13:28 was dindex.
Your backup log said it started at 13:31:45, so the 13:32 list belongs to backup, and is a typical start.
Recreate looked clean, needing no dblock searching, so those 181 might be from some other backup.
Unless you want to try to speculate based on their date, deleting them shouldn’t affect current backup.
Then why not just delete them? If you truly want to investigate their source, then I need answers requested, which still might not be enough, in which case you would need to reproduce the issue with better recording.
