So, I’m reparing a couple of local backups on my server, that I don’t trust. Now that I’ve got the backup jobs not running into errors during run, I am trying to delete all old versions, except for the known good most recent run.
So I read the CLI docs, and figured out how to use the DELETE command to do what I need. I ran it on my first backup, and it worked. But I noticed a discrepancy in the version between my home screen and the restore files screen. Having a second backup to do this to, I captured screenshots.
In the following scenario, I:
Compared the versions for the backup on the home screen and restore files screen, and verified that the version counts were the same (3).
Ran the DELETE command using the CommandLine option in the GUI.
Compared the versions for the backup on the home screen and restore files screen. At this point, they do not match (home says 3 still, restore files says 1).
These numbers should match post-command execution, correct?
To add: I also ran a Ctrl-F5 force reload on the home screen to make sure it wasn’t a cache issue in my browser. Things did not change. The discrepancy continued to be there.
Well, more data to add. I just watched the backup run on it’s schedule, and after it completed, the home screen updated to match what is in the restore files screen.
So it appears that the DELETE command does not update the field that the home screen uses for the version count, but a BACKUP command does.
Operations that were executed from the commandline (or from the Commandline section in the Web UI) do not update the number of available versions in the home page. This is a known issue.
I’d even go as far as to argue it’s not an issue. It’s just how it’s designed
The only reason it’s affecting users is because we still haven’t implemented all functionality in the web ui. All the commandline calls are just passed through a wrapper.
Aye. Well, apologies for cluttering up the forums. I’ll start searching GitHub too before posting.
Though after reading that issue thread, I kind of agree with the sentiment expressed here - https://github.com/duplicati/duplicati/issues/2693#issuecomment-364390549. I’ve had to drop to the CLI to fix some broken backups, and it’s been somewhat jarring to deal with the fact that while the GUI and the CLI can work on the same backups technically, they seem to do it in different ways (ie. CLI seems to track DB’s with dbconfig.json file, while the GUI has it in a SQLite DB.
Just thought I’d mention it’s not just CLI vs GUI that can cause a discrepancy.
I’ve got a TEST job (meaning I abuse it regularly) that has 78 versions available to restore but reports only 55 versions in the job menu.
I’ve tracked this down to an issue where a failure in some post-file-backup processing (such as retention cleanup) causes a job run to be considered a failure (so does NOT increment the versions counter).
However, because the error happened AFTER the files were actually backed up, the restore process (which uses actual available data for version listings) actually considers them viable. It’s been a while, but I do recall successfully testing a restore from one of these “orphaned” versions.
I need to try a test, but what I’m worried about for me is what happens if I delete version 0 - will that remove the first most recent SUCCESSFUL backup or the most recent RESTORABLE backup.
Sorry, don’t mean to hijack the topic - I’ve already got one.
