mariabackup restore corrupts InnoDB tablespace IDs

Restoring mariabackup backups into a different database on the same server where the backup was taken results in InnoDB tablespace ID corruption within the restored database.

All database and table names being used have been anonymized.

mariabackup backup command:

/usr/bin/stdbuf -o 10MB /bin/mariabackup --backup --slave-info --parallel=8 --user=root --target-dir=<backup dir>

The files are rsynced to a new directory so the backup can be reused.

mariabackup prepare command:

/usr/bin/mariabackup --prepare --export --target-dir=<new dir>

To do the restore, we perform the following actions:
1. The target database is dropped and recreated.

/usr/bin/mariadb-admin -f drop -h localhost our_database_staging --ssl

/usr/bin/mariadb-admin create -h localhost our_database_staging --ssl

2. The schema is recreated.

/usr/bin/mariadb-dump --routines --skip-triggers --no-create-info --no-data --no-create-db --skip-opt -h localhost our_database_production --ssl | /usr/bin/mariadb --force -h localhost our_database_staging --ssl

/usr/bin/mariadb-dump -C -d --skip-lock-tables -h localhost our_database_production --ssl | /usr/bin/mariadb --force -h localhost our_database_staging --ssl

3. The tablespaces are discarded using a SQL file with an `ALTER TABLE ... DISCARD TABLESPACE;` line for each table.

/usr/bin/mariadb -f -h localhost our_database_staging --ssl < /tmp/mariabackup-restore/discard_tablespace.sql

4. All of the prepared backup files (*.idb, *.cfg, *.frm) are put into place with rsync.

rsync -ogrvt /source/restore-prep/base/our_database_production/ /var/lib/mysql/our_database_staging/

5. The tablespaces are then imported using one file per table each containing the relevant `ALTER TABLE ... IMPORT TABLESPACE;` line. https://mariadb.com/kb/en/innodb-file-per-table-tablespaces/#importing-transportable-tablespaces-for-non-partitioned-tables

/usr/bin/mariadb -f -h localhost our_database_staging --ssl < /tmp/mariabackup-restore/import_tablespace-table_one.sql

/usr/bin/mariadb -f -h localhost our_database_staging --ssl < /tmp/mariabackup-restore/import_tablespace-table_two.sql

/usr/bin/mariadb -f -h localhost our_database_staging --ssl < /tmp/mariabackup-restore/import_tablespace-table_three.sql

...

/usr/bin/mariadb -f -h localhost our_database_staging --ssl < /tmp/mariabackup-restore/import_tablespace-final_table.sql

No errors are reported during the backup, prepare or restore.

No errors are reported by `mariadb-check our_database_staging`; however, errors do show up in the journal (see mariadb-check.txt and mariadb_2024-02-27.txt, trimmed for size and modified to hide database/table names). Example errror: `[ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=3418816455, page number=34359], should be [page id: space=185601, page number=34359]`

Querying `SELECT * FROM information_schema.INNODB_SYS_TABLES where name like 'our_database_staging/%';` shows the same tablespace IDs as the "should be" information reported in the journal.