How come mariabackup fails to restore in ubuntu and achieves it on fedora?

All we need is an easy explanation of the problem, so here it is.

I am unable to find the solution alone, so I decided to ask a question after two or three days of exeperimentation and research. I had a mysql (MariaDB) install on a server under Ubuntu 20.04 with a few databases (nextcloud, wordpress) and had a regular backup scheduled with mariabackup run as a cronjob.

I wanted to reinstalled the server recently so I made backups of everything manually, and copied to a remote location with rsync -avx backup_folder [email protected]:/backups and also on my own laptop (my tables aren’t that big). I then (after an upgrade failure) reinstalled the original setup with Ubuntu 20.04 and mariadb-server and mariabackup from the official repos, but when I run mariabackup --prepare --target-dir=/path/to/my/backup/ the procedure fails with output :

mariabackup based on MariaDB server 10.3.34-MariaDB debian-linux-gnu (x86_64)
[00] 2022-07-19 13:06:53 cd to /home/simon/db.bak/
[00] 2022-07-19 13:06:53 open files limit requested 0, set to 1024
[00] 2022-07-19 13:06:53 This target seems to be already prepared.
[00] 2022-07-19 13:06:53 mariabackup: using the following InnoDB configuration for recovery:
[00] 2022-07-19 13:06:53 innodb_data_home_dir = .
[00] 2022-07-19 13:06:53 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2022-07-19 13:06:53 innodb_log_group_home_dir = .
[00] 2022-07-19 13:06:53 InnoDB: Using Linux native AIO
[00] 2022-07-19 13:06:53 Starting InnoDB instance for recovery.
[00] 2022-07-19 13:06:53 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
2022-07-19 13:06:53 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-07-19 13:06:53 0 [Note] InnoDB: Uses event mutexes
2022-07-19 13:06:53 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-07-19 13:06:53 0 [Note] InnoDB: Number of pools: 1
2022-07-19 13:06:53 0 [Note] InnoDB: Using SSE2 crc32 instructions
2022-07-19 13:06:53 0 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
2022-07-19 13:06:53 0 [Note] InnoDB: Completed initialization of buffer pool
2022-07-19 13:06:53 0 [Note] InnoDB: page_cleaner coordinator priority: -20
2022-07-19 13:06:53 0 [ERROR] InnoDB: Invalid flags 0x15 in ./ibdata1
2022-07-19 13:06:53 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption
[00] FATAL ERROR: 2022-07-19 13:06:53 mariabackup: innodb_init() returned 39 (Data structure corruption).

Now what really surprises me, is that the same thing would happen on an Ubuntu 20.04 server virtual machine running on my laptop with kvm, but not on my laptop itself running Fedora 26 for which the output is a success :

mariabackup based on MariaDB server 10.5.16-MariaDB Linux (x86_64)
[00] 2022-07-19 15:07:24 cd to /home/sfouilleul/db.bak/
[00] 2022-07-19 15:07:24 open files limit requested 0, set to 1024
[00] 2022-07-19 15:07:24 This target seems to be already prepared.
[00] 2022-07-19 15:07:24 mariabackup: using the following InnoDB configuration for recovery:
[00] 2022-07-19 15:07:24 innodb_data_home_dir = .
[00] 2022-07-19 15:07:24 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2022-07-19 15:07:24 innodb_log_group_home_dir = .
[00] 2022-07-19 15:07:24 InnoDB: Using Linux native AIO
[00] 2022-07-19 15:07:24 Starting InnoDB instance for recovery.
[00] 2022-07-19 15:07:24 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
2022-07-19 15:07:24 0 [Note] InnoDB: Uses event mutexes
2022-07-19 15:07:24 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-07-19 15:07:24 0 [Note] InnoDB: Number of pools: 1
2022-07-19 15:07:24 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-07-19 15:07:24 0 [Note] InnoDB: Using Linux native AIO
2022-07-19 15:07:24 0 [Note] InnoDB: Initializing buffer pool, total size = 104857600, chunk size = 104857600
2022-07-19 15:07:24 0 [Note] InnoDB: Completed initialization of buffer pool
[00] 2022-07-19 15:07:24 Last binlog file , position 0
[00] 2022-07-19 15:07:24 completed OK!

I am stucked at the invalid flags 0x15 in the ibdata1 file because I don’t know exactly what this is, and absolutely not why it happens, and even less how to fix it.

I also tried to performe that mariabackup --prepare step on erlier database backups, but all failed in the same manner.

I was ultimately trying to convert my nextcloud database from mysql to postgresql so I could, maybe, import it in a Nextcloud AIO Docker setup. Needless to say that the conversion also failed, but that’s another topic.

If somebody could give me a hint of why this is happening…

Thanks to all of you!

How to solve :

I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.

Method 1

Awards to Rick James.

When I posted my question I actually saw the difference between versions (10.3 – 10.5) and I remember having updated MariaDB manually from its own repos and not ubuntu’s official. My bad… The restore fails on 10.3 and is a success in 10.5.

Thanks a lot, and sorry for that.

Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply