In your backup strategy, performance and storage space are key aspects. You want the backup to complete quickly, with little CPU overhead on the database server. You also want the backup data to be compact, so you can keep multiple backups on hand to restore at a moment's notice. Transferring the backup data to a different system should be quick and convenient. All of these aspects are controlled by options of the mysqlbackup command.
Sometimes you must balance the different kinds of overhead -- CPU cycles, storage space, and network traffic. Always be aware how much time it takes to restore the data during planned maintenance or when disaster strikes. For example, here are factors to consider for some of the key MySQL Enterprise Backup features:
Incremental backups are faster than full backups, save storage space on the database server, and save on network traffic to transfer the backup data on a different server. Incremental backup requires additional processing to make the backup ready to restore, which you can perform on a different system to minimize CPU overhead on the database server.
Compressed backups save on storage space for InnoDB tables, and network traffic to transfer the backup data on a different server. They do impose more CPU overhead than uncompressed backups. During restore, you need the compressed and uncompressed data at the same time, so take into account this additional storage space and the time to uncompress the data.
In addition to compressing data within InnoDB tables, compressed backups also skip unused space within InnoDB tablespace files. Uncompressed backups include this unused space.
When space is limited, or you have a storage device such as tape that is cheap, large, but also slow, the performance and space considerations are different. Rather than aiming for the fastest possible backup, you want to avoid storing an intermediate copy of the backup data on the database server. MySQL Enterprise Backup can produce a single-file backup and stream that file directly to the other server or device. Since the backup data is never saved to the local system, you avoid the space overhead on the database server. You also avoid the performance overhead of saving a set of backup files and then bundling them into an archive for transport to another server or storage device. For details, see Section 18.104.22.168, “Streaming the Backup Data to Another Device or Server”.
When streaming backup data to tape, you typically do not compress the backup, because the CPU overhead on the database server to do the compression is more expensive than the additional storage space on the tape device. When streaming backup data to another server, you might compress on the original server or the destination server depending on which server has more spare CPU capacity and how much network traffic the compression could save. Or, you might leave the backup data uncompressed on the destination server so that it is ready to be restored on short notice.
For disaster recovery, when speed to restore the data is critical, you might prefer to have critical backup data already prepared and uncompressed, so that the restore operation involves as few steps as possible.
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
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.