Resultados con respecto a la percepción de la población en los niveles de ruido

4.3 Frequency and duration

The administrator defines the time period (that is, theduration) during which a schedule can start, and how often to repeat the schedule (the frequency). An example of a typical schedule frequency could be: every night at midnight. The start time is 00:00 and the period between startup windows is 24 hours. The duration is set to 2 hours. See Figure 57.

Figure 57. Schedule frequency

The actual time that a scheduled operation will start can be at any time during the duration window. If it is unable to start in this window, then it will be missed and recorded as such. After the period parameter between schedules has passed, the schedule will attempt to start again. The duration window therefore allows handling of a situation where the client is not running its scheduler process when the schedule is supposed to start, for example, if it has been powered off. So long as the client is available at some time before the end of the duration window, the schedule will be able to start.

The actual time that a scheduled event will end is dependent only on how long it takes the scheduled process to complete. It has no relation to the duration window. This is shown in Figure 57.

4.4 Retry and randomization

You can specify the maximum number of concurrent clients allowed to log on to Tivoli Storage Manager, as well as the maximum number of scheduled sessions allowed. If you restrict the number of scheduled sessions allowed on the server, a client is prevented from running a schedule when the maximum number of sessions has been reached. Through options which can be set globally at the server or individually for each client, the client can retry a certain number of times to run the schedule and with specified time interval between retries.

Scheduling 79 With the retry and randomization options, you have considerable flexibility to balance the network load.

Let us consider the scenario where you, as an administrator, associate 100 workstations with a backup schedule that has a window of 2 a.m. through 6 a.m.

every Friday. You can use the randomization option to tell Tivoli Storage Manager to stagger the start times of 100 backup sessions so that they start at different times. In this way, you prevent a big bottleneck, which would occur if the 100 schedules started at 2 a.m., all at once!

4.5 Event log

Scheduled operations are recorded centrally in the event log at the server.

You can view which schedules ran successfully, were missed, and are scheduled to run in the future. You can create an exception reporting list. In this way you can view only those schedules that failed.

Detailed reports of the schedule are logged at client level. High level results are sent to the server to an event log, so you can view whether or not schedules ran successfully.

You determine how long a record is retained in the event log.

© Copyright IBM Corp. 2000 81

Chapter 5. Data storage

Tivoli Storage Manager represents data storage with administrator-defined objects: storage pools and storage pool volumes.

In the following sections we discuss how Tivoli Storage Manager automatically manages these pools and how you can define and check that the command used has performed the changes you require.

We also discuss some Tivoli Storage Manager concepts related to storage pools:

how to use fewer tapes (reclamation), and how to reduce a client’s restore time (collocation). We provide a brief outline of protecting disk storage by using some form of redundant array of independent disks (RAID).

5.1 Storage pools

A storage pool is a collection of storage pool volumes; each storage pool represents one type of media - see Figure 58. For example, a storage pool for a 4 mm digital audio tape device (DAT) represents collections of only 4 mm tapes, and a storage pool for an IBM 3590 represents collections of only 3590 tapes. A storage pool created on a disk has files formatted under Tivoli Storage Manager as volumes and are collectively grouped in the storage pool.

Figure 58. How volumes and storage pools are arranged for disk and tape

You can add or remove volumes without interrupting server operations. In this way you can increase or decrease the size of a storage pool dynamically without any interruption to the Tivoli Storage Manager service.

The two main categories of devices supported for storage pools are random access and sequential devices.

1. Random access devices refer to magnetic disks.

2. Sequential devices usually refer to tape devices and/or optical devices that require manual configuration. It is also possible to configure disk in a way that it will be accessed sequentially (a FILE device class).

Storage pools in Tivoli Storage Manager are defined on a wide range of different devices that may be attached locally to the server or accessed via a Storage Area Network (SAN).

DISK

Storage Pool

Storage Pool Volumes

TAPE

Storage Pool

Storage Pool Volumes

For a complete up-to-date list of different devices that can be attached to the server platform you are going to use, the best information source is the Tivoli Storage Manager Web site. This can be found at the URL:

http://www.tivoli.com/support/storage_mgr/adsercli.htm#servreq

Find your Tivoli Storage Manager server operating system type and click on the link to get to the most current device support list. Current SAN supported devices and configuration can be viewed at

http://www.tivoli.com/support/storage_mgr/san/overview.html

Tivoli Storage Manager has two types of storage pools:

• Primary storage pools

• Copy storage pools

5.1.1 Primary storage pools

When a client node backs up, archives, or migrates data, the data is stored in a primary storage pool.

When a user tries to restore, retrieve or export file data, the requested file is obtained from a primary storage pool if possible. Primary storage pool volumes are always located onsite.

A primary storage pool can use random access storage (DISK device class) or sequential access storage (for example, tape, optical or FILE device classes).

5.1.2 Copy storage pools

A copy storage pool provides an additional level of protection for client data. It is created by the administrator backing up a primary storage pool. The copy storage pool contains all current versions of all files, active and active, exactly as they appear in the primary storage pool.

A copy storage pool provides recovery from partial and complete failures in a primary storage pool. An example of a partial failure is a single tape in a primary storage pool being lost or defective. When a client attempts to restore a file which was on this volume, the server will automatically switch to the right copy storage volume if it is available to seamlessly restore the client’s data. If a complete primary storage pool is destroyed, for example in a major disaster, the copy storage pool is used to recreate the primary storage pool.

A copy storage pool can use sequential access storage (for example, tape optical or FILE device classes), or copy storage pools can also be created remotely on another Tivoli Storage Manager server, thus providing electronic vaulting. See Chapter 12, “Virtual Volumes” on page 143 for more information.

Copy storage pool volumes can be moved offsite and still be tracked by Tivoli Storage Manager. This is done by using the access mode of offsite to ensure that Tivoli Storage Manager does not request a volume mount. Moving copy storage volumes offsite provides a means of recovering from a disaster at your primary site. Tivoli Disaster Recovery Manager (see Chapter 9, “Tivoli Disaster Recovery Manager” on page 115 for more information) helps automate offsite media tracking and storage pool recovery.

Data storage 83 Copy pools are not part of the storage migration hierarchy. Files are not migrated to or from copy storage pools. The only way to store files in copy storage pools is by using theBACKUP STGPOOLcommand.

5.2 Storage pool hierarchy

Tivoli Storage Manager allows you to configure storage pools to provide the best combination of performance throughput and data permanence. In most cases, keeping client data on tape or optical media is a requirement. However, taking the backups direct to tape may not give the best performance, especially where there are many clients to backup concurrently, and many small files are being backed up. Therefore, Tivoli Storage Manager provides a storage pool hierarchy, whereby a client initially backs up to a storage pool usually on disk. When this storage pool fills up, Tivoli Storage Manager will automatically move or ’migrate’

files to the next storage pool in the hierarchy (usually on tape or optical) while the client continues its backup operation. This migration process is controlled by high and low thresholds set on the storage pool.

The management class (see Chapter 3, “Data storage policy” on page 63) determines where the client data enters the storage hierarchy. Figure 59 shows a configuration where 5 storage pools are defined. The default management class sends backups first to storage pool A which are then migrated by the server to pool B and finally to pool C. The other management class uses storage pool D for space managed files, whereas backups are sent directly to Tape_Pool. This would be appropriate for large client files (e.g. an application database files) which can exploit the streaming performance capacity of the tape device.

Figure 59. Possible hierarchical arrangement of different storage devices