Backup depends on the combined performance characteristics of the following entities:
Storage subsystem
File system
SMS
Backup application
Tape subsystem
You need to optimize each of these entities to ensure that they do not impact the throughput of the system.
For improved performance, it is necessary that all the components should meet the throughput requirements.
If backup is critical and a non-time consuming process, the disk subsystem should be configured to deliver high throughput. Doing parallel I/Os at the disk subsystem level improves the overall disk throughput, it helps the disk/RAID controllers to group the requests better, which reduces the overall seek time and improves the throughput as multiple heads are working at the same time. It is also important to ensure that components do not limit performance throughput delivered by other components.
Connecting Ultra320 disks to an Ultra160 controller or connecting both the Network and disk controllers to the same IO bus limits the backup performance.
Creating this parallelism through optimal configuration ranges from, setting up appropriate RAID levels to the load balancing of the multiple peer-to-peer buses at different levels, from SCSI to PCI. For details on optimizing the storage subsystem, see the respective hardware reference guides.
The file system performance tuning and networking parameters should be configured for improved performance. See the operating system documentation for more information on the system tunable parameters.
Backup and file compression operation should not be run simultaneously. For example, if the default time for both scheduled backup and restore sessions, and compression is midnight, set one of these defaults to different time. If you want to perform a delayed backup that includes files flagged for compression, schedule the delayed backup after the compression time to allow time for the compression to be completed.
Different types of files have different impacts on the backup performance. For example, backups are faster if compressed files are backed up in the same state. If volume compression is turned on and you back up compressed files in a decompressed state, restore speed is degraded when the existing files are overwritten. Compression is not supported in some environments (such as Novell Storage Services 2.0 volumes or ReiserFS). If you intend to restore a file that is currently compressed to an environment that does not support compression, back it up in a decompressed state.
Anti-virus software running at the time of backup significantly slows down the backup process due to checks made on each file access. Most anti-virus software provides options to either ignore backup applications accessing the file system or are tuned to validate modify or write operations alone during a backup process. Since backup is read-centric, the performance is improved significantly.
See the Managing Software RAID Devices
section in the OES 23.4: NSS File System Administration Guide for Linux for a detailed discussion on NSS tuning parameters.
SMS can be configured to optimally exploit the underlying subsystem capability by fine tuning its working parameters. For more information, see Section 5.3, Fine-Tuning SMS Performance.
Backup applications typically process and transfer data obtained from the SMS components to the tape sub-system. Backup applications employ different processing models which have different performance characteristics and features. Most backup applications provide parameters that can be used to optimize performance. For more information, see the respective backup application documentation.
The tape subsystem typically consists of the tape drivers, devices and media. It is important to consider the throughput of the device and employ appropriate devices based on the performance needs. In many cases, having a good disk subsystem and a poor tape subsystem limits backup performance. For more information, see the appropriate vendor documentation.