Percona XtraBackup moved to https://jira.percona.com/projects/PXB

Innobackupex remote and incremental backup

Asked by Jostein Martinsen

I made a full backup to a remote backup server.

Now I am trying to make an incremental backup, using the full backup. This doesn't work, since incremental-basedir asume the file xtrabackup_checkpoints are on the server with the database, not my backup server.

When I created the same folder structure on my database-server, as I had on the backup-server, and copied the file xtrabackup_checkpoints there, the file were read and parsed. Then incremental backup worked. But this is at least sub-optimal.

One would asume that using the option --remote-host, xtrabackup_checkpoints would be on the remote host.

Question information

Language:
English Edit question
Status:
Answered
For:
Percona XtraBackup moved to https://jira.percona.com/projects/PXB Edit question
Assignee:
Alexey Kopytov Edit question
Last query:
Last reply:
Revision history for this message
Alexey Kopytov (akopytov) said : 		#1

Jostein,

You can read to_lsn from xtrabackup_checkpoints and use its value as an argument to --incremental-lsn as described here: http://www.percona.com/doc/percona-xtrabackup/innobackupex/incremental_backups_innobackupex.html

Which is easier than recreating the directory structure and copying the entire file.

Revision history for this message
Jostein Martinsen (jostmart) said : 		#2

Yes I have checked out that option and I think that's the way to go.
Which lsn should I use, to_lsn or last_lsn?
This is with Percona MySQL 5.5 and /usr/bin/xtrabackup

backup_type = full-backuped
from_lsn = 0
to_lsn = 2326772795318
last_lsn = 2306487153664

Another strange thing, my incremental backup created 77G in my backup folder, and the full backup is 264G. Full backup were started: 2011-10-06_13-32-44 and incremental started: 2011-10-06_19-00-52. No way that much data have been changed. I ctrl-c terminated innobackup since I figured somethings wrong with my ibdata_log_file_size.

> ###Warning###: The copying transaction log migh be overtaken already by the target.
>> : Waiting log block no 262015578, but the bumber is already 272927154.
>> : If the number equals 262015578 + n * 20472, it should be overtaken already.
>> log scanned up to (2333175230976)
postdata.ibd

Revision history for this message
Alexey Kopytov (akopytov) said : 		#3

You should use to_lsn.

That message says that the redo log has wrapped around before xtrabackup could process it. The only solution is to increase innodb_log_file_size. In 1.7 this condition will lead to a backup failure with a bit more descriptive error message (see bug #805593).

Can you help with this problem?

Provide an answer of your own, or ask Jostein Martinsen for more information if necessary.

To post a message you must log in.