Backup is not versioning!

I have 5 running back-ups. Only one of the back-ups has 15 different versions. The others stay at only 1 version.

And yes: the source data is changed (almost) every day.

What is going wrong here?

Is it possible you have a retention policy on or --keep-versions? They would show up on the last page of your backup config under advanced options

They are all set to:

Keep this number of backups: Until they are older than 10 years.

Any advanced options specified?

Only: aes-set-threadlevel: 4

Hmm, what about global settings? On the settings page at the bottom of the page

Nope no additional options are set. Because of this behavior I reinstalled my Dupicati docker container and wanted to make simple/easy/plain back-up tasks to be sure the additional settings where not causing the version problem.

Do you run backups using the integrated scheduler in the Web UI, or do you use an external scheduler (Cron, Windows Task Scheduler) and start backups using the commandline from there?

It’s a known issue that the number of versions in the UI is not updated if a backup is started using the commandline. However, if you choose Restore files from the web UI, you can choose between all versions.

I use this docker container:

The versions aren’t visible at the back-up server also. Only the first initiated task (15 days ago now).

For the only (working) back-up which has 15 versions I see many many files at the back-up server.

What are the last run times for the single version jobs?

If is it possible there are filters causing the jobs to not back up the files or folders that are changing?

No filters, all the jobs are all the same. Offcource the file locations are different.

Something is really going wrong here. And yes again: there are file changes (everyday).

Including the destination right? Multiple jobs should not back up to the exact same destination. You can back up to the same general destination (eg, S3 bucket) if you use a separate folder for each job within that one bucket.

Thanks for the annotated screen shot, that makes it pretty clear what’s going on.

They only way I can think of this happening would be odd retention or “keep until” policy settings such as:

  • global only keep one version with a single job override to allow more than one
  • global keep multiple versions with all but one job having overrides to limit to a single version

Would you be able to post the results of “Export as command-line” for one of the single-version jobs (with any identifiable or secure data such as user names, passwords, etc. scrubbed)?

I’m having the same problem listed here.

I change a single file, start a manual backup and it doesn’t create a new version, just keep the first and latest version.

My settings:


My command line for this backup is:

"C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe" backup "file://C:\Users\serpro\backup" "C:\Users\serpro\Documents" "C:\Users\serpro\Documents\\" "C:\Users\serpro\Desktop\\" --all-versions=true --keep-versions=-1 --backup-name="Backup Dell Notebook" --dbpath="C:\Users\serpro\AppData\Local\Duplicati\EVJLLNBWCL.sqlite" --encryption-module= --compression-module=zip --dblock-size=50mb --retention-policy="1W:1D,4W:1W,12M:1M" --no-encryption=true --disable-module=console-password-input

Hello and welcome!

--all-versions probably does nothing on a backup job. It’s an option you can use when searching. I’d probably remove it.

--keep-versions=-1 is at conflict with your --retention-policy. You can’t have both, so I believe Duplicati ignores the --keep-versions option. So I’d probably remove that option, too. (Unless you really want to keep all versions, in which case you need to remove the retention policy.)

Your --retention-policy is telling Duplicati to keep only 1 backup version per day for the first week. That’s probably why you are losing a backup version when you run an extra backup during the day.

If you want you could keep ALL backup versions for the first week by adjusting your retention policy:


Note that with the above you won’t keep any backup versions beyond 12 months. If that’s what you want, great, but I thought I’d mention it just in case.

Thanks for your reponse!

That worked! I put at the end 4Y:1Y so it will keep some backups.

Wish a Great 2022 to you @drwtsn32 !

1 Like