source Win64 dest RHEL 8

Also attempted this on version 10.4.22 on Windows and it still does not create the xtrabackup_backupfiles folder when creating the backup or when preparing the backup.

Hello, I was able to finally get mariabackup to actually do something by using:

mariabackup --prepare --target-dir=.
mariabackup --copy-back --target-dir=.

It copies all of the files over to /var/lib/mysql when I do this but when I start mariaDB it says:

[ERROR] InnoDB: corrupted TRX_NO 62f900540074096f
[Note] InnoDB: Retry with innodb_force_recovery=5

I think this might be another bug.

Do you guys need more information or has there been any update on this?

Can I pay someone to look at this? or what is happening with this bug report?

Hello, thank you for reviewing the report.

Do the changes Sergei has made mean that it is fixed now or that it will be fixed in the versions listed?

Also is there any work around to get replication to work between Windows and Linux?

ZCT, the target-dir is the directory where backup is, or where it needs to be created by --backup mode . It is needed by all of mariabackup modes (backup, prepare, copy-back).

If it is not set, the default value is xtrabackup_backupfiles in current directory.

I hope this answers your original question. For your followup questions, that do not have anything in common with the original one (except obviously the reporter), it is better to create a new bug.

I am pretty disappointed that it took 7 months to get this looked at and nobody really even bothered to read the bug report. If there is not a bug why are these errors:

2021-12-22 11:21:28 0 [ERROR] InnoDB: Operating system error number 2 in a file operation.
2021-12-22 11:21:28 0 [ERROR] InnoDB: The error means the system cannot find the path specified.
[01] 2021-12-22 11:21:28 error: cannot open file ibdata1
[01] 2021-12-22 11:21:28 Error: copy_file() failed.

thrown after moving the data to the target host and running this command:

mariabackup --copy-back --target-dir=/var/lib/mysql

Did you actually test anything? I spent about three weeks trying to get this to work and it still does not work.

ZCT, let me clarify something.
You create a bug report where you complain about "mariabackup restore looking for folder that doesn't exist". I closed it with the explanation that you need to use --target-dir parameter whenever you uzse mariabackup with --backup, --prepare , or --copy-back. And the original synopsis of this report is classified as "Not a bug" therefore. mariabackup needs to look for backup in some folder, and if you do not say in which, it will try its default, and it is not guaranteed to exist.

The followup questions you asked do not have anything to do with your original question, except obviously, the reporter. We do not use a single bug report as a dialog, to report all of reporters troubles in comments section. Instead, we use one unique problem - one MDEV( bug report) approach. I tried to point this out in the last comment and it seems I did not succeed. It might be disappoiting for you, and we're sorry to hear that, but this approach to bug reporting is ubiquitious, and frankly, I have not seen alternatives yet. So, could you please create a new report (with "how to reproduce") about another problem that you have. Thank you.

To answer "did you test", yes, there is automated test suite for mariabackup which is done on each push into github. It does cover backup, prepare and copy-back. It does not cover cross-plattform backups.

Okay this bug report was about cross platform backup/restore to prepare for replication. So if you didnt test then I dont know how you came to the conclusion that there was no bug.

This report was about "mariabackup restore looking for folder that doesn't exist", that is still the name of this bug. Maybe there is some bug somewhere, bug that (Can't my_setwd /mbkagain/mbk/xtrabackup_backupfiles/) is not a bug.