In planning your backup strategy, you choose the balance between the overhead of performing the backup (CPU cycles, storage space, and network traffic), and the time needed to restore the data during planned maintenance or when disaster strikes. Using features such as incremental backups and compressed backups saves on storage space, and network traffic if you keep the backup data on a different server. Compression adds some CPU overhead to the backup process; incremental backup requires additional processing to make the backup ready to restore. For disaster recovery, when speed to restore the data is critical, you might prefer to have the backup data already prepared and uncompressed, so that the restore operation involves as few steps as possible.

When evaluating the performance of different backup techniques, put more emphasis on the speed of the restore operation than the speed of the initial backup. It is during a disaster recovery that speed is most critical. For example, although a logical backup performed with the mysqldump command might take about the same time as a physical backup with the MySQL Enterprise Backup product (at least for a small database), the MySQL Enterprise Backup restore operation is typically faster. Copying the actual data files back to the data directory skips the overhead of inserting rows and updating indexes that comes from replaying the SQL statements from mysqldump output.

To minimize any impact on server performance on Linux and Unix systems, MySQL Enterprise Backup writes the backup data without storing it in the operating system's disk cache, by using the posix_fadvise() system call. This technique minimizes any slowdown following the backup operation, by preserving the data blocks in the disk cache rather than filling up the cache with the output from the backup.