canary is a different channel. In Duplicati parlance, ‘beta’ === stable, ‘canary’ === ‘unstable’. I know that it’s confusing
You need to actually say that you want to use the unstable (canary) version else the upgrader will never attempt to use it. Change it under ‘settings’ (paramètres) / update channel (canal de mise à jour)
In ordinary times, it would be considered proven enough, but it’s also a matter of what’s in or trying.
It’s not stable as in Stable channel due to its many Issues, but it might be a candidate for next Beta.
That’s pretty much the standard flow, however it goes through Experimental first to test autoupdates.
What’s unusual now is the one person who can make releases seems to have no time to do them…
I’ve posted several times for a release manager opening, but now I’ll repeat my usual refrain, saying:
Duplicati exists and improves only through the work of volunteers doing code, test, docs and support
(maybe I should add release, but that’s kind of a specialty item). All please consider stepping in or up.
first and foremost: a good test is ONLY a reproducible test. It’s absolutely essential to document the steps for get to the initial situation (known as good) and the steps to produce a failure. So you should be able to get back to the initial state of data before the test begins. The main reason is that you can’t be sure of fixing a problem unless you actually demonstrates that you fix it. Another very powerful reason is that Duplicati, as a backup software for the masses, should work for people with consumer grade hardware. That means hardware without ECC Ram. Nowadays consumer grade hardware has lot of Ram and sometimes it suffers random failure (mostly cosmic rays and I am absolutely not joking). So an isolated crash or failure on such hardware means absolutely nothing and you would just wasting the time of everyone reading your reports. If you can reproduce it every time (at least 2 times), it begins to be interesting.
stays to the basics. A backup software has 2 main points: backup and restore. The most important step is restore, although it is hardly possible without the backup step. So the main test objective is testing restoring data. Duplicati has tons of commands that are only useful if you have a good database. If you are starting from backup data and a new computer and you can’t restore data, these commands are useless.
I’d modestly point to my own post about the best way to test restoring data: Duplicati error while restoring - #9 by gpatel-fr
because using the command line is the best way to ensure reproducibility, without having to do screenshots, describe complicated click sequences…
So if you have a way to get from good data to a restore failure (uncomplete while it should be correct, unsuccessful even), you could help the project. If you have such a case, post it here and see if someone that can read code can help figure the problem out. If you are ready to share the data or if it’s not doable provide a way to someone more experienced to access your test computer, the better.
I propose to install Canary version on my computer portable because I have not solution at this time of backup of my data in mirror on another disk
it possible for me to install Canary version on this machine (as a service ?) and so duplicati made backup of C:/ to another disk like D:/
I could test so the regular backup, the email and various option and so restauration
But if it not util so forget my proposition
it is for help because i think Duplicati is a very very good projet opensource
If you are backing up live data, it’s not very useful IMO because it’s not possible to reproduce a problem. If it’s personal data, it’s also awkward to share it. Well, drink a beer if you like the stuff, but don’t try the trick with a live bear, even a small one.
I think that’s the ideal, because a developer considering fixing it can then repeat it and look for the bug.
Lacking that, sometimes one can figure out rare events (e.g. a network glitch) through lots of advance preparation to set log-file and other collections. Personally, I keep a series of database snapshots too, however I’m pretty extreme, and will sometimes go try to get to the bottom of things without more help.
This also solves the privacy problems because it’s me looking at my own backup. I also use test data.
For lighter testing, even being willing to run Canary for a secondary backup will help spot big problems. Knowing if it’s bad will at least prevent an accidental bad Beta, but the more info we can get, the better.
It would be nice to have a test team that sort of know what helps, but even more, any developers here?