Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.6, 10.11, 11.4, 10.5.27, 11.8
-
None
-
Rocky Linux 9.6
-
Can result in data loss
Description
I am using mariabackup to create full and incremental backups of a single database schema on a server. E.g. I backup with the the flag --databases="apps" . I follow the instructions for recovering a single transportable innodb table, and everything seems to work as documented. The general steps I use to recover a table are
First apply-log and --export to prepare the directory for a restore, then:
mariadb> SET sql_log_bin=0; --commands DO NOT extend to working on a slave.
mariadb> ALTER TABLE apps.properties discard tablespace
root-> cp /db_backups/apps/work/P_2025_12_04-21_02_55/apps/properties.ibd /db_backups/apps/work/P_2025_12_04-21_02_55/apps/properties.cfg /dbase/rchqsim13/data/apps/
root-> chown mysql:mysql /dbase/rchqsim13/data/apps//properties.ibd /dbase/rchqsim13/data/apps//properties.cfg
mariadb> ALTER TABLE apps.properties import tablespace
I run this on a running database, and it seems to restore the table as desired.
What is odd, is on the very next scheduled full backup, the "properties.ibd" file does not get backed up as part of the backup process. All other table ibd files are there as expected.
The only message I see in the output of mariadbbackup is:
"[00] 2025-12-04 20:46:57 DDL tracking : delete 372 "./apps/properties.ibd"
otherwise the rest of the backup logs look as normal.
Things I tried but didn't alter the behavior:
- confirmed permissions on the properties.ibd file
- flush the tables
- flush the tables for export
- confirm no table locks, and 'unlock tables' to be sure.
- I tried running mariabackup with the -locks arg.
There are no other alters or updates going on to properties table other than the above.
The only thing that enables the properties.ibd file to be backed up again by mariabackup is to restart the mariadb instance. The the backup works as expected.