Create formal channels to inform users in time about the latest known critical issues (like this one which causes data loss). This can save the day for users. For channels, I personally like a dedicated category in the forum or newsletter (because I can subscribe by email).
There are a couple of channels for this already.
The main point of new releases is of course the GitHub releases page, which is where all new releases are published.
Besides that, there’s also the blog on the website and the corresponding blog category in the forum which has an announcement for each new restic release.
This bug is in the latest version of restic 0.16.3. And for now, there is no newer release fixing that bug. I mean, for example, we can inform users to stop using the max compression level with version 0.16.3 at this moment in time rather than the moment of release of the next version. I used to use max compression level. It takes me a lot of time to deal with my repositories because of this bug. And fortunately I didn’t need to restore from backups during my use of v0.16.3. Without the kind of notice I mentioned above, before v0.16.4 is released, for other users who use max compression level, if they lose original files, it’s possible that they can’t restore the files from recent backups from v0.16.3.
1 Like
Yes, I’m not dismissing your idea, and I’m aware of the situation. We’ll have a think about this, thanks for the suggestion!
Can you tell me what you would have done differently if there was a blog post a couple of days ago saying that a bug that can in some cases cause data corruption was found in the compression library, and that a patch release is around the corner? How would this change things in practice for you and what you do with your repositories?
Please note that the time window we’re talking about here is quite small - restic 0.16.4 will be released this evening as it look now - that’s less than three days after the bug was established. I think it would be a bit different if there was a larger time frame between the issue being discovered and a fix coming out. If the maintainer of a software finds an issue that can be severe, and feel that they cannot release a patch very soon - then it makes a lot more sense to put out a notice and recommendations for it, while a solution is being developed.
FWIW, a bug like this is unlikely to go unnoticed in the future, as restic will from now on have even more integrity checks enabled by default than it already had. This will catch even more hardware issues and also bugs in dependencies like in the latest case.
3 Likes
Thank you all for your work on the quick fix from v0.16.4! 
1 Like
An example to demonstrate the differences between with and without notice of the bug in the latest version of restic to an unfortunate user
Without notice of the bug in the latest version of restic
- Bob used to use
maxcompression level to back up his files. - Bob got some new (or new versions) files and backed them up into his repository, but unfortunately, the packs were corrupted, and Bob didn’t know.
- Something bad happened to the files. So Bob tried to restore it from the backup, but it failed. Finally he has lost those files.
- Restic v0.16.4 was released, and Bob’s aware of that bug in v0.16.3 now.
With a notice of the bug in the latest version of restic
- Bob used to use
maxcompression level to back up his files. - Bob got some new (or new versions) files and backed them up into his repository, but unfortunately, the packs were corrupted, and Bob didn’t know.
- Restic sent a notice about the bug in the latest version of restic. Bob received an email about it because he’s subscribed to a dedicated channel for that purpose.
- To secure all files Bob had at that time, Bob created a new repository and used the
autocompression level instead to create a new snapshot. - Something bad happened to the files. Now Bob can restore it from the new snapshot created with the
autocompression level in the new repository. Bob didn’t lose any files. - Restic v0.16.4 was released.
2 Likes
Thanks for taking the time to write that up! As promised we’ll discuss your suggestion. I’m pretty sure the official channel is still going to be the blog (which has RSS features so you can subscribe to it) or perhaps a category in this forum (which has RSS too), but the matter is about establishing a routine for that (which shouldn’t be a problem).
2 Likes
The lowest effort approach - as everybody is busy and this is open source project - IMO would be dedicated forum category. Moderator(s) could always post there something critical. And whoever cares can subscribe to this specific RSS category. I think it would be low hanging fruit to implement. Maybe there is an option to receive email for any new posting in specific category? It would crack mailing list problem in the same step.
I run daily backup and 3 days means files affected during these 3 days are corrupt. It would be really good to create a communication channel that notifies users as soon as the bug is found.
A mailing list or discord notification for any issue that can cause data corruption would be great as not everyone uses RSS.
If these issues were only brought up on the forum category, people such as myself now have to subscribe to two RSS feeds; the blog would be my preference.
It is a tedious chore to manage multiple channels of communication for sharing important information. For the sake of the developers’ time, my opinion is to use the existing Discourse capabilities and place the burden on end users to figure out how to enable personal notifications.
If the blog category is already used sparingly and suitable to the purpose, then people can follow 
the blog category RSS feed or 
register for emails like so to achieve a traditional email list behavior:
- Configure emails to be sent “when away” or “always”.
- Add desired categories to “Watching First Post” in
the tracking settings
The forum admins can configure the default settings for new forum users to automatically subscribe them to the blog category this way.
Discourse does support a way to track tags similarly, which would allow even more selective notification of blog posts tagged with something like security, but it looks like tags are disabled on this forum.
1 Like
I think you’re misunderstanding the issue. If you are affected by a bug in the compression library used by restic, then it’s not just those three days’ backups that are affected. Whenever a file contains that specific data that triggers the bug, it would have happened for all the backups that you made with the problematic version of the compression library. So this isn’t about just three days, it’s about a larger time, which makes the three days less relevant. In particular if a fix is on the way.
The same can be said by most users - I don’t use X and prefer Y. I don’t see Discord being an official channel for restic, for very good reasons. An official channel would preferably be one within restic’s own infrastructure, not a third party. RSS is extremely established for this type of use case, and since there’s RSS support both in the already official forum and the official blog, that is the obvious choice for this.
FWIW, using RSS is not something that you need to to through hoops to use - if you don’t already have an RSS reader (and they are pretty much everywhere - you can read RSS in your browser, your mail client, etc, etc), there are plenty of third party services where you can aggregate this type of stuff. I do like mailing lists too, but maintaining a mailing list is something we’d like to avoid when we as mentioned already have two RSS-enabled channels in place.
Are you referring to the blog being the first one, and then the announcements section being the other one?
The announcements section is a pretty good candidate given that it is about exactly what this topic is about - an announcement. But the blog category in this forum is already synchronized from the website blog, so that’s a good option in that regard.
Yes I definitely misunderstood it.
RSS would be nice too. People who don’t read the release changelogs (like me) need to be notified somehow.
1 Like
Yes. If it doesn’t cause undue burden then both would be beneficial.