I would like to know whether critical issues are solved for publishing a new beta (I remember there was a post by the developers with a checklist, but cannot find it).
I am sticking to beta since canary 126.96.36.199 gave me problems a few months ago, so reverted to 188.8.131.52 with some pain (since database versions changed). However I miss very much the multithread capabilities of recent canaries. On my Linux laptop with around 150 GB under backup, when mono starts, it hits 100% of 1 core for a lot of time. I fear trying new canaries, because I do not want to mess my 150GB backup.
Or, another nice possibility would be: is there a way to safely test new canaries with my existing backup, without messing it, and with a bulletproof way to reverting to the old database?
Critical issues with the current canary might be what you’re thinking of, and I’m not sure if the unchecked repair checkbox means something got worse (compared to 184.108.40.206 beta) or that improvements aren’t set.
On Linux, possibly Docker (which I don’t use) will let you have separate Duplicati “installations”, however keeping things separate is critical, because scrambling (e.g. sharing a destination) can create disasters.
Without that, keeping things separate might have to rely on a common base version with separate server folders (which you need anyway), allowing separate update channel settings and updates. Hazards exist. Basically you’re replacing risk from canary with risk from the setup and operation. Which do you want?
On a positive note, having separate backup software to separate destinations is exactly what’s suggested when reliable backups are sought. One hopes that both backups won’t suffer a problem at the same time, however you’d be increasing the risk by having both backup products be Duplicati (though different ones).
can mean several things. such as reverting the structure (should be safe unless manual steps are wrong), reverting the content if canary breaks it (some people backup their database anyway for faster restoring if drive fails – use a secondary backup if you want this), but reverting destination files could also be needed.
I believe a new beta is “in the works”, but it is focused mostly on dealing with Microsoft retiring their old OneDrive API.
There was definitely some pain with the 220.127.116.11 area releases, but it’s been pretty stable (for me at least) since at least 18.104.22.168. I’ve had no issues at all with 22.214.171.124 and 126.96.36.199. (Excepting ones caused by me messing around with stuff. )
I’d suggest giving it a few more days before putting effort into testing multiple versions (which is totally doable but, as @ts678 said, needs to be done carefully).
When you run a new version, Duplicati will upgrade the database as you have discovered. We do not currently have any safe way to roll back the version (it would require a test suite that could verify things worked correctly after downgrading).
Instead, Duplicati makes a copy of the database prior to upgrading it. You can then “switch back” by manually renaming the databases, but this will of course not contain anything you did with the new version.
Yes, there were a number of reports of ridiculous slowdowns, but I believe they are fixed now.
I held back creating a new beta build because there were some errors and slowdowns reported, but I believe these are now fixed.
With the recent OneDrive fix, I want to create a new experimental build and then a new beta build (including the multithreading updates).
That means that many people reported problems issuing the repair/recreate commands so it should be fixed. I have an idea for how to fix them but I have not completed the new code. This is the same as in 188.8.131.52 beta, so it does not make sense to postpone the next beta because of it.
(Side note: figuring out why repairs are often needed is also not completed).
I started the release process with 184.108.40.206, hoping to roll out a replacement for the closed OneDrive Live API, but it hit a small roadblock. I will make a new canary from master (hopefully today UTC), and then upgrade to experimental next week.