Restore fails from collation utf8mb4_0900_ai_c

MySQL & MariaDB Percona XtraBackup
1

I created a backup with mysql 8.0.32 Debian Buster. Upon trying to restore it with the latest 8.0.36 it said the utf8mb4_0900_ai_ci collate had an issue.

I find the 8.0.32 debian buster files and get it installed and same issue. Here is complete error message

2024-07-03T19:23:15.764818Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.32-24) starting as process 15324
2024-07-03T19:23:15.771149Z 0 [Warning] [MY-010075] [Server] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: b253fc97-3971-11ef-a7ab-00155d668c2f.
2024-07-03T19:23:15.782701Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-07-03T19:23:16.225657Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-07-03T19:23:16.226561Z 1 [ERROR] [MY-013178] [Server] Execution of server-side SQL statement 'CREATE SCHEMA mysql DEFAULT COLLATE utf8mb4_0900_ai_ci' failed with error code = 1049, error message = 'System schema directory does not exist.'.
2024-07-03T19:23:16.226714Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2024-07-03T19:23:16.226730Z 0 [ERROR] [MY-010119] [Server] Aborting
2024-07-03T19:23:17.311047Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.32-24)  Percona Server (GPL), Release '24', Revision 'e5c6e9d2'.
2024-07-03T19:23:17.398290Z mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended with return value of 1

What is the solution? How can I force the collation even if it means corrupting text, or how can I install another collation? I also installed 8.0.0.19 which is what I had before but it says it cant restore a backup from 80032

2

Figured out the issue.

The backup was located in /data/backup/restore but I used target-dir=/data/backup/ when decompressing/preparing. So there were .qp files in the database folders so when attempting to start Mysql it gave this error.

I would recommend that target-dir has more error checking to confirm its the right folder, as I have seen others get confused thinking its where files will be decompressed to (instead of location of the backup) and in my case I accidentally used 1 directory up but it didn’t throw an error because it went inside the folder and decompressed .qp files in /data/backup/restore but not /data/backup/restore/mysql/ and other databases.