Oh I’ve done all kinds of testing to makes sure this works for me. I did a disaster recovery scenario where I lost complete access from the backup source 4 states away. On my server, I simply added a new backup with the Syncthing folder (which is already local and 100% synchronized) as the destination for the backup, repaired the DB and I was back in business, ready to restore any and all versions. Bonus: The backup source has “Send Only” enabled, so when I re-enabled the synchronization, the original backup source is safe from changes on my end. I have also done at least a few actually-needed restores for the users on their end with no problems.
I had the same issue but am now running Duplicati as a service using VSS on one of the Win 10 home systems here and backing up directly to a SMB share sitting on a ‘Open Media Vault’ NAS.
The path I use is
I have noticed your funky path there. Maybe that is part of it for me.
I’ve been dealing with Windoze network shares for years, so I know that side is setup to work correctly. I can test from the PC fine. It is just that last little link across from Duplicati as a Service. Which user is it supposed to login as? I thought I had tried login as SYSTEM as noted by @ts678
@JonMikelV The FTP Server as destination method was comically simple to setup. Though I then proceeded to break it by trying FTPS and TLS login. @ts678 has saved me some testing time there by pointing out no FTPS in Duplicati. I did look at SFTP but the Bitvise is a “non-commercial use” application, so not an option for me.
I will be taking my test version of the FTP Server solution over to a client shortly. I’ll take some screenshots during setup for that one. As this is within the LAN then plain FTP should be fine. The FTP server will not have an external WAN port.
Both the “Backup to Windows LAN when running as a Service” and “Backup to FTP Server” are due to get mini HOWTOs written up by me. I want to feed back in what I have learnt.
I was claiming (possibly incorrectly) that the FTPS in Duplicati exists but isn’t listed specifically as FTPS name. Perhaps you can resume trying to get it to work, or possibly there’s more help on it in the forum or on GitHub.
FTPS (also known as FTPES, FTP-SSL, and FTP Secure) is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer (SSL, which is now prohibited by RFC7568) cryptographic protocols.
is from the link I cited, and Duplicati’s placement of encryption under FTP fits technically but is harder to spot.
Filezilla is, I think, quite good from a licensing view. Many of the fancy SFTP servers have license restrictions.
If you’re on a recent enough Windows 10, there is a beta version of OpenSSH-based client and server inside. This is a Windows port, but if you’re willing to run Windows Subsystem for Linux (WSL), more options open…
I am starting to wonder if much of my problems are down to the Visual Studio package not installing properly.
Just been on site with that client, in between other tasks I did another test. Working from a different PC, this time doing a big backup to FTP.
Win10 Pro (x86) PC, Installed Duplicati as a service, set “snapshot-policy = on”, left Thunderbird Mail open, kicked off a big backup…
And I found that Alpha.VSSx86.dll error popped up.
=> Could not load file or assembly ‘AlphaVSS.x86.dll’ or one of its dependencies. The specified module could not be found., Failed to process path: C:\Users\Martyn\AppData\Roaming\Thunderbird\Profiles\0j8qpsn9.default\parent.lock => The process cannot access the file ‘C:\Users\Martyn\AppData\Roaming\Thunderbird\Profiles\0j8qpsn9.default\parent.lock’ because it is being used by another process.
And from reading elsewhere this says I need to install the VisualStudio update. Which is odd, as it is already on here as I remember running it. Should I now reinstall Duplicati on this PC? Would the lack of the VS pack mean the installer failed? Or the service install may have failed?
On a separate test… LAN backup seems to want to work this time. Am using the IP v4 Address instead of the computer name. Which makes some sense as the Win10 PCs in the network mean more IP v6 running around the LAN.
\\192.168.1.203\stuff/martyn and giving it the username\password seemed to work this time. Or at least it passed the test. Just failed to backup due to that AlphaVSS.x86.dll again. Puzzling…
@ts678 the vagueness in your comments about FTPS implies you haven’t used it yourself. So I’ll be skipping that experiment for now as I have enough testing puzzles I am working through.
FileZilla is an OpenSource project. Brilliant FTP Client, and I have used the server a few times before.
Has been comically simple to setup a Server, add a user, tweak some security. Looks like a simple answer for LAN backups when other options fail. It is also handy as it is an “any OS” solution too.
I will be making a proper HOWTO Backup To FileZilla FTP Server in next few days. Find it so much easier to use than other FTP Servers I’ve previously configured. But then that is the beauty of open source collaborations - the best of the ideas get boiled into the file product without ID-10T users in Marketing getting in the way.
OKAY… here is Feedback from using Duplicati on a 32-bit Win10 PC
This PC is an older messier one. It auto-upgraded from Win7.
It is a 32-bit OS installation.
Last week I ran the Duplicati installer on here. Then ran the commands for converting to a service.
FEEDBACK NOTE ONE:
Please throttle back on some of the splurge of debugging info hitting the screen. So much went up on the screen as the service was starting up that I think I missed all the errors caused by not having the VisualStudio package installed.
With that debugging info it is too easy to miss real errors. The errors need to SCREAM OUT so attention is paid to them.
Subsequent tests this PC were failing the backup with the AlphaVSS.x86.dll error as noted in an above post.
I swapped back to a command prompt.
Note This caused a pop-up error message about not being able to stop duplicati service. So I manually stopped and removed the service
sc stop duplicati
sc delete duplicati
Still got the same pop-up error box. No other error text splurge to the command prompt though.
I then fully uninstalled Duplicati and rebooted.
Ran the VisualStudio update again. Rebooted. Ran the Duplicati installer. Installed as a service - no errors.
Ran my test backups again - and all is now happy!! No errors on the locked files.
Maybe find a better test for the lack of the VisualStudio update? Maybe catch the AlphaVSS.x86 error and tell the user to go install the VS package and reinstall everything properly?
Or maybe during the initial run of duplicati.windowsserver slam a message box up in the user’s face when the AlphaVSS.x86 error kicks in.
I think this could well be the heart of my issues.
Swapping Destination Test
Right - I am now going to be a right awkward sod to my little x86 test PC… I’m going to swap that Full Backup from an FTP target to a SMB target in the same folder.
So, if I understand this right, Duplicati should just handle this without a hiccup. And as I had just run the backup via FTP, swapping to SMB should mean nothing changes. I am expecting a speedy backup as nothing needs to be updated.
Hehe… I am cruel. (I’ll update this post soon with test result)
Edit: Clever little Duplicati. The initial backup was 50GB using FTP across the LAN. I then edited just the destination and swapped to SMB across the same LAN to the exact same folder. And Duplicati sped through the file check and was more than happy.
Two Backups in same folder
While testing I accidentally put two different backups into the same folder. I think this has caused damage. It certainly threw up some temporary confusion.
Am I right in thinking that backups need to be in separate folders?
Suggestion: Tell user when two different backups are pointing in the same place.
I had setup a “Full Backup” but had not run it.
I also setup a small “Test Backup” to the same folder, run it. 3 files were created.
I return later in the day and try and manually run “Full Backup” and get told about three files being in the folder and needing to run repair.
So I look at the test backup… oh yeah, three files from my earlier test. So I’ll delete that.
In attempting to clean up the test on this PC, I am removing my small test backup. And deleting the data. I get a CAPTCHA shown for that delete, but it is not centred on screen
This is Firefox x64 on Win10 Pro. Notice how I am having to guess if that is a 6. (Turned out to be wrong and I had to retry)
Maybe need to check the framing of that image?
So two points came up there:
1\ CAPTCHA not always visible.
2\ Two Duplicati backups should not share the same folder. Need a warning when setting up.
Yes unless the relatively obscure –prefix option is used so that Duplicati knows which files go with which jobs.
This has come up a few times, but seems to be stuck in the backlog. I wonder if anyone can edit the manual?
Regarding CAPTCHA, Captcha is unreadable #2965 found a font problem but also a that’s-how-it-was-made. Maybe someday a look at the generator could tell whether it’s framed badly by mistake, or if it’s intentional…
I did some testing and I have an idea for what might be giving you trouble. Not sure if you or others are aware, Windows will only allow access to a network resource using a single set of credentials, per user session. What I’m trying to say is when Duplicati is running as a service with it’s own user name, network access is “locked in” to the first successful network access of that resource. If you need to access a network resource with different credentials, you must restart the Duplicati service before any new credentials are attempted. Here is an example if you are interested:
Lets say you have security set up on \\computer\Folder1 where USER1 has access to read only and BACKUPUSER has access to both read and write. If Duplicati uses credentials to log in as USER1 for any purpose, such as testing access in the Destination selection page, then Duplicati will only be able to access all shares on \\computer as USER1. The inputs to Username and Passoword in the Backup Destination area are effectively ignored completely; You can put the wrong password in there and it will still report success. This will affect ALL shares on \\computer, including \\computer\folder2 and \\computer\completelyUnrelatedFolder. To fix this situation, you would restart the Duplicati service. Then, you should now be able to successfully test using the credentials for BACKUPUSER and Duplicati will now use BACKUPUSER for all access to \\computer.
This is not completely Duplicati’s fault, it is a limitation of Windows and how it handles network access. This is mainly an issue when using the GUI and installed as a service. Because the service’s user session never closes, neither do it’s network shares. You will run into even more problems if you have the service running as your own user account, since Duplicati will then be locked into the last credentials you used yourself to access network resources. Duplicati should have it’s own user account that is not used by anything else and when accessing network shares, it cannot change the credential used for accessing each host. You can use different credentials if you are accessing different hosts, such as \\computer1 and \\computer2 but multiple shares on the same host such as \\computer1\folder1 and \\computer1\folder2 must use the same credentials to access, even if you are accessing each one in different jobs.
To properly test access when setting up a job, enter a known-good UNC path (copy/paste from explorer window so you know its perfect). If you get a message claiming the folder does not exist, your access credentials are incorrect or that user does not have READ access to the folder. If you get Connection worked! then you know you have at least read access. To test write access, simply add a non-existing folder to the end of the path you already have and test again. You should get the folder does not exist prompt and this time push Yes to test your write access. If that works fine then take your test subfolder off of the path and you should be all set.
You do not need to mix your slashes, \\computer\folder1\subfolder1 works just fine. There is an interesting anomaly with this field though…after you save the job and go back in to edit the configuration, you will find that the destination path will now have a forward slash (/) on the end of it. This extra slash does not seem to affect anything and you can remove it if you are adjusting the path. It will be added again after you save.
Would Canceling a Network Connection help? If so, it’s in the code I linked to earlier, seemingly controlled by:
--force-smb-authentication (Boolean): Force authentication against remote share If this option is set, any existing authentication against the remote share is dropped before attempting to authenticate
This reminds me of the discussion in How to close SMB connection to remote share? where it seemed difficult sometimes to get around Windows’ expectations, including features like 15 minute idle timeouts, and also this:
The assumption in Windows is that a user will not try to re-authenticate with different credentials.
I found it hard to control (or even see) what Windows was up to, and such things make it seem unpredictable. “net use” and PowerShell (e.g. Get-SmbSession and Get-SmbConnection) would sometimes not even agree, and I would also have to Close-SmbSession from the server side, due to lack of client-side close (link above).
I got tired of poking at it, and hoped someone more expert would stop by (thanks @TPSMono). Do you have any opinion on whether Duplicati is on the right track, with use of the The WNetCancelConnection2 function?
The WNetCancelConnection2 function cancels an existing network connection. You can also call the function to remove remembered network connections that are not currently connected.
@ts678 I would have thought that the -prefix option should be default. I can see other people making the accidental assumption of uniquely named backups. We should always assume the user is an idiot and\or in a rush and can make mistakes.
When setting this up in a small office I have a single shared folder as destination. It was only my need to be tidy that made me create separate sub folders in there. I’ll now add this to my routine to always make unique folders for all my backups now.
Crashplan backups start by creating a fresh folder in the backup location and puts the backup into it. So this is going to catch other ex-CP users.
This also explains a few of the odd test results I have had where repairs have been needed because I piled too many backups into the same location.
Learning by mistakes
This makes sense and does fit. I also do recognise that limitation - but was not aware it affected apps as well as the desktop user. When doing this setup initially I was doing dozens of other tasks on the same machine so will have been active on the network. When concentrating on it yesterday I just was playing with backup, but this time I was using the IP Address to access the PC.
At all points I have had a unique username\password setup for just the backup. This account is on the target machine and only there for the file share. So when the Duplicati service goes to login to the backup destination it is not using desktop user credentials.
I’ll check the Credential Manager on the test PCs to see what has been stored.
MMmmmm… thinks more on this. So if my destination is only used for backup I can keep separate SMB user credentials. BUT if this destination machine is also used for other reasons across the LAN then I could have troubles. May swap back to FTP… food for thought there.
I’ve been using SMB since the old Windows for Workgroups v3.11 era. And it is a totally insane slapped together madmans random click and hope and wait for your Master Browsers to finish arguing the toss about who it winning today’s Election. Mixing Politics in to Engineering should have been a hint of the madness of unpredictability
Because of this I am usually in the habit of using IP Addresses of the destination. Gave up on Network Neighbourhood in XP days. Don’t know why I wasn’t doing that initially. I blame being confused with also having to fight an old network scanner and its love of SMB1…
I think FTP Server is going to be my simple headache free solution if this gets too weird.
ARGH - been caught by that missing VC++ Redist package error again
Warnings: [ Failed to create a snapshot: System.IO.FileNotFoundException: Could not load file or assembly 'AlphaVSS.x64.dll' or one of its dependencies. The specified module could not be found. File name: 'AlphaVSS.x64.dll'
This solution needs to be louder:
AlphaVSS needs the Visual C++ 2017 Redist package
This is an older Windows 7 x64 machine. I thought the installation was happy, but looks like I am getting VSS errors again. I am going to try installing the VC++ package and see if this AlphaVSS error disappears again. There certainly seems to be a pattern here. I am having to manually install the Redist Package on most installations to get the service to work.
Please update how the redistributables get installed on Windows. From my testing I don’t seem to see this ever getting installed correctly. (And yes, I am restarting the PC after installation of Duplicati)
What catches me out is that Duplicati happily runs as a service, lets you setup backups, but then odd splutters and fails occur. The message put into the logs is a little cryptic. I’d suggest that any AlphaVSS error triggers a louder pop-up \ message pointing to installation of the Redist Package.
(Now off to check this theory and today’s Win7 PC with this issue…)
Edit: to add to my own post… that is two Win7 Pro (x64) PCs that both suffered the same way. The VC++ 2017 redist was missing. Once I had installed that and rebooted then the backups complete without the Alpha error.
There is another oddity I am trying to make sense of. So checking some daft worded questions.
Once Duplicati is installed and running as a Service, can the non-service version get accidentally re-started?
I had a puzzling one today where a service install seems to have reverted to running the non-service version. This cause problems as that has now put an old backup into the same folder as the new (service based) backup and caused some chaos.
Though this Win7 (x86) PC is double chaotic as now it has thrown some kind of sulk and refusing to access a SMB folder it was happy with days earlier. Yet two Win10 PCs on the same network are happy as Larry.
The Win7 PC is a totally mad one so anything could be going on with it. I’m keeping an eye out for patterns. There must be Order in the Chaos.
Depends on whether anything was done to disable it after moving to the service, e.g. is it still on the Desktop? Although it’s rarely a useful configuration, it’s also possible to run several copies of Duplicati at the same time.
Migrating from User to Service install on Windows calls for moving enough files that it should prevent the non-service version from starting, however if files were copied, and old desktop shortcuts and automatic starts left alone, then the non-service version may remain fully functional and run whatever backup was configured in it.
If someone wants the Tray Icon, the How-To calls for adding --no-hosted-server to its shortcut on the Desktop.
Umm…by definition I think you might be wrong there.
Adding to my feedback as a Windows User. I get a feeling not as much testing happens for us in the Microsoft World…
I am trying to swap some 18.104.22.168 Beta’s to the latest 22.214.171.124 and having problems. This is an office with FOUR PCs setup to backup using a Windows Service. They backup to OneDrive (home version)
First PC: I open up the 127.0.0.1:8228 of my Windows Service installation. I see offer to download new version. So I do this. I then attempt to Activate…
Attempting to Activate the new install gives me “Activate failed: cannot activate update while task is running or scheduled”.
Trouble is I can’t stop the verifying. Looks like it has been jammed verifying for three days or more(!). It looks like current backups are jammed hard in “verifying backend data” and refusing to stop. The X doesn’t stop it. Pause will pause… but that doesn’t have any effect on my ability to stop.
On the first PC I solved this by rebooting and then Stopping the running service and manually downloading Duplicati from the web and installing on top.
Luckily I read the forum about “OneDrive v2” so edited current job, changed to OneDrive v2, got a new AuthID, saved those changes. Then did a Verify Files. All seems happy on that one now.
Next PC the service had crashed (?!?). So I restarted the Windows Service. Opened browser for the backup settings. Hit stop this time successfully. Used the Download and Activate in the program. Again activate issues. Used ABOUT to attempt to activate again. This button just seemed to do nothing. Was ignoring my clicks.
So I restarted the Windows Service. And that seemed to do the trick as I could then refresh the ABOUT page and now saw I was on version 126.96.36.199
Though something puzzling did occur. When trying to change this second PC the list box for the Backup Destination was stuck on the older one. OneDrive v2 being right at the bottom with odd settings. So I again used to force the cache to reload this page. That seemed to work as now I got the correct list of options and successfully changed OneDrive to v2.
Am hitting a third PC now… but of course, Sod’s Law decides to do big windows Updates on that one delaying me…
BIG plus points are the backup data seems good, and it is a quick job to verify those files. That is very helpful and gains lots of trust from me.
I have caught up the backup on the first two machines, and that all seems happy happy now. Nice.
It is the stopping and starting of the service on windows that is a bit odd to me. Think I may have to set a Task Schedule somewhere to kick a restart in case it has crashed. Or attempt to narrow down the actual issue there. Some of the PCs this is installed on are rarely restarted.