I just had to handle this.
Finding the backup
In my case, mysql lives in
/usr/local/mysql/ (where the last part is actually a symlink to the current installed version of mysql). It actually does correctly back up the files, and the whole structure exists on the backup.
But for some reason, even if you navigate to the correct local path in finder, if you run "Time Machine", it will show that no previous backup exists. Which thankfully is not true, unless you excluded it.
So, to recover your backup, you have to navigate to the respective path on your backup volume, which should be something like
/Volumes/<yourbackupvolume>/Backups.backupdb/<host>/<revision>/Macintosh HD/usr/local/mysql/data/. It's easiest in the Terminal. Once you
cd'd to the correct path you can use
open . to open a finder window in that path and use drag & drop. However Finder will probably ask you to take ownership of the folder first, so you'd have to fix the permissions afterwards.
Finding a stable backup
If you have mysql running constantly, you may still have a problem. As far as I know InnoDB is fairly resilient, but it is possible that the file structure is corrupted. MySQL ships with
mysqlcheck which supposedly can repair such tables..
I you don't, it's probably easier to find a backup where the modification date/time of all files in
data/ is (reasonably, say a few minutes) lower than the date/time of the backup. In this case you can be reasonably sure to have a consistent backup and mysql should start smoothly from it.
If for some reason your permissions do not work out after recovery, currently (OS X 10.10 / Yosemite) the permissions set by
sudo chown -R _mysql:admin /usr/local/mysql/data
worked great for me (MySQL runs as user
_mysql). Note that
mysqld will fail almost silently and will only try to create an error log file in
/usr/local/mysql/data/, which may also fail due to permissions.