The basic idea is not a bad one, but it has problems as discussed in another email chain. Here are some of my current thoughts on implementing this idea and will need buy in from EMT due to the amount of time it might take to fully implement this and make is production ready up to current XtraBackup standards.

Disabling checkpointing makes this a not-so-hot backup solution and has several potential drawbacks:
1) If backing up a very large data set (we have seen InnoDB backups that run for days) and checkpointing is disabled that entire time, the first checkpoint after re-enabling will be extremely painful and have a definite impact on client performance.
2) If backing up a very large data set, the recovery log can grow to extreme size, possibly causing disk pressure. Since this implementation copies the recovery log under FTWRL after the file copy, it can cause severe server stall if it is large.
3) If a crash in the server were to happen with checkpoint disabled and a large recovery log, recovery can take an extreme amount of time.
4) If a crash in XtraBackup were to happen after checkpoints are disabled, they will remain disabled until someone notices and re-enables them.
5) PerconaFT _will_ continue to write to data files with checkpointing disabled as cache pressure evicts dirty nodes (existing node copies will not be overwritten), what will not happen though is the block header map rotation. For an excessively long backup, this can cause the TokuDB data files to grow to over 2x the actual needed disk size due to having two copies of the nodes within the data files.
6) XtraBackup does page level validation (checksumming) during the backup, this patch does no such thing for TokuDB and possibly should.

Some of these can be made less painful:
1) Not much can be done to address this, checkpointing in general needs to be made fuzzy and not sharp.
2) Copy the recovery log in parallel with the backup similar to how InnoDB REDO log is copied and finalize the copy only under FTWRL.
3) Nothing can be done to address this.
4) Work on the server to re-enable checkpointing when a session disconnects if that session disabled checkpoints, perhaps use some bakup specific semantics for this instead of the current simple global option.
5) Nothing can be done to address this.
6) Can be implemented with some effort.


Things that also need consideration for a proper production ready implementation:
1) XtraBackup would need to go to the lengths to validate that TokuDB is installed and the plugin running before enabling the TokuDB portion of the backup functionality.
2) Incrementals have to be handled, either disallowing them if TokuDB is enabled and running and maybe adding a new option to bypass this (--incremental-innodb-only or something), or giving some kind of strong warning, or just skipping TokuDB. Whatever is chosen would need documented very well, and we know that users don't read documentation and might be surprised if they did a successful incremental backup of an InnoDB + TokuDB server but restored only to find that the TokuDB was not part of the incremental. This is a can of worms.
3) Compression and encryption, does it make sense for a user to compress TokuDB if TokuDB tables are compressed? This will just burn CPU and possibly result in larger backup than the original data.
4) Restoration, since TokuDB would not support incrementals, the --apply-logs-only would have no effect, but --apply-logs might still be useful to fully replay recovery logs in staging before dropping in to live server.
5) --copy-back functionality needs extending to TokuDB, but it might already 'just work'.

There will definitely be other things that come up where some XB specific InnoDB feature is incompatible with TokuDB that will need addressing.