Editing Backup-Jobs via CLI?

I need your help:
I have set up Duplicati via Docker as a backup solution for my NAS. Now, I want to solve the following issues:
Through CLI access:

  1. Listing the backup jobs
  2. Editing the backup jobs

Is something like this possible?
I hope you can help me; somehow, I’m stuck…
Which commands do I need to use? /app/duplicati/duplicati-cli …?

Best regards,
Kuhni

Welcome to the forum @kuhnikuehnast

What version?

Whose image? I wonder if you have the LinuxServer one. It’s a bit different (might not matter).

If you are on a 2.1 version of Duplicati, there is a new tool to replace third-party duplicati-client.
ServerUtil introduces it. Both of these are CLI tools that network into the API also used by GUI.

C:\Duplicati\duplicati-2.1.0.4_stable_2025-01-31-win-x64-gui>Duplicati.CommandLine.ServerUtil --help
Description:
  Server CLI tool for Duplicati

Usage:
  Duplicati.CommandLine.ServerUtil [command] [options]

Options:
  --password <password>                                The password to use for connecting to the server []
  --hosturl <hosturl>                                  The host URL to use [default: http://localhost:8200/]
  --server-datafolder <server-datafolder>              The server datafolder to use for locating the database []
  --settings-file <settings-file>                      The settings file to use []
  --insecure                                           Accepts any TLS/SSL certificate (dangerous) [default: False]
  --settings-encryption-key <settings-encryption-key>  The encryption key to use for the settings file. Can also be supplied with environment variable SETTINGS_ENCRYPTION_KEY []
  --secret-provider <secret-provider>                  The secret provider to use for reading secrets []
  --secret-provider-cache <InMemory|None|Persistent>   The secret provider cache to use for reading secrets [default: None]
  --secret-provider-pattern <secret-provider-pattern>  The pattern to use for the secret provider [default: $]
  --host-cert <host-cert>                              The SHA1 hash of the host certificate to accept. Use * for any certificate, same as --insecure (dangerous) []
  --version                                            Show version information
  -?, -h, --help                                       Show help and usage information

Commands:
  pause <duration>                Pauses the server []
  resume                          Resumes the server
  list-backups                    List all backups
  run <backup>                    Runs a backup
  login                           Logs in to the server
  change-password <new-password>  Changes the server password
  logout                          Logs out of the server
  import <file> <passphrase>      Import a backup configuration
  export <backups>                Export a backup configuration
  health                          Checks the server health endpoint
  issue-forever-token             Issues a long-lived access token
  status                          Gets the server status

Export and import might be one option. There is not an update yet, but it has been requested.

There are two other options mentioned there, using preload settings or using run-script-before.

oh, I have to add:
Duplicati is running on my NAS.
So it backs up the NAS-

I use the container linuxserver/duplicati

If I now open a terminal instance - how do I use these commands? :thinking: sorry, newbie- questions :smiley:

So you might have latest Beta 2.1.0.3, but About screen will confirm.
I assume you are already in, having set up the GUI password to allow it.
This is needed for ServerUtil, but first, which approach sounds the best?

You have two that supply overrides via either a script or a config file, and
one where you export a file, edit the undocumented format, and import it.

Or maybe nothing does what you want. What editing do you intend to do,
and why from CLI, and from which CLI, right at the NAS or some remote?

I have the beta version.
Access via the web interface also works. My goal is to automatically create a new backup using a cron job and to set the automatic backups for existing backups to manual.

Command Line Interface CLI might come into play then. Changes are just CLI option changes.

If you want the CLI job to match the GUI job, then, run Export As Command-line in the GUI.

This form of CLI runs independently, so don’t try running things from the GUI during a cron job.

I’m hearing nothing on which CLI this is, or what sort of editing is in mind, but GUI editing takes another Export As Command-line if cron version needs to stay totally identical (but it might not).

You can also have cron run ServerUtil, so that way there’s only one config contained in the GUI.
You could edit from the GUI (much easier) and just have ServerUtil run GUI job, but why do so?

I want to list my existing backup jobs and set them to “manual” (so they don’t run automatically anymore), but I’m struggling to find the right commands inside my Docker-based Duplicati setup.

What I have tried so far:

  • duplicati-serverutil list-backupsCommand not found.
  • duplicati-cli listCommand not found.
  • mono /app/Duplicati.CommandLine.exe listmono: command not found.
  • Accessing the API via:

bash

KopierenBearbeiten

curl http://localhost:8200/api/v1/backups

→ Is this the right way to list backup jobs and modify their schedule via the API?

My setup:

  • Duplicati runs in a Docker container.
  • I can access the container via docker exec -it duplicati bash.

Questions:

  1. How can I list existing backup jobs via CLI inside the Docker container?
  2. How can I change their schedule to “manual” via CLI or API?

Would really appreciate any guidance on this! :blush:

Can you click About to see what Beta version you use? Evidence still suggests some 2.1.

This probably confirms that the un-named Beta you’re on is a 2.1, else mono must be there.

Is there anything in /app on a LinuxServer image? We don’t make that, and I don’t have that.

suggests they may have put Duplicati in /app/duplicati. Is there a duplicati-server-util?

Command Line Interface CLI says that the current name is duplicati-cli, if you want that.

Basically, except for mono which I don’t think is anywhere, figure out where LSIO put things.

You can use ps -ef | grep duplicati. On a Linux system with 2.1, output shows full path:

root 8192 1 60 15:57 ? 00:00:01 /usr/bin/duplicati-server

LinuxServer often doesn’t use root (which is another issue), but maybe you can find install dir.

If all else (such as ps of your running server) fails, you can find / -mount -name duplicati

Not at all. It’s a rather complex API, and using an existing tool will be much much simpler.

But you need to first figure out where LinuxServer put it. Maybe somebody else can help?

Assuming you find duplicati-server-util, it’s still complicated compared to a button push:

image

I looked at the difference between a backup with above unchecked, and one after schedule add:

3c3,21
<   "Schedule": null,
---
>   "Schedule": {
>     "ID": 1,
>     "Tags": [
>       "ID=1"
>     ],
>     "Time": "2025-02-04T21:20:00Z",
>     "Repeat": "1h",
>     "LastRun": "0001-01-01T04:57:00Z",
>     "Rule": "AllowedWeekDays=Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday",
>     "AllowedDays": [
>       "Monday",
>       "Tuesday",
>       "Wednesday",
>       "Thursday",
>       "Friday",
>       "Saturday",
>       "Sunday"
>     ]
>   },

So I guess for starters you would reverse out the above changes in exported job configuration.
An actual run puts in more data, but I’m not sure it’s harmful, so maybe it could be left in there:

3c3,21
<   "Schedule": null,
---
>   "Schedule": {
>     "ID": 1,
>     "Tags": [
>       "ID=1"
>     ],
>     "Time": "2025-02-04T21:20:00Z",
>     "Repeat": "1h",
>     "LastRun": "0001-01-01T04:57:00Z",
>     "Rule": "AllowedWeekDays=Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday",
>     "AllowedDays": [
>       "Monday",
>       "Tuesday",
>       "Wednesday",
>       "Thursday",
>       "Friday",
>       "Saturday",
>       "Sunday"
>     ]
>   },

Your problem (as mentioned) is that while you can export and import, you can’t yet update.
ServerUtil is very new and not familiar, but I suspect you can get a new job without a schedule, however your old jobs will still have their schedule. I don’t think there’s job delete there either.

I don’t know if this is close enough to what you want, but clicking the button still sounds simple.
For completeness, I clicked mine to remove the schedule, did another GUI Export to a file, got:

3,21c3
<   "Schedule": {
<     "ID": 1,
<     "Tags": [
<       "ID=1"
<     ],
<     "Time": "2025-02-04T22:20:00Z",
<     "Repeat": "1h",
<     "LastRun": "2025-02-04T21:20:00Z",
<     "Rule": "AllowedWeekDays=Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday",
<     "AllowedDays": [
<       "Monday",
<       "Tuesday",
<       "Wednesday",
<       "Thursday",
<       "Friday",
<       "Saturday",
<       "Sunday"
<     ]
<   },
---
>   "Schedule": null,

so messing with the times related to the schedule does not seem necessary. Just null schedule.

Listing the backup jobs should be possible. Removing schedule from GUI jobs might need GUI.

Here’s my job listing:

$ duplicati-server-util --password password list-backups
Connecting to http://localhost:8200/...
1: test5

Assuming CLI is on Docker host and can edit Duplicati config, one unusual way to delete all the jobs is to delete Duplicati-server.sqlite then recreate it, including an import of edited job exports.

So I’m really not understanding why you won’t use the GUI button. CLI is going to be more work.

Regardless, I can help on further details, but you’re making an unusual request that’s hard to do.

Inside the Docker container, you need the full path to the binary:

/opt/duplicati/duplicati-serverutil list-backups

As @ts678 recommends, there is not a great patch command yet, so it is easier to just edit them in the UI, remove the schedule and click save.

After removing the schedule, you can use this, but triggered by whatever method you like:

/opt/duplicati/duplicati-serverutil run "backup name"

Are you sure LinuxServer went the same way? Even Duplicati’s image has changed location.

Do you disagree with my reading of the LinuxServer Dockerfile? I’m certainly not an expert…

Regardless, user has been given ways to figure out what “container linuxserver/duplicati” has.

I now managed to get a response using these arguments:

/app/duplicati/duplicati-cli

/app/duplicati/duplicati-server

I now also updated to the latest version (Version: - 2.1.0.4_stable_2025-01-31)

but I think both arguments aren’t helpful for my needs?

I want to automate the backup routines. And for that I need access via the CLI. A new backup should be started on the 1st of each month and the old backup should be switched to “manual”. The “old” backup should then be automatically transferred to my parents’ NAS via the Internet so that I have a complete emergency backup of the last month. If I have to do this manually every month, it’s very time-consuming.

You don’t need to do any of this. A Duplicati backup is not a file copy, and does not use traditional full/differential/incremental backup set organization if you happen to be thinking in those terms.

While you can play with retention settings on the options screen to suit your liking, doing rotations like this is generally not how one goes. Backups usually build on prior ones, with changes added. Backup size therefore grows slowly, so it might not be worth starting a new one to make it smaller.

Having multiple old and new backups defeats this, as each one is a full backup. Space use grows. You’ll work longer to make a new backup from scratch, and the old backup will just take up space.

Would it be a problem to get a complete emergency backup containing more than the last month? Transferring the multi-version backup once a month should get you a similar result far more easily.

I missed that part, but yes, it looks like @kuhnikuehnast figure out the right path in the LinuxServer image.

I agree with @ts678, this seems like you want full/incremental backups, which is not how Duplicati works.

If you want it anyway, I would suggest something like:

  1. Create a backup that looks like you want it, disable the scheduled backup, save it
  2. Export a copy of the configuration file
  3. Set up a cron job to trigger the backup when you want it to run
  4. On the 1st of the month,
    1. Use sed or similar to update the exported configuration with a fresh target folder, and a new name
    2. Add a new backup by importing the modified configuration document
  5. Make sure the cron job triggers the backup with the new name going forward

This will eventually fill your list with old backups, but maybe you can use the current month+year in the name so they are easy to clean up once a year or so.

Hello everyone,

I have discovered a few things regarding backups with the Duplicati CLI and their visibility in the GUI.

:one: Running a Backup via CLI

I can successfully start and run a backup job using the following command:

/app/duplicati/duplicati-cli backup file:///backups/2025_02/ /source/ \
  --backup-name=2025_02 \
  --dbpath=/config/2025_02.sqlite \
  --backup-id=DB-7 \
  --encryption-module=aes \
  --compression-module=zip \
  --dblock-size=500MB \
  --keep-time=1Y \
  --passphrase=testphrase \
  --disable-module=console-password-input

The backup runs fine, files are saved in the correct folder, and an SQLite file (/config/2025_02.sqlite) is created.


:two: Problem: Backup is not registered in Duplicati-server.sqlite

Even though the backup is created, it does not appear in the GUI because it is not automatically registered in Duplicati-server.sqlite.

To make the backup visible in the GUI, I ran the following SQL command:

sqlite3 /config/Duplicati-server.sqlite "INSERT INTO Backup (Name, Description, Tags, TargetURL, DBPath) VALUES ('2025_02', '', '', 'file:///backups/2025_02/', '/config/2025_02.sqlite');"

After executing this command and restarting Duplicati:

pkill -f Duplicati.Server

The backup appears in the GUI, but there are two major issues:

  1. No settings are saved – The backup entry exists but has no configuration details.
  2. The backup cannot be started from the GUI.
    I suspect that the issue is related to the TargetURL, which in GUI-created backups is stored as an encrypted string. I am unsure how to generate this correctly.

:three: My Questions

  1. Is there an easier way?
  • What needs to be done to ensure that a CLI backup automatically registers in Duplicati-server.sqlite?
  • Can I modify my CLI command to make this happen natively?
  1. If not – How can I generate the correct TargetURL?
  • Is there a way to generate the correct encrypted TargetURL so that the backup is fully functional in the GUI?

Any help or insight would be greatly appreciated! Thanks in advance. :blush:

Additionally, I also tried executing the registered backup (2025_02) using:

/app/duplicati/duplicati-server-util

However, I only received error messages and was unable to run the backup.

CLI is intentionally made to run separately from the GUI. You can even run several at once.

Duplicati-server.sqlite is for the server that runs the GUI. For those who find GUI to be convenient for creating jobs, job-equivalent CLI line comes from Export As Command-line. Integration is still limited, happening just because the two will be sharing the same database.

Alternatively ServerUtil can be run from CLI to run GUI jobs (but only one at a time as usual).

Please provide some information.

The Duplicati-Server.sqlite file contains several columns, including:

  • ID
  • Name
  • Description
  • Tags
  • TargetURL (e.g., for a backup configured via the GUI:
    enc-v1:B19406C6AC6CC9928EE134C5464FE79AC1656CEC7C8834E243784CA6009AD14A90345B720108A0D0A61059F8739E5105DA1013CF846FFB2AA4E5F35306E3CE7241455302000000DC94157B260B075D4C9FCD1F148290771C77D03C955E9D4D8A88A2F50E91332B460FF5506E6DF503FF8DC63BFA595E10514275A164036D864AF2D0C70AD40BF7B8DECE80A09B19283A226F6F7D2896E946D34EDE991639A9000D23E7E4DEA1CD9837DA970443137D7232A7504AEF3C37D6AEAF1CD6780353776C9DA3BFBC13B008C76EE4368FC771F7DB2727EB3D8C6BB27F88DDDC33AAF1E9020A2B8DFB58C7D6)
  • DBPath

I have now manually added the following entry in the database for a test backup (in this case, 2025_06):

  • ID: “3” (since it’s the third backup)
  • Name: “2025_06”
  • DBPath: “/config/2025_06.sqlite”
  • TargetURL: left empty, as I don’t know what to do with the cryptic string (but I assume it contains all the backup configuration details).

Now, when I run the command:

/app/duplicati/duplicati-server-util list-backups

I can see that there are three backups:

1: 2025_04
2: 2025_05
3: 2025_06

(1 and 2 were created via the GUI, 3 was executed via CLI and then manually added to Duplicati-Server.sqlite.)

However, when I try to run the backup using:

/app/duplicati/duplicati-server-util run 2025_06

nothing appears in the terminal. When I open the GUI, I see the following error:

Error while running 2025_06
No source folders specified for backup

Any ideas on what I might be missing?

You’re not supposed to be hacking on the database. There’s no telling what you’ll set up wrong.
There are no detailed directions for this, but you can guess some pieces of it by looking around.

There are a lot of things in the database indexed by ID in Backup table, e.g. the Source table.
If you put nothing in it for ID 3, that probably explains why the job thinks it’s got no source config.

Since you apparently didn’t like the kenkendk suggestion enough, how about just keeping a job around for cron to run by ServerUtil daily or whatever, then monthly you ship it off and start fresh, meaning delete the destination and its database. If you prefer, don’t delete, but move the pieces.

For example, to satisfy restores old enough to be in prior month, have that sitting around in a job meant only for restore purposes. Rather than reconfigure jobs, do file and folder rename instead. Symlinks might work too. Basically, move the destination and DB to the job (two jobs in this idea).

Refinement of that would avoid ServerUtil and let the current-backup job have Duplicati schedule. Historical-backup job has no schedule, as it’s only for restore.