IBM E16RMLL-I - Tivoli Storage Manager, Implementation Manual

Page: 76 / 828

46
IBM Tivoli Storage Manager Implementation Guide
migration to the next storage pool can execute concurrently; however,
performance will degrade.
We recommend using a primary disk storage pool of at least the recommended
size to reduce interference from migration while backup is running.
2.8.9 Disk storage pool size
To estimate a primary storage pool size if running backup cycles only, do the
following:
1. Using Table 2-1 on page 18, multiply the GB changed per backup by (1 - the
Data compression rate) to give the total bytes transferred for each client.
2. Sum the total bytes transferred for all clients to give the total bytes transferred
per backup cycle.
3. Add 15% to total bytes transferred per backup cycle to give the storage pool
size. This allows for variability in the size and number of files per backup.
For example, using the sample figures in Table 2-1 on page 18, the GB changed
per backup are 6 * 20 (120 GB) and 4 * x 100 (400 GB), while the data
compression figures are 0.5 and 0.66, respectively.
1. Multiplying 120 by (1 - 0.5) gives 60, and multiplying 400 by (1 - 0.66) gives
136.
2. Summing 60 and 136 gives 196 GB.
3. Adding 15% gives a storage pool size of 225.4 GB. We will round to 226 GB.
2.8.10 Archive disk sizing
In most environments, archive disk sizing is less critical than for backup. This is
because backup operations tend to run much more frequently (usually nightly)
and to a stricter time frame. Archives may run less frequently, and on weekends
when the overall workload is lighter. Since in these circumstances the impact of
running concurrent archive and storage pool migration might not be so critical, it
is not normally necessary to use the full archive size in calculating storage pool
requirements. Another factor to be considered for sites that are doing frequent
archiving of large amounts of data, where the storage pool and processing
impact are great, is the possibility of substituting backup set operations for
archive. The advantage of this is that generating a backup set requires the Tivoli
Storage Manager server only—the client is not involved in any way since the
backup set is created using data that has already been sent to the server in
normal backup operations.