Issue restoring files from remote location where backups are replicated to

I’m new to duplicati and I’ve decided to try and use it for a specific client.
The scenario is as follows.

I have a client premises with about 9 computers.
Currently I have setup duplicati to run during the course of the day usually about 30 minutes apart starting at 8:00AM and last scheduled backup probably running at around 14:00
Initially I wanted to just use Syncback to make a 1 to 1 copy of all the following three folders to their local server.
Desktop, Documents and downloads.
The client is still using pop email accounts. So I’ve made sure everyone’s pst file is under outlook file subfolder of Documents.
However Syncback copies the entire pst file everyday and since they are mostly using wifi this slow down their network too much.
So I Looked for alternative rsync style solution that backs up changed blocks only.
Duplicati came into consideration.
So I’ve implemented everyone machines to do a daily backup to their local server.
All machines backups are setup similarly.
No encryption enabled.
Network path with credentials setup as backup destination (No advanced options selected here)
Desktop, Documents, Download folder selected of each user.
Backup retention set to “smart backup retention”
under advanced options I’ve enabled to switches.
USN-Policy (set to on)
Snapshot-Policy (Set to on)
These switches just allow Volume shadow copy to work properly while outlook is open.
And that’s it. Each machine sends backups to their repectively named user on the local server at the client premises.
Now from here, i’m using Syncrify client to make a 1-1 copy at midnight every night to my server at my own premises every day.
I’m using Syncrify due to the fact I’m already using it for several other clients and it’s reporting tools are great.

Running Duplicati form the clients local server I’m able to select and restore from any of the respective user’s folder any files. Great.

I go to restore, select a local path, type in the exact path, leave out credentials as encryption was disabled during backup creation process.
I select “test connection” and I’m immediately greeted by an error message stating…
Just out of curiosity if I click on “create it now”
I’m greeted with a path that doesn’t even match.

I’m pretty sure you guys could give me some real advise as to what is required to fix this issue and I truly appreciate any assistance.

Also out of curiosity I also tried by clicking on next, Then clicking connect so it can open the backups and give me restore options, but it shows the following screen,
Followed by

Why is it trying to locate the backups from an incorrect path that I didn’t select?
I’ve also tried manually typing the restore path but it made no difference.
My server is a local barebone non-vm server. Nothing special.
Any advise? Thanks to everyone that could assist me with this.

Now I am pretty sure there are better ways to setup the replication from their local server to my local server over the internet. I’m pretty sure if I can receive a few tips I’ll be able to get it running as well.
I just like the kind of reporting I receive from Syncrify and since I’m already using it for other users I’m trying to stick to one solution for “cloud backups” where possible.

Apologies it is all Windows environments. No Linux here yet except I guess Adguard running as a hyper-v VM

You have lost me here. Am I to understand that you want to restore files from the replicated backup files on your own network ? If yes, you should import the configuration json file (that you exported for each client computer right ?), then adjust the directories accordingly.
Say if your users are backing up their c:\users\myuser\outlook to a j:\users\myuser\backedupfiles, and the replicated files are on your own system at z:\customer1\myuser\backup, you should change the target directory to z:\customer1\myuser\backup before even attempting to click on test connection.

Having two Duplicati and one backup is not a good use case. A backup needs a local database which must exactly match the destination. A backup will change its local DB, but not the other Duplicati DB.

Any details? The fact that you got a Test connection button suggests this isn’t a regular restore, as a client does at their site. This means it will take some time recreating a limited database for your restore, except you don’t have the J: path. Please describe J:. Is it already mounted? Does it need credentials? Does whatever user Duplicati is running as (which may be SYSTEM if a Windows Service) get access?

This is the case.
The client only has two drives in their local server. C: for the OS and few programs.
And D: which is the drive dedicated to just keeping all 9 of the local machines backups.

On my server I have many drives.
However I’ve pointed the restore location to the exact local location on my own server interface to the j: where the backup folders are located.

I’ve just straight forward installed the latest version of duplicati on both their local server as well as my local server.
Syncrify sends a complete copy of the backups folders in a 1:1 style to my server.
Since I was able to run restore from their local server and the restore process immediately worked. I assumed that running Duplicati on my server and pointing to the backup files should be able to run restore in exactly the same way.
But this does not seem to be the case.
J: is just a straightforward mounted ntfs disk with full access rights for the user I am logged in with. No credentials required.

I do change the target directory to the new path. But it doesn’t work.
However thank you for mentioning the “Configuration json file”.
Do I need to export it somewhere from each users workstation? Or is it something I can just export from their local backup server? Do I then need to copy it to a location on my own personal server, and edit it with the correct new path?

I do apologize I’m quite new to delta files system as well as Duplicati. But I appreciate all the help.
When I understand the system better I think I might enjoy it. I still must learn myself to program the mail reporting system as well as how to make it run repair’s automatically instead of me having to run repair manually. The client originally had a 4TB drive that started failing during backups. Stuff got corrupted.
Eventually I replaced the whole drive and just did clean backups.

As Duplicati is accessed with your web browser, the user the browser uses doesn’t matter.
What user is Duplicati running as? You can see this in About → System info as UserName
This isn’t always the user you are logged in with, as maybe you set up Duplicati as service.

What does StartedBy on that page say? If Duplicati is a service, then it has its own drives.
Services and Redirected Drives (Microsoft) may apply, but did you set Duplicati as service?
You have to use Duplicati.WindowsService.exe so it’s a manual action, but did you do that?

There are numerous ways to restore. Is the above what you used? It’s not what clients use.
Restoring files from a backup is the normal faster path clients would use. Your slow path is:
Restoring files if your Duplicati installation is lost because you don’t see clients’ databases.

When I hear “select”, I think of GUI action, e.g. in tree above, you navigate and finally select.
In your tree, is J: present with folders under it? Was it not, so you did Manually type path?

It is running as admin, the user I am logged in as. I have not run “Duplicati.WindowsService.exe”
I’ve just launched duplicati from the desktop icon created after install finished.

On the “backup location” page, I tried both ways, using the GUI, as well as clicking on “manually type path” Then I have used file explorer to head to the exact location of the backup I would like to restore.
Once there I copy the full path from the address bar and paste it in the “folder path” location.
No credentials are required for this user to access this location.
On the next page it requests the encryption passphrase. Since I disabled encryption and no passphrase is required I click on next. What follows afterwards is the following screen for like 30 seconds or so…

Afterwards the following window pops-up, as though it is looking in a completely different location from where I specified. Not even the correct drive letter.


When you install a Duplicati instance on a computer, you always export the job(s) configuration(s) and save them in a secure place (especially secure if you included the passwords of course - if you save the passwords separately - that’s I do - the job definition itself without password can be simply stored on a public share on the server or whatever could be convenient).
Then if a computer crashes, you install again Duplicati on the newly imaged workstation and import the jobs, then recreate the database(s) from the backend and restore the data.

If you want to test a replica of the data on another computer, you install Duplicati on this computer, import the appropriate job configuration, recreate the database and test the restore (in this case it makes sense to always pick a new path). You have to adjust the backend parameters if the paths don’t match, before recreating the database and test restoring. In your case of a local server, it’s the network path, and you have to ensure that access rights are appropriate.

Note that if you point at the same original data, you have to be very careful to not trigger any access to the backend (such as a backup obviously) since Duplicati is NOT able to share a backup like that. That’s not what you are trying to do in this case but I think it’s important to stress that anyway. In your case if you trigger a backup or let it happen automatically it will wreck the replica but that’s not a problem that can’t be solved easily (just wait for next replication).

Please tell us what you found in J: Did you find and select the folder, then Test connection failed?

This is the kind of path that can happen if you type in a relative path – except you didn’t. Might still be relevant because maybe in rejecting J:, for whatever reason, it decided that it’s not an absolute path.

Obscuring names was probably necessary but does get in the way. The Duplicati 2 folder is probably Duplicati current directory, then it added the rest, starting with something ending in za, so comparing screenshot with original post, it looks (but it’s hard to see) like it lost the J:\ and first level folder below.

FWIW I can’t reproduce this sort of behavior with my system where J:\ isn’t present. Still suspect J:…
Is that an SMB share? How locked up are the shares? Could you get there with a UNC path instead?
You could also carefully (don’t save, don’t run) edit a new backup and see if Source screen can show destination files. The direct restore tree seems to only allow expanding folder if it has a subfolder in it.

J: is a standard disk. It’s not a SMB share. The folder path doesn’t require any network sharing on my own premises. It’s a disk located inside my standard windows 10 pro Machine. I’ve only blurred details relevant to the client or me. I just use rdp to log into the box and I’m running Duplicati straight on the Box.
Syncrify does send a copy from the clients server to my server.
I apologize if my terminology isn’t always clear.

I guess what I can try and do is just copy the backup folder and just make a copy on a diferent disk with a uhmmm… what would be the right terminology. folder structure with less characters? Maybe there is some kind of incompatibility issue with the folder structure naming schemes created by Syncrify?

Sounds like a good test, although I thought Windows 260 character MAX_PATH got dodged already. Running out of ideas, so it’s down to trying different things to try to work out why it isn’t working now.

It worked! I simply copied the folder to a different folder with less characters and now I can restore from the backup. I’ll try and see if I can make Syncrify shorten the folder path length somehow. to see if that helps.

This is kind of weird. Does it get the latest Windows updates, including .NET Framework?
If you look at About → Changelog and search for long you’ll see the history of work there.

Switched to the new built-in .Net support for long paths, thanks @dferreyra

is one of the major moves, although there was more later and more earlier too. Big history.
Maybe you found a case that got missed somehow? If so, you can file a GitHub issue on it.
You can also try some other tests to see if long paths get handled better in other use areas.
Windows also has some bizarre character sensitivities, so it might not just be path length…

That’s what we want to hear, and I guess you’re already on your way to some more testing…

I looked at the amount of characters and it doesn’t appear close to the 256 character limit. So I am really unsure as to what the cause of this problem is.

One somewhat simpler way to cut it down is to Duplicati.CommandLine.BackendTool.exe list which is usually what a Test connection does. You can adapt target URL for it from an Export As Command-line or start from scratch. Test a bad one and see if you can change it to one that works. What did that?