I'm using Percona's innobackupex/xtrabackup tools to maintain backups of some innodb only mysql instances.
I've run into a situation where it seems after I do an initial restore the act of applying the logs of an incremental to a seed to be restored mutates the incrementals xtrabackup_logfile, rendering it useless for future restore attempts. Attempts to do so result in innodb complaining about data being corrupted.
My process is to first copy the initial full to a staging directory to apply the incrementals to (so I don't over write the state of my full in the event I want to do a future restore).
It's something like this
- rsync -av $FULL_DIR $STAGING_FULL_DIR
- innobackupex --defaults-file=$STAGING_FULL_DIR/backup-my.cnf --ibbackup=xtrabackup_55 --apply-log --redo-only --incremental-dir=$INCREMENTAL1_DIR $STAGING_FULL_DIR
After this the xtrabackup_logfile in $INCREMENTAL1_DIR is mutated. Diffing the results of before and after with od it's quite a bit of change.
Is this completely expected behavior? It seems silly that the act of restoring backups makes them unrestorable in the future or you need to first make an entire copy of all fulls plus incrementals before proceeding.
I suppose I could make the restore process make a copy of $INCREMENTAL1_DIR/xtrabackup_logfile to "restore" to the original backup since it looks like that's all that changes. Still that seems hacky and like I'm doing something wrong.
