Skip to content
Percona Software for MySQL Documentation

Rate this page
☆ ☆ ☆ ☆ ☆
Thanks for your feedback
Thank you! The feedback has been submitted.

Get free database assistance or contact our experts for personalized support.

Get help from Percona

Throttling backups

xtrabackup does not block database activity during a backup, but xtrabackup generates additional disk input/output (I/O) activity. On systems with limited I/O capacity, this can affect database performance.

Use the --throttle option to limit the backup rate.

How throttling works

Use the --throttle option to minimize backup impact on system performance. By limiting the number of 10 MB chunks processed per second, you primarily limit data throughput, which in turn reduces overall I/O pressure on the system.

When used with the --backup option, --throttle limits the rate of read and write operations performed during the copy process. For incremental backups, the limit applies only to read operations.

For example:

  • --throttle=1 limits processing to approximately 10 MB/s
  • --throttle=10 limits processing to approximately 100 MB/s

By default, throttling is disabled, and xtrabackup runs at the maximum rate permitted by the system.

On write-heavy systems, overly aggressive throttling can cause backups to fall behind redo log generation, see Redo log wraparound risk.

When to use throttling

Use the --throttle option in the following scenarios:

  • High-traffic production systems
    On latency-sensitive workloads, unthrottled backups can cause I/O contention. This can increase query latency as the database waits for disk operations to complete.

  • Limited storage throughput (cloud environments)
    On platforms such as AWS with provisioned IOPS or burst limits (for example, EBS volumes), unthrottled backups can exceed available I/O capacity. This may degrade overall system performance when limits are reached.

  • Systems with slower storage
    On HDDs or lower-performance SSDs, higher latency and seek times limit the number of concurrent I/O operations. Throttling prevents backups from saturating the storage subsystem.

  • Multi-tenant or co-located environments
    When multiple services share the same host, unthrottled backups can consume available I/O bandwidth and affect other applications.

Resource monitoring: finding your baseline

Before setting a throttle value, understand your storage subsystem limits. If your disk is already near saturation, an unthrottled backup can introduce significant I/O wait and increase query latency.

Use the following tools to observe disk utilization and validate your throttle settings.

iostat (sysstat)

Use:

iostat -xz 1

Key metrics:

  • aqu-sz - average queue size, a better indicator of saturation. Values consistently above 1 suggest the device cannot keep up with demand.

  • await — average time (ms) for I/O requests. Increasing values during backup indicate growing latency.

  • %util — indicates how busy the device is (time spent servicing I/O), not saturation. A device can show 100% utilization and still have spare capacity.

pidstat (sysstat)

Use pidstat to monitor per-process I/O activity.

Note

pidstat requires root privileges (or appropriate capabilities) to display system-wide I/O activity. Without this, output may be incomplete.

pidstat -d 1

Key notes:

  • Shows read/write throughput per process (including xtrabackup and mysqld).

  • Helps distinguish I/O generated by xtrabackup from that of the MySQL server.

  • Commonly available as part of the sysstat package.

  • When run without elevated privileges, it only shows processes owned by the current user.

pv (Pipe Viewer)

For streaming backups, pv can display real-time throughput:

xtrabackup --backup --throttle=5 --stream=xbstream \
  | pv \
  | gzip > backup.xb.gz

This helps verify whether the effective throughput matches the configured throttle, although compression (gzip) may become a bottleneck on CPU-constrained systems.

Configuration guidelines

Select a throttle value based on available I/O capacity and workload requirements. Use the insights from resource monitoring to select and refine an appropriate throttle value.

Typical starting points:

  • Busy systems: --throttle=1–5

  • Moderate load: --throttle=5–20

  • Dedicated backup window: no throttling

Note

If the throttle value is too low, the backup may not keep up with the rate of transaction log generation and may not complete.

Adjust the value based on observed system performance.

Redo log wraparound risk (important)

When using --throttle, backups may become too slow to keep up with redo log generation rate on busy systems.

Because the InnoDB redo log is a circular buffer with limited size, it can wrap around before xtrabackup has finished reading it. When this happens, the backup fails with an error similar to:

xtrabackup: error: expected log block no. ..., but got no. ...
xtrabackup: error: it looks like InnoDB log has wrapped around before xtrabackup could process all records
xtrabackup: Error: xtrabackup_copy_logfile() failed

This issue is more likely on write-heavy systems or when using very low throttle values.

There are two primary ways to prevent this issue:

SET GLOBAL innodb_redo_log_capacity = <larger value>;

Increasing redo log size:

  • Reduces the risk of wraparound during throttled backups.

  • Improves write performance under heavy load.

  • May increase crash recovery time.

Option 2: Prevent redo log wraparound

Use the --register-redo-log-consumer option to prevent redo log wraparound by coordinating with the server.

However:

  • It can block or significantly delay write operations if xtrabackup cannot keep up.

  • It is best suited for replicas, where replication lag is acceptable.

Advanced tuning scenarios

On high-performance storage (for example, NVMe), consider using higher --parallel values (4–8) with little or no throttling.

On shared or limited environments (such as cloud volumes):

  • Identify your provisioned IOPS or throughput limits.

  • Start with approximately 50% of available I/O capacity, then adjust based on observed latency and workload behavior.

  • Use moderate --parallel values (2–4) to ensure consistent utilization without overwhelming the system.

Interaction with –parallel

The --throttle and --parallel options control different aspects of backup performance and can be used together. If --parallel is set too high without adjusting --throttle, threads may compete for the limited throughput, reducing efficiency.

How they work together

  • --throttle sets a global limit on backup throughput.
  • --parallel controls the number of worker threads copying data.

If both are used:

  • All threads share the same throttle limit.
  • Increasing --parallel does not increase total throughput beyond the throttle limit.

For example:

  • --throttle=10 (approximately 100 MB/s total)
  • --parallel=4

Each thread will average approximately 25 MB/s to stay within the global limit.

Why use both

Using both options allows you to:

  • Improve efficiency when backing up many small tables (via parallelism)
  • Control overall I/O impact (via throttling)

This is especially useful on systems with mixed workloads.

Example usage

A) Streaming backup with throttling

Limit the backup speed to approximately 50 MB/s:

xtrabackup --backup --throttle=5 --stream=xbstream \
  | pv \
  | gzip > backup.xb.gz

B) Testing throttling behavior

To measure the effective throughput of --throttle without interference from compression or disk writes:

xtrabackup --backup --throttle=2 --stream=xbstream 2>/dev/null \
  | pv \
  | cat > /dev/null

This setup ensures:

  • No disk write bottleneck

  • No CPU bottleneck from compression

  • Clean pv output (stderr from xtrabackup is suppressed)

Use this method to validate that the configured throttle produces the expected throughput.

Local backup with throttling

Limit the backup to approximately 100 MB/s:

xtrabackup --backup --target-dir=/backups/full --throttle=10
Expected output 
xtrabackup: Starting backup
xtrabackup: Throttling set to 10 chunks per second
...
xtrabackup: completed OK!

Incremental backup with throttling

For incremental backups, the limit applies only to read operations. Redo log copying continues independently and may become a bottleneck if the backup is throttled too aggressively.

xtrabackup \
  --backup \
  --target-dir=/backups/inc1 \
  --incremental-basedir=/backups/full \
  --throttle=5
Expected output 
xtrabackup: Starting incremental backup
xtrabackup: Throttling set to 5 chunks per second
...
xtrabackup: completed OK!