I upgraded duplicati on my CentOs 7.7 server from 22.214.171.124-beta to 126.96.36.199.
Now my scheduled backup runs in an endless loop and never finishes.
In my verbose log file I can see the backup start as expected:
2020-01-28 02:30:54 +01 - [Information-Duplicati.Library.Main.Controller-StartingOperation]: Die Operation Backup wurde gestartet
Then it runs through the normal stages, “Backend event: List - Started”, “Backend event: List - Completed”, some “Backend event: Put”, “RetentionPolicy-StartCheck”, then it deletes old files (“DeleteHandler-DeleteResults]: Deleted 2 remote fileset(s)”), and checks the remote files.
Then it starts all over again:
2020-01-28 02:50:41 +01 - [Information-GetGpgProgramPath-gpg]: gpg
2020-01-28 02:50:41 +01 - [Information-Duplicati.Library.Main.Controller-StartingOperation]: Die Operation Backup wurde gestartet
2020-01-28 02:55:17 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Started: ()
2020-01-28 02:55:28 +01 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Completed: (2,65 KB)
and so on.
The backup is scheduled to run once a day at 02:30 AM.
When I click on “Stop after this file” it does stop but the server crashes.
The backup it has made does show up in the “Restore files” list, but the “Last successful backup” info on the main screen is not up to date.
When I delete the backup schedule and run the backup manually it does run the backup once, then the server crashes.
Interesting. If you DO have the schedule in place, does it crash between backups? Maybe Duplicati crashes before it can record that it completed the backup job, and when the service (automatically?) restarts, the backup job is immediately triggered.
I don’t really have an idea as to why it’d be crashing at that point, but can you confirm which version of mono you are using?
Ihave something similar on
and found it was the Destination folder was unreachable (S3 in my case).
Backups ran endlessly one after the next. Not sure if there should be a check of some kind to stop this
hope it helps
My destination folder (on a Microsoft OneDrive v2) is reachable. Files are written every time a backup runs. I can restore from it, too.
I added a second backup for testing: same destination, configuration newly created in 188.8.131.52-beta, less files to backup. This one runs fine. It shows 1 warning but no server crashes, “last successful backup” timestamp is shown correctly on the home page.
It seems to create a core file with every crash when I run the old config:
rw------- 1 root root 681M 28. Jan 13:44 core.29268
-rw------- 1 root root 699M 28. Jan 14:03 core.31866
-rw------- 1 root root 742M 28. Jan 14:21 core.2619
-rw------- 1 root root 509M 28. Jan 14:37 core.5379
-rw------- 1 root root 703M 28. Jan 15:12 core.7671
My mono version is:
Mono JIT compiler version 4.6.2 (Stable 184.108.40.206/ac9e222 Mon Jul 31 05:33:23 UTC 2017)
Your mono version needs to be upgraded… Duplicati 220.127.116.11 requires mono >= 5.0.
This link should help: Download - Stable | Mono
Updating mono solves this issue. Thank you.
The package managers should think about updating the rpm dependencies.
It’s actually messier than that, as the autoupdate doesn’t use an RPM install.
There are also other packages that aren’t RPMs that “should” get updated…
This is complicated by the person who knows packaging not being available.
In a perfect world, everything would have been covered. The actual notice is:
Release: 18.104.22.168 (beta) 2020-01-18
On Linux, macOS, and other systems that require Mono, this version requires Mono v5 or later.
Autoupdater definitely complicates things. But I agree that the rpm should have the dependency updated. I submitted a change earlier this week to have the deb package updated.
I’m not familiar with rpm packages but looks like it’s just this line that needs changing:
Thanks! One down, three or so to go. If you do Synology, at least you have a way to test it, I believe…
If there are packaging experts out there, see https://github.com/duplicati/duplicati/tree/master/Installer
If anyone looks into the Red Hat install, note that duplicati-binary.spec also has a reference to mono 3.
Another problem with some distros, especially the “Enterprise” or “LTS” ones, is they have old mono…
Probably declaring a dependency and having it fail is at least a step less mystifying than runtime crash.
I’ll have to look into it, but the current Synology package installs even if Mono isn’t installed at all. It’s as if there is no dependency set at all.
I have submitted PR # 4088 to update the RPM package dependecy, too. But I haven’t actually tested it myself. Pretty confident it will work though.