Hello

I am currently cleaning up my user database, i.e. I deleted lots of dead accounts.
Unfortunately, I deleted a few accounts wrongly

Only for clarity, it sounds as you deleted the accounts manually. Is this correct? I ask because we have a dedicated feature for cleaning up the userdata. You find it in the userdata management page in the admin area. It provides the opportunity of deleting all accounts for which there is no or only one login in a specified period. It might be a good idea to provide further criteria like "wrote no entries until now".

In generally it is in the EU a necessity by law (GDPR) to be able to delete inactive accounts because you as a service provider are only allowed to store personal data that you need to run the service. If a user seems not to be interested in the use of the service (was not active in your forum since ages) he or she has the right towards the operator to have his or her personal data deleted.

If you run your forum in an EU country, you should take this into account.

The last backup is some weeks old, so by replaying it I would lose content.

I know which users were deleted wrongly, and I have all their data in my backup.
Therefore it should be possible to undelete my mistake.

Your database backup should be one flat text file (with the data of all tables) or a bunch of files (each with the data of one table), when created with the common methods. You can extract the INSERT-queries for the affected accounts from your latest backup and run the queries in phpMyAdmin (or a similar tool). That way you can restore the affected accounts only without interfering other tables or userdata.

That's, what you described below for the user data table.

I looked into the database and noticed two locations where some changes would have to be done:

First, the userdata table of course. I have to extract the userdata table from the dump, this can be done like described here: https://stackoverflow.com/questions/1013852/can-i-restore-a-single-table-from-a-full-mysql-mysqldump-file
From this table I could extract the ingredients for a SQL insert statement:

INSERT INTO userdata (user_id, user_type, user_name, user_real_name, ...) VALUES (123, 0, 'name_of_deleted_user', 'real name', ...);

and manually manipulate the userdata table. In total, I counted 38 single data items for one entry in the userdata table.
After that, the userdata table should be OK again.

Yes, this is correct if MySQL allows you to insert a record and specify the primary key (user_id) yourself. Other database systems do not allow this and it is quite possible that your MySQL server is configured in the same way. In this case, however, you will also receive a corresponding message from the SQL server. You then (and only then) have to remove the column user_id from the column list and the values from the corresponding value list.

INSERT INTO userdata (user_type, user_name, user_real_name, ...) VALUES (0, 'name_of_deleted_user', 'real name', ...);

For comparision with your query above. The column list would start with user_type and the column list with the corresponding value for this column (typically 0).

If this restriction is not configured you can run the queries as is.

Second, the 'entries' table has one data record for each posting. For the deleted users, the user_id field seems set to '0', and this should be set to the original value. Something like

UPDATE entries SET user_id = 123 WHERE name = 'name_of_deleted_user' 

should do the trick.

Is that correct or is there missing anything?

No, that's all if you need to reconnect the entries to the user accounts. If not, you will have entries of a not registered user with the same name as a registered user. That wouldn't be the end of the world either.

Tschö, Auge