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.