Due to the threat of ransomware, I am concerned that backup files may also be encrypted and locked. Therefore, I want to back up to a volume without a drive letter.
Can this software back up to a volume without a drive letter?"
Let me know if you need further adjustments!
Hoping the malware doesn’t know how to easily see the volume?
It’s either code per docs, or run a single command to get those…
Either way, I haven’t had any luck trying a volume GUID backup.
This is interesting, as I think people can backup to a UNC path…
Official help text talks about these forms, and I’ve tested several:
C:\Program Files\Duplicati 2>Duplicati.CommandLine help file
Duplicati can use the local file system to store backups. The following target URL formats can be used:
file://hostname/folder%20for%20backup
file://\\server\folder%20for%20backup (UNC path)
"C:\folder for backup"
file://c:\folder%20for%20backup (Windows)
file:///usr/pub/folder%20for%20backup (Linux)
I’m reporting latest Beta status. Can’t say if devs wish to add this.
Argument that malware will get fooled sounds a little weak to me.
Basically, if Duplicati can get there, malware can too (assuming it knows simple queries).
You might be able to isolate better with Hyper-V if your Windows has it (Home does not).
Home might be able to isolate with WSL, but off-system storage is probably a better idea.
Even people on off-system storage know malware may get in by reading Duplicati config.
Sometimes this leads them to try to create some immutability scheme. New Duplicati has
The server database where the field-level encryption is new, suggested, and confusing…
Local providers covers some new ways to use OS facilities to save secrets more securely.
It’s still not bulletproof against all attacks, but all of this is kind of how big a hurdle to build.
EDIT:
To clarify the VM idea, you put some authenticated network-based server in a different VM.
Supposedly, Hyper-V can provide isolation even if both VMs are using the same hardware.
Duplicati has to authenticate for access, and you take steps that the malware can’t as well.
Thank you for your response.
I will look into the methods you mentioned.
We are currently working on a CIFS Backend currently in PR review and tests and it should be available soon on a canary release.
With the new backend you won’t need the share mounted/mapped, instead you will configure the share credentials and Duplicati will connect directly to it without.
Don’t Windows (but not other) users already have this ability with Username and Password?
Regardless, good idea to possibly avoid the issue of having to install something new on VM:
Indeed @ts678, when using Duplicati on Windows you can enter the source path as \server\share and then the credentials, it is for other operating systems the backend will be useful.
As mentioned, this works only for Windows.
But even the Windows implementation of shared folders is problematic for some uses.
The Windows Share will be authenticated in the context of the user and stay that way.
If Duplicati has access to the share, any process running in the user context also has (authenticated) access to the share.
If you need access to the share with two different credential sets (e.g. one is readonly, the other read-write), this can only be done in Windows by disconnecting the share and re-connecting it.
In other words: if you opened the share in read-only for some reason, you will get errors when you try to back up from Duplicati, even though you have correct credentials. Only workaround is to use --force-smb-authentication=true, which will drop the connection and authenticate again with the credentials, but after this, the share is mounted with the read-write credentials.
The CIFS backend on Windows gives the opportunity to de-couple Duplicati from the regular Windows Shares, so you do not end up granting access you did not intend. But you loose the option for integrated authentication.
Thanks for all the additional notes. SMB shares have been troublesome to set up before.
I vaguely recall trouble (maybe process context?) setting up SMB from Windows service.
Yes, I forgot about that. It is also problematic to get access to a Windows Share from a service as it does not run in the context of a user, so you cannot go into the context and authenticate in a simple way.
The CIFS backend also provides a way to authenticate within a Windows Service.
