Hi,
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 2.0.3.6 gave me problems a few months ago, so reverted to 2.0.3.3 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 2.0.3.3 beta) or that improvements aren’t set.
Release: 2.0.3.12 (canary) 2018-10-23 talks about a new Experimental – less potential for surprise than Canary which can drop major changes in too. Safest to read release notes, for example 2.0.3.6 warning.
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 2.0.3.6 area releases, but it’s been pretty stable (for me at least) since at least 2.0.3.10. I’ve had no issues at all with 2.0.3.11 and 2.0.3.12. (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 2.0.3.3 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 2.0.3.12, 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.
I’ve made a post at Downgrading / reverting to a lower version to discuss where to use this unattractive downgrade method instead of the unattractive downgrade methods currently being developed there.
)