Large SFS Backups

Products

• VM:Backup for z/VM
• VM:Backup High-Speed Disaster Recovery Option (HiDRO)

Issue/Introduction

VM:Backup can have performance issues when backing up large SFS file pools.  Are there any general suggestions for large file pools.

Resolution

Often we find that when processing a very large file space, VM:Backup spends a lot of time preparing to back it up. This can be due to other things beyond sheer size.

When “Number of Tries for Consistent View of a File Space” on screen WBTMABC2 is greater than zero, VM:Backup will read the file space catalog more than once. Doing so has the effect of shadowing changes that might occur once the dump is actually started which results in a more reliable backup. If during this stage something gets modified in the file space, VM:Backup will discard what it has produced and do it again until the specified number of tries is reached. It actually must do two consecutive scans with no changes to ensure that SFS shadows the contents correctly. The first thing that a customer should look at is how the file space is being used when the backup is occurring. Unless there is an application that requires a consistent view between multiple files you should leave this number at its default value of 0. Normal CMS file usage generally does not require a consistent view.

Another factor that determines the amount of data that is read from the file space catalog is the number of SFS authorizations that exist for the files in the file space. (CATINFO will list authorizations.) That can add a surprising amount of bulk to the catalog data that VM:Backup reads and hence slow down this processing. It also adds a lot of CPU overhead to VM:Backup. It is advised avoiding SFS authorizations altogether. SafeSFS is an external security manager for SFS that offloads authorization checking. If you use it, you can remove these authorizations from the SFS catalog and significantly improve VM:Backup performance scanning the file space catalog.

Also make sure DEBUG CSLIO is not turned ON. That forces the use of CSL routines to read data instead of the default action of reading directly from the SFS minidisks and it slows down backups enormously. Issue the command VMBACKUP DEBUG CSLIO to verify that. 

If the file pool is enormous, you might consider moving some of the data into a new file pool. 

Do not specify Data Packing ON in your backup template.