Are you trying to get a backup as a safety precaution, or move it for some reason for running a Duplicati?
For the backup, it sounds like maybe you want a command line tool that doesn’t stop on a locked file, e.g.
xcopy with /c to ignore errors (somewhat risky because there might be other errors, but the whole idea of backup poses risks, e.g. if you backup a job database while it’s being changed, it’s immediately obsolete)
lock_v2 comes and goes. It’s normally gone when Duplicati stops, and has no settings calling for backup. This lock is only so Duplicati, when started, can tell whether a Duplicati is already using that server folder.
I use realtime sync cloud software yandex disk (like dropbox), and i want to backup (sync) to cloud all *.sqlite to speed up recovery time in case of hard disk failure.
Yandex disk cant sync this lock_v2 and stuck. I cant ignore this file (no such settings there). In my opinion its the best idea to put all server databases in 1 folder and start sycn this folder with cloud. But now i didn`t find way how to make it.
For example i made %LocalAppData%\Duplicati\DB folder. How to put there all *.sqlite without locked lock_v2?
If somehow Yandex has a VSS snapshot option, you could try that. If not, some people use Duplicati to backup its own databases as a secondary job after the main backup, using a –snapshot-policy setting such as on. Avoiding the in-use database problem is easy if the backup is just the primary job database (find DB’s path) however backing up the whole folder at one go is trickier (unless you use the snapshot) because some file is typically in use during backup.
Also beware that Duplicati-server.sqlite has passwords and other credentials, so trust where you put it, and consider encrypting it (e.g. Duplicati backup) instead of just making a clear-text copy to the remote location.
By default everything is there, per --server-datafolder, however if you want you can probably use --dbpath for an individual job database to move it elsewhere, perhaps even to its own folder. I’m not terribly familar with the Database UI buttons, but you could probably also move where the job database is stored like this:
If you want to make changes to the location where the local database is stored, you can use the Reset, Save, Save and repair and Move existing database buttons.
EDIT: Quote was from the manual at the earlier link about DB’s path). Doing the same trick for Duplicati-server.sqlite (the one with the other security cautions) will be harder, however this file doesn’t change as often as the per-job database, is small, and has no Recreate need or ability. Maybe you can just manually copy it somewhere occasionally, e.g. after changing settings. Treat as like a set of job exports plus more.
I’m glad you found a solution you like. To clarify, is this using one symlink (made by mklink) per .sqlite file (one of which is Duplicati-server.sqlite, and the rest are per-job databases), with all links residing in folder to sync? Provideded your sync programs syncs the link targets (sounds like Yandex does), that’s one way to get these all into one folder. Even after looking at the code, it looks like the server things are in --server-datafolder so the Duplicati-server.sqlite looks pretty firmly located near control_dir_v2. Job databases are more easily moved…