The main aim of the performance recommendations is to decrease the backup time for logical data backup with HSMS. When the backed-up data is reconstructed, somewhat different throughput rates apply than for data backup. However, they are usually only critical if a full backup is to be loaded. With partial restoration, which runs in parallel with normal operation, the throughput plays a subordinate role.
The recommendations presented can be used individually and independently of each other. They are a,ways beneficial in all situations.
It is not possible to specify the improvement in performance for each recommendation precisely. The general situation and usage type (e.g. file size) must be taken into consideration. The throughput can be significantly lower with a large number of small files than in the ideal case with a small number of very large files.
Limiting the scope of the backup through file selection and the incremental process
Using the FROM-/EXCEPT-FILE parameters (positive and negative specification with partial qualification) is recommended.
A maximum backup class can be predefined: only files whose class is less than or equal to the specified backup class are saved (as a file attribute with the default backup class = A).
Temporary files and paging files are never saved.
Management classes in SM pubsets (freely definable file attribute for group formation in SM pubsets) can be used for file selection when backup and migration take place.
You can select whether migrated files should also be backed up (backup operand SAVE-DATA). By default only catalog entries of migrated files are also backed up.
Two processes are available for incremental backups between the periodical full backups:
MODIFIED: Save files only when these do not already exist in the archive
BY-CATALOG-MODIFICATION: Save files if these were modified only after a specified date or after the date of the last backup for the same archive
Decentralized organization (archives per pubset) also for large SF pubsets
Reducing the backup time through parallel I/Os (increased I/O load!)
HSMS enables multiple jobs to be performed in parallel. The degree of parallelism can be specified by the number of HSMS server tasks.
In turn, parallel data streams (to multiple tape devices) can be used in a job. This is controlled using the PARALLEL-RUNS operand in the action statement or an archive attribute. Under ARCHIVE this is controlled using the DRIVES operand in the SAVE statement.
The cartridges with a high capacity should always use the Several-SVID-Format for continuing (CONTINUE) tapes. This is practically a prerequisite for parallel operation, otherwise the tape consumption is high.
Increasing parallel operation reduces the runtime, and the number of inputs/outputs per second is increased.When a large number of tape devices are used (e.g. with ETERNUS CS), these can be used in parallel by HSMS/ARCHIVE.
Backup jobs which relate to the same archive directory or same HSMS archive cannot run in parallel.
Increasing throughput of disks and tapes
Using large tape blocks increases the performance and tape utilization. By default, 256 KB tape blocks are used when saving to tape cartridge using HSMS and ARCHIVE. To permit this, the parameter BLOCK-SIZE-T-C is predefined to the value BIG in the ARCHIVE parameter file. It may then be necessary to specify BLOCKING-FACTOR=*STD / *MAX in the HSMS statements and archive definitions.
LTO drives are always written to using a block size of 256 KB irrespective of predefined parameters and archive definitions.HSMS/ARCHIVE places an additional load on the disk side through catalog and file accesses (e.g. to the HSMS or ARCHIVE directory) and the fragmentation of small files.
To reduce this load as far as possible, PLAM libraries should be used instead of a large number of small files.
In the case of ARCHIVE RESTORE, the files are deleted on the disk before being rewritten, and then created anew (SPACE=REORG parameter). If no reorganization of the disk is required, the SPACE=KEEP parameter must be specified for RESTORE. This causes the files on the disk area to be overwritten, and the number of catalog operations and the number of IOs compared to the default setting are reduced.
Multiplexing with PAV (/390 servers)
HSMS/ARCHIVE generates asynchronous I/O operations These are executed in parallel when the storage system’s Parallel Access Volume (PAV, 390 server) function is used together with a suitable RAID level (see "RAID levels and their performance").
Reducing the downtime for online operation (application restart before the end of the actual backup)
HSMS and its CCOPY (Concurrent Copy) function enable consistent backups to be created simultaneously and the data which is to be backed up to be processed in any required way. To permit this, the application which processes the files to be backed up must be terminated briefly before backup begins or be guided to a synchronization point. The backup job can then be started. After an initialization phase which can be monitored with a job variable, the application can be enabled again. Backup then runs parallel to file processing.
Backup with CCOPY uses either a temporary scratch file or a replication function of the storage system. Further information on this subject is provided in the “HSMS” manual [14 (Related publications)].
Use of a replication function of the storage system permits load splitting between the application on the original disk and the backup on the mirror disk, and as a result operation of the application is disturbed considerably less by the backup I/Os.
In these cases a task job variable shows the status for the application restart before the task is completed.Performance of the catalog accesses in the case of DMS backups
In shared pubset operation the normal backup requests are sent to the master side in HSMS to utilize the quicker local catalog accesses without MSCF traffic.
Backup requests with CCOPY of mirror disks of the storage systems are always performed locally in shared pubset mode because the catalog accesses to the split mirror disks of the storage systems are performed locally. This enables the I/O load to be split (e.g. with two systems for application and backup).
Backup server
The concept of the backup server in the SE environment uses a different strategy. Here a dedicated BS2000 system is used as the backup server. Backup jobs which are started on BS2000 systems for pubsets to which the backup server also has access are then backed up by this server. This increases the MSCF workload with respect to accesses to the catalog when the productive system is the master in the SPVS network, but relieves the productive system of the load of data backup.
Here, too, backup jobs are processed locally by mirror disks with CCOPY and not sent to the backup server.
When a very large number of files are to be backed up, summary reports (only in the event of errors are entries made on a file-by-file basis) should be used instead of full reports (entries for all files) in order to keep the trailer time short.
- Reducing RESTORE-FILES run-time from K- to NK-Pubsets
If RESTORE-FILES has to be performed from a K-Pubset to a NK-Pubset the respective files should be carefully chosen rather than restoring the whole Pubset. Every file will be individually converted from K to NK, resulting in a dramatic increase in run-time when restoring large amounts of files in this specific case. Database backups during ongoing database operation
Files which can be backed up but are open for writing can be backed up using the backup option SAVE-ONLINE-FILES = *YES, e.g. for UDS databases with log files and for Oracle database files or single tablespaces.
SESAM database backup by SESAM/SQL via the HSMS program interface is performed in the same way, also in combination with CCOPY of mirror disks of the storage systems. This results in minimal refreshment phases for the database.