Before configuring your disk device, you should consider the differences between the two methods of storing data on disks and the advantages and disadvantages of each. The particular advantages provided by either device type depends on the operating system on which your Tivoli® Storage Manager server is running.
Table 1 provides some general information about the characteristics of DISK devices (random access) and FILE devices (sequential access) and the benefits of each.
| Function | Random Access (DISK) | Sequential Access (FILE) | Notes® |
|---|---|---|---|
| Storage space allocation and tracking | Disk blocks | Volumes | Space allocation and tracking by blocks uses more database storage space, and requires more processing power than space allocation and tracking by volume. |
| Concurrent volume access | A volume can be accessed concurrently by different operations | A volume can be accessed concurrently by different operations | Concurrent volume access means that two or more different operations can access the same volume at the same time. |
| Client restore operations | One session per restore | Multiple concurrent sessions access different volumes simultaneously on both the server and the storage agent. Active versions of client backup data is collocated in active-data pools. | Multi-session restore enables backup-archive
clients to perform multiple restore sessions for no-query restore
operations, increasing the speed of restores. Active-data pools
defined using sequential-access disk (FILE) enable fast client restore
because the server does not physically mount tapes and does not position
past inactive files. For more information, see Backing up primary storage pools, and the information about client restore operations in the Optimizing Performance guide. |
| Available for use in LAN-free backup | Not available | Available for LAN-free backup using IBM® General Parallel File System. | Using LAN-free backup, data moves over a
dedicated storage area network (SAN) to the sequential-access storage
device, freeing up bandwidth on the LAN. For more information, see LAN-free data movement. |
| Volume configuration | Operators need to define volumes and specify their sizes, or define space triggers to automatically allocate space when a threshold is reached. | The Tivoli Storage
Manager server
acquires and defines scratch volumes as needed if storage administrators
set the MAXSCRATCH parameter to a value greater
than zero. Operators can also define space triggers to automatically allocate space when a threshold is reached. |
For more information
about volumes on random-access media, see
For more information about volumes on FILE devices, see Configuring FILE sequential volumes on disk devices. |
| Tivoli Storage Manager server caching (after files are migrated to the next storage pool in the storage pool hierarchy) | Server caching is available, but overhead is incurred in freeing the cached space. For example, as part of a backup operation, the server must erase cached files to make room for storing new files. | Server caching is not necessary because access times are comparable to random access (DISK) access times. | Caching can improve how quickly the Tivoli Storage
Manager server
retrieves files during client restore or retrieve operations. For more information, see Caching in disk storage pools. |
| Recovery of disk space | When caching is enabled, the space occupied
by cached files is reclaimed on demand by the server. When caching is disabled, the server recovers disk space immediately after all physical files are migrated or deleted from within an aggregate. |
The server recovers disk space in a process called reclamation, which involves copying physical files to another volume, making the reclaimed volume available for reuse. This minimizes the amount of overhead because there is no mount time required. | For more information about reclamation, see Reclaiming space in sequential-access storage pools. |
| Aggregate reconstruction | Not available; the result is wasted space | Aggregate reconstruction occurs as part of the reclamation process. It is also available by using the RECONSTRUCT parameter on the MOVE DATA and MOVE NODEDATA commands. | An aggregate is two or more files
grouped together for storage purposes. Most data from backup-archive
clients is stored in aggregates. Aggregates accumulate empty space
as files are deleted, expire, or as they are deactivated in active-data
pools. For more information, see How Tivoli Storage Manager reclamation works. |
| Available for use as copy storage pools or active-data pools | Not available | Available | Copy storage pools and active-data pools
provide additional levels of protection for client data. For more information, see Backing up primary storage pools. |
| File location | Volume location is limited by the trigger prefix or by manual specification | FILE volumes use directories. A list of directories can be specified. If directories correspond with file systems, performance is optimized. | |
| Restoring the database to an earlier level | See Notes | Use the REUSEDELAY parameter to retain volumes in a pending state. Volumes are not rewritten until the specified number of days have elapsed. During database restoration, if the data is physically present, it can be accessed after DSMSERV RESTORE DB. | Use the AUDIT VOLUME command
to identify inconsistencies between information about a volume in
the database and the actual content of the volume. You can specify
whether the Tivoli Storage
Manager server
resolves the database inconsistencies it finds. For more information about auditing volumes, see Auditing storage pool volumes. For more information about reuse delay, see Delaying reuse of volumes for recovery purposes. |
| Migration | Performed by node. Migration from random-access pools can use multiple processes. | Performed by volume. Files are not migrated from a volume until all files on the volume have met the threshold for migration delay as specified for the storage pool. Migration from sequential-access pools can use multiple processes. | For more information, see Migrating disk storage pools. |
| Storage pool backup | Performed by node and file space. Every storage pool backup operation must check every file in the primary pool to determine whether the file must be backed up. | Performed by volume. For a primary pool, there is no need to scan every object in the primary pool every time the pool is backed up to a copy storage pool. | For more information, see Storage pools. |
| Copying active data | Performed by node and file space. Every storage pool copy operation must check every file in the primary pool to determine whether the file must be copied. | Performed by volume. For a primary pool, there is no need to scan every object in the primary pool every time the active data in the pool is copied to an active-data pool. | For more information, see Storage pools. |
| Transferring data from non-collocated to collocated storage | Major benefits by moving data from non-collocated
storage to DISK storage, and then allowing data to migrate to collocated
storage. See Restoring files to a storage pool with collocation enabled for more information. |
Some benefit by moving data from non-collocated storage to FILE storage, and then moving data to collocated storage. | For more information, see Keeping client files together using collocation. |
| Shredding data | If shredding is enabled, sensitive data is destroyed after it is deleted from a storage pool. Write caching on a random access devices should be disabled if shredding is enforced. | Shredding is not supported on sequential access disk devices. | For more information, see Securing sensitive client data. |
| Data deduplication | Not available | Duplicate data in primary, copy, and active-data pools can be identified and removed, reducing the overall amount of time that is required to retrieve data from disk. | For more information, see Deduplicating data. |
