Short Version: if you are running backups against a busy server, then YES.
If you lock the server from updates, ie is a slave and do
mysql -e "STOP SLAVE" before the backup, I suspect the xtrabackup_logfile would be empty and apply-log would do nothing.
There is a doc providing an example of making a backup and restoring it, as part of a howto on preparing a slave for replication, and that indicates that IT IS required to add a step to apply the logs before they are available for use;
innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir
innobackupex --user=yourDBuser --password=MaGiCdB1 /
The options page for innobackupex indicate that
--apply-log reads transactions from the
Prepare a backup in BACKUP-DIR by applying the transaction log file
named xtrabackup_logfile located in the same directory. Also, create
new transaction logs. The InnoDB configuration is read from the file
backup-my.cnf created by innobackupex when the backup was made.
I suspect that
xtrabackup_logfile contains the transactions during the period that the backup was running but the database was not locked. I think by this strategy that innobackupex can run with only a short lock time, and use the binlog to apply the updates to the backup retrospectively.
The xtrabackup-manager tool applies the log has a apply-log step in this file here;
Its not clear what format these files are (
file xtrabackup_logfile returns "data"), though they seem to be sparse on my system, but I don't expecting any pending transaction in this case because the backups are taken from a stopped slave. Though if you wanted to find out, the source code of xtrabackup is available for inspection.