Web-ui version restoring full backup instead of single file

I am trying to restore a single file on the web-ui version 1.5.0 on linux.
But when selecting the revision, and the single file I want to restore, and clicking restore (with that single file highlighted), duplicacy is actually restoring the full backup.
I tried several times but don’t see how I can restore a single file :frowning:

To restore an individual folder or file, you need to click on the little folder icon next to where it says Revision # - that’ll open up the file tree and you can drill down further by clicking the icons.

Yes, this is exactly what I did, I went through the file tree, a few folders down in the hierarchy, than I selected the file I wanted to restore (which font becomes bold), and clicked on restore.
Still, duplicacy is restoring all the backup. I don’t know where I could go wrong there.

Clicking restore here will restore 1TB of backup instead of a single file

What am I doing wrong?

The icon expands the tree but you have to click the folder or file to highlight it for restoration. :slight_smile:

*Edit: It looks like you done that, but if you only selected that one file, it should only restore that one file - if there’s files that already existing in the destination folder, they won’t be deleted, but you may notice extra meta data chunks being downloaded(?).

Thank you Droolio. I appreciate you taking the time to answer.

Isn’t that the case in the screenshot above and why the first file font is actually bold (and others are not).
If I don’t select it, actually the restore button is disabled, so it seems to me it’s correctly selected / highlighted ? Isn’t it?

Does it highlight in a different way when you click the file name itself? Is there anything odd about the characters in the file name btw?

Edit: you’re right - the selected file should show up in grey and be bold, hmm.

In the file name, there is an é with accent (french word décompte), there are spaces, and parenthesis.
The very top parent folder is -- Mes documents --
I checked the log but haven’t seen any error, just restoring all chunks

Perhaps try restoring just the 2021 folder containing it, if it’s not so big?

If that works and restoring the individual file doesn’t, it sounds like it’s not passing the file name properly as a filter to the CLI…

I tried, unfortunately it’s still restoring the full archive

And there are the logs

Your log does suggest it’s using a restoration filter (i.e. Loaded 1 include/exclude pattern(s)) - is your 2021 folder that big or is it definitely restoring the whole repository.

This is a weird one… perhaps @gchen can suggest what could be amiss?

The 2021 folder is small: about 3MB, only 6 PDF files.
It’s restoring the whole repository unfortunately

@gchen, I think your help is needed here. @Droolio has already helped and made some correct suggestions but it seems there is still something wrong with @elorn restore attempt.

1 - Since Friday, I let the restore job go to the end, and restore the full 1Tera backup instead of the single file so that I can actually have the pdf file I needed to restore

2 - Then I made a few changes to hopefully find a solution to avoid having this issue in the future. The folder Ï back up is /media/eric/critical-data. Inside that folder I have a number of subfolders. The folder with all my important documents was called -- Mes documents -- and several folders below was the file I needed.
I changed -- Mes documents -- to mes-documents and did the same with similars folder, and I re-ran the backup job

3 - I tried to restore the same file I tried to restore from the beginning (which is actually the restored filed which has been newly backed-up), and this time restoring that single file worked fine.

Therefore my hypothesis is that the problem was due to the subfolder -- Mes documents --; duplicacy might not like something in that name.

Now I’ll just have to figure out whether my backups are twice the size and therefore cost twice as much on the cloud, or not …

This is very interesting, I wonder if the cause is the double-dashes, as that had a special meaning on the command line I believe.

By the way, it may’ve been possible to reduce the amount downloaded by copying your existing data to a temporary place and then restoring on top - any unmodified files would’ve been skipped. (Obviously it’s better that Duplicacy properly allowed individual files to be restored!)

Files containing accented letters can’t be individually restored due to a bug in the code that parsed the select file/folder. This is the same bug as in Duplicacy Web Restore Folder with Umlaut not working. I’ll fix it in the next version.

I don’t know why the -- Mes documents -- folder can’t be restored – it should be able to handle file/folder names with spaces. I’ll double check.

About -- Mes documents -- vs to mes-documents – this should not matter and may only cause a few new chunks to be uploaded. You can check the backup log right after this change.

Interesting enough, the accent does not seem to be the problem, as I can restore it now and the only change I am aware of is mes-documents instead of -- Mes documents --. cf screenshot. There are accents in paths and filename

2021-06-23_16-01

Thank you @Droolio and @gchen for the 2 tips about restoring skipping unmodified files, and about the change of path not changing much the backup

3 posts were split to a new topic: Web GUI restoring paths starting with @