Search service is being restored after ransomware attack

03 Oct 23: One server has been relocated, the server currently doesn't have a public IP address in the meantime. I wrote some additional tunnel code running separately to handle this. When the server is engaged the connection is 5600+ days uniform (since around 24 July 2008). In the unlikely case I disengaged the server because of some problem the retention is 1200-3800 days depending on newsgroup. If you experience any issue please let me know.

29 Nov 23: Because of encrypted and obfuscated posts flood mass posted by a few nzb indexing websites using usenet servers as private storage for their members to download the posts - the situation with the content is pretty chaotic since their purpose is to post in such a way, so users must use their website exclusively, when the website disappears - the encrypted posts just eat usenet providers' hard disk space uselessly. If you can't find something specific please let me know at alexbirj at gmail dot com what exactly you can't find for me to check how it is possible to retain the posts. Non-obfuscated posts shouldn't be affected at all, let me know if you notice anything missing.

29 Nov 23: The search protocol had to be upgraded to extend 3 byte (16M+) limit on the server side for number of sets per instance, so at least the version 5.8.3 is needed to access it, otherwise should be no any difference.

21 Jun 24: The search protocol had to be upgraded again to be able to properly process the trial version searches on the tunneled server (see the first note above).

Post Reply
Posts: 4518
Joined: Thu Feb 27, 2003 5:57 pm

Search service is being restored after ransomware attack

Post by alex »


November 13: A server which was supposed to be upgraded was attacked by ransomware, probably due to rdp vulnerability, the search service is currently down for backup.

November 14: I'm restarting the search service with limited retention. The affected server had been already scheduled for upgrade, but I will need now also to copy the backup data to it which will take some time.

November 20: The server affected by the ransomware attack had the system reinstalled and it has been upgraded (RAM, disk space). I'm in the process of copying data from another server. Even as there is more RAM, for a subset of groups I will try to run mid retention range in the compact mode using sets as the server then starts several times faster and consumes twice less RAM, we'll see how it goes.

December 1: I will be engaging the server soon, maybe will try later today or tomorrow as it may take time to convert the database into the compact mode. It may take another week to copy all the data, but maybe I will be able already to run it very near full retention including the oldest headers.

December 2: The restored server has been engaged. There is a retention gap for some groups between 1200-2300 days, but it will be filled within a few days. Some server instances are run in the compact mode (natively supported sets) which wasn't a case in the past. Overall retention range is around 5300 days.
Post Reply