IBM i backup performance is affected by many variables, and many data transfer rate bottlenecks can be very easy to resolve. Some simple changes you can try to improve backup performance may only require using the correct media generation for your tape library/drive, minimize resource sharing, shortening the distance between the IBM i PCIe I/O adapter and tape library/drive, using backup optimization settings or restructuring your backup processes. These minor changes are virtually free to try and may have a significant impact on optimizing your IBM i backup transfer rates and without having to spend a lot of time analyzing the root cause. Other factors affecting your backup transfer rates may require a deeper analysis of interfaces involved in the backup and restore processes, including the capabilities of the tape library/drive, I/O SAS adapter and other IBM i hardware components, LPAR configuration, directory structure, types workloads and sizes of files being backed up.
Using general IBM i backup performance test results and some key assumptions, here are some ways that may have the most significant impact on optimizing backup and recovery performance:
- Replace slow IBM i PCIe I/O adapters like the 5901 (57B3), EJ1P and EJ1N (57B3) 3 Gbps SAS Adapters with the faster EJ10 or EJ11 (57B4) 6 Gbps SAS Adapter, or ideally use a EN0A (577F) or EN0B 16GB Fiber Adapter or a 5735 8GB Fiber Adapter. Keep in mind, the length of the cable used to connect your tape library/device will also affect the data transfer rate performance.
- Use a Virtual Tape Library (VTL) that ingests backup data at disk speed, versus tape drive and media speeds. The maximum backup data transfer rates on some VTLs can be up to a blazing 4.5 GB/s (14.4 TB/hr), compared to LTO-9 708 MB/s, LTO-8 360 MB/s, LTO-7 315 MB/s, LTO-6 160 MB/s and LTO-5 140 MB/s. Most VTL’s support running many parallel backup streams simultaneously which can also significantly speed up backups.
- Other IBM i system resources that affect backup speeds include type and amount of HDD or SSD, memory, processing and PCI placement. For instance, if you have open bays available for adding more internal storage, this is a fairly cost effective solution.
- Use Concurrent Saves and Restores or Parallel Saves and Restores. Read IBM’s documentation on these topics. System resources will be a major factor in determining if you can utilize these options, as significant memory, processing and DASD can have a great impact on the backup window.
- Backup workloads with a mix of user or small to medium objects can benefit from concurrent saves, which allow multiple objects to be processed at the same time from different jobs, making better use of the backup devices and the system.
- Backup workloads with a large quantity of smaller blocks of data and only a few very large database files (library or directory), a combination concurrent and parallel might be helpful. For instance, backing up all of the smaller libraries/directories to one backup device, running a parallel save of the larger files to multiple different backup devices.
- Backup workloads with a significant amount of large files will likely need to use multiple backup devices in conjunction with the parallel save feature, while systems with only few very large files can be balanced over the backup devices and will likely be best served using concurrent saves.
- Systems that have drastic swings in library and directory sizes likely should not use concurrent saves and may likely benefit from the parallel function (depending on the size and number of objects).
- Save-while-active can be used with other backup jobs and will minimize downtime, however some save functions require no access or read only access to the objects as you are saving them.
- Large IFS backup performance can be significantly improved by using Asynchronous (ASYNCBRING) feature. In environments where a large number of objects reside in a single directory, few objects qualify for the save or the system is memory constrained, performance may degrade using ASYNCBRING. ASYNCBRING enables objects to be asynchronously brought into memory early so they will not need to be paged when first accessed by the SAV processing. The performance gain seen is dependent on the directory structure, number and size of objects saved, amount of memory available, and the system configuration.
It is important to understand; the root cause of poor backup performance involves identifying the slowest component in the very long chain of factors that contribute to the backup window. Your backups will only perform as fast as the slowest component. Tape backup performance is affected by many factors, some of which will be out of your control, like compressibility of data being backed up. You do however have control over some bottleneck factors that can considerably speed up backup transfer rates, such as the tape drive, tape media and interface type (IO adapter). For instance, using older generation LTO media than the LTO drive (LTO6 tapes with an LTO7 tape drive) will likely be slower for a combination of many reasons, including tape drive buffer, data compressibility and speed matching. A more common performance bottleneck is when a system is using a slower interface (IO adapter) such as 3 Gb or 6 Gb SAS, when 8 Gb or 16 Gb is capable of providing much faster throughput rates. The number of devices sharing the IO adapter may also be a significant factor impacting backup performance, as well as length of cable used (distance between IO adapter and tape drive) as stated in IBM’s documentation.
For more ideas and details on how to improve the performance of IBM i Backup & Recovery processes, read “IBM i V7R3 System Management Backing up your system”: https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaiu/rzaiupdf.pdf
