Is there a problem if the two computers are running different versions of the CLI?
The new machine is a mac on 3.1.0 and the first machine is a PC on 2.7.2. The web-gui claims these are the latest stable versions…?
Yes, there was a breaking change recently.
You have set “Stable” on a PC and “Latest” on the mac (or haven’t rebooted pc or duplicacy service for months (or there is a race condition where duplicacy attempts to download update while network is not yet ready on start)), that’s why you got different versions: They are reported by this api: https://duplicacy.com/latest_cli_version, that right now returns {"latest":"3.1.0","stable":"2.7.2"}
Duplicacy shall keep “minimum required version” in the data store, recorded after every non-backwards-compatible change, and use it to fail adding the updated storage to old client, with a human-readable, descriptive, and actionable message.
Hmm…
I’m running the web versions on everything.
MAC is set to stable and is on 3.1.0. Really, I double checked.
PC is set to stable and is on 2.7.2 and I just shutdown and restarted the app. It’s not running as a service. It’s not grabbing anything than 2.7.2 on it’s own… How do I prod it into action?
PC is set to stable and is on 2.7.2
This seems to be correct: current stable is indeed 2.7.2.
This is weird. Not sure how could it end up like so.
What happens in the duplicacy_web.log when you restart duplicacy? (Exit and start it again)? I’d expect it to download 2.7.1.
If it does not even try — delete the duplicacy CLI binaries from ~/.duplicacy_web/bin folder and restart the duplicacy_web. It shall download some CLI now, and it shall be expected to be 2.7.2, per settings.
Quit and restarted duplicacy on the mac:
2023/01/27 22:30:20 Temporary directory set to /Users/carlliebold/.duplicacy-web/repositories
2023/01/27 22:30:20 Duplicacy Web Edition 1.4.1 (074ED2)
2023/01/27 22:30:20 127.0.0.1:49967 GET /
2023/01/27 22:30:20 The log file backup-20221228-203141.log has been deleted
2023/01/27 22:30:20 The log file check-20221228-203146.log has been deleted
2023/01/27 22:30:20 The log file backup-20221228-204001.log has been deleted
2023/01/27 22:30:20 The log file check-20221228-204005.log has been deleted
2023/01/27 22:30:20 127.0.0.1:49968 GET /assets/fonts/fontawesome-webfont.woff2?v=4.7.0
2023/01/27 22:30:20 127.0.0.1:49967 GET /assets/css/paper-dashboard.css
2023/01/27 22:30:20 127.0.0.1:49968 GET /assets/css/bootstrap.min.css
2023/01/27 22:30:20 127.0.0.1:49969 GET /assets/css/font-awesome.min.css
2023/01/27 22:30:20 127.0.0.1:49967 GET /assets/js/bootbox.min.js
2023/01/27 22:30:20 127.0.0.1:49970 GET /assets/css/duplicacy-web.css
2023/01/27 22:30:20 127.0.0.1:49971 GET /assets/js/jquery-1.10.2.min.js
2023/01/27 22:30:20 127.0.0.1:49972 GET /assets/js/jquery.min.js
2023/01/27 22:30:20 127.0.0.1:49968 GET /assets/js/bootstrap.min.js
2023/01/27 22:30:20 127.0.0.1:49969 GET /assets/js/paper-dashboard.js
2023/01/27 22:30:20 127.0.0.1:49967 GET /assets/js/axios.min.js
2023/01/27 22:30:20 127.0.0.1:49970 GET /assets/js/chartist.min.js
2023/01/27 22:30:20 127.0.0.1:49971 GET /assets/js/polyfill.min.js
2023/01/27 22:30:20 127.0.0.1:49972 GET /assets/img/product-icon.png
2023/01/27 22:30:20 Duplicacy CLI 3.1.0
2023/01/27 22:30:25 127.0.0.1:49967 GET /setting
2023/01/27 22:30:25 127.0.0.1:49967 GET /assets/css/paper-dashboard.css
2023/01/27 22:30:25 127.0.0.1:49968 GET /assets/css/bootstrap.min.css
2023/01/27 22:30:25 127.0.0.1:49970 GET /assets/css/duplicacy-web.css
2023/01/27 22:30:25 127.0.0.1:49971 GET /assets/js/jquery-1.10.2.min.js
2023/01/27 22:30:25 127.0.0.1:49969 GET /assets/css/font-awesome.min.css
2023/01/27 22:30:25 127.0.0.1:49972 GET /assets/js/bootstrap.min.js
2023/01/27 22:30:25 127.0.0.1:49968 GET /assets/js/chartist.min.js
2023/01/27 22:30:25 127.0.0.1:49971 GET /assets/js/bootbox.min.js
2023/01/27 22:30:25 127.0.0.1:49967 GET /assets/js/axios.min.js
2023/01/27 22:30:25 127.0.0.1:49973 GET /assets/js/jquery.min.js
2023/01/27 22:30:25 127.0.0.1:49969 GET /assets/js/paper-dashboard.js
2023/01/27 22:30:25 127.0.0.1:49972 GET /assets/js/duplicacy-web.js
2023/01/27 22:30:25 127.0.0.1:49968 GET /assets/js/polyfill.min.js
2023/01/27 22:30:25 127.0.0.1:49971 GET /assets/img/product-icon.png
2023/01/27 22:30:25 127.0.0.1:49967 GET /assets/fonts/fontawesome-webfont.woff2?v=4.7.0
So…
I tried this:
If it does not even try — delete the duplicacy CLI binaries from ~/.duplicacy_web/bin folder and restart the duplicacy_web. It shall download some CLI now, and it shall be expected to be 2.7.2, per settings.
And:
ANd then:
So… 3.1.0 seems to be the latest stable release for the M1 Mac. And 2.7.2 on the PC…
What should I make of that?
Weird. Paging @gchen — AFAIK there is just one version url that duplicacy-web is using to fetch CLI executables, but maybe it changed recently?
LoL.
So on a whim, I deleted the CLI bin AND the “Duplicacy Web Edition” app from my mac and installed the newest version… (I was on an older version, I think 1.4?).
And the new version DID download 2.7.2! So either it was the old app, or @gchen fixed something in the last hour…
So back to my question… running both a mac and a PC on 2.7.2.
I can imagine one might end up eventually updating before the other machine. I can’t really make sure those backups are synchronized.
Is it a problem if two machines pointing at the same bucket are on different revs?
Looks like indeed a new behavior in duplicacy web…
https://duplicacy.com/latest_cli_version still returns the same/
There used to be a way to fix the version of the CLI that web is using, somewhere in the settings.json file, but I can’t find that post.
Within the same major version, it should be fine. Between major versions — definitely not. That’s (one of the) implications of incrementing a major version – that it may break forward compatibility, among other things. In this case this was indeed the case somewhere in 3.0.x
Latest Duplicacy Web Edition is v1.6.3, is it up-to-date on both systems?
Now they are… 
They were not earlier today.
Hmm… so how do people manage this when the “stable” release bumps up a major rev?
I mean, I might not even notice the change…
I don’t think it’s handled properly today, if at all.
If duplicacy web checked for the CLI version before each invocation it would not have been a problem as long as all machines involved were on the same channel.
But IIRC it only checks on startup and CLI faceplants if datastore contains newer content.
I think nobody noticed, because there was no breaking change before, and there are very few people who backup to the same datastore from multiple sources, and even fewer that use web_ui, (based on my speculation). But since that 3.0.x there have been a few posts with symptoms similar to yours.
In other words, yes, duolicacy must handle that gracefully but I don’t think it handles it today.
OK… so it sounds like I really shouldn’t use the same data store. And thus will lose any de-duplication benefits. No biggie for me, but I could imagine others being rather annoyed.
If you benefit from deduplication across machines — use it. Worst thing that will happen — backups will start failing on the other machines, so you would get an email, and manually update that other machine.
I would not change my backup arrangement to workaround software issues.
You just need to update all clients to the latest v3.1.0.
The aforementioned issues only arise when trying to copy v3.x snapshots with v2.x client, or copying v3.x snapshots with v2.x client. Both issues are fixed if updating all clients to v3.1.0 (which can see ‘bad’ snapshots of v3 copied with v2, and can already upgrade v2 to v3).
Your issue, from what I understand, comes from downgrading to an earlier version on the same snapshot ID (which you must admit is extremely unlikely to happen and easy to rectify, since all you get is an error).
Ideally you’ll want to upgrade all clients at the same time, but v2 snapshots of one snapshot ID should be able to coexist with v3 snapshots of another snapshot ID. So backups should be fine, unless you downgrade a client. Trouble arises when doing storage maintenance (check, prune) if not all clients are updated, so update ASAP once the process is begun. 
I understand v3.1.0 and subsequent versions now have a version bit for the snapshot format, so future upgrades should be smoother sailing.
Yes, this all really tells me I shouldn’t use the same storage for multiple copmputers. I’m just too much of a regular user who isn’t going to notice if backups stop because of an automatic update… and that just seems nuts to me. I’ll run every computer independently to avoid that kind of issue.
I’ve complained about the lack of built in failure notice already:
Thanks for the help everyone!
The service like https://healthchecks.io/ helps here. You setup a url that duplicacy calls at the end of successful backup. And configure the service to send you a notification if it did not receive that callback at the expected intervals.
This way you will get notified if backup did not succeed regardless of the reason—failed in the middle or never started— no notification about success → notification (email/SMS/WhatsApp/whathaveyou) gets sent to you.
Ideally, similar service shall be hosted by duplicacy to avoid having user configure it with third parties, as part of the duplicacy_web value proposition, among other things.
I don’t think you understood what I said. Under no circumstances should backup jobs suddenly stop because of an auto update and mismatch between client versions. Clients have their own, separate, snapshot IDs. They stopped for you because your client got interactively downgraded.
In my case, backups continued to work just fine - and even copy jobs continued to work (albeit copied the snapshot without the version bit). This was corrected since v3.1.0 assumes no bit = try both formats.
Since v3.1.0, snapshot formats have a version bit now.
Healthchecks is a piece of piss to set up, and will cover a lot more failure modes as saspus points out.
This is a great point: during backup of a specific snapshot duplicacy only needs to be able to unpack data created as part of backups of this specific snapshot, and so if you never downgrade the version that makes that specific snapshot it shall never fail, regarding of what others are doing.
Restoring, on the other hand, can be a different story, although likely will still work, unless pruning and copy schedules overlap in some specific way.