Tivoli Storage Manager database

The Tivoli Storage Manager database size is based upon how many files are managed with Tivoli Storage Manager, and whether the files are in a primary storage pool or a copy storage pool. The database holds two types of data:

entries for backups and entries for archives. The database also holds items such as entries for image backups, server scripts and the volume history, but typically, these are insignificant in sizing the database.

Backup sizing calculates the size of the Tivoli Storage Manager database holding backup entries. Archive sizing calculates the size of the Tivoli Storage Manager database holding archive entries. Use either or both depending on the data you will be storing in Tivoli Storage Manager. If both are used, then add the calculated database sizes together to arrive at the total database size. If you are planning to use backup sets, remember that these are not tracked in the Tivoli Storage Manager database, so do not impact our calculation. They do affect the tape library size if the media used is retained online. Image backups are entered in the database, although only one entry for each backup is required. The database space requirements for image backup entries will therefore be small compared to the backups and archives and we will not include this in our calculation.

Our calculations are based on the following assumptions: each backed up or archived file version uses 600 bytes of space in the server database. If offsite copies are used as well, this takes an extra 200 bytes of space. Where we did not know the number of files to be kept, but only the total storage, we estimate 5% of the total server storage requirement for onsite copies and 1% for offsite.

2.4.2.1 Backup sizing

To estimate the Tivoli Storage Manager database size for backup data, use the data collected in Table 7 on page 13 and Table 11 on page 19.

The calculation is based upon two types of numbers: the actual number of file versions backed up; and when this is not known, by a percentage of the data backed up. Steps 1, 2, 3, and 6 are based on the number of file versions. Steps 4 and 7 are based on the estimated percentage of data method.

1. Sum the fieldNumber of Files Backed Upfor all clients, leaving out any fields containing estimates in GB.

2. Multiply this number by theNumber of Versions Kept, giving a total number of files backed up.

3. Multiply this number by 600 bytes, to give bytes used in the database for all known files backed up.

4. Sum of all the estimated files in GB multiplied by theNumber of Versions Kept. Take 5% of this number to give the estimated bytes for backed up files.

5. Add bytes for known files backed up to estimated bytes backed up to give total bytes for backed up files.

6. If copy storage pools are used (and we strongly recommend this), multiply the total number of files backed up and calculated in Step 2 above by 200 bytes, giving the bytes for known copy storage pool files.

7. Sum of all estimated files in GB multiplied by theNumber of Versions Kept. Take 1% of this number to give the estimated bytes for copy storage pool files.

8. Add bytes for known copy storage pool files to estimated bytes for copy storage pool files to give total bytes for copy storage pool files.

9. Add the total bytes for backed up files to the total bytes for copy storage pool files to give the total bytes calculated for the database.

10.Calculate 135% of total bytes calculated for the database to give the database size. This is for overhead and for growth.

For example, using the sample data in Table 7 on page 13 and Table 11 on page 19, calculate the sample database size as follows:

1. 5,000 + 15,000 = 20,000 files 2. 20,000 * 2 = 40,000 files

3. 40,000 * 600 = 24,000,000 bytes (24MB) 4. 2,500 MB * 7 * 0.05 = 875 MB

5. 24 MB + 875 MB = 899 MB for backed up files 6. 40,000 * 200 = 8,000,000 bytes (8 MB)

7. 2,500 MB * 7 * 0.01 = 175 MB

8. 8 MB + 175MB = 183 MB for copy storage pool files 9. 875 MB +183 MB = 1058 MB

10.1058 MB * 1.35 = 1428MB database size for backup files 2.4.2.2 Archive sizing

To estimate the Tivoli Storage Manager database size for archive data, use the data collected in Table 7 on page 13 and Table 11 on page 19.

The calculation is based upon the number of files archived:

1. Sum the fieldNumber of Files Archivedfor all clients.

2. Multiply theNumber of files archivedby theNumber of archives kepttimes the yearly retention ratio (i.e., desired monthly retention/12 months), giving a total number of files archived.

3. Multiply this number by 600 bytes to give total bytes for archived files.

4. If copy storage pools are used (and we strongly recommend this), then multiply the total number of files archived and calculated in Step 2 above by 200 bytes, giving the total bytes for copy storage pool files.

5. Add the total bytes for archived files to the total bytes for copy storage pool files to give the total bytes calculated for the database.

6. Calculate 135% of total bytes calculated for the database to give the database size for archives. This is for overhead and for growth.

For example, using the sample data in Table 7 on page 13 and Table 11 on page 19, (for simplicity we only present here the two Server class machines - the

process is similar for the Workstn system) calculate the sample database size for archive as follows:

1. 45,000 + 17,500 = 62,500 files

2. 6,500 * 12 * (12/12) = 750,000 files archived 3. 750,000 * 600 = 450,000,000 bytes (450 MB) 4. 750,000 * 200 = 150,000,000 bytes (150 MB) 5. 450 MB + 150MB = 600 MB

6. 716 MB * 1.35 = 810 MB database size for archive data 2.4.2.3 Identify database volumes

The total required database size including both backup and archive requirements will be 1428 + 810 = 2238 MB

We recommend using the Tivoli Storage Manager mirroring function for the database instead of a hardware mirror or operating system mirror, because Tivoli Storage Manager has additional functions to handle error conditions that may affect the mirrored copy.

If you are using Tivoli Storage Manager mirroring, you need to plan for the mirror copy by doubling the amount of disk for the database.

Various file systems have different maximum capacities, so the database may have to be split across numerous volumes to make up your database size. To ensure no single point of failure when mirroring the database, each volume in a mirrored set should be placed on a separate drive and even controller.

Complete Table 15 with the database file names and the volume names for your primary database and copy database. This table includes the space for the backup requirements only.

Table 15. Database worksheet - backup requirements only Database Our recommended configuration will set up triggers to additionally extend the database whenever necessary. This is documented in Chapter 4, “Database and recovery log” on page 57.

By summing up backup and archive database sizes, you will have a full, consolidated database for the calculated timeframe. You can start with a smaller configuration initially but leave enough spare disk space for growth.

You should round up database volume sizes to multiples of 4 MB plus 1 MB for overhead.

Note:

You can also use a full database allocation, using both backup and archive requirements, as shown in Table 16:

Table 16. Database worksheet - backup and archive requirements