Accidentally duplicati backup a huge file (1GB) for 2 or 3 backup versions… so I decide to run the purge command. Duplicati do something (the whole process continue for 40-50 minutes), no error occoured but nothing happen: the file is here - I see it in the tree-view of restore process and is here in any version it was backuped.
I try the “auto compact” but the result is “nothing to compact” - it make sense because the “overhead” is about 1% (the whole backup is about 120GB and the file is 1GB, the “data overhead” is 1.2%).
So, my question is: how can I delete file from backup set (of course the file is deleted from source path)?
Err… do you mean that Duplicati does not display anything at all ? As far as I remember, running ‘purge’ command in the UI displays some messages, it would be interesting to see them.
If you can do the operation again, try to add the LogLevel option at ‘verbose’.
This stuff is a trace and it can serve you to understand what is happening.
Unfortunately as the crystall ball that allows me (normally) to see what is on the other posters screen and explain it for them is currently off service for maintenance, I can’t provide you with more help than pointing you to duplicati.com to read the documentation.
If it’s about copying, it’s the normal browser operating procedure. On my system, I click on the beginning of text to select, then scroll the browser window then holding the ‘Shift’ key I click on the text end, then Ctrl C to do the copy.
Once you have your text paste it directly in your reply, preceded by three backticks at the beginning of a new line like this ``` to avoid any formatting.
I did a test with explicit only and it did not overflow my browser window, so if you do the test with only ‘verbose’ it should do without problem.
Rather than post a load of info on Duplicati’s something, can you describe how exactly you ran that purge?
The PURGE command describes the syntax. GUI Commandline is a good place to run it. Please describe.
If you’re doing it from CLI you can actually copy and paste the whole line. Redact the private info, of course.
It makes sense because compact only compacts wasted space (potentially 1%), but file is still backed up, therefore space is not wasted so long as the unwanted file is in any backup that’s still maintained, and it is.
The (potentially dangerous) purge command is what to use, but I’d like to learn how you’re actually using it.
Because any accident can purge the wrong thing, possibly you can practice usage on a small test backup.
That works fine here on Windows (what do you have?), but remember to also set the command dropdown.
One oddity of purge is that it doesn’t make a log. If you accidentally ran backup command, you’ll get the log.
Some of these commands don’t like options that backup might take. I thought maybe an include or exclude possibly would hurt purge, but it’s smart enough to complain. Regardless, maybe try simplifying the options.
You can also do the suggested small test backup. If it purges OK, try to start looking at difference in original.
Although purge should work (and can be valuable), how many hours of fighting is it worth to save the 1 GB?
Hi today i’m digging into this trouble. The command line result this:
Connection error, retry in 2 sec ...
Connection error, retry in 2 sec ...
Database file does not exist: C:\WINDOWS\system32\config\systemprofile\AppData\Local\Duplicati\XHEWXHIATP.sqlite
Return code: 100
The db path is wrong!
Yes, I run duplicati in administrator mode, and yes I move the database to another path. Please note: I have 1+ year of backup and it works fine. When I run the purge command the target url is the path when .zip.aes files are stored.
When I try this kind of stuff, I use the job export as command line as a basis. If Duplicati is run as a task, run as your normal user. If it is run as a service, run as the service user (usually system = administrator). Then in the command line:
replace ‘backup’ by ‘purge’ (duh)
remove any filter or exclude
replace (or complete) the target by the complete path to the file or directory to purge
(optional) add --log-level=verbose
(optional) add --dry-run (allow for some respite in case of bad mistake)
leave the rest alone and hit Enter. Should run fine. Does for me at least.
It should be exactly what the webui Database screen has in Local database path field, whether you use the Commandline screen or Export As Command-line, however if you run it outside of GUI, be careful your local file permissions give you write access to the database and whatever else you need, especially when database is in a locked down area like Windows C:\WINDOWS\system32\config which I’m glad you’re not using (if I understand you correctly), because Windows version updates impolitely move it to Windows.old.
Regardless, I’m glad whatever was going on got solved.
If you ever want to do GUI operations, you might want to type in the right database path, then Save the path.
Meaning what exactly? On the Options screen, empty Advanced options is where the setting starts.
It’s exactly the sort of path Duplicati.WindowsService.exe would have made if you ran that for a service, which seemingly you did because you then heard of the peril of the default database path, and moved it.
I don’t know why earlier purge didn’t choke, and I’d be amazed if GUI backups were happy with the path.
One way to tell what database you’ve been using for backups is to see what sort of logs they can show.
Run how? GUI, CLI? Which dbpath, and where did it come from?
EDIT: And are you sometimes removing dbpath? That can be bad.
That’s the behavior expected on the page that you get from clicking Commandline (if that’s what you meant by web-ui) but it’s an odd way to run a backup. It should work, but Run now using stored options is the usual.
How exactly? Commandline and remove dbpath? When there’s no dbpath specified, an implied one is used, tied to the Target URL and remembered in the text file dbconfig.json in the folder with the other databases which is by default in the user profile of whatever user Duplicati is running as. If you consistently remove the dbpath then run CLI or GUI Commandline screen (and no other), it will always use that implied CLI database.
If you go pull the implied database path out of dbconfig.json, you can type it into the GUI to get it in line too. That will give you the option to more easily do the GUI tasks besides those you hand-build for Commandline.
A good first thing to do if you do this is to run Show log to browse the history of the database as said above. Possibly you’ll see your recent backups there, which would be great. All modes will then all be on same DB.
Correct this is what I mean as “web-ui”. But there is a misunderstanding:
First of all: I run the backup clicking on “execute now” on the “home screen”.
Now, if I will delete files from backup I use the purge command in web-ui. Of course before to perform this action I must edit the command line (edit the forms in web ui). Now if I delete the dbpath, duplicati use this path for DB:
and if I don’t delete the dbpath in command line options all works fine.
I don’t understand why duplicati execute the purge command with the wrong dbpath instead of return an error. In this scenario duplicati should be return an error (because) XHEWXHIATP.sqlfile don’t exist in my HD.