Thanks for report, I reported it there
https://bugs.launchpad.net/percona-xtrabackup/+bug/346197

…
innodb_data_home_dir = /var/lib/mysql
innodb_log_group_home_dir = /var/lib/mysql
…

#>innobackupex-1.5.1 –databases=saturn –user=root –password=******* –slave-info /tmp

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.
All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackup
prints “innobackup completed OK!”.

innobackupex: Using mysql Ver 14.14 Distrib 5.1.31, for unknown-linux-gnu (x86_64) using readline 5.1
innobackupex: Using mysql server version 5.1.31-percona-log

innobackupex: Created backup directory /tmp/2009-03-21_00-40-56
090321 00:40:56 innobackupex: Starting mysql with options: –unbuffered –password=****** –user=root
090321 00:40:56 innobackupex: Connected to database with mysql child process (pid=32443)
090321 00:41:00 innobackupex: Connection to database server closed

090321 00:41:00 innobackupex: Starting ibbackup with command: xtrabackup –backup –suspend-at-end –target-dir=/tmp/2009-03-21_00-40-56
innobackupex: Waiting for ibbackup (pid=32450) to suspend
innobackupex: Suspend file ‘/tmp/2009-03-21_00-40-56/xtrabackup_suspended’

xtrabackup Ver alpha-0.3 for 5.0.77 unknown-linux-gnu (x86_64)
>> log scanned up to (34 1558149409)
090321 0:41:00 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: File name /tmp/2009-03-21_00-40-56/var/lib/mysql/ibdata1
InnoDB: File operation call: ‘open’.
InnoDB: Cannot continue operation.
innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex-1.5.1 line 427.

There is xtrabackup_binlog_info which contains binary log position corresponding to time of backup.
To do “point in time” recovery you should start from this position.

Yes, in incremental backup we will copy only pages with LSN greater then in full backup.
We do backup undo buffer, it is located in ibdata1 system table space, there is also insert buffer.

There is no easy way to say how many pages changed since LSN ‘x’ – only to scan all pages on disk.

thanks for the info. In that case, the inremental backup would be those pages for which the LSN is larger then the one recorded in the full backup, right?
How do you manage pages which contain uncommitted data? That is, tx#1 started, tx#2 started and committed, and due to dirty pages percent (or other reason), the page for tx#2 was flushed, along with the changes in tx#1.
Do you also backup the undo buffer, then?

It’s also interesting to estimate the percent of pages which will change between incremental backups. Is there some way to ask InnoDB how many pages have LSN greater than “x”?

Our ideas come from real practical usage, that’s why we do it to cover practical needs.

Incremental backup are not finished yet, you can’t use it in current version.

You are right – we are reading internal ibdata. There is such thing as LSN (Log Sequence Number) and each page has it, so basically we can retrieve only pages that older than given LSN.