That is probably the easiest way.
Duplicati will (by default) reset the permissions when it starts up again.
Folks, I’m now with hands-on access to my old Duplicati server. I just did a sudo update&upgrade sequence on the new Pi4, so I’m sure the Pi is up-to-date (Trixie). I went to updates.duplicati.com (for some reason I can not connect to www.duplicati.com or duplicati.com) and downloaded this .deb file: duplicati-2.3.0.4_stable_2026-07-09-linux-x64-cli.deb.
Then I ran this command:
sudo apt install /mnt/usbdrive/duplicati-2.3.0.4_stable_2026-07-09-linux-x64-cli.deb
with this output message stream:
Note, selecting ‘duplicati:amd64’ instead of ‘/mnt/usbdrive/duplicati-2.3.0.4_stable_2026-07-09-linux-x64-cli.deb’
Solving dependencies… Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:Unsatisfied dependencies:
duplicati:amd64 : Depends: libssl3:amd64 but it is not installable or
libssl1.1:amd64 but it is not installable or
libssl3t64:amd64 but it is not installable
Recommends: libicu:amd64 but it is not installable or
libicu80:amd64 but it is not installable or
libicu79:amd64 but it is not installable or
libicu78:amd64 but it is not installable or
libicu77:amd64 but it is not installable or
libicu76:amd64 but it is not installable or
libicu75:amd64 but it is not installable or
libicu74:amd64 but it is not installable or
libicu73:amd64 but it is not installable or
libicu72:amd64 but it is not installable or
libicu71:amd64 but it is not installable or
libicu70:amd64 but it is not installable or
libicu69:amd64 but it is not installable or
libicu68:amd64 but it is not installable or
libicu67:amd64 but it is not installable
Error: Unable to correct problems, you have held broken packages.
Error: The following information from --solver 3.0 may provide additional context:
Unable to satisfy dependencies. Reached two conflicting decisions:
- duplicati:amd64=2.3.0.4 is selected for install
- duplicati:amd64 Depends libssl3:amd64 | libssl1.1:amd64 | libssl3t64:amd64
but none of the choices are installable:
[no choices]
OK, it failed/ This message confuses me “Note, selecting ‘duplicati:amd64’ instead of '/mnt/usbdrive/duplicati-2.3.0.4_stable_2026-07-09-linux-x64-cli.deb’”
Anyway, where did I go wrong? Thanks…RDK
OK, my BAD 
After I looked more at the apt command and re-thought my comment about the P4 being “up-to-date”, it dawned on me that the Pi4 is ARM technology.
So YES,
sudo apt install /mnt/usbdrive/duplicati-2.3.0.4_stable_2026-07-09-linux-arm64-cli.deb
Note, selecting ‘duplicati’ instead of ‘/mnt/usbdrive/duplicati-2.3.0.4_stable_2026-07-09-linux-arm64-cli.deb’
The following packages were automatically installed and are no longer required:
linux-headers-6.12.75+rpt-common-rpi linux-image-6.12.75+rpt-rpi-2712 python3-asgiref python3-itsdangerous python3-werkzeug
linux-headers-6.12.75+rpt-rpi-2712 linux-image-6.12.75+rpt-rpi-v8 python3-dotenv python3-pyasyncore
linux-headers-6.12.75+rpt-rpi-v8 linux-kbuild-6.12.75+rpt python3-flask python3-pyinotify
Use ‘sudo apt autoremove’ to remove them.Installing:
duplicatiSummary:
Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 0
Download size: 0 B / 77.7 MB
Space needed: 0 B / 20.1 GB availableGet:1 /mnt/usbdrive/duplicati-2.3.0.4_stable_2026-07-09-linux-arm64-cli.deb duplicati arm64 2.3.0.4 [77.7 MB]
Selecting previously unselected package duplicati.
(Reading database … 166850 files and directories currently installed.)
Preparing to unpack …/duplicati-2.3.0.4_stable_2026-07-09-linux-arm64-cli.deb …
Unpacking duplicati (2.3.0.4) …
Setting up duplicati (2.3.0.4) …
did work!!! I’m still a bit confused about the note
“selecting ‘duplicati’ instead of ‘/mnt/usbdrive/duplicati-2.3.0.4_stable_2026-07-09-linux-arm64-cli.deb’”
, but now I can go to the next steps for moving the files, etc from the old Duplicati server to the new one…RDK
That is because you are using apt. With apt it will open the package file and find out that the package name is actually duplicati.
In case the file was called something like noname.deb you will now see duplicati in apt instead of noname.
I think I’m almost to the end and thanks again to all for your assistance.
I have a few questions about the service setup, the files in /root/.config/Duplicati and back-up files. Note, all of this is done when the service is STOP-ed on both servers.
-
For the service setup, it was already created in /usr/lib/systemd/system/duplicati.service. Is this the correct location? I added
DAEMON_OPTS=“–server-datafolder=/root/.config/Duplicati”
to the /etc/default/duplicati file.
This seems to be the way to set the location for the SQLITE file? Is once enough or let it run on each startup? -
For the folder and files in /root/.config/Duplicati:
control_dir_v2 Duplicati-server.sqlite installation.txt machineid.txt
I assume the only one to be copied over from the old server is Duplicati-server.sqlite? -
On the old server USB drive I have a folder called Backups_Dupli which has these files and folders:
-rw-rw-rw- 1 root root 37837 Oct 28 2022 duplicati-20221029T010000Z.dlist.zip.aes
-rw-rw-rw- 1 root root 38141 Oct 29 2022 duplicati-20221030T010000Z.dlist.zip.aes
-rw-rw-rw- 1 root root 207245 Oct 28 2022 duplicati-b1dab7bf0079c4a3abce483d3b5ffd39d.dblock.zip.aes
-rw-rw-rw- 1 root root 67997 Oct 29 2022 duplicati-bc5dbe25a80de4e3d992769945c620e97.dblock.zip.aes
-rw-rw-rw- 1 root root 5037 Oct 28 2022 duplicati-i11bcdba76e284e8da37f94827c2f958b.dindex.zip.aes
-rw-rw-rw- 1 root root 2477 Oct 29 2022 duplicati-ic99f41128f084d8eabdd8a2f91f20d29.dindex.zip.aes
drwxrwxrwx 2 root root 131072 Jul 7 10:05 email
drwxrwxrwx 2 root root 131072 Feb 15 19:00 PDNS
drwxrwxrwx 2 root root 131072 May 10 08:00 RPS
drwxrwxrwx 2 root root 131072 Jul 7 10:04 vmailI assume that only the four folders:
email, PDNS, RPS and vmail
need to be copied to the new server?
Again many thanks for you help on this project.
Waiting on your input before firing up the new server..RDK
Is it in some meaningless location, or plausible one for a Duplicati backup?
Direct restore from backup files might show content, if you know password.
Whatever that is, it looks like it’s from 2022. Maybe that will give you clues?
I don’t think Duplicati has anything to do with these. Any idea what they are?
Guessing from Google searches didn’t help much, but maybe email or DNS?
If you look at contents of folders, that will help guess more than folder name.
What else is on the system? I don’t know why it’d be next to old backup files.
Not likely already created before package install, but likely after, and like mine.
Are there Duplicati directions saying you should be working/checking location?
Ultimately, if the wrong location sneaks in due to bug, service will probably fail.
Why? Aren’t you running Duplicati as root? That looks like the default spot.
The default location when running Duplicati on Linux is
~/.config/Duplicati. For most distros, running Duplicati as a service means running it as the root users, resulting in/root/.config/Duplicati.
If you wanted a truly custom (not default) location, I think it needs each startup.
Otherwise how will it know where things are? But I’m questioning if you need it.
That’s the server database containing job configurations, etc. You want that.
I believe the .txt files are less important unless you use Duplicati Console.
The text files are readable. I see these notes in mine:
This file is used to assign a unique ID to the machine, and used to identify the machine in reports.
The first line in the file is used as an ID, but can be changed with --machine-id for a single or multiple runs.
This file is used to track the number of unique installs.
The first line in the file is used as an ID, which is sent to the server when checking for updates.
If the first line is blank, this installation will not be part of the usage statistics.
To be clearer, there are no such strings in Duplicati source code that I can find.
Regarding your two-days-in-2022 possible backup, you can check the location.
If none of your backup jobs use it, maybe it was a test you were doing in 2022?
Is it even plausible that an active backup has picked up no changes since then?
When you look inside the four mystery folders, dates will also show if it’s active.
The email/vmail ones are recent enough to worry me, but I doubt it’s Duplicati…
If you have Duplicati run some script before or after, there might be some tie-in.
Basically you’ll probably need to figure out the context and content of the folder.
@ts678 @kenkendk Thanks for the reply, sorry if my summary/questions were not clear. After reading your comments, I think the below should be clearer?
-
For the service setup,…
After installing Duplicati the datafolder was NOT in the /root/.config folder. So I added
DAEMON_OPTS=“–server-datafolder=/root/.config/Duplicati”
to the service file (/etc/default/duplicati), to set the location for the SQLITE file. Is once enough or let it run on each startup? -
The folder and files in /root/.config/Duplicati are control_dir_v2, Duplicati-server.sqlite, installation.txt and machineid.txt. Except for the Duplicati-server.sqlite file, I think the rest are installation specific. Thus I will only copy Duplicati-server.sqlite from the old server. Correct?
-
On the old server USB drive, the folder called Backups_Dupli is where I configured Duplicati to store the backup files. I have configured four Duplicati backups: email, PDNS, RPS and vmail so I assume the last set of backups for each are in that folder on the old server. I will only copy those folders to the new server. Correct?
Again thanks for your time and patience…RDK
Can you give an indication of where it was? Place is user-dependent though.
My service running as root is behaving exactly as it’s documented to behave.
It’s not supposed to be in /root/.config but in /root/.config/Duplicati
assuming you run as root (are you or not?). If not, please read the docs on it.
As stated, a non-default location must be passed to Duplicati on each startup.
That doesn’t mean you edit the file each time, but its option goes in again per:
# Additional options that are passed to the Daemon.
This is true of any options. They are just command-line switches on its launch.
You can see them with right ps command, and find more with --help option.
That’s correct, however it’s probably also correct to copy the other files as well.
As mentioned, Duplicati Console (if you use that) might benefit from machineid.
There also seems to be a backup (using the 2022 files) in the parent folder.
I can’t tell you what’s in the subfolders. Check their file dates for plausibility.
It’s not only the last set of backups. All versions of a backup share its folder.
The dlist files put the backup date in filename, however the date is UTC.
If these subfolders are active backup Destination folders, you’d copy them.
Per your description they should be, but I can’t see their contents. You can.
Please sanity check that things look right. Also consider remote destination
for protection against drive failure, if you currently backup the drive to itself.
EDIT 1:
Some duplicati-server options are remembered in the server database,
but a custom server database path has to be passed in on each server start.