The question of data saving is of particular importance to all data centers. Major arguments for a reliable data backup strategy are
the demand for high data availability
the possibility of accessing data sets which cannot be stored on public volumes due to limited capacity
the improvement of response times by reorganizing both public and private volumes
the desire/necessity to transport data sets to another data center.
In order to meet these requirements, preventive and regular saving of all important data must be carried out at all data centers.
Selection of data
Selection of data for saving generally depends on its so-called save worthiness. Thus a distinction is made between production data, which is required for ongoing production and is subject to continuous modification, and pure test data, which can be reproduced at any time. In addition, system data which normally does not change during operation can be excluded from regular saves. In such cases, a complete backup copy is sufficient to reconstruct the current status if necessary.
Time and frequency of data saving
The data saving methods must be devised in such a way that both the requirement for data security and the requirement for availability of the applications are met. For example, time-consuming saves - logical or physical total saves - should be strategically shifted to times of low workload in order to minimize the loss of usable processor time.
Furthermore, the data saving method used must ensure that redundant inventories of saved data are avoided. This means that each update status of a file should be saved once only.
Types of save
Total save
In a total save all of the files which are designated by the selection criteria and which are closed at the time of the backup are marked. These files are completely saved, irrespective of whether or not they have changed since the last backup.
A total save is sometimes called a “full save”. Physical saves are always full saves.
Incremental saves
In an incremental save, only those files that have changed or been created since the last backup are saved. These files are completely saved. The same directory file must be used in which the information on the file version was stored.
Partial saves
In a partial save (a special form of the incremental save), only those PAM pages that have been changed since the last complete backup are saved for selected files. The other files are not saved at all. In order to reconstruct a partially saved file, the last partial save and the last total save are required.
A partial save is frequently also called a “partial backup“.
Scope of data saving
The scope of data saving is determined by systems support on the basis of the criteria data inventory, consistency of the data, server load and configuration.
Data inventory
The number and size of the data to be managed and saved has a direct influence on the scope of data saving.
If the data inventory is small, systems support can forego partial or incremental saves and provide for regular logical or physical total saves of the system. Although unchanged data is saved time and again, the overall “data packet” is always consistent and will not have to be reconstructed from various saved data inventories. In the case of extensive data inventories, systems support must devise a strategic concept for saving data. All files can be saved successively by arranging a sequence of several partial and incremental saves; At weekly intervals, for example, a logical or physical total save can be performed.
Files can be assigned different backup levels or management classes. These assignments can then be used by systems support to limit the scope of the backup.
Consistency of the data
The data inventory must also be subject to a qualitative check with respect to the scope of the save.
The quality attributes of system and user files include the following:
the number of accesses
the frequency of updates
the scope of updates
the frequency with which program versions are exchanged
the assignment to a backup level or management class
If the data inventory is limited for the most part to constant, stable versions that are rarely or never updated, the current status can also be quickly reconstructed from a saved version made some time earlier. On the other hand, for program versions or file inventories that are changed or updated frequently, systems support must prevent data loss by means of a suitable, layered data saving strategy.
Server load
With the help of a detailed analysis of the server load, systems support can not only determine the time and frequency of saves but also draw conclusions regarding the scope of the data to be saved.
Ideally, the data saving strategy could be devised in such a way that comprehensive full saves are performed in periods of relatively low load, partial and incremental saves in periods of moderate load, and no saves at all during periods of full load.
Configuration
The configuration of the server and thus the hardware available for data saving purposes is an important consideration when devising the data saving strategy and is a factor which determines the scope of the individual saves.
If enough peripheral equipment is available, systems support can shorten the save duration and increase the scope of the saved data.By using the subtask function of the ARCHIVE and FDDRL utility routines, subtasks can be directed to different devices and saves can be performed in parallel.
Distribution of user groups to individual pubsets (MPVS) facilitates strategic access to subsets of the data to be saved.
At system generation time systems support can create the prerequisites for accelerated saving of even large data volumes by means of a performance-boosting configuration of peripherals, channels and IOPs.
Down time due to backup
When the data of an application is backed up, the application itself is not available for a while. This down time is determined mainly by the scope of the backup and how long its takes to back up the data. The down time can be reduced to the time it takes to create a copies of the files by just backing up copies (e.g. on mirror disks). The application itself can continue to work with the original files after the copy phase while the more time-consuming backup of the copy is being performed.
Logical and physical save
In a logical save, individual files and job variables are read from one or more volumes and written contiguously (i.e. in logical units) to other volumes.
The software products ARCHIVE (see the “ARCHIVE” manual [3]) and HSMS (see the “HSMS” manual [24]) are available in BS2000 for logical data saving.
HSMS provides the user with the four basic functions
data saving (backup)
long-term archiving
migration
data transfer (export/import)
HSMS is an extension of the software product ARCHIVE. Most functions that were formerly called via ARCHIVE are now available in compatible form in HSMS.
To reduce downtime, backup of a copy with CCOPY (Concurrent Copy) is offered in HSMS.
In a physical save, individual files are not saved; instead, entire volumes are saved according to their physical structure. All the files on a volume, including the volume labels, are written block by block in physical sequence to a second volume. This is then identical to the original volume.
The FDDRL software product (see the “FDDRL” manual [22]) is available in BS2000 for physical data saving.
The Snapset save is a mixture of the physical and logical saves: It is a pubset backup in which a copy of each pubset disk is created on a snap unit. Individual files and job variables can be read from this pubset backup as logical units. Depending on the storage system, the entire pubset can also be restored. The functions for the Snapset save and access to the saved data (at pubset, file and job variable level) are available in BS2000.
Encrypted files are stored in encrypted format for all save types.
The table below shows the basic differences between backing up volumes (physical saves), backing up files and job variables (logical saves), and a Snapset save.
Logical save | Physical save | Snapset save | |
What is saved? | Files, catalog entries, job variables | Entire volumes, i.e. private and public disks | Complete pubset |
Who saves it? | Systems support or HSMS administration: all user and system files; | Systems support or HSMS administration | Systems support or HSMS administration |
When is it saved? | At regular intervals (the applications are stopped) | Regularly in the case of pubsets which are exported with EXCAT | Regularly during ongoing operation (imported pubset) |
Facilities used | ARCHIVE and HSMS utility routines | FDDRL utility routine | Snapset commands in BS2000 |
Facts to be noted |
|
|
|
Backup medium | Tape cartridge, disk and Net-Storage volume | Tape cartridge and disk | Snap units |