For an overview on backup compression, see Section 4.3.4, “Making a Compressed Backup”.
Create backup in compressed format. For a regular backup, among all the storage engines supported by MySQL, only data files of the InnoDB format are compressed, and they bear the
.ibzextension after the compression. Similarly, for a single-image backup, only data files of the InnoDB format inside the backup image are compressed. The binary log and relay log files are compressed and saved with the
.bzextension when being included in a compressed backup.
Default: compression is disabled.
Type Enumeration Default Value
Specifies the algorithm for backup compression, or enables support for InnoDB transparent page compression. The supported arguments for the option and the algorithms they represent are:
lz4: LZ4 r109. Out of the three compression algorithms that are supported, this is the most efficient one, typically taking the shortest backup and restore times with the lowest CPU cost. See lz4—Extremely Fast Compression algorithm for more details, including a comparison with other compression algorithms.
lzma: LZMA 9.20. Out of the three supported compression algorithms, this typically provides the highest compression ratio; but it is also far more expensive in terms of CPU cost than the other two options. Thus we do not recommend this for active systems, but only for off-hour or inactive database servers, or where I/O rates are extremely low.
zlib: ZLIB v1.2.3. This is in between the other two supported compression algorithms in terms of both speed and compression ratio. ZLIB was the only compression algorithm available for MySQL Enterprise Backup versions prior to 3.10.
punch-hole: ( Enables support for transparent page compression for InnoDB tables for directory backups, which means that when the target platform for the mysqlbackup backup or restore operation supports hole punching, mysqlbackup keeps the punched holes in the page-compressed InnoDB files it transfers.
Limitations: The feature is NOT supported in the following cases, for which punched holes are removed from the InnoDB files:
For single-file backups.
For TTS, incremental, compressed, or encrypted backups.
When a backup is not created in a file system (for example, when cloud storage is used to save the backup), or when the file system does not support sparse files.
For those pages of InnoDB data files that are modified by the redo log in an
When the feature is enabled but hole punching fails, mysqlbackup issues a warning message after the operation is completed; for example:
WARNING: "Punch hole" operation failed.
WARNING: InnoDB datafiles in the backup are larger than in the source because of missing sparse file support.
A backup can be taken with
--compress-method=punch-holeand then be restored later without using the feature; the reverse is also true: a backup taken without using
--compress-method=punch-holecan be restored later with the feature.
none: No compression.
Default: lz4. Explicitly specifying a value other than
punch-holefor the option through a configuration file or command line automatically enables the
Type Numeric Default Value
Specifies the level of compression, ranging from “0” to “9”: “0 ”disables compression; “1” is fastest compression, and “9” is highest (and slowest) compression. The option is only meaningful for compression using the ZLIB or LZMA algorithm; it is ignored when any other algorithms are selected by the
Default: 1 (lowest and fastest compression). Explicitly specifying a non-zero value through a configuration file or command line automatically enables the