Computer Drive User Manual
Table Of Contents
- Chapter 1. HPSS 7.1 Configuration Overview
- Chapter 2. Security and System Access
- Chapter 3. Using SSM
- 3.1. The SSM System Manager
- 3.2. Quick Startup of hpssgui
- 3.3. Configuration and Startup of hpssgui and hpssadm
- 3.4. Multiple SSM Sessions
- 3.5. SSM Window Conventions
- 3.6. Common Window Elements
- 3.7. Help Menu Overview
- 3.8. Monitor, Operations and Configure Menus Overview
- 3.9. SSM Specific Windows
- 3.10. SSM List Preferences
- Chapter 4. Global & Subsystem Configuration
- 4.1. Global Configuration Window
- 4.2. Storage Subsystems
- 4.2.1. Subsystems List Window
- 4.2.2. Creating a New Storage Subsystem
- 4.2.3. Storage Subsystem Configuration Window
- 4.2.3.1. Create Storage Subsystem Metadata
- 4.2.3.2. Create Storage Subsystem Configuration
- 4.2.3.3. Create Storage Subsystem Servers
- 4.2.3.4. Assign a Gatekeeper if Required
- 4.2.3.5. Assign Storage Resources to the Storage Subsystem
- 4.2.3.6. Create Storage Subsystem Fileset and Junction
- 4.2.3.7. Migration and Purge Policy Overrides
- 4.2.3.8. Storage Class Threshold Overrides
- 4.2.4. Modifying a Storage Subsystem
- 4.2.5. Deleting a Storage Subsystem
- Chapter 5. HPSS Servers
- 5.1. Server List
- 5.1. Server Configuration
- 5.1.1. Common Server Configuration
- 5.1.1. Core Server Specific Configuration
- 5.1.2. Gatekeeper Specific Configuration
- 5.1.3. Location Server Additional Configuration
- 5.1.4. Log Client Specific Configuration
- 5.1.1. Log Daemon Specific Configuration
- 5.1.2. Migration/Purge Server (MPS) Specific Configuration
- 5.1.3. Mover Specific Configuration
- 5.1.3.1. Mover Specific Configuration Window
- 5.1.3.1. Additional Mover Configuration
- 5.1.3.1.1. /etc/services, /etc/inetd.conf, and /etc/xinetd.d
- 5.1.3.1.2. The Mover Encryption Key Files
- 5.1.3.1.3. /var/hpss/etc Files Required for Remote Mover
- 5.1.3.1.1. System Configuration Parameters on IRIX, Solaris, and Linux
- 5.1.3.1.1. Setting Up Remote Movers with mkhpss
- 5.1.3.1.2. Mover Configuration to Support Local File Transfer
- 5.1.1. Physical Volume Repository (PVR) Specific Configuration
- 5.1.1. Deleting a Server Configuration
- 5.1. Monitoring Server Information
- 5.1.1. Basic Server Information
- 5.1.1. Specific Server Information
- 5.1.1.1. Core Server Information Window
- 5.1.1.1. Gatekeeper Information Window
- 5.1.1.1. Location Server Information Window
- 5.1.1.2. Migration/Purge Server Information Window
- 5.1.1.3. Mover Information Window
- 5.1.1.1. Physical Volume Library (PVL) Information Window
- 5.1.1.2. Physical Volume Repository (PVR) Information Windows
- 5.1. Real-Time Monitoring (RTM)
- 5.2. Starting HPSS
- 5.1. Stopping HPSS
- 5.2. Server Repair and Reinitialization
- 5.1. Forcing an SSM Connection
- Chapter 6. Storage Configuration
- 6.1. Storage Classes
- 6.2. Storage Hierarchies
- 6.3. Classes of Service
- 6.4. Migration Policies
- 6.5. Purge Policies
- 6.6. File Families
- Chapter 7. Device and Drive Management
- Chapter 8. Volume and Storage Management
- 8.1. Adding Storage Space
- 8.2. Removing Storage Space
- 8.3. Monitoring Storage Space
- 8.4. Dealing with a Space Shortage
- 8.5. Volume Management
- 8.6. Monitoring and Managing Volume Mounts
- 8.7. New Storage Technology Insertion
- Chapter 9. Logging and Status
- Chapter 10. Filesets and Junctions
- Chapter 11. Files, Directories and Objects by SOID
- Chapter 12. Tape Aggregation
- Chapter 13. User Accounts and Accounting
- Chapter 14. User Interfaces
- Chapter 15. Backup and Recovery
- Chapter 16. Management Tools
“full”, “incremental”, or “delta”. Full backups record the full contents of the database at a point in time.
Incremental backups record all the changed data since the last full backup. Delta backups record only the
data that has changed since the most recent backup (of any type). Obviously, a full backup is necessary as
a starting point in the recovery of a database. Incremental and delta backups help reduce the number of
transaction logs that must be retrieved and applied during a restore operation.
Consider a site that keeps the following schedule for backing up a database:
Sunday: full
Monday: delta
Tuesday: delta
Wednesday: incremental
Thursday: delta
Friday: delta
Saturday: delta
Under this scheme, if the database fails between the Thursday and Friday backups, only a few backup
images would be needed for a restore: Sunday's full backup is needed as a starting point. Wednesday's
incremental backup includes all changes since Sunday, so it makes retrieval of Monday's and Tuesday's
backups unnecessary. Beyond that, Thursday's delta backup is needed, as well as any transaction logs
archived after Thursday's backup. So the needed images are: Sunday, Wednesday, Thursday, and only
those logs between Thursday's backup and the point of failure.
The way DB2's backup and restore commands are implemented makes restoration simple. Basically, only
the latest backup image needs to be specified. DB2 records the backup history in each backup, so it can
determine which images and logs are necessary. Assuming an automated method is used for backup
storage and retrieval, it can also fetch the images and restore from them. See the DB2 Data Recovery
Guide for details.
15.1.2.1. Configuring DB2 for Online Backup
Several steps must be taken to prepare a DB2 database for online backup. Initially, a newly-created
database is configured to perform offline backups. The database's configuration must be updated to
indicate that subsequent backups should be made online. An initial, offline backup must then be made as
a starting point for the backup process. The database will be inoperative until this initial full backup is
completed. So an outline of the major steps to set up a database for online backup is:
1. Configure backup software and make certain data can be archived into it and retrieved from it.
2. Update the database configuration to enable log archiving, this will place the database in "backup
pending" state.
3. Perform initial full, offline backup (database returns to normal state).
4. Schedule subsequent backups using cron.
To start a DB2 backup, invoke the “db2 backup” command line interface. Typically, the administrator
would put this command into a script along with any necessary parameters to indicate the type of backup,
destination, etc. The script would then be invoked from cron.
For details on configuring DB2 for backup, administrators should consult the DB2 Data Recovery Guide
as well as the documentation for their backup software.
HPSS Management Guide November 2009
Release 7.3 (Revision 1.0) 358