IBM E16RMLL-I Implementation Guide - Page 75
Tivoli Storage Manager supports
View all IBM E16RMLL-I manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 75 highlights
until space is needed for further backups. This can significantly improve restore performance for recently backed up files. As the cost of per megabyte of disk decreases, more and more disk is being used in Tivoli Storage Manager designs. Some use no tape at all, so that all backed up data is saved to disk. In this case, the file-type device class should be used, not a disk-type (even if a disk-type is the initial destination). Disk-type pools become fragmented if data is retained for extended periods of time, unlike file-type classes, which can be defragmented. Tivoli Storage Manager supports a tapeless configuration through the use of disk storage pools or a device class of type file. When deciding whether to use only disk for backup-archive storage, consider the following caveats: Do a realistic analysis of the total amount of storage needed considering your data retention policies, total data, and growth expectations. Evaluate the cost of tape versus disk for storing all data. Invest in a disk technology that can permanently store the data. If the device can fail (and all devices can, whether RAID, mirrored, or anything else), consider using a copy storage pool for data redundancy. Carefully consider the cost and technical feasibility of getting the data off-site for disaster recovery purposes. Tape cartridges are portable. If using disk only, off-site copies have to be moved over a network transport. In our scenario, when a client node backs up, archives, or migrates data via HSM, all data is stored in one primary storage pool. You could also use separate storage pools for a backup, archive, and HSM data for improved controls and manageability of production data. To size the disk storage pool, calculate how much will be backed up during one cycle and add on a proportion of the amount of archive data transferred to the server. This amount (plus a contingency for growth) is the recommended size for the storage pool. If you are also using Space Management (HSM) features, the rate of data migration to the server is hard to predict, so you need to get experience of your particular environment to make an accurate sizing. Primary storage pools (usually disk devices) can be made larger or smaller than the recommended size, depending on the resources available. A larger pool size allows for more than one backup cycle of data to remain on disk, thus improving restore times. It also allows for spare capacity for an unexpectedly large amount of backup data to prevent server migration from running during backup. A smaller primary storage pool uses less disk, but runs the risk that the pool will fill up during back up. This is not functionally a problem, since the backup and Chapter 2. Implementation planning 45