If an encrypted table is created during backup, then mariabackup --backup could wrongly fail with messages like the following:

190103 15:26:32 [01] Copying ./test/t.ibd to /dev/shm/10.2/mysql-test/var/1/tmp/backup/test/t.ibd

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Database page corruption detected at page 1, retrying...

[01] mariabackup: Error: failed to read page after 10 retries. File ./test/t.ibd seems to be corrupted.

This is due to the way how InnoDB creates .ibd files. It would first write a dummy page 0 with no encryption information. Due to this, xb_fil_cur_open() could wrongly interpret that the table is not encrypted. Subsequently, page_is_corrupted() would compare the computed page checksum to the wrong checksum. (There are both "before" and "after" checksums for encrypted pages.)

This caused a failure of the test mariabackup.huge_lsn once on buildbot. A reduced version of the test repeats the problem more easily:

--source include/have_file_key_management.inc

CREATE TABLE t(i INT) ENGINE INNODB;

let $targetdir=$MYSQLTEST_VARDIR/tmp/backup;

--disable_result_log

exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir;

--enable_result_log

DROP TABLE t;

rmdir $targetdir;

To work around this problem, we will introduce a Boolean option --backup-encrypted that is enabled by default. With this option, Mariabackup will assume that a nonzero key_version implies that the page is encrypted. We need this option in order to be able to copy encrypted tables from MariaDB 10.1 or 10.2, because unencrypted pages that were originally created before MySQL 5.1.48 could contain nonzero garbage in the fields that were repurposed for encryption.

MDEV-18128 would clean up the way how .ibd files are created, to remove the need for this option.