Linux 4.19.121-gentoo x86_64 AMD Opteron(tm) 6376

euglorg, sorry, I had missed this report.

If you start up the server on the prepared backup, will the table be accessible and would CHECK TABLE report any errors?

If some DDL operation was run on the table while the backup had been created, the failure could be related to that. While Mariabackup already since version 10.2 should not have much trouble with concurrent DDL, DDL operations in the MariaDB Server itself are not crash-safe before version 10.6.

>>> Needs Feedback -> Closed

After paying no attention on the issue for almost two years, you close it as you didn't get a feedback within a month. Brilliant!
Just wonder how many other problems were closed in very same way... Wish people deciding to use mariadb features find this case before they get into the a trouble and think twice before using them...

Now, some facts about the case.
First, the problem is still there, as you guess. Tried to prepare a backup in the very same way it was described initially. The ordinary backup-restore took 12 hours on partial dataset (yes, the database was huge and contained partitions). An attempt to prepare a test-bench with mariabackup ended in 3 weeks when the server was rebooted. Say, there was no reason to wait more as partitioned data retention period is one week while backup preparation took over 3 weeks and didn't finish...
For tiny unpartitioned tables with low server load a procedure of taking a backup, preparing it and restoring it back worked - exactly as it was written in documentation, that's true. But it's usually not a big deal to restore such a database from mysqldump-generated files.
And for the server with a databases of over 100GB of size per database, having partitions and intensively used - an attempt to restore several databases with mariabackup renders in just wasting a time. An attempt to use files that were partially exported when mariabackup was stopped before it finished rendered into mysqld crash on 10.4 - not tested on 10.5, however.

So, in fact mariabackup can't be used for restoring single database from the dataset, the procedure is extremely unreliable. This is practical side of this task resolution.

For those who will find this task later: please consider the fact of necessity for restoring from mysqldump files (with long index creation that can take hours) or necessity of whole dataset replacement in case you would like to rely on mariabackup. For whole dataset mariabackup works perfectly, but for per-database backups this tool can't be used due to the reason mentioned in this task caption.

euglorg, thank you for the feedback.

Did you try to specify --use-memory? With a small buffer pool, applying the log will take a long time, and it might actually never finish due to some bugs, such as MDEV-26784.

If you are already assigning a reasonable amount of buffer pool to have the logs applied and it still is slow, could you provide some output of sudo perf top -p $(pgrep mariabackup) to show where the time is being spent?

Note: I expect MDEV-12353 in MariaDB Server 10.5 to speed up the restoring of backups. Before that log format change, the log record parser frequently invoked malloc().

Hello Marko,

We didn't use "--use-memory" option due to MDEV-20679 and MDEV-21222 initially.
This time the command was used without any changes. Will try to check with forced pool size later and let you know (while we'd like to better upgrade to 10.5, we ran into another issue, namely, MDEV-27530 and have had to roll back, so 10.4 will be available for tests for some time).

elenst can I ask you to keep this task open (mean, not close it) for some more time? Due to the war that started recently by russia against Ukraine, all the plans are ruined.

euglorg, please check the advice that I posted in MDEV-27530.

euglorg, I'm going to close it again. Please, just add a comment whenever you want us to reopen it and we'll do that.