Marko Mäkelä added a comment - 2025-03-11 13:57 Can you see if disabling the MDEV-30000 functionality in the backup command would help? That is, add --skip-innodb-log-checkpoint-now to the invocation?

Marko Mäkelä added a comment - 2025-03-11 14:11 I think that this needs to be debugged and the root cause analyzed on the Windows platform. My previous comment is not a suggested fix; it is only a first step of troubleshooting. We also have an open bug MDEV-36201 in this area, but I don’t think that it shares a root cause with this one.

Vladislav Vaintroub added a comment - 2025-03-11 14:20 marko , yes, the first step is to debug and such. And we have a Windows machine to do this debugging, by the same person who caused the break I'm here to help you with debug techniques, but not spend time on something that I have no clue of. In the past, I remember, files that were undersized were extended, then they were just ignored by mariabackup, but at some point it has changed, so I do not know why Innodb fails or even requires that files have some specific size.

Marko Mäkelä added a comment - 2025-03-11 15:38 I think that "caused by MDEV-30000 " is an incorrect claim. There is correlation, but not causation. This test has failed in the past too, not as frequently as now, but it has failed. Here is an example: 10.4 ee59ca7ff1620dd74b9bc1449878c5d1acee0f53 mariabackup.incremental_compressed 'innodb' w32 [ fail ] … 2024-04-26 18:58:30 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=69905 2024-04-26 18:58:30 0 [ERROR] InnoDB: The size of tablespace file 'test\t#p#p0.ibd' is only 32768, should be at least 65536! 2024-04-26 18:58:30 0 [Warning] InnoDB: We do not continue the crash recovery, because the table may become corrupt if we cannot apply the log records in the InnoDB log to it. To fix the problem and start mysqld: 2024-04-26 18:58:30 0 [Note] InnoDB: 1) If there is a permission problem in the file and mysqld cannot open the file, you should modify the permissions. 2024-04-26 18:58:30 0 [Note] InnoDB: 2) If the tablespace is not needed, or you can restore an older version from a backup, then you can remove the .ibd file, and use --innodb_force_recovery=1 to force startup without this file. 2024-04-26 18:58:30 0 [Note] InnoDB: 3) If the file system or the disk is broken, and you cannot remove the .ibd file, you can set --innodb_force_recovery. 2024-04-26 18:58:30 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error [00] FATAL ERROR: 2024-04-26 18:58:31 mariabackup: innodb_init() returned 11 (Generic error). mysqltest: At line 20: exec of 'D:\Buildbot\amd64-windows-packages\build\extra\mariabackup\RelWithDebInfo\mariabackup.exe --prepare --target-dir=D:/Buildbot/amd64-windows-packages/build/mysql-test/var/32/tmp/backup --incremental-dir=D:/Buildbot/amd64-windows-packages/build/mysql-test/var/32/tmp/backup_inc1 --user=root > D:/Buildbot/amd64-windows-packages/build/mysql-test/var/tmp/32/backup_prepare_1.log' failed, error: 1, status: 1, errno: 2 A possible fix would be to adjust the deferred tablespace recovery that was introduced when MDEV-24626 was implemented. But we need to reproduce this within a debugger first. I have seen this test failing on Microsoft Windows only, and I am not productive in that environment.

Vladislav Vaintroub added a comment - 2025-03-11 15:53 - edited Yes, it has failed in the past. I said that, too. in 10.4, a year ago. I'm unable to reproduce it locally though mtr --repeat=100 did not help ... mariabackup.incremental_compressed 'undo3' w2 [ 99 pass ] 9762 mariabackup.incremental_compressed 'undo3' w2 [ 100 pass ] 16080 -------------------------------------------------------------------------- The servers were restarted 0 times Completed: All 200 tests were successful.   Also, I'm not exactly productive on any other environments but Windows. If I have to, I fix on Linux, and FreeBSD, and even Solaris. AIX, when it has to be.