PURE OPERATIONAL STANDPOINT

You need to decide which protocol works best for you

PLAN A : AFTER DUMP

Run --apply-log immediately after backup, and you would have the most currently full backup. You would not have to spend your recovery time applying applying logs at the time of a restore (especially at an actual disaster recovery event). Thus, recovery would be only focus at such a dire time.

PLAN B : BEFORE RESTORE

This might work to your advantage if and only if you do not need the transactions that were accumulated after the point-in-time start of the backup. Such a situation would hardly make sense in a write-heavy environment.

Perhaps under these circumstances it would be better

• Scheduled downtime
• Small enough dataset
• Acceptable window of time to backup (short time)
• Additional backup of binary logs (extra insurance)

EPILOGUE

Whichever way one choose, make sure all the logs are good. If you apply the logs immediately, you'll know right then and there if the transaction logs are corrupt or not.

You also need to take into account how transaction-heavy the production system is. Why?

If the backup is recording incoming transactions as fast or faster than the backup process, then you have no choice but to go with PLAN B.

A quick 101 on Percona Xtrabackup:

Basically, what the tool does is copying the data live in an inconsistent way, but making sure it gets all the necessary changes that are happening at copy time, so it can revert it to a proper state. In other words, it does an "unclean full copy" and then a "controlled crash recovery" with a custom InnoDB instance. That is exactly why you need the two phases (the copy first and then the application of the log, where committed changes are reapplied and uncommitted changes are discarded).

That second part can be done on a different machine, without a database connection -that is why it is a separate command.

So you have two options: running the --apply-log as soon as the copy has ended or just before the restore.

• Advantages of the first case: your copy is 100% ready to be restored in case of an emergency (just --copy-back it). You can delete the saved transaction log as it is not needed any more.
• Its disadvantages: Once you have deleted the uncommitted changes, you cannot roll forward your full backup with following incrementals. Also, you will not be generating the extra information that may be needed for partial imports.

If you only intend to create in the future full backups and perform full restores, you can safely do it just after the copy finishes. If your apply-log phase is fast (or you do not care about the extra time and space of the transaction log) and you want to have extra flexibility (for partial/incremental backups), just wait until the start of the recovery.