Backing up Multiple UNC Directories

Bug
#1

I read the other issue regarding backing up multiple directories, and symlinks seem to be the best way I can perform the backup that I require (multiple shares on multiple servers all linked through a few dfs shares - I’d like to use these dfs shares as the snapshot id’s.

So, I’ve tried setting up symlinks that point to remote unc paths, ie

mklink /d c:\backuproot\fileservershare \\fileserver\share

if I CAT then I can see the config files, and within I see:

"link": "\\\\fileserver\share",
"path" "fileservershare"

but there are no files backed up.

Can you allow symlinks with unc paths to backup, or should I rethink my plan?

#2

I ran into the same exact problem and am trying to find a solution. It would appear as though junctions (mklink /j) are followed correctly, but you cannot junction a remote server. Symbolic links (mklink /d) do not appear to be followed, which puts a huge stop on my plans right now until I can find a workaround.

#3

A few days ago Gilbert commented that the name of the symbolic link is significant. Maybe that’s what’s preventing it from working for you.

Also I recall reading somewhere else that the symbolic link must be in the root directory of the repository if you want it to be followed. Symbolic links farther down will not be followed.

#4

I did read that post. In both of our cases, this isn’t what is happening. Symbolic links work just fine. I have tried this with a few symbolic links and all work as expected ‘so long as’ the symbolic link is a junction. If the symbolic link is not a junction (as in the case when you make symbolic links against remote paths), then it will not follow the symbolic link for the remote path.

Net of it, it follows symbolic links so long as they are local to the machine. If they are remote to the machine, then it will not follow them.

#5

Supporting remote symbolic links can be very convenient. I’ll give it a try.

#6

@Danny as @tezgno said it’s not the naming issue, but thanks anyway.

@gchen That’s excellent news. I’ve written a piece of code (legacy from before powershell was useful) that lists dfs and currently robocopy’s files to one location - instead of robocopy I’ll probably just have it ensure that the symbolic links are kept up to date and then run duplicacy on it.

#7

The change that fixed the symlink issue on Windows seems to make UNC paths work too.

You’ll need to build from the source though; let me know if you need a new binary.

#8

Thanks, got it built, but I can’t test until later this week.