Comment 15 for bug 1177206

I think the root cause here is that xb_data_files_init() (i.e. loading tablespaces into fil_system) is performed before log copying is started.

Consider the following scenario:

When the full backup is started:

- the server starts to execute CREATE/ALTER TABLE
- xb_data_files_init() is called from xtrabackup_backup_func()
- if the file for the newly created tablespace already exists (i.e. is seen by fil_load_single_tablespaces()), but the first page has not been initialized/flushed yet, xtrabackup complains about tablespace ID being nonsensical and omits the table from the full backup
- the server writes MLOG_FILE_CREATE (and possibly other records corresponding to that tablespace) to the log and performs a checkpoint
- xtrabackup starts copying the log later in xtrabackup_backup_func(), so it will not write MLOG_FILE_CREATE to xtrabackup_logfile

When the incremental backup is started:

- if the corresponding page updates in the tablespace have not been flushed yet, we generate an empty delta for it
- and copy the corresponding updates to the incremental log file

When the full backup is prepared:

- we ignore all possible log records corresponding to the tablespace, because it doesn't exist (and there's no MLOG_FILE_CREATE in the log, so it is not created on prepare)

When the incremental backup is applied:

- xb_delta_open_matching_space() creates a new tablespace assuming the table was created between the full and incremental backups
- xtrabackup then starts to apply log records to uninitialized pages