I was testing one of my back-ups today and it turns out I cannot see UNC paths that are in the archive. Instead, I see only a folder icon that has no description and no subfolders.
It is interesting that an older version from about two months ago, displays the UNC path normally, however, there was only one UNC at the time. In the latest version I have multiple UNC paths.
Any ideas as to what the problem may be and how to work around it or fix it?
Duplicati is running on Windows Server 2012 R2. The back-end is a B2 bucket with no lifecycle (i.e. keep latest version only) and no caps.
Restore GUI not working correct with UNC source leading to open issue
When restoring a backup with multiple server UNC paths, file browser cannot be navigated until a search is performed. #3722 which s a pretty ugly work around (but because you asked for a work around it may help)
If your problem is similar but different, it might be helpful if you could add your experience with it to the Issue.
Yes, sounds like it - I cannot navigate the UNC paths, but if I search, for a file, I get the first two backslashes as separate parent folders and then I get the search hits somewhere below that.
I did some additional testing and it turns out this issue only exists if the UNC paths are to multiple servers. I start with multiple sources on the same server and there are no issues. I add sources from another host and the the problem surfaces. I remove source locations so that only a single remote host is on the list - it gets back to normal, even though previous back-ups have this issue.
That matches well with the issue (which apparently is in the queue waiting for the right developer to look).
- Create backup with multiple server UNC paths eg. \SERVER1\Share and \SERVER2\Share
The workaround worked great on the microscopic test back-up that I had (a few files from random locations from my network). It does not seem to be suitable for the real deal, though!
My real back-up has a source size of 400G, 33 versions and who knows how many hundreds of thousands of files. When I try the search workaround it initially seems to take a long time and eventually crashes the browser. I tried both searching for a dot and for an actual file name and neither was successful.
I take that back. Sort of… I just tried again and it did work… I guess it may be a bit hit-and-miss due to external unrelated factors (i.e. system load, browser load, network congestion etc.).
After hours of testing, 126.96.36.199 canary is working fine for me. I suppose I could test 188.8.131.52 beta, or even better (if you’re willing) you could test v184.108.40.206-220.127.116.11_experimental_2019-06-28, which is sort of the release preview for next truly updated beta. v18.104.22.168-22.214.171.124_beta_2019-07-14 is 126.96.36.199 plus warning.
One issue is that downgrading to 188.8.131.52 would be VERY difficult due to database changes. A test system (if you have one) is a better idea. It’s also possible to install two Duplicati on one system, if you’d like to… Another concern with experimental is some recent talk of putting big changes in. May or may not happen.
Would using drive letters be a work around? Assuming the data from your files is actually in your backup (though it’s hard to browse to), Duplicati should notice that for drive-letter paths and not upload file blocks.
The find command might be a way to see what’s in the backup, and the restore command to test restore.
It seems to be working fine for me on 184.108.40.206:
Tested with IE, Firefox, and Chrome…
220.127.116.11 shows the issue when I run the import of the export of the 18.104.22.168 backup. Suspect fix is below:
Backup cant be restored due to path handling #3597
fix for unc paths in prefixes #3599
- Fixed a case where listing files backed up from a UNC path are not shown, thanks @mnaiman
I split my back back-up job into a few smaller ones (one per server) as a workaround. Single UNC path seems to be working fine and I noticed that smaller back-up jobs work more reliably than the bigger ones. Case in point: I back-up my work laptop (10-20 G of data) and never had any issues. I back-up my entire home environment (a few different jobs with 200-300 G each) and had a ton of issues.
We’ll see how that works.