4 ms·
There was discussion of bigger issues. Such as large numbers of volunteers leaving to start an alternative beforehand. Data loss that apparently had no backup
by whatyesaid 3y ago
There was discussion of bigger issues.
Such as large numbers of volunteers leaving to start an alternative beforehand.
Data loss that apparently had no backups leaving thousands of pages gone to the dust in the case of a single wiki. Then restored randomly some night months later from a backup that now popped up out of nowhere, which then also made all newly added and replacement pages created in the months between the loss and restoration disappear. (source: https://news.ycombinator.com/item?id=36363433 https://news.ycombinator.com/item?id=36363433)
- jemmyw 3y agoI did see those comments, but that seems more like a good reason to tighten processes and consider if a different volunteer might be more suited a particular sysadmin role. Fuckups happen and more so in a community run project. I'd rather be hosted on something that had a major incident in the past and they've communicated how they'll move on than a project that has not yet had an incident, unless it was quite mature and proven.
- labster 3y agoWe're just about to appoint an outside analyst looking at our technology stack and processes over the next few months to make recommendations on how we can improve things. This too is a volunteer, but someone with both FAANG and Mediawiki experience. Also, users can create their own backups of wiki content and export it. This doesn't excuse our history with backups at Miraheze, but with good backup practices on the user's side it can greatly reduce your risk. You are not dependent on Miraheze's backups, as you would be at certain other wiki providers.
- sitkack 3y agoYou should write to the users choice(s) of s3 compatible buckets. 10s of providers here.