HP Archive Backup System for OpenVMS Guide to Operations

More documents

Recommendations

Info

Media Management 4.8 Media Types 4.8 Media Types 4.8.1 Capacity 4.8.2 Compaction 4.8.3 Density 4.8.4 Length 4.9 Node 4.9.1 Database Server Finally, you can specify if you need operator assistance. This is recommended with “Move Magazine” as magazines cannot be moved without human intervention. Only if you plan to do the physical move yourself or you manually let someone know would you disable operator assistance. MDMS uses media type objects to hold information about the type of media that volumes and drives can support. MDMS uses media type as a major selection criterion for allocating volumes and drives, and volumes can only be loaded into drives with compatible media types. Media types contain four attributes, as defined in the following sections. The capacity attribute indicates the capacity of the media in MB. This field is not used by ABS or HSM, but is used by the obsolete product “Sequential Media Filesystem” (SMF). This important field indicates whether you wish the tape to be written with firmware compaction. Enabling compaction usually doubles the capacity of the tape, so this is a desirable option which is set by default. Clear the attribute if you do not wish compaction. This field indicates the density of the tape that you desire. Many types of tape media (especially DLT tapes) support multiple densities, and certain types of drive can either read and write a certain density, or just read some densities. As such, you can define many media types with different densities that can be assigned to volumes and drives. MDMS uses the density field when initializing volumes, so the density must be a valid Open- VMS density for the version of the operating system being used. Issue a “HELP INITIALIZE /DENSITY” command to determine the valid densities on the platform. The length field is used for information purposes only. If your media comes in various lengths, you can differentiate between types by using the length field. Specify an integer value that has meaning to your operators. An MDMS node is an OpenVMS system that is running MDMS. All nodes running MDMS must have a node object defined in the database for MDMS to work properly. The node name must be one of the following, in this order: the SCSNODE name, the DECnet Phase IV name, the host name of the IP node, or the DECnet Phase V name. If none of these are defined then MDMS$SERVER should be the node name. Nodes contain attributes as outlined in the following sections. MDMS operates as a group of co-operating processes running on multiple nodes in multiple clusters in an MDMS domain. One of these MDMS processes is known as the “Database Server”, and it actually controls all MDMS operations in the domain. Although only one node is the database server at any one time, you should enable multiple nodes to be possible database servers in case the actual database server node fails. In this way, failover is supported. 4-16 Media Management
4.9.2 Disabled 4.9.3 OPCOM Class Media Management 4.10 Pools A database server must have direct access to the database files located in MDMS$DATABASE_LOCATION. Direct access, access via MSCP, and access via Fibre Channel are all considered local access. Access via a network protocol or DFS are not considered local access. It is recommended that you enable at least 3 nodes as potential database servers to ensure failover capabilities. Set to disable the node as an MDMS node. Clear to enable the node as an MDMS node. You can specify the OPCOM classes to be used by MDMS for operator messages on this node. By default, the domain default OPCOM classes are used, but you can override this on a node-bynode basis. Specify one or more of the standard OpenVMS OPCOM classes - messages are directed to all login sessions with these OPCOM classes enabled. 4.9.4 Transports and Full Names 4.10Pools 4.10.1 Authorized Users You can define which network transports are defined for this node. There are four choices: • DECnet - The DECnet transport is used • TCPIP - The TCP/IP transport is used, and the TCP/IP full name is specified • DECnet, TCPIP - The DECnet and TCP/IP transports can be used, with DECnet preferred • TCPIP, DECnet - The TCP/IP and DECnet transports can be used, with TCP/IP preferred If you identify TCP/IP as a supported transport, you must define the TCP/IP fullname in the TCP/IP fullname field. These fullnames are normally in the format “node.loc.org.ext”. For example, SLOPER.CXO.CPQCORP.COM If you identify DECnet as a transport, you need to specify a DECnet full name only if you are using DECnet-Plus (Phase V). In this case, enter the full name, which is normally in a format such as LOCAL:.node. If you are running DECnet Phase IV, do not specify a DECnet full name. The node’s node name is used. A pool is a logical MDMS object that associates a set of volumes with a set of users that are authorized to use those volumes. Every volume can be assigned one pool, for which we say that the volume is in the pool. The pool is then assigned a set of users that are authorized to use the volumes in the pool. If a volume does not have a pool specified, then it is said to belong to the “scratch pool” for which no authorization is required. Pools have three attributes that are discussed in the following sections. You can specify a list of authorized users for the pool, as a comma-separated list of users. Each user should be specified as node::username or group::username, where both the node/group and username portions can contain wildcard characters (*%). To authorize everyone, you can specify *::*. To authorize everyone on a node you can specify nodename::*. Everyone in the authorized user list is allowed to allocate volumes in the pool. Other users require MDMS_ALL_RIGHTS or MDMS_ALLOCATE_ALL rights. Media Management 4–17
Page 1 and 2:
HP Archive Backup System for OpenVM
Page 3 and 4:
Contents Preface . . . . . . . . .
Page 5 and 6:
3.6.1 Agent Qualifiers . . . . . .
Page 7 and 8:
4.11.7 Previous and Next Volumes .
Page 9 and 10:
9.3 Defining the Logical MDMS$SBT_T
Page 11 and 12:
B.2 SLS/MDMS V2.x to ABS/MDMS V4.x
Page 13:
Tables Table 3-1 Logical Names Avai
Page 17 and 18:
Preface Intended Audience This docu
Page 19 and 20:
1 Introduction The Archive Backup S
Page 21 and 22:
2 Overview This chapter provides an
Page 23 and 24:
Overview 2.2 ABS Objects Figure 2-1
Page 25 and 26:
2.2.6 Schedules 2.3 ABS Catalogs Ov
Page 27 and 28:
Overview 2.5 Media, Device and Mana
Page 29 and 30:
2.8.3 Groups 2.8.4 Jukeboxes Overvi
Page 31 and 32:
2.8.8 Nodes 2.8.9 Pools 2.8.10 Volu
Page 33 and 34: 3 Saving and Restoring Data 3.1 Arc
Page 35 and 36: 3.1.5 Destination 3.1.6 Drives 3.1.
Page 37 and 38: 3.1.12 Volume Sets Saving and Resto
Page 39 and 40: 3.2.5 Staging 3.2.6 Catalog Save En
Page 41 and 42: • Save Type - Copied from related
Page 43 and 44: Example 3-4 Staging Information in
Page 45 and 46: 3.4.3 Compression 3.4.4 Data Safety
Page 47 and 48: Saving and Restoring Data 3.4 Envir
Page 49 and 50: Saving and Restoring Data 3.5 Saves
Page 53 and 54: Table 3-3 Disk, File, Path and Data
Page 59 and 60: • First disk/file specification p
Page 61 and 62: 3.5.17.1 HOLIDAYS.DAT Record Format
Page 63 and 64: Saving and Restoring Data 3.6 Selec
Page 65 and 66: 3.7.2 Command 3.7.3 Restriction Sav
Page 67: 3.7.5 Include and Exclude 3.7.6 Tim
Page 70 and 71: Media Management 4.2 Domain 4.2.1 A
Page 72 and 73: Media Management 4.2 Domain 4.2.15
Page 74 and 75: Media Management 4.3 Drives 4.3.5 D
Page 76 and 77: Media Management 4.3 Drives 4.3.15
Page 78 and 79: Media Management 4.5 Jukeboxes 4.5.
Page 80 and 81: Media Management 4.5 Jukeboxes 4.5.
Page 82 and 83: Media Management 4.7 Magazines 4.6.
Page 86 and 87: Media Management 4.11 Volumes 4.10.
Page 88 and 89: Media Management 4.11 Volumes Table
Page 92 and 93: Media Management 4.11 Volumes neede
Page 94 and 95: Media Management 4.11 Volumes • R
Page 99 and 100: 5 Security The security model used
Page 101 and 102: Security 5.1 MDMS Rights Table 5-1
Page 103 and 104: Table 5-4 Domain Access Control Opt
Page 105 and 106: 6 User Interfaces ABS and MDMS supp
Page 107 and 108: 6.1.3 Logging In User Interfaces 6.
Page 109 and 110: User Interfaces 6.1 Graphical User
Page 113 and 114: Figure 6-5 Domain View Showing Expa
Page 117 and 118: 6.1.13 Viewing MDMS Audit and Event
Page 119 and 120: 6.2.1 Syntax Overview User Interfac
Page 121 and 122: User Interfaces 6.3 User Interface
Page 123 and 124: 7 Preparing For Disaster Recovery I
Page 125 and 126: 7.1.2 Backup of MDMS$ROOT Preparing
Page 127 and 128: 7.2 Prolog and Epilog Procedure Pre
Page 129 and 130: 7.2.1 Restoring The System Disk To
Page 131 and 132: 8 Remote Devices 8.1 RDF Installati
Page 133 and 134: Remote Devices 8.4 Monitoring and T
Page 135 and 136:
8.4.4 Changing Network Parameters f
Page 137 and 138:
• Free Space is 20 Remote Devices
Page 139 and 140:
Remote Devices 8.5 Controlling Acce
Page 141:
Remote Devices 8.7 RDF Error Messag
Page 144 and 145:
System Backup to Tape for Oracle Da
Page 146 and 147:
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Virtual Library System (VLS) 10.3 Q
Page 176 and 177:
Architecture 11.1 The Server Proces
Page 178 and 179:
Architecture 11.2 Scheduler Interfa
Page 180 and 181:
Architecture 11.3 Catalogs Example
Page 182 and 183:
Architecture 11.4 Coordinator 11.4.
Page 184 and 185:
Troubleshooting 12.2 Media Manageme
Page 186 and 187:
Troubleshooting 12.2 Media Manageme
Page 188 and 189:
Troubleshooting 12.4 ABS Catalogs 1
Page 190 and 191:
Troubleshooting 12.5 Windows and Un
Page 192 and 193:
Troubleshooting 12.6 RDF (Remote De
Page 195 and 196:
A Configuration Example Getting ABS
Page 197 and 198:
Configuration Example * Magazine -
Page 199 and 200:
Configuration Example Configuring s
Page 201 and 202:
Configuration Example If you comple
Page 203 and 204:
Configuration Example Assist: YES C
Page 205 and 206:
B Migrating from SLS/MDMS V2.X to A
Page 207 and 208:
Migrating from SLS/MDMS V2.X to ABS
Page 209 and 210:
Table B-1 SBK Symbols in ABS Termin
Page 211 and 212:
Page 213 and 214:
Page 215 and 216:
Page 217 and 218:
Page 219 and 220:
Page 221 and 222:
Page 223 and 224:
Page 225 and 226:
Page 227 and 228:
Page 229 and 230:
Page 231 and 232:
Page 233 and 234:
Page 235 and 236:
Page 237 and 238:
Page 239 and 240:
Page 241 and 242:
Page 243 and 244:
$ WRITE EpilogComFile - Migrating f
Page 245 and 246:
Table B-6 Execution Environment Par
Page 247 and 248:
• SAVE Migrating from SLS/MDMS V2
Page 249 and 250:
Page 251 and 252:
Page 253 and 254:
Page 255 and 256:
Solution - Follow these steps: Migr
Page 257 and 258:
C Prev3 Support Prev3 Support is pr
Page 259 and 260:
Prev3 Support C.2 Using SLS as the
Page 261:
Prev3 Support C.2 Using SLS as the
Page 264 and 265:
Upgrading from ABS V2.X/V3.X to V4.
Page 266 and 267:
Upgrading from ABS V2.X/V3.X to V4.
Page 268 and 269:
ABS/MDMS Support for Fibre Channel
Page 270 and 271:
ABS/MDMS Support for Fibre Channel
Page 273 and 274:
Index Numerics 100 times per day 3-
Page 275 and 276:
MDMS$SBT_ ARCHIVE_n 9-20 MDMS$SBT_
Page 277:
volumes 3-4 W WARNING 3-14, 3-31 WE
show all

HP Archive Backup System for OpenVMS Guide to Operations

Create successful ePaper yourself

Delete template?

Save as template?