storage migrator unixadmin
TRANSCRIPT
VERITAS Storage Migrator™ 4.5
System Administrator’s Guide
for UNIX
March 200230-000704-011
Disclaimer
The information contained in this publication is subject to change without notice. VERITAS Software Corporation makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. VERITAS Software Corporation shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual.
Copyright
Copyright © 1994-2002 VERITAS Software Corporation. All Rights Reserved. VERITAS, VERITAS SOFTWARE, the VERITAS logo, Business Without Interruption, VERITAS The Data Availability Company, VERITAS NetBackup, VERITAS NetBackup BusinesServer, VERITAS Remote Storage for Microsoft Exchange, VERITAS Cluster Server, VERITAS Storage Migrator, and VERITAS Storage Migrator Remote are trademarks or registered trademarks of VERITAS Software Corporation in the U.S. and/or other countries. Other product names mentioned herein may be trademarks or registered trademarks of their respective companies.
VERITAS Software Corporation.350 Ellis Street.Mountain View, CA 94043 Phone 650.527.8000 Fax 650.527.8050 http://www.veritas.com
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Audience and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxii
Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxii
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Type Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Notes and Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Key Combinations and Pulldown Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
Command Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
Chapter 1. About VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Administrative Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
User Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
NetBackup Requirement with VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
VSM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Basic Migration Operations and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
VSM Activity States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
File Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Select Files to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Assign a File Handle and Create Database Entries . . . . . . . . . . . . . . . . . . . . . . . . 10
Assign the Storage Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Create Migration Work Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
i
Copy Files to Secondary Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Update the VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
File Slices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Total File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Partial File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Directory-level Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Tape and Optical Volume Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Migration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Migration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The migbatch Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The mignospace Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
The miglow Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
User Migration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
The migrate Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
The migpurge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Accelerated Disk Space Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Constant Sweeps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Multilevel Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
File Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Select Files to Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
File Handles, Storage Methods, and Work Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Copy to Next Migration Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Update VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Clean Up, FHDB and VOLDB Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
File Export/Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
VSM System Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Managed File System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Databases, Work Files, Logs, and Binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Files in dwpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
ii VERITAS Storage Migrator System Administrator’s Guide for UNIX
Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Global Configuration File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Remote Volume Server Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Chapter 2. Planning VSM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
VSM Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Managed File Systems in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
File Systems to Manage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
File Systems Not to Manage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
VSM and Macintosh File Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Notes on Samba Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Number of Files and Inodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
VSM Databases in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Files in Database Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
FHDB and FNDB Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
FHDB and FNDB Space Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Inode-to-Handle File Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Total Database Space Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Log File Pathnames in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
VSM States, Space Management, and Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
States other than Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Migration Schedules in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Best Times for Migrating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
How Often to Migrate Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Time Required to Complete Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Migration Schedule Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Schedules for Report Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Completing the Global Configuration Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Managed File System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Contents iii
Initial Configuration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Storage Levels for Migrating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Method Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Tape Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Optical Disk Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Disk Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Remote FTP Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
NetBackup Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Volume Set Availability (hint value) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Volume Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Concurrent Stripes / Concurrent Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Choosing the Best Storage Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Volume Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Storage Levels for Moving Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
General File System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Slice Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Quota on Migration Stop Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Partial File Caching Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Accelerated Disk Space Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Criteria for Migrating Files (Water Marks) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Desired Percentage Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Desired Percentage Purged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Desired Percentage of Free Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Criteria for Selecting Files to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
How VSM Selects Files to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Procedure for Setting File Migration Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Criteria for Purging Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Criteria for Moving Migrated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Customizing Migration, Purging, and Moving Criteria . . . . . . . . . . . . . . . . . . . . . . . . . 84
Example Planning Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
iv VERITAS Storage Migrator System Administrator’s Guide for UNIX
Chapter 3. VSM-Java Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
About the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Administration Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Left Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Right Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Bottom Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Administration Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Change Server Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Basic Configure Wizard Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Advanced Configure Wizard Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Database Configuration Wizard Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
New Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Delete Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Change Properties Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
File Browser Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
File System Analyzer Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Refresh Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Administration Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
File Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Edit Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Volume Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Managing Jobs on the Activity Table (Bottom Pane) . . . . . . . . . . . . . . . . . . . . . . 99
Actions Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Management Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
VSM Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Help Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Contents v
Chapter 4. Configuring VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Basic Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Basic Configuration - Select File System Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Basic Configuration - Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Basic Configuration - Select Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Basic Configuration - Properties Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Basic Configuration - Select Local Device Properties Dialog . . . . . . . . . . . . . . 107
Setting up VSM Volumes Using Media Manager . . . . . . . . . . . . . . . . . . . . . . . . 108
Basic Configuration - Select Remote Server Properties Dialog . . . . . . . . . . . . . 109
Basic Configuration - Select Alternate Disk Properties Dialog . . . . . . . . . . . . . 110
Basic Configuration - Select NetBackup Properties Dialog . . . . . . . . . . . . . . . . 111
Basic Configuration - Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . . . . 112
Advanced Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Advanced Configuration - Select File System Dialog . . . . . . . . . . . . . . . . . . . . . . . 114
Advanced Configuration - Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Advanced Configuration - Hierarchy Properties Dialog . . . . . . . . . . . . . . . . . . . . 116
Advanced Configuration - New Level Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Advanced Configuration - New Stripe Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Advanced Configuration - Stripe Properties Dialogs . . . . . . . . . . . . . . . . . . . . . . . 118
Stripe Properties Dialog for Tape and Optical Media . . . . . . . . . . . . . . . . . . . . 119
Stripe Properties Dialog for Alternate Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Stripe Properties Dialog for FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Stripe Properties for NetBackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Advanced Configuration - Volume Registration Dialogs . . . . . . . . . . . . . . . . . . . . 124
Volume Properties Dialog for Tape and Optical Media . . . . . . . . . . . . . . . . . . 124
Volume Properties Dialog for Alternate Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Volume Properties Dialog for FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Volume Properties Dialog for NetBackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Advanced Configuration - Alternate Level Dialogs . . . . . . . . . . . . . . . . . . . . . . . . 129
Advanced Configuration - File System Properties Dialog . . . . . . . . . . . . . . . . . . . 129
vi VERITAS Storage Migrator System Administrator’s Guide for UNIX
File System Properties - General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
File System Properties - Additional Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
File System Properties - Water Marks Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
File System Properties - Migration Criteria and Purge Criteria Tabs . . . . . . . . 133
Advanced Configuration - Committing Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Database Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Database Configuration - Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Database Configuration - Select Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Database Configuration - Select Properties Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . 138
Select Local Device Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Select Remote Server Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Select Alternate Disk Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Select NetBackup Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Database Configuration - Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . 144
Editing the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Adding to Configured Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Adding Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Adding Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Adding Stripes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Editing Existing Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Editing Hierarchy Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Editing File System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Editing Level Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Editing Stripe Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Chapter 5. VSM-Java Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Managing Oracle Archive Redo Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Oracle Archive Redo Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Database Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Manage Archive Redo Logs Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Contents vii
Manage Redo Log Files Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Reporting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Starting the Reporting Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Reporting Tool Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Reporting Tool Pull-Down Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Setting Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Server Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Managed File System Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Response Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Performance Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
File Manipulation with the File Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
File Browser Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
File Browser Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
File Browser Pull-down Menus and Tool Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
File Browser Left Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
File Browser Right Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
File Browser Bottom Pane and View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
File Browser Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Directory Groups Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Migration... Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Scheduling Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Scheduling Tool Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Component Configuration Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Configuring Schedule Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Restarting a Task within Its Time Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Time Windows that Extend Past Midnight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Viewing a Schedule Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
File System Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
File System Analyzer Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
File System Analyzer Pull-down Menus and Tool Bar . . . . . . . . . . . . . . . . . . . . . . 181
viii VERITAS Storage Migrator System Administrator’s Guide for UNIX
Using the File System Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Experimenting with Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Deleting Previous Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Chapter 6. Managing VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Backing up VSM Databases and Managed File Systems . . . . . . . . . . . . . . . . . . . . . . . . 190
Backing up VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
General VSM Backup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Starting VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Customizing Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Shutting down VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Starting and Stopping VSM Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Powering down Remote Volume Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Setting up Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Administering Inode-to-Handle (IHAND) Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Setting up fstab/vfstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Global Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Scheduling Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Managing Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Monitoring Volume Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Keeping a Supply of Unused Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Cleaning nb Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Consolidating Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
One-Step Volume Consolidation with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . 207
Command-line One-Step Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Command-line Two-Step Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Recycling Empty Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Removing Tape or Optical Volumes for Offline Storage . . . . . . . . . . . . . . . . . . . . . 214
Moving Files to a New Volume Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Contents ix
Deleting Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Duplicating a Tape Volume from Migrated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Managing Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Controlling Global Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
General Rules for VSM Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Syntax Rules for VSM Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Control File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Scheduling Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Invoking Migration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Migrating Files to Secondary Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Managing the Free Space Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Making More Disk Space Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Move Files between Migration Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Customize the VSM Policy and Method for Migrating Files . . . . . . . . . . . . . . 227
Reconfiguring Storage Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Performance Tuning with Tape Marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Performance Tuning with Constant Sweeps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Moving Migrated Files (Export and Import) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Planning File Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Planning File Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Managing VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Databases on a VSM server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
File Handle Database (FHDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
File Name Database (FNDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Volume Database (VOLDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Work Lists (copydb files) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Destination Volume Database (DVDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
FHDB Lock File (FHDB.LK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
File Handle Sequence File (FHSEQF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Volume Database Lock File (VOLDB.LK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
x VERITAS Storage Migrator System Administrator’s Guide for UNIX
Volume Sequence File (VOLSEQF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Next-Volume-Set Files (NEXTVOLM1...NEXTVOLM8) . . . . . . . . . . . . . . . . . . 242
The migsweep.site and migsweepm.site files . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
migconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Inode to Handle File (IHAND) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
FLUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
ID_LABEL Databases on a Remote Volume Server . . . . . . . . . . . . . . . . . . . . . . . . . 244
Solving Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Viewing Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Viewing Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Automatic Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Searching Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Managing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Setting the Logging Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Making Log Files Smaller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Creating the VSM-Java Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Changing VSM States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Media and Database Information and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Database Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Fixing FHDB Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Clearing FHDB Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Fixing the Volume Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Recovering File Handle and Volume Databases . . . . . . . . . . . . . . . . . . . . . . . . . 254
Cannot Find Next File Handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Restoring Managed File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Extending Managed File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
File and Migration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Reloading Deleted Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Restarting Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Migrating, Purging, or Accessing Files Does Not Occur . . . . . . . . . . . . . . . . . . 259
Contents xi
Releasing VSM Tape Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Having No Volumes Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Appendix A. Man Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
fls(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
gethsm(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
HSMKiller(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
ihprint(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
mediacheck(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
migactivate(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
migadscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
migalter(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
migbatch(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
migcat(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
migchecklog(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
migcleanup(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
migconf(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
migconfg(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
migcons(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
migconsweep(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
migdbcheck(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
migdbconvert(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
migdbdir(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
migdbrpt(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
migfind(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
migftscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
miggetvol(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
miggroup(1), migungroup(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
migin(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
miglicense(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
xii VERITAS Storage Migrator System Administrator’s Guide for UNIX
migloc(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
miglow(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
migmdclean(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
migmove(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
mignbexport(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
mignbimport(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
mignbscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
mignewlog(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
mignospace(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
migpolicy(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
migpurge(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
migrate(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
migrc(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
migrd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
migreconstruct(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
migrecycle(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
migreg(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
migselect(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
migsetdb(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
migstage(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
migtestbadness(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
migtie(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
migtscan(1M), migopscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
migunmigrate(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
migVSMshutdown(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
migVSMstartup(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
migVSMstate(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
rebuild_ihand(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
startmigd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
stopmigd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Contents xiii
stopmigrd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
VSM(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Appendix B. Enterprise Agent for Storage Migrator . . . . . . . . . . . . . . . . . . . . . . . . 441
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Pre-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Import Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
VSM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Agent Configuration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Manual Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Manual Active-Active Configuration using FTP . . . . . . . . . . . . . . . . . . . . . . . . 450
Manual Active-Inactive Configuration using NetBackup . . . . . . . . . . . . . . . . . 453
Sample Configuration File Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Maintaining Your System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Removing the Enterprise Agent for Storage Migrator . . . . . . . . . . . . . . . . . . . . . . . . . 458
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Appendix C. Notes on Supported Optical Media . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
xiv VERITAS Storage Migrator System Administrator’s Guide for UNIX
Figures
Basic VSM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Basic VSM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
File Migration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
File Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Total File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Partial File Caching, Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Partial File Caching, Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Media Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Migration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Migrating Files with migbatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Making Space Available with mignospace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Checking Free Space with miglow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Default Configuration for Multilevel Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
File Movement Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Managed File System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
VSM File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Global Configuration File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Remote Volume Server Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Concurrent Recording of Multiple Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Low-Water Mark and Purge Mark Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Minimum Age, Minimum Size, and Threshold Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Threshold Example 1 (threshold = 30) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Threshold Example 2 (threshold=90) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
xv
Threshold Example 3 (threshold=90, cut to threshold=45) . . . . . . . . . . . . . . . . . . . . . . . . . 80
Selection Criteria for Moving Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Global Configuration Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Managed File System Configuration Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
VSM-Java Main Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Login Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Components of the VSM-Java Main Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Edit Menu When Server Is Selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Bottom Pane Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Right Pane Displaying Activity Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Toolbar when Server Is Highlighted and some File Systems not Configured . . . . . . . . . . 95
Toolbar when Hierarchy Is Highlighted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
VSM-Java Menu Bar when Hierarchy Is Highlighted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Edit Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
View Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Select Filesystem Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Basic Configuration Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Select Storage Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Local Device Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Remote Server Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Alternate Disk Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
The NetBackup Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Select Filesystem Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Advanced Configuration Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Hierarchy Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
The New Level Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
The New Stripe Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
General Tab, Stripe Properties Dialog for Tape and Optical Disk . . . . . . . . . . . . . . . . . . . 119
Physical Tab, Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
xvi VERITAS Storage Migrator System Administrator’s Guide for UNIX
Timeout Tab, Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Alternate Disk Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
FTP Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
NetBackup Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Primary Volume Registration Dialog, FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Primary Volume Registration Dialog - NetBackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
New Level Dialog, Alternate Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
General Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Additional Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Water Marks Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Migration Criteria Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Purge Criteria Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Login Dialog, Database Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Database Configuration Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Select Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Select Local Device Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Select Remote Server Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Select Alternate Disk Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Select NetBackup Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Database Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Edit > Change Hierarchy Properties Selection and Resulting Display . . . . . . . . . . . . . . . 148
Edit > Change Filesystem Properties Selection and Resulting Display . . . . . . . . . . . . . . . 149
Edit > Change Level Properties Selection and Resulting Display . . . . . . . . . . . . . . . . . . . 149
Edit > Change Level Properties Selection and Resulting Display . . . . . . . . . . . . . . . . . . . 150
Components of the Manage Archive Redo Logs Main Dialog . . . . . . . . . . . . . . . . . . . . . . 154
Manage redo log files Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Reporting Tool Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
File System Trends as Bar Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
File Browser Main Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
File Browser Actions > Migration Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
xvii
Schedule Jobs Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
File System Analyzer Main Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Number by access time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Number by modification time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Number by size Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Size by access time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Size by modification time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Size by size Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
What If File System Analyzer Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Writing and Obsoleting Files on Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Selecting a Full Volume to Consolidate with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
One-Step Consolidation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Two-Step Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Selecting an Empty Volume to Recycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Selecting a Volume to Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Files Affected by Example Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Premigrating Files with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Managing the Free Space Threshold with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Purging Files with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Moving Migrated Files with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
VSM Global Log File View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Managed File System Log File View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Searching in the Global Log File View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Sample Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Dependencies for Active-Active Configuration with FTP . . . . . . . . . . . . . . . . . . . . . . . . . 451
Dependencies for Active-Inactive Configuration with NetBackup . . . . . . . . . . . . . . . . . . 454
xviii VERITAS Storage Migrator System Administrator’s Guide for UNIX
Tables
Typographic Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Storage Method Possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
File Browser Icons Used in Left and Right Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Startup/Shutdown Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Initial Set of Migrating Candidates in Control File Example . . . . . . . . . . . . . . . . . . . . . . . . 220
Migration Candidates in Control File Example when Local .migstop Exists . . . . . . . . . . 221
FHDB Entry Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
FNDB Entry Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
VOLDB Entry Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Work List (copydb) Entry Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Commands for Media and Database Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Components and Resources for Enterprise Agent for Storage Migrator . . . . . . . . . . . . . . 442
Operations for the StorageMigrator Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Operations for the StorageMigratorFS Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Supported Optical Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
xix
xx VERITAS Storage Migrator System Administrator’s Guide for UNIX
Preface
This guide describes how to configure and manage VERITAS Storage Migrator (VSM) release 4.5.
VSM runs on Solaris, HP-UX, and SGI IRIX. The VSM-Java interface runs on Solaris, HP-UX, and Windows. For specific information about supported hardware and operating systems for this software, see the VERITAS Storage Migrator Release Notes for UNIX.
Audience and Scope This guide is intended for system administrators. Its purpose is to explain how to configure and manage VSM on a UNIX platform.
This guide assumes that you have the following experience:
◆ A basic understanding of system administration
◆ A good working knowledge of the UNIX operating system
◆ A basic understanding of storage management principles
See the VERITAS Storage Migrator Installation Guide for UNIX for information about installation.
OrganizationRead the following chapters in numerical order unless advised to see a specific section:
◆ “About VSM” on page 1 is a general overview of VSM; it tells you what the product does.
◆ “Planning VSM Configuration” on page 45 provides information about developing a migration policy for your site.
◆ “VSM-Java Overview” on page 89 describes the basics of the VSM-Java interface.
◆ “Configuring VSM” on page 103 describes how to configure VSM using the VSM-Java interface.
xxi
Related Documents
◆ “VSM-Java Tools” on page 151 describes the VSM-Java tools that help you maintain VSM managed files systems.
◆ “Managing VSM” on page 189 describes how to maintain and complete daily operations on VSM and file systems it manages.
◆ “Man Pages” on page 261 contains copies of all VSM man pages (command reference).
◆ “Enterprise Agent for Storage Migrator” on page 441 describes how to configure VSM in failover mode with the Enterprise Agent for Storage Migrator.
Related Documents◆ The VERITAS Storage Migrator Release Notes for UNIX lists the supported platforms
and operating systems and describes new features and problems fixed in this release.
◆ The VERITAS Storage Migrator Installation Guide for UNIX describes how to install and configure a test system.
◆ The NetBackup Release Notes provide important information about supported platforms, operating systems, and peripheral storage equipment.
◆ The NetBackup DataCenter Installation Guide for UNIX describes how to install NetBackup.
◆ The NetBackup Media Manager Device Configuration Guide for UNIX describes how to configure storage devices controlled by Media Manager.
◆ The NetBackup DataCenter Media Manager System Administrator’s Guide for UNIX describes Media Manager, its components, and how they are used to manage media volumes, drives, and robots.
AccessibilityVSM contains features that make the user interface easier to use by people who are vision impaired and by people who have limited dexterity. Accessibility features include the following:
◆ Support for assistive technologies such as screen readers and voice input software (Windows NT/2000 only)
◆ Support for keyboard (mouseless) navigation using accelerator keys and mnemonic keys
More information on these features are included in the release notes.
xxii VERITAS Storage Migrator System Administrator’s Guide for UNIX
Conventions
Conventions This section explains typographical and other conventions used in this guide.
Note In this publication, the term Media Manager refers to the media management software that is part of NetBackup. The term volume refers to storage media such as tape or optical disk.
Type Style
Notes and Cautions
Note This is a Note. It is used to call attention to information that makes it easier to use the product or helps you to avoid problems.
Caution This is a Caution. It is used to warn you about situations that can cause data loss.
Typographic Conventions
Typeface Usage
Bold fixed width Input. For example, you might see, “Type cd to change directories.”
Fixed width Paths, commands, filenames, or output. For example, you might see, “The default installation directory is /opt/VRTSxx.”
Italics Book titles, new terms, or used for emphasis. For example, you might see, “Do not ignore cautions.”
Sans serif (italics) Placeholder text or variables. For example, you might see, “Replace filename with the name of your file.”
Bold type (no italics) Graphical user interface (GUI) objects, such as fields or menu choices.
For example, you might see, “Enter your password in the Password field.”
Preface xxiii
Getting Help
Key Combinations and Pulldown MenusSome keyboard command sequences use two or more keys at the same time. To describe this sequence, the keys are connected by plus signs, as follows:
Press Ctrl+t
Pulldown menus often require you to make more than one selection from a menu. To describe a sequence of menus meant to be selected together, the menus are connected by a greater than sign (>), as follows:
Select Edit > New Stripe
Command UsageThe following conventions are frequently used in the synopsis of command usage.
brackets [ ]
The enclosed command line component is optional.
Vertical bar or pipe (|)
Separates optional arguments from which the user can choose. For example, it is used when a command has the following format:
command arg1|arg2
The user can use either the arg1 or arg2 variable.
Getting Help◆ For updated information about this product, including system requirements,
supported platforms, supported peripherals, and a list of current patches available from Technical Support, visit our web site:
http://support.veritas.com/
◆ VERITAS Customer Support can be reached through email, as follows:
xxiv VERITAS Storage Migrator System Administrator’s Guide for UNIX
About VSM
1VERITAS VSM (VSM) is a hierarchical storage management product that increases the amount of disk space available to users. To manage file space, VSM migrates files from a local UNIX file system to secondary storage as space is needed in the local file system. This local UNIX file system is referred to as a managed file system. VSM-Java, the graphical administration and management interface to VSM, refers to a managed file system and its configured attributes as a hierarchy.
A managed file system is generally known by its hsmname, which is the name you provide for it during configuration.
Note Usually, the hsmname is the same as the file system mount point.
An hsmname has a maximum length of 32 characters. In VSM-Java, you can enter a maximum of 14 characters. Names longer than 32 characters may overwrite other data, with unpredictable results.
When a user accesses a migrated file, it is automatically retrieved from secondary storage and cached in the online file system. Except for the delay to perform the retrieval, users and programs are unaware that file migration and retrieval are taking place.
VSM is implemented using the standard Data Management Application Programming Interface (DMAPI) and an inode-to-handle (IHAND) file.
VSM stores data on directly connected tape, optical disk, magnetic disk devices, or remote volume servers. Media Manager provides the interface to tape and optical storage devices. Support for large-capacity library devices with robotic access mechanisms eliminates the need for operator action to either migrate or cache files. The net result is apparently unlimited online storage that uses low-cost media.
VSM offers several storage methods (the method name is in parentheses):
◆ Disk file for premigration (dk)
◆ Alternate magnetic disk (ad)
◆ Tape (ct, dt, and mt)
◆ Optical disk as tape with random seek (op and ow)
1
◆ Remote migration using FTP (ft)
◆ Migration integrated with NetBackup (nb)
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
VSM shares secondary storage devices with NetBackup through the use of a common Media Manager.
The VSM server performs the following tasks:
◆ Holds managed file systems
◆ Executes the server component of VSM
◆ If configured, communicates with a remote volume server using NFS (ad method) or FTP (ft method). Remote volume servers hold remote volumes VSM uses.
The figure “Basic VSM Configuration” shows a managed file system residing on the managed server. The VSM server migrates files to local optical and tape volumes using op, ow, ct, dt, or mt migration methods. This managed server also migrates files to a remote volume server using the ft, ad, or nb methods. (A second copy of VSM can be, but is not required to be, running on the remote volume server.)
Basic VSM Configuration
Remote volumes
Remote volume server
Managed file system
(ft, ad, and nb
methods)
(ct, dt, and mt methods)
Local optical volumes
Local tape volumesVSM server
(op and ow methods)
2 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Administrative Controls
VSM completes the following steps in its migration process:
1. Selects migration candidates according to predefined selection criteria.
2. Premigrates the files by associating them with migration identifiers in its databases, and placing them on a work list of files that can be migrated.
3. Copies the premigrated files to one or more secondary storage devices, which means that files are actually migrated. The files remain available on disk. They are ready to be purged and are referred to as purge candidates.
VSM deletes purge candidates when the managed file system uses disk space up to a configured threshold. The file names and attributes of these migrated files remain in users’ directories, and information about each migrated file (size, number of copies VSM made, location, and type of media for each copy) resides in VSM databases on the server.
If users access migrated files, VSM makes them available by recalling, or caching, the data back to disk. Often users have no idea the files reside somewhere other than local disk.
VSM can use an NFS-mounted file system as a secondary storage device. Although you can NFS-mount a VSM partition, VSM cannot directly manage an NFS-mounted file system. VSM can only manage file systems that are resident on the server on which VSM is installed.
Caution Mount NFS file systems in a dedicated subdirectory of the root directory. You cannot mount them in the root directory itself because VSM and other applications perform stat() operations on entries in the root directory to determine the path to the current working directory. The stat operation can block on an NFS mount point in the root directory itself if the NFS server is unreachable.
Administrative ControlsAs an administrator, you configure and manage VSM operation. You choose the file systems that VSM manages and tailor VSM to meet their migration requirements. For example, it makes sense to migrate small and frequently accessed files to optical disk and to migrate very large or infrequently accessed files to tape.
“Managing VSM” on page 189 describes management and operation in detail.
Areas that you can configure for each file system follow:
◆ Space thresholds at which VSM starts and stops migration.
◆ How VSM selects individual files to migrate and purge.
Chapter 1, About VSM 3
Administrative Controls
◆ Media on which VSM writes selected files, and how data is written on that media (for example, block sizes). The choice of media also implies the device using the media.
◆ Number of copies made of each migrated file
◆ How much of a migrated file remains on disk after the file is purged (the file slice).
◆ Registration of volumes on which to store each copy of the files.
◆ Whether or not to use concurrent recording to speed up migrations when multiple devices are available.
◆ Quota for the amount of space a user can restrict from migration.
◆ Number of migration levels to use.
After you have configured VSM, you can initiate and control file migrations using VSM-Java, at the system prompt, and by using the Scheduling tool. You can also add commands to startup scripts that will start and stop VSM. If you use such techniques, VSM requires little or no action outside of exception conditions.
You can control data migration in various ways:
◆ Make space available before you have problems by selecting and copying files to secondary storage, but also retaining the files on disk. If open file system space falls below configured limits, VSM will purge some or all of them to make space available.
◆ Check open file system space and keep it within configured limits. If space is below configured limits, VSM purges files it can or migrates and then purges additional files until it provides enough space.
◆ Activate and deactivate managed file systems.
◆ List which files you always want to migrate in a global migrate file, and list which files you never want to migrate in a global stop file.
◆ Enable constant sweeping of the managed file system to select migration candidates.
VSM also offers a comprehensive set of tools for managing the secondary media. These management capabilities include the following:
◆ Registering media for use with VSM
◆ Consolidating volumes to recover obsolete space
◆ Listing database information about all VSM volumes
◆ Scanning volumes and displaying information about their contents
◆ Displaying the location of a migrated file
◆ Validating database consistency
◆ Restoring lost files
◆ Reconstructing lost VSM databases
4 VERITAS Storage Migrator System Administrator’s Guide for UNIX
User Controls
◆ Moving migrated files to a new volume set
◆ Exporting migrated files (and volumes) to another managed file system
◆ Specifying how often file marks are written to tape
User ControlsYou can provide users some control over their file migrations and caches by allowing them to do the following:
◆ Premigrate files if they own the files or directories
◆ Delete purge candidates if they own the files or directories
◆ Specify which files they want to prevent from automatic migration by listing them in local stop files (.migstop)
◆ Specify which files they always want to migrate by listing them in local migrate files (.migrate)
◆ Force files in a directory to be migrated and cached together
◆ Read migrated data without caching files
◆ Display file information about migrated files. If a file is migrated, the fls command displays an m in the left column of the mode bit field and the machine ID and file handle on the right, as in the following example output:
mrw---x--- 1 lm 6123456 Dec 10 06:13 fileA [002c70c0 00005b3d]
If the same file is purged, a t also appears in the mode bit field, as follows:
mrw---x--t 1 lm 6123456 Dec 10 06:13 fileA [002c70c0 00005b3d]
If the file is cached back to disk but not modified, VSM removes the m and the t from the output. If the file is modified, it removes the m, t, machine ID, and file handle, as follows:
-rw---x--- 1 lm 6123456 Dec 19 08:43 fileA
The migloc command is more explicit. It defines a file’s migration status using the words Premigrated, Migrated, Purged, Cached, and Unmigrated.
To enable user permissions, you change file access permissions on command files, as described in the VERITAS Storage Migrator Installation Guide for UNIX.
Chapter 1, About VSM 5
NetBackup Requirement with VSM
NetBackup Requirement with VSMEven though VSM makes copies of your data, you must use NetBackup to backup the file names and attributes. The VSM server must be a NetBackup client, no matter what storage method VSM is using. Being a NetBackup client means that the server must have NetBackup client executables (bpbkar/tar) in the /usr/openv/netbackup/bin directory.
This configuration also means that the VSM server is a NetBackup client for backup to a NetBackup server. If the VSM server is also a NetBackup server, the necessary executables are installed when you install NetBackup. If the VSM server is only a NetBackup client, the appropriate binaries (executables) must be pushed by the NetBackup server.
VSM ArchitectureThe main elements of VSM architecture are as follows:
◆ Migration daemon (migd)
◆ Reload processor (migin)
◆ Media Manager
◆ Administrative tools to control the migration and cache processes (for example, migbatch and mignospace)
◆ Utilities for volume management (migvold) and database request (migrd) management
The migration daemon (migd) uses the DMAPI interface to communicate with the VERITAS VxFS file system on Solaris, the OnlineJFS file system on HP-UX, and the XFS file system on IRIX.
The following figure illustrates how these elements interact.
6 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM Architecture
Basic VSM Architecture
The migration daemon (migd) runs in user space. It processes both object events and file system events generated by the file system when a user references a migrated file.
Object events are as follows:
DM_EVENT_READ
DM_EVENT_WRITE
DM_EVENT_TRUNCATE
File system events are as follows:
DM_EVENT_NOSPACE
DM_EVENT_REMOVE
DM_EVENT_DESTROY (Solaris and HP-UX only)
DM_EVENT_UNMOUNT
The migd daemon registers to receive certain DMAPI events generated by the managed file system. It then calls the appropriate processor, based on the original request. For instance, on read and write requests, migd calls the reload processor (migin) to cache (recall) the requested file to disk. After migin finishes, migd sends a completion message to the kernel. The completion message causes the kernel to pass the original read or write request to the underlying UNIX file system for further processing.
The migd daemon checks the open disk space on the managed file system at set intervals that you can specify when you start the daemon. The default is 60 seconds.
The miglow or migbatch and mignospace commands manage open file system space by controlling migration and purging of files. During the migration process, migcopy copies files from the managed file system to secondary storage.
VxFS, XFS, orOnlineJFS File System
Administrative tools
migin
migd
Secondary Storage
Disk
DMAPI interface
Media Manager
Chapter 1, About VSM 7
Basic Migration Operations and Features
VSM records its activities in log files. The migd daemon records its activities in a VSM global log file. Other VSM processes use individual log files for managed file systems.
The migvold volume daemon unmounts Media Manager volumes mounted in read mode. VSM uses Media Manager to access tape or optical disk.
The migrd request daemon handles communication for VSM-Java and commands.
Basic Migration Operations and FeaturesBasic migration operations and features are described in the following sections:
◆ “VSM Activity States” on page 8
◆ “File Migration” on page 9
◆ “File Caching” on page 13
◆ “File Slices” on page 15
◆ “Total File Caching” on page 16
◆ “Partial File Caching” on page 17
◆ “Directory-level Migration” on page 20
◆ “Tape and Optical Volume Management” on page 21
VSM Activity StatesA mounted managed file system can be in any of the following five VSM activity states:
◆ Active: Available for all VSM operations. Purged files are cached. NetBackup can be used to back up and restore files. The migd daemon runs mignospace as necessary.
◆ Inactive: VSM activity cannot occur. Files cannot be cached or migrated.
◆ Idle: VSM has cleanly terminated operations. Files cannot be migrated or cached. The managed file system may be unmounted and the server shutdown.
◆ Idling: VSM is moving the managed file system from Active state to Idle state, but some operations are not yet complete. No new migrations or caches can be initiated.
◆ Maintenance: Maintenance activities (such as database cleanup) are allowed. Files cannot be cached. migd does not initiate mignospace.
You can view or change the state of a managed file system either in VSM-Java or by using the migVSMstate(1M) command. To see states in VSM-Java, highlight the VSM server or a specific managed file system in the Left Pane. The Status column in the Right Pane shows the VSM state. When the Status column is blank, the state is Active.
8 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
To change states, you can select Actions > File System > Set State and select a state or run the migVSMstate -s state hsmname. If you change the state to Idle, VSM first changes the state to Idling while operations complete and changes the state to Idle when operations are complete.
Use the VSM-Java Actions > File System > Kill HSM Processes for Filesystem selection or the migVSMshutdown command to stop VSM activities. You will need to stop all VSM activity if you make changes to the file system itself. For example, unmounting a managed file system requires that VSM activities stop.
Shutting down VSM through VSM-Java or migVSMshutdown will leave an Active file system in Idle state for reboot. These actions also shut down the VSM daemons.
All managed file systems should be in Idle state when the VSM server boots. The migVSMstartup command changes a managed file system in Idle state to Active or Inactive state, and it moves a file system in a state other than Idle to the Maintenance state.
As VSM comes up, some recovery operations take place (as described in the migVSMstartup man page). After migVSMstartup completes its processing, a file system will be in Active state or Inactive state if its space thresholds are within the configured limits and no problems were encountered during recovery. Otherwise, the managed file system state will be changed to Maintenance. Further recovery on a file system in Maintenance state must be carried out manually. After recovery is complete, manually change the state of the managed file system to Active using VSM-Java or migVSMstate. In VSM-Java, select Actions > File System > Set State > Active.
Both the migVSMstartup and migVSMshutdown commands use the migVSMstate command to change file system states. The standard VSM startup and shutdown scripts use migVSMstartup and migVSMshutdown to cleanly start and stop VSM operations. See the table “Startup/Shutdown Scripts” on page 192 for scripts appropriate for your platform.
File MigrationDuring migration, VSM selects files, associates them with a file handle, adds them to a work list of files to copy, and then copies them to secondary storage.
The following figure shows the main steps in the migration process.
Chapter 1, About VSM 9
Basic Migration Operations and Features
File Migration Process
Select Files to Migrate
VSM selects files by scanning the managed file system and evaluating each file according to the file-selection criteria set during configuration. These selection criteria are based on file size and time elapsed since the last access or since last modification, whichever is most recent. Files that meet the criteria are premigrated.
VSM selects files until there are no more files that meet the selection criteria or until it selects enough to reduce space used to a predefined level, referred to as the low-water mark. “Criteria for Selecting Files to Migrate” on page 73 has details on selection criteria.
VSM sweeps the managed file system on demand, periodically as scheduled in the Scheduling tool, or periodically if you have configured constant sweeping with migconsweep. See “Constant Sweeps” on page 31 for details on file system sweeps.
Assign a File Handle and Create Database Entries
VSM controls access to migrated files using the DMAPI interface. When a file is selected for migration, VSM completes the following steps:
◆ Assigns a new file handle. The handle is a 32 bit-integer usually represented in hexadecimal. The file handle, together with a 32-bit machine ID, uniquely identify a file within a managed file system. The file handle is stored in the file name database (FNDB), the file handle database (FHDB), and the inode-to-handle (IHAND) file for the managed file system.
Select files to migrate
Assign a file handle and create database entries
Assign the storage method (migpolicy)
Create work lists for copying files to secondary storage (migpolicy)
Copy files to secondary storage (migworker)
Update databases to show location of the file data
10 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
◆ Appends one entry to the file name database (FNDB) for the file.
◆ Appends entries to the FHDB for the file. One entry represents the copy on disk. Other entries (one or more) are “placeholders” that will later hold information about the copies VSM makes.
◆ Sets DMAPI managed regions on the file so that any attempt to write or truncate the file will be reported to the migd daemon.
◆ Sets DMAPI “attributes” on files. These attributes contain the file handle and machine ID as well as other information DMAPI requires about the file.
VSM holds a copy of migrated data on disk until space is needed in the managed file system, at which time the migrated file is purged or truncated.
Assigning file handles and creating database entries are quick operations that neither move nor copy data from one place to another. All data remains in the same file system and takes up no additional space.
If a user executes the VSM fls -l command on a migrated file, the resulting output shows the migrated flag, the file handle, the original file size and dates. If the file has been purged, the t flag is also shown in the output, as in the following example:
mrw---x--t 1 ljgm 20000 Dec 17 19:42 filec [002c70c0 00005bc9]
The t flag indicates that the file has been purged. The t flag can be seen with the standard UNIX ls command on an NFS client, which is useful whan an NFS server exports VSM managed file systems. The t flag tells a user on the client that there will be a delay when the file is accessed.
The migloc command for the same file provides more detailed information:
Status: Purged nutmeg ljgm filecHandle: 2C70C0M5BC9 20000 1/1 Mon Dec 17 19:48:23 2001Medium: 2N512A op.1 1 1 765 1331737600
If a purge candidate is written to, truncated, or removed, a DMAPI event will be generated that will cause VSM to make the file unmigrated.
Assign the Storage Method
VSM next reads the storage methods defined in the configuration file (migconf) for the managed file system and assigns them to the selected files. Storage methods are a combination of the method name, volume set number, volume set availability, and volume pool. These determine the secondary storage media to which files are migrated.
You should configure the storage method that is most suitable for a file system. The volume set number specifies a set of volumes.
Chapter 1, About VSM 11
Basic Migration Operations and Features
The volume set availability provides an indication of how long it takes to access the volume. For example, library indicates that the volume is in an online library and VSM has immediate access.
The volume pool specifies if the volume set is part of a group (pool) of volumes.
Create Migration Work Lists
The migpolicy script creates a work list (a copydb file), for each secondary storage method and volume set configured for VSM. migpolicy also assigns files to storage methods and writes file entries in the proper work list. For information on how to divert specific files to suitable media, see “Customize the VSM Policy and Method for Migrating Files” on page 227.
VSM work lists provide input for the copy processors that copy premigrated files to secondary storage. VSM stores these work lists in the working directory specified in the global configuration file (migconfg). “Work Lists (copydb files)” on page 240 provides a more detailed description of work lists.
Copy Files to Secondary Storage
The migworker script initiates a copy processor for each work list. The copy processors read entries from their assigned work lists and copy the premigrated files to secondary storage. If the configuration specifies concurrent recording, and if sufficient devices are available, different files can be copied simultaneously.
A copy processor attempts to copy every premigrated file in its work list from disk to secondary storage, and, upon completion, sets the status of each file operation. VSM periodically removes work list entries that have status fields indicating proper completion. Copy operations that do not complete successfully are reprocessed the next time VSM starts that copy processor.
After using up previously registered media, VSM automatically registers additional tape and optical disk media as needed from one or more volume pools in order to write the premigrated files on the work list to secondary storage.
Update the VSM Databases
The final step in the migration process is to update the file handle database (FHDB), the volume database (VOLDB), and the inode-to-handle (IHAND) file to reflect the location of the migrated files.
The FHDB contains at least one entry for each copy of a migrated file. If the copy was made using the NetBackup (nb) method or the FTP (ft) method, there will be only one FHDB entry for the copy. For other methods, large files can be divided into portions
12 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
referred to as granules. A temporary file (a destination volume database, or DVDB file) contains one entry for each granule. The FHDB has more than one entry for a file when the granules for a copy reside on more than one volume.
After a copy program completes its worklist, VSM calls the migmerge.sh script to compress the individual entries for each granule into one entry per file or per volume. If more than one volume is used to hold a file’s granules, there will be more than one FHDB entry for the file.
File CachingCaching is the process of copying migrated files back to the managed file system for access.
Caching fits into the entire migration process as follows:
1. After copies have been made, a file’s data blocks are still on the local disk. At this point, VSM (or the file owner) may purge the file’s data blocks (which is why it is called a purge candidate).
2. Users can access purge candidates without intervention from VSM. The name of the file remains in its original directory and stays visible to the user. Users can determine the status of a purge candidate by using the fls(1) or migloc(1) command.
3. If a purge candidate is written to or truncated, VSM updates its databases to reflect that the file is now considered unmigrated.
4. If the user or an application tries to read a purged file, VSM must cache the data back to the original file system in one of two ways:
- Total file caching (described in detail on page 16)
- Partial file caching (described in detail on page 17)
The following figure illustrates how VSM does file caching:
Chapter 1, About VSM 13
Basic Migration Operations and Features
File Caches
When a user accesses a purged file, VSM copies data from secondary storage and makes it available to the user. VSM updates the IHAND file to mark the file as cached (or partially cached).
Is partial caching
enabled?
When it cannot cache a file, VSM returns errno EPFNOSUPPORT to the user system call, which the user will know only if the application reports the errno. In some cases, the process will fail silently.
Is migd active?
No
No
No
Yes
Yes
Cache part of file
Cache Request -- as the result of a system call, such as read()
Entire file is cached
Is VSM state Active? (see page 8)
Yes
File is not cached.
File is not cached.
14 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
After VSM caches a migrated file, the file is again eligible for purging. If the file is modified, VSM will change it from a migrated file to an unmigrated file, and it can again become a migration candidate. When a migrated file is written, truncated, or removed, VSM sets the obsolete flag in each FHDB entry for the file. You can use either the fls(1) or migloc(1) command to see if a file is migrated or purged.
If more than one copy of a migrated file is available, VSM attempts to cache the copy from the volume it can access in the shortest time, regardless of whether it is on remote or local media.
Caching occurs automatically. Because the application accessing the data is blocked during the cache operation, a noticeable delay can occur. Partial file caching can reduce or control this delay for large files; however, it is a slower process when the whole file must be cached.
The following factors affect the length of the caching delay:
◆ Availability of drives
◆ Availability of volumes
◆ Transfer rates and access times from secondary storage to local disk
◆ Size of files
◆ Level of activity on the system
You can minimize caching delays in several ways:
◆ Configure enough tape or optical devices to handle the peak demand
◆ Match device characteristics to the size and access frequency for migrated files
◆ Configure the NetBackup unmount delay parameter to enable successive read requests from the same volume to proceed without unmounting and remounting that volume
◆ Configure the NetBackup demand delay parameter to unmount an unused volume of the same density immediately, and mount the volume containing the file to be cached
◆ Use partial file caching (described in “Partial File Caching” on page 17)
For example, making more than one device available to VSM can help minimize caching delays. If only one device is available, only one cache or migration request can be processed at a time. However, if four devices are available, assuming no migrations are active, four simultaneous caches are possible.
File SlicesIt is useful to understand how VSM uses the concept of file slices before discussing how partial or total caching works.
Chapter 1, About VSM 15
Basic Migration Operations and Features
Having part of a purged file immediately available to a user or application can be a very efficient method of managing data migration. The user or application does not need to wait for any VSM processing to occur before accessing the beginning of a file. If the entire file will need to be cached, however, partial file caching is slower than total file caching.
During configuration, you can set the size of that portion of a file you want VSM to retain on disk even after the file is purged. You can set this configured slice to a different value for each managed file system.
Partial file caching creates an effective slice that adds file data to the configured slice when a purged file is accessed.
Any write request or any memory-mapped I/O request to a purged file will cache the entire file, no matter how big its slice is. Depending upon the size of the configured slice, you can use the following methods to prevent some standard utilities like file and head from accidentally caching a large number of migrated files:
◆ The head utility reads the first 32768 bytes of a file by default. To prevent head from caching an entire file, set the slice value to at least 32768 bytes.
◆ The file utility normally reads fewer than 8192 bytes to determine the type of a file (such as whether it is executable). Therefore, setting the slice value to 8192 bytes usually prevents the file utility from caching an entire migrated file. However, file does apply its own built-in rules to determine a file’s type. If it fails to determine the file type by using its rules, it reads more of the file. If any of the data file tries to read is beyond the slice, VSM caches the entire file.
Restoring a migrated file with NetBackup sets its slice value to 0. This can cause performance delays when the files are used by file or head commands. If restored files with a slice value of 0 are modified and then re-migrated, VSM re-establishes the configured slice value.
Total File CachingA file read request for a sliced migrated file will be satisfied, if possible, by using the data on disk. If the read request exceeds or is completely beyond the configured slice, the entire file is cached before control is returned to the application or user.
A write request to append to a file always caches the entire file. A request to overwrite the file entirely does not cache the file, because the previously migrated data is no longer valid to the file owner.
Total file caching is illustrated in the following figure.
16 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
Total File Caching
If more than one copy of a file is available, VSM attempts to cache the copy it can access first. If everything else is equal, the copy is cached from the volume with the lowest migration level number (that is, the Primary copy is cached before the Alternate copy, a copy from migration level 3 before one from level 4, and so on). If the first accessed copy is damaged, VSM automatically switches to another copy and caches it completely, regardless of whether it is on remote or local media.
During configuration, VSM-Java sets the highest volume set availability (library) to the Primary copy of the file, and the lower volume set availability to the Alternate copy.
Partial File CachingPartial file caching provides access to some of the data in a purged file before VSM caches the entire file.
Some files are always totally cached:
◆ Files migrated using the ft or nb methods.
◆ Files migrated as a group ( the miggroup command)
◆ Files cached by staging. Users can avoid caching delays by running migstage to request copies of migrated files before needing to use them.
Partial file caching allows read access to a migrated file without caching the entire file. A file read request for a sliced migrated file will be satisfied, if possible, by using the data on disk.
Migrated File
Configured sliceNeither read request lies entirely within the configured slice that resides on disk.
The file is cached in its entirety.
data accessed by read requests
Cac
hed
data
Chapter 1, About VSM 17
Basic Migration Operations and Features
If a read request either exceeds or is completely beyond the configured slice, the file is partially cached to satisfy the read request. If a read request plus a configurable read-ahead value either exceeds or is completely beyond the partially cached data on disk, additional data is cached to satisfy the read request.
The configurable read-ahead determines the minimum amount of data VSM caches to disk beyond what is needed to satisfy the read request. For more information on configuring read-ahead values, see “File System Properties - General Tab” on page 129.
A write request always caches an entire file. If a read cache is in progress or a file is partially cached when a read request comes in, caching continues until the file is totally cached.
The following figure illustrates how VSM makes determinations during the first phase of partial file caching.
Partial File Caching, Phase 1
Migrated file
Configured slice Neither read request lies entirely within the configured slice that resides on disk
Data accessed by read requests
Cac
hed
data
Read-ahead File is partially cached to a point beyond the read request
Entire darker and lighter shaded area indicates the effective slice that resides on disk
Uncached portion of the migrated file (that does not reside on disk)
18 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
The following figure illustrates how VSM makes determinations during the second phase of partial file caching:
Partial File Caching, Phase 2
You can disable partial file caching by configuring the read-ahead to be -1, in which case any read request that does not lie entirely within the configured slice caches the entire file.
If a file is partially cached, VSM allows read access to cached data as soon as the granules containing the requested data are cached to disk.
VSM continues with the partial caching operation for a configurable read-ahead amount. All data previously on disk, plus the data required for the read, plus the read-ahead, is rounded up to the next whole granule. This cached portion of the migrated file now becomes the effective slice for the file, which supersedes the configured slice when processing subsequent read requests.
The initial partial caching request reads from the beginning of the file, including the configured slice. Subsequent partial caches of the same file do not reread data already cached, but resume caching at the end of the effective slice (the data on disk).
VSM stores information on effective slices and other information pertaining to partial file caching in the IHAND entry for the file.
Partially cached files remain marked as migrated unless the effective slice is the entire file, in which case VSM restores the configured slice value and marks the file as totally cached.
Migrated File
Effective slice
Neither read request lies entirely within the effective slice that resides on disk
Data accessed by read requests
Read-ahead File is partially cached to a point beyond the read request
Entire darker and lighter shaded area indicates the new effective slice that resides on disk
Cac
hed
data
Uncached portion of the migrated file (that does not reside on disk)
Chapter 1, About VSM 19
Basic Migration Operations and Features
If more than one copy of a file is available, VSM attempts to cache the copy it can access first. If everything else is equal, the copy is cached from the volume with the lowest migration level number (that is, the Primary copy is cached before the Alternate copy, a copy from migration level 3 before one from level 4, and so on). If the first accessed copy is damaged, VSM automatically switches to another copy and caches it completely, regardless of whether it is on remote or local media.
Partial file caching applies only to the first copy VSM attempts to cache from local media.
Partially cached files remain on disk until selected for purging. Selection criteria are the same as those for any unmigrated file. VSM updates the IHAND entry when a partially cached file is purged.
For information on configuring file caching, see “Partial File Caching Trade-offs” on page 68.
Directory-level MigrationWhile migration customarily occurs at the file level, it is also possible to perform migration and caching at the directory level.
With directory-level migration, users can group files they own in a directory (and its subdirectories), and migrate those files as a group. Users with root privilege can group directories owned by any user. If any file in the group is cached, all of the files in the group are cached.
Note Use directory-level migration only where applicable. It will increase migration and caching activity unnecessarily if it is used when file-level migration would suffice.
In directory-level migration, grouped files are premigrated together and placed in a work list as a group. When VSM copies the group to secondary storage, the files are located in close proximity to one another on sequential media. This minimizes the time needed to cache the grouped files (see “Work Lists (copydb files)” on page 240 for a more detailed description).
Normal file selection criteria, as described in “Select Files to Migrate” on page 10, are not applicable in directory-level migration. However, normal VSM rules apply to any ungrouped files added to grouped directories after the directories were grouped, and these files are selected, migrated, and cached individually.
Users can group files in directories selecting Actions > Directory Groups > Group in the File Browser or by using the miggroup(1) command.
20 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
Tape and Optical Volume Management During configuration, you define the storage methods that are available to VSM. VSM can use magnetic disk, tape, or optical disk (which is used as raw device).
You also define which method name, and therefore which media, to use for specific managed file systems. The configuration for one managed file system can specify that migrated files go on a cartridge tape, while files from another managed file system can go on the same or another media type.
The tape or optical storage devices that VSM uses are managed by Media Manager, as the following figure illustrates.
Media Management
When transferring data to or from a storage device, VSM queries the volume database (VOLDB) and identifies the volume on which to read or write the migrated data. It then includes the volume information in a tape request to the Media Manager device daemon, which allocates or deallocates drives based on availability.
You place volumes for VSM in pools from which it selects the volumes to use. After VSM selects a volume, that volume is assigned to it and registered in the VOLDB.
Media Manager tracks the location of both online and offline volumes and keeps this information in its own volume database. If a request from VSM involves a robotic device, the Media Manager device daemon queries the Media Manager volume daemon to determine which robotic device has the volume. The device daemon then issues a mount
MediaManager
Manual storagedevice
Mount request for volume
Database
Operator
VSM
Volumedatabase
Robotic storagedevice
Mount request for volume
Managed file system VSM
volumeinformation
Chapter 1, About VSM 21
Basic Migration Operations and Features
command to the robotic daemon controlling that device, which automatically mounts the specified volume and returns control to the application or user. No operator intervention is required, provided the required volume is physically in the robotic device.
With a manually operated device, the device daemon issues a mount request to the operator. To satisfy the request, the operator must find the volume, mount it manually, and assign it.
Media Manager is managed separately from VSM and can be used by other applications. See “Setting up VSM Volumes Using Media Manager” on page 108 for configuration specifics, and the Media Manager System Administrator’s Guide for more information.
Migration ParametersThe following configuration parameters control space limits on a managed file system:
◆ Free space value (also referred to as the high water mark). You can use the Scheduling tool to configure automatic removal of premigrated files or to configure automatic migration of files when open file system space is less than the free space value. If you prefer you can use VSM-Java or the command line to execute commands that start this process.
◆ Low-water mark. You can configure VSM to stop selecting files for migration when open file system space reaches this percentage.
◆ Purge mark. Purge candidates are files left on disk, even though they are also copied to secondary storage. VSM can remove purge candidates immediately and quickly provide open space on the managed file system, if necessary.
The following figure illustrates how these migration parameters work in VSM.
22 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
Migration Parameters
The following configuration parameters control the files that VSM selects for migration.
◆ VSM cannot migrate files that have been accessed or modified within a minimum age time period. For example, if the minimum age parameter is set at 2 days, VSM selects only files that were accessed or modified more than 48 hours ago.
◆ The minimum size specifies the minimum size of files that VSM can migrate. For example, if minimum size is 100 KB, VSM selects only files 100 KB or larger.
◆ After ruling out migration of files that are less than the minimum age and size, VSM calculates a value for each remaining file, referred to as its threshold. The file’s threshold determines whether or not it is selected to be migrated. After it calculates the threshold, VSM selects files only if their threshold exceeds the configured value.
If purge candidates exist, VSM removes them to the purge mark percentage and stops.
If no purge candidates exist, VSM sweeps the file system, selects enough files to increase open file system space to the low-water mark percentage, migrates the files, and finally purges files to the purge mark percentage.
VSM migd daemon detects that the percentage of file system space open for use in the managed file system is below the free space value.
Open file system space
Free space value
Purge mark
Free space value
Low-watermark
Open space
Chapter 1, About VSM 23
Basic Migration Operations and Features
VSM provides a threshold formula that is based on file size and age (time since last access or modification). You can also define a site-selected threshold formula in lieu of the VSM formula.
Note You also set size, age, and threshold parameters for purging files.
Migration CommandsVSM provides the following commands for automatic disk space management:
◆ migbatch
◆ mignospace
◆ miglow
The migbatch Command
The migbatch command selects and copies files to secondary storage, but it does not purge files. It performs the following steps:
1. Selects files according to configured criteria.
2. Marks the files with a migrated flag and associates a file handle with them. This process continues until one of the following is true:
- All files meeting the file-selection criteria are ready to copy to secondary storage
- The space that VSM can potentially free by purging premigrated files is enough to increase the percentage of open file system space to the low-water mark
3. Creates a work list entry for each file
4. Copies files to secondary storage. Purge candidates also remain on the local disk until the migd daemon determines that the managed file system needs more space. When more space is needed, the purge candidates are deleted using mignospace.
You can invoke migbatch from the VSM-Java interface, from the command line, or from a scheduled task you have defined using the Scheduling tool. You can also invoke it by running the miglow command, which invokes migbatch and then invokes mignospace.
24 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
When selecting files for migration, VSM performs “round-robin” sweeps, as follows:
1. Initially starts at the root of the managed file system or directory and traverses the entire directory tree.
2. Stops sweeping when enough files have been selected to satisfy the low-water mark.
3. Saves the path of the last selected file in the file managed file system’s dwpath/workdir/hsmname.sweep.restart. The dwpath is the pathname of the managed file system directory containing the database and workdir directories.
4. Starts the next sweep from the last component of the saved path that still exists in the managed file system.
5. Removes the sweep.restart file after it determines the starting point for the sweep.
6. If the sweep.restart file does not exist, starts sweeping from the root of the tree.
Round-robin sweeping eventually scans all of the files in the managed file system or directory.
Note Files listed in local and global migrate control files are not selected during normal sweeps of the managed file system. Eventually, however, these files may become migration candidates if VSM cannot migrate enough files to create adequate open space. For more information on these files, see “Control Files” on page 201.
Because the migration process can take a long time, run migbatch during off-peak times, thus creating purge candidates without interfering with user processes. VSM can then quickly provide space during normal working hours by purging the purge candidates.
The following figure illustrates what occurs when you run migbatch; it also indicates the other programs that migbatch calls to perform each task.
Chapter 1, About VSM 25
Basic Migration Operations and Features
Migrating Files with migbatch
Scheduled migration or command execution
migd detects that free space
is below the free space
value
Update databases to show locationof file data
Update IHAND file, file handle, and file name databases
Start migbatch
Scan file system for files that meet selection criteria
Select files and assign file handle
Create work list in workdir
Copy files in work list to secondary storage
(Calls migarch.sh andthen migworker)
migsweep
migout
migout
migpolicy
migcopy
migmerge.sh
migarch.sh
migworker
26 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
The mignospace Command
VSM uses the mignospace command to remove purge candidates. Purging starts when one of the following is true:
◆ A user or process writes to the managed file system when open file system space is at or less than the free space value. When VSM detects this condition, the migd migration daemon starts mignospace.
◆ You execute the mignospace command.
In either case, the mignospace process removes purge candidates to increase open file system space to the purge mark.
If there are no purge candidates when the managed file system reaches its free space value, mignospace starts selecting and copying files. This selection and removal process continues until all files meeting the selection criteria have been purged or the amount of open file system space increases to the purge mark percentage, whichever is first.
You can invoke mignospace from VSM-Java, from the command line, or from a scheduled task you have defined using the Scheduling tool. You can also invoke it by running the miglow command.
When you run mignospace, it performs one of the following steps, depending on the conditions of the managed file system:
◆ If some purge candidates exist that exceed the purge threshold:
- Purges this space to the purge mark percentage and stops
- Purges all purge candidates and stops
◆ If purge candidates exist, but removing them will not exceed the purge threshold, mignospace cuts the current purge threshold in half and exits.
◆ If there are no purge candidates:
- Cuts the current threshold in half and selects enough files to increase open file system space to the low-water mark percentage.
- Assigns file handles
- Creates work list entries
- Copies the files to secondary storage
- Removes purge candidates as necessary, up to the purge threshold
The migd daemon periodically checks to see if the free space value has been exceeded and starts mignospace if necessary. The frequency with which migd checks the free space value can be specified using startmigd (the default is 60 seconds).
The following figure illustrates what occurs when you run mignospace.
Chapter 1, About VSM 27
Basic Migration Operations and Features
Making Space Available with mignospace
If file system open space is low, miglow runs migbatch, then
mignospace
Is VSM state Active or
Maintenance?
Select and migrate enough files to bring free
space to the low-water mark
Has purge mark been exceeded?
Do purgecandidates
exist?
Cut threshold in half
mignospace
No
No
No
Yes
Yes
Yes
Administrator executes the mignospace
command miglow command
executes
migd detects that file system space open for
use is less than free space value
Cut threshold in half, then exit
Exit
Remove purge candidates,
increasing free space to the purge
mark, then exit
28 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
VSM can also accelerates disk space availability by selecting, migrating, and purging files incrementally, if you have configured this feature. If so, when migd detects that file system space open for use is less than the free space value, it calls mignospace with the -N option. If no purge candidates exist, mignospace -N will work incrementally so that users have freer access to the file system.
The miglow Command
The miglow command combines the individual functions of the migbatch and mignospace commands. This command checks the free space value you set during configuration and runs both migbatch and mignospace to provide space, if necessary.
When it is invoked, the miglow command first checks the open file system space available. If open space is less than specified by the free space value, miglow calls migbatch to select and copy files and then calls mignospace to purge them.
See “Criteria for Migrating Files (Water Marks)” on page 70 for information on configuring free space values.
You can invoke miglow from the command line or from a scheduled task you have defined using the Scheduling tool.
The following figure illustrates how miglow works:
Checking Free Space with miglow
Run migbatch to select and migrate enough files to allow mignospace to bring open file system space to purge mark
miglow executes
Yes
No
Exit. Enough space is available
Checks open file system space
Run mignospace to remove purge candidates, increasing open space to the purge mark
Isfree space
less than its configured
value?
Chapter 1, About VSM 29
Basic Migration Operations and Features
User Migration CommandsIf you enable user permissions, users can migrate and purge files that they own using the File Browser or the migrate and migpurge commands. The process for enabling user permissions is described in the VSM installation guide.
The migrate Command
By selecting Actions > Migration > Migrate in the File Browser or by running the migrate command, users can start the process of migrating individual files. This action does not actually copy files to secondary storage or free any disk space. It does make a work list entry so that the next time migbatch executes, VSM will copy the file to secondary storage.
The migpurge Command
By selecting Actions > Migration > Purge in the File Browser or by running the migpurge command, users can purge individual files from local disk, if a copy has been made and is resident on secondary storage.
Accelerated Disk Space AvailabilityAccelerated disk space availability reduces the delay in freeing disk space when no purge candidates exist. Rather than waiting for the entire mignospace process to run before making disk space available, VSM can optionally interrupt this process and purge files incrementally.
The mignospace -N command triggers accelerated disk space availability and creates the dwpath/workdir/hsmname.nospace file.
The existence of the hsmname.nospace file causes VSM to stop migsweep and migcopy processing as soon as any one of the following file system attributes is reached:
◆ The configured maximum number of minutes migcopy can run
◆ The configured maximum number of files migsweep and migcopy can process
◆ The configured minimum kilobytes of disk space migsweep and migcopy can free
If migcopy does terminate before the work list is complete, Media Manager will remount the destination tape when migcopy starts up again.
Note VSM may run mignospace more than once to reach the free space value. However, running mignospace -N triggers accelerated disk space availability during a single migsweep process. The next time migsweep runs, it will not invoke accelerated disk space availability.
30 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
Constant SweepsYou can tune VSM to perform constant sweeping of the managed file system. To enable constant sweeping, execute the following shell script:
/usr/openv/hsm/bin/migconsweep [-s sleep_time] hsmname &
The -s sleep_time option specifies the time (in seconds) that the process sleeps before resuming a sweep of the managed file system. The default is 60.
Constant sweeping prevents the work list of premigrated files from becoming empty, because VSM periodically checks the list and resumes sweeping if necessary.
If mignospace is running when VSM sweeps the managed file system, the accelerated disk space availability feature of mignospace is used.
Constant sweeping does use system resources, and it can adversely affect overall system performance, particularly during periods of heavy system usage. Once initiated, constant sweeping continues to run until you terminate the process by using the kill command.
Multilevel Migration Multilevel migration lets you configure and manage cost-effective storage hierarchies that make the best use of your storage equipment investment. VSM features offer options for how many copies of a file you want made. Primary copy only means that VSM makes one copy of a file. Dual copies means that VSM will make two or more. Multilevel migration is compatible with both of these methods. VSM adds optional migration levels up to a maximum of eight: four associated with the Primary copy and four associated with the Alternate copy.
After you configure multilevel migration, operations occur automatically on a schedule that moves files from one migration level to the next based on your site-defined criteria. These operations remain invisible to users but can reduce operating costs by retaining frequently used data on more easily accessed media and moving less frequently accessed data to lower-cost storage media at other levels. For example, frequently used files can be kept on optical disk while “older” files are on tape.
You can configure different multilevel-migration criteria for each managed file system. Typically, the secondary storage devices at higher levels have progressively larger capacities, longer access times, and lower unit storage costs. However, you are free to configure the storage methods at each level without such arbitrary restrictions.
VSM caches migrated data back to the server directly, without going through intervening migration levels or media. By tracking multiple copies of migrated files, VSM caches data from the volume with the highest volume set availability (library), regardless of other criteria. If that volume is not available, VSM requests another volume. The Primary copy of a file defaults to the volume set availability library, and the Alternate copy defaults to vault.
Chapter 1, About VSM 31
Basic Migration Operations and Features
Note If you use the ft or nb storage method, files are not eligible to be moved to a different migration level. They can only reside at Primary Level 1 and Alternate Level 2.
Default Configuration for Multilevel Migration
Initial file migration sends files to Primary Level 1 and Alternate Level 2. Thereafter, as data access becomes less urgent, VSM automatically selects files and moves them to higher levels whenever the migmove command is executed. You can execute migmove from VSM-Java, from the command line, or automatically by using the Scheduling tool.
By default, VSM marks files at the source level as dead after the files are moved to the destination level. You have the option to mark the Primary copy VSM made (also referred to as the source-level file) obsolete or have it remain active. At some later time, you can reclaim wasted disk space in source-level volumes by consolidating active files to other volumes and removing all remaining obsolete or dead files. For more information on these dead and obsolete database entries, see “Criteria for Moving Migrated Files” on page 81.
Migrate Primary copy
Migrate Alternate copy
Files cachedirectly fromany level
FileSystem
Level7
Level5
Level3
Level1
Level8
Level6
Level4
Level2
MovePrimary Copy
MovePrimary Copy
MovePrimary Copy
MoveAlternate
Copy
MoveAlternate Copy
MoveAlternate
Copy
Primary copy
Alternate copy
Level 3 Level 4
Level 5 Level 6
Level 7 Level 8
Tier 4
Tier 3
Tier 2
Tier 1
32 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Migration Operations and Features
File MovementThe migmove command controls file movement in multilevel migration. VSM selects files and then copies them to the next migration level. The following figure shows the main steps in this process:
File Movement Process
Select Files to Move
VSM selects files by scanning the source migration level and evaluating each file according to the selection criteria for files that you set during configuration. If the selection criteria has not been modified since the file was migrated or moved to the source migration level (the original Primary or Alternate level), VSM selects files based on file size and time elapsed (since moving or migrating the file). Files that meet the criteria become candidates for moving to the next migration level and are placed on a work list.
VSM selects files until there are no more files that meet the selection criteria. For more information on selection criteria, read “Criteria for Migrating Files (Water Marks)” on page 70.
File Handles, Storage Methods, and Work Lists
VSM reads the configured storage methods for each destination migration level and uses those methods to copy files to that migration level.
Select files to move
Assign storage method
Create worklists for copying files to next migration level
Copy files to a higher migration level
Update databases to show file location
Alter flags in databases for files at source migration level
Chapter 1, About VSM 33
Basic Migration Operations and Features
Like the migbatch and mignospace commands, migmove creates a work list for each configured storage method and volume set. It also assigns files to storage methods and writes file entries in the proper work list. The work lists provide input for the copy processors that move files to the next migration level.
Copy to Next Migration Level
The migworker script initiates a copy processor for each work list file. The copy processors read entries from their assigned work list and copy the indicated files to the destination migration level. If the configuration specifies concurrent recording, and if devices are available, different files can go to different devices simultaneously. Note that VSM can simultaneously move both the Primary copy and the Alternate copy of a file.
A copy processor attempts to copy every file on its work list from the source to the destination migration level. Upon completion, VSM sets the status of files. VSM periodically removes work list entries that have status fields indicating proper completion.
Copy operations that do not complete successfully are reprocessed the next time VSM starts that copy processor. Note that files are copied only once to a destination migration level.
Update VSM Databases
VSM updates the file handle database (FHDB) and VSM volume database (VOLDB) to show the location of moved files. The FHDB contains at least one entry for each copy of a migrated file. If the copy of the file is large enough to span more than one volume, the FHDB may contain more entries for each file copy at both source and destination levels.
The copy processors perform the database update by creating temporary database entries as they complete their work lists. After a copy processor completes its work list, migworker calls migsetdb to update the FHDB and then calls migmerge.sh to merge in the temporary entries.
Clean Up, FHDB and VOLDB Flags
By default, VSM sets a dead flag in the FHDB for files at the source level after moving them to the destination level. Other options are available with migmove. Volumes containing large numbers of obsolete and dead files can be consolidated and recycled as new volumes. See the migcons(1M) and migsetdb(1M) man pages for more information.
34 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File Export/Import
File Export/ImportThe export/import feature of VSM makes it possible to transfer migrated files from one managed file system to another managed file system that uses the same storage methods. To use this feature with optical volumes, the file systems must have the same platform and operating system. NetBackup and Media Manager are required for file export/import. VSM only exports tape and optical volumes managed by Media Manager. The export/import operation does not require file caching and can process files of any size.
For example, if your organization begins working on a project at Site 1, but later transfers that project to Site 2 in another city, the administrator at Site 1 can export to tape all the migrated files for that project. The administrator at Site 2 can import these same files, adding them to a similarly configured managed file system that is already running.
Note The mignbexport command does not supported embedded special characters in file names, such as asterisk, backslash, newline, parenthesis, question mark, right curly brace, square bracket, tab, or vertical bar (pipe).
The mignbexport command does the following:
1. Identifies all VSM volumes containing migrated files to be exported
2. Backs up all unmigrated files to be exported to NetBackup volumes
3. Backs up data from the file handle database (FHDB), file name database (FNDB), and volume database (VOLDB) for all files being exported.
4. Deletes these FHDB, FNDB, and VOLDB entries from the exporting managed file system.
After the mignbexport command completes processing, the exporting administrator (at Site 1) can remove the VSM volumes containing the migrated files and the NetBackup volumes containing the unmigrated files and database entries from their storage devices and sends them to the new location.
The import process is the reverse of export. The importing administrator (at Site 2) places in the appropriate storage devices the VSM volumes containing file data to be imported and the NetBackup volumes used in the mignbexport operation and then registers them with Media Manager for the importing managed file system. The Site 2 administrator uses the NetBackup import feature to make NetBackup at the Site 2 aware of the new data.
Chapter 1, About VSM 35
VSM System Files and Directories
The mignbimport command does the following:
1. Uses the NetBackup restore command to load the data.
2. Updates the FNDB, FHDB, and VOLDB for the importing managed file system to include this information about all files being imported.
3. Uses the NetBackup restore command to restore the imported files into the managed file system at the new location.
For more information on how to plan export/import operations, read “Moving Migrated Files (Export and Import)” on page 230 and the mignbexport(1M) and mignbimport(1M) man pages.
VSM System Files and DirectoriesIt is perhaps easiest to think of the VSM file structure as having four parts:
◆ The path for the managed file system (any managed file system’s mount point)
◆ The/usr/openv path for VSM databases, work files, log files, and binaries
◆ The /usr/var/openv/hsm path for global configuration
◆ The path for the remote volume server
Managed File System StructureThe mount point for any file system that VSM manages is referred to as the fspath.
You specify each fspath during configuration. The managed file system’s configured hsmname can be the same as fspath, but you can also use different names for each of them.
All of the files that VSM manages are in the fspath directory structure. The nb method uses a directory named fspath/migration/data for migrating files to NetBackup.
Note The NetBackup (nb) method will not be supported in the next VSM release.
The managed file system structure is shown the following figure.
36 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM System Files and Directories
Managed File System Structure
Databases, Work Files, Logs, and BinariesThe databases, work files, binaries, and logs that VSM uses to do its work reside in /usr/openv. The following diagram shows this file structure.
VSM File Structure
Managed files
fspath file system mount pointconfigured name of the
managed file systemhsmname
data
migration
/usr
/openv
(See “Global Configuration File
Structure” on page 41)
bin
admincmd
commandsscriptstoolsmigd
migvoldmigrd
goodies
/hsm/java
migsa, migfbvarious NetBackup files
/var
database logs
hsmname
databaseworkdirscriptstools
See “Files in dwpath” on page 38
(See “Log files” on page 40)
See “Files in dwpath” on page 38commands
scriptstools
Chapter 1, About VSM 37
VSM System Files and Directories
Files in dwpath
The databases and work files associated with a managed file system reside in a pathname referred to as the dwpath. If VSM manages more than one file system, you specify each dwpath during global configuration. The default is /usr/openv/hsm/database/hsmname.
The dwpath/workdir directory contains the work lists (copydb files) that VSM uses to copy premigrated files to secondary storage and to move migrated files from source to destination migration levels. These files have names of the following form:
hsmname.copydb.method_name.volume_set_number.volume_set_availability
The worklist directory also contains destination-volume database (DVDB) files. VSM creates these files to store temporary FHDB entries that it creates during copy operations. After merging the temporary entries into the FHDB, VSM deletes the DVDB file. To create a DVDB file, VSM uses a temporary destination-volume database (TVDB) file that it removes when it is no longer needed.
See “Databases on a VSM server” on page 233 for a more detailed description of work lists and the DVDB.
If the following files exist in the work directory (dwpath/workdir), they contain the process ID (pid) of the commands in the file name:
hsmname.migbatch.running: migbatch pid
hsmname.migcons.running: migcons pid
hsmname.migconsweep.running: migconsweep pid
hsmname.migdbcheck.running: migdbcheck pid
hsmname.miglow.running: miglow pid
hsmname.migmdclean.running: migmdclean pid
hsmname.migmove.running: migmove pid
hsmname.mignbexport.running: mignbexport pid
hsmname.mignbimport.running: mignbimport pid
hsmname.mignospace.running: mignospace pid
hsmname.migrc.running: migrc pid
hsmname.migreconstruct.running: migreconstruct pid
hsmname.migrecycle.running: migrecycle pid
hsmname.migsetdb.running: migsetdb pid
38 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM System Files and Directories
The workdir directory can also contain the following files, depending on what processes are running:
mig.lck: Used by migbatch and mignospace to lock the managed file system
hsmname.idling: Exists if hsmname is idling down
hsmname.last_merge: If present, its mtime (the time when it was last modified) is the time when the last FHDB merge operation completed.
hsmname.migsweep: List of files selected to be migrated
hsmname.nospace: Exists when mignospace is running with the -N option.
hsmname.p_badness: Current purge threshold value
hsmname.s_badness: Current threshold value.
hsmname.state: Current VSM state if the state is Idle, Iding, or Maintenance
hsmname.sweep.restart: Path of the last file selected by migsweep before reaching the low-water mark.
hsmname.VxFS_34_vsmstate: If non-zero in size, VSM detected VxFS version 3.4. The contents of the file (ASCII 0 or 1) indicate the value VSM assumes for the VxFS tunable hsm_write_proalloc.
The dwpath/database directory contains the following files that hold database information:
FHDB: Contains at least one entry for each copy of a migrated file. When VSM must split storage of a file over more than one volume, it creates an FHDB entry for each volume on which the file is stored.
FHSEQF: Contains the eight-digit hexadecimal value that VSM assigns to the next file handle.
FHDB.LK: Provides a master lock on the FHDB for the database merge process.
FNDB: Contains one entry for each migrated file.
VOLDB: Contains an entry for each volume registered with VSM.
VOLSEQF: Contains the eight-digit hexadecimal value that VSM assigns to the next volume ID (handle).
VOLDB.LK: Provides a master lock on the VOLDB for the database merge process .
NEXTVOL1: Next volume VSM will use for the Primary copy of a migrated file.
NEXTVOL2: Next volume VSM will use for the Alternate copy of a migrated file (if applicable).
NEXTVOL3 ... NEXTVOL8: Next volume VSM will use for moving a migrated file to migration level 3-8 (if applicable).
Chapter 1, About VSM 39
VSM System Files and Directories
migsweep.site: Site-defined migration and purge criteria control.
migsweepm.site: Site-defined move criteria control for files (if applicable).
migconf: Configuration file that specifies migration criteria for the managed file system using this database.
hsmname.IHAND: Inode and handle information about migrated files
hsmname.FLUSH: Controls how often VSM writes tape marks when making copies during file migration.
hsmname.merge_threshold_count: Contains the minimum number of DVDB entries that must be waiting to be merged before VSM will trigger a merge operation (an ASCII file).
hsmname.merge_time_delay: Contains the minimum number of seconds between merge operations (an ASCII file).
hsmname.gran_retry: Presence indicates VSM will try to read the same granule twice if it encountered a read error.
hsmname.NUMBER_PLACEHOLDERS: Contains the number of placeholder FHDB entries created when a file is migrated. If not present, VSM uses the number of copies as the number of placeholders.
hsmname.PREFERRED_LEVEL: Contains the level number to be tried for file caches. If not present, VSM uses the copy of the file it can access most quickly.
Log files
Managed file system log files reside in the lgpath pathname. If VSM manages more than one file system, you specify each lgpath during global configuration. The lgpath default path is /usr/openv/hsm/logs/hsmname.log.
The global log file is not in lgpath, but in /tmp/hsm.log; its path is not configurable.
Binaries
The /usr/openv/hsm/bin directory contains the binaries and commands that you execute from the command line.
The /usr/openv/hsm/bin/admincmd directory contains the executables for some of the administrative commands, scripts, and tools found in /usr/openv/hsm/bin. It also includes the VSM daemon (migd), the volume daemon (migvold), and the VSM-Java request daemon (migrd).
40 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM System Files and Directories
Global Configuration File StructureGlobal configuration information resides in the /usr/var/openv/hsm directory, as shown in the following figure.
Global Configuration File Structure
Significant directories in this tree are as follows:
◆ The /usr/var/openv/hsm/database directory contains the following files:
migconfg: VSM global configuration file created during configuration.
migconfg_example: A template VSM global configuration file.
migrate: Optional global migrate file, containing a list of the files (and possibly directories) of files that VSM will migrate during automatic migration.
migstop: Optional global stop file that contains a list of the files that VSM will not migrate.
schedules: Global schedule file created with the Scheduling tool.
◆ The /usr/var/openv/hsm/workdir directory contains the following files:
HsmLogLevel: Level of logged VSM messages.
MOTAB: Global VSM mount table.
migd.pid: Contains the migd daemon process ID (pid), if migd is running
migd.sid: Contains the migd daemon session ID (sid), if migd is running
/usr/var/openv/hsm
database
workdir
example
Template files:FHDB
FNDBFHSEQFVOLDBVOLSEQFmigsweep.sitemigsweepm.sitesample.migpolicy.scriptmigconf
database
Template files:migconfg_example
Template files:migd.pidmigvold.pidMOTABvolume mount pointsmigd.sidHsmLogLevelmigrd.pid
VSM files:migconfg
Chapter 1, About VSM 41
VSM System Files and Directories
migrd.pid: Contains the migrd daemon pid, if migrd is running.
migvold.pid: Contains the voldb daemon pid, if voldb is running
hsmname.volume id.[W|R]: Volume mount points
◆ The /usr/openv/hsm/examples/database directory contains template VSM database files, as follows:
FHDBFNDBFHSEQFVOLDBVOLSEQFmigsweep.sitemigsweepm.sitemigconfsample.migpolicy.script
Note To create site-defined migsweep.site and migsweepm.site files, use the template files in the examples directory as a starting point and then move the site-defined files to dwpath/database/hsmname.
To create a site-defined migpolicy.script, use the template in the examples directory and a starting point then move the site-defined file to /usr/openv/hsm/bin/admincmd/migpolicy.script.
Remote Volume Server Files and DirectoriesThe following figure shows the key VSM system files and directories that reside on a remote volume server in a VSM configuration.
Remote Volume Server Files and Directories
The ftvpath directory is the path to the file system containing the ft volume. This file system contains the following types of files:
ftvpath
CMIG.pidMIG.pid
1LXXX
data_filedata_file.GLABEL
2LYYY
ID_LABEL
42 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM System Files and Directories
ID_LABEL: Each remote file system containing an ft volume has an ID_LABEL file. This file contains a single line of text that identifies the label and the client name for the managed server using the volume.
1LXXX is the first level directory.
2LXXX is the second level directory within which data_file and data_file.GLABEL files reside.
data_file: Each migrated file has a unique ID.
data_file.GLABEL: There is a GLABEL file for each migrated file. The GLABEL files contain information pertaining to the migrated file.
Note If VSM is running on a remote volume server, use the global stop file to prevent the migration of any data_file.GLABEL files from that remote server. See “Controlling Global Migration” on page 218 for details.
CMIG.pid: Stage list of files being created.
MIG.pid: Stage list of files available for use.
Chapter 1, About VSM 43
VSM System Files and Directories
44 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Planning VSM Configuration
2 Before you configure VSM, you must develop a migration plan that takes into account the unique requirements of your site. This chapter explains factors to consider and steps to perform during each part of the planning process. The example plan developed in this chapter serve as a guide for developing your own plan.This chapter follows the general procedure that the Advanced Configuration Wizard uses. (You do not need to know VSM configuration procedures to plan your configuration.)
VSM configuration has two levels:
◆ Global configuration. The migconfg file holds this information for the entire VSM system after you have configured VSM.
◆ Managed file system configuration. The migconf file for each managed file system holds this information after you have configured the managed file system.
VSM Global ConfigurationThe global configuration defines a named collection of managed file systems and their associated attributes. You use VSM-Java to set up the global configuration for the VSM server, which resides in the /usr/var/openv/hsm/database/migconfg file.
The global configuration file contains entries that specify the managed file systems. You can choose to configure only one file system in the global configuration on the VSM server, or you can configure several entries that each specify a different file system.
The parameters for each managed file system are as follows:
◆ hsmname: Name of the individual managed file system that you provide during configuration.
Note Usually, the hsmname is the same as the file system mount point.
An hsmname has a maximum length of 32 characters. In VSM-Java, the name is limited to a maximum of 14 characters. Names longer than 32 characters may overwrite other data, with unpredictable results.
45
VSM Global Configuration
◆ fspath: File system mount point.
◆ dwpath: Path to the database directory that VSM uses to control and store migration information for the managed file system.
◆ lgpath: Path to the log file in which VSM stores its status and error information about operations performed on this managed file system and its databases.
◆ state: The VSM state, which is usually Active. The VSM state controls the level of VSM activity that can occur on the file system.
The schedules that you set up for migration and report data collection on a managed file system also affect the global configuration. To keep your server running efficiently, migrations for different managed file systems should be scheduled at different times.
Managed File Systems in Global ConfigurationVSM allows you to manage standard UNIX file systems mounted as VxFS file systems. The actual file system types that VSM supports depends on the type of server.
The term managed file system refers to the file system containing the set of directories that VSM searches for files to migrate. VSM-Java refers to the managed file system and the configured attributes associated with it as a Hierarchy.
File Systems to Manage
To identify those files that will benefit from VSM management, examine the file systems that are most likely to have space problems. For example, projects may have file systems that typically grow very rapidly and cause the file system to run out of space often. The best candidates for migration are old files that are rarely accessed in file systems that fill up regularly.
The VSM File System Analyzer can help you assess which file systems VSM management will best serve, as described in “Experimenting with Scenarios” on page 187.
VSM manages disk space in each managed file system configured as an hsmname. If another file system is mounted in the managed file system, VSM will not managed it.
File Systems Not to Manage
VSM cannot manage the following:
◆ Root (/) or any subdirectory in the root file system
◆ NFS-mounted file systems
◆ Raw disk partitions, including swap partitions
46 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM Global Configuration
◆ /tmp file systems
◆ /home directories
Note Never migrate the executables for VSM, NetBackup, Media Manager or Volume Manager that reside in /usr/openv/.
Avoid migrating files that are critical to system operation or those in file systems that do not grow quickly enough to benefit from VSM management. For example, the /usr file system can contain information essential to system startup and operation, and you must plan carefully if you need to manage it.
All your managed file systems will contain some files that you do not want to migrate. Some specific types of files follow:
◆ Temporary files
◆ Core files
◆ History files
◆ Files labeled junk or testing
◆ .login, .cshrc, and other . (dot) files
Administrators and users can list files VSM will always migrate or those VSM should not migrate in special VSM control files. See “Controlling Global Migration” on page 218 for more information on how to create and use these VSM control files.
VSM and Macintosh File Servers
If your managed file systems are accessed by users on Macintosh systems, certain metadata files should not be migrated by VSM. To prevent this, add the following lines to your global migstop file (/usr/var/openv/hsm/database/migstop):
.../.HSResource
.../.HSancillary
.../.HSicon
Notes on Samba Configurations
The following notes apply to configure a managed file system on a UNIX platform and mounting the managed file system to a Windows machine using a Samba connection:
◆ Virus scanners will cache files on the Samba share.
◆ On Windows ME, you may see very poor performance in attempting to use the cd command to change directories to a drive while a file is being cached.
Chapter 2, Planning VSM Configuration 47
VSM Global Configuration
◆ If the UNIX system has migrated data to tape, caching it could cause a network timeout. You can alleviate this problem by changing the following registry entries to lengthen the timeout value:
- On Windows NT 4.0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\sesstimeout(DWORD set in seconds)
- On Windows 95 and 98
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VxD\VNETSUP\sesstimeout (DWORD set in seconds)
- On Windows 2000
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstationParameters\sesstimeout (DWORD set in seconds)
◆ Microsoft Word sets file access time to the future, which means that the data may not migrate for an hour after it has been written.
◆ Microsoft Explorer requires that a file be cached in order to change its attributes. This means that changing access control lists (ACLs) when using SLFS with Microsoft Explorer will cause the file to be cached.
Number of Files and Inodes
The number of files in a managed file system affects the time required to select files for migration. As the number of files increases, so does the selection time. It is good UNIX administration practice to limit the number of files in any one file system.
The number of files you expect to migrate from the file system is also an important consideration. As the number of migrated files grows, so do the VSM databases, and therefore the time required for tasks such as migmerge.sh and migdbcheck increases..
In addition, migrated files still use some disk space because they have inodes, and they can have a portion of data on disk (this portion is referred to as a slice).
The file system must have enough extra space to allow for the configured slices that will reside on disk. For example, if you expect to maintain 10,000 files in a migrated state and set the slice value to the default 8 KB, you need 8 MB just to store the slice data. VSM continues to use this space for the slice even after the file is completely migrated to secondary storage.
You must also allow space in the database directory for the IHAND file, as described in “Files in Database Directories” on page 49.
48 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM Global Configuration
VSM Databases in Global ConfigurationAll managed file systems are associated with databases and workfiles that reside on the VSM server. These databases and work files are kept in the file system’s dwpath. By default, the path name to the database is as follows:
/usr/openv/hsm/database/hsmname
The hsmname is the configured managed file system name. Its maximum length is 32 characters.
You are asked for this pathname on the Enter Values dialog of configuration wizards.
Files in Database Directories
Significant files in the database directory include the following:
◆ File handle database (FHDB)
◆ File name database (FNDB)
◆ VSM volume database (VOLDB)
◆ Inode-to-handle file (hsmname.IHAND)
◆ Managed-file-system-specific configuration file (migconf)
Caution Always specify the pathname for a database directory in a local file system that VSM does not manage. This eliminates the possibility of migrating files from the database or workdir directories that VSM needs for operation.
VSM-Java ensures that database directories are unique for each managed file system.
FHDB and FNDB Entries
A VSM file handle is a unique sequence number that makes it possible to locate all copies of a migrated file, regardless of the storage methods used.
The file handle database (FHDB) file and the file name database (FNDB) files reside in the dwpath/database directory.
The number of entries in these files impact the performance of VSM operations that require database access and updates. Carefully estimate your FHDB size, both for current size and your anticipated system growth, and partition your file system accordingly.
VSM creates one FHDB entry for each copy of a file, unless the file spans multiple volumes. If it spans multiple volumes, an additional FHDB entry is required for each volume on which the file resides.
One entry also exists for the dk FHDB entry, which represents the copy of the file on disk.
Chapter 2, Planning VSM Configuration 49
VSM Global Configuration
In the following example, there are 20,000 migrated files, 5% of which span two volumes. VSM makes two copies of each file. You can anticipate an FHDB of 62,000 entries:
(20,000 files x 2 copies/file x 1.05 spanned vol.) + 20,000 dk entries = 62,000 entries
VSM also creates one FNDB entry for each migrated file.
FHDB and FNDB Space Requirements
The amount of disk space needed for your file handle and file name database files depends on the number of entries you expect to be in the database.
The size of a typical FHDB entry is about 160 bytes.
Note The FHDB has decreased in size since the VSM 3.4.1 release.
Multiplying the number of file entries by 160 provides the total bytes you must reserve for the database.
If there are 20,000 migrated files, 5% of which span two volumes, and VSM makes 2 copies of each file, the FHDB space requirements can be calculated as follows:
(20,000 files x 2 copies x 1.05 spanned vol.) + (20,000 dk entries x 160 bytes/entry) = 9.92 MB
Each FNDB entry is about 80 bytes long, plus the length of the file’s full pathname. If the average full pathname is 40 bytes long, the FNDB space requirements for 20,000 files can be calculated as follows:
20,000 entries x 120 bytes/entry = 2.4 MB
The combined FNDB and FHDB space requirements in this example are about 12.32 MB.
Inode-to-Handle File Requirement
Like the VSM database files, the inode-to-handle (IHAND) file resides outside of the managed file system, in dwpath. The maximum space needed for the IHAND file is platform-dependent. On Solaris and HP-UX systems, the space required is 64 bytes times the number of inodes in the file system; on IRIX systems it is 56 bytes times the number of inodes in the file system.
The IHAND file is a sparse file. (A sparse file is one with large amounts of “blank” space. Such files save disk space because the file system allocates disk space to the file as its blank space is filled, but not while the space is blank.)
50 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM Global Configuration
Total Database Space Requirement
You must allow space for the other database files (for example, VOLDB and the workfiles located in dwpath/workdir/). The total amount of space you need for all VSM databases is about three times what you calculate for the FNDB and FHDB.
In the following example, there are 20,000 migrated files, 5% span two volumes, and VSM makes 2 copies, which means there are 62,000 FHDB entries. There are 20,000 FNDB entries.
3 (((All FHDB entries) (160 bytes each)) + ((All FNDB entries) (120 bytes each))) = 36.96 MB
Depending on how certain you are about the number of files you expect to migrate, you will need to monitor the growth of the databases can adjust the space allocation if necessary.
Log File Pathnames in Global ConfigurationVSM keeps a global log file containing messages that pertain to all VSM processes on the server. The global log file is named /tmp/hsm.log, which cannot be changed. You should, however, ensure that you do not lose log messages in the event of a reboot or system crash by linking to another pathname, as in the following example:
ln -s /var/logs/hsm_global.log /tmp/hsm.log
For information on the contents of the global log file, read “Managing Logs” on page 247.
In addition to the VSM global log file, VSM writes informative messages to a log file that you define for each managed file system. By default, the path name to each log file is as follows:
/usr/openv/hsm/logs/hsmname.log
The hsmname is the name you assign to the managed file system, such as hsm1.
Do not put the file-system specific log files in /tmp.
For all managed file systems, you are asked for this pathname on the Enter Values dialog of configuration wizards.
Chapter 2, Planning VSM Configuration 51
VSM Global Configuration
VSM States, Space Management, and CachesWhen a managed file system’s VSM state is Active, the migration daemon (migd) monitors the free space on a file system. If an Active managed file system has less free space than you configured it to have, migd attempts to increase the free space by starting the following process:
1. The migd daemon starts the mignospace command.
2. The mignospace command causes VSM to remove files that have been copied to secondary storage and to increase free space to the configured percentage. If there are no files ready to remove (purge), mignospace copies files to secondary storage and purges the local disk copies.
VSM continues to copy and purge files until the percentage of free space on the file system increases to the configured percentage. By default, files are selected for migration according to their size and how much time has elapsed since they were last accessed.
3. If a user accesses a migrated file, VSM caches it back to its original directory.
States other than Active
In addition to Active state, a managed file system’s state can be any of the following:
◆ Idle: VSM recognizes if the file system has been mounted or unmounted.
◆ Idling: VSM can remove files. All VSM processes cleanup and terminate. No mignospace processing can start. After all VSM activity completes, migd will changes the state to Idle.
◆ Maintenance: VSM does not cache files or start mignospace processing.
◆ Inactive: No VSM activity takes place.
Setting the VSM state of a file system to a state other than Active disables both automatic space management and caching.
If the managed file system is in Active state, you can manually manage disk space by periodically either running miglow or running migbatch and then mignospace. The miglow command does the selecting, copying, and purging that migbatch and mignospace do. The miglow always uses the percentage of free space you specified during configuration.
In Maintenance state, VSM may be used to migrate or purge files, but it does not cache files back to the managed file system.
52 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM Global Configuration
Migration Schedules in Global ConfigurationVSM allows you to schedule automatic, unattended migration of files in managed file systems.
The Enter Values dialog of configuration wizards prompts you to select a time each day to migrate files. Daily migration ensures that if migration is prevented one day, it still occurs the next day without intervention (which is most efficient). You can select times on the hour every two hours from 00:00 to 23:00 (from midnight to 11:00 P.M.).
The scheduling guidelines in this section also apply to using the miglow command to migrate files.
Best Times for Migrating Files
If the act of writing to a file system causes its free space to be less than the percentage you configured, VSM will attempt to make space. It creates free space by removing the local files that the migbatch process previously copied to secondary storage. If there are no such local files to remove, VSM automatically performs a migration by selecting files, copying them to secondary storage, and then removing the local files.
Migrating files can take a long time, depending on factors such as the following:
◆ Size of the file system
◆ Number of files selected
◆ Availability of storage media
◆ Transfer rates and access times from disk to secondary storage
◆ Level of activity on the VSM server
Migrating files during peak-use periods can result in reduced system performance and delays for users. Part of planning your configuration is anticipating requirements and ensuring enough files are migrated when system activity is low. Scheduled migrations for different managed file systems on the same server should not contend for resources.
The best time to execute migbatch is when user and network activity is lowest. You can also schedule around restrictions such as large jobs that run at off-peak times, or departments that work in shifts.
To avoid performing extra backups, synchronize your migration and system backup schedules.
Chapter 2, Planning VSM Configuration 53
VSM Global Configuration
How Often to Migrate Files
In addition to knowing when to schedule migrations, you need to know how often to perform migrations. The main factor to consider is the amount of new space users need every day (referred to as the fill rate).
Based on percentages of free space you configure and the amount of space used each day, you can determine how often you need to migrate files.
A good approach is to migrate files at least twice as often as it takes to fill the file system from the lowest percentage you configure (referred to as the low-water mark) to the highest you can allow without taking action (referred to as the free space value, or high-water mark). For example, if you determine that the file system fills to the highest percentage you can allow every two days, migrate files every day.
After configuring a file system, you can migrate files to the low-water mark before allowing users to resume normal operations with the file system. Perform this initial migration during off-peak time to minimize the effect on users.
If possible, specify daily migrations in your initial schedule. You can then assess the results and determine whether to adjust the frequency.
Time Required to Complete Migration
The time to complete a migration is also an important factor in scheduling. Completion time depends primarily on the amount of data that you move. As the amount of data in a file system increases, so does the time required to complete the operation. Therefore, consider the amount of data and total time when determining when and how often to execute file migration.
One approach to dealing with large amounts of data is to back up and migrate different file systems on different schedules. This enables you to spread the migrations over several days. Another approach is to migrate files more often. If you have enough devices, you can reduce migration time by making copies concurrently, as described in “Concurrent Stripes / Concurrent Recording” on page 63).
Migration Schedule Example
If you determine that the best time for backup and migration is between 10:00 PM and 6:00 AM on weekdays and between 6:00 PM and 6:00 AM on weekends, you might schedule backups to start every night at 10:00 PM, followed by migration with migbatch at 1:00 AM.
Reversing the schedule by starting file migration at 10:00 PM, followed by backups at 3:00 AM, would not affect the time needed to complete file migration, but it would reduce backup time. When backup precedes migration, entire files are backed up. When migration precedes backup, however, only the inodes of any migrated files are backed up.
54 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM Global Configuration
Schedules for Report Data CollectionVSM-Java provides Reporting tools that let you view reports about VSM performance and past trends. Using these tools, you can display reports of space details, copies made, and caches made by file system, day, hour, and user ID.
The Enter Values dialog of configuration wizards prompts you to select a time each day to gather reporting data. Collecting report data daily ensures that if collection of data is prevented one day, it could still occur the next day without intervention, and your report data will be acceptably current. You can select times on the hour every two hours from 00:00 to 22:00.
Completing the Global Configuration PlanThe following factors should enter into planning your VSM global configuration:
◆ Each managed file system has a unique hsmname, which is usually the same as the file system mount point.
◆ The number and type of storage devices your server can access affects how efficiently VSM can use secondary storage.
◆ Total space available (and used) in each file system affects how it should be managed. File systems that fill up quickly can benefit most from VSM management.
◆ Total number of inodes in each file system and the amount currently used affect how much space migrated files will use.
◆ Access frequency (time between file accesses) for each file system affect which files to migrate. Target large, infrequently accessed files for migration.
◆ Schedules for migrate should be based on the fill rate (average size and number of new files users create in a specific time period) for each file system
As you progress through the planning process, you may decide to change file system configuration to optimize VSM performance. For example, you can use a larger number of file systems to reduce the size of the FHDB to less than 2 GB, which positively affects VSM performance.
The VSM File System Analyzer can help you determine how to configure file systems, as described in “Experimenting with Scenarios” on page 187.
After you have completed your global configuration plan, complete the “Global Configuration Worksheet” on page 86.
Chapter 2, Planning VSM Configuration 55
Managed File System Configuration
Managed File System ConfigurationAfter you have determined the global configuration, you determine the configuration for the individual managed file systems. You configure the file systems using VSM-Java. A migconf configuration file that VSM-Java creates for each managed file system includes the following types of attributes:
◆ Name of the managed file system (hsmname) using the VSM database
◆ Disk-space management parameters for the file system.
◆ Methods for storing each copy of migrated files and for moving migrated files to another migration level.
◆ Characteristics of each type of storage method. For example, the file specifies the capacity and access time of media.
◆ General parameters for controlling file migration. For example, you can list control how much space individual users can exclude from migration.
Note VSM-Java refers to the hsmname and the attributes associated with it during configuration as a Hierarchy.
Initial Configuration TestingIf you are configuring VSM for the first time, the best approach to defining your most efficient migration criteria is as follows:
1. Read all the topics in this chapter and fill out the “Global Configuration Worksheet” on page 86.
2. Use the Basic Configuration Wizard and leave values at the defaults unless you know that you want to customize your configuration. For example, you might provide a limit for the number of files that VSM removes from local disk (VSM does not provide this limit by default).
3. Evaluate VSM operation at the default values to see how well it satisfies your migration and caching requirements. If you decide to vary your settings from the defaults, fill out the “Managed File System Configuration Worksheet” on page 87 for each file system.
4. If necessary, continue to adjust the file system configuration to achieve the desired performance by following the guidelines in this chapter and using information from step 3.
56 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Storage Levels for Migrating Files
The VSM File System Analyzer can help you determine how to optimize migration (see “Experimenting with Scenarios” on page 187).
Storage Levels for Migrating FilesYour choice of storage levels has a major impact on the caching performance of the VSM system.
The first consideration when choosing storage levels is to decide whether to write one or two copies of migrated files. Then you decided on the type of media to use for each copy. Usually sites use the same media for multiple copies. It is possible, however, to configure VSM to write the Primary copy (the first copy) of a file to one media (such as optical disk) and the Alternate copy (the second copy) to another media (such as magnetic tape). It is also possible to record on several devices simultaneously in order to speed up the migration process, as described in “Concurrent Stripes / Concurrent Recording” on page 63.
The storage level for the Primary copy of a file is referred to as the Primary Level. (In the migconf configuration file, it is a set of parameters referred to as METHOD1.) The storage level for the Alternate copy of a file is referred to as the Alternate Level. (In the migconf configuration file, it is a set of parameters referred to as METHOD2.) If you make only a Primary copy, you use only the Primary Level.
You must configure at least as many storage levels as you have configured copies to be made. The Basic and Database Configuration wizards always configure two copies for the tape and optical disk methods. Unless you have deselected the Dual Copies checkbox on the Hierarchy Properties dialog of the Advanced Configuration wizard, you will use both the Primary Level and the Alternate Level.
Caution The number and type of your storage drives must correspond to the storage levels you configure. For example, if you configure tape method names for both the Primary Level and the Alternate Level, you must have at least two tape drives configured.
The best storage method to use depends on the characteristics of the managed file system you are configuring. If you have a file system with many large files, choose a method that employs media with a fast transfer rate. If you have many small files, access time is more important.
You set four parameters for a Level, which comprise a stripe.
Note When you use VSM-Java to define the configuration, it encodes the stripe syntax.
The following parameters are the components of a stripe:
◆ method name, which defines the device and media
Chapter 2, Planning VSM Configuration 57
Storage Levels for Migrating Files
◆ volume set number, which makes the stripe unique (VSM-Java assigns this number)
◆ volume set availability, which defines how quickly files at this Level can be accessed.
◆ volume pool, which defines the volumes that are available to this Level.
The stripe format in the migconf configuration file is as follows:
"method name.volume set number.volume set availability.volume pool"
The following example from a migconf file has the method name ct (cartridge tape), the volume set number 1, the volume set availability library, and the volume pool HSM:
"ct.1.library.HSM"
This stripe format is used in migconf file. You do not need to know or use it unless you are working with the configuration file.
A Level may consist of more than one stripe. Defining multiple stripes for a Level means that copies are made and sent to different locations on secondary storage, as described in “Concurrent Stripes / Concurrent Recording” on page 63.
Method Name A VSM method name equates to a set of parameters for each storage method that VSM supports. These parameters define the characteristics that VSM associates with each storage method. For example, the access time parameter is 0 for a local disk file and 30 seconds for an 8mm cartridge tape.
You can change storage methods for tape or optical disk in VSM-Java by highlighting the stripe in the Left Pane of the main Administration dialog and selecting Edit > Change Stripe Properties and making changes on the Physical tab.
VSM has the following storage method options (the actual method names are given in parentheses):
◆ Sony AIT-2 technology 8 mm tapes (mt). In VSM-Java, this is named Tape 1.
◆ STK-9840 technology cartridge tapes (ct). Tape 2 in VSM-Java.
◆ DLT 7000 technology tapes (dt). Tape 3 in VSM-Java.
◆ Rewritable optical disk (op)
◆ Write once, read many (WORM) optical disk (ow)
◆ Remote method using FTP (ft)
◆ Alternate magnetic disk (ad)
◆ NetBackup (nb)
58 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Storage Levels for Migrating Files
With release 4.5, VSM supports write-once-read-many (WORM) tapes. The storage method for WORM tapes is determined by VSM-Java.
Note You can alter media density and other tape features on the Advanced Configuration wizard Stripe Properties dialog’s Physical tab. You can alter the default methods by changing them in the migconfg file. However, if you have already written migrated files with one set of parameters, do not change them.
The VSM disk file (dk) method is used for the disk cache, and it is never used on a stripe property. The dk is required for premigrating files, and it is automatically configured during VSM installation.
Tape Methods
VSM supports the following tape storage methods:
◆ mt, which designates Sony AIT-2 technology 8 mm tapes (Tape 1 in VSM-Java)
◆ ct, which designates STK-9840 technology cartridge tapes (Tape 2 in VSM-Java)
◆ dt, which designates DLT 7000 technology tapes (Tape 3 in VSM-Java)
Your choice of tape method depends on the type of device you have on your site. If you have more than one type of device, you use Edit > Add Stripe in VSM-Java and configure the stripes you want to use for a Level.
With release 4.5, VSM supports write-once-read-many (WORM) tapes. The storage method for WORM tapes is determined by VSM-Java when you check the WORM tape checkbox on the Stripe Properties dialog’s General tab.
VSM interfaces with the VERITAS device-manager interface (ltid) to allow VSM to share a tape library with other applications.
You can remove tapes from a library and store them on your site or send them to an off-site storage location. When you physically remove a tape from the library device, Media Manager updates its database to indicate the volumes on that tape are offline.
For more information on Media Manager and VSM configuration, see “Setting up VSM Volumes Using Media Manager” on page 108.
Optical Disk Methods
VSM supports the following optical disk storage methods:
◆ op, which designates rewritable optical disk
◆ ow which designates write once, read many optical disk
Chapter 2, Planning VSM Configuration 59
Storage Levels for Migrating Files
Note You can alter these default storage methods by changing the configured density attribute in migconf. However, if you have already written migrated files with one set of parameters, do not change them.
Your choice of optical disk method depends on the type of media you have on your site. If you have more than one type of device, you highlight the Level and select Edit > Add Stripe in VSM-Java and configure the stripes you want to use.
The op and ow methods manage optical disks as logical tapes and treat each disk surface as a tape volume. VSM stores files in a format similar to that used for storing files on tape; however, the random seek ability of the optical-disk drive reduces access time. VSM does automatic volume registration with optical disks.
Note When you register one side of an optical disk by using the migreg command, VSM also automatically registers the other side of the disk using the same parameters. This avoids deadlocks during volume consolidation and when moving files between migration levels.
VSM interfaces with the VERITAS device-manager interface (ltid) to allow VSM to share an optical-disk library with other applications.
Because VSM treats each optical disk as a tape volume, you can remove optical disks from a library and store them elsewhere at your site or send them offline just as you would store tapes.
For specific information on supported optical media, see “Notes on Supported Optical Media” on page 461.
Disk Method
The alternate disk (ad) method uses disk volumes. You can use the ad method in the following ways:
◆ To migrate files to another file system mounted on the same managed server
◆ As a remote method when used with NFS. If you NFS-mount a remote file system and register it as a VSM volume, VSM can use it as secondary storage. You must mount the NFS file system before registering it in the VSM volume database (VOLDB).
◆ With two-step tape or optical disk consolidation, as described in “Managing Volumes” on page 201.
Remote FTP Method
VSM supports the remote ft method for storing migrated files on remote file systems. This method copies and caches using the standard File Transfer Protocol (FTP).
60 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Storage Levels for Migrating Files
The remote volume servers that the ft method uses can be from a variety of different vendors and have different capacities. The result is to combine a local UNIX file system with one or more remote file systems and create the impression of one large virtual file system.
Note If VSM transfers files greater than 2 GB using the ft method, the remote volume server must be configured to accept and process files of this size.
A major difference between the ft method and tape or optical disk methods is that it transfers whole files without breaking them into parts, or granules.
Note If VSM is running on the remote volume server in addition to the local server, use the global stop file to prevent the migration of any data_file.GLABEL files from that remote server. See “Controlling Global Migration” on page 218 for more information. Having a stop file expedites the cleaning of remote file systems using migmdclean(1M).
NetBackup Method
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
The nb (NetBackup) method lets you use NetBackup to store copies of migrated files.
When you use the nb method, file migration causes a user backup of files and their associated granule header files to a previously defined NetBackup policy. The nb method is similar to the remote ft method in that it transfers whole files without breaking them into granules.
VSM issues a migcopy command to create the granule header file, referred to as GLABEL, for each entry in the work list. The GLABEL header file is deleted when the copy completes. VSM lists both the premigrated file and its GLABEL file in an input file for NetBackup.
After worklist processing is finished, VSM issues a bpbackup command to NetBackup, and the listed files are backed up. NetBackup backs up files using their full paths. The bpbkar command uses invisible input/output to avoid causing unnecessary file caching events.
Chapter 2, Planning VSM Configuration 61
Storage Levels for Migrating Files
After the backup operation is complete, or the deadman timeout configured for the nb method has expired, the GLABEL files are deleted. VSM sets the copy_date field in the FHDB for each file successfully backed up to be the UNIX date of the NetBackup image. This value is used to cache the files, and later by migmdclean to clean the databases and NetBackup volumes by setting obsolete entries to dead and removing them.
An error is logged in the VSM log file for each failed copy attempt, unless the entire backup operation failed (then the backup failure is logged). GLABEL files are recreated the next time a failed backup is migrated again.
Drawbacks to Using the NetBackup Storage Method
Before you determine if the NetBackup storage method will work for you, be aware of several major drawbacks to using it:
◆ You will need double the space for databases, because VSM and NetBackup each need the same amount.
◆ You cannot consolidate media.
◆ You cannot use partial caching.
◆ You cannot use file import/export features to move files between managed file systems.
◆ You cannot move files to other levels.
◆ If a file is premigrated using the nb method and subsequently renamed, that file will not be migrated.
◆ You cannot rely on access control list (ACL) and other attribute information being current after purged files are cached.
Volume Set Availability (hint value)If you create dual copies of migrated files (a Primary and an Alternate copy), VSM stores the copies on different volumes.
When VSM caches a file from secondary storage, it attempts to use the volume with the shortest access time. To ensure that this occurs, each storage method includes a volume set availability, or hint, that specifies how easily a file can be accessed.
VSM adds an access-time bias to ensure that it always requests the files in the order you specified. If for some reason VSM cannot access the Primary copy, it requests the Alternate copy on the other volume.
The possible values for volume set availability are as follows:
◆ library. Specifies that the volume is in an online library unit (an automounting or robotic device). Access is immediate, so no access-time bias is added.
62 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Storage Levels for Migrating Files
◆ operator. This parameter was previously used in VSM configuration. VSM-Java configures only library and vault.
◆ vault. Specifies that the volume is at a remote location. This choice adds 24 hours to the access time bias.
VSM-Java sets the volume set availability to library for the Primary copy of a file and assigns all other copies the value vault.
Note Cache requests are issued immediately, regardless of volume set availability.
You can think of library as immediately available and vault as incurring a caching delay.
Volume PoolA volume pool is a group of volumes to be used by a single application and protected from access by other applications and users. The VSM volume pool parameter designates a group of volumes from which VSM selects volumes where it can write copies of files.
If you do not specify a stripe’s volume name, the default volume pool HSM is used. The volume pool is set in the Select Local Device Properties dialog of the Basic and Database Configuration wizards and in the New Stripe dialog of the Advanced Configuration wizard.
Concurrent Stripes / Concurrent RecordingA concurrent stripe (which is also referred to as concurrent recording) allows VSM to migrate files to more than one device at the same time. When multiple devices are available, you can use this capability to speed up the migration process.
This section describes the default action of VSM for concurrent recording as defined in /usr/openv/hsm/bin/admincmd/migpolicy.script. You can modify or replace this standard script in order to migrate files in different ways.
To take advantage of concurrent recording, you must organize your Levels into multiple stripes as described in “Adding to Configured Systems” on page 145. Stripes that you have added appear below the Level in the Left Pane of the VSM-Java Administration dialog.
In the following example, the storage methods share the default volume pool (HSM) and each has two stripes. VSM makes a Primary and Alternate copy of each file and distributes them to four stripes. Assuming there are enough devices configured and available, VSM writes to four different devices simultaneously.
Chapter 2, Planning VSM Configuration 63
Storage Levels for Migrating Files
◆ The Tape 3 Stripe and Tape 1 Stripe under Primary Level: 1 each contain a Primary copy of migrated files. Files alternate going between the two devices.
◆ The Tape 3 Stripe and Tape 1 Stripe under Alternate Level: 2 each contain an Alternate copy of migrated files. Files alternate going between the two devices.
Concurrent Recording of Multiple Copies
You can take advantage of concurrent recording to speed up the migration process even if you make only one copy. VSM will distribute migrated files between the two stripes and write each copy on a separate device.
VSM is able to perform any number of concurrent migrations, although it does have some constraints:
◆ Number of secondary storage devices that are available.
◆ Server speed. Too many concurrent migrations interfere with the performance of the server. The actual number that VSM can support efficiently depends on the hardware, operating system, and applications that are running.
VSM has been tested with as many as five stripes for one Level.
Choosing the Best Storage MethodThe best method for storing your files is always the one that optimizes the migration and caching performance of your system. Two characteristics of your file system have the greatest effect on caching:
◆ Size of files
◆ Frequency with which they are accessed or modified
Alternate Level: 2
FileA
FileB Primary copy
Alternate copy
Tape 3 StripePrimary copy
Alternate copy
Primary Level: 1 Tape 1 Stripe
Tape 1 Stripe
Tape 3 Stripe
Alternate Level: 2
Primary Level: 1
64 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Storage Levels for Migrating Files
Consider the following device and media characteristics when making your choices:
◆ Access time
◆ Transfer rate
◆ Capacity
For example, if you have many small files that are frequently accessed, choose a device and media with a fast access time. Transfer rate is not as important if files are small. Optical disk generally has faster access time than tape.
As file size increases, however, the importance of the transfer rate also increases, and with very large file sizes the transfer rate becomes the most significant factor to consider. In most cases tape has a faster transfer rate than optical disk.
Media cost can also affect your choice of methods. For example, a site may be unable to afford fast enough devices or enough online capacity to handle all the requests. If cost constraints prevent you from achieving satisfactory cache times, set up special procedures for users, such as requiring that migrated files be requested a day before they are needed.
The following example uses optical disk for the file systems hsm1, hsm2, and hsm4 because they have many small files, and cartridge tape for file system hsm3 because it has mostly large files.
The files on /hsm3 are about 1.8 GB. They are also accessed or modified relatively infrequently (every 30 days). Therefore, the tape library is used for the Primary and Alternate copies of files migrated from this file system.
For all four of the file systems, volume set availability is always library for the first copy and vault for the second copy. This ensures that VSM always chooses the Primary copy for cache operations.
Storage Method Possibilities
File System Average File Size Storage Method
/hsm1 and /hsm2
18 MB Primary Level = Optical Disk Stripe
Alternate Level = Optical Disk Stripe
/hsm3 1.8 GB Primary Level = Tape 2 Stripe
Alternate Level = Tape 2 Stripe
/hsm4 1.5 MB Primary Level = Optical Disk Stripe
Alternate Level = Optical Disk Stripe
Chapter 2, Planning VSM Configuration 65
Volume Properties
Volume PropertiesYou can associate Volume Properties with stripes to define the media on which VSM will store migrated files. The Basic and Database wizards use some default values, but the Advanced Configuration wizard will always prompt you for the following volume information for all storage methods:
◆ The volume label that specifies the unique name of the volume to be recorded on the volume and in the VSM volume database (VOLDB).
◆ Whether you want to force the registration of a previously labeled volume. If you force registration on a volume, it cannot currently be registered in any VSM volume database.
Caution Forcing registration of a previously labeled volume destroys all information that may be on the volume.
◆ Whether you want to add the volume to the current stripe or to volume set 0, which makes the volume generally available for use should a stripe not have a free volume it can access (see “Keeping a Supply of Unused Volumes” on page 202 for more information).
For tapes and optical disk, the Advanced Configuration Wizard also prompts you to specify if you want to delay labeling until it is needed.
For the alternate disk method, all configuration wizards prompt you for the volume directory name, which is the file system mount point on the alternate disk. The entire capacity of the file system at the specified mount point is assumed, so do not register a disk partition for a directory below the mount point.
For the remote FTP method, all configuration wizards prompt you for the remote server’s fully qualified hostname (its IP address is also valid), the pathname of the file system on the remote server to which you will copy files, and the username/password to use.
For the NetBackup method, the Advanced Configuration Wizard also prompts you to specify the name of the NetBackup master server, the policy name to be registered as an NetBackup volume, and the name of the schedule defined for the policy.
Storage Levels for Moving Files Read this section if you are configuring multilevel migration for VSM.
You can configure up to eight migration Levels. The default configuration for moving files with VSM has four migration tiers. The odd-numbered migration Levels (1, 3, 5, 7) are generally associated with the Primary copy of migrated files and the even-numbered migration Levels (2, 4, 6, 8) are associated with the Alternate copy of migrated files.
66 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General File System Properties
The storage methods for moving files are the same as those described in “Storage Levels for Migrating Files” on page 57.
Which storage method is best for moving files depends on how you want to handle files as the time period in which they have not been accessed grows. For example, you may have migrated files initially to an optical disk library for fast access. As these files grow “older” and caching delays become less important, you may decide to move the files to tape at a higher migration level.
To configure multilevel migration, highlight a Hierarchy in the VSM-Java Left Pane, and select Edit > New Level, as described in “Adding to Configured Systems” on page 145.
General File System PropertiesThe Advanced Configuration Wizard lets you configure file system properties that can make your migration process more efficient. For each managed files system you can configure the following:
◆ File slice size
◆ Stop file quota
◆ Partial file caching
◆ Accelerated file system availability
Slice SizeYou can configure VSM to retain on disk a slice of data from the beginning of each file it migrates. Keeping this slice immediately available can be the most efficient use of disk space, because it allows some data to be read without caching the file.
Determining how large a slice should be to prevent unnecessary caching is dependent on whether read-ahead occurs on the migrated files and how much the read-ahead actually reads. Such reads are operating system-specific and outside VSM control. You must test your configuration to determine the best value for slice size.
You set slice values on the Advanced Configuration wizard Filesystem Properties dialog, on the General tab. The size of a slice can range from 0 to 2147483648 bytes (2 GB).
Quota on Migration Stop FilesUsers are able to specify files they want to prevent from migrating by listing them in special VSM control files named .migstop.
Chapter 2, Planning VSM Configuration 67
General File System Properties
You can limit the number of bytes that users can restrict from migration in their .migstop files. The default is 10,000,000 bytes (about 9.5 MB per user). If there are many users, the restricted space can become a significant consideration. For example, the default allows 100 users to restrict a total of just under 1 GB.
After the total quota is exceeded, no files listed in any non-superuser’s .migstop files are prevented from migration.
You set the quota on stop files in the Advanced Configuration wizard Filesystem Properties dialog, on the General tab.
Note VSM ignores this quota for file systems configured to manage Oracle archive redo logs.
Partial File Caching Trade-offsLike file slices, partial file caching is designed to provide access to less than an entire file without caching it all.
Note The ft and nb methods do not permit partial file caching.
When a file is partially cached, VSM allows read access to data as soon as it is cached to disk. When you use partial file caching, you create an effective slice for the file, which supersedes the configured file slice when processing read requests. The effective slice is kept on disk as the configured file slice was.
The effective slice is all data previously on disk, plus the data required for the read, plus the read-ahead, rounded up to the next whole granule. Subsequent partial caches of the same file do not reread data already cached, but resume caching at the end of the effective slice.
Partial file caching applies only to the first copy VSM attempts to cache from storage.
The decision to enable or disable partial file caching depends on the way your applications use migrated data.
Total file caching is preferable if your applications read migrated file data sequentially from start to end.
Partial file caching is preferable if your applications read a small portion of data without reading the entire file. Total file caching, if enabled in this situation, can increase system overhead and make your applications run longer.
Performance improvement is greatest if an application requires read access near the beginning of the file. VSM allows read access to partially cached data as soon as the granules containing the requested data are cached to disk. Total file caching, if enabled in this situation, delays read access until the entire file is cached.
68 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General File System Properties
If possible, determine the applications that read entire files and separate them from those that read only partial files. Place data for the former in a managed file system with partial file caching disabled, and data for the latter in another managed file system with partial file caching enabled. If you cannot separate the data in this way, enable partial file caching and configure the read-ahead to optimize overall performance.
If the majority of your applications read migrated file data sequentially from start to end, configure a larger read-ahead value. If the majority of your applications only read a small portion of the file data, configure a smaller read-ahead value. Reconfigure read-ahead as often as necessary to maintain optimum performance.
Accelerated Disk Space AvailabilityAccelerated disk space availability frees up disk space more quickly than normal VSM copy and purge processes. Rather than waiting for the entire migration process to run, you can set criteria to determine when VSM should interrupt migration and make space available immediately.
Note Take into consideration that accelerated disk space availability makes the migration process less efficient. If files remain to be migrated, the destination storage media must remount after each interruption.
If you use accelerated disk space availability, VSM stops migsweep and migcopy processing as soon as any one of the following three configured file system properties is satisfied:
◆ File is the maximum number of files processed by migsweep and migcopy VSM stops processing. The default is 50 files. A value of 0 signifies no limit.
◆ Time is the maximum time in minutes migcopy runs before VSM stops processing. The default is 30 minutes. A value of 0 signifies no limit.
◆ Kilobytes is the minimum amount of disk space (in kilobytes) freed by migsweep and migcopy before VSM stops processing. The default is 1 MB. A value of 0 signifies no limit.
If migcopy terminates before the work list is complete, Media Manager will remount the destination volume when migcopy starts up again.
Note VSM may run mignospace more than once to reach the free space value. However, running mignospace -N triggers accelerated disk space availability during a single migsweep process. The next time migsweep runs, it will not invoke accelerated disk space availability.
Chapter 2, Planning VSM Configuration 69
Criteria for Migrating Files (Water Marks)
You set the values for accelerated disk space availability in the Advanced Configuration wizard Filesystem Properties dialog’s Additional tab (the values can be changed after configuration by selecting Edit > Change Filesystem Properties).
Criteria for Migrating Files (Water Marks)VSM bases its decisions to migrate files and keep free space available by using the following criteria that you set with VSM-Java:
◆ The low-water mark specifies the point at which VSM should stop migration. You can set this value by clicking on the checkbox next to Desired Percentage Migrated on the Water Marks tab of the Advanced Configuration wizard Filesystem Properties dialog. A slide appears that lets you choose a percentage.
◆ The purge mark specifies the point at which VSM should stop removing files from local disk (purging them). You can set this value by clicking on the checkbox next to the Desired Percentage Purged on the Water Marks tab of the Advanced Configuration wizard Filesystem Properties dialog. A slide appears that lets you choose a percentage.
◆ The free space value specifies the point at which to start migrating files to secondary storage (this is also referred to as the high-water mark). You can change this value by moving the slide for Desired Percentage Free Space on the Water Marks tab of the Advanced Configuration wizard Filesystem Properties dialog. The slide appears when you select the Water Marks tab.
In the Advanced Configuration Wizard, the Migration Crieria tab in the Filesystem Properties dialog lets you specify how VSM will select files for migration (described in “File System Properties - Migration Criteria and Purge Criteria Tabs” on page 133 and “Criteria for Selecting Files to Migrate” on page 73).
Desired Percentage MigratedYou do not have to configure a low-water mark, which specifies the percentage of file system free space at which to stop premigration. VSM can operate satisfactorily without a low-water mark, but it may not work well with your configuration.
Without a low-water mark, VSM premigrates all files that meet the selection criteria, which could result in purging more files than necessary for efficient operation. (See “Criteria for Selecting Files to Migrate” on page 73 for detailed information.)
The low-water mark lets you limit the number of files that migbatch can premigrate. You express the low-water mark in terms of the percentage of space used in the file system. The default is no low-water mark.
70 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Criteria for Migrating Files (Water Marks)
A general guideline for defining the low-water mark percentage is to set it high enough so that the scheduled migbatch session selects and copies enough files to last until the next migbatch session. Migration operations can be time-consuming, and you configure them to occur at the most appropriate time.
VSM requires that the low-water mark percentage be equal to or greater than the free space percentage. A value of 80% gives good results in most cases, but there are other situations in which you will want to vary it:
◆ Increase the low-water mark percentage if the number of ready-to-purge files is not enough to satisfy requirements between migbatch sessions.
◆ Decrease the low-water mark percentage if VSM is removing more files than necessary to keep space available between migbatch sessions.
Desired Percentage PurgedThe purge mark specifies the percentage of disk space that you want set aside to hold files that could be purged from local disk (and become resident only on secondary storage). You express the purge mark in terms of the percentage of file system space that would be used if the files were purged. The default is to have no purge mark.
VSM does not require that you configure a purge mark.
Without a purge mark, VSM purges all local file copies that meet purging criteria whenever free space becomes less than the free space value. Purging all premigrated files can be less efficient than keeping some on disk.
VSM can access unpurged files immediately, while access to those same files after they have been purged imposes a caching delay (while the files are returned from secondary storage). The purge mark, therefore, can minimize or postpone removing local file copies from your file system, which avoids unnecessary caching delays when accessing those files.
A general guideline for defining the purge mark percentage is to set it low enough so that the mignospace process purges enough premigrated files to increase free space sufficiently while still retaining some ready-to-purge files in the file system. See “Criteria for Purging Files” on page 80 for more information on selecting which files the mignospace process removes first.
Set the value for the purge mark to be less than the low-water mark and more than the free space value. If the free space value is 10% (90% used space) and the low-water mark is 80%, a purge mark value of 85% gives good results in most cases.
The following figure illustrates what happens when the low-water mark and purge mark are set properly.
Chapter 2, Planning VSM Configuration 71
Criteria for Migrating Files (Water Marks)
Low-Water Mark and Purge Mark Example
11% of disk space is open
Scheduled migbatch command runs and premigrates files to the low-water mark of 20% free space
The mignospace command purges files premigrated at 4:00 AM until free space is at the purge mark
Premigrated files remain on disk that use the percentage of disk space equal to the difference between the low-water mark (20%) and purge mark (15%). This 5% of disk space is available for instant access should free space be needed quickly.
More new files are created
Disk space usage increases, but not above the 10% free space configured before migbatch is scheduled to run its daily migration.
This pattern indicates that purge marks and low-water marks are set correctly.
Free space
Premigratedfiles
Free space value 10%
Purge mark 15%
Low-water mark 20%
Low-water mark 20%
Low-water mark 20%
Purge mark 15%
Purge mark 15%
Free space value 10%
Free space value 10%
4:00 AM
2:00 PM
More file are created
Disk space usage increases
Free space decreases to 8%
Free space
Free space value 10%
Purge mark 15%
Low-water mark 20%
4:00 AM to 2:00 PM
Premigratedfiles
Free space
2:00 PM to 4:00 AM
Free space
72 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Criteria for Selecting Files to Migrate
Desired Percentage of Free SpaceThe purpose of the free space value (also referred to as the high-water mark) is to inform VSM that the file system is becoming too full to satisfy user storage requirements.
You express the free space value in terms of the percentage of free space remaining in the file system (the other water marks are set as the percentage of used space). The default is 10 percent.
A general guideline for setting the free space value is to set it high enough so that if the disk space above the configured maximum, there is still enough free space left for the largest file that you expect users to cache or create. If a user does attempt to create or cache a large purged file when there is not much space available, the migration daemon (migd) can start the mignospace command to purge files and make space available.
For most systems, the default free space value of 10% free space remaining is adequate for satisfactory VSM operation. However, there are conditions that require you to change the percentage:
◆ You can increase the free space value if you have a small file system in which users cache or create large files.
To illustrate this, consider the following example:
10% of a managed file system namedhsm1 is 116 MB. This percentage is adequate for a 100 MB file. However, on a managed file system namedhsm2, 10% is only 45 MB. If a user creates a 100 MB file on the hsm2 file system, it will be too large to maintain the free space at 10%.
If the same users access both file systems and create 100 MB files, the free space value should be higher (about 25% rather than 10%) on the hsm2 file system.
◆ You can decrease the free space value if 10% is more than enough space. Decreasing the percentage allows more files to reside on disk for fastest access, if that is what users need most.
Note DMAPI events only look at the free space value when a write occurs in the managed file system. If you reconfigure the free space value to be below the current configured value, nothing will happen until a write occurs in the managed file system.
Criteria for Selecting Files to MigrateThe next step in planning VSM configuration is to determine which files VSM selects to migrate.
Chapter 2, Planning VSM Configuration 73
Criteria for Selecting Files to Migrate
Administrators and users can use special control files in which they list specific files that they want VSM to migrate or to prevent from migrating. The files listed will take priority over other selection criteria. See “Controlling Global Migration” on page 218 for more information on how to create and use these VSM control files.
For VSM to consider a file for migration, the file must meet the following criteria:
◆ Must be a regular UNIX file (for example, not a device file or link).
◆ Must not already be a premigrated or migrated file.
◆ Must reside in a managed file system. If you want files to be migrated, they cannot reside within a nonmanaged file system, even if that file system is mounted in a managed file system.
◆ Must have a full pathname length fewer than 1024 characters.
Note A significant number of files with full pathname lengths greater than 1023 characters can eventually fill a file system because they can never be selected for migration. The migdbcheck(1M) man page provides more information on pathname length.
◆ Must not be a sparse file. You can force the migration of sparse files by using the migrate -f command, but you should know that when a sparse file is cached (recalled to disk), it expands to its non-sparse size.
◆ Must not be a zero-length file.
How VSM Selects Files to Migrate
If files meet the general criteria for migration, VSM selects them based on more specific criteria, as follows:
1. VSM eliminates files that are under the configured minimum age (in days since last accessed or modified) and size (in kilobytes). You set these minimums during configuration. The defaults are 7 days and 8 KB.
2. Next, VSM selects from the remaining files according to a formula that assigns weighting factors to file age and size to derive what is referred to as the threshold value for the file.
If a file’s threshold (its age and size calculation) equals or exceeds the threshold for the managed file system, the file can be migrated.
You configure migration criteria on the Filesystem Properties dialog’s Migration Criteria tab. You can change the file threshold, the weighting factors used to calculate the threshold, and the formula used to create the threshold.
74 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Criteria for Selecting Files to Migrate
The standard threshold_formula that VSM uses to calculate a file’s threshold value is as follows:
threshold = (min_age x age_weight) (+ or x) (min_size x size_weight)
The following list defines the variables in the threshold_formula:
◆ threshold is the result of calculating the size and age (time since last access) of files selected for migration using the configured threshold formula. A file is migrated if its threshold equals or exceeds the configured threshold value.
◆ min_age is the minimum number of days since a selectable file was last accessed or last modified.
◆ age_weight is a value that you assign to make the age of a file more or less important than its size when files are selected for migration (the default is 1).
◆ min_size is the minimum size of a selectable file in kilobytes.
◆ size_weight is a value that you assign to make the size of a file more or less important than its age when files are selected for migration (the default is 1).
◆ + (add) or x (multiply) either adds or multiplies the products of (min_age x age_weight) and (min_size x size_weight), depending on the value you assign to weight_operator. The default is multiply.
Note You can substitute a site-specified threshold formula for the standard VSM migration threshold formula. VSM uses one threshold formula to calculate threshold values when it selects files to migrate and to purge.
By configuring age and size values in the standard threshold formula, you can specify that larger files are migrated before smaller files that have an equal time since last accessed or modified, and less frequently accessed files are migrated before more frequently accessed files of equal size.
To determine if a file can be selected for migration, VSM goes through the following process:
1. Determines if the file’s time since last access or modification is greater than min_age. If it is not, the file is not selectable for migration.
2. Determines if the file’s size is greater than min_size. If it is not, the file is not selectable.
3. Determines the file’s calculated threshold based on the threshold_formula.
4. Determines if the file’s calculated threshold is greater than or equal to the result of the configured threshold value. If it is, the file can be selected for migration.
Chapter 2, Planning VSM Configuration 75
Criteria for Selecting Files to Migrate
The following figure illustrates how the threshold, min_age, and min_size affect which files are migrated.
Minimum Age, Minimum Size, and Threshold Values
Procedure for Setting File Migration Criteria
The following procedure and examples are based on the standard VSM threshold formula.
As a general rule, you should set min_age, min_size, and threshold so that VSM can select at least enough files to reach the low-water mark when migbatch premigrates files.
It is important to set these values so that VSM is not likely to migrate files that are needed on a regular basis. You do not want to migrate a file created today that will be updated tomorrow. Instead, migrate files that are not used regularly, especially if they are large.
The following procedure suggests how to determine criteria for selecting files to migrate:
1. Determine the size- and age-range of files that you must migrate to increase file system free space to the desired low-water mark.
2. Determine min_age and min_size criteria for the files you want to migrate.
- Set min_age to at least 1. This prevents VSM from migrating files the same day they were created.
Files with acalculated threshold lessthan the configured threshold_formula
File Age
Files not migrated, regardless of age, because they are under min_size
File
s no
t mig
rate
d, r
egar
dles
s of
siz
e, b
ecau
se
they
are
und
er m
in_a
ge
File
Siz
e
Files greater than min_age, min_size, and threshold that can
be migrated
76 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Criteria for Selecting Files to Migrate
- Unless you anticipate problems, leave min_size at its default of 8 KB. This allows VSM to migrate files larger than the default slice value (if they also equal or exceed min_age and threshold).
When setting min_size, remember that VSM never automatically migrates files less than the minimum size. If you set too high a value, a managed file system can fill up even if you have scheduled automatic migration. Too low a value can cause problems by significantly increasing migration time relative to the amount of additional space provided.
3. Determine the threshold at which you want to start selecting files that equal or exceed the minimum age and size.
4. Run the File System Analyzer to determine the amount of disk space your file selection criteria would free on a file system, and adjust the criteria to suit your needs. This process is described in “Experimenting with Scenarios” on page 187.
5. Monitor the file system and adjust your file-selection criteria, if necessary. For example, change the values if your current settings allow the file system to gradually fill up.
The following examples illustrate how a threshold_formula affects file migration.
Example 1:
Assume that for the managed file systems configured as hsm1, hsm3, and hsm4, you can migrate enough files by setting min_age to 1 day, min_size to 1 KB, and threshold to 30. VSM selects files for migration as follows:
◆ Never selects files that are under 1 day old or under 1 KB.
◆ Initially selects all files that are at least 1 day old and 30 KB.
◆ Selects files between 1 and 30 KB after all files of 30 KB or more are selected, and after a smaller file’s age increases to the point that its threshold factor equals or exceeds 30.
Chapter 2, Planning VSM Configuration 77
Criteria for Selecting Files to Migrate
Threshold Example 1 (threshold = 30)
Example 2:
Assume that the managed file system configured as hsm2 does not fill rapidly, but still can benefit from VSM management. You want to migrate all files that have not been accessed or modified in at least 30 days and are at least 300 KB.
First you set minimum amounts: you do not need to migrate files that have been accessed or modified within 30 days, or any files smaller than 10 KB, regardless of age.
If min_age is 30 and threshold is 9000, files 300 KB or larger can be selected for migration:
(30 x 1) x (s x 1) = 9000
30s=9000
s=300
threshold=3
File
Siz
e (in
kilo
byte
s)
min_age=1 File Age (in days)
30
25
20
15
10
5
0302520151050
File
s be
low
min
imum
age
for
mig
ratio
n
Files greater than min_age and min_size that can be migrated
Files below minimum size for migration
78 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Criteria for Selecting Files to Migrate
In this configuration, VSM selects files for migration as follows:
◆ No files under 30 days old or under 10 KB.
◆ All files that are larger than 300 KB and at least 30 days old.
◆ Thirty-day-old files between 1 and 299 KB after all files 30-day-old files of 300 KB or more are selected, and a smaller file’s age increases to the point that its computed threshold equals or exceeds 9000 (that is, a 200-KB file that is 50 days old is selectable after eligible larger and older files have been selected, because its threshold is 10000).
Threshold Example 2 (threshold=90)
.
Example 3:
In the following example, you can see the effect of cutting the threshold in half. The darkest shaded area that is bounded by the line labeled t1 indicates the extent of file selection by migbatch when it selects files for premigration.
When VSM does not find enough files to migrate, it calls mignospace to decrease the threshold by 50%. VSM then rescans the file system for migration candidates.
VSM will continue to cut the threshold in half until enough files are found to reach the desired percentage of free space. VSM never automatically migrates files under the configured minimum age or minimum size, even if it cannot find enough files to migrate.
File
Siz
e (k
iloby
tes)
File Age (days)
300
250
200
150
100
50
0300250200150100500
min_age=3
File
s be
low
min
imum
age
for
mig
ratio
n
Files greater than min_age and min_size that can be migrated
when threshold=90
Files below minimum size for migration
Chapter 2, Planning VSM Configuration 79
Criteria for Purging Files
The lighter shaded area that is bounded by the line labeled t2 illustrates how many new files are selected when mignospace cuts the threshold in half--in this case from 90 to 45.
Threshold Example 3 (threshold=90, cut to threshold=45)
Criteria for Purging FilesAfter specifying the criteria for migrating files, you determine criteria to define the sequence by which VSM purges those files that have been copied to secondary storage.
Note Setting purge attributes is an optional step in configuring VSM. The default purge attributes will purge the oldest files first, regardless of size. In many cases, this is satisfactory and need not be changed.
VSM may be configured to select files to purge similarly to the way it selects files to migrate. When properly configured, VSM purges files as follows:
File
Siz
e (in
kilo
byte
s)
File Age (in days)
30
25
20
15
10
5
0302520151050
File
s be
low
min
imum
age
for
min_age=3
Files greater than min_age and min_size that can be migrated
when threshold=90 (and also when threshold=45)
t1
t2
Additional files that can be
migrated when threshold=45
80 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Criteria for Moving Migrated Files
1. Eliminates files that are under the purge minimum age (in days) and size (in kilobytes). You can change these minimums with VSM-Java. The default is 0 for both.
2. Selects files to purge according to a formula that assigns weighting factors to file age and size to derive the file’s purge threshold value. If a file’s calculated purge threshold equals or exceeds the value that you configure for the managed file system, the file is eligible for purging.
You set purge criteria on the Filesystem Properties dialog’s Purge Criteria tab. If you select Weighted Calculation on this dialog, you can change both the purge threshold value that VSM allows and the weighting factors that VSM uses to calculate a file’s purge threshold.
The standard formula that VSM uses to calculate a file’s purge threshold is as follows:
purge_threshold = (min_age x age_weight) (+ or x) (min_size x size_weight)
The following list defines the variables in the threshold_formula:
◆ purge_threshold is the result of calculating the size and age (time since last access) of files selected for purging using the configured purge threshold formula. A file is purged if its threshold equals or exceeds the configured purge threshold value.
◆ min_age is the minimum number of days since a file was last accessed or last modified.
◆ age_weight is a value that you assign to make the age of a file more or less important than its size when files are selected for purging (the default is 1).
◆ min_size is the minimum size of a file in kilobytes.
◆ size_weight is a value that you assign to make the size of a file more or less important than its age when files are selected for purging (the default is 0).
◆ + (add) or x (multiply) either adds or multiplies the products of (min_age x age_weight) and (min_size x size_weight), depending on the value you assign to weight_operator. The default is add.
Criteria for Moving Migrated Files You should read this section if you are using the VSM’s multilevel migration capabilities.
After specifying the criteria for migrating and purging files, you can determine and specify other criteria VSM uses for selecting which migrated files to move to various migration Levels.
Chapter 2, Planning VSM Configuration 81
Criteria for Moving Migrated Files
Note If you use the ft or nb storage method, files are not eligible to be moved to a different migration level. They can only reside at Primary Level: 1 and Alternate Level: 2.
VSM selects migrated files to move similarly to the way it selects files to migrate:
1. From the files at the source migration level, VSM eliminates files that are under the move minimum age (in days since migrated or moved to this level, or since last accessed) and size (in kilobytes). The default minimum age is 7 days, and the default minimum size is 0.
2. Next, VSM selects from the remaining files according to a formula that assigns weighting factors to file age and size to derive what is referred to as the file’s move_threshold value. If a file’s calculated move_threshold equals or exceeds the threshold that you configured for the source migration level or method name, the file is eligible for moving.
3. After a file has reached its destination level, VSM does not move it any more.
You configure move criteria by selecting Edit > Change Level Properties and then selecting Weighted Calculation or Site-defined script from the selection box. The fields for changing move criteria are active only after you select one of these criteria.
You also configure if you want the selected files to be left active, obsolete, or dead when the move completes. The default is that VSM marks files at the source (first) level as dead in the VSM databases after it copies them to the destination (final) level. You can configure whether you want the source-level copy to be active, obsolete or dead in VSM databases. A file marked active is accessible for caching. A file marked obsolete has a newer copy to be used for caching (the data from files marked obsolete can be retrieved). A file marked dead is not available for caching, and its data cannot be retrieved.
The following figure illustrates the selection procedure for moving files.
82 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Criteria for Moving Migrated Files
Selection Criteria for Moving Files
The standard formula that VSM uses to calculate a file’s move threshold is as follows:
move_threshold = (min_age x age_weight) (+ or x) (min_size x size_weight)
The following list defines the variables in the move_threshold_formula:
◆ move_threshold is the result of calculating the size and age (time since last access) of files selected for moving using the configured move threshold formula. A file is moved if its threshold equals or exceeds the configured move threshold value.
◆ min_age is the minimum number of days since the file was migrated or moved to this level or since the file was accessed or modified, whichever is most recent (the default is 7 days).
◆ age_weight is a value that you assign to make the age of a file more or less important than its size when files are selected for purging (the default is 1).
◆ min_size is the minimum size of a file in kilobytes (the default is 0).
◆ size_weight is a value that you assign to make the size of a file more or less important than its age when files are selected for purging (the default is 1).
◆ + (add) or x (multiply) either adds or multiplies the products of (min_age x age_weight) and (min_size x size_weight), depending on the value you assign to weight_operator. The default is multiply.
Use defaultmove threshold
formula
Aremove criteriafor migration
levelsspecified inmigconf?
Start file selection process
Yes
Use move thresholdformula specified forthe migration level
No
Is asite-defined
move thresholdformuladefined?
Yes
Use site-definedmove threshold
formula
No
Chapter 2, Planning VSM Configuration 83
Customizing Migration, Purging, and Moving Criteria
Customizing Migration, Purging, and Moving CriteriaYou can use different weighting options in a threshold_formula by using the scripts migsweep.site or migsweepm.site, which are located in the VSM database directory.
To use migsweep.site for migrating or purging files, you can choose Site-define script as the Criteria you want to use for migration or purging when you set the Level Properties in the Advanced Configuration wizard. If you have already configured Level Properties and want to change the them to use migsweep.site, highlight a Level in the VSM-Java Administration dialog and select Edit > Change Level Properties.
To use migsweepm.site to move migrated files, highlight a Level in the Left Pane of the VSM-Java Administration dialog and select Edit > Change Level Properties. Choose Site-define script as the Criteria you want to use for moving files.
VSM calls migsweep.site and/or migsweepm.site for each file that exceeds the minimum age and size values you set in VSM-Java.
The input for both scripts is file name, size (in kilobytes), age (days since last access or modification), and threshold.
The migsweep.site and/or migsweepm.site file can be any type of program or script that echoes a true/false migration flag to standard output. VSM migrates, purges, or movies a file if output is 0, and does not migrate, purge, or move it if output is anything else. See “The migsweep.site and migsweepm.site files” on page 242 and the migpolicy(1M) man page for more information.
Example Planning ProcedureThe following procedure summarizes the steps in the planning process.
1. Complete the global configuration plan.
a. Choose the managed file systems and specify an hsmname for each.
b. Choose a pathname for each database directory.
c. Choose a pathname for each log file.
d. Choose a time for daily migrations to occur for each managed file system.
e. Choose a time for daily data collection to occur for reports.
f. Complete the “Global Configuration Worksheet” on page 86.
84 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Example Planning Procedure
2. Determine the storage levels to use for each managed file system. As a part of planning the storage levels, determine whether you want to use concurrent recording.
The Primary Level and Alternate Level direct the migration of Primary and Alternate copies, respectively. Levels 3 through 8 direct the multilevel migration of these same files to other storage media at a later time.
3. Determine general file system properties: slice size, stop file quota, and whether to use partial file caching and/or accelerated disk space availability.
4. Establish the migration thresholds for each managed file system:
a. Choose a start point (free space value) and stop point (low-water mark) for migration of files from managed file systems.
b. Choose how much disk space to make available (the purge mark) whenever free space on the file system drops below the free space value.
Generally good guidelines are 10% free space for the free space value, 15% free space for the purge mark, and 20% free space for the low-water mark. Specifying a value for the low-water mark provides a limit on how many files are selected for migration.
c. Choose criteria for selecting files for migration:
- Minimum age file to migrate. The default value is 7 days.
Note The minimum age is in days since the file was either accessed or modified, whichever is less.
- Minimum size file to migrate. The default value is 8 KB.
- Threshold. The default value is 0.
Although VSM caches a file when a user accesses it, there is a delay involved. Keeping frequently accessed files on the local disk eliminates delay and reduces load on the system.
d. Choose criteria for purging premigrated files:
- Minimum age file to purge (default is 0, effectively no minimum)
- Minimum size file to purge (default is 0, effectively no minimum)
- Purge threshold (default is 0, effectively no minimum)
Using a minimum age 5 days greater than the migrate minimum age, a minimum size of 0, and a purge threshold of 0 prevents VSM from purging migrated files for at least 5 days.
Chapter 2, Planning VSM Configuration 85
Example Planning Procedure
e. Choose criteria for moving files, if you are using multilevel migration:
- Minimum age file to move. The default is 7 days.
- Minimum size file to move (default is 0, effectively no minimum)
- Move threshold. The default value is 30.
Global Configuration Worksheet
Hierarchy/hsmname/Mount Point
Database Pathname
Logfile Pathname:
Migration schedule:
____________________________________
____________________________________
____________________________________
____________________________________
Data collection schedule (for reports): ____________________________________
Hierarchy/hsmname/Mount Point
Database Pathname
Logfile Pathname:
Migration schedule:
____________________________________
____________________________________
____________________________________
____________________________________
Data collection schedule (for reports): ____________________________________
Hierarchy/hsmname/Mount Point
Database Pathname
Logfile Pathname:
Migration schedule:
____________________________________
____________________________________
____________________________________
____________________________________
Data collection schedule (for reports): ____________________________________
Hierarchy/hsmname/Mount Point
Database Pathname
Logfile Pathname:
Migration schedule:
____________________________________
____________________________________
____________________________________
____________________________________
Data collection schedule (for reports): ____________________________________
86 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Example Planning Procedure
Managed File System Configuration Worksheet
File slice: _____
Stop File Quota: _____
Partial File Caching: _____ Size of read-ahead: _____
Accelerated Disk Space Availability: _____
Minimum before user access is allowed: Files migrated: _____ Minutes: _____ Kilobytes free: _____
Migration Thresholds (Water Marks)
Free Space Value: _____% Low-water Mark: _____% Purge Mark: _____%
Min. age to purge (days): _____
Min. size to purge (KB): _____
Purge files with threshold >: ____
Age weight: _____
Size weight: _____
Weight operator: _____
Min. age to move (days): _____
Min. size to move (KB): _____
Move files with threshold >: ___
Age weight: _____
Size weight: _____
Weight operator: _____
Min. age to migrate (days): _____
Min. size to migrate (KB): _____
Migrate files with threshold >: ____
Age weight: _____
Size weight: _____
Weight operator: _____
Alternate Disk
Media Capacity: _____
Granule size: _____
Remote FTP
FTP port number: _____
Deadman timeout: _____
Tape or Optical
Media Density: _____
Media Capacity (tape): _____
Block size (tapes only):_____
Granule size: _____
Deadman timeout: _____
NetBackup
Deadman timeout: _____
Storage Method: _____
Volume Pool Name: _____
Level Properties
Alternate Disk
Volume directory: ______________Remote FTP
Server: ______________
Username: ______________
Password: ______________
All methods
Volume label: ______________
Force registration: _____
Add to current stripe:_____
NetBackup
Server: ______________
Policy: ______________
Schedule: ______________
Volume Properties
Stripe Properties
Purge Criteria Move CriteriaMigration Criteria
File System Properties
Hierarchy Properties:
Managed File System Name (hsmname) _________________________
Dual Copies: _____
Chapter 2, Planning VSM Configuration 87
Example Planning Procedure
88 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM-Java Overview
3 This chapter explains the components of VSM-Java, the Java-based interface used by VSM.The major topics discussed in this chapter are as follows:
◆ “About the Interface” on page 89
◆ “Administration Dialog” on page 92
◆ “Administration Toolbar” on page 95
◆ “Administration Menu Bar” on page 97
About the InterfaceEach VSM server host that is to accept VSM-Java must be running the migrd daemon. To start migrd, run the following command:
/usr/openv/hsm/bin/startmigd
To start VSM-Java on a UNIX platform, run the following command:
/usr/openv/java/migsa &
To start VSM-Java on a Windows NT or Window 2000 system, select Start > Programs > VERITAS Storage Migrator > Unix Administration.
You will see a screen like the one in the following figure.
89
About the Interface
VSM-Java Main Dialog
The VSM-Java user interface lets you configure VSM on a server and perform a variety of operations, including running VSM management commands.
Note VSM-Java is accessible to blind, color-blind, or low-vision users, deaf or hard-of-hearing users, and mobility impaired users.
Two techniques are available for configuring VSM:
◆ Configuration Wizards walk you through the configuration process. Wizard dialogs contain step-by-step instructions.
◆ The Edit menu lets you change an existing configuration.
Instructions for installing VSM-Java are included in the VSM installation guide. You must follow these instructions to ensure VSM-Java has the necessary NetBackup and Media Manager components.
You can run the VSM-Java display locally or remotely. Note the following in determining where you want to run the display:
◆ On HP-UX or Solaris systems you can run VSM-Java locally on the VSM server. Files are installed to /usr/openv/java.
◆ You can install VSM-Java on a PC and use it to manage VSM servers on any of the supported UNIX platforms.
90 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Login Screen
- To install VSM-Java on a PC, use the InstallShield on the VSM release media. VSM-Java files are installed to a directory of your choice. The default path name is C:\Veritas\java.
- The release level of VSM-Java on the local host must match the release level of VSM on the server being managed.
- If you use SGI machines, you run VSM-Java from NT or Windows 2000, or from a Solaris or HP-UX system.
Note If you will run tape and optical devices, you must configure those devices and start the Media Manager daemon before running VSM-Java. See the VSM installation guide for information.
Login ScreenTo log into a VSM server and use VSM-Java, you must provide the host name of the server. The default for the field is the host name from which you started VSM-Java, if you have started it on a VSM server. You can use any VSM server name.
The username you provide must either be root or another username with superuser privileges.
Login Dialog
After you have provided the host name and user name, you enter the password and either press <Enter> or click the Login button.
Chapter 3, VSM-Java Overview 91
Administration Dialog
Administration DialogThe VSM-Java Administration dialog has a Menu Bar, Toolbar, Left Pane (or Tree), Right Pane, and Bottom Pane, as shown in the following figure.
Components of the VSM-Java Main Dialog
What is highlighted (selected) in the Left Pane determines what is displayed in the Right Pane and which buttons and menu selections are active. For example, if the VSM server is highlighted, the Right Pane displays all of the file systems on the server.
If the server is highlighted and you select Edit on the Menu Bar, you will find that only one selection is active, as shown in the following figure.
Edit Menu When Server Is Selected
Menu Bar
Toolbar
Left Pane
Bottom Pane
Right Pane
92 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Administration Dialog
Left PaneThe Left Pane (or Tree) displays the tree structure of the VSM server and its configured hierarchies.
To expand or contract the information displayed in the Left Pane, click + or -.
VSM-Java uses the term Hierarchy to refer to a managed file system and its associated storage information. For example, a managed file system hsm1 is called a Hierarchy in the Left Pane when it is associated with configured stripes and migration levels.
What you highlight in this tree changes the information shown in the Right Pane.
Right PaneWhen you highlight an item in the tree on the left, the panes on the right display information about that item. Clicking the column headings on the right Pane sorts the information in the Pane according to the column on which you click, toggling from ascending to descending sorts.
You will find it informative to highlight various elements in the Left Pane to see how the Right Pane changes.
When you highlight the server, information about all the file systems is displayed.
From left to right, the Right Pane displays the name, VSM state for managed file systems, and the percentage of space used. For managed file systems, the state shown can be Idle, Idling, Maintenance, or Inactive. If the state field is blank, the managed file system state is Active.
If you highlight another item in the Left Pane, you will see details about that item. For example, when you highlight Hierarchy: hsm1 in the Left Pane, the Right Pane displays details about the hsm1 hierarchy.
Chapter 3, VSM-Java Overview 93
Administration Dialog
Bottom PaneThe bottom Pane displays the progress of VSM commands. Most of the commands invoked from the Actions pull-down menu run asynchronously, and the Bottom Pane displays a summary of their progress. To run a system status report, select View > System Status.
Bottom Pane Display
To see more job detail, highlight an activity in the in the Bottom Pane. The recent output for that job is displayed in the Right Pane, as shown in the following figure.
Right Pane Displaying Activity Output
The Right Pane displays recent output from the System Status, which the Progress column shows as being 6% complete.
94 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Administration Toolbar
Administration ToolbarThe VSM-Java Administration Toolbar is located near the top of the main screen, just below the Menu bar. Select View > Show Toolbar to toggle whether the toolbar is displayed.
Which tools can be selected and run depends on what you have highlighted in the Left Pane and the state of the VSM server and file systems.
The following figure shows the Toolbar when the VSM server is highlighted in the Left Pane and there are file systems that are not configured to be managed.
Toolbar when Server Is Highlighted and some File Systems not Configured
You can see that the Delete and Change Properties icons (the sixth and seventh from the left) are grayed out or stippled. The grayed out icons cannot be selected. In this case, they are not selectable because the functions those tools provide do not apply to the VSM server.
If you highlight a Hierarchy in the Left Pane all of the tools become active, although the configuration tools are active only if there are file systems that can be configured The following figure shows the toolbar when a Hierarchy is highlighted and there are other file systems that could be configured.
Toolbar when Hierarchy Is Highlighted
The icons in the tool bar represent the following tools.
Change Server IconClick the Change Server icon to invoke the tool that logs out from this server and logs in to another server.
Basic Configure Wizard IconClick the Basic Configuration Wizard icon to activate the Basic Configuration Wizard.
Chapter 3, VSM-Java Overview 95
Administration Toolbar
Advanced Configure Wizard IconClick the Advanced Configuration Wizard icon to activate the Advanced Configuration Wizard.
Database Configuration Wizard IconClick the Database Configuration Wizard icon to activate the Database Configuration Wizard and add VSM management to Oracle archived redo logs.
New IconWhen the server is highlighted in the Left Pane, click the New icon to add a new hierarchy. When a hierarchy is highlighted in the Left Pane, click the New tool to add a migration level to the hierarchy. When a Level is active in the Left Pane, click the New tool to add a stripe. When a stripe is active in the Left Pane, click the New tool to add a volume.
Delete IconClick the Delete icon to remove an element from the configuration. This tool is not active when the server or an unmanaged file system is highlighted in the Left Pane.
Change Properties IconClick the Change Properties icon to change the properties of an element in the configuration. This tool is not active when the server or an unmanaged file system is highlighted in the Left Pane.
File Browser IconClick the File Browser icon to open the VSM File Browser interface.
96 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Administration Menu Bar
File System Analyzer IconClick the File System Analyzer icon to open the File System Analyzer interface.
Refresh IconClick the Refresh icon to refresh the display. When you invoke this tool, the display returns to the opening screen with the server highlighted.
Administration Menu BarThe menu bar, found at the top of the main VSM-Java screen, provides access to all VSM-Java functions. Which menus can be selected depends on what is highlighted in the Left Pane.
VSM-Java Menu Bar when Hierarchy Is Highlighted
File MenuUse the File menu to change servers or exit VSM-Java. If you select Change VSM Server, a confirmation dialog appears. If you confirm your choice, the Login dialog appears. If you select Exit, VSM-Java exits. This menu is not affected by what is highlighted in the Left Pane.
Edit MenuUse the Edit menu to add, change, or delete properties in the VSM configuration. The Edit menu provides different selections depending on what is highlighted in the Left Pane, as the following figure shows.
Chapter 3, VSM-Java Overview 97
Administration Menu Bar
Edit Menu Selections
View MenuUse the View menu to control the main VSM-Java window and to gather system status. You can toggle the display of the Toolbar, set your preference for obtaining and displaying granule counts when viewing information about a volume, refresh the display, and clear, detach, or cancel a job you have highlighted in the Bottom Pane.
Volume Preferences
Select View > Volume Preferences to control whether VSM-Java will gather and report information about granule counts when it displays information about volumes in a stripe.
The default behavior is to display no granule counts. When you highlight a stripe, the Right Pane displays the volume label, the space it uses, the flags that are set on it, and the volume pool to which it belongs.
To see how the View > Volume Preferences selection changes the display, highlight a stripe and select View > Volume Preferences > Wait for Granule Count.
Non-managed
Server Selection Hierarchy Selections
Level Selections Stripe Selections
Managed Filesystem Selections
Filesystem Selection
98 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Administration Menu Bar
The display in the Right Pane expands to include the live and obsolete granule counts and the total bytes the granules use.
The Bottom Pane provides the status of the granule count. How quickly VSM-Java can obtain the information about granule counts and display it varies depending on such factors as the size of the volumes and how easily accessed they are.
When you choose Wait for Granule Count, VSM-Java stops other activity until the job is complete. If you select Delayed Granule Count, the job is run in the background and you can continue to use VSM-Java while it completes.
System Status
If you select View > System Status, VSM-Java will begin to gather data about VSM managed file system activity. A new System Status job appears in the Bottom Pane. If you highlight the system status job, the system status output will begin to display in the Right Pane, as shown in “View Menu Selections” on page 99.
Managing Jobs on the Activity Table (Bottom Pane)
Three View menu selections control the display of jobs in the Bottom Pane.
Clear Completed Jobs from Activity Table removes jobs that have succeeded or failed from the display in the Bottom Pane.
Detach Selected Job from Activity Table removes the job from the display, but the job continues to run.
Cancel Selected Job in Activity Table stops the job and removes it from the display.
View Menu Selections
Chapter 3, VSM-Java Overview 99
Administration Menu Bar
Actions MenuThe Actions menu provides access to VSM configuration and management tools. The use of these tools is described in the subsequent chapters of this manual, as follows:.
◆ The use of the Configure selection is described in “Configuring VSM” on page 103.
◆ The Server, Filesystem, Level, and Volume selections are described in “Managing VSM” on page 189.
◆ The Schedule, File Browser, File System Analyzer, and Reports selections are described in “VSM-Java Tools” on page 151.
Configure
Select Actions > Configure to activate VSM configuration wizards or to activate the Manage Archive Redo Logs interface.
The Basic Configuration Wizard, Advanced Configuration Wizard, and Database Configuration Wizard step you through your configuration process; they are described in “Configuring VSM” on page 103.
The Database Configuration Wizard and the Manage Archive Redo Logs interfaces provide special tools for managing Oracle archive redo logs in a file system. The archive redo log management tool is described in “Managing Oracle Archive Redo Logs” on page 151.
Management Actions
You can always select the first-level Actions menu choices, but for the second-level Server, Filesystem, Level, and Volume choices that you expand to the right, the what is highlighted in the Left Pane helps determine what you can select.
For example, if you have the server highlighted in the Left Pane and you select Actions > Level, you cannot make any further selections. If you have multiple migration levels configured and highlight a Level in a Hierarchy, you can make any of the selections available from the Actions > Level menu.
100 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Administration Menu Bar
What you can choose is also dependent on the condition of VSM. If a managed file system state is Idle, you can select only those tasks that can be performed while the state is Idle.
VSM Tools
The bottom four selections on the Actions menu launch new interfaces to VSM tools.
◆ The Schedule selection lets you schedule running the VSM commands migbatch, migmove, or mignewlog and collecting data for Reports. This interface is described in “Scheduling Tool” on page 173.
◆ The File Browser selection lets you view the files in a managed file system or perform tasks such as migrating or purging files. The File Browser is described in “File Manipulation with the File Browser” on page 167.
◆ The File System Analyzer selection lets you scan file systems on the VSM server. This interface helps you visualize how files age and grow on your managed file systems. The File System Analyzer is described in “File System Analyzer” on page 179
◆ The Reporting selection opens the Storage Migrator Reporting interface. This tool gives you access to information that was collected when Report information was scheduled to be collected. The graphical user interface lets you easily monitor file system activity and trends. “Reporting Tools” on page 158 provides information on the interface.
Help MenuUse the Help menu to bring up the online help window and to display the VSM-Java interface version information.
VSM-Java help is context-sensitive when you have a dialog open that displays a Help button. If you click Help, you will go directly to information about that window.
Chapter 3, VSM-Java Overview 101
Administration Menu Bar
102 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Configuring VSM
4 This chapter describes procedures for configuring VSM.Before you configure your system, complete your system configuration planning, as described in “Planning VSM Configuration” on page 45.
To perform an initial VSM configuration, use a configuration wizard. Wizard dialogs contain step-by-step instructions, and additional online help is available from those dialogs.
◆ The Basic Configuration Wizard guides you through the basic configuration process. This wizard assumes you want to accept most default values. It is described in “Basic Configuration Wizard” on page 103.
◆ The Advanced Configuration Wizard offers greater flexibility for customizing your initial VSM configuration. It is described in “Advanced Configuration Wizard” on page 113.
◆ The Database Configuration Wizard guides you through configuring VSM management for Oracle archive redo logs. It is described in “Database Configuration Wizard” on page 135.
To change the configuration, use the Edit menu as described in “Editing the Configuration” on page 145.
Basic Configuration WizardThe Basic Configuration Wizard steps through a series of dialogs to configure an unmanaged file system to be a VSM-managed file system. The wizard assumes you want to use most default values. It prompts you for which file system to manage and which storage method to use. The last dialog summarizes all configured and default values for the managed file system.
The wizard will not commit configuration information until you click on the Finish button in the Configuration Summary dialog.
To launch the Basic Configuration Wizard, select the Actions > Configure > Basic Configuration Wizard menu.
103
Basic Configuration Wizard
Use the Configure pulldown menu or click the Basic Configure tool to activate the Basic Configuration Wizard.
Basic Configuration - Select File System DialogSelect a file system you want to manage with VSM. The file system must be mounted as a DMAPI file system before it will appear as a configurable file system in this dialog.
Select Filesystem Dialog
Note This chapter does not explicitly tell you to click Next to move forward to the next dialog in the Wizard after you have completed your selections. When instructions for one dialog are complete, it is assumed you will click Next.
Basic Configuration - Enter Values DialogProvide the path names for the directories in which the databases and log files will reside and select times for automatically migrating files and collecting data for activity reports.
104 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Configuration Wizard
Basic Configuration Enter Values Dialog
1. Specify a path name for the directories in which VSM databases reside. You must provide a value. Click Default Path to use the default /usr/openv/hsm/database.
Note If you use the default values for database and log file paths, you must monitor the size of the files to ensure that the /usr directory does not become full.
2. Specify a path name for the directories in which VSM logs reside. You must provide a value. Click Default Path to use the default /usr/openv/hsm/logs. The full path cannot be more than 1023 characters.
3. The checkbox for migrating files daily is checked by default. Migrating files daily ensures that if something such as a power failure were to prevent migration one day, migration could still occur the next day without intervention, and your migrated data will be acceptably current. You can select times on the hour.
4. The checkbox for collecting report data daily is checked by default. Collecting VSM report data daily ensures that if something such as a power failure were to prevent report data collection one day, the collection could still occur the next day without intervention, and your report data will be acceptably current. You can select times on the hour.
Basic Configuration - Select Method DialogSelect a method for storing files migrated from the managed file system.
Chapter 4, Configuring VSM 105
Basic Configuration Wizard
Select Storage Method Dialog
❖ Select from among the following alternatives:
- Local Devices (Tape/Optical): Use the local tape or optical disk methods. These methods may use either rewritable or write once, read many (WORM) media.
- Remote Server (FTP): Use the remote method and transfer file data using the File Transfer Protocol (FTP).
- Alternate Disk (AD): The alternate magnetic disk method is used for migrating files to another file system mounted on the same VSM server or as a remote method when used with NFS.
- NetBackup (NB): Use the NetBackup storage method.
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
Basic Configuration - Properties DialogsUse the Properties Dialog to select the properties for the managed file system and storage method being configured.
The information you are asked to supply in this dialog depends on your selection in the Select Method dialog (just before this one). This section describes each of the dialogs that can follow the dialogs after the Select Method dialog.
106 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Configuration Wizard
Basic Configuration - Select Local Device Properties Dialog
Select the properties for the storage method. The following figure shows the default values provided.
Local Device Properties Dialog
1. Desired Percentage Free Space: Select the percentage of free space below which VSM makes more space available by initiating migration operations. The default value is 10 (percent).
2. Minimum Age in Days: Provide a value to specify that VSM will not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
3. Minimum Size in Kilobytes: Provide a value to specify that VSM will not migrate files smaller than this size. The default is 8 KB.
4. Number of Copies: Select whether you want one or two (which is the default) copies migrated to secondary storage.
Caution Configuring one copy rather than two can result in data loss should the media that holds the copy fail in any fashion.
Chapter 4, Configuring VSM 107
Basic Configuration Wizard
Note If only one tape or optical device with a single drive is attached, the default is one copy.
The Basic Wizard allows you to create only one copy for the ad, ft, and nb methods.
5. First copy: Select the storage medium for the first (primary) copy.
6. Pool Name: Select the volume pool name for the first (primary) copy. The pool name must exist or be created using Media Manager.
7. Second Copy: Select the storage medium for the second (alternate) copy (if configured).
8. Pool Name: Select the volume pool name for the second (alternate) copy (if configured). The pool name must exist or be created using Media Manager.
Setting up VSM Volumes Using Media Manager
VSM relies on the NetBackup Media Manager to control access to the tape robot and libraries it uses to hold its migrated files. VSM also relies on Media Manager for the mounting and unmounting of volumes on the locally attached drives (VSM does not have its own local drive and tape management functionality).
You must configure Media Manager on the VSM server and create a separate media pool to hold the VSM media you wish to use. Typical pool names are HSM1, HSM2, and so on.
VSM will query the Media Manager server through vmquery to determine if there are any available volumes in the configured pool. If any volumes are available, VSM will register a volume to itself using vmquery -assignbyid. VSM then places the media into its own volume database (VOLDB). After a piece of media is registered to VSM and has a VOLDB entry, VSM has all the information it needs to issue a mount request for this volume.
To request the mount or dismount of media, VSM issues the Media Manager commands tpreq and tpunmount. The tpreq command causes the robot to mount the media specified on the command line into a drive. After the media is mounted in the drive, the tpreq command creates a symbolic link to the drive’s device file through the file name passed to tpreq on the command line.
VSM continues to monitor the results of tpreq. After successful completion (that is, tpreq exiting with status 0), VSM can write or read to the media. The communication between the media and VSM is accomplished by the VSM migcopy command writing
108 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Configuration Wizard
and/or reading to or from the symbolic link file created by tpreq. After migcopy is finished, VSM issues the tpunmount command to send a signal to the robot to unmount the drive. After the unmount completes, VSM removes the symbolic link.
Basic Configuration - Select Remote Server Properties Dialog
Select the properties for the storage method. The following figure shows the default values provided.
Remote Server Properties Dialog
1. Desired Percentage Free Space: Select the percentage of free space below which VSM will make more space available by initiating migration operations. The default value is 10 (percent).
2. Minimum Age in Days: Provide a value to specify that VSM will not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
3. Minimum Size in Kilobytes: Provide a value to specify that VSM will not migrate files smaller than this size. The default is 8 KB.
4. Number of Copies: This field is not selectable. The wizard does not allow you to configure more than one copy for the FTP method.
Chapter 4, Configuring VSM 109
Basic Configuration Wizard
5. Server Name: Specify the name of the remote server. This can be the fully qualified host name or the IP address of the server. VSM uses this name on the ftp open command as the host parameter. It must be a valid FTP host.
6. Directory: Specify the full path name of the file system directory on the remote server. The VSM user name on the VSM server must have read and write permissions to this remote directory. You can specify any directory on the remote server that is not already registered for VSM.
7. User Name: Specify the user name that VSM will use when accessing the remote server from the VSM server through FTP. This name must be valid on the remote server and also must have read and write access to the remote file system that you are using for migration.
8. Password: Specify the password for the user name on the remote server that you already specified.
Basic Configuration - Select Alternate Disk Properties Dialog
Select the properties for the storage method. The following figure shows the default values provided.
Alternate Disk Properties Dialog
1. Desired Percentage Free Space: Select the percentage of free space below which VSM will make more space available by initiating migration operations. The default value is 10 (percent).
2. Minimum Age in Days: Provide a value to specify that VSM will not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
110 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Basic Configuration Wizard
3. Minimum Size in Kilobytes: Provide a value to specify that VSM not will migrate files smaller than this size. The default is 8 KB.
4. Number of Copies: This field is not selectable. The Basic Configuration wizard does not allow you to configure more than one copy for the alternate disk method.
5. Volume Directory Name: Specify the file system mount point. Make sure the specified file system is mounted before registering the volume. Do not register a disk partition for a directory below the mount point because the entire capacity of the file system at the mount point is assumed.
Basic Configuration - Select NetBackup Properties Dialog
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
Select the properties for the storage method. The following figure shows the default values provided.
The NetBackup Properties Dialog
.
Chapter 4, Configuring VSM 111
Basic Configuration Wizard
1. Desired Percentage Free Space: Select the percentage of free space below which VSM makes more space available by initiating migration operations. The default value is 10 (percent). See the figure “The NetBackup Properties Dialog” on page 111.
2. Minimum Age in Days: Provide a value to specify that VSM not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
3. Minimum Size in Kilobytes: Provide a value to specify that VSM not migrate files smaller than this size. The default is 8 KB.
4. Number of Copies: This field is not selectable. The Basic Configuration does not allow you to configure more than one copy for the NetBackup method.
5. Storage Unit: Select the storage unit from the list box. Values in the list box reflect storage units available from the NetBackup configuration.
The selected storage unit will be used to create a new NetBackup policy. The NetBackup policy name is made by concatenating the hsmname with the string nbhsm, as in hsm1nbhsm. This policy will be used to copy migrated data whenever files are migrated from the managed file system. If a policy with the same name already exists in the NetBackup configuration, it will be replaced with the newly created policy without warning.
The newly created policy has its attributes set as follows:
- Policy name: hsmnamenbhsm
- Storage Unit: Select from the list box
- Volume Pool: HSM-NB
- Schedule Type: UBAK (a user-directed backup with the retention level of 9).
Caution It is highly recommended not to change any attributes of the VSM-created policy. Doing so may cause unpredictable consequences for VSM operation.
Basic Configuration - Configuration Summary DialogThe last dialog summarizes all configured and default values for the managed file system.
The following figure shows the values for a system that uses mostly default characteristics:
◆ Uses default values for database paths and log files
◆ Creates the default two copies of files and migrates both to optical disk
112 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
◆ Default values for free space, file space and file age
◆ Migrates files daily at 2:00 a.m.
◆ Generates report data daily at 4:00 a.m.
Configuration Summary Dialog
.
1. Review the summary and make sure you are satisfied with the configuration.
2. Click the Finish button. The wizard will not commit the configuration information until after you click Finish.
Advanced Configuration WizardThe Advanced Configuration Wizard steps through a series of dialogs to configure an unmanaged file system to be a managed file system.
The wizard steps through creating a new hierarchy. The wizard will not commit configuration information until you click the Finish button on the Filesystem Properties dialog.
To launch the Database Configuration Wizard, use the Actions > Configure > Advanced Configuration Wizard menu selection.
Chapter 4, Configuring VSM 113
Advanced Configuration Wizard
Note To change an existing configuration, use the Edit menus described in “Editing the Configuration” on page 145. If all of the file systems that are mounted for VSM management are already managed, the configuration wizards are greyed out and cannot be selected.
Use the Configure > Advanced Configuration Wizard pulldown menu or click the Advanced Configure tool to activate the Advanced Configuration Wizard.
Advanced Configuration - Select File System DialogThe selection box shown in the following figure lists nonmanaged file systems that are mounted correctly for VSM management.
Select Filesystem Dialog
.
❖ Select the file system you want to configure as a managed file system (hierarchy).
Advanced Configuration - Enter Values DialogEnter values about the file system you are configuring to be hierarchy.
114 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
Advanced Configuration Enter Values Dialog
.
1. Specify a path name for the directories in which the VSM databases reside. You must provide a value. Click Default Path to use the default /usr/openv/hsm/database.
VSM-Java appends /hsmname/database to the end of the path name you specify. For example, if you use the default path and your managed file system is named beta, the database files will reside in /usr/openv/hsm/database/beta/database.
Note If you use the default values for database and log file paths, you must monitor the size of the files to ensure that the /usr directory does not become full.
2. Specify a path name for the directories in which VSM logs reside. You must provide a value. Click Default Path to use the default /usr/openv/hsm/logs. The full path cannot be more than 1023 characters. The log file name in this directory will be hsmname.log.
3. The checkbox for migrating files daily is checked by default. Migrating files daily ensures that if something such as a power failure were to prevent migration one day, migration could still occur the next day without intervention, and your migrated data will be acceptably current. You can select times on the hour.
4. The checkbox for collecting report data daily is checked by default. Collecting VSM reporting data daily is useful for the same reasons as migrating files daily. You can select times on the hour.
Chapter 4, Configuring VSM 115
Advanced Configuration Wizard
Advanced Configuration - Hierarchy Properties DialogCreate a name for the new VSM hierarchy.
Hierarchy Properties Dialog
.
1. Specify the name of the hierarchy in alphanumeric characters; it cannot be more than 14 characters.
2. Dual Copies: Leave this box checked if you want to migrate two copies to secondary storage (which is the default). Deselect this box only if you want VSM to migrate just one copy to secondary storage.
Caution Configuring one copy rather than two can result in data loss should the media that holds the copy fail in any fashion.
You will define a Primary Level for the selected hierarchy. If you select Dual Copies, you will also define an Alternate Level. If you want to configure more Levels, you can do so later by selecting Edit > Change Filesystem Properities.
Advanced Configuration - New Level DialogThe first time this dialog appears, define a Primary Level for this hierarchy.
116 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
The New Level Dialog
.
❖ Define a Primary level for the selected hierarchy. If you intend to use two migration (dual) copies, you will define an Alternate Level after you have defined the Primary Level.
When the Primary Level is defined, it appears in the Left Pane as a child of the Hierarchy that is named Primary Level: 1.
To define more levels for multilevel migration, follow the procedure in “Adding to Configured Systems” on page 145.
Advanced Configuration - New Stripe DialogSelect a storage method for the level you are defining.
The New Stripe Dialog
.
Chapter 4, Configuring VSM 117
Advanced Configuration Wizard
1. Method: Select the storage method from among the following alternatives:
- Tape 1, Tape 2, Tape 3: Your choice of tape method depends on the type of device you have on your site. If you have more than one type of device, you can analyze their characteristics to determine the method to use for a managed file system.
The values shown after the tape methods reflect the default values for tapes. You can change them to reflect other devices by changing the media density on the Physical tab of the Stripe Properties dialog, as described in “Physical Tab (Tape and Optical Media)” on page 120.
- Optical Disk: Rewritable optical disk method.
- WORM Disk: Write once, read many optical disk method.
- Alternate Disk: The alternate magnetic disk method is used for migrating files to another file system mounted on the same VSM server or as a remote method when used with NFS.
- FTP: Remote method using File Transfer Protocol.
- NetBackup: Use the the NetBackup storage method.
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
2. Pool: Specify the Media Manager pool for tape and optical volumes; the default is HSM. This pool must exist or be created using Media Manager.
Advanced Configuration - Stripe Properties DialogsUse the Stripe Properties dialogs to select the stripe properties for the Level (for example, Primary) that you are configuring.
The information you are asked to supply in this dialog depends on your selection in the New Stripe dialog.
Note In the Stripe Properties dialogs for tape and optical media, you must click on the tabs to move forward in the stripe configuration rather than clicking Next at the bottom of the dialog. Clicking on Next will go forward in the configuration without changing default stripe properties. Next does not go forward to the next tab. It goes forward to volume properties configuration.
118 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
Stripe Properties Dialog for Tape and Optical Media
Assign the general stripe properties for tape and optical disk methods.
The method you chose provides unique configuration options, which are shown on three tabbed pages, as in the following figure.
General Tab (Tape and Optical Media)
General Tab, Stripe Properties Dialog for Tape and Optical Disk
.
Assign general properties for tape and optical media as follows:
1. Method: Indicates the storage method you selected in the New Stripe dialog.
2. Pool: Indicates the name of the Media Manager pool you specified in the New Stripe dialog.
3. Append checkbox: If checked, place multiple migrations on the same volume until it reaches full capacity. Always check this box. If it is not checked, each migration always starts on an empty volume.
4. End of Tape checkbox: Applies to tape methods, and only appears on those dialogs.
If checked, place multiple migrations on the same volume until end of tape (EOT) is encountered. Always check this box.
5. WORM Tape checkbox: Applies to tape methods, and only appears on those dialogs.
Check this box if you will use WORM tape.
Chapter 4, Configuring VSM 119
Advanced Configuration Wizard
This feature has been tested with StorageTek 9840 write-once-read-many (WORM) tape using Imation 9840 VolSafe cartridges and an AIT drive unit with Sony SDX2-50C Advanced Intelligence tape.
6. Click the Physical tab.
Physical Tab (Tape and Optical Media)
Assign the physical properties for tape or optical disk media.
Physical Tab, Stripe Properties Dialog
.
1. Media Density: Specify the density of the tape or optical disk. Pull down the menu and select the type of storage media for this stripe.
2. Capacity: Capacity of the media. During labeling, VSM records this value on the tape volume.
This field applies only to tape and alternate disk methods.
VSM automatically determines the capacity of an optical disk volume when the volume is labeled. You specify the capacity of the FTP and NetBackup methods when you register volumes.
3. Block Size: Applies only to tape methods.
Block size (in bytes) to use when writing to the device. The allowable block sizes follow: 512, 1KB, 2KB, 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, and 256KB. The value must be a power of 2.
Do not change this parameter after the initial configuration. It is not necessary to configure block size for the optical disk methods because VSM determines the actual physical block size of optical volumes each time they are mounted or opened.
120 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
4. Granule Size: Specifies the size of each granule that VSM writes to the device.
VSM divides files into granules. Each granule must fit on one volume. Granule size is a power of 2 and an integral of the block size; valid values range from 128 KB to 64 MB. You can only select valid values.
5. Click the Timeout tab.
Timeout Tab (Tape and Optical Media)
Specify tape or optical disk timeout properties for tape or optical disk media.
Timeout Tab, Stripe Properties Dialog
.
1. Deadman Timeout: Specify the maximum time in seconds that VSM waits for a volume request to complete. The default is 3600 seconds (one hour). This field is not used for the alternate disk method.
2. Demand Delay: Specify the maximum time in seconds that a mount request waits before VSM unmounts a similar unused volume.
If VSM identifies a mounted but unused volume of the same density whose unmount delay has not yet expired, it unmounts that volume as soon as the demand delay occurs. Otherwise, the mount request remains active until a drive becomes available. This field is not used for the alternate disk method. The defaults are 3 minutes for tape and 20 seconds for optical disk.
3. Unmount Delay: Specify the maximum time that a volume mounted in read mode remains mounted pending another read request (the time is in seconds). If no read request arrives prior to the expiration of this time delay, VSM unmounts the volume. The default value is 3 minutes. A single unmount delay value pertains to all stripes in this configuration using the tape and optical disk methods.
Chapter 4, Configuring VSM 121
Advanced Configuration Wizard
Stripe Properties Dialog for Alternate Disk
Assign the stripe properties for alternate disk media.
Alternate Disk Stripe Properties Dialog
The Method indicates the storage method you selected in the New Stripe dialog. To complete this part of the configuration, you may select the following:
1. Obsolete checkbox: Always check this box. It specifies that the media supports granule obsoleting.
2. Capacity: Specify the capacity of the method as being bytes, kilobytes, megabytes, or gigabytes.
3. Granule Size: Specifies the size of each granule that VSM writes to the device.
Stripe Properties Dialog for FTP
Assign the stripe properties for the FTP method.
122 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
FTP Stripe Properties Dialog
The Method indicates the storage method you selected in the New Stripe dialog.
1. Obsolete checkbox: Always check this box. It specifies that the stripe supports granule obsoleting.
2. FTP Port Number: Specify the port number for FTP. The default value is 21.
3. Deadman Timeout: Specify the maximum time in seconds that VSM waits for an FTP request to complete. The default is one hour (3600 seconds).
Stripe Properties for NetBackup
Assign the stripe properties for the NetBackup method.
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
Chapter 4, Configuring VSM 123
Advanced Configuration Wizard
NetBackup Stripe Properties Dialog
The Method indicates the storage method you selected in the New Stripe dialog.
1. Obsolete checkbox: Always check this box. It specifies that the stripe supports granule obsoleting
2. Granule Size is not selectable because granule size does not affect the NetBackup method.
3. Deadman Timeout: Specify the maximum time in seconds that VSM waits for a request to complete. The default is one hour (3600 seconds).
Advanced Configuration - Volume Registration DialogsUse the Volume Registration dialogs to setup volume registration for the Level. The title of the dialog indicates if you are setting up a Primary or Alternate Level.
The information you are asked to supply in this dialog depends on your selection in the New Stripe dialog.
Volume Properties Dialog for Tape and Optical Media
Set up volume registration for tape and optical disk methods
.Volume registration information varies from one media type to another.
124 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
1. Volume Label: Specify the unique name of the volume to be recorded on the volume and in the VSM volume database (VOLDB). VSM restricts volume names to an alphabetic character followed by up to five alphanumeric characters, and converts all lower case input to upper case.
2. Force Registration: Check this box to force the registration of a previously labeled volume. If this box is not checked, previously labeled volumes are not reregistered.
Caution Forcing registration of a previously labeled volume destroys all information that may be on the volume. The volume cannot currently be registered in any VSM volume database.
3. Delayed Labeling: Check this box to delay labeling of media until needed. If not checked, the media is labeled immediately.
4. Add Volume To: Select either Current Stripe or Volume Set 0. If you select Current Stripe, the volume is added to the current stripe. If you select Volume Set 0, it becomes an extra volume available for use should a stripe not have a free volume it can access (see “Keeping a Supply of Unused Volumes” on page 202 for more information).
Volume Properties Dialog for Alternate Disk
Set up volume registration for the alternate disk storage method.
1. Volume Label: Specify the unique name of the volume to be recorded on the volume and in the VSM volume database (VOLDB). VSM restricts volume names to an alphabetic character followed by up to five alphanumeric characters, and converts all lower case input to upper case.
2. Volume Directory Name: Specify the file system directory required when registering a volume. Ensure the file system is mounted before registering the volume. The directory should be a mount point, because VSM assumes it can store enough files to fill the entire capacity of the file system at the mount point.
3. Force Registration: Check this box to force the registration of a previously labeled volume. If not checked, previously labeled volumes are not reregistered.
Chapter 4, Configuring VSM 125
Advanced Configuration Wizard
Caution Forcing registration of a previously labeled volume destroys all information that may be on the volume.
4. Add Volume To: Select either Current Stripe or Volume Set 0. If you select Current Stripe, the volume is added to the current stripe. If you select Volume Set 0, it becomes an extra volume available for use should a stripe not have a free volume it can access (see “Keeping a Supply of Unused Volumes” on page 202).
Volume Properties Dialog for FTP
Set up FTP volume properties.
Primary Volume Registration Dialog, FTP
.
1. Volume Label: Specify unique name of the volume to be recorded on the volume and in the VSM volume database (VOLDB). VSM restricts volume names to an alphabetic character followed by up to five alphanumeric characters, and converts all lower case input to upper case.
2. Server: Specify the name of the remote server. This can be the fully qualified host name or the IP address of the server. VSM uses this name on the ftp opencommand as the host parameter. It must be a valid FTP host.
126 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
3. Directory: Specify the full path name of the file system directory on the remote server. The user name on the VSM server must have read and write permissions to this remote directory. You can specify any directory on the remote server that is not already registered for VSM.
4. Username, Password, and Reenter Password: Specify the user name and password VSM will use when accessing the remote server from the VSM server through FTP. This name and password must be valid on the remote server and also must have read and write access to the remote managed file system that you are using for migration.
Keystrokes into the password field are echoed as asterisks (*). Because you cannot see the password, it must be entered twice.
5. Force Registration: Check this box to force the registration of a previously labeled volume. If not checked, previously labeled volumes are not reregistered.
Caution Forcing registration of a previously labeled volume destroys all information that may be on the volume.
6. Add Volume To: Select either Current Stripe or Volume Set 0. If you select Current Stripe, the volume is added to the current stripe. If you select Volume Set 0, it becomes an extra volume available for use should a stripe not have a free volume it can access (see “Keeping a Supply of Unused Volumes” on page 202 for more information).
Volume Properties Dialog for NetBackup
Set up NetBackup method volume properties.
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
Chapter 4, Configuring VSM 127
Advanced Configuration Wizard
Primary Volume Registration Dialog - NetBackup
.
1. Volume Label: The unique name of the volume to be recorded in the VSM volume database (VOLDB). VSM restricts volume names to an alphabetic character followed by up to five alphanumeric characters, and converts all lower case input to upper case.
2. Server: The name of the NetBackup master server.
3. Policy: The name of the NetBackup policy VSM will use.
4. Schedule: The name of the schedule defined for the NetBackup policy. The backup window for this schedule must be 24 hours per day, seven days per week.
5. Force Registration checkbox: Check this box to force the registration of a previously labeled volume. If the box is not checked, previously labeled volumes are not reregistered.
Caution Forcing registration of a previously labeled volume destroys all information that may be on the volume. The volume cannot currently be registered in any VSM volume database.
6. Add Volume To: Select either Current Stripe or Volume Set 0. r Volume Set 0. If you select Current Stripe, the volume is added to the current stripe. If you select Volume Set 0, it becomes an extra volume available for use should a stripe not have a free volume it can access (see “Keeping a Supply of Unused Volumes” on page 202 for more information).
128 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
Advanced Configuration - Alternate Level DialogsIf you elected to have dual copies of files (Primary and Alternate Levels), you will see the New Level, New Stripe, Stripe Properties, and Volume Registration dialogs again for the Alternate Level. The following figure shows the first dialog.
New Level Dialog, Alternate Level
.
To complete the dialogs, follow the steps in the procedures beginning with “Advanced Configuration - New Level Dialog” on page 116.
Advanced Configuration - File System Properties DialogAfter you have set up storage levels, set up managed file system properties. Click each of the tabbed pages to reveal the properties it defines.
File System Properties - General Tab
Set up general managed file system properties.
Chapter 4, Configuring VSM 129
Advanced Configuration Wizard
General Tab, Filesystem Properties Dialog
.
1. Slice: Specify the number of bytes at the beginning of the file that VSM leaves stored on disk after a file is purged. These bytes are also migrated, but VSM keeps a copy of them on local disk when it purges the associated file. If the file is accessed, this number of bytes can be read without caching the entire file. The value 0 implies that no bytes will be kept in the managed file system (which is the default).
2. Quota: Specify the maximum number of bytes that users can restrict from migration. The default is just over 9.5 MB (for the entire file system). VSM ignores this quota for file systems configured to manage Oracle archive redo logs.
3. Partial File Caching checkbox: Check this box if you want to allow VSM to have read access to the beginning of a purged file without caching the entire file.
4. Read Ahead: Specify the minimum number of kilobytes beyond the current read request that VSM will partially cache to disk. Setting the value to -1 disables partial file caching (which is the default).
5. Managed Directory: This field is informative. It displays the name already specified for the managed file system.
6. Click the Additional tab.
File System Properties - Additional Tab
Set up accelerated file space availability on the managed file system, which makes file space available sooner by selecting, migrating, and purging files incrementally.
130 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
Note Accelerated file system availability is only used if the file system is over the free space value. A migbatch or miglow command does not use accelerated file system availability.
Additional Tab, Filesystem Properties Dialog
.
1. Files: Specify the maximum number of files that will be processed before users can resume accessing available free space. A value of 0 signifies no limit (which is the default).
2. Minutes: Specify the maximum time increment that will be processed before users can resume accessing available free space. The default is 60. A value of 0 signifies no limit.
3. Kilobytes: Specify the minimum amount of disk space freed with Accelerated File Space Availability enabled before users can resume accessing available free space. The default is 1,048,576 (1 MB). A value of 0 signifies no limit.
4. Hsmname: This field is informative. It displays the name already specified for the managed file system.
5. Logfile path: This field is informative. It displays the log file already specified for the managed file system.
6. Click the Water Marks tab.
Chapter 4, Configuring VSM 131
Advanced Configuration Wizard
File System Properties - Water Marks Tab
Set up the parameters for managing open space on the managed file system.
Water Marks Tab, Filesystem Properties Dialog
.
1. Desired Percentage Migrated checkbox: (also called the low-water mark.) Specify the percentage of free disk space at which VSM stops selecting files for migration. If the checkbox is not checked, the percentage bar is not shown. The default is 100, which is interpreted as none.
2. Desired Percentage Purged checkbox: (also called the purge mark.) Check this box if you want to specify the percentage of free disk space at which VSM stops deleting purge candidates . The percentage bar is not shown if you do not check the box.
The default is 100, which is interpreted as none.
The Desired Percentage Purged must be equal to the Desired Percentage Migrated or between the Desired Percentage Migrated and the Desired Percentage Migrated. If the checkbox is not checked, the slider is not shown.
3. Desired Percentage Free Space checkbox: (also called the free space value or high-water mark.) Check this box if you want to specify the percentage of free disk space at which VSM initiates migration operations. The default value is 10 (percent).
Desired Percentage Free Space must be selected and configured.
4. Click the Migration Criteria tab.
132 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Advanced Configuration Wizard
File System Properties - Migration Criteria and Purge Criteria Tabs
The fields and list boxes on the Migration Criteria and Purge Criteria Tabs are the same, although they apply to setting different thresholds. The default values are different for migration thresholds and purge thresholds.
Use the dialog shown in the following figure to set migration criteria.
Migration Criteria Tab, Filesystem Properties Dialog
.
Use the dialog shown in the following figure to set purge criteria.
Purge Criteria Tab, Filesystem Properties Dialog
.
The following procedure walks through filling in the fields in both tabs.
1. Criteria: Select one of the following:
- Default: Specifies that you want to select files to migrate or purge based on the default weighted algorithm which factors both file size and file age.
- Large Files: Specifies that you want to select larger files to migrate or purge first, regardless of age.
- Old Files: Specifies that you want to select older files to migrate or purge first, regardless of size.
Chapter 4, Configuring VSM 133
Advanced Configuration Wizard
- Weighted Calculation: Specifies that you want to select files to migrate or purge based on a modified weighted algorithm that you can specify which factors both file size and file age. The algorithm follows:
threshold = ((age)(age weight)) [x or +] ((size)(size weight))
The age is in days and the size is in kilobytes.
- Site-defined Script: Specifies that you want to select files to migrate or purge based on the site-defined algorithm different from the one used in the Weighted Calculation. This algorithm is defined in the migsweep.site script, as described in “Customizing Migration, Purging, and Moving Criteria” on page 84.
- Oracle: Specifies that you want to select Oracle archive redo logs for migration or purging. For more information, see “Managing Oracle Archive Redo Logs” on page 151.
2. Minimum Age in Days: Provide a value to specify that VSM will not migrate or purge files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating or being purged the same day they are created or modifed. The default is 7 days for migration and 0 days for purging.
3. Minimum Size in Kilobytes: Provide a value to specify that VSM will not migrate or purge files smaller than this size. The default is 8 KB for migration and 0 for purging.
4. Threshold: Specifies that you want to select files to migrate or purge if the weighted algorithm output is equal to or greater than this threshold. The default is 0 for migration and for purging.
5. Age Weight: Available if you selected Weighted Calculation or Site-defined Script*
6. .Specify the weighting factor for file age used in the algorithm. The default is 1 for migration and for purging.
7. Size Weight: Available if you selected Weighted Calculation or Site-defined Script. Specify the weighting factor for file size used in the algorithm. The default is 1 for migration and 0 for purging.
8. Calculation: Available if you selected Weighted Calculation. Specify either Multiply or Add. This is the arithmetic operator between file size and file age in the weighted algorithm. The default is Multiply for migration and Add for purging.
Advanced Configuration - Committing ChangesIn all the Advanced Configuration Wizard Filesystem Properties dialogs, the Next button is replaced by the Finish button.
134 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Database Configuration Wizard
After you are satisfied with your choices, click Finish.
The wizard commits your changes when you click Finish.
You will not see a Configuration Summary dialog in the Advanced Configuration wizard.
When VSM completes the configuration, you will see the Hierarchy for the managed file system displayed in the Left Pane as a child of the Server.
Database Configuration WizardThe Database Configuration Wizard steps through a series of dialogs to configure VSM management for Oracle archive redo logs. To use the wizard, the Oracle database must be started.
Note The Managing Oracle Redo Logs feature is not available on SGI IRIX platforms.
The wizard will not commit the configuration information until you click on the Finish button in the Configuration Summary dialog.
To launch the Database Configuration Wizard, use the Actions > Configure > Database Configuration Wizard menu selection.
The Enter username and password dialog has the following fields:
You will see a dialog like the one in the following figure.
Login Dialog, Database Configuration Wizard
Chapter 4, Configuring VSM 135
Database Configuration Wizard
1. Database Name: Specify the name of the Oracle database that you want to configure. If VSM-Java finds values in /var/opt/oracle/oratab, it will provide those names in its drop-down list. If you select a name from the drop-down list, VSM-Java fills in the home directory that you configured.
You can also type a value that is not on the drop-down list. You must also provide the home directory.
1. Database User: Provide the user name for Oracle database administration.
2. Database Password: Provide the password for the Oracle database administration user name.
3. Database home directory: If you the select a database name from the drop-down list, this field is filled in by VSM-Java. If you specified a database name not on the drop-down list, specify the home directory for Oracle.
4. Check for Backup before migration using: Specify if you use NetBackup or RMAN to perform your database backups. VSM checks to ensure a backup exists before deleting files. VSM does not perform backups; you must use NetBackup or RMAN to backup your files.
5. If you choose NetBackup, the NetBackup Server field becomes active. Specify the NetBackup server name.
6. If you choose RMAN, you can choose to use RMAN with or without the catalog option.
- RMAN without the catalog option checks for the existence of backup copies. If you make this selection, you provide the UNIX id with DBA privilege to run RMAN in the appropriate field. This user ID runs the script that runs RMAN.
- RMAN with the catalog option checks for the existence of backup copies using the catalog option.
The RMAN Catalog Net Service Name value is used as a target database for RMAN.
The RMAN Catalog Database User Name and RMAN Catalog Database Password values are used to connect to the catalog database and check for a backup copy of the archive redo log files.
The UNIX id with DBA privilege to run RMAN is the user ID for running the script that runs RMAN.
136 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Database Configuration Wizard
Database Configuration - Enter Values DialogDefine the hierarchy’s general properties.
Database Configuration Enter Values Dialog
1. Specify a path name for the directories in which VSM databases reside. Click Default Path to use the default /usr/openv/hsm/database. You must provide a value.
Note If you use the default values for database and log file paths, you must monitor the size of the files to ensure that the /usr directory does not become full.
2. Specify a path name for the directories in which VSM logs reside. Click Default Path to use the default /usr/openv/hsm/logs. You must provide a value. Using the default value is the best choice in nearly all circumstances. The full path cannot be more than 1023 characters.
3. The checkbox for migrating files daily is checked by default. Migrating files daily ensures that if something such as a power failure were to prevent migration one day, migration could still occur the next day without intervention, and your migrated data will be acceptably current. You can select times on the hour.
4. The checkbox for collecting report data daily is checked by default. Collecting VSM reporting data daily ensures that if something such as a power failure were to prevent data collection one day, the collection could still occur the next day without intervention, and your reporting data will be acceptably current. You can select times on the hour.
Chapter 4, Configuring VSM 137
Database Configuration Wizard
Database Configuration - Select Method DialogSelect a storage method.
Select Method Dialog
❖ Select from among the following alternatives:
- Local Devices (Tape/Optical): Use the local tape or optical disk methods. This may be to either rewritable or write once, read many (WORM) media.
- Remote Server (FTP): Use the remote method over File Transfer Protocol (FTP).
- Alternate Disk (AD): The alternate magnetic disk method is used for migrating files to another managed file system mounted on the same VSM server or as a remote method when used with NFS.
- NetBackup (NB): Use the the NetBackup storage method.
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
Database Configuration - Select Properties DialogsUse the Select Properities dialogs to configure the properties of the database you want to manage.
138 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Database Configuration Wizard
The information you are asked to supply in this dialog depends on your selection in the Select Method dialog. This section describes each of the dialogs that are possible as Select Properties dialogs.
Select Local Device Properties Dialog
Select the properties for the storage method.
Select Local Device Properties Dialog
1. Desired Percentage Free Space: Select the percentage of free space below which VSM makes more space available by initiating migration operations. The default value is 10 (percent).
2. Archived redo log destination directory: Specify the full directory path for the intended final destination of all Oracle archived redo logs.
3. Naming Convention: Specify the format you want to use for the archived redo log files. The format T%TS%S_HAY.ARC will use the wildcard convention T*S*_HAY.ARC to determine the names of the files for migration.
4. Migrate files older than (days): Provide a value to specify that VSM will not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
Chapter 4, Configuring VSM 139
Database Configuration Wizard
5. Number of Copies: Select whether you want one or two copies migrated to secondary storage.
Note The default number of copies is two, unless only one tape or optical device with a single drive is attached. In that case, the default is one copy.
Caution Configuring one copy rather than two can result in data loss should the media that holds the copy fail in any fashion.
6. First copy: Select the storage medium for the first (primary) copy.
7. Pool Name: Select the volume pool name for the first (primary) copy.
8. Second Copy: Select the storage medium for the second (alternate) copy (if configured).
9. Pool Name: Select the volume pool name for the second (alternate) copy (if configured).
Select Remote Server Dialog
Select the properties for the FTP storage method.
Select Remote Server Properties Dialog
140 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Database Configuration Wizard
1. Desired Percentage Free Space: Select the percentage of free space below which VSM will make more space available by initiating migration operations. The default value is 10 (percent).
2. Archived redo log destination directory: Specify the full directory path for the intended final destination of all archived redo logs for the Oracle database.
3. Naming Convention: Specify the format you want to use for the archived redo log files. The format T*S*_HAY.ARC will use the wildcard convention T*S*_HAY.ARC to determine the names of the files for migration.
4. Migrate files older than (days): Provide a value to specify that VSM will not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
5. Migrate files every: Select how often you want VSM to initiate file migration.
6. Number of Copies: This field is not selectable. The wizard does not allow you to configure more than one copy for the FTP method.
7. Server Name: Specify the name of the remote server. This can be the fully qualified host name or the IP address of the server. VSM uses this name on the ftp open command as the host parameter. It must be a valid FTP host.
8. Directory: Specify the full path name of the managed file system directory on the remote server. The VSM user name on the VSM server must have read and write permissions to this remote directory. You can specify any directory on the remote server that is not already registered for VSM.
9. User Name: Specify the user name VSM will use when accessing the remote server from the VSM server through FTP. This name must be valid on the remote server and also must have read and write access to the remote managed file system that you are using for migration.
10. Password: Specify the password for the user name you already specified.
Select Alternate Disk Properties Dialog
Select the properties for the alternate disk storage method.
Chapter 4, Configuring VSM 141
Database Configuration Wizard
Select Alternate Disk Properties Dialog
1. Desired Percentage Free Space: Select the percentage of free space below which VSM will make more space available by initiating migration operations. The default value is 10 (percent).
2. Archived redo log destination directory: Specify the full directory path for the intended final destination of all archived redo logs for the Oracle database.
3. Naming Convention: pecify the format you want to use for the archived redo log files. The format T%TS%S_HAY.ARC will use the wildcard convention T*S*_HAY.ARC to determine the names of the files for migration.
4. Migrate files older than (days): Provide a value to specify that VSM will not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
5. Number of Copies: This field is not selectable. The wizard does not allow you to configure more than one copy for the alternate disk method.
6. Volume directory Name: Specify the managed file system mount point required when registering a volume. Make sure the managed file system is mounted before registering the volume. Do not register a disk partition for a directory below the mount point, because the entire capacity of the managed file system at the mount point is assumed.
142 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Database Configuration Wizard
Select NetBackup Properties Dialog
Select properties for the NetBackup storage method.
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in “Drawbacks to Using the NetBackup Storage Method” on page 62. Read this information before you consider configuring the nb method.
Select NetBackup Properties Dialog
1. Desired Percentage Free Space: Select the percentage of free space below which VSM will make more space available by initiating migration operations. The default value is 10 (percent).
2. Archived redo log destination directory: Specify the full directory path for the intended final destination of all archived redo logs for the Oracle database.
3. Naming Convention: pecify the format you want to use for the archived redo log files. The format T%TS%S_HAY.ARC will use the wildcard convention T*S*_HAY.ARC to determine the names of the files for migration.
4. Migrate files older than (days): Provide a value to specify that VSM will not migrate files accessed or modified within this time. Set this to a value greater than 0 to prevent files from migrating the same day they are created. The default is 7 days.
Chapter 4, Configuring VSM 143
Database Configuration Wizard
5. Number of Copies: This field is not selectable. The wizard does not allow you to configure more than one copy for the NetBackup method.
6. Storage Unit: Select the storage unit from the list box. Values in the list box reflect storage units available from the NetBackup configuration.
The selected storage unit will be used to create a new NetBackup policy. The NetBackup policy name is made by concatenating the hsmname with the string nbhsm, as in hsm1nbhsm. This policy will be used to copy migrated data whenever files are migrated from the managed file system. If a policy with the same name already exists in the NetBackup configuration, it will be replaced with the newly created policy without warning.
The newly created policy has its attributes set as follows:
- Policy name: hsmnamenbhsm
- Storage Unit: Select from the list box
- Volume Pool: HSM-NB
- Schedule Type: UBAK (a user-directed backup with the retention level of 9).
Caution It is highly recommended that you do not to change any attributes of the VSM-created policy. Doing so may cause unpredictable consequences for VSM operation.
Database Configuration - Configuration Summary DialogThe last dialog summarizes all configured and default values for the managed file system.
The following figure shows the values for the database file system configured in this chapter.
144 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Editing the Configuration
Database Configuration Summary Dialog
1. Verify your choices.
2. Make any necessary changes by pressing the < Back button until you reach the dialog you wish to change. Update it accordingly and press the Next > button to return to the Summary Dialog.
Note If you click the < Back button to make changed, you must start the configuration again and re-enter your changes for all the dialogs that you went past as you found the dialog that needed the change.
3. After you are satisfied with your choices, click Finish. You have successfully configured VSM to manage your archived redo logs.
Editing the ConfigurationThis section describes how to add to or make changes in VSM configuration.
Adding to Configured Systemsconfigure hierarchies, levels, and stripes that you add to the existing configuration. The configuration is described in “Editing Existing Configurations” on page 147.
Chapter 4, Configuring VSM 145
Editing the Configuration
Adding Hierarchies
You can add a hierarchy as follows:
1. Highlight the Server node in the Left Pane.
2. Select Edit > New Hierarchy or click the New tool.
3. Define the hierarchy, the storage levels, and the stripes for the hierarchy by following the steps in the dialogs, as described in “Advanced Configuration - Hierarchy Properties Dialog” on page 116.
4. After you create the hierarchy, it appears in the Left Pane as a child under the Server and has the form Hierarchy: hsmname.
5. To add a nonmanaged filesystem to the new hierarchy, highlight the Filesystem in the Left Pane.
6. Select Edit> New VSM Management or click the New tool.
7. Choose the hierarchy from the popup menu. When the file system name is assigned, in the Left Pane it is a Managed Filesystem and a child of the Hierarchy node.
You can use the Edit pulldown menu or Change Properties tool to change managed file system properties.
Adding Levels
You can add a level as follows:
1. To add levels to a hierarchy, highlight in the Left Pane the Hierarchy that you want to have multilevel migration.
2. Select Edit > New Level or click the New tool.
3. Select whether you want to add a level associated with the Primary Level or the Alternate Level.
4. If you only configured a Primary Copy, the level will be associated with the Primary Copy.
5. Select the number you want to associate with the level. You can choose only numbers that are not in use.
146 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Editing the Configuration
6. After you have added the level, add stripes to it as described in “Adding Stripes” on page 147.
Adding Stripes
You can add stripes and make more volumes available for VSM use as follows:
1. In the Left Pane, highlight the Level to which you want to add stripes.
2. Select Edit > New Stripe or click the New tool.
3. Define a storage method and a volume pool as described in “Advanced Configuration - New Stripe Dialog” on page 117.
4. Repeat step 1 through 3 for each stripe you want to add.
5. To add volumes to the newly created stripe, go to the Left Pane and select the Stripe you just added.
6. Select Edit > New Volume or click the New tool.
7. Provide volume labels and other information relevant to the storage method this volume will use, as described in “Advanced Configuration - Volume Registration Dialogs” on page 124.
8. Repeat steps 6 and 7 for each volume you want to add.
Editing Existing ConfigurationsUse the Edit pulldown menu to customize an existing configuration.
Editing Hierarchy Properties
The Edit > Change Hierarchy Properties selection lets you edit whether a hierarchy should make dual copies or single copies of migrated files.
All other hierarchy properties are defined at configuration. To change other hierarchy properties, either select Edit > Delete Hierarchy and then reconfigure it, or edit the file system, level, stripe, and volume properties that you want to change.
The steps for editing the number of copies made of migrated files are as follows:
Chapter 4, Configuring VSM 147
Editing the Configuration
1. Highlight a Hierarchy node in the Left Pane
2. Select Edit > Change Hierarchy Properties or click the Change Properties tool, as shown in the following figure.
Edit > Change Hierarchy Properties Selection and Resulting Display
3. Select or deselect the Dual copies checkbox. The database path that is displayed is informational only. the procedures described in “Advanced Configuration - Hierarchy Properties Dialog” on page 116.
Editing File System Properties
You can edit Filesystem properties as follows:
1. Highlight a Managed Filesystem in the Left Pane.
2. Select Edit > Change Filesystem Properties or click the Change Properties tool, as shown in the following figure.
148 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Editing the Configuration
Edit > Change Filesystem Properties Selection and Resulting Display
You edit the file system properties using the procedure described in “Advanced Configuration - File System Properties Dialog” on page 129. You are not actually in the Advanced Configuration wizard when you edit the file system. All configuration steps are done separately if you use the Edit menu to change the configuration.
Editing Level Properties
You can edit Level properties as follows:
1. Highlight a Level in the Left Pane.
2. Select Edit > Change Level Properties or click the Change Properties tool, as shown in the following figure.
Edit > Change Level Properties Selection and Resulting Display
Chapter 4, Configuring VSM 149
Editing the Configuration
The resulting dialog has much in common with the dialogs described in “File System Properties - Migration Criteria and Purge Criteria Tabs” on page 133. However, rather than setting criteria for migrating or purging files, this dialog sets criteria for moving files for multilevel migration. The default values for moving files are also different from those for migrating or purging files. For information on the defaults, see “Criteria for Moving Migrated Files” on page 81
In addition to the selections described in “File System Properties - Migration Criteria and Purge Criteria Tabs” on page 133, this dialog also includes the Flags buttons, as follows:
◆ Dead: Specifies that you want to mark FHDB entries for file copies at the source migration level as dead.
◆ Active: Specifies that you want to mark FHDB entries for file copies at the source migration level as active.
◆ Obsolete: Specifies that you want to mark FHDB entries for file copies at the source migration level as obsolete.
The default is Dead for the tape and optical disk methods. For the alternate disk method, the default is Obsolete. Move flags are not applicable to the FTP and NetBackup methods, because these methods do not support multilevel migration.
Editing Stripe Properties
You can edit Stripe properties as follows:
1. Highlight a Stripe in the Left Pane.
2. Select Edit > Change Stripe Properties or click the Properties too.
Edit > Change Level Properties Selection and Resulting Display
Editing the configuration by selecting Change Stripe Properties is the same procedure as the one described in “Stripe Properties Dialog for Tape and Optical Media” on page 119.
150 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM-Java Tools
5 This chapter describes management tools VSM-Java provides that give you easy-to-use access to commands and utilities.The following tasks and tools are described:
◆ “Managing Oracle Archive Redo Logs” on page 151 (following)
◆ “Reporting Tools” on page 158
◆ “File Manipulation with the File Browser” on page 167
◆ “Scheduling Tool” on page 173
◆ “File System Analyzer” on page 179
Managing Oracle Archive Redo Logs
Note The Manage Oracle Archive Redo Logs feature is not available on SGI IRIX platforms.
Oracle archive redo logs let you recover a database that has experienced instance or media failure. This section explains the VSM tool that allows you to use VSM to manage your Oracle archive redo logs.
The following major topics are discussed:
◆ “Oracle Archive Redo Logs” on page 152.
◆ “Database Configuration Overview” on page 152
◆ “Manage Archive Redo Logs Dialog” on page 153.
151
Managing Oracle Archive Redo Logs
Oracle Archive Redo LogsMost database applications that use Oracle archive redo logs are critical to your business. These files are usually stored on a disk file system that is large enough to hold a fixed number of files, and you set the size of the archive redo logs based on transaction activity, space availability, and desired performance.
When the file system that holds your Oracle archive redo logs runs out of space, it will bring the associated database application to a halt. Rather than using a manual workaround (such as reserving space with a large file that can be removed), you can use VSM to automatically manage your Oracle archive redo log file system. The interface also provides easy search and retrieval when you need to use the logs.
Note To use the VSM Oracle Archive Redo Logs features, you must run NetBackup and the NetBackup Database Agent for Oracle.
Database Configuration OverviewBefore you can use VSM to automatically manage the file system containing your Oracle archive redo logs, you must configure the file system as described in “Database Configuration Wizard” on page 135. You will be asked to provide the following:
◆ Name, user name, password, and home directory of the database that produces the archive redo logs.
◆ Storage medium for the migrated archive redo logs (local disk, tape, optical disk, remote disk, and so on).
◆ How much open space the redo log file system must have.
◆ Destination directory (location after migration) for the archive redo logs you want to manage.
◆ Format for the archive redo log file names that you want to view (naming convention).
◆ Minimum age. This is the number of days since the last file access or modification that you want VSM to wait before it considers the file eligible for migration. If you specify 7, for example, VSM will never migrate files that have been accessed or modified within the last week.
◆ How many copies of each redo log you want VSM to create, store, and manage.
◆ Specific information about the storage medium you have chosen for each copy.
◆ How often to migrate files.
◆ When to create reports about activity on the managed file systems containing the archive redo logs.
152 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Oracle Archive Redo Logs
If you accept the default values offered by the Database Configuration Wizard, the file system that contains your archive redo logs will be managed as follows:
◆ VSM will start premigrating and then purging files from local disk if the file system’s open space drops below 10%.
◆ Files that have not been accessed or modified within 7 days are eligible for migration.
◆ Every eight hours, VSM will scan the file system to determine if it has enough open space and take appropriate action.
◆ Reporting information will be generated daily at midnight.
Note VSM will not cache archive redo logs for database backup. A process is run to determine if the files have been backed, and VSM does not migrate the files unless backup copies have been made.
If you have different Oracle databases that save archived redo logs to the same file system, you do not configure the managed file system twice. Instead, you configure it once for one database, and then use the management tools to set up what files you want migrated.
Manage Archive Redo Logs DialogTo manage Oracle archive redo logs, select Actions > Configure > Manage Archive Redo Logs from the VSM-Java pull down menu. You will see a screen like the one in the following figure.
Chapter 5, VSM-Java Tools 153
Managing Oracle Archive Redo Logs
Components of the Manage Archive Redo Logs Main Dialog
To access the Manage Archive Redo Logs interface, select Actions > Configure > Manage Archive Redo Logs from the VSM-Java Administration menu bar.
The initial dialog is similar to the initial dialog of the Database Configuration wizard. As part of the Manage Archive Redo Logs tool, this dialog lets you update what files you want to manage and how they are backed up, as follows:
◆ The Database name field controls what database you will manage with the tool. If you select a name from the drop-down list, VSM-Java fills in the username, password, home directory, and backup values that you configured.
If you enter a value that is not on the drop-down list, you fill in the username, password, home directory, and backup values that you configured. VSM-Java informs you if the file system you entered is not managed by VSM.
◆ The Check for Backup before migration using field lets you choose between NetBackup and RMAN to perform your database backups.
The values you configured for backups are displayed in the Right Pane.
If you want to change how backups are done, you make changes and select Update Backup Values.
◆ The Query database and show files button brings up the Manage redo log files dialog, which lets you change file management.
154 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Oracle Archive Redo Logs
▼ To access a different database
1. Select the name of the database from the Database name drop-down list, or enter the name of the database.
2. If you select a name from the drop-down list, VSM-Java fills in the username, password, home directory, and backup values that you configured for that database. If you entered the name of the database, you provide those values.
▼ To change backup values to NetBackup
1. Click the NetBackup radio button.
2. Fill in the NetBackup Server field with the server name.
3. Click Update Backup Values.
▼ To change backup values to RMAN without the catalog option
1. Click the RMAN radio button.
2. Provide the UNIX id with DBA privilege to run RMAN in the appropriate field. This user ID runs the script that runs RMAN.
3. Click Update Backup Values.
▼ To change backup values to RMAN with the catalog option
1. Click the RMAN radio button.
2. Click the Use RMAN catalog checkbox.
3. Provide the RMAN Catalog Net Service Name in the appropriate field. This value is used for the catalog database.
4. Provide the RMAN Catalog Database User Name and RMAN Catalog Database Password in the appropriate fields. These values are used to connect to the catalog database and check for a backup copy of the archive redo log files. VSM does not perform backups; it only checks for a backup copy. You must back up files using RMAN or NetBackup.
5. Provide the UNIX id with DBA privilege to run RMAN in the appropriate field. This user ID runs the script that runs RMAN.
6. Click Update Backup Values.
Chapter 5, VSM-Java Tools 155
Managing Oracle Archive Redo Logs
Manage Redo Log Files DialogThis dialog has two main functions:
◆ List files with a specific naming convention
◆ Update which files you want to include for migration, exclude from migration, and delete from the file system.
▼ To query a managed database
1. Verify that the Database name and its associated values correspond to the database you want to query.
2. Click Query database and show files. You will see a screen like the one in the following figure.
Manage redo log files Dialog
VSM-Java fills in the Archive redo log destination directory field based on the database you queried in the Manage Archive Redo Logs dialog immediately preceding this dialog.
156 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Oracle Archive Redo Logs
▼ To list files with a specific naming convention
1. Provide the Naming Convention of the files you want to list in the appropriate field.
2. Click the List files for the naming convention button.
Any files that match your specified naming convention are displayed in the Files selected based on naming convention Pane.
▼ To change which files are migrated
1. After you have searched a managed file system and listed files in the Files selected based on naming convention Pane, either the Include all files for migration or the Exclude all files from migration button is active.
Which button is active depends on whether the files you listed are included for migration.
2. Click on the active button to change whether the files are migrated.
▼ To delete files from the file system
1. After you have searched a managed database and listed files in the Files selected based on naming convention Pane, you can delete them from the file system.
2. Select the file(s) you wish to delete.
3. Click Delete selected files from file system.
4. Click OK when asked for confirmation.
5. VSM-Java checks to see if the files have a backup copy before deleting them. VSM does not perform the backups. You must back up the files using NetBackup or RMAN.
6. Monitor the progress of the deletion job in the Status pane.
Chapter 5, VSM-Java Tools 157
Reporting Tools
Reporting ToolsThis section describes the VSM-Java Reporting tools that allow you to view file system details collected by the migrd migration daemon and to generate reports about performance and past trends.
The time span the reports can detail depends on the type of report you display. You can display hourly reports and user ID reports that span a maximum of one year. You can display all other reports that span a maximum of five years.
You can display reports of the frequency and number of files copied and cached, the space used, and the general use and performance of VSM.
Major topics discussed in this section are as follows:
◆ “Starting the Reporting Tool” on page 158.
◆ “Reporting Tool Main Window” on page 158
◆ “Reporting Tool Pull-Down Menus” on page 159
◆ “Server Reports” on page 161
◆ “Managed File System Reports” on page 162
◆ “Response Reports” on page 163
◆ “Performance Reports” on page 165
Starting the Reporting ToolBefore you can view reports in VSM-Java, you must schedule reports to be run that generate the data used by the reports. For information on scheduling, see “Scheduling Tool” on page 149.
Open the Reporting tool by selecting Actions > Reports from the pull-down menu of the main VSM-Java Administration window.
Reporting Tool Main WindowThe main window of the Reporting tool has three sections, as shown in the following figure.
158 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Reporting Tools
Reporting Tool Window
The Menu bar lets you choose among options to print, close the display, set preferences, and display help.
The Left Pane displays the tree to select report types.
The Right Pane displays the reports for the area you highlighted in the Left Pane.
Reporting Tool Pull-Down MenusThe pull-down menus let you select options for the display.
◆ File > Print prints the report displayed in the Right Pane. On Solaris and HP-UX platforms, ensure your PRINTER environment variable is set to the printer you want to use.
◆ File > Close closes the window and ends your reporting session.
◆ View > Preferences lets you set preferences for the display.
◆ Help displays help on the interface.
Menu Bar
Right Pane
Left Pane
Chapter 5, VSM-Java Tools 159
Reporting Tools
Setting Preferences
1. Select View > Preferences to set preferences for bar charts. Under Chart Labels, select On to have labels appear or Off to have no labels appear.
2. Under Generate Reports, define the window of time that a report will represent by defining a start date and an end date.
Note that before you can view reports in VSM-Java, you must schedule reports to be run that generate the data you display with the Reporting tool. For information on scheduling, see “Scheduling Tool” on page 149.
You can select the dates in Generate Reports and change them by typing the dates you want to use, or you can select the calendar buttons to the right of the dates:
a. Click the Start Date calendar button to invoke the Select Dates dialog. Select the month and year, then select the date you want to begin reporting.
b. Click the End Date calendar button to invoke the Select Dates dialog. Select the month and year, then select the date you want to end reporting.
The default dates span one week, ending on the current date.
160 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Reporting Tools
Server Reports
▼ To display the details of the file systems managed by the server
1. Select Server: servername from the Left Pane
The file system statistics displayed in the Right Pane are as follows:
◆ File system name.
◆ Size of the file system
◆ Space currently in use on the file system.
◆ Space currently available on the file system.
▼ To display details about files and space used for all managed file systems
1. Select Files and Space Details from the Left Pane.
The report displayed in the Right Pane shows migration trends in the managed file system over the dates you specified under Preferences.
The following figure shows trends on the server cranberry for files migrated, purged, and not migrated over a week.
On a color display, the number of purged files is shown in red, migrated files in yellow, and non-migrated files in blue.
You can display the results in a plot format or a bar chart format.
Chapter 5, VSM-Java Tools 161
Reporting Tools
To zoom in on an area of the chart, click the left mouse button. To restore the chart to its original size, type the lowercase letter r.
Managed File System Reports
▼ To display file and space statistics
1. In the Left Pane, select a managed file system name under Files and Space Details.
The report displayed in the Right Pane shows migration trends in the managed file system over the dates you specified under Preferences.
You can display the results in a plot format or a bar chart format. The displays by server or by file system are essentially the same in the data they display, except that the data is gathered for all managed file systems for the server display and only for the managed file system you highlight in the Right Pane for the managed file system display.
File System Trends as Bar Chart
On a color display, the number of purged files is shown in red, migrated files in yellow, and non-migrated files in blue.
162 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Reporting Tools
Response ReportsResponse reports let you view information about requests VSM made to cache or copy data from or to secondary storage.
All of the response reports display the following:
◆ The managed file system where the requests originated
◆ The number of requests
◆ The number of requests that failed
◆ The average time of the requests, in seconds
◆ The maximum time of any request, in seconds
◆ The amount of data moved
The response By Day reports include information about the you will also see the mount time and positioning time for requests to which these are applicable.
▼ To display information about data cached (recalled from) secondary storage
1. Select Response > Cached > By Day to display daily data retrieval information for all file systems by day.
2. Select Response > Cached > By Filesystem to display data retrieval information by file system.
Chapter 5, VSM-Java Tools 163
Reporting Tools
3. Select Response > Cached> By Hour to display data retrieval information for all file systems by hour.
▼ To display information about data copied to secondary storage
1. Select Response > Copied > By Day to display copy request information for all file systems by day.
2. Select Response > Copied > By Filesystem to display copy request information by file system.
164 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Reporting Tools
3. Select Response > Copied > By Hour to display copy request information for all file systems by hour.
Performance ReportsCopied and Cached performance reports let you view the amount of data that VSM has copied and cached between secondary storage and this server.
Performance reporting offers a separate selection to view by user ID, which lets you see how much data individual users moved between secondary storage and local disk.
▼ To display information about VSM performance
1. Select Performance > Copied and Cached > By Day to display copied and cached data for all file systems by day.
Chapter 5, VSM-Java Tools 165
Reporting Tools
2. Select Performance > Copied and Cached > By Hour to display copied and cached data for all file systems by hour.
3. Select Performance > Copied and Cached > By User ID to display copied and cached data for all file systems by user ID.
4. Select Performance > Copied and Cached > By Filesystem to display copied and cached data by file system.
166 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File Manipulation with the File Browser
File Manipulation with the File BrowserThis section explains how to execute VSM file-manipulation commands using the File Browser. The File Browser does not require root access, but only a subset of functionality is available to users without super-user privileges.
The File Browser can run on HP-UX, Solaris and Windows systems.
The following topics in this section explain these user-directed VSM operations in more detail:
◆ “File Browser Login” on page 167
◆ “File Browser Main Window” on page 167
◆ “File Browser Actions” on page 171
◆ “Migration... Menu Selection” on page 172
File Browser LoginTo bring up the login screen for the File Browser, you can select Actions > File Browser from the VSM Administration interface, select Start > VERITAS Storage Migrator > UNIX File Browser on a Windows system, or run the command /usr/openv/java/migfb& on a Solaris or HP-UX system.
▼ To log in to the File Browser after the login screen appears
1. Provide the name of the server on which VSM is installed.
2. Provide the user name and password you will use.
3. Click Login, or press <Enter> within the Password field.
File Browser Main WindowThe main screen layout of the File Browser contains five functional elements, as shown in the figure below.
Chapter 5, VSM-Java Tools 167
File Manipulation with the File Browser
File Browser Main Screen
The main window has the following functional parts:
◆ The Menu bar lets you choose among options to exit (File menu), change and refresh the display (View menu), group files for migration and manage file migration (Actions menu), and display help (Help menu).
◆ The Tool bar lets you choose among options to change servers and refresh the display.
◆ The Left Pane displays the tree to select managed file systems you want to browse.
◆ The Right Pane displays information about the files and directories you are browsing. What appears in this pane depends mainly on what you select in the Left Pane and somewhat on what you select from the Actions menu.
◆ The Bottom Pane (Activity Bar) displays information about the VSM operations you have invoked by selections in the Actions menu. The View menu lets you control what is displayed in this pane.
Find more details on this screen are provided in the following sections:
◆ “File Browser Pull-down Menus and Tool Bar” on page 169 (following)
◆ “File Browser Left Pane” on page 169
◆ “File Browser Right Pane” on page 169
◆ “File Browser Bottom Pane and View Menu” on page 170
Menu bar
Bottom Pane (Activity Table)
Left Pane
Tool bar
Right Pane
168 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File Manipulation with the File Browser
File Browser Pull-down Menus and Tool Bar
The menu bar at the top of the main screen offers four pull-down menus that let you select options for the display and perform actions.
Some of the Pull-down Menu options and Tool Bar icons are standard for graphical interfaces:
◆ File > Exit closes the window and ends your File Browser session.
◆ View > Show Toolbar is a checkbox that toggles the Tool bar display.
◆ View > Refresh refreshes the entire window display. It is equivalent to the Refresh icon.
◆ Help displays help on the interface and provides version information for Storage Migrator.
Other Pull-down menu options and Tool bar icons are more unique:
◆ The File > Change server selection logs you out of the server you are on and prompts you to log in to another VSM server. It is equivalent to the Change Server icon
◆ The View and Actions menus have more functions than the other menus; see the following sections:
- “File Browser Bottom Pane and View Menu” on page 170
- “File Browser Actions” on page 171
File Browser Left Pane
The Left Pane shows the tree directory structure for the managed file system(s) on this server. To expand or contract the information displayed in this pane, click on the + or the - button next to the file systems and directories displayed.
The table “File Browser Icons Used in Left and Right Panes” on page 170 shows the directory icons used on the Left Pane.
File Browser Right Pane
When you highlight a particular item in the Left Pane, the Right Pane displays information about that item. Clicking a column heading in the Right Pane sorts the information in the pane according to that column, toggling from ascending to descending sorts.
If you select a job fin the activity table (the Bottom Pane), the Right Pane displays information about that job.
Chapter 5, VSM-Java Tools 169
File Manipulation with the File Browser
Both the Left Pane and the Right Pane use icons to illustrate the type of file that you are seeing in the display, as shown in the following table:
File Browser Bottom Pane and View Menu
Job activity is displayed in the pane at the bottom of the main screen. Most of the commands invoked from the Actions pull-down menu execute asynchronously, and their progress is summarized in this pane (see “File Browser Actions” on page 171 for more information on these operations).
If you highlight a job in the bottom pane, output for that job is displayed in the Right Pane.
▼ To manage job activity
◆ To clear all completed jobs, select View > Clear Completed Jobs from Activity Table.
◆ To cancel a highlighted job, select View> Cancel Selected Job in Activity Table.
File Browser Icons Used in Left and Right Panes
Icon Icon Description
Directory: a normal directory that has not been grouped.
Grouped Directory: a directory that has been grouped so its files and those in its subdirectories will be premigrated and cached as a group.
Regular File: a file that resides on disk and is neither premigrated nor migrated.
Migrated File: a premigrated file that has been copied to secondary storage (a purge candidate).
Purged File: a migrated file that has been purged from local disk.
170 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File Manipulation with the File Browser
File Browser ActionsUse the Actions pull-down menu to initiate VSM operations that manage your files and directories.
Note You must provide the proper permissions before nonroot users can use the File Browser.
There are two selections from the Actions menu:
◆ Actions > Directory groups
◆ Actions > Migration
Directory Groups Menu Selection
Note: To complete the actions described in this section, you must have selected a managed file system and highlighted a directory in the tree displayed in the Left Pane.
▼ To manage directories you want to keep together through migration and caching
1. To group a directory so that and all files (including subdirectories) are migrated together, select Actions > Directory Groups > Group. The Left Pane changes to display a grouped directory icon
If any of these files are accessed after they have been purged, the entire directory is cached.
If you add new files or move files to this directory, they are not grouped with the other files for migration until you group the entire directory again.
2. To defragment a directory before grouping it, select Actions > Directory Groups > Defragment and Group.
Any migrated files in the directory are cached and their database entries are marked obsolete.
Chapter 5, VSM-Java Tools 171
File Manipulation with the File Browser
After the cache of purged files completes, the files and subdirectories are premigrated as a group.
Performing this action does not guarantee that all grouped files will migrate together. Other migration activity may cause other files to be intermingled on the same media.
3. To ungroup a previously grouped directory, select Actions > Directory Groups > Ungroup. Subsequently any accessed files are cached individually.
4. To list information about a grouped or ungrouped directory, select Actions > Directory Groups > List Information.
5. To display output in the Right Pane, click on the job in the Bottom Pane. The files in the directory are not grouped and have not been migrated to secondary storage.
6. To list more detailed information about a grouped directory, including the volume(s) on which the migrated data resides, select Actions > Directory Groups > Verbose Information.
7. If you configured VSM to create multiple file copies, the File Browser displays information about the copy that can be most quickly cachedTo copy all files in a directory group to secondary storage, but not purge them from the local disk, a root user can select Actions > Directory Groups > Copy.
8. To copy all files in the directory group to secondary storage and purge them from local disk, a root user can select Actions > Directory Groups > Copy and Purge.
Migration... Menu Selection
In the tree pane on the left, highlight the Directory node in the managed file system. Files in that directory are displayed in the right pane.
172 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Scheduling Tool
File Browser Actions > Migration Selection
▼ To migrate, purge, stage, or locate files in managed file systems
1. To migrate highlighted files, select Actions > Migration > Migrate. VSM copies premigrated files to secondary storage during its next migration operation.
No files listed in the global stop file or a local stop file will be premigrated unless the stop file is overridden.
2. To purge highlighted files that are copied to secondary storage, select Actions > Migration > Purge.
This action makes disk space available without waiting for normal purging operations to occur. If the slice value is nonzero, VSM will leave that much data from the file on disk.
3. To stage (precache) highlighted files that have been purged, select Actions > Migration > Stage. Staging purged files in anticipation of accessing them in the near future avoids caching delays at the time of access.
4. To locate highlighted files, select Actions > Migration > Locate. This operation is informational only. It does not change the location or migration status of the file.
Scheduling ToolYou can use the VSM-Java Scheduling tool to add, revise, or delete a scheduled VSM management task for a managed file system.
Chapter 5, VSM-Java Tools 173
Scheduling Tool
The following topics explain scheduling VSM tasks:
◆ “Scheduling Tool Main Window” on page 174
◆ “Component Configuration Dialog” on page 175
◆ “Configuring Schedule Settings” on page 176
◆ “Viewing a Schedule Summary” on page 178
Scheduling Tool Main Window
▼ To access the scheduling tool
❖ Select Actions > Schedule on the VSM-Java Administrator interface.
Note The screen differs, depending on whether you have set up any tasks.
If you have not set up any tasks, you will see a screen such as the one on the left in the following figure, in which not all of the buttons are active.
If you have set up task schedules and select one, you will see a screen such as the one on the right in the following figure, in which Schedule ID and Schedule Names are visible, and the buttons to update or delete the schedule and to view its properties are active.
Schedule Jobs Dialogs
174 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Scheduling Tool
Component Configuration DialogThe specific time a task can be scheduled to run is defined in two ways:
◆ The time window determines when tasks can start (tasks can restart within the time window). The Scheduling tool refers to the options that specify events in the time window as General Options.
◆ The run days are specific dates, a recurring pattern of days, or both. The Scheduling tool refers to these options as Run Day Options.
◆ If you select a command to run from the window in the lower left of the Schedule dialog and select New Schedule, a new Schedule Component Configuration Dialog appears.
The instructions on the screen explain the General Options. If you select Effective Date, Time Window, or Restart Time Interval from the pane on the left, you will see more detailed descriptions of each option and be able to specify when and how often you want the command to run.
The Schedule Component Configuration dialog contains the following functional elements:
◆ The Options tree list in Left Pane contains the various options you can select to schedule a task.
You can expand and collapse the Options tree list, view the available options, and enter or change the settings for an option. The following steps describe how to manipulate the tree and choose options:
- A plus sign [+] indicates that an option contains sub-options. Click [+] to expand the section and display all suboptions.
- A minus sign [-] indicates that an option’s suboptions are displayed. Click [-] to collapse the section and hide suboptions.
- Highlight an option name to display the associated option in the Configuration pane.
Chapter 5, VSM-Java Tools 175
Scheduling Tool
- An icon next to an option indicates there are no additional sub-options. Select the icon to display the option in the Configuration pane. Each option has its own icon.
◆ The Configuration pane on the right changes when you click on an options in the Options tree list. When you have selected an option on the left, this pane lets you configure settings for that option.
◆ The button bar at the bottom of the dialog enables you to accept settings and close the dialog box, cancel settings, or get help about the pane currently displayed. The Summary button displays a summary of your current task settings.
◆ The buttons on the bottom of the screen have the following effects:
- Select Summary to see the characteristics of the task you are setting up as it is defined when you select the button.
- Select OK to save the task you have set up as it is defined and return to the main Schedule Jobs dialog
- Select Cancel to end this configuration session and return to the main Schedule Jobs dialog.
- Select Help to bring up the Scheduling tool help display.
◆ The icons next to the tasks have the following meanings:
- The grayed-out task icon indicates that no Effective Date has been configured for the task.
- The standard task icon indicates that an Effective date has been configured for the task.
- The arrow icon indicates that the Effective Date pane is currently displayed and can be configured.
Configuring Schedule SettingsBy default, a task is scheduled to run for an indefinite time period once each day at any time of the day. You can, however, set up a schedule that defines what time and on which days the task can run.
176 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Scheduling Tool
▼ To view or edit schedule settings
1. Expand the options tree if necessary to display the schedule options.
2. Highlight the option you want to view or edit.
The associated configuration pane is displayed.
3. Make the changes you want in the pane.
4. Click OK when you have completed the entire schedule.
The Schedule Component dialog box accepts the changes you made and closes.
Tip After making changes, you can view a summary of the modified schedule by selecting the Summary button.
Restarting a Task within Its Time Window
You can set up a task to restart at regular intervals within the specified time window. This scheduling allows a task to run multiple times on each scheduled day based on an interval that you specify in hours, minutes, and seconds.
The interval you specify is measured with respect to the first value of your defined time window. For example, if you set up a task to run between 2:00 AM and 9:00 AM and repeat every three hours, the run schedule is 2:00 AM, 5:00 AM, and 8:00 AM.
If you schedule a task to start today, the task can run at the next scheduled interval if it fits within the time window.
▼ To restart a task during the scheduled time window
1. Click the Restart Time Interval option in the Left Pane.
The Restart Time Interval Within the Run Day pane is displayed on the right.
Chapter 5, VSM-Java Tools 177
Scheduling Tool
◆ Click the Restart task every checkbox.
2. In the listbox to the right of the checkbox, select or type the restart interval. You can either click on the arrows at the right of the time display or select and replace hours, minutes, or seconds.
The maximum values you can choose are 23 hours, 59 minutes, and 59 seconds.
Time Windows that Extend Past Midnight
When setting up the time during which a task runs, you can enter a time window that extends past midnight and into the next day. You do this by providing an end time that occurs the next morning.
Bear in mind, however, that this type of time window changes the days on which the task can run.
For example, if you schedule a task to run between 8:00 PM Friday night and 4:00 AM on Saturday, the task might run on Friday and Saturday anytime before or at 4:00 AM. If you do not want the task to run on Saturday, you must alter the time window and change the ending value from 04:00:00 AM to 11:59:59 PM to confine the task to one day.
Viewing a Schedule SummaryYou can view current schedule settings for your task. This is especially helpful when you have made changes to your schedule and want to verify that the new schedule is correct.
178 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File System Analyzer
▼ To view a schedule summary
❖ Click the Summary button beneath the schedule options tree. The Summary dialog box is displayed.
This is a read-only dialog box that cannot be edited.
The Summary dialog displays the run days and time window defined for a task during the current summary period. If you scheduled a task to repeat during the day, the restart interval is shown as well. Run days are highlighted; in the example, the task runs on the eleventh, twenty-first, and last day of each month.
After viewing the current summary, you can advance the calendars.
▼ To advance a calendar
1. Select the month button (labeled the starting month for the current six-month summary).
A drop-down listbox displays starting months of the two six-month summaries for this task.
2. Select the starting month for the next six-month summary.
The calendar displays the next six months of the current year.
File System AnalyzerThe File System Analyzer (FSA) helps you visualize how much space in a file system is being used, which should help you determine if VSM could help you manage its size and growth.
Chapter 5, VSM-Java Tools 179
File System Analyzer
The File System Analyzer gathers statistical information about the size and age of files in file systems and presents this information in graphical form. The File System Analyzer is a read-only application; it will not alter your file system in any way.
You must run the File System Analyzer with superuser privileges. On large file systems, gathering statistics can be time consuming and should be scheduled accordingly. After the File System Analyzer retrieves the necessary statistics, you can view analysis of how various “what if” scenarios can improve your system. You can repeatedly use this analyzer to analyze any number of file systems.
To use the File System Analyzer, you can select Actions > File Browser from the VSM Administration interface or select Start > VERITAS Storage Migrator > File System Analyzer on a Windows system.
File System Analyzer Main WindowThe File System Analyzer main screen layout contains four functional elements, as shown in the following figure.
File System Analyzer Main Screen
The functional elements are described as follows:
◆ The Menu bar lets you choose among options to change servers, print, close the display, view the toolbar, refresh the display, analyze file systems, delete scans, and display help.
Menu bar
Selection Pane
Tool bar
Graph Display Pane
180 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File System Analyzer
◆ The Tool bar lets you choose among options to change servers, analyze file systems, delete scans, print the display, and refresh the display.
◆ The Selection Pane displays the tree to select managed file systems you want to analyze.
◆ The Graph Display Pane shows you information about the file systems you choose to analyze. What appears in this pane is dependent on what you select in the Selection Pane.
More details on this screen are provided in the following sections:
◆ “File System Analyzer Pull-down Menus and Tool Bar” on page 181
◆ “Using the File System Analyzer” on page 182
File System Analyzer Pull-down Menus and Tool BarThe menu bar at the top of the main screen offers four pull-down menus that let you select options for displaying information.
Some of the Pull-down Menu options and Tool Bar icons are standard for graphical interfaces:
◆ File > Exit closes the window and ends your File Browser session.
◆ File > Print prints the Graph Display Pane. It is equivalent to the Print button. On Solaris and HP-UX platforms, ensure your PRINTER environment variable is set to the printer you want to use.
◆ View > Show Toolbar is a checkbox that toggles the Tool bar display.
◆ View > Refresh refreshes the display. It is equivalent to the Refresh button.
◆ Help displays help on the interface and provides version information about FSA. It is equivalent to the Help Topics button
The other Pull-down Menu options and Tool Bar icons are more unique:
◆ File > Change FSA Server prompts you to confirm your choice to change servers. It then logs you out of the server you are on and prompts you to log in to another VSM server. It is equivalent to the Change Server button.
◆ Edit > Delete deletes the scan(s) you have selected in the Selection Pane. It is equivalent to the Delete button.
◆ Actions > Analyze performs the scan of the file system(s) you have selected in the Selection Pane. It is equivalent to the Analyze button.
Chapter 5, VSM-Java Tools 181
File System Analyzer
Using the File System Analyzer
▼ To perform a scan of a file system
1. Select Actions > File System Analyzer from the VSM-Java Administration interface.
2. If you want to scan a file system on another server, do the following:
a. Choose Change FSA Server from the File menu.
b. Confirm your choice.
c. Log in to the server you want to work on.
3. The main window opens.
4. Select Actions > Analyze or click the Analyze button
5. A dialog appears that contains all the file systems on the server. Select the file system(s) you want to analyze. To select more than one, press the <Ctrl> or <SPACE> and click on multiple file systems. Click Analyze
6. The Selection Pane expands to include a scan for this date. A bar graph displays in the Graph Display Pane.
Tip Hold your cursor over any bar in any graph to see the actual number of files or actual size.
▼ To display the relationship of a specific criterion with the data on your file system
1. Select a graph from today’s scan of your file system
2. Select Number by access time to display the number of files in comparison to the time since they were last accessed.
The following figure shows, for example, that the file system has about 2000 files that were last accessed one month ago. All of these files have been migrated.
182 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File System Analyzer
Number by access time Graph
3. Select Number by modification time to display the number of files in comparison to the time since they were last modified.
The following figure shows that the modification time and access time of the files on the hsm2 managed file system follow the same trend, even if the numbers are different.
Holding the mouse cursor over the bars in these graphs reveals that 45 files were accessed between 1 and 2 weeks ago, and 41 files were modified.
Number by modification time Graph
Chapter 5, VSM-Java Tools 183
File System Analyzer
4. Select Number by size to display the number of files in comparison to their size.
The following figure shows, for example, that the file system has over 2000 files that are 16 KB and one file over 512 MB.
Number by size Graph
5. Select Size by access time to display the total size of data in all files in comparison to the time that data was last accessed.
In the following figure, for example, approximately 2 GB of data were last accessed 1 month ago; all of that data is migrated.
184 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File System Analyzer
Size by access time Graph
6. Select Size by modification time to display the total size of data in all files in comparison to the time that data was last modified.
Much of the information in this graph is similar to the Size by access time graph; however, in the example graphs in this section you can see that approximately 1 MB of data was accessed but not modified 2 weeks ago.
Chapter 5, VSM-Java Tools 185
File System Analyzer
Size by modification time Graph
7. Select Size by size to display the total size of data in all files of the specified size.
In the following figure, for example, you can see that slightly under 7 MB of data is contained in migrated files that are between 128 and 512 KB.
Size by size Graph
186 VERITAS Storage Migrator System Administrator’s Guide for UNIX
File System Analyzer
Experimenting with Scenarios
You can experiment with the data you have collected about your file system by selecting What If from the Selection Pane. The Graph Display Pane will look like the one in the following figure:
What If File System Analyzer Graph
▼ To experiment with migration policies using the What if display
1. To experiment with a minimum size for migrated files, select a different value from the Migrate files greater than menu.
2. To experiment with dates of last access, select a different value from the Migrate files not accessed in menu.
3. To experiment with dates of last modification, select a different value from the Migrate files not modified in menu.
The graph changes as you make selections.
Chapter 5, VSM-Java Tools 187
File System Analyzer
Deleting Previous Scans
Because you can use the File System Analyzer over and over again, you may want to delete the results of previous scans.
▼ To delete old file system scans
1. Expand the file systems in the Selection Pane until you see the date of an obsolete or unwanted scan.
2. Highlight the date of the scan you want to delete.
3. Select Actions > Delete or click the Delete button. Confirm your choice. The scan disappears from the Selection Pane.
188 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing VSM
6 VSM provides various tools, commands, and processes for administration and management.Topics in this chapter include the following:
◆ “Backing up VSM Databases and Managed File Systems” on page 190
◆ “Starting VSM” on page 192
◆ “Customizing Startup” on page 194
◆ “Shutting down VSM” on page 196
◆ “Starting and Stopping VSM Daemons” on page 197
◆ “Powering down Remote Volume Servers” on page 198
◆ “Setting up Utilities” on page 198
◆ “Scheduling Management Tasks” on page 201
◆ “Managing Volumes” on page 201
◆ “Invoking Migration Commands” on page 222
◆ “Performance Tuning with Tape Marks” on page 229
◆ “Moving Migrated Files (Export and Import)” on page 230
◆ “Managing VSM Databases” on page 232
◆ “Solving Problems” on page 244
More details about all commands mentioned in this chapter are available on their respective man pages. The VSM(1M) man page groups all VMS commands by function.
189
Backing up VSM Databases and Managed File Systems
Backing up VSM Databases and Managed File SystemsThe first step in managing VSM is to set up a regular schedule for backup. Migrating files does not substitute for regular backups.
Only VERITAS NetBackup can backup all files and directory structures for a VSM managed file system.
Caution If you migrate files with the NetBackup (nb) method, do not back up managed file systems to a NetBackup policy used by VSM.
Note The NetBackup (nb) method will not be supported in the next release of VSM.
Caution Do not use the FlashBackup feature of NetBackup (if supported on the client/server) to back up managed file systems.
Backing up VSM DatabasesAlways perform database backups on the same schedule as managed file system backups. Otherwise, the databases will not match the contents of the file systems after a restore.
For example, assume that you back up the file system (but not the databases) on Monday, and then migrate files on Monday night. If a disk crash occurs on Tuesday, recovering the last backup results in restoring the file system to the state it was in on Monday. Unfortunately, the databases now are not synchronized with the file system because they show the results of migrations from Monday night.
The managed file system and the databases being out of sync can result in problems during subsequent migrations and caches.
Restoring a VOLDB that is not synchronized with its managed file system can cause the following problems:
◆ Loss of any volumes that were registered after the backup.
◆ If, for example, you back up a managed file system at 1:00, make changes to it (such as migrating or purging files) by 2:00, and a system crash happens at 3:00, the VOLDB will be out of sync. Restoring the file system from the backup created at 1:00 and writing the restored data to a tape or optical volume will result in the restored VOLDB not being able to migrate to that volume.
◆ If an ft volume is written after the backup, the restored VOLDB will not have the correct available space for the volume.
190 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Backing up VSM Databases and Managed File Systems
Caution If your FNDB and FHDB do not match each other, you will encounter problems with VSM operations.
When you back up the database directory for a managed file system you must exclude the hsmname.IHAND (Inode-to-Handle) file.
If you do back up the IHAND file, never restore it. Restoring a VSM file system that you previously backed up automatically creates the correct IHAND file for the file system. For details, see “Administering Inode-to-Handle (IHAND) Files” on page 198.
Note After restoring a managed file system and its FHDB/FNDB, you should run migdbcheck to verify that the file system and the databases are in sync.
General VSM Backup Procedure Use the following procedure to back up VSM databases and managed file systems:
1. Make sure the migd migration daemon is running and the VSM state is Active or Maintenance.
2. Backup the managed file system (to tape or optical disk).
Caution Restoring part of a managed file system can cause problems because there is no way of partially restoring the corresponding FHDB.
NetBackup restore sets all slice values to 0, which forces VSM to cache files the next time they are accessed, in order to reestablish the slice data.
If a file is a purge candidate (its data resides on secondary storage), NetBackup backs up only the inode with the VSM file handle, not the data itself. Restoring such a file restores only the inode and VSM file handle, and VSM must then cache the data back to disk before you can access it. See the problem solving section “Restoring Managed File Systems” on page 255 for more information.
When purged files are removed from the managed file system (usually by the user running rm), VSM marks the files as obsolete in the FHDB.
You can run either migrc or migmdclean to remove obsolete entries from the FHDB that are older than the specified age variable (the default is 7 days).
Caution Be sure to set the age variable for the migrc and migmdclean commands at a value higher than the longest NetBackup backup retention period on the managed file system.
You cannot use NetBackup to restore files unless they have a valid FHDB entry.
Chapter 6, Managing VSM 191
Starting VSM
The following migrc command removes obsolete entries in the FHDB that are older than 10 days, assuming that the longest NetBackup backup retention is 7 days:
# /usr/openv/hsm/bin/migrc -O FHDB -a 10
You can use the following migdbclean command, with the same effect:
# /usr/openv/hsm/bin/migdbclean -a 10
You can also edit the commands, although this method is not recommended.
To change the default age of 7 days for the migrc command, edit /usr/openv/hsm/bin/migrc and change the 7 in AGE=7 to a value higher than the longest NetBackup backup retention period.
To change the default age of 7 days for the migmdclean command, edit /usr/openv/hsm/bin/migmdclean and change the 7 in FLAGS="$FLAGS -a -7" to a value higher than the longest NetBackup backup retention period.
Starting VSMThe next VSM management task is to familiarize yourself with its startup scripts and to modify yours if necessary.
The startup scripts are copied into place as part of the installation procedure. They reside in /etc/init.d/hsm, and have unique names according to platforms. You can find copies of these scripts in /usr/openv/hsm/bin/goodies:
The startup script does the following:
1. Starts the migd, migvold, and migrd daemons.
2. On Solaris systems, it verifies the migattr driver is present
3. On IRIX systems, a symbolic link is created from /tmp/hsm.log to /usr/openv/hsm/logs/global.log
Startup/Shutdown Scripts
Name Supported Platforms
S78hsmveritas Solaris VxFS/DMAPI implementation
hpuxrc.sh HP 11.0 and HP 10.20
irixrc.sh SGI IRIX 6.5.x
192 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Starting VSM
4. If necessary, runs fsck on managed file systems, and mounts the file systems.
5. Runs migVSMstartup.
By default the startup script calls migVSMstartup without options, which provides the fastest startup script execution time. You can edit the script to use options if you prefer, as described in “Customizing Startup” on page 194.
During startup, the action migVSMstartup takes depends on the current state of each file system:
◆ If a managed file system is in Inactive or Maintenance state, the migVSMstartup leaves the state unchanged.
◆ If a managed file system is in Idle state, migVSMstartup changes it to Active or Inactive, depending on the value in the global configuration file for that managed file system. Idle indicates that the file system was cleanly shut down.
◆ If a managed file system was in Idling or Active state, it was not cleanly shut down. In this case, migVSMstartup checks for missing trailer labels, locks, and sufficient free space.
If migVSMstartup finds no problems, it changes the state to Active and logs the following message in /tmp/hsm.log:
INFO: HSMNAME hsmname appears intact; state set to ACTIVE
However, if migVSMstartup does find problems, it changes the state to Maintenance and logs the following message in /tmp/hsm.log:
ERROR: HSMNAME hsmname has problems; left in state MAINTENANCE
If VSM is left in Maintenance state, read “Starting and Stopping VSM Daemons” on page 197 to determine what action you should take.
▼ After the startup script completes
1. Start VSM-Java:
- On a Windows system, select Start > Programs> VERITAS Storage Migrator > UNIX Administration. If you use SGI IRIX on your VSM server, you run VSM-Java on Windows, Solaris, or HP-UX.
- On Solaris or HP-UX, run the following command (you can also use Windows to run VSM-Java if you prefer):
# usr/openv/java/migsa &
2. If you have not already done so, configure VSM as described in “Configuring VSM” on page 103.
Chapter 6, Managing VSM 193
Customizing Startup
3. The hsmname of all managed file systems is shown in the Left Pane of theVSM-Java administration dialog.
Note Usually, the hsmname is the same as the file system mount point.
An hsmname has a maximum length of 32 characters. In VSM-Java, the name is limited to a maximum of 14 characters. Names longer than 32 characters may overwrite other data, with unpredictable results.
The state of the managed file systems is shown in the second column of the VSM-Java Left Pane. You can also obtain the state of managed file systems by running /usr/openv/hsm/bin/migVSMstate.
If any managed file systems are in Maintenance state do not resume normal operations. Read “Customizing Startup.”
4. Start copy operations on active file systems. migcopy makes the required copies of migrated files and migrates files from one level to another.
To start copy operations, do one of the following:
- In VSM-Java, highlight the managed file system and select Actions > Filesystem > Restart Migrations and Moves for Filesystem.
- Run /usr/openv/hsm/bin/migrc -RM hsmname
Customizing StartupYou can edit the startup script (as found in “Startup/Shutdown Scripts” on page 192) to call migVSMstartup with any or all of the options -D, -T, or -N. These options cause migVSMstartup to initiate corrective actions if necessary, as follows:
-D Run migdbcheck if there appear to be database problems.
-N Run mignospace if the file system open space is less than the configured threshold.
-T Run migadd_trailer.sh on volumes that have missing trailers.
Using the options lengthens the time needed to complete the startup script.
To modify the script, use an editor to open the startup script and search for $MIGVSMSTARTUP. Add the options you want to run at the end of the line that contains that string.
After you have started VSM, determine if any managed file systems are in Maintenance state by checking the global log file or by running the command usr/openv/hsm/bin/migVSMstate.
194 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Customizing Startup
A managed file system does have startup problems when you see the following error message in your global log file:
ERROR: HSMNAME hsmname has problems; left in state MAINTENANCE
Caution Contact Technical Support if you see database and/or file system errors in the log file. Data loss is very possible if you try to correct such problems without experienced support.
Do not run migdbcheck -r to repair FHDB entries unless you are certain you know how the command affects databases.
If VSM is in Maintenance state after startup, do not resume normal VSM operations on that file system. Try the following, but use caution:
1. When a managed file system is left in Maintenance state, check for consistency of the databases and the file system. In VSM-Java, highlight the managed file system and select Actions > Filesystem > Check DB Consistency for Filesystem.
The command-line equivalent is /usr/openv/hsm/bin/migdbcheck.
Checking database consistency can be a time-consuming operation. If you want the database consistency check to happen automatically when a managed file system is left in the Maintenance state, edit the startup script and change it so that migVSMstartup is called with the -D option.
If migdbcheck reports problems, see the migdbcheck man page for procedures you can use.
The following commands provide tools for database problem correction:
- migalter to change DMAPI attributes.
- ihprint to modify the hsmname.IHAND file entry.
Caution Changing the IHAND file incorrectly with the ihprint command or any other way can hang the VSM or produce inconsistent results.
- migsetdb to modify FHDB or VOLDB entries
- migmdclean to clean up databases
- migfind to determine the full path of a file
Other problems with the file system may be missed during the migdbcheck of database consistency. These errors may be detected when VSM sweeps the file system searching for migration or purge candidates.
2. To check that the file system has enough free space to satisfy the configured threshold, run /usr/openv/hsm/bin/miglow hsmname.
Chapter 6, Managing VSM 195
Shutting down VSM
The miglow command reports the percentage of space used in the file system and the percentage of open space you configured. If more space is used than you configured, mignospace processing begins for the file system.
To ensure free space is available before the file system becomes Active, edit the startup script and change it so that migVSMstartup is called with the -N option.
3. If VSM was interrupted, the ct, dt, and mt methods require trailer labels to added to any tapes that were being written. This can be done at any time before you run out of tapes in the pool for the method.
a. To identify volumes that need trailer labels, use the migdbrpt command, as in the following example for the managed file system tao:
# /usr/openv/hsm/bin/migdbrpt -a tao
00001001 <=>T SM0001 HSM dt.1 37580963840 58153 0 1620310203 4.46%
The T indicates that a trailer label is needed on volume SM0001.
b. To add a trailer, use the migadd_trailer.sh script found in /usr/openv/hsm/bin/goodies, as in the following example for the managed file system tao and volume pool HSM:
# /usr/openv/hsm/bin/goodies/migadd_trailer.sh -P HSM tao SM0001
c. To set the write flag on a volume after you have added the trailer label, use the the migsetdb command, as in the following example for the managed file system tao:
# /usr/openv/hsm/bin/migsetdb -V -w tao SM0001
4. After you have completed manual recovery and maintenance activities on a managed file system, you must make it Active. Using VSM-Java, highlight the managed file system in the Left Pane of the Administration dialog and select Actions > Filesystem > Set State > Active
The command-line equivalent is migVSMstate -s active hsmname
Shutting down VSMVSM operations should be stopped on a managed file system before it is unmounted.
Stopping VSM operations and unmounting the file system are independent operations. For example, it is possible to unmount a managed file system while its VSM state is Active, which causes problems when restarting operations later. Always change the state of a managed file system to Maintenance, Idle, or Inactive before unmounting it.
196 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Starting and Stopping VSM Daemons
With no options specified, migVSMshutdown does the following:
◆ Stops VSM activity on all managed file systems
◆ Stops the migd, migrd, and migvold daemons
◆ Stops VSM-Java processes running on the VSM server
Specifying a managed file system (hsmname) on the migVSMshutdown command line stops VSM activity only on that managed file system.
migVSMshutdown tries to cleanly terminate any ongoing VSM operations and make the file system Idle.
The appropriate startup/shutdown script for your operating system resides in the directory /usr/openv/hsm/bin/goodies.
If a managed file system cannot be placed in the Idle state due to errors (which are reported in the global log file), the shutdown script leaves it in Maintenance state.
If the startup script cannot terminate because some VSM processes will not terminate, it may be necessary to run the HSMKiller command. In that case, the startup script leaves the system in Idling state, and you must perform recovery operations when you restart VSM.
Most VSM operations are not allowed on a managed file system in the Idle state. For instance, VSM cannot cache or remove files on an Idle file system.
After a managed file system is in the Idle, Maintenance, or Inactive state, it may be safely unmounted.
On any UNIX file system, the umount command fails if there are open files. Use the UNIX fuser -cu filesystem command to identify processes that are currently using a managed file system. See the fuser(1M) man page on your system for more information.
A managed file system cannot be unmounted if it is currently shared or exported for use with NFS. Always unshare or unexport a managed file system before stopping VSM operations on the file system and unmounting the file system. On VxFS file systems, an active DMAPI token may keep a managed file system from unmounting. You can use migcleanup to respond to any remaining DMAPI tokens.
Starting and Stopping VSM DaemonsVSM installs three daemons in /usr/openv/hsm/bin/admincmd:
◆ The migrd request daemon must be running before you can use VSM-Java. migrd must also be running for certain migVSMstate changes to take effect, as described in the migVSMstate(1M) man page.
Chapter 6, Managing VSM 197
Powering down Remote Volume Servers
◆ The migd migration daemon must be running for many VSM functions to work, including file caching.
◆ The migvold volume daemon must be running to manage media that is mounted for reading.
The following commands stop or start the VSM daemons:
◆ The startmigd command starts VSM daemons. The -m, -r, and -v options start migd, migrd, and migvold, respectively, as described in the startmigd(1M) man page.
◆ The stopmigd command stops the migd and the migvold daemons. The -m and -v options start migd and migvold, respectively, as described in the stopmigd(1M) man page.
◆ The stopmigrd command stops the migrd daemon.
If migrd is running, you can use VSM-Java to start and stop the migd and migvold daemons:
1. Verify that VSM-Java is logged in to the server that has the daemons you want to start or stop, and highlight the server in the Left Pane.
2. To start daemons, select Actions > Server > Start Daemons.
3. To stop VSM daemons, select Actions > Server > Stop Daemons.
Powering down Remote Volume Servers Before powering down a remote volume server, notify the administrators of all the VSM servers that use the remote volume server. This communication allows the administrators of the VSM servers to stop the migration daemon, preventing any further migrations or caches until the remote volume server is available again.
Setting up UtilitiesThe following sections describe VSM management utilities.
Administering Inode-to-Handle (IHAND) FilesVSM keeps the state of migrated files in a file called the IHAND (Inode-to-Handle) file. The IHAND file is created by migd. It is a sparse file that grows as files are migrated.
198 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Setting up Utilities
The full path of the IHAND file for each managed file system (hsmname) is dwpath/database/hsmname.IHAND.
The file is indexed by inode number. Entries show the migration state of each file VSM migrates from the file system. They contain the following information:
◆ machid
Machine ID
◆ handle
File handle assigned
◆ flags
State flags (in hexadecimal)
01 reloading (not migstage)02 removing04 partial cache 08 cached, unmodified 10 reloading by migstage
◆ slice
Size of the file slice (in bytes) at the time of migration. If you use partial file caching, the configured slice size may have been replaced by the effective slice size, as described in.“File Slices” on page 15.
◆ DM_handle
DMAPI handle
◆ DM_length
Total size of the DMAPI handle (in bytes)
◆ highest_read
For partial file caching only, this value is the read event offset plus length (in bytes)
The size of each IHAND entry is 64 bytes on Solaris and HP-UX systems, and 56 bytes on IRIX systems. The size of the hsmname.IHAND file is approximately the number_of_inodes * (64 | 56). The number_of_inodes is equal to the number of migrated files. You can expand the size of an existing file system by increasing the number of available inodes. If you do add inodes to a managed file system, the IHAND file will grow as needed.
The VSM command ihprint will allow you to display and alter entries in the IHAND file. Only use ihprint to fix the file if you are certain the IHAND entry is incorrect.
Chapter 6, Managing VSM 199
Setting up Utilities
Caution Never make changes to the IHAND file outside of those made with ihprint (to fix the file) and rebuild_ihand (to recover the file).
Any differences in IHAND format that may occur between software releases are accommodated automatically when you upgrade.
Caution The IHAND file must NOT be restored with the FHDB, FNDB, and VOLDB databases.
Typical error messages that indicate rebuild_ihand needs to be run are as follows:
05/15 22:17:45 [142]migd[343]: ERROR: Handle mis-match for inode 144005/15 22:17:45 [142]migd[343]: ERROR: could not convert DM to mig
See the rebuild_ihand man page for detailed usage information.
Setting up fstab/vfstabUpdate the fstab file (vfstab file on Solaris) to include all managed file systems. This update ensures that the VSM server mounts these file systems at start up. If the mount is not done at startup, you must mount the managed file systems individually or with a special script.
Example vfstab entries from a Solaris system follow:
/dev/dsk/sds1 /dev/rdsk/c1t6d0s1 /hsm2 vxfs - yes -/dev/dsk/sds6 /dev/rdsk/c1t6d0s6 /hsm3 vxfs - yes -/dev/dsk/sds0 /dev/rdsk/c1t3d0s0 /db vxfs 2 yes -/dev/dsk/sds1 /dev/rdsk/c1t3d0s1 /hsmdb vxfs 2 yes -/dev/dsk/sd3 /dev/rdsk/c1t3d0s3 /hsmbig vxfs 2 yes -/dev/dsk/sds6 /dev/rdsk/c1t3d0s6 /auspex vxfs 2 yes -
Global Log FileThe VSM global log file contains messages that pertain to all VSM configurations on the server. This log is named /tmp/hsm.log.
You cannot reconfigure the path name or log name. However, to ensure that you do not lose log messages after a system reboot or crash, link this log to a file that is in a directory other than /tmp, as in the following example:
ln -s /var/logs/hsm.log /tmp/hsm.log
Note Ensure this link is created after reboot.
On IRIX systems, the startup script creates the following symbolic link:
200 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Scheduling Management Tasks
ln -s /usr/var/openv/hsm/global.log /tmp/hsm.log
See “Managing Logs” on page 247 for information using and managing this log file.
Control FilesYou can control the migration of specific files by including them in one of two global control files:
◆ The global migrate file (/usr/var/openv/hsm/database/migrate) contains a list of the files or directories of files that VSM will migrate each time automatic migration occurs.
◆ The global stop file (/usr/var/openv/hsm/database/migstop) contains a list of the files that VSM will not migrate.
These global control files apply to all managed file systems on the server. For more information how to create and use these global VSM control files, see “Controlling Global Migration” on page 218.
Scheduling Management TasksUse the VSM Scheduling tool to schedule automatic processing of migration tasks, as described in “Scheduling Tool” on page 173.
To access the VSM Scheduling interface, select Actions > Scheduler in the VSM-Java Administration interface. The scheduler lets you automate the following tasks:
◆ migbatch migrates and copies files to keep the managed file system within configured limits
◆ mignewlog saves a copy of the previous log and starts a new log
◆ migmove moves files between migration levels
◆ Reports scans managed file systems and collects data for the Reporting tool
Managing VolumesVolume management tasks that you perform as a VSM administrator include the following:
◆ “Monitoring Volume Usage” on page 202
◆ “Keeping a Supply of Unused Volumes” on page 202
◆ “Cleaning nb Volumes” on page 203
Chapter 6, Managing VSM 201
Managing Volumes
◆ “Consolidating Volumes” on page 204
◆ “Removing Tape or Optical Volumes for Offline Storage” on page 214
◆ “Moving Files to a New Volume Set” on page 214
◆ “Deleting Volumes” on page 214
◆ “Duplicating a Tape Volume from Migrated Files” on page 215
Caution Never use media containing VSM migrated files in a device that is not under control of NetBackup Media Manager. Doing so can result in loss of data due to the media being used by non-VSM processes.
Monitoring Volume Usage Monitoring volume use helps ensure the most efficient use of media and its capacity to accommodate pending migrations. The migdbrpt and miggetvol commands provide reports that list your VSM volumes and help determine how much space remains on each.
◆ To check the used and free space of volumes, use the migdbrpt command.
◆ To list volumes in order of space utilization, use the miggetvol command.
◆ To select possible volumes for consolidating, use the migselect command.
When monitoring volume usage, be alert to volumes that require management, such as the following:
◆ Unused volumes that VSM can use for future migrations.
◆ Volumes with many obsolete files that can be consolidated and recycled
◆ Damaged volumes to which VSM no longer writes, but from which VSM still reads migrated files
Keeping a Supply of Unused Volumes Unused volumes are your reserve for future storage. These are volumes that you have already registered, but that VSM has yet to use for storage. Ensure that you always have enough unused volumes available to prevent VSM from running out of media during a migration.
You can register extra media in volume set 0 for each method. The extra media can be either new or media that you have reclaimed through the recycling process. Recycling used media is explained in “Consolidating Volumes” on page 204.
202 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
After VSM uses all previously registered media, it automatically registers additional tape and optical disk media for writing the files on the work list to secondary storage. The registered media can be from one or more volume pools specified for the storage method in VSM-Java. If no volume pool is specified, VSM uses the default volume pool HSM.
If there are no unassigned volumes in the specified pool, VSM registers a volume from the Media Manager scratch pool and changes the pool name of that volume to match its own volume pool name. For this to occur, include the following statement in the Media Manager configuration file, /usr/openv/volmgr/vm.conf:
SCRATCH_POOL = scratch_pool_name
The scratch_pool_name is the pool name for all volumes currently unassigned in the Media Manager scratch pool.
Cleaning nb Volumes
Note The NetBackup (nb) method will not be supported in the next release of VSM.
When VSM migrates files using the nb method, it attempts to identify the NetBackup imageID for the migrated files. This imageID takes the form of the NetBackup client name and the UNIX timestamp.
When a file is cached from an nb volume, VSM informs NetBackup of the UNIX timestamp in order to help locate the file image on the volume.
If VSM cannot find the imageID when attempting to cache the file, it enters a default timestamp of 0 in the FHDB. A timestamp of 0 slows restore operations for such files, because no time range is indicated.
If all file images from a given timestamp are obsolete, the migmdclean command notifies NetBackup to delete the images from its database. You are responsible for determining when all the images on a NetBackup volume have been deleted and for expiring the volume.
If the timestamp is 0, VSM cannot correctly inform NetBackup which images to delete, and migmdclean cannot clean the nb volume.
The following procedure resets the time stamp so VSM can inform NetBackup which images to delete.
▼ To fix timestamps for the nb method by substituting imageIDs for all files
1. To run the mignbscan command and merge its FHDB.label output file with the FHDB, run the /usr/openv/hsm/bin/goodies/dbconstruct.sh script.
2. To eliminate FHDB entries for deleted files, run migdbcheck -r
Chapter 6, Managing VSM 203
Managing Volumes
The remaining FHDB entries have the proper timestamp, and migmdclean will correctly inform NetBackup which images to delete.
Consolidating Volumes
Note Consolidation is not applicable for ft or nb volumes.
Volume consolidation makes it possible to reuse otherwise wasted space.
When a cached file is modified or removed from local disk, VSM marks the file as obsolete in the FHDB. The space occupied by obsolete files on a volume cannot be reused as long as there are any active files on the same volume.
The consolidation process reads active and obsolete data from a set of input volumes and writes it to a set of output volumes. No data marked as dead is written to output. After consolidation, all files on the consolidated volumes are marked dead, and the volume can be recycled.
The steps in volume consolidation are as follows:
1. Run migmdclean to change obsolete entries to dead, so that you write only active files to another volume.
2. Write any active files to another volume.
3. VSM does a feasibility check ensure the output volume has adequate capacity for the files to be consolidated.
You can force consolidation to occur regardless of the outcome of the feasibility check. If the output volume capacity is inadequate, VSM automatically registers additional media. The new output volumes are registered in the same volume pool as the first input volume being consolidated.
4. VSM removes all entries for file granules from the FHDB.
5. VSM removes the entry for the volume from VOLDB.
6. Register and label the volume for reuse by VSM, as described in “Recycling Empty Volumes” on page 213.
The frequency with which you must perform consolidation depends primarily on the rate at which migrated files are changed or deleted on the local file system.
Note Although you can consolidate ow volumes (write once, read many), you can not recycle them.
204 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
In addition to using consolidation to recover wasted space, you can use consolidation to move data from one set of volumes to another set.
The following figure illustrates what occurs as VSM writes and caches files to an optical disk (methods op and ow) or tape volume (methods ct, dt, and mt). The process is the same for alternate disk volumes (method ad) except that there is no EOV label to rewrite. After files that have been cached are modified or removed, volumes may need to be consolidated.
Chapter 6, Managing VSM 205
Managing Volumes
Writing and Obsoleting Files on Media
Note If you are consolidating to a write-once-read-many (WORM) tape, consolidation will create multiple EOV labels on the tape.
Labeling media creates a volume label at the front of the tape or optical media after the BOT (beginning-of-tape label). On tape media it creates an EOV (end-of-volume label) after the volume label. VSM also creates an entry for the volume in the VOLDB.
If a file is modified or removed, VSM marks the FHDB entry for the file as obsolete. In the following example, file A and file C have been cached and modified, and VSM makes their FHDB entries obsolete. VSM rewrites the space for file A and file C only after the media is recycled.
VOLDB entry
BOT VOLn Label EOV
FHDB entry
VOLn labelMedia
Media
Media
FHDB entriesFNDB entries
VOLDB entry
VOLDB entry
BOT VOLn label file A file B file C EOV
VOLn label
VOLn label
VOLn label
BOT VOLn label file A file B file C EOV
active active active
obsolete active obsolete
When you migrate files to the volume, VSM writes them behind the header. On tape, it rewrites the EOV after the last file. VSM updates entries in the FHDB for each file; these files are marked “active.” This process continues until the media is full. The example below writes three files.
206 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
One-Step Volume Consolidation with VSM-Java
You must have two drives to do one-step consolidation: the first drives reads input volumes and the second drive writes output volumes.
The input and output storage methods can be either the same or different.
If you do not have enough drives to support one-step consolidation, use the two-step consolidation procedure described in “Command-line Two-Step Consolidation” on page 210.
Before you consolidate volumes, run migmdclean to change obsolete database entries to dead so that you write only active files to another volume.
▼ To perform one-step consolidation using VSM-Java
Note VSM-Java allows only one-step consolidation.
1. On the Left Pane of the VSM-Java Administration dialog, click the + sign for the hierarchy and expand it until you see the volume you wish to consolidate.
2. In the Right Pane, highlight the volume you want to consolidate, as shown in the following figure.
Selecting a Full Volume to Consolidate with VSM-Java
3. Verify that the volume full flag is set to full in the Flags column in the Right Pane. If it is not set, select Actions > Volume > Set Flags > Full. Confirm your choice.
4. Select Actions > Volume > Consolidate Volume. Confirm your choice.
Chapter 6, Managing VSM 207
Managing Volumes
5. Repeat these steps for each volume you wish to consolidate.
Command-line One-Step Consolidation
If for some reason you cannot perform consolidation by using VSM-Java, you can use the command-line interface.
▼ To perform one-step, command-line consolidation
1. Run migmdclean on the volumes you are consolidating. This process cleans the media and databases by changing obsolete FHDB entries to dead and then removing the dead entries from the FHDB.
Note For the ad and ft methods, migmdclean attempts to remove files from the media if the MFLAG_OBSOLETE flag for these methods is set in the configuration (which it is by default). For the ct, dt, mt, op, and ow methods, migmdclean never attempts to remove files from the media, but makes the data inaccessible.
2. Consolidate volumes by using the migcons command:
The following example for the managed file system delta consolidates V00001 and V00002 cartridge tape volumes to new cartridge tapes selected by VSM:
# migcons delta one ct 1 V00001.ct.1 V00002.ct.1
You can also consolidate volumes based on percentage of how full the volume by running migselect in conjunction with migcons, as follows:
The following example selects input volumes from ct method, volume set 2, based on limits ranging from 0.00 through 5.50 percent full:
# migcons delta one ct 2 ‘migselect delta 0.00-5.50 2 ct‘
The following example selects and consolidates media when the data on the media is at least 50 percent obsolete:
# migcons delta one ct 2 ‘migselect delta -o 50.0-100 1 ct’
3. Register and label the input volumes for future use by using the migreg command:
4. The following example for the managed file system delta registers the two cartridge tapes that were consolidated in step 2 and assigns them to volume set number 2:
# migreg -D delta ct 2 V00001 V00002
Consolidating the volumes makes all data on the input volume inaccessible.
The following figure shows what occurs during the consolidation of optical disk or tape volumes (the ad method process is the same, except that there is no EOV label to rewrite).
208 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
One-Step Consolidation Process
Note If you are consolidating to a write-once-read-many (WORM) tape, consolidation will create multiple EOV labels on the tape.
Files 1A and 1C on VOL1 are dead. VSM cannot reuse the space until all files on the tape (that is, file 1B) become dead and the tape is recycled.
migreg labels the media and registers the volume for reuse by VSM by creating an entry for it in VOLDB. The example below relabels the media as VOLn, removes the files, and rewrites the EOV after the label.
migcons copies file 1B from VOL1 to VOL2 and then makes file 1B obsolete on VOL1.
migcons removes all FHDB and VOLDB entries for VOL1.
BOT VOL1 label file 1A file 1B file 1C EOV
BOT VOL1 label file 1A file 1B file 1C EOV
BOT VOL2 label file 2A file 2B file 1B EOV
BOT VOL1 label file 1A file 1B file 1C EOV
dead active dead
active active active
VOL1 label
VOL2 label
VOLn label
BOT VOLn label EOV
Media
Media
Media
Media
Media
VOLDB entry
VOLDB entry
VOLDB entry
VOLDB entry
FHDB entry
FHDB entry
FHDB entry
Chapter 6, Managing VSM 209
Managing Volumes
Command-line Two-Step Consolidation
If you have only one drive available for reading and writing, use two-step consolidation
In two-step consolidation, VSM first consolidates input volumes on disk to an intermediate ad volume and from that volume to the final output volumes.
To do two-step consolidation, you must register at least one volume to ad method, volume set 0.
Note Two-step consolidation is only available with the command-line interface. VSM-Java does not support it.
The two-step consolidation process performs the following tasks:
- Copies active and obsolete files from the input volumes to alternate disk volumes.
- Copies the files from the alternate disk volumes to the final output volumes.
- Removes FHDB entries for all input volumes.
- Marks the input volumes dead in the VOLDB.
- Makes active FHDB entries for active files copied to output volumes (and obsolete FHDB entries for any obsolete files copied).
- Updates VOLDB entries for the output volumes.
▼ To perform two-step consolidation
1. To mark obsolete files dead, run migmdclean on the input volumes. If you do not run migmdclean, obsolete files will be consolidated to the output volumes along with the active files.
Note For the ad and ft methods, migmdclean attempts to remove files from the media if the MFLAG_OBSOLETE flag for these methods is set (which is the default configuration for these methods). For the ct, dt, mt, op, and ow methods, migmdclean never attempts to remove files from the media. It makes the data inaccessible.
2. Ensure the ad volumes you register have enough space to hold the data being copied from the input volumes. You can estimate this by examining the output from migdbrpt for all input volumes. The space the volume occupies is listed in bytes under the GRAN_USE column
3. To register one or more alternate disk volumes to volume set 0, use the migreg command, as in the following example.
# migreg epsilon ad 0 /diskAA diskAA
210 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
4. To consolidate volumes by moving the data from disk to tape, use the migcons command.
The following example for the managed file system named epsilon consolidates ct volumes. The embedded migselect command selects ct volumes with occupancy limits ranging from 1.00 through 80.00 percent full. The volumes are consolidated first on diskAA using the ad method and then to new cartridge tapes (method ct) that VSM selects:
# migcons epsilon two ct 1 ’migselect epsilon 01.00-80.00 1 ad’
5. Register and label the input volumes for future use by using migreg.
The following example for the managed file system epsilon registers the cartridge tapes selected in step 4 and assigns them to volume set number 1:
# migreg -D epsilon ct 1 C00001 C00002 C00003
Consolidating the volumes makes all data inaccessible on the input volume (but accessible on the output volume for active and obsolete granules.
The following figure shows what occurs during the consolidation of optical disk or tape volumes. The process is the same for alternate disk volumes (method ad), except that there is no EOV label to rewrite.
Chapter 6, Managing VSM 211
Managing Volumes
Two-Step Consolidation
Note If you are consolidating to a write-once-read-many (WORM) tape, consolidation will create multiple EOV labels on the tape.
BOT VOL1 label file 1A file 1B file 1C EOV
Files 1A and 1C on VOL1 are dead. VSM cannot reuse the space until all files on the tape (that is, file 1B) become dead.
dead active dead
BOT VOL1 label file 1A file 1B file 1C EOV
BOT VOL1 label file 1A file 1B file 1C EOV
migcons copies file 1B from VOL1 to the ad volume.
migreg labels the media and registers the volume for reuse by creating a VOLDB entry for it. The example below relabels the media as VOLn, removes the files, and rewrites the EOV after the label.
BOT VOL2 label file 2A file 2B file 1B EOV
Media
Media
Media
Media
FHDB entries
VOLDB entry
VOLDB entry
VOLDB entry
VOLDB entry
MediaBOT VOLn label EOV
VOL1 label
VOL2 label
VOLn label
ad Volume file
active active active
migcons removes FHDB and VOLDB entries for VOL1.
migcons mounts the output volume using Media Manager and copies file 1B to VOL2
FHDB entries
FHDB entries
212 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
Recycling Empty Volumes
VSM regards a volume as empty when all of the files and granules on that volume are marked dead in the FHDB. This can occur when the migrated files on the volume have all been either modified or removed. VSM does not automatically reclaim this space, and the obsolete data remains available for possible reference at some future time. When the obsolete data is no longer of any value, you can recycle the empty volumes.
The migrecycle command makes data on empty volumes inaccessible. It also removes the related entries from the FHDB and VOLDB database files. After the entries are removed, migrecycle calls migreg to reregister and label the empty volume, thus reclaiming its storage space for future use.
Each side of an optical disk is a separate volume, but VSM registers both sides with the same volume set number. If both sides of a rewritable disk (op method name) are empty, you can recycle the entire disk, change its attributes, and assign a new volume set number. If one side is empty and the other contains granules, you can recycle the empty volume, but not change its attributes, and the volume set number remains the same for both sides. WORM media cannot be recycled.
▼ To recycle an empty volume
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the hierarchy until you see the volume you wish to recycle.
2. In the Right Pane, highlight the volume you want to recycle, as shown in the following figure.
Selecting an Empty Volume to Recycle
3. Select Actions > Volume > Recycle Volume. Confirm your choice.
4. Repeat these steps for each volume you wish to recycle.
Chapter 6, Managing VSM 213
Managing Volumes
Removing Tape or Optical Volumes for Offline Storage You can remove a volume from a library device for offline storage, making it less available.
To physically remove a volume from an online library, use the Media node of the NetBackup Administration Console or Media Manager vmadm utility to change the physical location of the volume to indicate Not Robotic.
To remove a single optical volume, remove the disk by using the mailslot capability of the optical disk library.
Subsequent references to a nonrobotic volume generate an operator mount request. To satisfy the mount request, either manually mount the volume in a nonrobotic device or move the volume to the appropriate robot.
If you will continue writing to the volume set of the removed volume, replace the removed volume with another volume registered to the same volume set.
To move volumes to a robot, you also use the NetBackup Administration Console or Media Manager vmadm utility. To move a single optical volume, insert the disk by using the mailslot capability of the optical disk library. After moving the requested volume to a robot, resubmit the mount request through the operator interface.
Moving Files to a New Volume SetIf you want to move migrated files to a different volume set (to change media, for example), you can use either of the following two methods:
◆ For ct, mt, dt, op, ow, or ad volumes, move active and obsolete files from one volume to another volume by using the consolidation procedure. See “Consolidating Volumes” on page 204 for further details on this process.
◆ If you are using multilevel migration, you can use the migmove command to move files. migmove moves files from one volume set to another volume set if the volume sets are on different migration levels.
Deleting VolumesIf a volume is lost, destroyed, becomes unreadable, or all FHDB entries within it are obsolete, you can remove the entry from VOLDB, using either VSM-Java or the command line.
Note To ensure data is not lost, it is safest to duplicate the tape before deleting volumes.
214 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
▼ To delete volumes using VSM-Java
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the hierarchy until you see the volume you want to delete. The Right Pane will show the volume.
2. In the Right Pane, highlight the volume you want to recycle.
Selecting a Volume to Delete
3. Select Actions > Volume > Delete Volume. Confirm your choice.
4. Repeat these steps for each volume you wish to delete.
▼ To delete volumes using the command line interface, do the following:
❖ Force valid FHDB entries to be obsolete, then to be dead, and finally remove the VOLDB entry use a command such as the following example for VOL1, dt method:
# migmdclean -O -R VOL1.dt
Duplicating a Tape Volume from Migrated FilesIf VSM can no longer read a tape volume containing migrated data, you can make a new copy of all the files on the tape.
Chapter 6, Managing VSM 215
Managing Volumes
Caution If you want to duplicate a tape volume, make certain that another copy of each file exists on another volume that is neither an ft nor an nb volume.
Note
▼ To duplicate a tape volume from migrated files
1. Identify the volume handle (VOL_HAND) of the damaged tape volume. The VOL_HAND is found in each FHDB entry for files that are on the volume. To print a report of all volumes, use the following command:
# migdbrpt -a hsmname
In the following example, the VOL_HAND for tape label TP0004 is 00001008.
# migdbrpt -a vdm2
VOL_HAND LABEL POOL METHOD... 00000000 <=> DK0000 dk.0 ...00001007 <=> AD0001 ad.1 ...00001008 <=>W TP0004 dt.3 ...
The damaged tape TP0004 is in volume set dt.3, as shown in the METHOD column.
2. To mark all files as dead in the FHDB that have all or part of their data on the damaged tape volume, remove all of these dead FHDB entries, and remove the damaged tape volume from the VOLDB, use the following command:
# migmdclean -O -R hsmname label.method.volume_set
The following example removes the database entries for tape TP0004:
# migmdclean -O -R vdm2 TP0004.dt.3
After you have removed the damaged volume and files from the VSM databases, you can duplicate the files in different ways. The first of the following procedures uses migdbcheck and the second and third use migmove.
▼ To create another copy of all files on a damaged tape volume using migdbcheck
1. Set the managed file system state to Maintenance.
2. To find and repair problems on the tape volume, run the following command:
# migdbcheck -F hsmname
The output of this command is a set of files in /tmp that begin with the string migdbcheck and end with a process ID.
216 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Volumes
The problems described in these results files must be fixed before you go on to step 3.
Caution You could lose data if you do not repair the problems described in the /tmp/migdbcheck* files from step 2 before you start step 3.
3. To produce a work list of all files that do not have enough copies, run the following command:
# migdbcheck -F -r hsmname
4. To process the list produced by migdbcheck, run the following command:
# migrc -R hsmname
▼ To create copies using multilevel migration
1. In VSM-Java, do the following:
a. In the Left Pane, highlight the level that has a good copy of the files that were on the damaged tape.
b. Select Edit > Change Level Properties.
c. In the Level Properties dialog, set all the fields to 0. Changing the values sets the move threshold, the move minimum age, and the move minimum size to 0.
d. Select Actions > Level > Move Between Specified Levels.
e. In the resulting dialog, the first field is the source level. Specify the number of the level that still has an undamaged copy of the files.
The second field is the destination level. Specify the number of the level that has the damaged files.
Confirm your choice.
2. In the command-line interface, do the following:
a. To make another copy of the files that were on the damaged tape, run the following command:
# migmove -fa -A -s source_level -d destination_level hsmname
The -fa option causes the source level files to remain active.
The source_level is the level that still has a good copy of the files.
Chapter 6, Managing VSM 217
Managing Migration
The destination_level is the level of the damaged tape.
This migmove command attempts to move all the files. Note that if a file at destination_level, even if it is flagged as dead, migmove does not put it there again. For this reason, the tape volume was removed from the VSM databases before using migmove.
In the following example on the managed file system gamma, the source_level is 1 and destination_level is 2. Files at level 1 remain active.
# migmove -fa -s 1 -d 2 gamma
Managing MigrationThis section describes migration management tasks.
Controlling Global MigrationIn addition to the local control files .migrate and .migstop available to users, you can use global control files. These files are part of the VSM configuration and apply to all VSM file systems:
◆ The global migrate file (/usr/var/openv/hsm/database/migrate) contains a list of the files VSM will migrate during automatic migration.
◆ The global stop file (/usr/var/openv/hsm/database/migstop) contains a list of the files that VSM will not migrate. The specifications only affect files that reside in a VSM managed directory.
General Rules for VSM Control Files
VSM applies the following general rules to control files.
◆ Control file names are not configurable. All local (user) migrate files must be named .migrate. All local stop files must be named .migstop.
◆ Local control files can reside anywhere, even outside managed file systems, but they only apply to managed files in the subtree of the directory in which the control file resides. Symbolic links are not traversed.
◆ You can create one global migrate file and one global stop file. These files apply to all managed file systems on the VSM server.
218 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Migration
◆ The .migrate and .migstop files closest in the directory structure to the migration candidate completely replace more remote control files in the directory tree. Local control files take precedence over global control files if the same file or directory is listed in both.
◆ If the same file or directory is listed in both a .migrate file and a .migstop file at the same level, the .migrate file takes precedence over the .migstop file.
◆ Directories listed in a control file apply to all files and subdirectories residing in that directory unless replaced by another control file closer in the directory structure to the listed file or directory.
See “Control File Example” on page 220 for more information how VSM determines the priority of control files.
Syntax Rules for VSM Control Files
VSM applies the following syntax rules to local and global control files.
◆ Each line in a control file contains only one entry. Empty lines and lines starting with the pound sign (#) are ignored.
◆ In local control file entries, relative paths stem from the directory in which the local control file resides. Absolute paths only apply if they resolve to files or directories in the subtree in which the local control file resides.
◆ In global control file entries, relative paths stem from the mount point of each VSM file system. Absolute paths only apply if they resolve to files or directories in managed file systems.
◆ VSM does not traverse symbolic links.
◆ VSM does not match parent directory (..) entries.
◆ VSM recognizes wildcards in control file entries. The wildcard metacharacters are as follows:
- An asterisk (*) matches any character string including the null string.
- A question mark (?) matches any single character.
- A set of brackets ([]) matches any of the enclosed characters. A pair of enclosed characters separated by a hyphen (-) matches any character lexically between the pair, inclusively. If the first character following the first bracket ([) is an exclamation point (!), matches occur for any character not enclosed.
◆ VSM matches initial dot (.) file names and directories explicitly.
◆ VSM matches an ellipsis (...) used as a directory name to match any number of subdirectories.
Chapter 6, Managing VSM 219
Managing Migration
◆ Special characters including a backslash (\) can be escaped with a backslash if they are to be matched explicitly in a file name or directory.
◆ Files listed in global control files are not subject to the quota limit.
◆ If files are excluded from automatic migration by listing them in a .migstop file or global stop file, the super user or the file’s owner can still force their migration by running migrate -F filename.
Control File Example
Assume that user kali has files in the managed file system beta as shown in the following figure.
Files Affected by Example Control Files
Files in /beta/kali/kali_proj1/ are migrated as follows:
Initial Set of Migrating Candidates in Control File Example
File Name Migratable? Rationale
yesmig1 yes Control file entry /beta/kali/*proj*/yesmig* in /beta/kali/.migrate
yesmig2 yes Control file entry /beta/kali/*proj*/yesmig* in /beta/kali/.migrate
files in /beta/kali/.migstop:
/beta/kali/nomig1/beta/kali/nomig2/beta/kali/*proj*/nomig*
.migstop
files in /beta/kali/.migrate:
/beta/kali/yesmigrate1/beta/kali/yesmigrate2/beta/kali/*proj*/yesmigrat*
.migrate
kali_proj1
kali
/beta
nomig1nomig8nomigrate2nomigrate1yesmig2yesmig1
220 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Migration
The migsweep process checks for control files in the directory where it is trying to locate migration candidates. If there are none, it searches for control files further away in the directory structure. If it finds a control file in the local directory, it looks creates work lists for migration based on the information it finds in that local file.
Now assume that user kali creates a .migstop file in /beta/kali/kali_proj1/ that contains the following entries:
/beta/kali/kali_proj1/nomigrate1/beta/kali/kali_proj1/nomigrate2/beta/kali/kali_proj1/yesmig1
◆ The existence of this file changes the set of migration candidates in /beta/kali/kali_proj1/ as follows:
nomigrate1 no Control file entry /beta/kali/*proj*/nomig* in /beta/kali/.migstop
nomigrate2 no Control file entry /beta/kali/*proj*/nomig* in /beta/kali/.migstop
nomig1 no Control file entry /beta/kali/*proj*/nomig* in /beta/kali/.migstop
nomig6 no Control file entry /beta/kali/*proj*/nomig* in /beta/kali/.migstop
Migration Candidates in Control File Example when Local .migstop Exists
File Name Migratable? Rationale
yesmig1 no Control file entry /beta/kali/kali_proj1/yesmig1 in /beta/kali/kali_proj1/.migstop
yesmig2 yes Control file entry /beta/kali/*proj*/yesmig* in /beta/kali/.migrate
nomigrate1 no Control file entry /beta/kali/kali_proj1/nomigrate1 in /beta/kali/kali_proj1/.migstop
nomigrate2 no Control file entry /beta/kali/kali_proj1/nomigrate1 in /beta/kali/kali_proj1/.migstop
Initial Set of Migrating Candidates in Control File Example
File Name Migratable? Rationale
Chapter 6, Managing VSM 221
Managing Migration
Scheduling MigrationsVSM allows you to schedule automatic, unattended migration of files either by using the scheduling feature of VSM or by using cron to invoke the migbatch command. When setting up schedules, the two main considerations are as follows:
◆ What time of day migration will occur, as described in “Best Times for Migrating Files” on page 53
◆ Which days migration will occur, as described in “How Often to Migrate Files” on page 54
Note For information in the VSM Scheduling tool you can use to create these schedules, see “Scheduling Tool” on page 173.
Invoking Migration CommandsMost file migration with VSM is handled by scheduled, automatic, and unattended migration operations.
There are other situations, however, when you need to perform particular migration functions immediately. VSM-Java lets you invoke many of these migration commands.
Migrating Files to Secondary Storage
You may want to migrate files to secondary storage at an unscheduled time. One example of when this might occur is a power interruption that caused a scheduled batch migration to be missed.
nomig1 yes Control file /beta/kali/kali_proj1/.migstop contains no entry that applies, and /beta/kali/.migstop has been replaced with /beta/kali/kali_proj1/.migstop
nomig6 no Control file /beta/kali/kali_proj1/.migstop contains no entry that applies, and /beta/kali/.migstop has been replaced with /beta/kali/kali_proj1/.migstop
Migration Candidates in Control File Example when Local .migstop Exists
File Name Migratable? Rationale
222 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Migration
▼ To migrate files on a managed file system to secondary storage
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the display of the hierarchy that contains the files you want to copy, and highlight the managed file system.
Premigrating Files with VSM-Java
2. Select Actions > Filesystem > Batch Migrate.Confirm your choice.
Confirming the action starts the migbatch command, which sweeps the managed file system, selects migration candidates, assigns file handles and puts the files in work lists (changing migration candidates to premigrated files), and then copies them to secondary storage as you specified when you configured the file system.
3. Repeat these steps for each managed file system with files that you wish to migrate.
Managing the Free Space Threshold
You can examine and change the minimum percentage of available disk space you want to maintain in the managed server.
Chapter 6, Managing VSM 223
Managing Migration
▼ To change the free space threshold
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the display of the hierarchy that you want to change and highlight the managed file system.
2. Select Edit > Change Filesystem Properties to open the Managed Filesystem Properties dialog. Click on the Water Marks tab. You will see a screen such as the one in the following figure.
Managing the Free Space Threshold with VSM-Java
3. Change Desired Percentage Free Space to meet your needs.
If they have not been configured, the slides for the other desired percentages (low water mark and purge mark) do not appear unless you click on their respective checkboxes.
4. Repeat these steps for each managed file system you wish to change.
224 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Migration
Making More Disk Space Available
After files are copied to secondary storage, their disk space is still assigned on the managed server until the files are purged.
▼ To make disk space available in a managed file system
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the display of the hierarchy that contains the files you want to purge, and highlight the managed file system.
Purging Files with VSM-Java
2. Select Actions > Filesystem > Batch Purge. Confirm your choice.
Confirming the action starts the mignospace command, which deletes purge candidates from disk to increase free space.
If there are no purge candidates to delete, mignospace initiates a migration operation to move additional files to secondary storage, thus creating purge candidates.
3. Repeat these steps for each managed file system with files that you wish to purge.
Chapter 6, Managing VSM 225
Managing Migration
Move Files between Migration Levels
Multilevel file migration lets you configure up to eight different migration levels. See “Migration Parameters” on page 22 to learn more about migration levels.
Note If your managed file system has only one migration level, this option is not available to you. It is grayed out in VSM-Java.
In multilevel migration, the initial migration to secondary storage sends the Primary copy of a file to migration level 1. If dual copies are configured, the Alternate copy goes to migration level 2. Because you can configure up to eight migration levels in VSM, you can move files between levels in a variety of ways. See “Criteria for Moving Migrated Files” on page 81 for an explanation of multilevel migration.
▼ To move files between migration levels
Note You can move files between migration levels in VSM-Java either by selecting the managed file system to complete moves on all levels or by selecting a single level within the managed file system that contains files want to move to another level.
This procedure describes the options for moving files from a single level to another.
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the display of the hierarchy that contains the files you want to move to a different level, and highlight the level.
2. Select Actions > Level. You have three options you can use to migrate files between levels.
Moving Migrated Files with VSM-Java
226 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing Migration
a. To move the files from the level you highlighted above to the next configured migration level, select Actions > Level > Move This Level to Next. Confirm your choice.
b. To move files between levels (from Primary Level: 3 to Primary Level: 7, for example), complete the following steps:
- Select Actions > Level > Move Between Specified Levels. A confirmation dialog appears.
- .Specify the level from which (source level) and to which (destination level) you will move files. VSM then marks the files on the source level files as obsolete in the FHDB.
c. To copy files between levels and increase redundancy of your data, do the following:
- Select Actions > Level > Copy Between Specified Levels. A confirmation dialog appears.
- Specify whether you want to move the Primary copy or the Alternate copy, and to which level you want it copied. VSM leaves the files on the source level files as active in the FHDB.
3. Repeat these steps for each managed file system with files that you wish to move or copy to a different migration level.
Customize the VSM Policy and Method for Migrating Files
You can customize the way VSM copies files to suitable media by replacing /usr/openv/hsm/bin/admincmd/migpolicy.script with an alternate script. A file /usr/var/openv/hsm/example/database/sample.migpolicy.script provides a sample replacement. This sample uses the size of a file to determine whether VSM will copy it to the Primary or Alternate level. For detailed information on this process, see the migpolicy(1M) man page.
Chapter 6, Managing VSM 227
Managing Migration
Reconfiguring Storage MethodsYou can change the storage method associated with a storage level.
▼ To change storage methods for migration levels
1. To change the state of the affected managed file system, highlight the file system in the Left Pane of the VSM-Java Administration window and select Actions > Filesystem > Set State > Maintenance.
The command-line equivalent is migVSMstate -s maintenance hsmname.
2. To ensure all required copies have been made by the current method, run the following command:
migbatch -s hsmname
Wait until this command finished before proceeding to the next step.
3. When processing from step 2 is complete, run the following command:
migdbcheck -F -r hsmname
4. If there are not enough copies, and you are asked to run migrc -R also, do so.
Note When the migrc command completes, other background processes may still be running. To ensure all recovery work is finished, check the log file for a migrecover.sh completion message.
5. Use multilevel migration to move any files you want to move from the current level, as described in “Move Files between Migration Levels” on page 226. (This step is optional.)
6. Reconfigure the level to use the new storage method.
a. Highlight the level in the Left Pane of the VSM-Java Administration window and select Edit > Delete Level.
b. Highlight the hierarchy in the Left Pane of the VSM-Java Administration dialog and select Edit > New Level. Configure the level as described in “Adding to Configured Systems” on page 145.
7. Register volumes for the reconfigured level as described in “Adding to Configured Systems” on page 145.
228 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Performance Tuning with Tape Marks
8. To change the state back to Active, highlight the file system in the Left Pane of the VSM-Java Administration window and select Actions > Filesystem > Set State > Active.
The command-line equivalent is migVSMstate -s active hsmname.
Files will now be migrated according to the reconfigured storage method. Files previously migrated under the old storage method for the level can still be cached.
Performance Tuning with Tape MarksBy default, when VSM copies premigrated files to tape it writes a tape mark in two circumstances:
◆ After every four gigabytes of file data (rounded up to include complete files)
◆ After all files in the copy operation have been written to tape.
Writing tape marks more frequently degrades copy performance. Writing tape marks less frequently makes recovery from a system crash more difficult because the entire copy operation since the last tape mark must be repeated. In general, the default behavior is a good balance of these trade-offs.
To modify the default behavior and write tape marks differently, create a file named in dwpath/database/hsmname.FLUSH. This FLUSH file should contain two values, separated by a blank:
value1 value2
The first value (value1) is the number of files to be copied before writing a tape mark. The second value value2 is the number of kilobytes to be written before writing a tape mark.
If you set value1 = 0, VSM interprets it as no file limit. If you set value2 = 0 VSM interprets it as unlimited kilobytes. Thus, if the FLUSH file contains 0 0, VSM writes a tape mark only after all files are written.
Default tape marks are written in the following situations:
◆ hsmname.FLUSH does not exist
◆ hsmname.FLUSH exists but is empty
◆ hsmname.FLUSH exists, value1 = 0 and value2 does not exist
◆ hsmname.FLUSH exists, value1 = 0 and value2 = 4104304 (4 gigabytes)
If both value1 and value2 are specified, a tape mark is written whenever either condition is met.
Chapter 6, Managing VSM 229
Performance Tuning with Constant Sweeps
Performance Tuning with Constant SweepsYou can tune VSM to perform constant sweeping of the managed file system instead of the normal sweeping process. To enable constant sweeping, run the following shell script:
/usr/openv/hsm/bin/migconsweep [-s sleep_time] hsmname
The -s sleep_time option specifies the time (in seconds) that this command sleeps before resuming a sweep of the file system. The default is 60, or 1 minute.
Constant sweeping uses system resources and may adversely affect overall VSM performance, particularly during periods of heavy system usage. After initiation, constant sweeping continues to run until the process is terminated with the kill command. For more information, see the migconsweep(1M) man page.
Moving Migrated Files (Export and Import)
Note Neither the ft or nb methods are eligible to be imported or exported.
To move copies of migrated files from one managed file system to another managed file system, use the export and import feature of VSM. NetBackup is required for file export and import with VSM.
Note The mignbexport command does not support embedded special characters in file names, such as newline, backslash, vertical bar (pipe), tab, question mark, asterisk, parenthesis, square brackets, or curly braces.
Make sure that each of the file systems for exporting or importing file is configured with a unique machine ID. This convention prevents the possibility of importing files that have the same file handles as files that have been previously migrated on the importing file system.
Configure an appropriate migration level and corresponding method on both the exporting system and the importing system. Copy files to that level before exporting them, and access them from that level when importing them.
Although VSM writes data in the same format on all platforms, platform-specific device drivers can be incompatible. For example, tapes written on HP-UX or Solaris platforms cannot be imported to IRIX platforms in all cases. If you are exporting to optical media, the exporting and the importing file systems must run on identical platform types and operating systems.
230 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Moving Migrated Files (Export and Import)
Planning File ExportsThere are two ways to export files:
◆ Export only migrated files residing at the specified export level (ExpLevel). In this case, do not specify the -s dir option. Note that unmigrated files are not exported.
◆ Export all migrated and unmigrated files residing in the specified directory (export_dir) in the managed file system.
If you want to export only migrated files from a directory in the managed file system, make sure that all files in that directory are migrated and copied as follows:
# cd export_dir# find . -type f -print | xargs fls -l | grep -v "\[machid"
The machid is the machine ID displayed by the fls command for any migrated file in the same file system. If all files have been migrated, there is no output from this find command (as specified with grep-v).
To verify that all these migrated files have the required number of copies, run the migdbcheck command and ensure there are no messages such as the following:
-- INFO: 2 files have less than 2 copies made.
Files are exported from a migration level. Valid values are levels 1 to 8; the default is 8 (the default for importing is 7).
You can also export files from a subdirectory in the managed file system. In this case, the mignbexport command moves the files to be exported to the export migration level first and then exports them.
Because all volumes at that level will be exported, you must eliminate extraneous active entries at the export migration level before running the export command.
The mignbexport command does a user-directed backup of the exported files and all VSM database entries for exported files.
The backup is done to a NetBackup policy that you define in the NetBackup configuration before running mignbexport. The NetBackup policy must define a NetBackup volume pool that contains volumes that can be sent to the location that will be doing the mignbimport.
After running mignbexport, send the following items to the administrator of the importing file system:
◆ The VSM volumes listed in Volumes_to_export.pid
◆ The NetBackup volumes belonging to the specified NetBackup policy which were used during the mignbexport operation
◆ The NetBackup client name contained in /usr/openv/hsm/database/dwpath/Client_name.pid
Chapter 6, Managing VSM 231
Managing VSM Databases
Planning File ImportsFiles are imported from a migration level. Valid values are levels 1 to 8; the default is 7 (the default for exporting is 8).
The mount point (fspath) as defined in the configuration of the importing file system replaces the mount point as defined in the configuration of the exporting file system.
The paths for the imported files found in the managed directory (as defined in the configuration of the importing file system) are identical to the paths for the exported files in the managed directory (as defined the configuration of the exporting file system). These managed directories can be either at or below the mount point for the file system.
The mignbimport command does a user-directed restore of the exported files and all VSM database entries for those exported files.
The restore is done from a NetBackup policy that you define in the NetBackup configuration before running mignbimport. The NetBackup policy must have the same name as the policy used with the mignbexport command. The policy must reference a NetBackup volume pool that contains only the NetBackup volumes that were written by the mignbexport command.
The NetBackup volumes written by mignbexport must be imported into NetBackup at the location importing the files before running mignbimport. Use the NetBackup client name found in the /usr/openv/hsm/database/dwpath/Client_name.pid file sent from the exporting site. If you do not do this, Media Manager will issue requests for the operator to assign this media. These volumes retain their original volume name, so they must be unique.
The mignbimport command registers these volumes to VSM automatically.
For more information importing NetBackup images, see the NetBackup DataCenter System Administrator’s Guide - UNIX.
Managing VSM Databases The VSM databases reside in the database and workdir directories.
Caution VSM databases in dwpath/database/hsmname (except for the hsmname.IHAND file) are text files that you can view with any text file editor. Do not alter or otherwise damage any VSM database you view in this way. Doing so can make it difficult if not impossible to retrieve migrated files. Whenever possible, view the files with commands such as cat, tail, or view that do not allow writing the file.
232 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing VSM Databases
Databases on a VSM server“Files in dwpath” on page 38 lists VSM database files on the VSM server.
File Handle Database (FHDB)
A VSM file handle is a unique sequence number that makes it possible to locate all copies of a migrated file, regardless of the storage methods used. The file handle database (FHDB) contains at least one database entry for each copy of a file.
VSM creates one FHDB entry for each copy of a file, unless the file spans multiple volumes. If the file does span volumes, it has an additional FHDB entry for each volume.
The main processes that add entries to the FHDB are those that premigrate files and copy them to secondary storage, as follows:
◆ After selecting a migration candidate, VSM extends the FHDB when it moves each file into premigration. VSM adds one dk entry and one or two placeholder entries to the FHDB.
◆ VSM creates destination volume database (DVDB) entries as it copies files to secondary storage.
◆ VSM replaces FHDB placeholder entries with DVDB entries when possible.
◆ VSM merges any remaining DVDB entries into the FHDB.
Each FHDB entry contains the following fields:
handle|machid|flags|volid|lock|size|offset|gransize|crc|reserved|reserved|arch_date|copy_date|obsdate|method|path|reserved|reserved|reserved|hint|seek_info|fh_seek_increment|comment|inode|rep_FHDB|mmlevel|
Because the file name database (FNDB) holds information that was formerly stored in the FHDB, some of the fields in the FHDB are reserved. They are included in the FHDB even though they are unused because VSM and customer scripts often reference FHDB fields by position.
The following FHDB entry represents a copy of a file that VSM has stored on optical disk:
000306AB|000E7C03|00000000|00001086|00000000|00002800|00000000| 00002800|00432E8|l|3B9681E3|3B968209|00000000|op|||||l| 1 512|00002A00|||00000000|00000001|
Chapter 6, Managing VSM 233
Managing VSM Databases
The following table describes the values for each field.
FHDB Entry Description
Entry field Example value Description
handle 000306AB File handle. Unique file identifier
machid 000E7C03 Machine ID. Machine identifier of the VSM server
flags 00000000 Any of the following:
- 00000000 Entry is Active
- 00000002 Item failed; possibly corrupted
- 00000004 Entry for obsolete data or volume
- 00000008 Entry is dead
Flags can appear in any combination
volid 00001086 Volume ID of the volume on which the data resides
lock 00000000 Process ID (pid) of the locking process
size 00002800 File size in bytes
offset 00000000 File offset.
gransize 00002800 Granule size in bytes
crc 000432E8 Granule checksum
reserved
reserved
arch_date 3B9681E3 Date the file was premigrated
copy_date 3B968209 Date the file was copied to a volume.
obsdate 00000000 Date the file was changed or removed, making the entry obsolete.
method op Storage method associated with this file.
reserved
234 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing VSM Databases
File Name Database (FNDB)
The File Name DataBase (FNDB) is much like the FHDB, in that it stores information that helps VSM to manage location and status of migrated files. Like the FHDB, the FNDB references all files by handle and machine ID.
Unlike the FHDB, the FNDB has only one entry per file. The information in the FNDB is generally static with regard to migration or rarely used in the migration process. It is used most often to rebuild file path names when you must recover your data after an interruption that caused data loss.
Each FHDB entry contains the following fields:
handle|machid|flags|lock|uid|gid|mode|comment|reserved|reserved|safepath|
The following entry is for the same file described in “FHDB Entry Description” on page 234:
000306AB|000E7C03|00000000|00000000|00000463|0000006E|000001A4| Auto HSM run |||@hsm3/kcm/d1/f.0|
reserved
reserved
reserved
hint l Volume set availability. Either l for library, o for operator, or v for vault
seek_info 1 512 Used to locate data on optical platters or tapes.
fh_seek_increment 00002A00 Number of bytes to seek to locate the next granule.
reserved
reserved
rep_FHDB 00000000 Number of granules this FHDB entry represents.
mmlevel 00000001 Multilevel migration level. If 1, this is the Primary copy. If 2, this is a copy created by multilevel migration (migmove).
FHDB Entry Description
Entry field Example value Description
Chapter 6, Managing VSM 235
Managing VSM Databases
The following table describes the values for each field.
FNDB Entry Description
Entry field Example value Description
handle 000306AB File handle. Unique file identifier.
machid 000E7C03 Machine ID. Machine identifier of the VSM server.
flags 00000000 Available for flags. Currently not used.
lock 00000000 Available for locking process ID (pid). Currently not used.
uid 00000463 User ID of file.
gid 0000006E Group ID of file.
mode 000001A4 Mode bits of file.
comment Auto HSM run Auto HSM run, User selected, or the group name used by migtie.
reserved Currently not used.
reserved Currently not used.
safepath @hsm3/kcm/d1/f.0 Path name associated with the file.
The path can begin with the following characters:
- / indicates a UNIX-readable pathname.
- @ indicates a safe pathname with any special characters replaced as necessary to make the path UNIX-readable.
- % indicates a DMAPI handle.
Any other character indicates an invalid path and an FNDB problem.
236 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing VSM Databases
Volume Database (VOLDB)
The VSM volume database (VOLDB) contains one entry for each registered volume. The first entry is the disk entry (dk entry). It is required. VSM creates subsequent VOLDB entries whenever you register a volume for one of the other methods.
VSM updates the database whenever it selects a volume to which it will migrate files and updates the database again when the copy is complete. The copy operation can fail, and VSM may not update some of the fields in the database, but the failure does not cause a problem in VSM.
Each volume database entry contains the following fields:
handle|machid|lock|flags|label|method|location|metric|date|size|reserved|inuse|files|volset|lt_file|blocks|gid|user|group|project_name|pool_name|server_name|server_user|server_password|
The migreg command redefines three VOLDB fields when registering a NetBackup policy as a volume for the nb method. The location field holds policy_name, the server_user field holds schedule, and the server_password field holds client_name.
Note The NetBackup (nb) method will not be supported in the next release of VSM.
For optical disk, the lt_file field holds the next byte address available, and the server_password field holds the large sector size flag.
The following VOLDB is for an optical disk:
000001086|000E7C03|00000000|00000000|OP003A|op||0|3BB30833|001E4DC0| 0000038A|001E4986|0000046F|00000003|003C915B|0|0||||HSM|||2|
The following table describes the values for each field.
VOLDB Entry Description
Entry field Example value
Description
handle 000001086 File handle. Unique file identifier.
machid 000E7C03 Machine ID. Machine identifier of the VSM server.
lock 00000000 Process ID (pid) of the locking process.
Chapter 6, Managing VSM 237
Managing VSM Databases
flags 00000000 Status of entry. Any of the following:
- 00000000 Volume can contain data; not assigned for writing. VSM clears the flags field either when the volume becomes full or when it encounters problems reading from a volume.
- 00000010 Physical volume dead - will not be used. ( migdbrpt output = D)
- 00000020 Volume empty; available for use. ( migdbrpt output = E)
- 00000040 Volume assigned for writing copy. (migdbrpt output = W)
- 00000080 or 00000800 Do not write to this volume. ( migdbrpt output = f)
- 00001020 Volume has no trailer label. (migdbrpt output = T)
- 00002020 Volume needs FORCED label when used. ( migdbrpt output a=F)
- 00002000 Volume corrupted. ( migdbrpt output a= C)
Note VSM does not automatically set the corrupt flag. It must be set by migsetdb.
label OP003A Volume label.
method op Storage method. See server_password.
locationa Mount information.
metric 0 Currently not used.
date 3BB30833 Date the volume was registered.
size 001E4DC0 Size of volume in kilobytes.
reserved 0000038A Number of kilobytes not used on the volume.
inuse 001E4986 Number of kilobytes in use on the volume.
files 0000046F Number of files on the volume.
VOLDB Entry Description
Entry field Example value
Description
238 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing VSM Databases
volset 00000003 Volume set number.
lt_file 003C915B Location of trailer label.
blocks 0 Number of blocks on the volume.
gid 0 Numeric group ID associated with the file.
user Currently reserved.
group Currently reserved.
project_name Currently reserved.
pool_name HSM Volume pool.
server_name Name of server.
server_usera User name on server.
server_passworda 2 If the method field is op or ow, the server_password field is a flag with the following values:
- (blank): 2048 and 4096 sector size not supported.
- 1: block size unknown; supports 2048 / 4096 sector size
- 2: supports 512 block, 2048 / 4096 sector size
- 3: supports 1024 block, 2048 / 4096 sector size
- 4: supports 2048 block, 2048 / 4096 sector size
- 5: supports 4096 block, 4096 sector size
a The migreg command redefines three VOLDB fieldswhen it registers a NetBackup policy as a volume forthe nb method. The location field holds policy_name,the server_user filed holds schedule, and theserver_password field holds client_name.
VOLDB Entry Description
Entry field Example value
Description
Chapter 6, Managing VSM 239
Managing VSM Databases
Work Lists (copydb files)
VSM uses work lists to copy files to secondary storage and to move migrated files between migration levels. The work list file name format is as follows:
hsmname.copydb.method_name.vol_set_number.hint
The following example is for a file on the managed file system named alpha, using the alternative disk (ad) method, with the volume set number 1 and volume set availability of library.
alpha.copydb.ad.1.library
Entries in a copydb file represent files waiting either to be copied from premigration to secondary storage or to be moved from a source migration level to a destination migration level. Each copydb entry contains the following fields:
handle|machid|lock|flags|volset|copied|method|dst_seek|age|size|badness|path|hint|comment|mmlevel|slevel
The following example work list entry represents the original migration of a file to alternate disk:
00001F22|000D2742|00000000|00000000|00000001|00000000|ad||0.00|11|0|%000000000080009400000057000000000000000000000002000001ff00000034,@tiny/kcm/d3/f.c|library|Auto HSM run|00000001|00000000|
The following table describes the value for each entry.
Work List (copydb) Entry Description
Entry field Example value Description
handle 00001F22 File handle associated with the file.
machid 000D2742 Machine ID associated with the file.
lock 00000000 pid of the process that has this entry locked.
flags 00000000 Status of the file. Any of the following:
- 00000000: If copied=0, file has not been copied/moved. If copied=1, copy/move complete.
- 00000100 Copy/move operation failed.
volset 00000001 Volume set number associated with the file.
copied 00000000 Clear until the copy or move operation is complete; then 1.
240 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing VSM Databases
Destination Volume Database (DVDB)
As VSM finishes copying migrated files to secondary storage, it creates temporary FHDB entries in a DVDB file. When all files are copied, VSM merges the DVDB entries into the FHDB and deletes the DVDB file.
You seldom see DVDB files. However, if a problem prevents VSM from merging all temporary entries into the FHDB, the DVDB file is left in the database directory. In this case, no data is lost. To complete the unfinished copy and merge processes, run migrc -R before you delete the DVDB file.
method ad Storage method associated with the file.
dst_seek Currently not used.
age 0.00 Age weight associated with the file.
size 11 Size weight associated with the file.
threshold 0 Free Space threshold associated with the file.
path %000000000080009400000057000000000000000000000002000001ff00000034,@tiny/kcm/d3/f.c
Path name associated with the file. Possible formats follow:
- % indicates that a DMAPI handle follows
- @ indicates that a safe path follows (a safe path has any special characters replaced as necessary to make the path UNIX-readable).
- If the first character is % and the next nonnumeric characters are ,@ the path is a DMAPI handle followed by a safe path.
hint library Volume set availability associated with the file.
comment Auto HSM run Comment associated with the file.
mmlevel 00000001 Destination level associated with the file, 1-8. 1 indicates the Primary copy of the file. 2 indicates the Alternate copy of the file (if configured).
slevel 00000000 Source level associated with the file.
Work List (copydb) Entry Description
Entry field Example value Description
Chapter 6, Managing VSM 241
Managing VSM Databases
FHDB Lock File (FHDB.LK)
The FHDB lock file (FHDB.LK) does not contain any data. It provides a master lock on the FHDB. Most processes use a shared lock on the FHDB. The merge database process uses an exclusive lock. This ensures that the FHDB is not being accessed while it is being sorted and merged.
File Handle Sequence File (FHSEQF)
The file handle sequence file (FHSEQF) contains the 6-digit hexadecimal value that VSM will assign to the next file handle.
Volume Database Lock File (VOLDB.LK)
The VOLDB file (VOLDB.LK) does not contain any data. It provides a master lock on the VOLDB. Most processes use a shared lock on the volume database. The merge database process uses an exclusive lock. This ensures that the VOLDB is not being accessed while it is being sorted and merged.
Volume Sequence File (VOLSEQF)
The volume sequence file (VOLSEQF) contains the 6-digit hexadecimal value that VSM assigns to the next volume ID (handle).
Next-Volume-Set Files (NEXTVOLM1...NEXTVOLM8)
The NEXTVOLM1 file contains the stripe number of the volume set that VSM will select on the next migration to a volume for the Primary copy. The NEXTVOLM2 file contains the stripe number of the volume set that VSM selects on the next migration to a volume for the Alternate copy. The remaining files, NEXTVOLM3 through NEXTVOLM8, contain the number of the volume set to use for moving a migrated file to Primary Level: 3 through Alternate Level: 8, respectively.
The migsweep.site and migsweepm.site files
The migsweep.site script lets you intercept standard VSM migsweep processing if you want to use something other than the default VSM threshold or purge threshold calculation. The same site-specified threshold formula applies to both the selection of migration candidates and the deletion of purge candidates already migrated. This intercept calls migsweep.site for each file that meets minimum age and size parameters. The input to migsweep.site is one parameter in the following format:
file_name|age_in_days|size_in_kilobytes|current_threshold
242 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Managing VSM Databases
Note The filename is not a safe path name as used in the FNDB.
The script must echo a true false migration flag to stdout. Files are migrated if the output is 0 and not migrated if the output is anything else.
The migsweep.site file can be any type of program or script.
The migsweepm.site is very much like the migsweep.site file, except that it lets you intercept standard migsweepm processing if you want to use something other than the default move_threshold calculation. This intercept calls migsweepm.site for each file that meets minimum move_age and move_size parameters. The input to migsweepm.site is one parameter in the following format:
file_name|age_in_days|size_in_kilobytes|current_threshold|method|level
Note The filename is not a safe path name as used in the FNDB.
The script must echo a true false migration flag to stdout. Files are moved if the output is 0 and not moved if the output is anything else.
The migsweepm.site file can be any type of program or script.
migconf
The migconf file is the configuration file containing migration criteria for the file systems using this database. It is created when you configure VSM.
Note It is not best practice to edit the migconf file directly, because it can introduce errors that produce unpredictable results. You should use VSM-Java to edit your configuration. If you choose to edit migconf, however, do not do so while VSM-Java or migrd is active.
Inode to Handle File (IHAND)
The hsmname.IHAND file contains inode and handle information about migrated files. See “Administering Inode-to-Handle (IHAND) Files” on page 198 for a detailed description.
FLUSH
The hsmname.FLUSH file controls how often VSM writes tape marks during file migration. See “Performance Tuning with Tape Marks” on page 229 for more information.
Chapter 6, Managing VSM 243
Solving Problems
ID_LABEL Databases on a Remote Volume Server The ID_LABEL files exist on remote volume servers that have ft volumes. Each file system that is registered as an ft volume has an ID_LABEL file that contains a single line of text identifying the label and the client name for the VSM server. When you register the ft volume using the migreg command, the file and label are created.
For example, for the managed file system is named hsmftvol1, the migreg command creates the /hsmftvol1/ID_LABEL file.
If you register the volume to the server named kiran and use the label kiranft1, the ID_LABEL file entry is kiran:kiranft1.
When the VSM server attempts to access the file system for migration and cache operations, it uses the contents of the ID_LABEL file to verify that the file system is registered to have ft volumes on that VSM server and only that server. Multiple registrations are not permitted.
Solving ProblemsThis section discusses actions you can take to solve problems with VSM operations at your site.
Viewing Log FilesThe first step in resolving VSM problems is to check the log files. The messages in the logs usually contain information that points you to a solution. In particular, look for any instances of ERROR or WARNING.
244 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
▼ To view the global log file for the VSM server
1. Select Actions > Server > View Log. You will see a screen like the one in the following figure.
VSM Global Log File View
▼ To view the VSM log file for a managed file system, do the following:
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the display of the hierarchy. Highlight the managed file system that contains the log file you want to view.
2. Select Actions > Filesystem > View Log. You will see a screen like the one in the following figure.
Chapter 6, Managing VSM 245
Solving Problems
Managed File System Log File View
Viewing Errors and Warnings
You may choose to see only certain messages that appear in the log file pane.
If you click the checkbox next to Show only errors and warnings, you will see only errors and warnings.
Automatic Update
You can select Automatic Update to continuously update the display with the latest information in the log file.
Searching Log Files
You can search the log file by using the Search button.
246 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
▼ To look for specific messages or strings
1. Click the Search button. The Search Log Messages dialog appears. You will see a screen like the one in the following figure.
Searching in the Global Log File View
2. Type the string for which you want to search.
3. To continue to see all messages and highlight the specified string in each message, click Search.
4. To filter out any messages that do not contain the string, click the checkbox next to Filter messages and click Search.
5. To make the search case-insensitive, click the checkbox next to Ignore Case and click Search.
Note The command-line equivalent for viewing error and warning messages in log files is the migchecklog command.
Managing LogsVSM logs can require management if they become too large or too verbose for your needs.
Chapter 6, Managing VSM 247
Solving Problems
Setting the Logging Level
If you need to increase or decrease the amount of information your log files record, you can change how verbose the logs are.
▼ To set logging levels
1. Select Actions > Server > Set Logging Level. A confirmation dialog will appear.
Values can be from 1 to 8; the default value is 3. The higher the number, the more verbose the logging is.
2. Change the logging level as you prefer and click OK.
Making Log Files Smaller
Occasionally, VSM logs accumulate too much data. If this should happen, you can use the mignewlog command to do the following:
◆ Truncate the desired log file.
◆ Copy the desired log to another file before truncating it. This option is useful if you want to start a fresh log file but need a record of previous messages.
VSM recreates a new log file for the first log message that occurs. The copy option is useful if you want to start with a fresh log file, but need a record of previous log messages.
▼ To schedule the creation of a new log file
1. To activate the Scheduling tool interface, select Actions > Schedule from the Administration dialog.
2. From the Programs pane, select mignewlog and click New Schedule from the Administration dialog.
3. Set up the schedule for creating new logs by following the procedures in “Configuring Schedule Settings” on page 176.
The command-line equivalent is mignewlog hsmname.
Creating the VSM-Java Log
You can create a log for the VSM-Java request daemon with the path /usr/openv/hsm/logs/migrd.log.
248 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
If this path exists before you start migrd, VSM will log information to it. You do not need to take any other action to activate migrd logging. However, if you do not create the file before you start migrd, you must stop migrd and restart it in order for VSM to start logging information to migrd.log.
The log file is never created by VSM; you must always create it. After you start migrd logging, monitor the migrd.log file size to prevent over filling the /usr file system.
Changing VSM StatesIf the VSM server manages more than one file system, you can perform maintenance on one while the others remain Active.
▼ To change VSM states
1. In the Left Pane of the VSM-Java Administration dialog, click the + signs to expand the display of the hierarchy. Highlight the managed file system for which you want to change the state.
2. To change the state of a file system from Active to Maintenance, select Actions > Filesystem > Set State > Maintenance. A confirmation dialog will appear; click OK.
3. The Bottom Pane will show that VSM-Java has changed the state. The Right Pane shows the changed state also; the Status column shows that the state changes to Maintenance,
4. To change the state of a file system from Maintenance to Active, select Actions > Filesystem > Set State> Active. A confirmation dialog will appear; click OK.
5. The Bottom Pane will show that the VSM-Java has changed the state back to Active.
The command-line equivalent for changing VSM states is the migVMSstate command.
Media and Database Information and ReportsYou can obtain reports on VSM media and databases.
Chapter 6, Managing VSM 249
Solving Problems
To obtain a volume scan report in VSM-Java, expand the hierarchy in the Left Pane, highlight a stripe, and then highlight the volume in the Right Pane. Select Actions > Volume > Scan.
To obtain a database report in VSM-Java, expand the hierarchy in the Left Pane, highlight a file system, and select Actions > Filesystem > Check DB Consistency for Filesystem.
The following table lists the commands used to obtain for informational reports. Man pages have details on command syntax and use.
Commands for Media and Database Reports
Command Description
Volume Scan Reports include data about the volume as a whole (for example, total capacity) and about individual granules on each volume (for example, granule size). You can use the information to resolve inconsistencies in the VSM databases.
migtscan Provides information on tape volumes (ct, mt or dt method), including data about the volume as a whole and about granules on each volume
migopscan Provides information on optical disk volumes (op or ow method)
migadscan Provides information on alternate magnetic disk volumes (ad method)
migftscan Provides information on remote volumes (ft method)
mignbscan Provides information on NetBackup volumes (nb method)
Migration Database Reports include information on files and volumes. They can, for example, list all the files on all volumes in a specific volume set or specific file handle or file path.
migdbrpt Provides information on files and volumes
Volume Usage Reports include information to help you determine when to consolidate volumes.
miggetvol Lists volumes, sorted by method name, in ascending order of percentage used
Global Configuration Reports include data about a specific managed file system, such as displaying the database path and file systems.
migdbdir Displays information about a specific VSM file system.
250 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
Database ProblemsLike any other file, the VSM databases are susceptible to errors due to system crashes or premature termination of programs that lock and unlock database entries.
Caution The FHDB, FNDB, and VOLDB are text files that you can view and modify with a text editor. However, before modifying any VSM database, be sure to stop the VSM daemons and any VSM processes that are running.
Fixing FHDB Problems
Symptoms that indicate problems with the FHDB follow:
◆ Log files report that VSM processes wait indefinitely for FHDB locks
◆ Files with file handles are not in the FHDB
◆ User-deleted files still have active entries in the FHDB
◆ A migdbcheck command indicates inconsistencies in the managed file system
▼ To diagnose problem conditions in an FHDB
Note The man pages for commands used in the following steps include detailed syntax and usage information.
1. Change the state for the managed file system to Maintenance.
2. Clear all locks and complete any interrupted migrations in VSM-Java by highlighting the managed file system in the Left Pane and selecting Actions > Filesystem > Clear Old Locks.
Wait for the job shown in the Bottom Pane to complete. After it is done, select Actions > Filesystem > Restart Migrations and Moves for Filesystem
Alternatively, you can run the following command:
# migrc -LR hsmname
3. Verify consistency between the FHDB and the managed file system in VSM-Java by highlighting the managed file system in the Left Pane and selecting Actions > Filesystem > Check DB Consistency for Filesystem
Alternatively, you can run the following command:
# migdbcheck hsmname
Either action checks the following:
Chapter 6, Managing VSM 251
Solving Problems
- All migrated files on the specified managed file systems have an FHDB entry.
- The FHDB contains entries only for files that exist in the managed file system.
Note Repairing a managed file system requires thorough knowledge of VSM. Do not attempt it unless you are aware of the consequences of running the necessary commands.
VSM creates numerous output files in /tmp related to migdbcheck. These files have the format /tmp/migdbcheck-*. You must review each output file and take appropriate action before repairing the file system by running the migdbcheck -r hsmname command. You do not have to run migdbcheck -r under normal conditions.
4. Verify consistency between the media and the FHDB by running the following command:
# mediacheck hsmname
This command verifies that files recorded on the media also have entries in the FHDB.
5. If you find problems during step 3 or 4, correct them as described in “Customizing Startup” on page 194.
6. Change the state for the managed file system to Active.
Clearing FHDB Locks
VSM processes maintain locks in the VSM databases. If a process fails, it can leave a lock set and delay processes that are waiting for the locks to clear.
▼ To clear database locks
1. Terminate any processes hung waiting on a database lock in VSM-Java by highlighting the managed file system in the Left Pane and selecting Actions > Filesystem > Set State > Maintenance. Wait for the job shown in the Bottom Pane to complete.
Alternatively, you can run the following command, which will terminate the processes, but leave the managed file system in Idle state:
# migVSMshutdown hsmname
2. Clear the locks:
252 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
- Ensure that the managed file system is in Maintenance state and select Actions > Filesystem > Clear Old Locks. Wait for the job shown in the Bottom Pane to complete.
Alternatively, you can run the following command:
# migrc -L hsmname
3. Select Actions > Filesystem > Set State > Active.
Fixing the Volume Database
VSM records all its volumes in the VSM volume database (VOLDB) and updates VOLDB entries as it uses volumes for migration. Each VOLDB entry shows volume status, used space, and free space available in the volume.
VSM keeps the FHDB and VOLDB synchronized. However, a system crash or other malfunction can cause empty volume database entries or FHDB entries that have no corresponding entry in the volume database. In either case, VSM cannot cache the affected files or granules from the volume and must use the Alternate copy for caching (if one exists).
▼ To diagnose problems with the volume database
1. In VSM-Java, highlight the managed file system that has the problem in the Left Pane and select Actions > Set State > Maintenance. Wait for the job shown in the Bottom Pane to complete.
2. To ensure no locks are set, select Actions > Filesystem > Clear Old Locks.
Alternatively, you can run the following command:
# migrc -L hsmname
3. To ensure that there are no premigrated files, select Actions > Filesystem > Batch Purge.
Alternatively, you can run the following command:
# mignospace -i hsmname
4. To check for consistency among the VSM databases, select Actions > Filesystem > Check DB Consistency for Filesystem.
Alternatively, you can run the following command:
# migdbcheck hsmname
Chapter 6, Managing VSM 253
Solving Problems
5. If problems are found in step 4, correct them as described in “Customizing Startup” on page 194.
6. Change the VSM state back to Active.
Recovering File Handle and Volume Databases
Restoring VSM databases involves steps that can cause problems for VSM operations. Proceed with caution and read the entire directions before you start.
Caution Do not restore the hsmname.IHAND file when you restore the other databases.
Problems Resulting from Restoring an Non-synchronized VOLDB
Restoring a VOLDB that is not synchronized with its managed file system can cause the following problems:
◆ Loss of any volumes that were registered after the last backup.
◆ If a tape or an optical (ow) volume is written after the backup, the restored VOLDB will not be able to migrate to that volume.
◆ If an ft volume is written after the backup, the restored VOLDB will not have the correct available space for the volume.
Caution If you do not restore the FHSEQF file, you may re-use existing file handles.
Critical Notes about VSM Database Recovery
The following operational points are extremely important in database recovery:
◆ Because recovery of your VSM databases can be a complex process, you should review it with VERITAS customer support before you attempt it.
◆ Because VSM databases are dynamic, the database directory (dwpath/database) must be part of your nightly backup. Ensure that you back up the entire directory structure; VSM stores a number of critical files in various places. Nightly backups will save you valuable rebuild time should you need to recover your databases.
The following procedure provides a basic outline of a database recovery. This example uses a backup copy of the database directory. There are alternative methods of restoring your databases if no backups are available.
254 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
▼ To recover a lost database
1. Shutdown VSM completely for the managed file systems that need to be restored:
# /usr/openv/hsm/bin/migVSMshutdown hsmname
2. If possible, rename the current database directory (dwpath/database) before restoring the backup image. The database files (FHDB, VOLDB, FNDB, FHSEQF, and VOLSEQF) may all be required for review during the restore/rebuild of the database directory.
3. Restore the databases from the latest backup at the dwpath/database level. Check and reconcile each file in the restored directory against the original database files.
Under certain circumstances, a manual rebuild of the database may be required. To do this, you scan the VSM storage volumes as needed (as described in “Commands for Media and Database Reports” on page 250). Contact VERITAS Customer Support any time you are attempting to rebuild your VSM databases.
4. After you have rebuilt databases, rebuild the .IHAND file as described in the rebuild_ihand(1M) man page. Read the man page before you rebuild the .IHAND file.
5. Before you attempt further migration, run migdbcheck complete a file system consistency check on the VSM managed file system. Read the migdbcheck(1M) before you run the command.
Cannot Find Next File Handle
If the FHSEQF file is lost, VSM is unable to assign file handles and starts logging errors in the /tmp/hsm.log file.
To correct the problem, check the end of the FHDB file to determine the last file handle. Write a value one larger than that last handle to the FHSEQF file.
The file handles (in hexadecimal format) in the FHDB use uppercase letters while those in the FHSEQF file use lowercase letters.
Restoring Managed File Systems
Note As a precaution, if you need to restore a managed file system, make a copy of the current file system before restoring it.
To back up a damaged or incomplete managed file system and restore it to a previous backup level that is neither damaged nor incomplete, use the following procedures.
Chapter 6, Managing VSM 255
Solving Problems
▼ To back up the current managed file system
1. Ensure that the migd, migrd, and migvold daemons are running and that the managed file system is in Maintenance state.
2. Complete next steps in VSM-Java or from the command line:
For VSM-Java, do the following:
a. In the Left Pane of the VSM-Java Administration dialog, highlight the managed file system.
b. Start the purge operation by migrating all premigrated files. Select Actions > Filesystem > Batch Migrate and confirm your choice. Wait until the Bottom Pane reports that the operation succeeded.
c. Complete the purge operation by deleting all purge candidates. Select Actions > Filesystem > Batch Purge and confirm your choice. Wait until the Bottom Pane reports that the operation succeeded.
To complete the steps from the command line, do the following:
a. Start the purge operation by migrating all premigrated files. Run the following command:
# migbatch hsmname
b. Complete the purge operation by deleting all purge candidates. Run the following command:
# mignospace -i hsmname
3. Back up the current incomplete or damaged file system to tape.
4. Back up the VSM database directory to tape.
▼ To restore an earlier version of a managed file system
1. Change the state of the damaged managed file system you want to restore to Maintenance.
2. Ensure that the migd, migrd, and migvold are running
3. Use mkfs or newfs to create a new file system to which you will restore undamaged migrated files.
256 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
Caution Do not change any configuration file entries.
4. Mount the file system created in step 2.
5. If necessary, restore an undamaged copy of the VSM database directory.
6. If the undamaged copy of the file system you are restoring has an hsmname.IHAND file in the database directory, remove it.
7. Restore the copy of the file system from before the damage occurred. A fairly common error is to restore a copy of the damaged file system, so ensure you have the correct one.
8. If you restore migrated files that were removed from the file system, the FHDB entries for those files are marked as obsolete. To reactivate those entries, use the following command:
# migactivate hsmname
9. Start the VSM daemons by running startmigd.
10. To clear locks and remove obsolete and dead database entries, select Actions > Filesystem > Clear Old Locks in VSM-Java or run the following command:
# migrc -L -O hsmname
11. Change the VSM state back to Active.
Extending Managed File SystemsYou can expand the size of an existing file system by increasing the number of available inodes with operating systems commands.
Caution Stop all activity on the managed file system before extending it.
If you add inodes, the hsmname.IHAND file will grow as needed to accommodate the larger file system.
File and Migration ProblemsThe following sections provide possible solutions for various problems with VSM managed files.
Chapter 6, Managing VSM 257
Solving Problems
Reloading Deleted Files
If a purged file is deleted, it is possible to reload it from the VSM volume, providing the volume has not been consolidated or recycled since the file was deleted.
▼ To reload migrated files that have been deleted
1. Check the FNDB to find the file handle that VSM assigned to the file.
For example, assume that you are trying to reload file /home2/jdoe/tprog/proga from the server greek2me. This file is under the management of iota and the machine ID is 3E8 (1000 decimal). You find the following FNBD entry for proga:
000012D2|000E03E8|00000000|00000000|00000463|00000001|000001A4| Auto HSM run |||@home2/jdoe/tprog/proga|
The first field is the file handle (000012D2) and the second is the machine ID (000003E8)
There must also be at least one FHDB entry for this file. It must not be a dk method entry (an online copy) or a pl method entry (a placeholder). FHDB entries do not contain the file path name. The FHDB entries for this file will have the same file handle and machine ID in the first two fields:
000012D2|000E03E8|00000000|00001048|00000000|00028000|00000000|00028000|00000001|||3B17DF57|3B17DF7C|00000000|ct|||||l|59 0 00002235|00000000|||00000000|00000001|
This entry represents a copy using the ct method (field 15, shown in bold type face).
2. Use the examples in the migreconstruct man page to help you reconstruct deleted migrated files.
After migreconstruct completes, try to cache the file.
3. If you cannot cache the file after running migreconstruct, do the following:
4. Restore files by running the following:
# migin hsmname file_system machine_ID file_handle
For example, using the file handle and machine ID values from step 1:
# migin hsm2 /home2 000003e8 000012d2
5. Use the migactivate command to make sure the FHDB entries are active. This can be a slow process.
Note A file restored in this manner is no longer considered a migrated file. The command fls -l filename will show no VSM machine ID or file handle.
258 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Solving Problems
Restarting Migrations
If VSM fails during migration or of migration does not finish (for example, if there were not enough tapes), first correct cause of the system failure. After the problem is corrected, complete the following procedure.
▼ To clear all locks and complete any interrupted migrations
1. Ensure the managed file system is in Maintenance state. If it is not, select Actions >Filesystem > Set State > Maintenance or run migVSMstate -s maintenance hsmname.
2. Restart the migration process in VSM-Java by highlightingthe managed file system in the Left Pane.
a. Select Actions > Filesystem > Restart Migrations and Moves for Filesystem
Alternatively, you can run the following commands:
a. Clear old locks by running migrc -L hsmname
b. Start the migvold daemon by running startmigd -v
c. Recover migrations by running migrc -RM hsmname
3. Change the managed file system state to Active.
Migrating, Purging, or Accessing Files Does Not Occur
If VSM does not automatically purge files when free space percentage is below the high water mark percentage, check that the migd migration daemon and Media Manager ltid device manager daemon are both running.
If either daemon is stopped, the automatic removal or migration cannot occur.
If users are unable to read or delete migrated files, the migd daemon may not be running.
▼ To start the daemons
1. Depending on what storage method you are using, do the following:
a. For tape or optical storage, start the device manager daemon by run the following command:
# /usr/openv/volmgr/bin/ltid
Chapter 6, Managing VSM 259
Solving Problems
b. For ft remote volumes, ensure that the VSM server is able to access the file system on the remote volume server.
2. To start migd, do one of the following:
- In VSM-Java, select Actions > Server > Start Daemons
- From the command line, run the following command:
# startmigd -m
3. If necessary, change the VSM state to Active. In VSM-Java, select Actions >Filesystem > Set State > Active or run migVSMstate -s active hsmname.
Releasing VSM Tape Requests
If a tape process aborts leaving a tape mounted, unmount the tape.
▼ To release VSM tape requests
1. Check the dwpath/workdir directory for the name of the requested tape file.
2. Run the tpunmount command on the tape file
Having No Volumes Available
If there are no available volumes at the time of a scheduled migbatch run, the log file for the managed file system file indicates the problem.
Having no volumes available stops the migbatch process.
▼ To restart file migration
1. Register additional media. Tapes can automatically be registered from a free pool. The migreg man page provides information on registering media for VSM.
2. Ensure that there are no premigrated files in VSM-Java by selecting Actions > Filesystem > Batch Migrate and confirm your choice.
Alternatively, you can run the following command:
# migbatch hsmname
260 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Man Pages
A This appendix contains man pages for VSM commands. If you have the man pages installed, you can access any of these command descriptions online by using the man command.The man pages are shown in alphabetical order.
261
fls(1)
fls(1)
NAME
fls - list contents of a directory and indicate whether files are migrated
SYNOPSIS
/usr/openv/hsm/bin/fls [-l]
DESCRIPTION
The fls command is a version of the standard ls command, modified to work with VSM. It supports most of the options supported by the standard ls command.
The fls command lets you list the contents of your directories, and, when used with the -l option, indicates which of those files have been migrated or purged.
For example, assume you have a migrated file named tproga in your current working directory, and you run the following command:
# /usr/openv/hsm/bin/fls -l tproga
The response is as follows:
mrwxr-xr-- 1 root 23 Nov 29 14:30 tproga [000003e8 0000100e]
The m in the mode bit field indicates that the file has been migrated. The numbers to the right of the file name indicate the machine ID and file handle, respectively.
If tproga has also been purged, the fls command output is as follows:
mrwxr-xr-t 1 root 23 Nov 29 14:40 tproga [000003e8 0000100e]
The t in the mode bit field indicates that the file has been purged and no longer resides on disk. The t flag is the UNIX “sticky” bit. It is visible using the standard ls command. If the VSM server exports managed file systems via NFS, the sticky bit on the NFS client can indicate that the file is purged and make take some time to access.
If tproga has been cached but not been changed, the fls command output is as follows:
-rwxr-xr-- 1 root 23 Nov 29 15:30 tproga [000003e8 0000100e]
The m and the t in the mode bit field are removed to indicate that the file has been cached back to disk. The machine ID and the file handle are displayed.
If tproga has been cached and also changed, it is no longer a migrated file. The fls command output is as follows:
-rwxr-xr-- 1 root 23 Nov 29 15:40 tproga
The machine ID and file handle are removed to indicate that the cached file has been changed, which renders the migrated copy in secondary storage invalid.
262 VERITAS Storage Migrator System Administrator’s Guide for UNIX
fls(1)
CAVEATS
◆ When fls is run with the -F option, it causes directories to be marked with a trailing /, sockets with a trailing =, symbolic links with a trailing @, executable files with a trailing *, and migrated files with a trailing %. The fls command does not mark fifos.
◆ fls has other options corresponding to those of the standard ls command, but those options have not been tested.
SEE ALSO
ls(1), migloc(1)
Appendix A, Man Pages 263
gethsm(1)
gethsm(1)
NAME
gethsm - display the hsmname for all managed file systems or for a specified file or directory
SYNOPSIS
/usr/openv/hsm/bin/gethsm [filename | dirname]
DESCRIPTION
The gethsm command identifies and displays the hsmname assigned to managed file system containing the file or directory specified in the command. If no file or directory is specified, gethsm identifies and displays the hsmnames for all managed file systems.
Output is displayed to standard output. Error messages go to standard error.
This command may be run without regard to whether the migd migration daemon is running, but the VSM state must be Active if an option is specified.
This command is intended for both administrators and users.
OPTIONS
filename The full pathname of the file for which to display the hsmname.
dirname The full pathname of the directory for which to display the hsmname.
EXAMPLES
To display all managed file systems, type the command without options:
# gethsmalpha beta gamma delta
To display the managed file system for a particular file or directory, include the filename or dirname option in the command:
# gethsm /hsmrel/dir/subdir/filenamealpha
Error messages are returned if the filename or dirname are not valid:
In the following example, /usr is not a managed file system (/usr should not be a managed file system because of its contents).
# gethsm /usrERROR: Path not configured for VSM.
264 VERITAS Storage Migrator System Administrator’s Guide for UNIX
gethsm(1)
In the following example, the beta file system state is Inactive, and gethsm cannot obtain information.
# gethsm /beta/tom/file1Error: hsmname is inactive.
FILESdwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
VSM(1M)
Appendix A, Man Pages 265
HSMKiller(1M)
HSMKiller(1M)
NAME
HSMKiller - end active VSM processes
SYNOPSIS
/usr/openv/hsm/bin/HSMKiller [hsmname]...
DESCRIPTION
The HSMKiller command ends VSM processes and unmounts secondary storage volumes that are left mounted by any ended processes.
Note Always shutdown VSM processes with migVSMshutdown. Only if migVSMshutdown fails should you use HSMKiller.
If one or more hsmnames are specified, HSMKiller ends all active processes listed in HSMKiller.kill_list for the specified hsmnames, but not the daemons migd and migvold. The HSMKiller.kill_list is located in the admincmd directory of /usr/openv/hsm/bin.
The HSMKiller also unmounts secondary storage volumes left mounted by any ended process, and signals migvold to clean up the mount table.
If no hsmname is specified, HSMKiller ends all active processes listed in HSMKiller.kill_list and HSMKiller.global.kill_list, located in the admincmd directory of /usr/openv/hsm/bin. It also ends the daemons migd and migvold, unmounts all secondary storage volumes, and removes the VSM mount table.
Use stopmigd if you want to terminate just the VSM daemons migd and migvold.
Note After running HSMKiller, run migrc to clean up any locks left set by the ended processes.
The migcleanup command should be used to see if there are left over DMAPI sessions (migcleanup -e). Left over DMAPI sessions should be cleaned up with the migcleanup -k command.
A tape volume that was being written when ended by HSMKiller, will have the T flag set in its VOLDB entry. (The T flag can be seen with the migdbrpt command. The flag means that a trailer label is needed on the tape volume.) The command /usr/openv/hsm/bin/goodies/migadd_trailer.sh should be used to add trailer labels to such volumes.
266 VERITAS Storage Migrator System Administrator’s Guide for UNIX
HSMKiller(1M)
Note Any process that cannot be terminated by a kill-9 command after three attempts remains active, and a failure message is placed in the global log file.
OPTIONS
hsmname Configured VSM name for the managed file system for which you want to end processes. More than one hsmname may be included on the command line. The default is all hsmnames if none are specified.
CAVEATS
◆ HSMKiller searches for processes to end which are executing using the full pathname for VSM binaries, /usr/openv/hsm/bin. All VSM processes which call other VSM processes use this convention. For HSMKiller to work properly, all VSM processes called by customer defined scripts or cron schedules should follow this same convention instead of depending on PATH variables to allow shorthand command names.
◆ Use care either when deleting unused processes from /usr/openv/hsm/bin/admincmd/HSMKiller.kill_list to speed HSMKiller processing or when otherwise editing the two lists. This may result in a less comprehensive termination of active processes.
FILES/usr/openv/hsm/bin/admincmd/HSMKiller.kill_list
HSMKiller kill list
/usr/openv/hsm/bin/admincmd/HSMKiller.global.kill_list
HSMKiller global kill list
SEE ALSO
migVSMshutdown(1M), migVSMstartup(1M), migconfg(1M), migrc(1M), startmigd(1M), stopmigd(1M)
Appendix A, Man Pages 267
ihprint(1M)
ihprint(1M)
NAME
ihprint- print or alter an IHAND (inode-to-handle) file entry
SYNOPSIS
/usr/openv/hsm/bin/ihprint [-m machid] [-h handle] [-f flags] [-c slice] [-d dmhandle] [-H highest] [-I ihandfile] hsmname [inode | pathname]
Caution ihprint is intended only for customer support engineers who are trained in its use--this especially applies to changing the IHAND file. All other users should rely on the rebuild_ihand command to verify and change IHAND entries.
DESCRIPTION
The ihprint command prints the IHAND entry for an inode in a managed file system. If any options are specified, ihprint sets the indicated field of the IHAND entry, prints the new entry to stdout, and updates the IHAND file.
To make changes, the managed file system state must be Active or Maintenance. The file system must be mounted for ihprint to run.
OPTIONS
-m machid Set the machine id field of the appropriate IHAND entry to machid. The value is assumed to be hexadecimal.
-h handle
Set the file handle field of the appropriate IHAND entry to handle. The value is assumed to be hexadecimal.
-f flags Set the flags field of the appropriate IHAND entry to flags. The value is assumed to be hexadecimal.01 reloading
02 removing
04 parital_cache 08 cached, unmodified
10 being cached by migstage
-c slice Set the slice field of the appropriate IHAND entry to slice.
-I ihandfileSpecifies an alternate path to an IHAND file in which an entry is to be modified and/or printed. If ihandfile is specified, hsmname and inode must also be specified and pathname cannot be specified.
268 VERITAS Storage Migrator System Administrator’s Guide for UNIX
ihprint(1M)
hsmname Specifies the hsmname for which an IHAND entry is to be modified and/or printed. If hsmname is specified, inode must also be specified and pathname cannot be specified.
inode Specifies the IHAND entry to be modified and/or printed. If hsmname is specified, inode must also be specified and pathname cannot be specified.
pathname Specifies the pathname of a file for which an IHAND entry is to be modified and/or printed. If pathname is specified, do not specify the hsmname and inode parameters.
-d dmhandle Set the DMAPI handle field of the appropriate IHAND entry to dmhandle. The value is assumed to be hexadecimal.
-H highest Set the highest byte-to-read field of the IHAND entry to highest.
EXAMPLE
The following command and resulting output show how to print the IHAND entry for the inode at /iota/file94:
# ihprint /iota/file94Current IHAND entry for file94:HANDLE MACHID FLAGS SLICE HIGHEST13D2 2C70C0 10 0 0 DMHANDLE-LENGTH DMHANDLE20 00000000400000090000000842042dc00000000000000180000016963000001
The following command and resulting output show how to change the machine ID field of this same IHAND entry to 3E8:
# ihprint -m 3E8 /iota/file94Current IHAND entry for magic:HANDLE MACHID FLAGS SLICE HIGHEST13D2 2C70C0 10 0 0 DMHANDLE-LENGTH DMHANDLE20 00000000400000090000000842042dc00000000000000180000016963000001Modified IHAND entry for file:HANDLE MACHID FLAGS SLICE HIGHEST13D2 3E8 10 0 0DMHANDLE-LENGTH DMHANDLE20 00000000400000090000000842042dc00000000000000180000016963000001
Do you want the IHAND entry reset? [yn] yIHAND entry modified.
Appendix A, Man Pages 269
ihprint(1M)
The following command and resulting output show how to clear the flags field of the IHAND entry for handle 13D4 in managed file system iota:
# ihprint -f 0 iota 13D2Current IHAND entry for iota inode 13:HANDLE MACHID FLAGS SLICE HIGHEST0 0 10 0 0 DMHANDLE-LENGTH DMHANDLE0 Modified IHAND entry for iota inode 13:HANDLE MACHID FLAGS SLICE HIGHEST0 0 0 0 0 DMHANDLE-LENGTH DMHANDLE0 Do you want the IHAND entry reset? [yn] yIHAND entry modified.
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/hsmname.IHAND
Inode-to-handle file for VSM
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
SEE ALSO
rebuild_ihand(1M)
270 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mediacheck(1M)
mediacheck(1M)
NAME
mediacheck - check the media and file handle database (FHDB) for consistency
SYNOPSIS
/usr/openv/hsm/bin/mediacheck hsmname label method
DESCRIPTION
The mediacheck command verifies that all files recorded on the secondary storage media are also recorded in the VSM file handle database (FHDB). The label is scanned (using migadscan, migtscan, migopscan, migftscan, or mignbscan) and compared with the file handle database entries.
You can use the migdbrpt command to display a summary of information from the FHDB. You can use the migdbcheck command to verify consistency between the file system and FHDB and also to verify the consistency between the volume database (VOLDB) and FHDB.
To run this command, the VSM state must be Active or Maintenance.
OPTIONS
hsmname Configured VSM name of the managed file system containing the database files you want to check. This parameter is required.
label Label of the volume that is to be checked.
method Method the label is registered for. The allowed methods are ad, ct, dt, mt, op, ow, ft, and nb.
EXAMPLE
The following example verifies the media on optical disk OP001A, which is registered in the database specified by the configured VSM name alpha.
# mediacheck alpha OP001A op
ERRORS-- FHDB entry 00001098 is locked by 0007700
An entry is locked by the indicated process. Ensure that VSM is not being actively used and the VSM migration daemon (migd) is not running (see stopmigd(1M)). Run migrc to clear any leftover locks. Then, rerun mediacheck.
-- FHDB entry 00001097 is out of order
Appendix A, Man Pages 271
mediacheck(1M)
The FHDB is maintained in sorted order. If an entry is reported out of order, sort the FHDB according to the first two fields of each line.
-- Missing FHDB gran 00001098, offset 1000, file /home/gls/wiggins
A portion of the file recorded on the media is no longer in the FHDB. If the file is still in the active file system, you may have to reconstruct the FHDB entries as described in migdbcheck.
-- Missing FHDB entry for file /home/gls/wiggins
The media contains a file that does not have an entry in the FHDB. If the given file is still in the active file system, you may have to reconstruct the FHDB entries as described in migdbcheck.
-- Missing media granule 00001098, offset 1000, file /home/gls/bird
A portion of the file recorded in the FHDB is no longer on the media. If the file still exists in the active file system, the file data may be lost if you cannot recover it from a backup.
-- No media file for orphan FHDB entry
A file recorded in the FHDB is no longer on the media. If the given file still exists in the active file system, the file data may be lost if you cannot recover it from a backup.
SEE ALSO
VSM(1M), migdbcheck(1M), migadscan(1M), migconfg(1M), migdbrpt(1M), migftscan(1M), mignbscan(1M), migtscan(1M), migopscan(1M), migrc(1M), stopmigd(1M)
272 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migactivate(1M)
migactivate(1M)
NAME
migactivate - activate FHDB entries for files with VSM file handles
SYNOPSIS
/usr/openv/hsm/bin/migactivate [-E loglevel] [-v] hsmname
DESCRIPTION
The migactivate command activates all dead or obsolete file handles in the FHDB for all files in a managed file system that have VSM file handles. migactivate must be run before you use migrc or migmdclean to remove obsolete or dead FHDB entries.
Dead or obsolete file handles result whenever two files share an identical VSM file handle and one file is deleted. For example, if you backup and restore migrated files to an alternate path, and then remove one of these files, you will have a file with an obsolete VSM file handle.
OPTIONS
-E loglevelSets the log level used by migactivate. The numeric value for the log level you want to use for this command; this is used instead of the configured VSM setting. The configured default setting is found in the VSM configuration log file.
Note If the VSM log level is set to 8, migactivate lists all FHDB handles, and assigned inode numbers, of all FHDB handles that were made active.
Note FHDB dk entries are not activated with migactivate.
-v Causes the log messages to also go to STDOUT or STDERR. The default setting is HSMLOG.
hsmname Configured VSM name of the managed file system that you want VSM to process.
EXAMPLE
The following example sets the log level to 8 for migactivate and lists all activated FHDB entries.
# ./migactivate -E 8 -v xistarting migactivate xiINFO: activated FHDB entry 3E8M13A0 inode = 107
Appendix A, Man Pages 273
migactivate(1M)
INFO: activated FHDB entry 3E8M13A1 inode = 108INFO: activated FHDB entry 3E8M13A2 inode = 109 ...INFO: activated FHDB entry 3E8M1402 inode = 205INFO: activated FHDB entry 3E8M1403 inode = 206migactivate complete for xi FHDB problems = 0, FHDB activates = 100
SEE ALSO
VSM(1M), migmdclean(1M), migrc(1M), migconfg(1M)
274 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migadscan(1M)
migadscan(1M)
NAME
migadscan - scan alternate disk volumes under VSM for file granules
SYNOPSIS
/usr/openv/hsm/bin/migadscan -F [-n] [-s] hsmname label mount_point
/usr/openv/hsm/bin/migadscan [-n] [-s] hsmname label
DESCRIPTION
The migadscan command scans an alternate magnetic disk (ad) volume and displays information about the volume as a whole in addition to information about each granule on the volume.
If you specify the -F option, the media can be scanned without a VOLDB entry. You must supply an alternate magnetic disk mount_point with the -F option.
The migadscan command creates three output files: FHDB.label, FNDB.label, and VOLDB.label, in the dwpath/database directory. The structure of these files is the same as the FHDB, FNDB, and VOLDB database files. These files may be used to rebuild the FHDB, FNDB, and VOLDB if they are corrupted or damaged (see migdbcheck(1M)).
You can sort and merge FHDB.label and FNDB.label files for different magnetic disks in order to recreate the FHDB and FNDB. Similarly, you can merge and sort the VOLDB.label files for different magnetic disks to recreate the VOLDB database.
Note When you recreate the VOLDB, you must merge the old and new VOLDB files to include the entry for the dk method.
OPTIONS
-F Force a scan of the volume for VSM granules. This is useful when the volume identity is not in the volume database. This parameter is optional. If omitted, the volume must be registered in the volume database. If specified, mount_point must also be specified.
-n Do not compress the FHDB entries for files found on the volume. When the -n option is used, no FNDB.label file is produced. This option is useful for examining what is actually written on the media. The FHDB.label file produced with the -n option must be run through migfhdbconvert before it can be merged into the real FHDB and FNDB.
Appendix A, Man Pages 275
migadscan(1M)
-s Silently scan the volume and create FHDB.label and VOLDB.label files. Do not display information on stdout.
hsmname Configured VSM name of the managed file system specifying the path to the database files that contain entries for the volume you want to scan.
label Label of the volume you are scanning. This parameter is required. For a force scan, you can specify any name for the label.
mount_point Indicates the mount point for the alternate magnetic disk. Specify mount_point if and only if using the -F option. If using NFS, make sure the file system has been mounted.
CAVEATS
Scanning an alternate magnetic disk volume that contains files that are not VSM granules will produce informative messages such as the following:
<filename> ***Not a Valid Granule*** 10
EXAMPLE
The following example scans alternate magnetic disk volume pjrad1 registered under ad method and displays a list of granule information for files migrated to the volume. Files FHDB.PJRAD1 and VOLDB.PJRAD1 are created in the VSM database directory.
# /usr/openv/hsm/bin/migadscan hsm2 AD0001VOLUME AD0001 registered to HSM Volume Particulars ------------------000E7C00V00001003 AD0001 ad 00050000 00006288 #16Volume Label Found ====> AD0001-------------------------------E7C00M8D.2.0 <=> 00826C00 00200000 Wed Jan 9 17:48:55 2002 /Xa/sv/h1E7C00M8D.1.0 <=> 00826C00 00000000 Wed Jan 9 17:48:55 2002 /Xa/sv/hxE7C00M8D.5.0 <=> 00826C00 00800000 Wed Jan 9 17:48:55 2002 /Xa/sv/hsE7C00M8D.4.0 <=> 00826C00 00600000 Wed Jan 9 17:48:55 2002 /Xa/sv/haE7C00M8D.3.0 <=> 00826C00 00400000 Wed Jan 9 17:48:55 2002 /Xa/sv/h4
Under Volume Particulars you see displayed (in order): volume handle (000E7C00V00001003), volume label (AD0001), method (ad), total capacity of the volume (00050000), total space in use on the volume (00006288), and number of granules on the volume (16).
276 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migadscan(1M)
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database for VSM
dwpath/database/migconf
Configuration file for managed file systems.
dwpath/database/FHDB.label
File handle database for current volume
dwpath/database/FNDB.label
File name database for current volume
dwpath/database/VOLDB.label
Volume database for current volume
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
migdbcheck(1M), migconf(1M), migconfg(1M), migdbrpt(1M), migftscan(1M), migtscan(1M), migopscan(1M)
Appendix A, Man Pages 277
migalter(1M)
migalter(1M)
NAME
migalter - display or alter regions, events, or attributes for a file or managed file system
SYNOPSIS
/usr/openv/hsm/bin/migalter [-F] [-e event]... [-d event]... [pathname | -f filelistpath]
/usr/openv/hsm/bin/migalter [-O] [-r region] [-h handle] [-m machid] [-p slice] [pathname | -f filelistpath]
/usr/openv/hsm/bin/migalter -I [pathname | -f filelistpath]
/usr/openv/hsm/bin/migalter -R [pathname | -f filelistpath]
Caution migalter is intended only for customer support engineers who are trained in its use.
DESCRIPTION
When the used with file pathnames, migalter displays or alters managed regions, displays or enables events, displays or alters DM attributes, or punches a hole.
For managed file systems, migalter displays or alters events or DM attributes.
If no options are specified, migalter displays the enabled events for the managed file system, and the managed regions, DM attributes, file attributes, allocation information and DMAPI handle information for the file. If a file is partially cached, this is noted with the allocation information.
OPTIONS
-F Display or alter enabled events for the managed file system of pathname. Default is display or alter enabled events, managed regions, and DM attributes for the file pathname.The -F option can not be used with -r, -h, -m, -p, or -u.
-e event Add the specified event to the pathname. Valid values for event are as follows:event = CREATE, POSTCREATE, REMOVE, POSTREMOVE, RENAME, POSTRENAME, LINK, POSTLINK, SYMLINK, POSTSYMLINK, DESTROY, NOSPACE, ATTRIBUTE, PREUNMOUNT, UNMOUNT, or NOEVENT.NOEVENT clears all events.Multiple instances are allowed. If both -e and -d are specified, events are added before they are deleted. See Examples.
278 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migalter(1M)
-d event Delete the specified event from the pathname. Valid values for event are as follows:event = CREATE, POSTCREATE, REMOVE, POSTREMOVE, RENAME, POSTRENAME, LINK, POSTLINK, SYMLINK, POSTSYMLINK, DESTROY, NOSPACE, ATTRIBUTE, PREUNMOUNT, UNMOUNT, or NOEVENT.Multiple instances are allowed. If both -e and -d are specified, events are added before they are deleted. See Examples.
-O Specifies that migalter should use the rules for interpreting the DMAPI attribute that it used before VSM version 4.5. If you use -O, migalter will regard a file that is migrated by VSM version 4.5 as a cached file.
-r region Add the managed region to the file pathname. Valid values for region are as follows:region = READ, WRITE, TRUNCATE, NOREGION, MIGRATED, PURGED, or CACHED
NOREGION clears all regionsMIGRATED sets WRITE, TRUNCATEPURGED sets READ, WRITE, TRUNCATECACHED sets WRITE, TRUNCATENOREGION, MIGRATED, PURGED, and CACHED all change the DM attributes for the pathname
region offset and size are always set to 0; thus, the region applies to the whole file
Note Before VSM version 4.5, MIGRATED set READ, WRITE, TRUNCATE events.
-h handle Set the file handle field of the DM attributes to handle for the file pathname. The value is assumed to be hexadecimal.
-m machid Set the machid field of the DM attributes to machid for the file pathname. The value is assumed to be hexadecimal.
-p slice Punch a hole in the file pathname from the offset slice to the end of the file, where slice is specified in bytes. The value is assumed to be decimal.
-I Initialize DM attributes on the managed file system or file pathname. You must first mount the file system before running migalter -I. Once migalter -I is run, you must have the migd migration daemon running to mount the manged file system.The -I option can not be specified with any other option. It is only available on Solaris and HP-UX implementations.
Appendix A, Man Pages 279
migalter(1M)
-R Remove DM attributes from the managed file system or file pathname. You must first mount the file system before running migalter -R. Once migalter -R is run, you do not have to have the migd migration daemon running to mount the managed file system.The -R option can not be specified with any other option. It is only available on Solaris and HP-UX implementations.
-f filelistpath
Specifies the name of a file that contains a list of pathnames, one per line, that you want to alter.
pathname Specifies the pathname of a file or managed file system to which the options are applied.
EXAMPLE
A single command statement can both add and delete events. The following example first adds the REMOVE event and then deletes the DESTROY event for the managed file system kappa:
# migalter -F -e REMOVE -d DESTROY /kappa
The following example clears the regions for the file /omega/file6:
# migalter -r NOREGION /omega/file6
The following example initializes DM attributes on managed file system theta and prevents it from being mounted unless the migd migration daemon is running:
# migalter -I /theta
The following example removes DM attributes from managed file system theta and allows it to be mounted whether or not the migd migration daemon is running:
# migalter -R /theta
The following example displays the enabled events for file system sigma, and the managed regions, DM attributes, file attributes, allocation information and DMAPI handle information for the file /sigma/projects/file1:
# migalter /sigma/projects/file1
SEE ALSO
migcleanup(1M)
280 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migbatch(1M)
migbatch(1M)
NAME
migbatch - control migration of files from file system to secondary storage
SYNOPSIS
/usr/openv/hsm/bin/migbatch [hsmname] | [file_system]
DESCRIPTION
The migbatch command controls the migration of files to secondary storage. It can sweep all file systems, the file system indicated by hsmname, or the specified file_system. A migbatch command searches for files that meet specified age and size criteria. A file in a managed file system is considered a migration candidate if all of the following are true:
◆ It is a regular UNIX file (for example, not a device file or symbolic link). The nb method does not support asterisk, backslash, parenthesis, question mark, right curly brace or square bracket characters in file names.
◆ The file’s computed threshold value is greater than or equal to the migration threshold value specified in migconf.
◆ It is not already migrated.
◆ The pathname of the file does not appear either in the global stop file or in a local stop file, .migstop, unless the stop file is overridden. See CAVEATS.
◆ The file does not reside in nonmanaged file system, even if that file system is mounted in a VSM-managed directory.
◆ The full pathname length is under 1024 characters.
If the migconf file specifies a low-water mark, migbatch stops selecting files when this is reached. Otherwise, all files that meet the selection criteria are selected. This could result in migrating almost every regular file from the managed file system.
VSM then premigrates the data for each selected file. The site configure the Primary Level (an optionally the Alternate Level) to specify the type of media, volume set, volume set availability, and volume pool to which the premigrated files are written. VSM then writes the specified number of copies of the file to the specified secondary storage media.
After files are copied to secondary storage, files may be purged by mignospace to make disk space available. mignospace starts under any of the following conditions:
◆ The migd migration daemon periodically checks the high-water mark threshold and starts mignospace if the threshold is exceeded.
Appendix A, Man Pages 281
migbatch(1M)
◆ The command responds to preset schedule that you established using the VSM Scheduling tool.
◆ You execute mignospace from the system prompt.
◆ You execute miglow from the system prompt.
◆ You start migration in VSM-Java.
This command may be run without regard to whether the migd migration daemon is running, but the VSM state must be Active.
OPTIONS
hsmname Configured VSM name of the managed file system that specifies the file system you want migbatch to process.
file_system Full path name of the file system on which to initiate migration.
If you do not specify either file_system or hsmname, then migbatch reads all configuration files and sweeps all file systems.
CAVEATS
◆ The migration process only migrates regular file data. It is not a substitute for a backup process which copies all directories and files. You must backup your system, including VSM databases, so you will be able to restore the system to that level following a catastrophic failure or loss of files.
◆ If you use cartridge tapes or optical platters, the ltid daemon must be running. If the ft method name is used, the remote file system must be available.
◆ If VSM transfers files greater than 2 GB with the ft method, the remote volume server must be configured to accept and process files of this size.
◆ Migration waits for caching operations to complete when migrating and caching from the same tape or optical volume. Migration and caching operations can occur in parallel for the ft and ad method names.
◆ The .migrate and .migstop files most local to the listed file override more remote control files in the directory tree. Local control files override global control files if the same file or directory is listed in both. If the same file is listed in both a .migrate file and a .migstop file at the same level, the .migrate control file overrides the .migstop file.
◆ Some processes spawned by migbatch create large temporary files and there may not be enough space in the /tmp directory to store these files. You can avoid this problem by defining the environment variable TMPDIR to contain the pathname of a
282 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migbatch(1M)
directory in a file system that has sufficient space available. Then, if the process checks TMPDIR, it creates any temporary files in the specified directory instead of in the default /tmp.
EXAMPLES
◆ The following example starts the migration for hsmname alpha.
# migbatch alpha
◆ The following example starts the migration for all file systems on the VSM server:
# migbatch
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
/usr/var/openv/hsm/database/migrate
Global migrate file for VSM
/usr/var/openv/hsm/database/migstop
Global stop file for VSM
SEE ALSO
VSM(1M), migconf(1M), migconfg(1M), miglow(1M), mignospace(1M), migreg(1M), migrc(1M), startmigd(1M), stopmigd(1M)
Appendix A, Man Pages 283
migcat(1)
migcat(1)
NAME
migcat - concatenate and display migrated files without caching them to disk
SYNOPSIS
/usr/openv/hsm/bin/migcat file [file]...
DESCRIPTION
The migcat command is a modified version of the standard UNIX cat command.
The migcat command sends the migrated file or files to stdout one granule at a time, and does not cache the file to disk. The user does not have to wait until the entire file is cached before reading it.
The standard UNIX cat command caches the entire file data to disk before the user can read it. This delay is reduced by using migcat instead of cat, particularly for large files; however, the I/O transfer rate may be lower for a migcat than for a normal cache operation.
This command may be run without regard to whether the migd migration daemon is running, but the VSM state must be Active.
This command is intended for both administrators and users.
OPTIONS
file Specifies the file or list of files to concatenate. Wildcards are recognized. This parameter is required.
CAVEATS
◆ Files migrated with method ft or nb will be cached.
Note The nb method will not be supported after the VSM 4.5 release.
EXAMPLE
The following command reads the migrated files report21a, report21b, and report33 to stdout:
# migcat rep*21? report33
SEE ALSO
cat(1), migstage(1)
284 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migchecklog(1M)
migchecklog(1M)
NAME
migchecklog - list the most recent error messages from an error log file
SYNOPSIS
/usr/openv/hsm/bin/migchecklog [-d time_in_minutes] [-h] [hsmname | GLOBAL]
DESCRIPTION
The migchecklog command checks the specified VSM log file and displays the 20 most recent error messages logged.
Using the -d option runs migchecklog periodically following a variable delay. If subsequent checks find newer error messages, older messages are dropped from the input. The display indicates that new errors exist and appends them to the list of up to twenty error messages.
OPTIONS
-d time_in_minutes Check logs, and then delay for the sleep time specified by the variable time_in_minutes before checking logs again. Default is 0, which checks logs only once.
-h Print Help information.
hsmname The VSM name configured to use the log file you want migchecklog to check. Checking the global log file on the VSM server (/tmp/hsm.log) is the default. See migconfg(1M) for more information on the global configuration file.
CAVEATS
◆ Because migchecklog lists only the latest 20 error messages, it is possible some error messages could be missed by this command. If the listing shows 20 new errors, the administrator is advised to check the actual log in question for any errors that may not have been reported.
EXAMPLES
◆ The following example checks the global log file once:
# migchecklog
Appendix A, Man Pages 285
migchecklog(1M)
◆ The following example checks the log file for the managed file system nu:
# /usr/openv/hsm/bin/migchecklog -d 6 nu ------- Fri Jan 11 10:52:48 CST 2002 --------01/11 10:14:27 [1164]migtie[4937]: ERROR: groupfile .fd not found above tie file /nu/ag/f1.01/11 10:14:27 [1164]migtie[4937]: ERROR: groupfile .fd not found above tie file /nu/ag/f2.01/11 10:14:27 [1164]migtie[4937]: ERROR: groupfile .fd not found above tie file /nu/ag/f3.01/11 10:25:20 [1164]migin[5949]: ERROR: No FHDB entries for 2912448M5BDE
After 6 minutes, migchecklog prints the list again, appending any new messages and dropping older messages as necessary to maintain a maximum list of 20 messages:
------- Tue Jan15 15:11:58 CDT 2002 --------New errors01/12 14:36:25 [12]migmkspace[113]: ERROR No entries in FHDB for filehandle 100001/12 14:36:25 [12]migmkspace[113]: ERROR No entries in FHDB for filehandle 107C01/12 14:40:13 [22]migcopy[413]: ERROR choose_src_gran no gran for as_filep=x001/12 14:40:13 [22]migcopy[413]: ERROR read_data: no good source granules found01/12 14:40:13 [22]migcopy[143]: ERROR copy_file()/copy_gran fail01/12 14:40:13 [22]migcopy[143]: ERROR ** FAILED TO COPY: X107C01/12 14:40:13 [22]migcopy[143]: ERROR ** copy_for_method() ret=101/12 14:41:43 [25]migcopy[149]: ERROR choose_src_granno gran for as_filep=x001/12 14:41:43 [25]migcopy[149]: ERROR read_data: nogood source granules found01/12 14:41:43 [25]migcopy[149]: ERROR copy_file()/copy_gran fail01/12 14:41:43 [25]migcopy[149]: ERROR ** FAILED TO COPY: X107C01/12 14:41:43 [25]migcopy[149]: ERROR ** copy_for_method() ret=101/12 14:42:42 [12]migmkspace[166]: ERROR No entries in FHDB for filehandle 100001/12 14:46:17 [12]migmkspace[202]: ERROR No entries in FHDB for filehandle 100001/12 15:08:21 [14]mignospace[239]: ERROR: No threshold
286 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migchecklog(1M)
specified.01/12 15:09:03 [12]migmkspace[249]: ERROR No entries in FHDB for filehandle 1000
FILES/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
/tmp/hsm.log
Global log file for the VSM server
SEE ALSO
migconfg(1M), mignewlog(1M), migrc(1M), startmigd(1M)
Appendix A, Man Pages 287
migcleanup(1M)
migcleanup(1M)
NAME
migcleanup - displays or cleans up DMAPI sessions
SYNOPSIS
/usr/openv/hsm/bin/migcleanup [[-e] | [-l] | [-k] | [-g]| [-r token]] [-R reply] [-s sid]
Caution migcleanup is intended only for customer support engineers who are trained in its use.
DESCRIPTION
The migcleanup command cleans up orphaned DMAPI sessions. migcleanup prints all generated token and session lists to standard output. The lists exclude the current session.
OPTIONS
-e List all outstanding event tokens for all sessions only if sid is not specified. Otherwise, list all outstanding event tokens for the sid. Tokens are listed in decimal. If there are no tokens, the output list is identical to the one generated with the -l option.
-l List all sessions only if sid is not specified. Otherwise, list sid.
-k Ends all sessions initiated by VSM for which the creating process no longer exists only if sid is not specified. Otherwise, end sid unconditionally. Responds to all oustanding tokens.
Note The -k option will only kill the session belonging to migd if you specify migd’s sid.
-g Get all undelivered events for all sessions only if sid is not specified. Otherwise, get all undelivered events for sid.
Note The -g option does not respond to events. You must run migcleanup a second time with -k or -r to respond to events
-r token Respond to event token. The value is assumed to be decimal. Requires that -s sid be specified.
-R reply Reply to event tokens with reply, specified as c for continue or a for abort. The default is abort.-R is optional with -k and -r.
288 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migcleanup(1M)
-s sid Specifies the session to process. The value is assumed to be decimal. Required to be used with -r and is optional with -e, -l, -k, and -g.
CAVEATS
A session can not be canceled if there are undeliverable events or if it has outstanding tokens with exclusive rights. Use the -g option to get all undeliverable events. Use the -r option to respond to tokens with exclusive rights.
EXAMPLE
The following example lists all outstanding event tokens for all sessions:
# migcleanup Session (37100) name: OVT.25719.tar-create Session (37098) name: OVT.25714.tar-create Session (37097) name: OVT.25713.tar-create Session (37096) name: OVT.25712.tar-create Session (36959) name: OVT.20137.migd
The following example kills session 37100 unconditionally:
# migcleanup -k -s 37100Responding to events for sid 37100, tokens:227Destroying session 37100: OVT.25719.tar-create
To list the remaining sessions, execute migcleanup again:
# migcleanup Session (37098) name: OVT.25714.tar-createSession (37097) name: OVT.25713.tar-createSession (37096) name: OVT.25712.tar-createSession (36959) name: OVT.20137.migd
The following example kills all sessions initiated by VSM for which the creating process no longer exists:
# migcleanup -kDestroying session 37098: OVT.25714.tar-createDestroying session 37097: OVT.25713.tar-createDestroying session 37096: OVT.25712.tar-create
The following example replies continue to token 6 for session 36959:
# migcleanup -r 6 -s 36959 -R c
SEE ALSO
migalter(1M)
Appendix A, Man Pages 289
migconf(1M)
migconf(1M)
NAME
migconf - VSM managed file system configuration file
SYNOPSIS
dwpath/database/migconf
DESCRIPTION
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
Migration parameters for each VSM-managed file system reside in a dwpath/database/migconf file. Use the VSM-Java GUI to make changes to this file based on your site’s needs.
The managed file system configuration file is divided into six general parameter blocks:
◆ DEFAULTS
Describes general parameters for controlling the operation of VSM. For example, in this section you define whether to make one or two copies of each migrated file.
◆ METHOD1 and METHOD2
Indicates the storage method (including types of media, volume sets, hints, and volume pools) to use for migrating the Primary (first) and Alternate (second) file copies. For example, a site may choose to write the first copy to optical disk and the second copy to magnetic tape.
These parameters refer to the Primary Level and Alternate Level in VSM-Java.
◆ METHOD3 through METHOD8
Indicates the storage method (including types of media, volume sets, volume availability, and volume pools) to use for migrating the Primary (first) and Alternate (second) file copies. For example, a site may choose to write the first copy to optical disk and the second copy to magnetic tape.
These parameters are set via Level Properties in VSM-Java.
◆ METHOD
This information is provided as a reference. You are encouraged to use the LEVEL parameter to describe characteristics for migration levels.
290 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
◆ LEVEL
Describes characteristics of migration levels, including types of media, volume sets, volume availability, and volume pools. Generally, you do not need to change the defaults in this section. Some parameters, however, may be configured, including the criteria associated with each method for moving migrated files to another migration level.
These parameters are set via Level Properties in VSM-Java.
Note Move criteria for migration levels, if specified, take precedence over move criteria for method names, if specified.
◆ FILESYS
Defines a managed file system directory and its associated migration parameters such as the percentage of free space that should be remaining when VSM starts migrating files. Sites must change this section to specify the file systems and policies VSM is to use for selecting files for migration. There is a separate FILESYS entry for each managed file system that uses the migconf file.
Comments within a parameter block are currently not allowed. Parameters are separated by newline characters or commas.
On startup, the migration daemon reads the configuration files. If you manually change the configuration file while the daemon is up, you can stop and restart the daemon so that it picks up the changes or you can signal the daemon as follows:
# kill -INT ‘cat /usr/var/openv/hsm/workdir/migd.pid*‘
If you use the VSM-Java interface to make the changes, it signals the daemon for you.
Some parameter values for size or time in migconf can be specified as a base number followed by an optional multiplier. Possible multipliers are as follows:
B 1 Block (512 bytes)
K 1 kilobyte (1,024 bytes)
M 1 megabyte (1,048,576 bytes)
G 1 gigabyte (1,073,741,824 bytes)
d 1 day (86400 seconds)
h 1 hour (3600 seconds)
m 1 minute (60 seconds)
s 1 second (1 second)
Appendix A, Man Pages 291
migconf(1M)
DEFAULTS SECTION
The parameters you can specify in the DEFAULTS section are as follows:
mach_id Integer (nonzero) identifier for each VSM-managed file system. All file systems exporting or importing files between them must be distinct; each must have a unique mach_id. Valid values range from 1 to FFFFFF.
quota Maximum number of bytes a user may exclude from migration. The default is 10,000,000 bytes.
copies Number of migration copies of the disk file to be made. The maximum value is 2. The default is 2. You can change this value to 1.
unmount_delayTime in seconds a volume that is mounted in read mode remains mounted if no read request is received during that time. The default is 180.
checksumIf you set checksum to 1, VSM calculates a check sum for each granule that is written. If checksum is set to 0, VSM does not calculate a check sum. The default is 1. During a read, VSM checks the check sum only if the granule was written with a check sum.
The following is an example DEFAULTS entry:
DEFAULTS quota=400000, copies=1, unmount_delay=300, checksum=1
The configuration has been set to make one copy of migrated files (copies=1).
METHOD1 AND METHOD2 SECTION
These parameters specify the characteristics of the Primary Level and Alternate Level for migrating files. These characteristics a e types of media, volume sets, volume availability, and volume pools. The METHOD1 parameter defines where the Primary (first) copy is to be written. If you are making dual copies, the METHOD2 parameter defines where the Alternate (second) copy is to be written. These values are used bymigpolicy.
The format is as follows:
method_name.volume_set_number.hint.volume_pool
Names used for method_name must match the names listed in the METHOD section of the migconf file. Valid method names follow:
ad Alternate magnetic disk
ct Tape
dt Tape
292 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
mt Tape
op Optical disk as tape with random seek - rewritable
ow Optical disk as tape with random seek - write once, read many
ft Remote method using ftp
nb NetBackup
Default attributes for tape method names are platform-dependent. Tape method names may be used interchangeably and optical disk method names may be used interchangeably if the default method attributes in migconf are modified to match the site configuration.
If you use VSM-Java, it assigns the volume_set_number for you. The volume_set_number specifies the number for the set of media IDs from which to choose the volume. VSM uses different method names or volume set numbers for Primary and Alternate Levels.
The hint parameter is the volume set availability, which is part of how VSM calculates how log it will take to cache a file (that is, recall it from secondary storage). It may be any of the following three values:
library Access is immediate.
operator Access requires operator action. 15 minutes is added to access time.
vault Access is off-site and requires 24 hours.
The volume_pool parameter designates volume pools other than HSM (the default). The same volume set cannot exist in more than one volume pool.
If the DEFAULTS parameter is copies=1, the migconf file has an entry such as the following:
METHOD1="ct.1.library" METHOD2="" .
If the DEFAULTS copies parameter is copies=2, you will see an entry such as the following:
METHOD1="ct.1.library" METHOD2="ct.2.vault"
Multiple volume sets may be specified in the same METHOD1 or METHOD2 parameter to allow VSM to use more than one drive at the same time. This speeds up the migration process although only one copy of the file is being made.
Appendix A, Man Pages 293
migconf(1M)
METHOD1 THROUGH METHOD8 SECTION
These parameters specify the characteristics of the Primary Level and Alternate Level for migrating files. These characteristics are types of media, volume sets, volume availability, and volume pools. The METHOD1 parameter defines where the Primary (first) copy is to be written. If you are making dual copies, the METHOD2 parameter defines where the Alternate (second) copy is to be written. These values are used by migpolicy.
The following are example METHOD3 and METHOD4 entries:
METHOD3="ct.10.library" METHOD4="ct.20.vault"
This specifies an online tape library at migration level 3, and off-site tape storage at migration level 4.
METHOD SECTION
Each block of parameters in the METHOD section specifies the characteristics of all supported device method names. Generally, sites do not need to change the defaults in this section, but may want to modify the criteria associated with each method name for moving files from one migration level to another migration level.
The following METHOD parameters are available:
name The name of the device method. Valid values are ct, dt, mt, op, ow, ad, ft, and dk. Method name dk, used for premigration, is mandatory but not configurable.
flags Flags set for this method.
MFLAG_OBSOLETEMedia supports obsoleting granules (see migmdclean(1M)). This option applies only to the ad, ft, nb, and dk methods.
Note If the storage method is ct, dt, or mt, the MFLAG_OBSOLETE flag is also used to indicate that the method is using write-once-read-many (WORM) tapes.
MFLAG_APPENDApplies only to the ct, dt, mt, op, and ow methods. This flag allows VSM to place multiple migrations on the same volume by appending them to that volume until it is full to its configured limit. When writing to tape or optical media and MFLAG_APPEND is present, VSM continues to append to a volume until it is full and then writes on the next empty volume. This allows smaller migrations without wasting space. When MFLAG_APPEND is not present, each migration always starts on an empty volume.When MFLAG_APPEND is present, VSM performs the following two steps to select a volume for a new migration:
294 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
1. Checks the dwpath/database/VOLDB file for a volume that belongs to the correct volume set that has the WRITING flag set in the VOLDB entry. (When VSM selects an empty volume for migration, it sets the WRITING flag in the VOLDB entry for that volume, indicating that VSM is using the volume for writing.)2. If VSM finds a volume that is in the correct volume set and is also being written, it extends that volume with the new migration. Otherwise, it selects an empty volume (if possible) for the migration.
MFLAG_EOTApplies only to ct, dt, and mt methods. This flag allows VSM to write to the media until end of tape (EOT) is encountered instead of using the capacity value. It is still necessary to specify capacity because VSM uses that value for calculating volume requirements during media consolidation.
access Time to access the media in seconds. VSM combines the access value with hint, speed, and file size to determine the relative time required to cache a copy of a file. The formula is as follows: Relative cache time = access + hint + file_size/speed: The Relative cache time is a value that VSM uses to determine which device method to use to cache first. The access is the value of the access parameter. The hint is the time delay indicated by the hint parameter. The file_size is the total size of the file in bytes. The speed is the value of the speed parameter. If there is more than one copy of a file, VSM uses the relative cache time to determine which volume to select for a cache. VSM attempts to select the volume with the copy that it can cache in the least time. If that volume is not available, VSM then chooses another volume. VSM attempts to cache remote copies first (if they exist) before attempting to cache copies from local media.
capacity The capacity of the tape method (ct, dt, or mt) in bytes. You specify capacity for the ft and nb methods when registering the volumes (see migreg(1M)).
Note The nb method will not be supported after the VSM 4.5 release.
speed Relative rate at which the device can transfer data in bytes per second. As mentioned in the description for the access parameter, VSM uses speed when determining which copy of a file to cache.
Appendix A, Man Pages 295
migconf(1M)
gran_sizeVSM divides files into granules. Each granule must fit on one volume. The gran_size parameter specifies the number of bytes in each granule that VSM writes to the device. The allowable granule sizes are 128KB, 256KB, 512KB, 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, and 64MB. Granule size is a power of 2 and an integral multiple of block size.
block_sizeBlock size in bytes to use when writing to the device. The allowable block sizes are 512, 1KB, 2KB, 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, and 256B. The value must be a power of 2. Do not change this parameter after the initial configuration. It is not necessary to configure block size for method names op or ow because VSM determines the actual physical block size of optical volumes each time they are mounted or opened.
density Density of the tape or optical disk medium.
dead_man_timeoutThe maximum period of time in seconds that VSM should wait for an ftp or NetBackup request to complete or for a tape or optical mount to complete. The default is 3600 (one hour).
port_numberftp port number and used only for the ft method.
demand_delayThe time a mount request waits before VSM unmounts a similar unused volume. If VSM identifies a similar mounted but unused volume whose unmount delay has not yet expired, it unmounts that volume as soon as the demand delay occurs. Otherwise, the mount request remains active until a drive becomes available. This is used only for the ct, dt, mt, op, and ow method names. Default values are 1 minute for method name ct, 3 minutes for method names dt and mt, and 20 seconds for method names op and ow.
Note Move criteria for migration levels, if specified, take precedence over move criteria for method names, if specified.
move_badnessThe criterion that VSM uses to move files from one migration level to another after skipping those that are less than the minimum move age or size. VSM computes the move badness for each migrated file, and then selects those with a move threshold factor that equals or exceeds the configured value. The VSM move threshold formula is as follows: move_badness=(move_age_weight x (move_age)) + or x [as specified by move_weight_operator] (move_size_weight x (move_size))The default value is 30.
296 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
move_age Age of file (in days). VSM does not move files that have been migrated, moved, or accessed within this time. The default is 7. (Express value as a base number without a multiplier.)
move_sizeSize of file (in kilobytes). VSM does not move files smaller than this. The default is 0. (Express value as a base number without a multiplier.)
move_age_weightWeighting to be used for age in the move threshold formula. The default is 1.
move_size_weightWeighting to be used for size in the move threshold formula. The default is 1.
move_weight_operatorThe operator to be used (add or multiply) in calculating the threshold factor. The default is multiply. Configuring move_weight_operator = Site specifies a site selected threshold algorithm.
move_flagsMark FHDB entries for file copies at the source migration level either dead, acitve, or obsolete. The default is to mark then dead for method names ct, dt, mt, op, and ow, and to mark them obsolete for method name ad.
Be sure to delete or comment out method names not used at your site because extra unused methods cause additional processing. dk is always needed.
Method names ct, dt, and mt may be used interchangeably if the default method attributes in migconf are modified to match the site configuration. Method names op and ow may be used interchangeably if the default method attributes in migconf are modified to match the site configuration. /usr/var/openv/hsm/example/database/migconf, the example migconf file, supports the following METHODs:
◆ Disk File (dk)
This method is required for premigration. The access time for the staging area is always 0 to ensure that it is preferred over all other methods.
METHODname=dk, access=0, capacity=50M, speed=1M, gran_size=1M, block_size=64K
Appendix A, Man Pages 297
migconf(1M)
◆ Tape (ct)
METHODname=ct, flags=MFLAG_APPEND | MFLAG_EOT block_size=32K, access=15s, gran_size=2M, capacity=20G, speed=10M, density=hcart, dead_man_timeout=3600, demand_delay=3m
◆ Tape (dt)
METHODname=dt, flags=MFLAG_APPEND | MFLAG_EOT block_size=32K, access=2m, gran_size=2M, capacity=35G, speed=5M, density=dlt, dead_man_timeout=3600, demand_delay=3m
◆ Tape (mt)
METHODname=mt, flags=MFLAG_APPEND | MFLAG_EOT, block_size=32K, access=30s, gran_size=2M, capacity=50G, speed=6M, density=8mm, dead_man_timeout=3600, demand_delay=3m
◆ Alternate Magnetic Disk (ad)
METHODname=ad, flags=MFLAG_OBSOLETE, block_size=1K, access=10s, gran_size=2M,
298 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
capacity=320M, speed=800K
Appendix A, Man Pages 299
migconf(1M)
◆ Optical Disk as Tape, rewritable (op)
METHODname=op, flags=MFLAG_APPEND, block_size=512, access=1m, gran_size=2M, capacity=280M, speed=200K, density=odiskwm, dead_man_timeout=3600, demand_delay=20s
◆ Optical Disk as Tape, write once, read many (ow)
METHODname=ow, flags=MFLAG_APPEND, block_size=512, access=1m, gran_size=2M, capacity=280M, speed=200K, density=odiskwo, dead_man_timeout=3600, demand_delay=20s
◆ Remote method using ftp (ft)
METHODname=ft, flags=MFLAG_OBSOLETE, block_size=32K, access=20s, gran_size=2M, capacity=0, speed=300K, dead_man_timeout=3600, port_number=21
◆ NetBackup (nb)
METHODname=nb, flags=MFLAG_OBSOLETE, block_size=32K, access=2m, capacity=0, speed=300K, dead_man_timeout=3600
300 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
Note The nb method will not be supported after the VSM 4.5 release.
LEVEL SECTION
Each block of parameters in the LEVEL section specifies the criteria associated with each migration level for moving files from one migration level to another migration level.
Note Move criteria for migration levels, if specified, take precedence over move criteria for method names, if specified.
move_badnessThe criterion that VSM uses to move files from one migration level to another after skipping those that are less than the minimum move age or size. VSM computes the move threshold for each migrated file, and then selects those with a move threshold factor that equals or exceeds the configured value. The VSM move threshold formula is as follows: move_badness=(move_age_weight x (move_age)) + or x [as specified by move_weight_operator] (move_size_weight x (move_size))The default value is 30.
move_ageAge of file (in days). VSM does not move files that have been migrated, moved, or accessed within this time. The default is 7. (Express value as a base number without a multiplier.)
move_sizeSize of file (in kilobytes). VSM does not move files smaller than this. The default is 0. (Express value as a base number without a multiplier.)
move_age_weightWeighting to be used for age in the move threshold formula. The default is 1.
move_size_weightWeighting to be used for size in the move threshold formula. The default is 1.
move_weight_operatorThe operator to be used (add or multiply) in calculating the threshold factor. The default is multiply. Configuring move_weight_operator = Site specifies a site selected threshold algorithm.
Appendix A, Man Pages 301
migconf(1M)
move_flagsMark FHDB entries for file copies at the source migration level either dead, active, or obsolete. The default is to mark them dead for method names ct, dt, mt, op, and ow, and to mark them obsolete for method name ad.
FILESYS SECTION
The FILESYS section specifies a managed file system directory and its associated migration parameters. VSM uses these parameters to manage space in the managed file system. There is a separate FILESYS entry for each managed file system that uses the migconf file. FILESYS parameters are as follows:
name The path to the directory in the file system that VSM manages. It must be the real name and not a link name, and must not contain a trailing slash. The default is /hsm1.If you configure more than one name, each managed file system must be unique and its name must be uniqye.
freespaceSpecifies the percentage of space to be kept free on the file system. If file system free space falls below this amount, migration should be restarted. The default is 10.
lowwaterThe percentage of free space that stops the selection of files to be migrated. If specified, lowwater must be greater than or equal to the value specified for freespace. The default is 0 (the parameter is ignored). Files listed in a user’s .migrate file are selected after lowwater is reached, so the percentage of free space may be larger than expected. Space in premigration is not considered free. migbatch makes only one pass through the file system with the current threshold as it tries to achieve lowwater. Each time mignospace executes and finds no files in premigration to purge, the current threshold is cut in half, causing more files to be selected. migrc and migbatch reset the current threshold to the value you initially configured in the migconf file.
purgemarkThe percentage of free space that stops the purging of premigrated files. If specified, purgemark must be greater than or equal to the value specified for freespace and less than lowwater unless lowwater=0. The default is 0 (the parameter is ignored).
badness The criterion that VSM uses to select files for migration after skipping those that are less than the minimum age or size. Files with a threshold factor that equals or exceeds this value are selected for migration.
302 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
threshold=(age_weight x (min_age)) + or x [as specified by weight_operator] (size_weight x (min_size))The default value is 0.
min_age Age of file (in days). VSM does not select files for migration that have been either accessed or modified within this time. The default is 7. Generally, age should be greater than 0 to prevent VSM from migrating files on the same day they are created. (Express value as a base number without a multiplier.)
min_sizeSize of file (in kilobytes). VSM does not select files for migration that are smaller than this. The default is 8. (Express value as a base number without a multiplier.)
age_weightWeighting to be used for age in the threshold formula. The default is 1.
size_weightWeighting to be used for size in the threshold formula. The default is 1.
weight_operatorThe operator to be used (add or multiply) in calculating the threshold factor. The default is multiply. Configuring weight_operator = Site specifies a site selected threshold algorithm.
slice Number of bytes from the head of a file to keep on disk when the file is migrated. These bytes are also migrated but VSM keeps a copy of them on disk even when it purges the file from premigration, thus allowing this number of bytes to be read without caching the file. Valid values range from 0 to 2147483648 (2 GB). The default is 0, which means that no slice is kept in the file system.
readaheadMinimum number of kilobytes beyond the current read request that VSM partially caches to disk. A readahead of 0 means partial file caching with no minimum caching beyond the read request. A readahead of -1 disables partial file caching (default).
The FILESYS section also specifies three parameters used in making additional file space available quickly.
give_up_time (Time Increment)Maximum time in minutes migcopy runs before stopping an accelerated file space availability operation. The default is 60. A value of 0 signifies no limit.
Appendix A, Man Pages 303
migconf(1M)
give_up_files (File Increment)Maximum number of files processed by migcopy and migsweep before stopping an accelerated file space availability operation. A value of 0 signifies no limit (default).
give_up_kbytes (Space Increment)Minimum amount of disk space (in kilobytes) freed by migcopy and migsweep before stopping an accelerated file space availability operation. The default is 1,048,576. A value of 0 signifies no limit.
The FILESYS parameters also specify the purge parameters for the file systems to which this specific dwpath/database/migconf file applies. The migconf file contains a separate set of purge parameters for each file system. Those parameters are as follows:
purge_badnessThe criterion that VSM uses to select premigrated files for purging after skipping those that are less than the minimum purge age or size. Files with a purge_badness factor that equals or exceeds this value are selected for purging. purge_badness=(purge_age_weight x (purge_age)) + or x [as specified by purge_weight_operator] (purge_size_weight x (purge_size))The default value is 0.
purge_min_ageAge of file (in days since migrated). VSM does not purge premigrated files migrated within this time. The default is 0. (Express value as a base number without a multiplier.)
purge_min_sizeSize of file (in kilobytes). VSM does not purge files smaller than this. The default is 0. (Express value as a base number without a multiplier.)
purge_age_weightWeighting to be used for age in the purge_badness formula. The default is 1.
purge_size_weightWeighting to be used for size in the purge_badness formula. The default is 0.
purge_weight_operatorThe operator to be used (add or multiply) in calculating the purge_badness factor. The default is add. Configuring purge_weight_operator = Site specifies a site selected purge_badness algorithm.
An example FILESYS configuration is as follows:
304 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconf(1M)
FILESYS name=/lamda, freespace=10, badness=2000, min_age=1, min_size=1, age_weight=1, size_weight=1, weight_operator=multiply,slice=8192, purgemark=0
In the above example, VSM manages the file system /lamda. With the above parameter values, VSM does not migrate files on the same day they were created (because min_age=1), nor files under a kilobyte (because min_size=1). If VSM encounters a 100-KB file that has not been accessed or modified for 30 days, it computes the threshold to be 3000 (30 days x 100 KB). Because the threshold value is set to 2000 in this example, this file would be a migration candidate.
SEE ALSO
VSM(1M), migconfg(1M), miglow(1M), migmdclean(1M), migreg(1M), migtestbadness(1M), startmigd(1M)
Appendix A, Man Pages 305
migconfg(1M)
migconfg(1M)
NAME
migconfg - global configuration file for the VSM server
SYNOPSIS
/usr/var/openv/hsm/database/migconfg
DESCRIPTION
The VSM global configuration file, migconfg, has one or more entries, each starting with the string HSMDEV followed by one or more parameters. Not all parameters are required. The parameters specified in this file let you partition VSM into easily manageable partitions by name (hsmname) and define location of files for each hsmname. Use VSM-Java to make changes to migconfg.
The following parameters are available:
hsmname The logical name for the managed file system. hsmname must be a unique alphanumeric value, such as projectx or zeta. Although numeric values such as 1234 are accepted, their use is not recommended as the hsmname is embedded in path names and some utilities may not work correctly. The maximum length is 32 characters.
fspath The path name of the managed file system for this hsmname. It is used for computing the device number of the file system. fspath is the mount point for the file system. It cannot be the full path to the FILESYS name if the FILESYS name is a subdirectory in fspath. This parameter is required.
Caution Always create the database directory in a local file system that VSM does not manage. This eliminates the possibility of migrating files from the database or workdir directories.
dwpath The path name of the directory containing the database and workdir directories for the hsmname you specify. The default is /usr/openv/hsm/database/hsmname.
lgpath The path name of the log file for the hsmname you specify. The default is /usr/openv/hsm/logs/hsmname.log. The hsmname hsmname is the value you supply for hsmname.
state Specifies whether VSM processes hsmname when it automatically migrates or caches files from the file system indicated by fspath. The state parameter can have a value of either 1 or 0, where 1 is on and 0 is off. Default is 1 (on). If you set state to 0 (off), users cannot access migrated files and an error is returned to the user’s application program.
306 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconfg(1M)
The following lists VSM files in the dwpath/database directory (for a configured VSM):
FHDB: The file handle database contains at least one entry for each copy of a migrated file. When VSM must split storage of a file over more than one volume, it creates an FHDB entry for each volume the file is stored on.
FHSEQF: The file-handle-sequence file contains the eight-digit hexadecimal value that VSM assigns to the next file handle.
FHDB.LK: The file-handle-database lock file used by the VSM database merge process to provide a master lock on the file handle database.
FNDB: The file name database contains one for each copy of a migrated file.
VOLDB: The volume database contains an entry for each volume registered with VSM.
VOLSEQF: The volume-sequence file contains the eight-digit hexadecimal value that VSM assigns to the next volume ID (handle).
VOLDB.LK: The volume-database lock file. The VSM database merge process uses this file to provide a master lock on the volume database.
NEXTVOL1: Next volume set to use for the primary copy of a migrated file.
NEXTVOL2: Next volume set to use for the alternate copy of a migrated file (if applicable).
NEXTVOL3 ... NEXTVOL8: Next volume set to use for moving a migrated file to migration level 3-8 (if applicable).
migsweep.site: Site-specific migration and purge criteria control.
migsweepm.site: Site-specific move criteria control for files (if applicable).
migconf: The configuration file that specifies migration criteria for file systems using this database. You set up this file during the configuration process.
hsmname.IHAND: Inode and handle information about migrated files
hsmname.FLUSH: Controls how often VSM writes tape marks when making copies during file migration.
hsmname.merge_badness_count: If present, an ASCII file containing the minimum number of DVDB entries that must be waiting to be merged before VSM will trigger a merge operation.
hsmname.merge_time_delay: If present, an ASCII file containing the minimum number of seconds between merge operations.
hsmname.gran_retry: If present, VSM will try to read the same granule twice if it encountered a read error.
Appendix A, Man Pages 307
migconfg(1M)
The files in the VSM directory workdir are as follows for a configured VSM:
mig.lck: Used by migbatch and mignospace to lock the managed file system while sweeping and premigrating files.
hsmname.copydb.method_name.volume_set_number.hint: Work list files used to copy premigrated files to storage and move migrated files to destination levels.
hsmname.idling: Exists if hsmname is idling down
hsmname.last_merge: If present, its last modification time is when the last FHDB merge operation completed.
hsmname.migsweep: List of files selected to be premigrated
hsmname.nospace: Exists if mignospace is running with the -N option.
hsmname.p_badness: Current purge threshold value
hsmname.s_badness: Current threshold value.
hsmname.state: Current VSM state if the state is Idle, Iding, or Maintenance
hsmname.sweep.restart: Path of the last file selected by migsweep before reaching the low-water mark.
hsmname.VxFS_34_vsmstate: If non-zero, VSM detected VxFS version 3.4. The contents (ASCII 0 or 1) indicate the value assumed for hsm_write_proalloc.
The following files are present if the command process is running:
hsmname.migbatch.running: Processs ID (pid) of migbatch.
hsmname.migcons.running: Process ID of migcons.
hsmname.migconsweep.running: Process ID of migconsweep .
hsmname.migdbcheck.running: Process ID of migdbcheck.
hsmname.miglow.running: Process ID of miglow.
hsmname.migmdclean.running: Process ID of migmdclean.
hsmname.migmove.running: Process ID of migmove.
hsmname.mignbexport.running:Process ID of mignbexport.
hsmname.mignbimport.running: Process ID of mignbimport
hsmname.mignospace.running: Process ID of mignospace.
hsmname.migrc.running: Process ID of migrc.
hsmname.migreconstruct.running: Process ID of migreconstruct.
hsmname.migrecycle.running: Process ID of migrecycle.
hsmname.migsetdb.running: Process ID of migsetdb.
308 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconfg(1M)
To find the actual file names used in your system, use gethsm and migdbdir.
VSM uses a global log file to log messages from the migration daemon and volume daemon, and a log file for each hsmname to log messages from migration processes running on behalf of hsmname. The path name of the global log file is /tmp/hsm.log.
You can initiate logging for the VSM-Java request daemon by creating a file with the path name /usr/openv/hsm/logs/migrd.log. If this path exists before you start migrd, VSM will log information to it.
You can obtain the values of migconfg parameters by using the migdbdir command. For example, the following prints the value of the lgpath parameter for the managed file system alpha:
# migdbdir alpha 3
On startup, the migration daemons read the configuration files. If you change the global configuration file while the daemons are running, you can stop and restart the daemon so that it picks up the changes, or you can signal the daemon as follows:
# kill -HUP ‘cat /usr/var/openv/hsm/workdir/migrd.pid*‘
If you use the VSM-Java interface to make the changes, it signals the daemon for you.
EXAMPLE
The following are example /usr/openv/hsm/database/migconfg entries.
HSMDEV hsmname=hsm1, fspath=/sd7, dwpath=/usr/openv/hsm/database/hsm1/database, lgpath=/usr/openv/hsm/hsm1.log, state=1
HSMDEV hsmname=hsm2, fspath=/hsm2, dwpath=/usr/openv/hsm/database/hsm2/database, lgpath=/usr/openv/hsm/hsm2.log, state=1
SEE ALSO
VSM(1M), migconf(1M), migdbdir(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M), migactivate(1M)
Appendix A, Man Pages 309
migcons(1M)
migcons(1M)
NAME
migcons - consolidate VSM tape and optical disk volumes
SYNOPSIS
/usr/openv/hsm/bin/migcons [-F] [-N] hsmname one | two out_method out_volume_set label.method.volset [label.method.volset]...
DESCRIPTION
The migcons command consolidates one or more input volumes onto a set of output volumes. Input volumes can belong to different storage methods. Output volumes must belong to a single method.
Periodic volume consolidation is necessary because VSM does not release unusable volume space automatically. As files are migrated, cached, and modified, the amount of unusable space on a volume grows. Run miggetvol or migdbrpt to determine which VSM volumes have low space utilization or otherwise are candidates for consolidation.
Unusable space is occupied by file data that has been marked obsolete or dead. Obsolete data represents an earlier version of a modified file. It is possible to retrieve obsolete data up until the time these entries are marked dead. To mark obsolete entries dead, run migmdclean before consolidating volumes.
The migcons command does the following:
◆ Copies active and obsolete data from the input volume(s) onto the output volume(s). Because migmdclean removes expired and obsolete data, running it before you run migcons will prevent your copying obsolete data. The migcons command does not copy data marked dead in the FHDB.
◆ Removes all references to the file granules on input volumes from the FHDB.
◆ Removes the volume entry for the input volume from the volume database (VOLDB).
◆ Deassigns the volume and returns it to the HSM pool for use by any managed file system.
Note When one side of an optical disk is consolidated, the volume entry for that input volume is marked dead and not removed from the VOLDB unless the other side of that optical disk is also marked dead.
After consolidation, all data other than dead entries is available on the output volumes. The input volumes must be reregistered before VSM will use them again (see the migreg(1M) man page). For optical volumes, if the volume still exists in the VOLDB as a
310 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migcons(1M)
dead entry, then migrecycle(1M) must be run before VSM can use the volume again. Although it is possible to consolidate ow volumes (write once, read many), it is not possible to recycle them.
migcons can use two drives simultaneously for reading and writing volumes. If sufficient drives are not available, migcons supports a two-step consolidation process, which is described in the options section.
You can use migselect to generate a list of volumes that need to be consolidated.
OPTIONS
-F Perform consolidation without feasibility check to assess the capacity of the output volumes. See CAVEATS.
-N Selects a new (empty) volume for output, disregarding the MFLAG_APPEND flag for the method. If you do not specify -N, migcons selects the output volume based on the MFLAG_APPEND flag: - If MFLAG_APPEND is set, migcons selects and appends the data to the volume currently being written. - If MFLAG_APPEND is not set, migcons selects a new volume.
hsmname Configured VSM name of the file sytem containing the database files for the volumes you want to consolidate.
one | two Specifies whether the consolidation occurs in one or two steps. This parameter is required. • One-step consolidation copies files directly from the input media to volumes under the output method. • Two-step consolidation copies from the input media to alternate magnetic disk media (method ad) and then to volumes under the specified output method. VSM-Java does not support two-step consolidation; you must use migcons if you need two-step consolidation.One-step consolidation is always faster. However, sites that consolidate input volumes using the same method as the output method but have only one device for the output method must use a two-step process. For example, a site that uses cartridge tape but has only one cartridge-tape drive available must use a two-step process. Prior to performing two-step consolidation, the site must register a volume in alternate magnetic disk (ad) volume set 0 (see migreg(1M)).
out_method Output method name for consolidation. This parameter is required. Valid values are ad, ct, dt, mt, op, or ow. See CAVEATS for details on the ad method.
Appendix A, Man Pages 311
migcons(1M)
out_volume_set Output volume set to use for consolidation. Volumes selected for writing belong to this volume set. You can use this parameter to ensure that multiple copies of the same file are consolidated on different volumes. This parameter is required.
label.method.volset Label, method, and volume set of the input volume (for example, CWra01.mt.1). You must supply at least one volume. The volumen cannot have the w flag set.Do not specify output volumes here; VSM automatically selects output volumes. Valid method values are ct, dt, mt, op, or ow.
CAVEATS
◆ You cannot consolidate volumes that use the ft or nb method.
◆ The migcons command performs a feasibility check before attempting to consolidate media, and it does not consider volumes in the scratch pool during this check. No additional media is registered. Then, migcons consolidates media only if the empty volumes for the output method have sufficient space for data from the input volumes.
◆ If consolidation is forced with the -F option and output volume capacity is inadequate, available tape or optical disk media in the same volume pool as the first input volume being consolidated are registered automatically as needed to provide adequate output volume capacity for writing the data from the input volumes. If output volume capacity is still inadequate, the command will fail when output volumes become full. These output volumes are marked full in the VOLDB, but no FHDB changes occur for input volumes being consolidated.
◆ Locked VOLDB entries for the input volumes fail the feasibility check and prohibit consolidation. Run the migrc command prior to consolidation to clear the locks.
◆ Do not run migcons and migmove simultaneously if they both are taking source from the same volumes. The results of such an action are undefined.
◆ If the output volume uses the ad method, an empty ad volume is required.
EXAMPLE 1
The following example uses a one-step process to consolidate REEL01 and REEL02 cartridge tape volumes (method ct) to new cartridge tapes selected by VSM.
# migcons alpha one ct 1 REEL01.ct.1 REEL02.ct.1
312 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migcons(1M)
EXAMPLE 2
If a site has just one tape device under method ct, the following example would consolidate volumes REEL01 and REEL02 under method ct to volume(s) under out_method ct. This occurs in two steps, with ad volumes used as staging volumes.
# migcons alpha two ct 1 REEL01.ct.1 REEL02.ct.1
EXAMPLE 3
The following example selects input volumes from ct volume set 2 based on volume occupancy limits ranging from 0.00 through 5.50 percent full. The consolidation is a one-step process to output method ct.
# migcons alpha one ct 2 ‘migselect alpha 0.00-5.50 2 ct‘
EXAMPLE 4
The following example consolidates volumes under multiple input methods ct and dt to volumes under output method ct.
# migcons alpha one ct 1 ‘migselect alpha 0.00-5.50 1 ct dt‘
FILES
The dwpath is the directory in that contains the database and workdir directories.
dwpath/database/VOLDB
Volume database.
dwpath/database/FHDB
File handle database.
dwpath/database/FNDB
File name database for VSM
dwpath/database/CONS_INVOL
Consolidation input volume list file generated during consolidation.
dwpath/database/CONS_OUTVOL
Consolidation output volume list file generated during consolidation.
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
migconfg(1M), migdbrpt(1M), miggetvol(1M), migmdclean(1M), migreg(1M), migrc(1M), migselect(1M), migrecycle(1M)
Appendix A, Man Pages 313
migconsweep(1M)
migconsweep(1M)
NAME
migconsweep - enable constant file system sweeping
SYNOPSIS
/usr/openv/hsm/bin/migconsweep [-s sleep_time] hsmname
DESCRIPTION
The migconsweep command enables constant sweeping of the managed file system instead of the normal sweeping process performed by VSM. Sweeps occur periodically, following interruptions determined by the sleep_time variable. This makes it less likely that the file list of migration candidates will be empty when needed.
Constant sweeping attempts to keep the list of migration candidates from becoming empty by periodically checking the list and resuming sweeping if necessary.
If mignospace is running when the file system is swept by migconsweep, the accelerated file space availability feature of mignospace is implemented whereby the sweeping process is interrupted as soon as any one of three configurable file system attributes is satisfied: time increment, file increment, or space increment. See man page mignospace(1M) for more information.
Once initiated, constant sweeping continues to run until the process is terminated with the kill command.
This command may be run without regard to whether the migd migration daemon is running, but the VSM state must be Active.
OPTIONS
-s sleep_timePause for this interval between sweeping operations, where sleep_time is the time in seconds that this command pauses before resuming a sweep of the file system. Default is 60.
hsmname Configured VSM name for the file system (in VSM-Java, the heirarchy) containing the database files for the volumes you want to consolidate.
CAVEATS
◆ Constant sweeping uses system resources that may adversely affect overall VSM performance, particularly during periods of heavy system usage.
314 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migconsweep(1M)
EXAMPLE
The following command initiates constant sweeping with a sleep time of 10 minutes (600 seconds) between sweeps for hsmname alpha.
# -s 600 alpha &
To stop constant sweeping, terminate the process with the following command.
# kill pid
FILESdwpath/workdir/hsmname.migconsweep.running
The process identifier (pid) for migconsweep.
dwpath/workdir/hsmname.migsweep
The list of files selected to be premigrated.
SEE ALSO
migbatch(1M), mignospace(1M)
Appendix A, Man Pages 315
migdbcheck(1M)
migdbcheck(1M)
NAME
migdbcheck - check VSM databases for consistency
SYNOPSIS
/usr/openv/hsm/bin/migdbcheck [-F | -P] [-V] [-v -r -s -h -p] [-c number_of_copies] hsmname
DESCRIPTION
The migdbcheck command checks the file handle database (FHDB), file name database (FNDB), and volume database (VOLDB) for consistency with the file system. You can check FNDB and FHDB together, the VOLDB by itself, or all three together.
Note The migdbcheck command defaults to check only the FHDB and FNDB. Checking the FHDB, FNDB, and VOLDB with a single command is faster than checking the databases independently with two commands.
You should correct database inconsistencies immediately to guard against future problems.
FHDB AND FNDB CHECKING
The migdbcheck command checks the databases in two ways:
◆ It verifies that the file system does not contain any files that have a file handle, but no entry in the FHDB/FNDB.
◆ It verifies that the FHDB/FNDB does not have any entries without files in the file system.
The migdbcheck command automatically checks the managed file system that uses the FHDB and FNDB. The command generates a list of all migrated files from the managed file system and compares this list with the contents of the databases. It detects the following error conditions:
◆ Migrated files exist that do not have enough entries in the FHDB and FNDB and do not have a valid dk method name entry. If there is a valid dk method name entry, VSM checks the copydb database.
◆ FNDB entries that contain a path that is different than the current path of a file with the same machid and handle. This list is placed in the file: /tmp/migdbcheck-movedfiles.hsmname.pid
◆ Active FHDB or FNDB entries exist for which there are no corresponding migrated files in the file system. These are sometimes referred to as orphan entries.
316 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbcheck(1M)
◆ FHDB or FNDB entries which have been flagged obsolete are present for files that still exist. Each migration level is checked.
◆ FHDB or FNDB entries which have been flagged dead are present for files that still exist. Each migration level is checked.
◆ The FHDB or FNDB is not in sorted order.
◆ Duplicate FHDB or FNDB handles exist in the file system.
◆ The FHDB or FNDB sequence number in the FHSEQF file is incorrect.
◆ FHDB or FNDB entries exist that are flagged as locked.
◆ FHDB or FNDB entries exist that are flagged as failed.
◆ There are active dk entries in the FHDB or FNDB but the data is purged.
◆ There are files in the file system whose full pathnames exceed 1024 characters. These files cannot be selected for migration, and may eventually fill the file system.
VOLDB CHECKING
The migdbcheck command checks the volume database (VOLDB) in two ways:
◆ It verifies that all files recorded in dwpath/database/FHDB and dwpath/database/FNDB have an associated entry in dwpath/database/VOLDB.
◆ It verifies that all active VOLDB entries are associated with at least one FHDB and FNDB entry.
The migdbcheck command automatically checks all file systems that use the VOLDB specified by hsmname. The following error conditions are detected by migdbcheck:
◆ Active FHDB or FNDB entries exist that reference nonexistent VOLDB entries.
◆ Active VOLDB entries exist for which there are no corresponding FHDB references.
◆ VOLDB entries exist in write mode for which there are no corresponding FHDB references.
OPTIONS
-F Check all entries in the FHDB and FNDB configured for hsmname. This is the default condition if neither -P nor -V is specified.
-P Check consistency between dk entries and premigrated files. This overrides -F.
-V Check all entries in the VOLDB configured for hsmname.
-v Verbose mode; output is directed to standard output as well as to the output files.
Appendix A, Man Pages 317
migdbcheck(1M)
-r Repair FHDB and FNDB entries. As a precaution, save a copy of the FHDB and FNDB before you alter it. See CAVEATS and EXAMPLES.
Note migdbcheck -r does not repair VOLDB entries.
-s Save the list of migrated files.
-p Correct all file paths in the FNDB for files that are migrated and copied. The original FNDB is saved in the filedwpath/database/FNDB.OLD.hsmname.pid.
-h Print help information about this command.
-c number_of_copiesUsed to override the configured number of copies. This value is used to determine if there are too few or too many copies. See EXAMPLES.
hsmname Name of the VSM managed file system to which the database belongs.
CAVEATS
◆ If migdbcheck is run while the migd migration daemon is active and the VSM state is Active, a warning message tells you that the results of this command may not be correct because of simultaneous migration activity. Nevertheless, VSM gives you an option to continue.
◆ If the -r option is specified, a warning message tells you that the results of this command may not be correct because of simultaneous migration activity. Nevertheless, VSM gives you an option to continue.
◆ If migbatch, miglow, or migmove run simultaneously with migdbcheck, the results of migdbcheck may be in error.
◆ Be sure to analyze very carefully any error messages generated by migdbcheck before taking corrective action. The examples that follow show only a few of the error situations that could arise.
EXAMPLE 1
The following example checks the file system that uses the FHDB and FNDB specified by hsmname alpha.
# migdbcheck -F alpha
318 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbcheck(1M)
Typical messages in response to this command are shown below:
-- INFO: There are 54 migrated files in the /alpha file system -- INFO: There are 54 migrated files. -- INFO: There are 1302 entries in the FHDB. -- INFO: 2 of the FHDB entries are place holders. -- ERROR: 1 FHDB entries with no file with a matching handle were found.-- INFO: 1 files have the error flag set. -- INFO: 2 files have fewer than 2 copies made. -- INFO: 21 files have more than 2 copies made. -- Extra copies found at level 1 -- Extra copies found at level 2
To repair FHDB entries, set the VSM state to Inactive and specify the -r option in the command:
# migdbcheck -F -r alpha
A typical error message in response to this command is shown below:
-- ERROR: 1 FHDB entries with no file with a matching handle were found.
You would be prompted as follows:
Do you wish to set them inactive?? [aynq](n):
Answering a will correct all the entries with no further prompting.
Answering y will then lead to a one-by-one listing of the problem entries, as shown below.
Answering n or q will move on to the next problem analysis and leave the file migdbcheck-orphan.pid in the /tmp directory.
Set handle: 00001000 flags: 00000000 path:alpha/test_foo to inactive? [aynq](n):
Answering a will correct all remaining entries without prompt.
Answering y will correct the entry.
Answering n will not correct the entry.
Answering q will stop processing the list and not correct any more errors.
Another response could report extra copies found at different migration levels.
-- INFO: 21 files have more than 2 copies made.-- Extra copies found at level 1-- Extra copies found at level 2
Appendix A, Man Pages 319
migdbcheck(1M)
It is possible to alter the flags field of the FHDB entry for these extra copies using the -i argument of the migsetdb command, but the administrator must first evaluate the files to decide which flags to alter for each level. The files migdbcheck-level-X.hsmname.pid in /tmp are used to indicate the files that exist at each migration level. The character X is replaced by the appropriate migration level, 1 through 8.
An error message alerts the administrator when files exist in the file system that can never be migrated because their full pathnames are too long.
-- WARNING: Files with path lengths exceeding 1024 were found in the file system.
The following information message indicates that VSM has cached some premigrated files before making any copies:
-- INFO: 6 cached files with no active entries in the FHDB were found.
Note If this message continually shows large numbers of files, VSM is selecting too many frequently accessed files for migration. Tune the file threshold formula to be less aggressive.
VSM lists all such files in verbose mode. Run migloc on each file so identified. There is no problem if the output resembles the following:
# migloc /alpha/raa/7/6/4/4/1/1/2/f0Status: Cached code raa /alpha/usr1/7/6/4/4/1/1/2/f0No matching entries found in the FHDB handle: A14C2.Problems getting migration data on file.
The next time the file gets migrated it will get a new handle and be placed in the copydb worklists.
EXAMPLE 2
The following example checks the file system that uses the VOLDB specified by hsmname delta.
# migdbcheck -V delta
Typical messages in response to this command are shown below:
-- INFO: checking hsmname=delta fspath=/delta-- INFO: There are 15 entries in the VOLDB.
If you have just installed VSM and have not registered any volumes using migreg or if no files have been migrated out, the following message appears:
-- WARNING: no volumes in VOLDB referenced by FHDB
320 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbcheck(1M)
If an entry is locked by the indicated process, the following message appears. This could occur if you run migdbcheck when VSM is actively being used and the migration daemon (migd) is running. See CAVEATS.
-- WARNING: VOLDB entry 00001000 is locked by 4660
VSM maintains the VOLDB in sorted order. If an entry is out of order, the following message error appears:
-- ERROR: /usr/var/openv/delta/database/VOLDB is not in the correct order! handle 1000 preceeded 999.You must sort the file and rerun migdbcheck. ABORTING
Use the sort command to put the VOLDB in sorted order.
Another typical error message in response to this command is shown below:
-- ERROR: Files on missing volid 00001000
To list all such FHDB entries, run migdbcheck in verbose mode.
# migdbcheck -Vv delta00001000|00D86BC0|00000000|0000101A|00000000|00019000|00000000|00000000|dt|||||l|1 0 00000004|00000000|||00000000|00000001|
A similar error message is produced by migdbrpt. The FHDB references a volume that is not in the VOLDB. In the example, volume ID 1000 was not in the VOLDB. Following the initial error is a display of the FHDB entries that reference the missing volume. Use this list to determine the specific files that the error affects and take the following actions:
1. If the missing entry exists on a recently backed up VOLDB, you may add that entry to the VOLDB.
2. Run migtscan, migopscan, migadscan, migftscan, or mignbscan on the volume. This creates a file dwpath/database/VOLDB.label. If this file looks reasonable, use an editor to insert this file into dwpath/database/VOLDB. Keep the file dwpath/database/VOLDB sorted with respect to handle and machine ID, which are the first two fields of each line. Rerun migdbcheck to determine the effect of this change.
3. If only a few files are affected, you can restore the user files from the site’s backup tapes and delete the entries from dwpath/database/FHDB.
Other typical messages indicate that no file currently references this volume:
-- 00000998 in VOLDB, but no FHDB reference to it-- Writing Entry 00000999 in VOLDB, but no FHDB reference to it
Appendix A, Man Pages 321
migdbcheck(1M)
This is normal if all of the files on the volumes have been cached or removed. Registered but unwritten volumes do not appear in this list. The first message indicates the writing flag is not set for the VOLDB entry; the second message indicates the writing flag is set for the VOLDB entry.
To list all such VOLDB entries for these volumes, run migdbcheck in verbose mode.
# migdbcheck -Vv delta0998|00d86BC0|00000000|00000000|A00001|dt||0|3BA73139|0230000| 0122466F|00E700019|0007a9e8|0||||HSM||| |
These volumes are good candidates for consolidation and reuse (see migcons(1M)). Before consolidating the second volume, run migdbcheck clear the write flag in its VOLDB flags field.
# migsetdb -Va delta A00001
EXAMPLE 3
The following example use the -c option to determine if the correct number of copies are being made.
The configuration of managed file system omikron set the number of copies to be 1.
In the example, the -F option requests that both the FNDB and FHDB are checked. The -c option queries if 2 copies of any files are being made:
# migdbcheck -F -c 2 xi
Typical messages in response to the command follow:
-- INFO: checking hsmname=omikron fspath=/omikron-- INFO: There are 4 entries in the FHDB.-- INFO: 1 of the FHDB entries are place holders.-- INFO: There are no valid active dk entries in the FHDB.-- INFO: There are 1 migrated files in the /omikron file system-- ERROR: 1 files have fewer than 2 copies made and are not found in a copydb.
The messages tell you that there is one migrated file in omikron, that it has fewer than 2 copies made, and that is not in a worklist file waiting to be copied for a second time. The configuration is working as configured, because only one copy should be made.
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
322 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbcheck(1M)
File handle database
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database
dwpath/database/FHSEQF
File handle sequence number file
dwpath/database/VOLSEQF
Volume ID sequence number file
dwpath/database/migconf
Configuration file for managed file systems
dwpath/database/FNDB.OLD.hsmname.pid
After migdbcheck corrects paths of all migrated and copied files, this path holds the original FNDB from before the corrections were made.
dwpath/workdir
VSM work directory
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
dwpath/database/hsmname.IHAND
VSM inode-to-handle file
/tmp/migdbcheck-migratedfiles.hsmname.pid
List FHDB inconsistencies discovered
/tmp/migdbcheck-movedfiles.hsmname.pid
List of all migrated copied files that have a path that is different than the path in the FNDB.
/tmp/migdbcheck-obsolete.hsmname.pid
A list of FHDB entries other than dk entries that are obsolete or dead but the files exist as migrated files in the file system
/tmp/migdbcheck-orphan.hsmname.pid
A list of migrated files that have an entry in the FHDB but the files do not exist
/tmp/migdbcheck-dk-orphan.hsmname.pid
Appendix A, Man Pages 323
migdbcheck(1M)
A list of files that have an active dk entry in the FHDB but the files either do not exist or are not migrated (data not on disk)
/tmp/migdbcheck-missing.hsmname.pid
A list of migrated files that do not have enough entries in the FHDB
/tmp/migdbcheck-dup-handles.hsmname.pid
A list of migrated files with duplicate FHDB handles
/tmp/migdbcheck-no-fhdb.hsmname.pid
A list of migrated files that do not have any entries in the FHDB
/tmp/migdbcheck-cached.hsmname.pid
A list of cached files that do not have any entries in the FHDB because they were cached before any copies were made
/tmp/migdbcheck-copies-needed.hsmname.pid
A list of files that do not have the required number of migrated copies
/tmp/migdbcheck-error-flag.hsmname.pid
A list of files whose FHDB entry contains an error flag that is either locked or failed
/tmp/migdbcheck-level-X.hsmname.pid where 1<= X <= 8
A list of files that exist at migration level X, where X represents migration levels 1 through 8, and there are more valid copies found than defined in migconf
The following output files are created and used by migdbcheck to list VOLDB inconsistencies discovered:
/tmp/migdbcheck-voldb-missing.hsmname.pid
A list of volumes in the FHDB that are not in the VOLDB. Verbose mode lists FHDB entries residing on the missing volumes.
/tmp/migdbcheck-voldb-consolidate.hsmname.pid
A list of volumes in the VOLDB with no FHDB references. Verbose mode lists VOLDB entries for these volumes.
/tmp/migdbcheck-voldb-writing.hsmname.pid
A list of volumes in the VOLDB that are in write mode with no FHDB references. Verbose mode lists VOLDB entries for these volumes.
The migdbcheck command checks the environment variable TMPDIR, which allows the administrator to use a path other than the default /tmp. This can save files through system reboots or make use of a larger file system to avoid running out of space. The path defined by TMPDIR, if set, is used instead of /tmp as the directory in which to place any temporary files. The process id of the migdbcheck that is executing replaces pid.
324 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbcheck(1M)
Files which could indicate problems or which could be used to obsolete or activate FHDB or VOLDB entries are left in /tmp (or the path defined by TMPDIR). No output files should be left if migdbcheck executes successfully and finds no errors.
Note Some output files created by migdbcheck may be used as input files for migsetdb.
SEE ALSO
migadscan(1M), migbatch(1M), migconfg(1M), migcons(1M), migdbrpt(1M), migftscan(1M), miglow(1M), mignbscan(1M), mignospace(1M), migtscan(1M), migopscan(1M), migrc(1M), migsetdb(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)
Appendix A, Man Pages 325
migdbconvert(1M)
migdbconvert(1M)
NAME
migdbconvert - convert FHDB into VSM 4.5 formatted FHDB and an FNDB
SYNOPSIS
/usr/openv/hsm/bin/migdbconvert [-b backupdir] hsmname
DESCRIPTION
The migdbconvert command converts VSM file databases from releases before 4.5 to VSM release 4.5 format.
The file handle database (FHDB) is a text database file in the database directory for each managed file system. In VSM release 4.5, a file name database (FNDB) also exists in the database directory. You must have a properly formatted FHDB and a FNDB for VSM release 4.5. Unless the conversion is run by the VSM installation script, the managed file system being converted must be in Maintenance state.
The migdbconvert command first checks to see if the current FHDB for hsmname appears to be in VSM 4.5 format. If it is, migdbconvert exits with exit status 0.
If you use the -b option to specify a backup directory, the original (pre-version 4.5) FHDB is moved to backupdir/hsmname.FHDB.prev. This is done before the conversion begins.
If you do not use the -b option to specify a different directory, the original (pre-version 4.5) FHDB remains in the database directory while the new FHDB and FNDB files are written. After the new files are created, the original FHDB is renamed FHDB.prev.
Not specifying the -b option requires more space in the VSM database directory. You will need enough space to hold the both the old and new databases.
OPTIONS
-b backupdirSpecifies a directory to be used for the backup copy of the FHDB.
hsmname Specifies the managed file system (hierarchy) name.
EXAMPLE
The following example shows the syntax for converting the database for hsmname xi. The backup copy of the FHDB is created in the directory /conversion/theta.
# /usr/openv/hsm/bin/migdbconvert -b /conversion/xi xi
SEE ALSO
VSM(1)
326 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbdir(1M)
migdbdir(1M)
NAME
migdbdir - get VSM information from the global configuration file
SYNOPSIS
/usr/openv/hsm/bin/migdbdir hsmname id
DESCRIPTION
The migdbdir command prints the desired value or device for the specified hsmname on standard output. The id specifies the desired information.
OPTIONS
hsmname Configured name of the managed file system about which to query.
id Integer identifying the desired information. Accepted values follow: 1 - Database path (dwpath) 2 - File system path (fspath) Requires that file system by mounted.3 - Log file path (lgpath) 4 - VSM state flag (state; the value in migconfg)5 - File system device number 6 - Mounted status7 - Mount point8 - migattr driver status. Returns yes or not based on the working status of the migattr driver (Solaris only)
EXAMPLES
The following example prints the device number of the managed file system delta.
# migdbdir delta 533554455
The following example prints whether or not the theta file system is mounted correctly. In this case, it is not mounted correctly.
# migdbdir theta 6not mounted
SEE ALSO
migconfg(1M)
Appendix A, Man Pages 327
migdbrpt(1M)
migdbrpt(1M)
NAME
migdbrpt - report on VSM migration database
SYNOPSIS
/usr/openv/hsm/bin/migdbrpt [-g] -f file_path hsmname
/usr/openv/hsm/bin/migdbrpt [-g] -h file_handle | -H hsmname
/usr/openv/hsm/bin/migdbrpt [-g] -l label | -a hsmname
/usr/openv/hsm/bin/migdbrpt [-g] -m method | -a hsmname
/usr/openv/hsm/bin/migdbrpt [-g] -s vol_set hsmname
/usr/openv/hsm/bin/migdbrpt [-g] -v vol_handle hsmname
DESCRIPTION
The migdbrpt command prints reports on database information maintained by VSM. Preserving periodic migdbrpt reports helps trace volumes for important files and make decisions on volume consolidation. The system administrator can issue migdbrpt at any time.
You can base enquiries about files on the following:
◆ file_path (-f option)
◆ file_handle (-h option) that VSM assigns to the file during the migration phase
The -H option displays information about all migrated files. The displayed information includes where the file is migrated, as well as the number of granules and the percentage of volume capacity for the file.
You can base inquiries about volumes on the following:
◆ Volume label (-l option)
◆ Method name (-m option)
◆ Volume set (-s option)
◆ Volume handle (-v option) that VSM assigns when the volume is registered with migreg
The -a option reports on all volumes. migdbrpt displays the percentage of the volume in use and the number of both live and obsolete granules on the volume. This information is useful in making decisions on consolidating volumes (see migcons(1M)). All numbers are displayed in decimal.
328 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbrpt(1M)
The migdbrpt command also displays database entries that have duplicate file handles or duplicate volume handles.
If a report indicates possible problems, use migdbcheck to verify the databases. Correct any database inconsistency immediately to guard against future catastrophe.
OPTIONS
-g Prints granule-related information. You can use this parameter with any of the other options.
-f file_pathReports on the file with the specified file path. The file path must be specified with the full path.
-h file_handleReports on the file with the specified file handle (specify the file handle in hexadecimal).
-H Reports on all migrated files.
-l label Reports on the volume with the specified label. You can use this option with the -m option to report on all volumes under a given method and label pair.
-m method Reports on all volumes registered under the specified method.
-a Reports on all volumes registered.
-s vol_setReports on all volumes registered under the specified volume set. You can use this option with the -m option to report on all volumes under a given method and volume set pair.
-v vol_handleReports on the volume with the specified volume handle (specify the volume handle in hexadecimal).
hsmname Configured VSM name for the managed file system containing the database files from which you want to derive the report.
EXAMPLE 1
The following example prints information about the /home/pjt/f1 file. Information is displayed about what volumes the file resides on, as well as its granule count and what percentage of the volume is occupied by this file.
# migdbrpt -g -f /home/pjt/f1 alpha
Appendix A, Man Pages 329
migdbrpt(1M)
The command results in a display similar to the following:
FILE_HAND VOL_HAND METHOD FIL_SIZE OFFSET GRN_SIZE F GRN# SEEKINFO FI.0009C2EA 00000000 dk 0072C668 00000000 0072C668 L 0 00000000 /home...0009C2EA * 00001004 dt 0072C668 00000000 00200000 L 4980 00000000 ...0009C2EA * 00001004 dt 0072C668 00200000 00200000 L 4980 00000041 ...0009C2EA * 00001004 dt 0072C668 00400000 00200000 L 4980 00000082 ...0009C2EA * 00001004 dt 0072C668 00600000 0012C668 L 4980 000000C3 ...
VOL_HAND LABEL POOL METHOD CAPACITY #LGNS #OGNS GRAN_USE...00000000 <=> DK0000 dk.0 17483290624 6...00001003 <=>C VLS001 HSM dt.1 293601280 114...00001004 <=>W VLS001 HSM op.1 375896384 57...
The columns in this display have the following meanings:
FILE_HANDFile handle for the file, followed by an asterisk (*) if locked.
VOL_HANDHandle assigned to the volume and referenced by entries in FHDB.
<*> Indicates this volume is currently locked for use
W Current volume to be written
<=> Indicates the volume has been written (if not followed by a letter)
C volume is corrupt- this volume will not be read or written
D Indicates a dead volum
E Indicates an empty volume
f Do not write to this volume
F Volume needs to be force labeled
L Volume needs to be labeled
T Volume needs a trailer label added or the volume is actually being written
METHOD Method name. Valid values are ct, dt, mt, op, ow, ad, ft, nb, and dk. In some displays the volume set number is also shown.
FILE_SIZESize of the file (hexadecimal).
OFFSET Offset from the beginning of the file for each granule.
GRN_SIZE Size of each granule in the file.
F File status: O for obsolete; L for active.
GRN# The number of the file on the media.
330 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migdbrpt(1M)
SEEKINFO Seek information for the file.
FILE_PATHFile path name.
LABEL Label specified when this volume was registered.
POOL Name of the volume pool for this volume.
#LGNS Total number of active granules on the volume. VSM derives this value from a scan of the FHDB.
#OGNS Total number of obsolete granules on the volume. VSM derives this value from a scan of the FHDB.
GRAN_USE Space used on the volume, in bytes.
PERCENT Percentage of space used on the volume. Anything over 86% may be full. If drivers compress the data before writing it to a volume, however, PERCENT could exceed 100 and the volume may still not be full.
LOC Path to the registered directory. This applies to methods ad, and ft.
SERVER Server name.
USER User name (root).
EXAMPLE 2
The following example prints a report on all volumes registered under the configured methods.
# migdbrpt -a alpha
The command results in a display similar to the following (this example has been truncated on the right):
VOL_HAND LABEL POOL METHOD CAPACITY #LGNS...00001000 <*>W OPT01A HSM op.1 375896384 572...00001009 <=>C TST003 HSM dt.1 293601280 1140...00000000 <=> DK0000 dk.0 17483290624 6083...00001001 <=>E OPT01B HSM op.1 293601280 0...
EXAMPLE 3
The following example prints information about volume rao001 under method ct. The display will include information about the migrated files, their granule count, and the volume occupancy.
# migdbrpt -g -l rao001 -m ct alpha
Appendix A, Man Pages 331
migdbrpt(1M)
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/migconf
Configuration file for managed file systems
dwpath/database/FHDB
File handle database for migrated files
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
migdbcheck(1M), migadscan(1M), migconf(1M), migconfg(1M), migcons(1M), migreg(1M), migtscan(1M), migopscan(1M)
332 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migfind(1M)
migfind(1M)
NAME
migfind - determine the full pathname of a file
SYNOPSIS
/usr/openv/hsm/bin/migfind -h file_handle -m machid hsmname
/usr/openv/hsm/bin/migfind -d DMAPI_handle hsmname
DESCRIPTION
The migfind command determines the full pathname of a file, given either its VSM file handle and machine ID or its DMAPI handle.
Output is displayed to standard output. Error messages go to standard error.
This command may be run without regard to the VSM state or whether the migd migration daemon is running, but the managed file system must be mounted.
OPTIONS
-h file_handleThe VSM file handle of the file. File handles are stored in the file handle database (FHDB) for the file system.
-d DMAPI_handleThe DMAPI file handle of the file.
-m machidThe integer (nonzero) identifier for the VSM-managed file system from which the file was migrated, as configured with the machid parameter in the DEFAULTS section of the dwpath/migconf file.
hsmname Configured VSM name that specifies the file system in which the file resides.
EXAMPLE
The following command determines the full path of a file in hsmname beta whose VSM file handle is 1f29 and machine id is 3e8.
# /usr/openv/hsm/bin/migfind -h 1f29 -m 3e8 beta/beta/acg/acg1
Appendix A, Man Pages 333
migfind(1M)
Identical results are achieved by using the DMAPI handle of the file, as follows (this command uses a UNIX continuation character; it is meant to be entered on one line).
# /usr/openv/hsm/bin/migfind -d 00000000008000\a90000000600000000000000000000001a0000010070c00080 beta/beta/acg/acg1
The following output shows the full path of a file in hsmname beta whose VSM file handle is 25c1 and machine id is 3e8, but reports that no FHDB entry exists for this file.
# /usr/openv/hsm/bin/migfind -h 25c1 -m 3e8 beta INFO: No FHDB entries exist /beta/acg/acg33
The following output reports that neither the FHDB entry nor the file exist for VSM file handle 25c1 in hsmname beta and machine id 3e9.
# /usr/openv/hsm/bin/migfind -h 25c1 -m 3e8 beta INFO: No FHDB entries exist No such file
The following output reports that the file with the specified DMAPI handle does not exist in hsmname beta (this command uses a UNIX continuation character; it is meant to be entered on one line).
# /usr/openv/hsm/bin/migfind -d 00000000008000\a90000000300000000000000000000001a0000010070c00090 betaNo such file
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
SEE ALSO
VSM(1M)
334 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migftscan(1M)
migftscan(1M)
NAME
migftscan - scan ft volume and reconstruct database entries for the ft storage method.
SYNOPSIS
/usr/openv/hsm/bin/migftscan [-F] [-n] [-s] hsmname label [server_name server_path [user]]
DESCRIPTION
The migftscan command scans a remote file system and displays information about the volume as a whole as well as information about each file granule on the volume. It also reconstructs the FHDB, FNDB, and VOLDB entries for all scanned granules.
The remote disk volumes are registered by using the migreg command before they can be used as archive media.
A file is migrated to a remote file system as a single granule. The granule header is separately archived in the remote file system as a file. The granule header contains FHDB, FNDB, and VOLDB entry information.
The migftscan command creates three output files: FHDB.label, FNDB.label and VOLDB.label, in the dwpath/database directory. The structure of these files is the same as the FHDB, FNDB, and VOLDB database files. These files may be used to rebuild the FHDB, FNDB, and VOLDB if they are corrupted or damaged (see migdbcheck(1M)).
Sorting and merging of FHDB.label files or FNDB.label files for different remote file systems can be used to recreate the FHDB and the FNDB. Similarly, merging multiple VOLDB.label files for different remote file systems can be used to recreate the VOLDB database.
Note When you recreate the VOLDB, ensure that you merge the VOLDB file (in the directory /usr/var/openv/hsm/example/database) to include the entry for the dk method.
OPTIONS
The following parameters are available:
-F Force scan the volume for granules in case the volume identity is not in the volume database (VOLDB). This parameter is optional. If omitted, the volume must be registered in the volume database. If specified, the optional parameters server_name server_path user must also be supplied. A password prompt is issued.
Appendix A, Man Pages 335
migftscan(1M)
-n Do not compress the FHDB entries for files found on the volume. When the -n option is used, no FNDB.label file is produced. This option is useful for examining what is actually written on the media. The FHDB.label file produced with the -n option must be run through migfdbconvert before it can be merged into the real FHDB and FNDB.
-s Silently scan the volume and create FHDB.label and VOLDB.label files, but do not display information on stdout.
hsmname Configured VSM name for the managed file system containing the database that has information on the desired volume.
label Remote-file-system volume label used when registering the volume. This parameter is required. For a force scan, you may specify label as anything.
server_nameName of the remote volume server. This can be the internet id or number. VSM uses this name on the ftp open command as the host parameter. It must be a valid ftp host. This parameter is required when you specify -F.
server_pathPath of the file system on the remote volume server. This parameter is required when you specify -F.
user User name used for the ftp login request when VSM migrates or caches files from the remote volume server. If you do not specify user, then root is assumed. This parameter is required when you specify -F.
CAVEATS
◆ Only the system administrator may use this command.
◆ The remote volume server file system must be available via ftp for this command.
◆ migftscan performance depends on the number of files and FTP performance.
EXAMPLE
The following example scans the archive disk volume FT005 that uses the ad method. The display shows a list of granule information for files archived on the volume. Files FHDB.FT005 and VOLDB.FT005 are created in the dwpath/database directory.
# migftscan openv2 FT0005 VOLUME FT0005 registered to HSMVolume Particulars ------------------ 000003E8V000010AF FT0005 ft 00000B71 00000883 #31 Volume label Found ====> hare:FT0005 ---------------- /usr/home/acg/ft_stor1/3E8M122D.1.
336 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migftscan(1M)
0.GLABEL <=> 0000000000100000000 Thu Apr 26 13:09:40 2001 /sd7/ov2fs/b1f2 /usr/home/acg/ft_stor1/3E8M1231.1.0.GLABEL <=> 00001036 00000000 Thu Apr 26 13:09:41 2001 /sd7/ov2fs/f1.c
/usr/home/acg/ft_stor1/3E8M1235.1.0.GLABEL <=> 000760000 0000000 Thu Apr 26 13:09:42 2001 /sd7/ov2fs/f1.x
/usr/home/acg/ft_stor1/3E8M1239.1.0.GLABEL <=> 00000F3B 00000000 Thu Apr 26 13:09:44 2001 /sd7/ov2fs/f2.sh
/usr/home/acg/ft_stor1/3E8M123D.1.0.GLABEL <=> 0000188E 00000000 Thu Apr 26 13:09:45 2001 /sd7/ov2fs/f3.rcs
/usr/home/acg/ft_stor1/3E8M1241.1.0.GLABEL <=> 0000565C 00000000 Thu Apr 26 13:09:47 2001 /sd7/ov2fs/f4.o
/usr/home/acg/ft_stor1/3E8M1245.1.0.GLABEL <=> 00001036 00000000 Thu Apr 26 13:09:48 2001 /sd7/ov2fs/f5.c.../usr/home/acg/ft_stor1/3E8M1276.1.0.GLABEL <=> 00002000 00000000 Thu Apr 26 13:10:07 2001 /sd7/ov2fs/k8f8
/usr/home/acg/ft_stor1/3E8M127A.1.0.GLABEL <=> 00001000 00000000 Thu Apr 26 13:10:08 2001 /sd7/ov2fs/kef4
/usr/home/acg/ft_stor1/3E8M1283.1.0.GLABEL <=> 00004592 00000000 Thu Apr 26 13:10:12 2001 /sd7/ov2fs/nrof.3
/usr/home/acg/ft_stor1/3E8M1287.1.0.GLABEL <=> 00002000 00000000 Thu Apr 26 13:12:52 2001 /sd7/ov2fs/k8f2
Volume particulars are displayed in the following order:
◆ volume handle
◆ volume label
◆ method
◆ total capacity of the volume
◆ total space in use on the volume
◆ number of granules on the volume
Particulars of granules are displayed in the following order:
◆ granule file name
◆ migrated file size
Appendix A, Man Pages 337
migftscan(1M)
◆ offset of the granule in the migrated file
◆ date of archiving the granule
◆ migrated file pathname
FILES
The dwpath is a directory in each managed file system that holds the database directory.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database for VSM
dwpath/database/migconf
Configuration file for VSM
dwpath/database/FHDB.label
File handle database for current volume
dwpath/database/FNDB.label
File name database for current volume
dwpath/database/VOLDB.label
Volume database for current volume
server_name:/server_path
File system on the server
SEE ALSO
migdbcheck(1M), migconf(1M), migconfg(1M), migdbrpt(1M), migreg(1M), migadscan(1M), mignbscan(1M), migtscan(1M), migopscan(1M)
338 VERITAS Storage Migrator System Administrator’s Guide for UNIX
miggetvol(1M)
miggetvol(1M)
NAME
miggetvol - print a list of VSM volumes on stdout by method name in ascending order of percentage utilization
SYNOPSIS
/usr/openv/hsm/bin/miggetvol hsmname [method]
DESCRIPTION
The miggetvol command prints a list of volumes registered under the specified method. This list is sorted by method name in ascending order according to the percentage of space used on the volumes. The total size of files currently migrated to the volume determines space used on the volume.
The entries in the list include the following:
labelmethod empty gran_count obsolete_gran percent_use% volume_set date_last_written
You can use miggetvol to monitor volume usage, such as required in determining when to consolidate volumes. The migselect command uses miggetvol for selection of volumes to consolidate.
You must have superuser (root) privileges to use miggetvol.
OPTIONS
-q Prints the command output without column headers. The default is to print the column headers. See EXAMPLES.
hsmname Configured VSM name for the managed file system containing the database files from which you want to derive the report.
method Method name under which miggetvol is to return information. By default, volumes under all methods are returned.
CAVEATS
◆ miggetvol does not consider granule space overhead on the volume in arriving at volume occupancy.
Appendix A, Man Pages 339
miggetvol(1M)
EXAMPLE
The following command prints a list of volumes on the managed file system hsm1.
# miggetvol hsm1LABEL METHOD FLAGS GRAN_CNT OBS_GRANS USE VOLSET LAST_WRITTEN C102A nb W 33 26 0.00 % 1 Mon Jan 14...E102B op E 0 0 0.00 % 1 Tue Jan 15...E102A op W 33 57 4.46 % 1 Wed Jan 23...DK0000 dk - 31 0 0.00 % 0 Wed Dec 31...2N512A op - 0 13 0.00 % 1 Tue Jan 15...2N512B op - 0 0 0.00 % 1 Mon Jan 14...
A W in the third column indicates writing. E indicates empty, D indicates dead, and the minus sign (-) is a place-holder indicating none of the above.
If you are using this command in a script and want to omit the column headers, you invoke it with the -q option, as follows:
miggetvol -q hsm1
The output for the script would be as follows:
C102A nb W 33 26 0.00 % 1 Mon Jan 14...E102B op E 0 0 0.00 % 1 Tue Jan 15...E102A op W 33 57 4.46 % 1 Wed Jan 23...DK0000 dk - 31 0 0.00 % 0 Wed Dec 31...2N512A op - 0 13 0.00 % 1 Tue Jan 15...2N512B op - 0 0 0.00 % 1 Mon Jan 14...
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/VOLDB
Volume database for VSM
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
migconfg(1M), migcons(1M), migdbrpt(1M), migselect(1M)
340 VERITAS Storage Migrator System Administrator’s Guide for UNIX
miggroup(1), migungroup(1)
miggroup(1), migungroup(1)
NAME
miggroup, migungroup - group files for migration and caching
SYNOPSIS
/usr/openv/hsm/bin/miggroup [-d] [-M] [-P] dir
/usr/openv/hsm/bin/miggroup -l [-v] dir
/usr/openv/hsm/bin/miggroup -u dir
/usr/openv/hsm/bin/migungroup dir
DESCRIPTION
The miggroup and migungroup commands let users premigrate and group all of the files in a directory and all of its subdirectories in VSM-managed file systems. Users with root privilege can group directories owned by any user. Other users can group their own regular directories if allowed to use this command.
For nonroot users, the miggroup and migungroup perform only the premigration phase of migration. Optionally, users can also purge copied files. The files in a grouped directory do not actually migrate to secondary storage until the next time mignospace, migbatch, migrc -R, or miglow execute. Users with root privilege can also optionally copy and purge premigrated files in a grouped directory.
Grouping causes files to be added to a tie group, MigGroup, as key caching files so they will be cached together when any one file in the group is cached. Files listed in global and local stop files are not included in the group.
Use the -l option to determine if a directory has been grouped, and to see the status of the files in that directory. Adding the -v option gives the status of each file in the directory. If many files in the directory are already migrated, they may reside on multiple volumes. This means the directory is fragmented. The -d option will defragment the directory by caching migrated files before grouping the directory.
After a grouped directory is migrated to secondary storage, accessing any purged file in the group causes VSM to transparently cache all of the files in the group back to disk. De-fragmenting a directory will cache and re-migrate previously migrated data to a minimal number of tapes, which reduces the mount time whenever the directory is cached.
Directory grouping is not dynamic. If files are created in a grouped directory, removed from the directory, or moved in or out of the directory, the grouping remains the same. It is good practice, therefore, to group active directories periodically.
Appendix A, Man Pages 341
miggroup(1), migungroup(1)
Normal file selection criteria are not applicable to miggroup, but normal VSM rules apply to files that have not been grouped in grouped directories, and these files continue to be selected, migrated, and cached individually.
The VSM state must be Active and the migration daemon migd must be running when you issue a miggroup command
Users can ungroup a grouped directory using either the migungroup command or miggroup with the -u option.
OPTIONS
-d Defragment the directory. If specified, all migrated files in the directory are cached and their FHDB entries are marked obsolete before the directory is grouped. If not specified (default), all migrated files in the directory remain migrated, and the directory is grouped. In either case, files not previously grouped are included in the grouped directory.
-M Run migbatch to make copies of the grouped premigrated files. Available only to users with root privilege, and generates an error message if used by nonroot users. If the directory is not yet grouped, this option groups the directory.
-P Purge copied files in the directory. If the directory is not yet grouped, using miggroup -P or migungroup -P groups the directory.
-l List the status of a directory without grouping the directory.When the -l option is used, only one offline volume is displayed. If VSM has multiple file copies, the volume displayed is the copy that can be most quickly cached.
-v Generate a verbose list showing the status of a directory. Must be used with the -l option.
-u Ungroup a previously grouped directory. Previously grouped migrated files are cached individually if accessed.
dir Path of the directory to group (relative or absolute).
CAVEATS
◆ By their very nature, grouped directories can increase migration and caching activity unnecessarily if used in situations where files are used individually. Group and migrate directories only where applicable.
◆ Files created in or moved to a grouped directory are not added to the group until the grouped directory is grouped again. Until they are added to the group, the grouped behavior of these files when cached is undefined.
342 VERITAS Storage Migrator System Administrator’s Guide for UNIX
miggroup(1), migungroup(1)
◆ Files moved out of a grouped directory remain in the directory group. The behavior of these files when cached is undefined.
◆ Unless specifying the -l option, the directory is grouped again each time miggroup is executed.
◆ The tie group name MigGroup is reserved for miggroup. Using this name for other uses may cause unpredictable behavior. Also using migtie and miggroup on the same directory and files will cause unpredictable results.
◆ Making changes to a directory while miggroup is processing the directory may produce unpredictable behavior. Do not access migrated files, add files, or remove files in the directory being processed by miggroup.
◆ Grouping and de-fragmenting a directory does not guarantee that all grouped files will migrate together. Other migration activity in the same file system may cause other files to get intermingled with the grouped files on the same media.
◆ Running two miggroup commands on the same directory at the same time may produce undefined results.
◆ Moving grouped directories or files will cause unpredictable behavior. It is best not to group directories that will be subject to moving.
◆ De-fragmenting a directory requires disk space to cache migrated files from secondary storage. If this space is not available the de-fragmenting operation will fail. If the operation fails, create space on disk and try again. A partially completed operation to defragment a disk may leave unnecessary data from migrated files on disk.
◆ If a migrated and purged file in a grouped directory is truncated to size zero, the migration daemon migd does not cache the file, nor does it cache any of the other files in the grouped directory.
◆ Files whose pathname length exceeds 1023 characters will not be migrated.
EXAMPLES
In the following example, the user requests that VSM group and premigrate all of the files in directory project123 without first de-fragmenting that directory.
# miggroup /home/abc/project123
In the following example, the user defragments directory project123 before grouping and pre-migrating all of the files in that directory.
# miggroup -d /home/abc/project123
If the user has root privilege, the following command defragments directory project123 before grouping, migrating, and purging all of the files in that directory.
# miggroup -d -MP /home/abc/project123
Appendix A, Man Pages 343
miggroup(1), migungroup(1)
The following command uses an absolute pathname to list the number of volumes holding data for the grouped files in the project123 directory.
# miggroup -l /home/abc/project123Regular 3 files 0.046080 MBGrouped 9 files 0.101412 MBNot Grouped 3 files 0.046080 MB
Migrated/Grouped files are on 1 volume.
The following command uses a relative pathname to list the number of volumes holding data for the grouped files in the project123 directory.
# miggroup -l project123Regular 3 files 0.046080 MBGrouped 9 files 0.101412 MBNot Grouped 3 files 0.046080 MB
Migrated/Grouped files are on 1 volume.
The following command gives a more detailed status of directory project123 by listing the number of volumes holding data for the grouped files in that directory on a file-by-file basis. Grouped files in subdirectories are also shown.
# miggroup -lv /home/abc/project123Regular 3 files 0.046080 MBGrouped 9 files 0.101412 MBNot Grouped 3 files 0.046080 MB
Migrated/Grouped files are on 1 volume.
Not Yet Copied 3 files 0.046080 MB State Size File m-- 15360 dir1/f4 m-- 15360 d1/d1/d3/d4/d5/d6/f4 m-- 15360 f4
Volume CT0001 9 files 0.101412 MB State Size File mg- 11268 f1 mgt 11268 f2 mg- 11268 f3 mg- 11268 dir1/f1 mgt 11268 dir1/f2 mg- 11268 dir1/f3 mg- 11268 d1/d1/d3/d4/d5/d6/f1 mgt 11268 d1/d1/d3/d4/d5/d6/f2 mg- 11268 d1/d1/d3/d4/d5/d6/f3
344 VERITAS Storage Migrator System Administrator’s Guide for UNIX
miggroup(1), migungroup(1)
Either of the following two commands will ungroup directory project123.
# miggroup -u /home/abc/project123# migungroup /home/abc/project123
FILES/usr/var/openv/hsm/database/migstop
Global stop file for VSM.
SEE ALSO
VSM(1M), migbatch(1M), migpurge(1), migrate(1), migsetdb(1M), migstage(1), migtie(1)
Appendix A, Man Pages 345
migin(1M)
migin(1M)
NAME
migin - cache a file from secondary storage to disk
SYNOPSIS
/usr/openv/hsm/bin/migin [-c] hsmname file_system machid file_handle
DESCRIPTION
The migin command caches a file in that has been removed or lost and therefore cannot be cached simply by accessing it. This command is useful in recovering files that were migrated or cached and then perhaps accidentally deleted. The file is cached to the original location as a regular file.
It is possible to recover the file only if an FHDB entry exists for a copy of the file on secondary storage. VSM automatically removes obsolete entries from the FHDB after 7 days.
This process does not restore original file ownership or mode bits.
This command may be run without regard to whether the migration daemon migd is running, but the VSM state must be Active or Maintenance.
OPTIONS
-c Specifes that migstage ignores checksum (crc) errors when caching files. Normally, when caching a file from tape the cache operation fails if the crc computed from the data does not match the crc in the granule header.When -c is specified, the cache operation succeeds even if the crc check fails. This option is intended to be used only as a last resort when a file cannot be recovered the usual way. The file data cached back with the -c option may not be the original file data.
hsmname Name of the managed file sytem that is controlling migrations for the file system in which the file you are recovering resided, as configured with the hsmname parameter in the /usr/var/openv/hsm/database/migconfg file.
file_systemPath to the file system that contained the file, as configured with the fspath parameter in the /usr/var/openv/hsm/database/migconfg file.
346 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migin(1M)
machid The integer (nonzero) identifier for the VSM-managed file system from which the file was migrated, as configured with the machid parameter in the DEFAULTS section of the dwpath/migconf file.
file_handleFile handle of the file you are recovering, as recorded in the FHDB.
CAVEATS
◆ If a file has been designated as a key caching file by the migtie command, caching that file manually with migin will not cause all migrated files in the associated group to be cached as well.
◆ If a file has been included in a grouped directory by the miggroup command, caching that file manually with migin will not cause all migrated files in the grouped directory to be cached as well.
◆ If both a file and its directory have been removed, migin will not cache the file until you have made a new directory with its full path to replace the original directory.
◆ Manual migin is not intended to be used on existing files. If migin is used on an existing purged file, the command restores the data and leaves the file in a purged state.
EXAMPLE
Assume you run migdbcheck and find that a file handle exists for a file that is not in the file system. Upon further checking you discover that you need this file. The file resided in the /project1 file system, was migrated by the managed file system zeta, the machine ID for the host is 3e8, and the file handle is 12d2. You execute the following:
# migin zeta /project1 3e8 12d2
The command restores the file to its original pathname as a regular, unmigrated file.
FILES/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
dwpath/database/migconf
Configuration file for managed file systems
SEE ALSO
migdbcheck(1M), migconf(1M), migconfg(1M), migreconstruct(1M), migpurge(1), migtie(1)
Appendix A, Man Pages 347
miglicense(1M)
miglicense(1M)
NAME
miglicense - displays the current license capacity of VSM
SYNOPSIS
/usr/openv/hsm/bin/miglicense
/usr/openv/hsm/bin/miglicense -l [-v]
/usr/openv/hsm/bin/miglicense -u [-f]
/usr/openv/hsm/bin/miglicense -a | -d textofkey
DESCRIPTION
The miglicense command determines the current license capacity of VSM. If used without options, miglicense displays the total valid capacity under license. The -l option displays an itemized list of each VSM license key including both valid and invalid keys.
You can compare the licensed capacity with the actual current capacity used on storage media by using the -u option. VSM issues a warning message when current capacity exceeds 90% of licensed capacity, and an error message when current capacity exceeds licensed capacity. When current capacity exceeds licensed capacity, VSM suppresses further migrations with migcopy until additional license keys are added.
Licensing is enforced when migcopy migrates data using the following storage methods: optical (op and ow), tape (ct, dt, and mt), and NetBackup (nb). Capacity includes active and obsolete granules, but not any granules marked dead.
Note The nb method will not be supported after the VSM 4.5 release.
VSM calculates current capacity and increments the total as new migrations occur, recording the sum in either /usr/var/openv/hsm/database/CAPACITY_USED1 or /usr/var/openv/hsm/database/CAPACITY_USED2. When VSM periodically recalculates current capacity, only one copy of each migrated file is counted, regardless of how many copies exist and the levels on which they are located.
Note VERITAS recommends the practice of making two copies of each migrated file.
348 VERITAS Storage Migrator System Administrator’s Guide for UNIX
miglicense(1M)
OPTIONS
-l [-v]Lists the text value and capacity of each VSM license key. The -verbose option is for debugging or customer support, and also displays NetBackup keys.
-u Lists the previously calculated, current capacity used on storage media.
-f Recalculate the current capacity used on storage media. Must be used with the -u option.
-a Add a license key of format textofkey.
-d Delete a license key of format textofkey.
textofkey The text of the license key in the format AAAA-BBBB-CCCC-DDDD-EEEE-FFFF.
CAVEATS
◆ Whenever current capacity exceeds licensed capacity, VSM suppresses further migrations with migcopy. This continues until licensed capacity is increased. During this period, migrated files can continue to be cached if there is enough free space on disk to hold them.
FILES/usr/var/openv/hsm/database/CAPACITY_USED1/usr/var/openv/hsm/database/CAPACITY_USED2
The current capacity used
SEE ALSO
VSM(1M)
Appendix A, Man Pages 349
migloc(1)
migloc(1)
NAME
migloc - display the location of a migrated file
SYNOPSIS
/usr/openv/hsm/bin/migloc [-R] pathname [pathname ...]
/usr/openv/hsm/bin/migloc -f filelist
DESCRIPTION
The migloc command shows attributes of and medium (volume) location of migrated files. The output includes obsolete FHDB entries for migrated files.
The resulting migloc display has the following format:
Status: type mach_name owner file_pathname Handle: mach_idMhandle file_size gran_count date_of_migration Medium: label method level gran_count seek_info vol_location
Status fields (if the file is not migrated, VSM generates only this field) are as follows:
type For a migrated file, type is one of the following: Premigrated, Migrated, Cached, Purged, Staging, or Partial. For other files, type is one of the following: Regular, Directory, Bloc-spl, Char-spl, Socket, Pipe, or Symb-link.
mach_nameHost name of the machine on which the file resides.
owner Owner of the file.
file_pathnamePathname of the file.
Handle fields are as follows:
mach_idMhandleMachine ID and file handle, in hexadecimal, separated by M.
file_size File size in bytes.
gran_countTotal number of active granules of this file on all media.
date_of_migrationDate when the file was last migrated.
350 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migloc(1)
Medium fields are as follows:
label Volume label.
method Volume method name and volume set number.
level Volume migration level.
gran_countNumber of granules (of the file) on this media.
seek_info Information used by VSM to get to the file on the media. The information printed depends on the volume method. For dk and ad it is the name of the corresponding file. For ct, dt and mt it consists of two numbers separated by a space ( ). The first number is the file number of the file on the volume relative to the beginning. The second number is the granule number of the first granule on the volume.
vol_locationPath to file system in which the volume resides. For the ft remote method, it indicates the location of both the server and file system in the format:
The method name indicates the type of media as follows:
ct Tape - as defined in migconf
dt Tape - as defined in migconf
mt Tape - as defined in migconf
op Optical disk - as defined in migconf
ow Optical disk - as defined in migconf
ad Alternate magnetic disk
dk Disk file (required for premigration)
ft Remote ftp method
nb NetBackup
Note The nb method will not be supported after the VSM 4.5 release.
After migration, the file data may exist both on disk and secondary storage until mignospace releases the space from disk. If the data still exists on disk, the display shows media type dk.
OPTIONS
-R Recursively list subdirectories encountered.
Appendix A, Man Pages 351
migloc(1)
pathname Files or directories that migloc should locate. If a directory is specified, all files in the directory and its subdirectories are located. May be given as a relative path or absolute path. You can specify multiple files or directories, or use standard regular expressions. Wildcards are recognized.
-f filelist Locate the files listed in filelist. The format of filelist is one file name per line, showing either the full pathname of each file or a pathname relative to the current directory in which migloc is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.
EXAMPLE 1
In the following example, the tproga file resides on cartridge tape and the data has not yet been purged.
# migloc tproga
Status: Migrated aspen root tprogaHandle: 3E8M10E0 133 49 Mon Jan 28 12:48:36 2002Medium: DK0000 dk.0 0 1 3e8M10e0 /sd7/ov2fs/migration/dataMedium: EXB007 ct.1 1 48 60/3055
EXAMPLE 2
In the following example, the acg1 file resides on a remote ft volume and has been purged.
# migloc acg1
Status: Purged star root acg1Handle: 3E8M140A 6 2 Wed Apr 11 08:09:52 2001Medium: DK0000 dk.0 0 1 3e8M140A /sdisk3/migration/dataMedium: FT0001 ft.1 1 1 3e8M140A.1.0 star:/sdisk4/ft_storage
SEE ALSOfls(1)
352 VERITAS Storage Migrator System Administrator’s Guide for UNIX
miglow(1M)
miglow(1M)
NAME
miglow - check the VSM-managed file systems for low space
SYNOPSIS
/usr/openv/hsm/bin/miglow [hsmname] | file_system]
DESCRIPTION
The miglow command maintains and manages disk space on a managed file system by initiating migration when free space is below the freespace percentage specified in the dwpath/database/migconf file.
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
miglow is used when the migration daemon is not automatically managing the free space for a VSM-managed file system. When a managed file system is in Maintenance state, you may wish to run miglow before changing the state to Active.
This command may be run without regard to whether the migration daemon (migd) is running. The VSM state must be Active or Maintenance.
OPTIONS
hsmname Configured VSM name for the managed file system that you want to check.
file_systemFull path name of the file system you want to check.
If you do not specify an hsmname or file_system, miglow checks all managed file systems.
SEE ALSO
VSM(1M), migconfg(1M), migbatch(1M), mignospace(1M)
Appendix A, Man Pages 353
migmdclean(1M)
migmdclean(1M)
NAME
migmdclean - clean VSM migration media
SYNOPSIS
/usr/openv/hsm/bin/migmdclean [-O] [-i] [-a days] [-R] [-S] hsmname label.method[.volset] [label.method[.volset]]...
DESCRIPTION
When a user modifies or deletes migrated files, VSM does not remove the migrated files and granules from the medium, but simply marks them as obsolete in the file handle database (FHDB). VSM is unable to reuse the space on the media until all FHDB entries for the volume are obsoleted and set to dead.
The migmdclean command cleans media and databases by setting obsolete FHDB entries to dead and then removing all dead FHDB entries. When all FHDB entries for a volume are dead, the -R option can remove the volume’s entry from the VSM volume database (VOLDB). You can then recycle the media by registering and relabeling it for use with VSM. By using the migselect command, you can select multiple media under different methods.
You can use the migrc command to remove obsolete and dead entries (see migrc(1M)). You can also use the migcons command to consolidate volumes and free them for reuse. However, migmdclean has additional options that may be useful under certain conditions. For example, if the medium is damaged you can use the -O and -R options to forcibly obsolete database entries and remove the empty volume from VSM.
For the ad and ft methods, migmdclean also attempts to remove files from the media when the MFLAG_OBSOLETE flag is specified in the dwpath/database/migconf configuration file for these methods.
For the ct, dt, mt, op, and ow methods, migmdclean never attempts to remove files from the media. If all granules on the volume are already dead, use migrecycle to reregister the media and remove files. If the volume contains obsolete granules, use migcons and then reregister the media with migreg to remove files. Although it is possible to clean ow media (write once, read many), it is not possible to recycle these optical disks.
Note When one side of an optical disk is consolidated, the volume entry for that input volume is not removed from the VOLDB unless and until both sides of that optical disk are empty.
354 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migmdclean(1M)
Note Although VSM sets FHDB entries to obsolete if a migrated file is modified or deleted, VSM must set these entries to dead before actually removing them from the FHDB. With the ad and ft methods, migmdclean may also unlink the file on the media so it is no longer possible to recover the data using VSM utilities. Prior to unlinking, you could recover the file by simply setting the corresponding FHDB entry back to active. In the following discussions, removal refers to unlinking and applies only to media used by the ad and ft methods.
OPTIONS
By default, migmdclean marks as dead all FHDB entries that have been obsolete for 7 days, regardless of the method or volume. For ad and ft volumes, the command also attempts to remove obsolete files from the media if MFLAG_OBSOLETE is set. For nb volumes, the command will expire the NetBackup image when the last FHDB entry to reference it is deleted.
Note The nb method will not be supported after the VSM 4.5 release.
-O This option forces valid FHDB entries to be obsolete. If -a 0 was specified, the valid FHDB are also forced to be dead.
Caution Use the -O parameter with extreme caution, as it might prevent user access to migrated files residing on the volume. See CAVEATS.
For ad and ft volumes, this option also attempts to remove the files from the media. If this option is not specified, migmdclean removes only currently obsolete entries.
-i Marks the FHDB entries as dead but inhibits removal of files from the media. If this option is not specified, VSM attempts to remove files. This option applies to the ad and ft methods.
-a days Selects only files that have been obsoleted for the specified number of days. The default is 7 days. An important use of the age parameter [-a days] is to specify that VSM delete only those files obsoleted prior to the last full backup.
-R Specifies that if all FHDB entries for the volume are dead, migmdclean removes the volume entry from the VOLDB. Doing this will also remove all dead volumes, not just the ones being cleaned. If this option is not specified, the volume remains in the VOLDB as a valid entry.
-S Activate obsolete and dead FHDB entries of all files with VSM handles.migmdclean -S applies to all files with VSM handles, not just those in the specified volumes.
Appendix A, Man Pages 355
migmdclean(1M)
FHDB dk entries are not activated with migmdclean -S.
hsmname Specifies the configured VSM name for the managed file system containing the database files for the volumes that you want migmdclean to process.
label.method.volsetSelects the media id that has a matching label in the volume set for the method. volset is optional. You can supply a list for this parameter.
CAVEATS
◆ When migmdclean is run to clean a specified volume, it will also remove all dead volumes, not just the ones being cleaned.
◆ Locked database entries for the media will cause the cleanup operation to fail. Run migrc -L prior to running migmdclean to unlock the locked entries.
◆ Execute migdbcheck before running migmdclean to ensure database consistency.
◆ Side effects of running migmdclean -a 0 -O -R after all copies have been made:
- If there is only one migrated copy and the file is purged from premigration, the file cannot be cached and the data is lost.
- If another active or obsolete copy exists and the file is purged from premigration, the file can still be cached.
- Unpurged files will not be purged and can still be cached.
- Copies of unpurged files will not be remade.
◆ If using NetBackup in conjunction with VSM, set the age variable for migmdclean at a value higher than the longest NetBackup retention period on the managed file system. Do this by adding the following line to /usr/openv/hsm/bin/cmd/migmdclean:
FLGS=”-a xxxx $FLGS”
The xxxx is the longest NetBackup retention period.
Next, remove the following line:
FLGS=“-a 7”
EXAMPLE
The following example removes obsolete FHDB entries at least 7 days old from media in cartridge disk rao001 volume set 1.
# migmdclean -a 7 alpha rao001.ct.1
356 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migmdclean(1M)
The following example selects media in alternate magnetic disk (ad) volume set 1 that have no active files and removes the granules from them. When removal is successful, the corresponding FHDB entries are marked as dead.
# migmdclean alpha ‘migselect alpha 0-0 1 ad‘
FILES
The term dwpath refers to the path name of the directory containing the database and workdir directories. The path name of this directory is site configurable
dwpath/database/FHDB
File handle database
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database
dwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
migdbcheck(1M), migreg(1M), migconf(1M), migconfg(1M), migcons(1M), migdbrpt(1M), migrc(1M), migrecycle(1M), migselect(1M), migactivate(1M)
Appendix A, Man Pages 357
migmove(1M)
migmove(1M)
NAME
migmove - move migrated files from one migration level to another level
SYNOPSIS
/usr/openv/hsm/bin/migmove [-A] [-m methname] [-f a | o | d] [hsmname | file_system]
/usr/openv/hsm/bin/migmove -c 1 | 2 [-A] [-m methname] [-f a | o | d] [hsmname | file_system]
/usr/openv/hsm/bin/migmove -s miglevel [-d miglevel] [-A] [-m methname] [-f a | o | d] [hsmname | file_system]
DESCRIPTION
The migmove command controls the movement of active migrated files from one migration level to another migration level. It scans the configured migration levels associated with the specified hsmname or file_system, selecting and moving files that meet the configured age and size criteria. A file is selected for movement if all of the following are true:
◆ The file is active (not marked error, obsolete or dead in the FHDB).
◆ The file’s calculated move threshold value is greater than or equal to the configured move threshold value for the source migration level. The file move threshold is calculated using either the standard move threshold formula (which factors in file age and size) or a site-specified move threshold formula.
◆ The destination migration level and corresponding storage method are configured in migconf.
◆ Any copy of the file at the destination migration level, even if that file has the error flag set or is marked obsolete or dead in the FHDB, will prevent a file from being selected to be moved to that level.
◆ The source migration level method name is ad, ct, dt, mt, op, or ow.
VSM supports a total of up to eight migration levels. By default the migmove command assumes there will be two migrated copies, and divides the eight migration levels into a symmetrical hierarchy where the first copy is associated with odd-numbered levels and the second copy is associated with even-numbered levels. Defaults are set accordingly.
Sites can create asymmetrical hierarchies by migrating only one file copy, or by specifying both the source and destination migration levels in migmove commands.
358 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migmove(1M)
Using the VSM-Java interface you may configure move criteria for migration levels or for method names or for both. Move criteria for migration levels, if specified, take precedence over move criteria for method names, if specified.
VSM first attempts to retrieve the data from the volume at the source migration level. If that fails, VSM attempts to retrieve the data from another volume regardless of its migration level, starting with the storage device with the shortest file transfer time.
After a file moves from a source migration level to a destination migration level, the file at the source level can remain active or it can be marked obsolete or dead. Volumes can later be consolidated and recycled to reclaim the file space occupied by obsolete and dead files.
The migmove command is generally run on a schedule created with the Scheduling tool.
OPTIONS
-c 1 | 2For -c 1, move copy 1 of the migrated files. In the default configuration with all eight migration levels configured, the source migration levels 5, 3, and 1 are processed in that order. Files at level 5 move to level 7, then files at level 3 move to level 5, and then files at level 1 move to level 3. Configured source migration levels are scanned only if their respective destination migration levels are also configured.For -c 2, move copy 2 of the migrated files. In the default configuration with all eight migration levels configured, the source migration levels 6, 4, and 2 are processed in that order. Files at level 6 move to level 8, then files at level 4 move to level 6, and then files at level 2 move to level 4. Configured source migration levels are scanned only if their respective destination migration levels are also configured.The default is move both copy 1 and copy 2 files when neither -c nor -s are specified. If -c is specified, -s cannot be specified.
-s miglevelMove files from the source migration level indicated by miglevel, where miglevel is an integer in the range 1 to 8. If the destination migration level -d is not specified, miglevel cannot equal 7 or 8. The default destination migration level is the source migration level +2.If -s is specified, -c cannot be specified.
Note When specifying the -s level, if the data selected to move is currently on disk, then the data will come from the disk and not the -s level specified.
Appendix A, Man Pages 359
migmove(1M)
-d miglevelMove files to the destination migration level indicated by miglevel, where miglevel is an integer in the range 1 to 8. The destination migration level cannot equal the source migration level. The default is the source migration level +2.If -d is specified, -s must be specified.
-A Select all files at source level ignoring selection criteria.
-m methnameScan for this method name when selecting and moving files for all source migration levels processed. Allowed values for methname are ad, ct, dt, mt, op, and ow. Default is to scan for all allowed and configured method names for all source migration levels processed.If -m is specified, either -c or -s may also be specified.
-f a | o | d For -f a, leave the FHDB entries for the selected files active at the source migration level.For -f o, mark the FHDB entries for the selected files obsolete at the source migration level.For -f d, mark the FHDB entries for the selected files dead at the source migration level. If the method name is ad, mark the FHDB entries for the selected files obsolete at the source migration level. When -f a|o|d is not specified, the default is what is specified in the migconf move flags.
-h Print help information.
hsmname Configured VSM name for the managed file system to be processed for moving files from one migration level to another migration level.
file_systemThe full path name of the file system to be processed for moving files from one migration level to another migration level. The hsmname for this file system must be in the Active or Maintenance state.If neither hsmname nor file_system is specified, all hsmnames are processed.
CAVEATS
◆ The defaults for migmove assume two migrated copies and a symmetrical hierarchy in which the first copy is associated with odd-numbered migration levels and the second copy is associated with even-numbered migration levels. To implement any other multilevel migration hierarchy, configure the migration levels you need and then specify both the source and destination migration levels in migmove commands.
360 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migmove(1M)
◆ If migmove is interrupted by a system crash, the last incomplete move by migmove of a file to another migration level will complete when the VSM startup script migrc -M is run.
◆ migmove will deadlock and time out if the same storage unit drive is the only one available to process files at both the source migration level and the destination migration level.
◆ The migmove command can be used to restore missing copies of files at METHOD1 (or METHOD2 if two copies of files are made). Before using migmove in this manner, change the state of the hsmname to Inactive. This avoids problems that may occur if either a migbatch or mignospace operation occurs simultaneously with migmove. You must specify hsmname in the migmove syntax.
◆ Do not run migcons and migmove simultaneously if they both are taking source from the same volumes. The results of such an action are undefined.
EXAMPLES
The hsmname for the file system to be processed in these examples is alpha.
The following example is the most general case.
# migmove alpha
It assumes there are two migrated copies and all eight migration levels are configured into a symmetrical hierarchy where the first copy is associated with odd-numbered levels and the second copy is associated with even-numbered levels. The default conditions will move selected primary and alternate files with any method name from source migration levels 5 and 6 respectively to their corresponding default destination migration levels, 7 and 8 respectively, and then process the other source migration levels in decreasing numerical sequence. After they are moved, selected files at all source migration levels are marked dead by default unless the method name is ad, in which case they are marked obsolete.
In the special case where only migration levels 1, 2, and 3 are configured, this same command
# migmove alpha
moves selected files with any method name only from source migration level 1 to default destination migration level 3.
The following example moves only copy 2 of migrated files. Assuming all migration levels are configured, the command moves selected files with method name ct sequentially from source migration levels 6, 4, and 2 to their default destination migration levels, 8, 6, and 4 respectively. After they are moved, selected files at all source migration levels are marked dead by default.
# migmove -c 2 -m ct alpha
Appendix A, Man Pages 361
migmove(1M)
The following example moves selected files with any method name from source migration level 4 to default destination migration level 6. After they are moved, selected files at source migration level 4 remain active.
# migmove -s 4 -f a alpha
The following example is that of an asymmetrical hierarchy where the destination migration level is specified to be something other than the default value (source migration level plus 2). This command moves selected files with any method name from source migration level 3 to destination migration level 4. After they are moved, selected files at source migration level 3 are marked obsolete.
# migmove -s 3 -d 4 -f o alpha
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database
dwpath/database/FNDB
File name database for VSM
dwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
dwpath/database/migsweep.site
Site migration and purge criteria
dwpath/database/migsweepm.site
Site move criteria
/usr/var/openv/hsm/example/database/sample.migpolicy.script
Sample migpolicy replacement script
SEE ALSO
migconf(1M), migconfg(1M), migpolicy(1M), migsetdb(1M)
362 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignbexport(1M)
mignbexport(1M)
NAME
mignbexport - export VSM files
SYNOPSIS
/usr/openv/hsm/bin/mignbexport [-s dir] [-e ExpLevel] [-S schedule] [-P policy] [-D timeout] hsmname
DESCRIPTION
The mignbexport command exports files from one VSM-managed file system so they can be imported into a different VSM-managed file system using the companion mignbimport command. Migrated files, if any, are not cached by either mignbexport or mignbimport.
Using this command requires that NetBackup be installed and running on the server executing mignbexport.
mignbexport does a user directed backup of the exported files and the FHDB entries and VOLDB entries for those exported files. These NetBackup images are exported to the site doing the mignbimport.
The backup is done using a NetBackup policy that must be defined in the NetBackup configuration prior to executing mignbexport. The NetBackup policy must define a NetBackup volume pool that contains volumes that can be sent to the site doing the mignbimport.
The VSM volumes that contain data for any migrated files being exported must also reside on VSM volumes that can be sent to the site doing the mignbimport.
There are two ways to export files.
◆ Export all migrated and unmigrated files residing in the specified subdirectory (dir) in the managed file system.
◆ Export all migrated files residing at export level ExpLevel. In this case, do not specify the -s dir option.
After mignbexport runs, the Volumes_to_export.pid file in dwpath/database contains a list of all VSM volumes that are exported. Additionally, the exported tapes now reside in the VSMEXP volume pool, which prevents these tapes from being overwritten with migrated files. Send all the exported volumes to the site that will import the data with the mignbimport command.
After mignbexport runs, the Client_name.pid file in dwpath/database contains the NetBackup client name that initiated the user directed backup. This client name is needed when doing the NetBackup import at the import site.
Appendix A, Man Pages 363
mignbexport(1M)
After mignbexport -s runs, the files_to_export.pid file in dwpath/database contains a list of all files that are exported.
After running mignbexport you must identify which NetBackup volumes belonging to the specified NetBackup policy were used during the mignbexport operation. Send these volumes to the site doing the mignbimport.
OPTIONS
-s dir Full path of the directory to export. This must be a subdirectory in the managed file system. mignbexport moves files in dir to ExpLevel and exports all migrated and unmigrated files in dir.Prior to running mignbexport a LEVELExpLevel must be configured and there must be VSM volumes registered for this LEVELExpLevel. After mignbexport moves migrated data to these VSM volumes, the volumes are sent to the site doing the mignbimport.All files residing in dir following a mignbexport operation remain there.If -s dir is specified and there are any migrated files in dir that reside at level ExpLevel prior to running mignbexport, the command will abort with an error message.If -s dir is not specified, mignbexport will only export files that currently reside at ExpLevel. No files will be moved to ExpLevel and unmigrated files will not be exported.
-e ExpLevel Migration level of volumes to export. Valid values range from 1 to 8. Default is 8. See the -s option for an explanation of the relationship between ExpLevel and dir.
-S schedule NetBackup schedule in policy to use for the user directed backup. The default is HSMEXPS. The schedule must be defined in the NetBackup configuration prior to running mignbexport.
-P policyNetBackup policy to use for the user directed backup. The default is HSMEXPC. The policymust be defined in the NetBackup configuration prior to running mignbexport. The policymust use NetBackup volumes that can be moved to the site doing the mignbimport.
-D timeoutA deadman timeout value in minutes. If NetBackup does not respond to the user directed backup request of mignbexport within the timeout period, mignbexport will abort. The default is 60 minutes.
hsmname The name of the file system from which files are exported. For more information, see migconf(1M).
364 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignbexport(1M)
CAVEATS
◆ All systems exporting and importing files between them must have unique Machine IDs for managed file systems. Valid hexadecimal values range from 1 to FFFFFF. The default is 1000.
◆ mignbexport does not supported embedded special characters in file names, such as asterisk, backslash, newline, parenthesis, question mark, right curly brace, square bracket, tab, or vertical bar (pipe).
◆ All systems exporting and importing files between them must have unique volume labels for the VSM volumes containing the migrated files being exported. These volumes are sent to the site doing the mignbimport.
◆ All systems exporting and importing files between them must have unique volume labels for the NetBackup volumes sent to the site doing the mignbimport.
◆ All systems exporting or importing files between them must have unique NetBackup client names for the client doing the user directed backup.
◆ If mignbexport does not terminate successfully you may have to cleanup the exporting file system before trying again. If the -s option was specified, the VSM volumes containing the migrated files being exported may have to be recycled.
◆ Configure the export migration level (ExpLevel) and corresponding level before using this command.
◆ Neither the ft or nb methods are eligible to be imported or exported.
Note The nb method will not be supported after the VSM 4.5 release.
EXAMPLE
In the following example, the exporting site will move copies of all migrated and unmigrated files in directory /delta/export/6/4 to default level 8 for export from file system delta. The NetBackup schedule is the default HSMEXPS, and the NetBackup policy is the default HSMEXPC.
# mignbexport -s /delta/export/6/4 delta
A typical response follows. Dots are printed in sequence while tapes are writing or rewinding.
Waiting on NetBackup backup ... Waiting on NetBackup to complete ...
The HSM volumes exported are listed in file/usr/var/openv/delta/database/Volumes_to_export.225The NetBackup client name is listed in file/usr/var/openv/delta/database/Client_name.225
Appendix A, Man Pages 365
mignbexport(1M)
The files exported are listed in file/usr/var/openv/delta/database/files_to_export.225
After mignbexport runs, remove the VSM volumes that are listed in Volumes_to_export.pid and send them to the importing site. Then, remove this media from VOLDB and your media manager volume database. Use the NetBackup and Media Manager interfaces to identify which volumes are in policy HSMEXPC, and also send the ones that have been written to the importing site.
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database for VSM
dwpath/database/migconf
Configuration file for VSM
dwpath/database/Volumes_to_export.pid
A list of all VSM volumes that are exported
dwpath/database/Client_name.pid
NetBackup client name
SEE ALSO
migconf(1M), migconfg(1M), migdbcheck(1M), migdbrpt(1M), mignbimport(1M), migmove(1M)
366 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignbimport(1M)
mignbimport(1M)
NAME
mignbimport - import VSM files
SYNOPSIS
/usr/openv/hsm/bin/mignbimport [-i ImpLevel] [-P policy] -m client_name [-D timeout] hsmname
DESCRIPTION
The mignbimport command imports files previously exported using the companion mignbexport. The managed file system must be active before you import files.
Using this command requires that NetBackup be installed and running on the server executing mignbimport.
mignbimport does a user directed NetBackup restore of the exported files and the FHDB entries and VOLDB entries for the exported files. This restore also includes information about the original path of the exported VSM-managed file system.
mignbimport merges the FHDB, FNDB, and VOLDB entries created by mignbexport into the FHDB, FNDB, and VOLDB of the importing managed file system, hsmname. When the files are restored, the portion of the path that was the original path of the exported VSM-managed file system is replaced with the path of the VSM-managed file system into which the files are being imported.
The VSM volumes that were exported must be placed in the desired library before running mignbimport. These volumes retain their original volume name so they must be unique. Do not register these volumes to VSM because mignbimport will take care of this automatically.
A NetBackup policy must be defined prior to running mignbimport and this policy must have the same name as the NetBackup policy used with the mignbexport. This policy must reference a NetBackup volume pool that contains only the NetBackup volumes that were written by mignbexport. The NetBackup volumes that were written by mignbexport must be imported into NetBackup at the site importing the files prior to running mignbimport. For more information on importing NetBackup images, see the NetBackup DataCenter System Administrator’s Guide for UNIX.
This command may be run without regard to the VSM state, but the migd migration daemon must be running.
Appendix A, Man Pages 367
mignbimport(1M)
OPTIONS
-i ImpLevel Migration level of the imported volumes. Valid values range from 1 to 8. Default is 7.mignbimport will change the FHDB entries for the imported files to indicate that the files reside at this level. mignbimport will also change the VOLDB entries for the imported volumes so they appear to be full and will never be written on again.
-P policy NetBackup policy to use for the user directed restore. It must be the same as the policy used with mignbexport. The default is HSMEXPC. The policy must be defined in the NetBackup configuration prior to running mignbimport. The policy must use NetBackup volumes that were exported from client_name and sent from the site doing the mignbexport. These volumes must be imported into NetBackup prior to running mignbimport.
-m client_name Name of the NetBackup client from which the VSM files were exported. See the dwpath/database/Client_name.pid file created when the mignbexport operation finished.
-D timeout A deadman timeout value in minutes. If NetBackup has not responded within the timeout period, mignbimport will abort. The default is 60 minutes.
hsmname The name of the file system to which the files will be imported. For more information, see migconf(1M).
CAVEATS
◆ All systems exporting and importing files between them must have unique Machine IDs for managed file systems. Valid numerical values range from 1 to FFFFFF. Default is 1000.
◆ All systems exporting and importing files between them must have unique volume labels for the VSM volumes containing the migrated files being exported. These volumes are sent from the site doing the mignbexport.
◆ All systems exporting and importing files between them must have unique volume labels for the NetBackup volumes sent from the site doing the mignbexport.
◆ Do not run mignbimport twice on a system to import the same files without first cleaning up any errors from the first run.
368 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignbimport(1M)
◆ Imported files lose any designations they may have as tied files, and must be redesignated. See man page migtie(1).
◆ Configure the import migration level (ImpLevel) and corresponding LEVEL before using this command.
◆ The NetBackup policy used for the user directed restore must match the NetBackup policy used in the mignbexport operation, and must be defined in the NetBackup configuration prior to running mignbimport.
◆ Imported VSM volumes must be loaded into a library prior to running mignbimport.
◆ The NetBackup volumes that were exported must be in a NetBackup pool referenced by policy, and must have been imported into NetBackup as client_name prior to running mignbimport.
◆ Neither the ft or nb methods are eligible to be imported or exported.
Note The nb method will not be supported after the VSM 4.5 release.
EXAMPLE
Place the NetBackup volumes containing files to be imported in the appropriate storage devices and register them with Media Manager for the importing VSM-managed file system, giving them a unique pool name. Define the NetBackup policy HSMEXPC to use this unique pool name
Using NetBackup, import the client client_name. In this example, this is hat.
Place the VSM volumes containing file data to be imported in the appropriate storage devices and register them with Media Manager for the importing VSM-managed file system, giving them a pool name of HSM. If this is not done, Media Manager will issue requests for the operator to assign this media.
In this example, the site will import copies of files to default level 7 on file system omikron. The name of the NetBackup client is hat.
# mignbimport -m hat omikron
A typical response is shown below:
Waiting on NetBackup restore in Phase 1...Waiting on NetBackup restore in Phase 2...mignbimport complete.
Note The dots are printed in sequence while tapes are reading or rewinding.
The imported files now are ready for access by VSM on the file system at the new location.
Appendix A, Man Pages 369
mignbimport(1M)
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database for VSM
dwpath/database/migconf
Configuration file for VSM
SEE ALSO
migconf(1M), migconfg(1M), migdbcheck(1M), migdbrpt(1M), mignbexport(1M), migmove(1M), migtie(1)
370 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignbscan(1M)
mignbscan(1M)
NAME
mignbscan - scan nb volume and reconstruct database entries for the nb storage method
SYNOPSIS
/usr/openv/hsm/bin/mignbscan [-s] [-h] hsmname label NB_master policy_name NB_client level
DESCRIPTION
Note The nb method will not be supported in the next release of VSM.
The mignbscan command scans a NetBackup policy and displays information about the volume as a whole as well as information about each file granule on the volume. It also reconstructs the FHDB, FNDB, and VOLDB entries for all scanned granules.
A file is migrated to NetBackup as a single granule. The granule header, <machid>M<handle>.GLABEL.<level>, is separately backed up as a file. The granule header contains FHDB, FNDB, and VOLDB entry information.
The mignbscan command creates three output files: FHDB.label, FNDB.label and VOLDB.label, in the dwpath/database directory. The structure of these files is the same as the FHDB, FNDB, and VOLDB database files. These files may be used to rebuild the FHDB, FNDB, and VOLDB if they are corrupted or damaged (see migdbcheck(1M)).
You can sort and merge FHDB.label and FNDB.label files for different volumes to recreate the FHDB and FNDB. Similarly, merging VOLDB.label files for different volumes can recreate the VOLDB.
When recreating the VOLDB, be sure to merge the VOLDB file in the /usr/var/openv/hsm/example/database directory to include the entry for the dk method.
OPTIONS
The following parameters are available under migftscan:
-s Silently scan the volume and create FHDB.label and VOLDB.label files, but do not display information on stdout.
-h Print help information.
hsmname Configured VSM name for the managed file system containing the database containing information on the desired volume.
label NetBackup volume label used when registering the volume. This parameter is required.
Appendix A, Man Pages 371
mignbscan(1M)
NB_masterName of the master NetBackup server for nb volumes. NB_master must be the first name the server is known by to NetBackup.
policy_nameName of the NetBackup policy. The NetBackup policy must be active.
NB_client Name of the NetBackup client. Check the NetBackup GUI to identify the correct value to use for client.
level The migration level of this volume. Valid values are 1 or 2.
EXAMPLE
The following example scans the NetBackup disk volume NB003 that is registered under the nb method. The NetBackup server is duo, the NetBackup policy is hsmnb2, the NetBackup client is trio, and the migration level for this volume is 1. The display shows a list of granule information for files backed up onto the volume. The FHDB.NB003 and VOLDB.NB003 files are created in the dwpath/database directory.
# mignbscan tau4 NB003 duo hsmnb2 trio 1Volume label Found ====> NB003 duo hsmnb2-------------------------------Obtaining list of granules.Restoring granule header files.../tau4/migration/data/3e8M24c5.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:35 2001 /tau4/files/a/tau4/migration/data/3e8M24c6.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:36 2001 /tau4/files/b/tau4/migration/data/3e8M24c7.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:36 2001 /tau4/files/c/tau4/migration/data/3e8M24c8.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:36 2001 /tau4/files/d/tau4/migration/data/3e8M24c9.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/e/tau4/migration/data/3e8M24ca.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/f/tau4/migration/data/3e8M24cb.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/g/tau4/migration/data/3e8M24cc.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/h
Particulars of granules displayed include (in order): granule file name, migrated file size, offset of the granule in the migrated file, date of backing up the granule, and migrated file pathname.
Including an incorrect policy name in the command gives the result shown in the following example:
372 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignbscan(1M)
# mignbscan tau4 NB003 duo badname trio 1Warning NO Volume label found active for duo badname
There are no output files, and the hsmlog contains the following message:
ERROR - the specified policy does not exist in the configuration database Policy:migrate exit code:230
Including an incorrect migration level in the command gives the result shown in the following example:
# mignbscan tau4 NB003 duo hsmnb2 trio 0Volume label Found ====> NB003 duo hsmnb2-------------------------------Obtaining list of granules.Restoring granule header filesNo files found in /tmp/mignbscan2.2401Z
There are no output files, and the hsmlog contains the following message:
ERROR 13:29:29 INF - Status = no files specified in the file list.
Including an incorrect NetBackup client in the command gives the result shown in the following example:
# mignbscan tau4 NB003 duo hsmnb2 badclient 1# echo $status4
The output files are deleted, and the hsmlog contains the following message:
ERROR: bpflist failure ABORTING no entity was found
Including an incorrect NetBackup server in the command gives the result shown in the following example:
# mignbscan tau4 NB003 badserver hsmnb2 trio 1# echo $status3
There are no output files, and the hsmlog contains the following message:
ERROR 13:33:38 INF - Status = no entity was found.
Appendix A, Man Pages 373
mignbscan(1M)
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database for VSM
dwpath/database/migconf
Configuration file for VSM
dwpath/database/FHDB.label
File handle database for current volume
dwpath/database/VOLDB.label
Volume database for current volume
SEE ALSO
migconfg(1M), migdbcheck(1M), migdbrpt(1M), migreg(1M), migadscan(1M), migftscan(1M), migtscan(1M), migopscan(1M)
374 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignewlog(1M)
mignewlog(1M)
NAME
mignewlog - truncate or restart and optionally make a copy of VSM logs
SYNOPSIS
/usr/openv/hsm/bin/mignewlog [-F] hsmname [destination_file] | GLOBAL [destination_file]
DESCRIPTION
VSM maintains a global log file for the VSM server and a separate log file for each hsmname in the /usr/var/openv/hsm/database/migconfg file.
◆ The pathname to the global log file is not configurable and is always /tmp/hsm.log (it may be a symbolic link).
◆ You define the log file paths for each managed file system during configuration. The term lgpath refers to these file paths.
VSM uses each hsmname’s log file lgpath and the global log file (/tmp/hsm.log) to store messages, status, and errors. To ensure that the global is maintained between boots and does not fill up the /tmp partition, you should link it to a file that resides on a file system other than /tmp.
If the lgpath or /tmp/hsm.log files become too large, you can use the mignewlog command to truncate or restart them and release the associated disk space. Note that using rm to remove the global log file /tmp/hsm.log does not release the disk space associated with that file if the migration daemon (migd) is running.
Before truncating or restarting any log files, you should inspect them for abnormal errors.
OPTIONS
-F Used to replace the contents of the destination_file. When this is not specified, the destination_file is NOT overwritten.
hsmname Configured VSM name for the managed file system containing the log file you want mignewlog to truncate or restart. If hsmname=GLOBAL, the command uses the global log file /tmp/hsm.log.
destination_fileIf you specify this parameter, mignewlog copies the log to the specified destination before truncating or restarting it. If you do not specify a destination_file, the log is removed.
Appendix A, Man Pages 375
mignewlog(1M)
CAVEATS
If migration to secondary media is taking place, the disk space for lgpath is not actually released until the copy-out operation completes.
FILES/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
/tmp/hsm.log
Global log file for the VSM server
SEE ALSO
migconfg(1M), migchecklog(1M), migrc(1M), startmigd(1M)
376 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignospace(1M)
mignospace(1M)
NAME
mignospace - make disk space available
SYNOPSIS
/usr/openv/hsm/bin/mignospace [-N] [-i | -h] hsmname | file_system
DESCRIPTION
The mignospace command attempts to make space available in the indicated file system. This command starts in either of two ways:
◆ The administrator executes it directly from the system prompt, from the VSM-Java interface, or with a crontab entry.
◆ A user attempts to write to the file system when the actual free space is less than the configured free space.
mignospace purges premigrated file space in a sequence determined by the purge threshold attributes configured for the file system. The default purge threshold attributes will purge space for the oldest files first, regardless of size. See migconf(1M).
mignospace starts by checking for premigrated files.
◆ If some premigrated files exist that exceed the purge threshold, mignospace either purges this premigrated file space to the purgemark percentage and stops or purges all this premigrated file space and stops, whichever comes first.
◆ If premigrated files exist but none exceed the purge threshold, mignospace cuts the current the purge threshold in half and exits.
◆ If there are no premigrated files, mignospace cuts the current threshold in half and selects enough files to increase free space to the freespace parameter percentage.
It then premigrates the selected files, copies them to secondary storage, and determines if any exceed the purge threshold.
If some premigrated files exceed the purge threshold, mignospace either purges the file space to the purge mark percentage and stops, or it purges all the file space and stops, whichever comes first.
If no premigrated files exceed the purge threshold, mignospace cuts the current purge threshold in half and exits.
migrc and migbatch reset current thresholds and current purge thresholds to their original dwpath/database/migconf values.
Appendix A, Man Pages 377
mignospace(1M)
If the migconf file specifies a lowwater value, mignospace selects only enough files to satisfy lowwater. If lowwater is unspecified, mignospace selects all files meeting the selection criteria. Files in premigration are not considered free, and files in .migrate are not used in calculating lowwater.
If the migconf file specifies a purgemark value, mignospace purges only enough premigrated file space to satisfy purgemark. If purgemark is unspecified, mignospace purges all premigrated file space. Use the -i option to ignore a specified purgemark value and purge all premigrated files.
The log for hsmname indicates the action taken by mignospace.
OPTIONS
-N Use accelerated disk space availability. The misweep and migcopy processes will quit before the threshold is reached in order to free some of the disk more quickly.
-i Ignore the purgemark and purge all available premigrated file space.
-h Print help information.
hsmname Configured VSM name for the managed file system in which you want to provide space.
file_systemFull path name of the file system in which you want to provide space.
CAVEATS
◆ Always maintain a sufficient number of VSM-registered tapes, optical platters, or alternate magnetic disks since mignospace may be started automatically by the system on low space conditions. See migreg(1M).
◆ The migration daemon migd and device-manager daemon (see ltid(1M)) must be running and the VSM state must be Active for mignospace to start automatically on low space conditions.
◆ Some processes spawned by mignospace create large temporary files and there may not be enough space in the /tmp directory for them. Define the environment variable TMPDIR to contain the pathname of a directory in a file system that has sufficient space available.
EXAMPLE
The following example, calls mignospace to increase the space available on the file system named /mig2 and then on the hsmname alpha.
# mignospace /mig2 # mignospace alpha
378 VERITAS Storage Migrator System Administrator’s Guide for UNIX
mignospace(1M)
FILESdwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
VSM(1M), ltid, migconf(1M), migconfg(1M), startmigd(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)
Appendix A, Man Pages 379
migpolicy(1M)
migpolicy(1M)
NAME
migpolicy - specify VSM policy and method to write files to secondary storage
SYNOPSIS
/usr/openv/hsm/bin/migpolicy hsmname inputfile [levelno]
DESCRIPTION
The migpolicy command reads the input file and adds the number of copies and the destination level to migcopy’s input script. The command is used whenever the controlling commands migbatch or mignospace are run. The migpolicy command calls migpolicy.script, which is responsible for filling in fields 5 (volset), 7 (method), 13 (hint), 14 (comment), and 15 (mmlevel) of the input file, and for placing the altered information on worklists, the names of which are echoed as an exit condition. (The migpolicy.script file is found in the admincmd directory of /usr/openv/hsm/bin/.)
Generally, you do not alter migpolicy or use it directly. However, it is possible to enhance the migpolicy.script to divert specific files to suitable media. You can divert files by file size, by owner, or by any other distinguishable file characteristic.
You change the behavior migpolicy.script by replacing it with an alternate script. The file /usr/var/openv/hsm/example/database/sample.migpolicy.script is a sample replacement that uses the size of a file to determine whether VSM will copy it to the primary level or to the alternate level.
OPTIONS
hsmname Configured VSM name for the managed file system from which you are migrating files.
levelno Level number that migpolicy will use. Level number 1 is the primary level, 2 is the alternate level, and 3-8 are multilevel migration levels.
inputfile List of files to be migrated; its format is similar to a copydb worklist:0000103A|000003E8|00000000|00000100|0|00000000|ad|| 0.92|512|472|/home1/migtie/asd|library|Auto HSM run|00000001|00000000|
The fields are as follows:1 2 3 4 5 6 7 8 9
handl|machid|lock|flags|volset|copd|meth|dst_seek|age|
10 11 12 13 14 15 16
size|threshold|path|hint|comment|mmlevel|slevel|
380 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migpolicy(1M)
This file is specified in the VSM controlling scripts.
CAVEATS
The migration level specified in migpolicy must be a valid level defined in the dwpath/database/migconf configuration file.
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
/usr/var/openv/hsm/example/database/sample.migpolicy.script
Sample migpolicy replacement script
/usr/openv/hsm/bin/admincmd/migpolicy.script
Migration policy script currently used
hsmname.copydb.method_name.vol_set_number.hint
VSM work lists
SEE ALSO
VSM(1M), migbatch(1M), migconf(1M), migconfg(1M), mignospace(1M)
Appendix A, Man Pages 381
migpurge(1)
migpurge(1)
NAME
migpurge - purge migrated file disk space
SYNOPSIS
/usr/openv/hsm/bin/migpurge filename [filename ...]
/usr/openv/hsm/bin/migpurge -f filelist
DESCRIPTION
The migpurge command purges disk space used by migrated files, which makes some disk space available immediately. The files are not purged unless copies have been made.
Users can purge files they own; root users can purge any files. For users, the VSM state must be Active; for root users the state can be Active or Maintenance. The migd migration daemon must be running.
The system administrator can ensure all migration copies have been made before using migpurge by running migrc -R hsmname first.
OPTIONS
filename Files to purge; may be a relative path or absolute path. You can specify multiple files, use standard regular expressions, or use wildcards.
-f filelist Purge the files listed in filelist. The format of filelist is one file name per line, showing the full pathname of each file or a pathname relative to the current directory in which migpurge is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.
EXAMPLES
The following command purges files listed in the input file purglist.
# migpurge -f purgelist
The following command purges files f4, f5, and f6 in the current working directory.
# migpurge f4 f5 f6
The following command purges all file space in the current working directory that have file names begin with the string July_15.
# migpurge July_15*
SEE ALSO
VSM(1M), fls(1), migloc(1), mignospace(1M), migrate(1)
382 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migrate(1)
migrate(1)
NAME
migrate - request premigration of a file
SYNOPSIS
/usr/openv/hsm/bin/migrate [-F] filename [filename ...]
/usr/openv/hsm/bin/migrate [-F] -f filelist
DESCRIPTION
The migrate command lets users request that VSM migrate a file to secondary storage. Users can premigrate regular files that they own in VSM-managed file systems if allowed to use this command. The system administrator must provide the proper permissions before users can use this command.
All files specified with a single migrate command must be in the same managed file system. The first file determines that file system.
Use the fls command to determine if a file has been migrated or premigrated.
The migrate command performs only the premigration phase of migration. The files do not actually migrate to secondary storage until the next time mignospace, migbatch, or miglow execute. After a file is migrated to secondary storage, accessing it causes VSM to transparently cache the file back to disk.
If the migrate command is used to premigrate an unmodified cached file for which enough valid copies already exist in secondary storage, VSM does not recopy the file. VSM purges the data immediately from disk if the dk method entry for the file does not exist in the FHDB, otherwise the data is purged later by mignospace. Use the migloc command to determine whether or not file data was purged; if the file remains in premigration, migloc will show a dk method entry for the file.
The migrate command creates a list of files in /tmp/migrate_list.pid that meet the migration file selection criteria. The pid is the process ID of the migrate command that is executing. This list is of the following form:
age size 0|0|path|machid|handle|
where the third field is a default threshold value of 0, and the fourth field is 0 which indicates the migration level for premigration. The machid and handle are both 0 if the file has never migrated before.
Appendix A, Man Pages 383
migrate(1)
OPTIONS
-F Force file migration even if the file is listed in the global stop file or a local stop file, .migstop. This argument is applicable only to Super Users or to owners of the file.
filename Files that migrate should migate. May be given as a relative path or absolute path. You can specify multiple files or use standard regular expressions. Wildcards are recognized.
-f filelist Migate the files listed in filelist. The format of filelist is one file name per line, showing either the full pathname of each file or a pathname relative to the current directory in which migrate is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.
CAVEATS
◆ Unless the -F argument is given, migrate will not premigrate any files listed in the global stop file or in a local stop file, .migstop, unless the stop file is overridden. A typical error response is as follows:
/ov2/stop/nono found in user stopfile not allowed to migrate
The .migstop file most local to the listed file overrides other stop files higher in the directory tree. Local control files override global control files if the same file or directory is listed in both. If the same file is listed in both a .migrate file and a .migstop file at the same level, the .migrate control file overrides the .migstop file.
◆ Files whose pathname length exceeds 1023 characters will not be migrated.
◆ For non-root users, this command requires that VSM state be Active and the migration daemon migd be running. For root users, this command may be run without regard to the VSM state or whether the migration daemon is running.
EXAMPLES
In the following example, the user requests that VSM migrate a file named tproga.
# migrate /home/gls/tproga
In the following example, the user has a file named migrate_list that contains a list of files to be migrated, one file per line.
# migrate ‘cat migrate_list‘
384 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migrate(1)
The following example uses the find command to select for migration all regular files under a directory, and then uses fls to check if they are migrated.
# migrate ‘find /home/gls/hawks -type f -print‘
# fls -l /home/gls/hawks total 94 mr--r--r-- 1 root other 23368 May 9 17:20 osprey mr--r--r-- 1 root other 23368 May 9 17:21 peregrine
FILES/usr/var/openv/hsm/database/migrate
Global migrate file for VSM
/usr/var/openv/hsm/database/migstop
Global stop file for VSM
The following output file is created and used by migrate to premigrate files:
/tmp/migrate_list.pid
A list of files in the file system that meet the migration file selection criteria
The pid is the process id of the migrate command that is executing. migrate checks the environment variable TMPDIR, which allows the administrator to use a path other than the default /tmp. This can save files through system reboots or make use of a larger file system to avoid running out of space. The path defined by TMPDIR, if set, is used instead of /tmp as the directory in which to place any temporary files.
SEE ALSO
VSM(1M), fls(1), migloc(1), migmode(1), migpurge(1)
Appendix A, Man Pages 385
migrc(1M)
migrc(1M)
NAME
migrc - VSM restart and cleanup operations
SYNOPSIS
/usr/openv/hsm/bin/migrc [-LRSMh] [-o | -O db_type] [-a age] hsmname
DESCRIPTION
The migrc command provides a variety of functions. Some are intended to be used when restarting VSM operations on a managed file system and some are intended to be used as part of regular VSM operations.
Except for the -L option, this command may be run for file systems in the Active, Inactive, or Maintenance states. The -L option should only be used on a managed file system in the Inactive or Maintenance state.
The copy activities initiated by the -R and -M options will continue even after the migrc command has completed.
OPTIONS
At least one of the options L, R, M, h, o or O must be specified.
-L Clear all locks. This option is intended for use only when restarting VSM operations for a file system. migrc -L may be called by the migVSMstartup command for this purpose. migrc -L can only be used for file systems in Maintenance state.
-R Restart interrupted premigration and migration. Execute migrc -RM following a system interrupt to ensure that any unfinished migration and multilevel migration (migmove) work is completed.
-S Activate obsolete and dead FHDB entries of all files with VSM handles.The -S option requires at least one option to be specified with it. For example, migrc -R -S HSM1 or migrc -O FHDB -S HSM1.FHDB dk entries are not activated with migrc -S.
-M Restart interrupted migmove work and FHDB flag updates. Execute migrc -RM following a system interrupt to ensure that any unfinished migration and multilevel migration (migmove) work is completed.
-h Print usage information.
386 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migrc(1M)
-o (A lowercase o) Remove obsolete/dead entries from all three databases: FHDB, VOLDB and COPYDB.
-O db_type(An uppercase O) Remove obsolete/dead entries from the single database type specified by db_type: FHDB, VOLDB or COPYDB.
-a age The age parameter indicates the age (in days) of obsolete entries to remove from the FHDB. The default age is 7 days. This argument only has meaning when used in conjunction with either the -O FHDB option or with the -o option as it pertains to FHDB entries.
Caution You should use the age parameter to specify removing only files that were obsoleted prior to the last full backup.
hsmname Configured VSM name for the managed file system that you want VSM to process.If you do not specify hsmname, migrc performs the selected operation(s) on all VSM-managed file systems.
CAVEATS
◆ Ensure that a sufficient number of volumes are available for migrations that may occur when you run migrc. Use migreg to register volumes.
◆ Running migrc resets the current threshold and current purge threshold to their respective values as specified in migconf.
◆ If using NetBackup in conjunction with VSM, set the age variable for migrc at a value higher than the longest NetBackup retention period on the managed file system. Do this by changing the line AGE=7 to AGE=nnn
where nnn is the longest NetBackup retention period.
◆ If MFLAG_OBSOLETE is set, dk entries will stay in the FHDB when migrc is run. This allows a cached file to be returned to premigration and processed by normal purge operations. To remove these dk entries and reduce the size of the FHDB, run migmdclean.
◆ When migrc completes there may still be VSM processes running that migrc has started.
SEE ALSO
VSM(1M), migconfg(1M), migreg(1M), startmigd(1M), stopmigd(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M), migactivate(1M)
Appendix A, Man Pages 387
migrd(1M)
migrd(1M)
NAME
migrd - VSM request daemon
SYNOPSIS
/usr/openv/hsm/bin/admincmd/migrd
DESCRIPTION
Running migrd as a command starts the migrd request daemon. You must have super-user privileges to execute this command.
migrd is the VSM request daemon (migrd).
You should ensure that migrd is started as part of your system startup. If migrd is not running when you run /usr/openv/java/migsa to start VSM-Java, the GUI cannot connect to the server, and the migsa command fails.
SEE ALSO
VSM(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)
388 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migreconstruct(1M)
migreconstruct(1M)
NAME
migreconstruct - Reconstruct lost or deleted migrated files
SYNOPSIS
/usr/openv/hsm/bin/migreconstruct [-v] [-n] [-o] [-p permissions] [-l out_file | -f | -w in_file] hsmname
DESCRIPTION
The migreconstruct command reconstructs migrated files either when they have been accidentally deleted or when the file system is damaged beyond repair. (The command cannot reconstruct files that have not been migrated.) The preferred way to do this is to restore migrated files from their backup copies, if created previously by NetBackup. If no backup copies exist, however, use migreconstruct to recover the migrated files. migreconstruct uses information in the file handle database (FHDB) to do the reconstruction.
If you are reconstructing a damaged file system, you must first re-initialize the file system. Use fsck, newfs, or mkfs as necessary. The hsmname.IHAND (inode-to-handle) file must be removed before starting migd. The path to the managed directory must exist. And, lastly, the migration/data directories must be created in the managed directory.
The migreconstruct command does not overwrite existing files unless the -o option is specified. In all other cases, it only reconstructs lost or deleted migrated files.
OPTIONS
The following options and parameters are available with migreconstruct:
-f Reconstructs all files that have an entry in the FHDB. This parameter may not be used with -l or -w. Default is no files are reconstructed.
-l out_fileLists in out_file all files that have an entry in the VSM file handle database (FHDB). Does not reconstruct any of these files. This parameter may not be used with -f or -w. Each line in out_file contains the following information:handle|machid|size|uid|gid|permissions|file_path
The handle and machid fields are in hexadecimal; size, uid and gid are decimal; and permissions is octal. Default is no out_file.
-n Do not sort FHDB in reverse order. If the FHDB is not sorted in reverse order, the oldest version of a file will be created. The default is to sort the FHDB in reverse order.
Appendix A, Man Pages 389
migreconstruct(1M)
-o Overwrite existing files. The default is to never recreate an existing file.
-p permissions Permissions to be used if the VSM database entry for the file does not contain the mode of the file. permissions is assumed to be an octal value; the default is 1755. Entries get their permissions from the mode information in the VSM database, with a few exceptions. All files created as a result of the -f option that do not have mode information will be given these permissions, and all entries in the out_file that do not have mode information will be given these permissions. The permission field in the in_file overrides permissions.
-w in_file Reconstructs all files listed in in_file. This parameter may not be used with -l or -f. Each line in in_file should contain the following information:handle|machid|size|uid|gid|permissions|file_path The handle and machid fields are in hexadecimal; size, uid and gid are decimal, and permissions is octal. file_path may be set to any full path in the managed file system. Default is no in_file.
-v Verbose; lists the full path of all files reconstructed. Default is none are listed.
hsmname Name of the file system that VSM is managing.
Note One of the options -l, -f, or -w is required to run migreconstruct.
To restore accidentally deleted files, create proper in_file entries and use migreconstruct with the -w option.
CAVEATS
◆ migreconstruct requires that the VSM state to be Active or Maintenance.
◆ All directories created by migreconstruct belong to the user of this utility, and take on whatever permissions are set in the user’s umask. This would normally be root.
◆ migreconstruct will not reconstruct files from method dk.
◆ migreconstruct will reconstruct obsolete migrated files if VSM has not yet removed their corresponding FHDB entry. Obsolete files are no longer obsolete after they have been reconstructed.
◆ Moved or renamed migrated files will be reconstructed in their original locations according to the full path recorded in the FHDB when the files were first migrated.
◆ All reconstructed files will have a 0 slice value.
390 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migreconstruct(1M)
EXAMPLE
In the following example, all files that have a full path in the FHDB of VSM-managed file system alpha will be reconstructed and granted default permission 1755.
# migreconstruct -v -f alpha
In the following example, all files in VSM-managed file system openv2 with the path name /tmp/out_list will be reconstructed.
# migreconstruct -w /tmp/out_list openv2
The file /tmp/out_list contains the following lines:
1861|3e8|105|0|1|1755|/home1/home1/file-23_#1862|3e8|108|0|1|1755|/home1/home1/file-24_$1863|3e8|111|0|1|1755|/home1/home1/file-25_%1864|3e8|114|0|1|1755|/home1/home1/file-26_&1865|3e8|117|0|1|1755|/home1/home1/file-27_’
This shows the handle machid size uid gid permissions and file_path for the five files to be reconstructed.
FILESdwpath/database/FHDB
File handle database
dwpath/database/FNDB
File name database
SEE ALSO
VSM(1M), migin(1M), newfs, fsck, mkfs, pfinit(1M)
Appendix A, Man Pages 391
migrecycle(1M)
migrecycle(1M)
NAME
migrecycle - Reregister an empty volume
SYNOPSIS
/usr/openv/hsm/bin/migrecycle [-h | -a days -v volset -P poolname -d device -c capacity -s server -u user -l new_label -p password] hsmname label method
DESCRIPTION
The migrecycle command reregisters an empty, registered VSM volume.
If the volume is not empty, an error is produced without any change in registration. A volume is considered empty either if it has no FHDB entries for granules or if all FHDB entries for granules on the volume are marked dead.
The volume is reregistered with the parameters in the VOLDB unless they are specified as migrecycle options. The volume set, volume pool, device, capacity, server, and the password may be changed by supplying them on the command line. migrecycle maintains the volume assignment to the current file system and volume set.
Note When one side of an optical disk is consolidated, the volume entry for that input volume is not removed from the VOLDB until both sides of that disk are empty.
migrecycle first calls migmdclean -a days -R with the supplied label and method to remove dead FHDB entries. This is followed by a call to migreg, if the volume is now empty. migmdclean removes obsolete entries from the FHDB that are at least days old. Note, that 7 days is the default value for days defaults. For optical disks, migrecycle trys to recycle both sides of the disk. If migrecycle is asked to alter attributes on an optical disk, both sides of the disk must be empty before a side is recycled.
VSM always cleans obsolete entries that are days old, even if the volume cannot be recycled.
After a volume is reregistered, any data previously stored on it can no longer be recovered.
OPTIONS
The following options and parameters are available with migrecycle:
-a days Select only obsolete FHDB entries aged by days when cleaning the FHDB. The default value is 7 days.
392 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migrecycle(1M)
-v volset Volume set number used to reregister this volume. If not specified, the volume set number is not changed.
-P poolname The name of the volume pool if other than the default, HSM.
-d device For recycling ad method volumes, this is the path to the file system. For recycling ft method volumes, this is the file system path on the remote volume server.
-c capacityCapacity of the remote file system for the ft method.
-s server Name of the remote volume server system for ft method.
-u user For the ft method, this is the valid ftp user name on the remote volume server system.
-p password
For the ft method, this is the name of the server password.
-l new_label Label used to reregister the volume.
-h Print help information.
hsmname Configured VSM name for the managed file system containing the database that has an entry for the volume you are recycling.
label This is the name of the label that VSM assigns to the remote file system for identification. The label is a single line of text in a file named ID_LABEL that is stored in the remote file system.
method Volume method name. It can be ct, dt, mt, ad, op, or ft. Volumes for the ow and nb methods cannot be recycled.
Note The nb method will not be supported after the VSM 4.5 release.
If the method is ft, a prompt is issued for the password when the volume is reregistered.
CAVEATS
◆ When recycling an ft volume, the remote file system must be available so the ID_LABEL file, if present, can be read.
◆ If one side of a rewritable optical disk (method name op) is empty and the other contains granules, you can recycle the empty volume but not change its attributes, and the volume set number remains the same for both sides.
Appendix A, Man Pages 393
migrecycle(1M)
EXAMPLE
In the following example, an mt volume EXB001 is reregistered in volume set 1.
# migrecycle -v 1 alpha EXB001 mt
FILESdwpath/database/VOLDB
Volume database.
dwpath/database/migconf
Configuration file for the managed file system(s).
SEE ALSO
VSM(1M), migreg(1M), migmdclean(1M)
394 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migreg(1M)
migreg(1M)
NAME
migreg - Register and label volumes for VSM
SYNOPSIS
/usr/openv/hsm/bin/migreg [-F] [-D] [-P poolname] hsmname methname volume_set_number volume_name [volume_name]...
/usr/openv/hsm/bin/migreg [-F] hsmname ad volume_set_number mount_point volume_name [mount_point volume_name]...
/usr/openv/hsm/bin/migreg [-F] [-u user [-p password]] hsmname ft volume_set_number server_name server_directory capacity volume_name [server_name server_directory capacity volume_name]...
/usr/openv/hsm/bin/migreg [-F] hsmname nb volume_set_number policy_name NB_master NB_client schedule capacity volume_name [schedule capacity volume_name]...
DESCRIPTION
The migreg command registers and labels volumes for VSM.
For local secondary storage, you can register tapes for use by method names ct, dt, and mt, or optical disk surfaces for use by method name op or ow. You can also register disk partitions as alternate magnetic disk volumes for use with method name ad.
Note When using migreg to register and label new, unused tape volumes, it is normal behavior to receive some routine error messages.
For remote secondary storage, you can register remote file system directory names for use by method name ft. You can also register disk partitions as alternate magnetic disk volumes for use with method name ad on remote systems. You can register a NetBackup policy as a volume for use by method name nb.
Note The migreg command does not register volumes for method name dk.
migreg registers all volumes in the VSM volume database, dwpath/database/VOLDB for the hsmname. After registration, VSM can use these volumes on subsequent migrations requiring the corresponding method name associated with each volume.
OPTIONS
The following options and parameters are available with migreg:
Appendix A, Man Pages 395
migreg(1M)
Caution Use the -F option with extreme caution, as it may prevent access to files already migrated to the volume.
-F Forces the relabeling of a previously labeled volume. The volume must not be registered currently in any VSM volume database. If necessary, you can use migmdclean -R to remove an entry from a VOLDB. You may also use migsetdb to set an empty volume to dead in a VOLDB so it can be removed by migrc and relabled by migreg. If -F is not specified, VSM returns an error if you attempt to register a volume that has already been labeled.
-D Delay labeling of tape or optical disk until needed. This argument affects only volumes registered for the ct, dt, mt, op, and ow method names. If specified for other method names, VSM posts a message and then proceeds with the normal registration process. If -D is not specified, the volume is labled at the time migreg is run.
-P poolname The name of the volume pool if other than the default, HSM.
-u user User name used for the ftp login request when VSM migrates files or caches files from the server with method name ft. If not supplied on the command line, it is read from stdin. If stdin is a tty, a prompt is issued.
-p password Password used for the ftp login request with method name ft. It must be a valid password for user on the remote volume server. If not supplied on the command line, it is read from stdin. If stdin is a tty, a prompt is issued.
hsmname Configured VSM name for the managed file system containing the database in which you want to record the volume information.
methname The method name under which this volume will be recorded. Valid values are ct, dt, mt, op, and ow. Any method name used with migreg (including ad, ft, and nb) must be defined in the dwpath/database/migconf configuration file for hsmname.
volume_set_numberThe integer number of the volume set of which this volume is a part. Setting the volume_set_number parameter to 0 causes the volume to be assigned to any volume set with the same method when it is needed for writing.A unique volume set is denoted by both the method name and volume set number. Volume sets provide a means within VSM of specifying the volumes on which a particular copy of a migrated file is placed. This is useful when a library device is being used to manage your migrations.
396 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migreg(1M)
volume_nameThe name of the volume to be recorded on the volume and in the volume database VOLDB. For NetBackup volumes, the volume_name is only recorded in the VOLDB, not on the volume. VSM restricts volume names to an alphabetic character followed by up to five alphanumeric characters, and converts all lower case input to upper case.
mount_pointThe file system mount point required when registering a volume for use with method name ad. Make sure the file system is mounted before registering the volume.
server_nameName of the remote volume server for ft volumes. This can be the internet id or number of the server. VSM uses this name on the ftp open command as the host parameter. It must be a valid ftp host.
server_directoryAbsolute pathname of a directory on the host identified by server_name for use by method name ft. The user must have read and write permissions to this directory. This can be any directory on the remote volume server identified by server_name that is not already registered for VSM.
capacity Capacity, in bytes, of the remote file system or NetBackup volume that is available for VSM to use for storing migrated files. A value of 0 is interpreted as unlimited storage capacity.
policy_nameThe name of the NetBackup policy.
NB_masterName of the master NetBackup server for nb volumes. NB_master must be the first name the server is known by to NetBackup.
Note The nb method will not be supported after the VSM 4.5 release.
NB_client Name used for nb volumes to register the client under NetBackup. It must be the name used to register the client in the NetBackup policy.
schedule The name of the NetBackup schedule.
CAVEATS
◆ Using the -F option to force write a new label destroys all information that may be on the volume.
◆ Always use the -F option if the media is already labeled and you wish to reuse the volume.
Appendix A, Man Pages 397
migreg(1M)
◆ The device-manager daemon ltid must be running if you are registering ct, dt, mt, op or ow method names.
◆ When you register one side of an optical disk, VSM also automatically registers the other side with the same volume set number. This avoids deadlocks during volume consolidation and when moving files between migration levels.
◆ If migrating two copies of a file, it is good practice to migrate copy 1 and copy 2 to different volume sets, such as to ct.1 and ct.2 or to ct.1 and dt.1. This avoids the chance of losing both copies when a volume is damaged or lost.
◆ To specify a password on the command line with the -p parameter is less secure that to let the command line prompt for input.
EXAMPLES
The following example for hsmname alpha registers a dlt tape (method name dt) with the name ARC001, and assigns it to volume set number 2.
# migreg alpha dt 2 ARC001
The following example for hsmname alpha registers three cartridge tapes (method name ct) with the names CT001, CT002, and CT003, and assigns them to volume set number 0. Later, when a different ct volume set needs another volume, VSM can assign this tape to that volume set and re-register it with the new volume set number. Tapes are labeled when they are needed.
# migreg -D alpha ct 0 CT001 CT002 CT003
The following example for hsmname alpha registers two disk partitions on device names /dev/dsk01 and /dev/dsk02 as alternate magnetic disk volumes (method name ad) with the names ARC900 and ARC901, and assigns them to volume set number 4.
# migreg alpha ad 4 /dev/dsk01 ARC900 /dev/dsk02 ARC901
The following example for hsmname alpha attempts to register two sides of optical disk AB001, but cannot do so because the volume on side B of the platter is already registered. (VSM had registered side B automatically the first time it had registered side A.)
# migreg alpha op 0 AB001A AB001BTape label: AB001B already registered to HSM
The following example for hsmname alpha registers a remote file system directory (method name ft) at pathname /sdisk3 on server greek2me with the name FTD001, and assigns it to volume set number 1 with a capacity of 600,000,000 bytes (about 572 MB). The user name is fred and the password is HsMk2$.
# migreg -u fred -p HsMk2$ alpha ft 1 daneel /sdisk3 \600000000 FTD001
398 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migreg(1M)
The following example for hsmname alpha registers NetBackup policy hsmnb on NetBackup server duo as a NetBackup volume (method name nb), and assigns it to volume set number 1 with NetBackup schedule sk01 and infinite capacity (0).
# migreg alpha nb 1 hsmnb duo duo sk01 0 NB001Capacity set to unlimited.Registered vh_label=NB001 [at hsmnb] as vh_handle=104A
and method= nb
FILESdwpath/database/VOLDB
Volume database.
dwpath/database/migconf
Configuration file.
SEE ALSO
VSM(1M), migbatch(1M), migconf(1M), migconfg(1M), migdbrpt(1M), migmdclean(1M), mignospace(1M), migsetdb(1M)
Appendix A, Man Pages 399
migselect(1M)
migselect(1M)
NAME
migselect - select volumes for consolidation
SYNOPSIS
/usr/openv/hsm/bin/migselect [-o] hsmname low_high volume_set method
DESCRIPTION
The migselect command selects a set of volumes for consolidation according to the percentage of volume usage. The percentage occupancy can have low-range and high-range values. This utility provides only a model in selecting the volumes and a site can modify it to meet specific requirements.
The output is of the form label.method.volume_set. migcons accepts this format in a list of input volumes to consolidate.
Only the system administrator may use this utility.
OPTIONS
-o Causes migselect to base its selection on the percentage of a full volume that is obsolete. If this parameter is not specified, the selection is based upon the percentage of a full volume that is both active and obsolete.
hsmname Configured VSM name for the managed file system containing the database that has information on these volumes. This parameter is required.
low_high Volume use expressed as limits of low and high percent (for example, 20.05-30.75). This parameter is required.
volume_setThe name of the volume set to use. This parameter is required.
method Method name under which migselect selects volumes. Allowed values for method are ad, ct, dt, mt, op, or ow. This parameter is required.
CAVEATS
◆ This command does not select volumes that have the W flag set.
◆ This command ignores dead volumes.
◆ Write overhead on the volume is not considered in choosing the low and high range values for percent occupancy.
400 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migselect(1M)
EXAMPLE
The following example selects volumes in ct volume set 1 and ad volume set 1, that have percentage occupancy between 1 and 10 percent.
# migselect alpha 01.00-10.00 1 ct adRAO001.ct.1 GLS002.ad.1
The following example selects cartridge tape volumes less than 20 percent full that are on volume set 2. The output of migselect is used as input to consolidation (see migcons(1M)).
# migcons alpha one ct 2 ‘migselect alpha 0.00-20.00 2 ct‘
The following example selects volumes in op volume set 1, that are at least 50 percent obsolete and consolidates them to op volume set 1.
# migcons alpha one op 1 ‘migselect alpha -o 50.0-100 1 op‘
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDBVolume database for VSM.
/usr/var/openv/hsm/database/migconfgGlobal configuration file for the VSM server
SEE ALSO
migconf(1M), migcons(1M), miggetvol(1M), migmdclean(1M), migrecycle(1M)
Appendix A, Man Pages 401
migsetdb(1M)
migsetdb(1M)
NAME
migsetdb - allows you to alter the flags field in the FHDB or the VOLDB
SYNOPSIS
/usr/openv/hsm/bin/migsetdb -F [-a | d | O] [-h hint] [[-m methname [-L label]] -i worklist_file [-s setlevel] hsmname
migsetdb -F [-a | d | O] [-h hint] [[-m methname [-L label] [-K]] [-M machid] [-s setlevel] hsmname handle [handle]...
migsetdb -V [-a | C | d | e | f | l | w | R | T] hsmname label [label]...
migsetdb -V [-u new_user] [-p] hsmname label [label]...
migsetdb -V [-u new_user] [-P password] hsmname label [label]...
migsetdb -V -U user [-P password] hsmname
DESCRIPTION
VSM uses the migsetdb command to select and change the state of the file handle database (FHDB), the file name database (FNDB), and volume database (VOLDB) entries automatically. Administrators can also use migsetdb to fix inconsistencies not corrected by migdbcheck.
An administrator can use migsetdb to perform the following functions:
◆ Mark all FHDB entries as active, obsolete, or dead. Finer granularity may be used by specifying method, volume label, and level. This also allows only the last copy found with the finer granularity to be set by VSM.
◆ Mark specific file handle as active, obsolete, or dead. Finer granularity may be used by specifying method name, volume label, migration level, and -K.
◆ Alter the hint value in FHDB entries for a specific handle. This choice also allows a subchoice by method and/or level and/or volume. Also allows hint to be set for last copy found at subchoice.
◆ Alter the hint value in FHDB entries for a specific file handle. This choice allows a sub-choice by any or any combination of method, level and volume. It also allows the hint value to be set for the last copy found at method, level, and/or volume.
◆ Alter the flags field in the VOLDB to any valid value for the label(s) specified or change the only password, only the user name, or both the password and use name, for the volumes that match the label(s) specified.
◆ Change all passwords for individual users in the VOLDB.
402 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migsetdb(1M)
◆ Additionally, the command may be called by migmove to mark all FHDB entries in the supplied worklist file as active, obsolete, or dead.
migsetdb creates the file /tmp/migsetdb.pid when changing flags on FHDB entries. For changing users or passwords in the VOLDB, migsetdb creates the file /tmp/migsetdb-tmp-voldb.pid. However, migsetdb checks the environment variable TMPDIR, which allows the administrator to use a path other than the default /tmp. This can save files through system reboots or make use of a larger file system to avoid running out of space. The path defined by TMPDIR, if set, is used instead of /tmp as the directory in which to place any temporary files. The process ID of the migsetdb that is executing replaces pid. No files should be left after successful execution.
This command may be run without regard to the VSM state or whether the migration daemon migd is running, except that the -L label can only be run in Maintenance state.
OPTIONS
Caution Inappropriate use of migsetdb may make migrated files inaccessible or make the FHDB inconsistent.
-F Make changes to the filehandle database, FHDB.
-V Make changes to the volume database, VOLDB.
-a Set the flags field of the specified FHDB, FNDB, or VOLDB entry to active (or 0). This is the default for the VOLDB when neither -a nor -d are specified. Default for the FHDB and FHDB when neither -a nor -d nor -O are specified is the condition specified in migconf.
-C Set the corrupt flag field of the specified VOLDB entry.VSM does not automatically set the corrupt flag. It must be set by migsetdb.
-d Set the flags field of the specified FHDB or VOLDB entry to dead.
-O Set the flags field of the specified FHDB entry to obsolete.
-e Set the flags field of the specified VOLDB entry to empty.
-f Set the flags field of the specified VOLDB entry to full.
-h hint A hint of l indicates Library volume set availability (highest). A hint of o indicates Operator volume set availability (lower; no longer configurable with VSM-Java). A hint of v indicates Vault volume set availability (lowest; generally offline).
-l Set the flags field of the specified VOLDB entry to NEEDLBL, indicating that this VOLDB entry needs to be labeled.
Appendix A, Man Pages 403
migsetdb(1M)
-L label Only change FHDB entities that reference this volume label. This option can only be run when the VSM state is Maintenance.
-K Set only the flags for the last occurrence of handle that matches with -s level, -m methodname, and -L label. The -s, -m, and -L are required.
-w Set the flags field of the specified VOLDB entry to write.
-R Set the flags field of the specified VOLDB entry to NDLBLFRC, indicating that this VOLDB entry needs to be force-labeled.
-T Set the flags field of the specified VOLDB entry to indicate no trailer label on tape.
-m methname Set the flags field for FHDB entries with migration level setlevel only if they match method name methname and either handle or the files specified in worklist_file. These method names must be defined in the dwpath/database/migconf configuration file for hsmname. When -m is not specified, entries at setlevel will be modified without regard to methname. Specifying -M machid further restricts which FHDB entries are modified.
-i worklist_file Set the flags field for FHDB entries with migration level setlevel only for the files specified in worklist_file. The format of each line of worklist_file is as follows:handle|machid|lock|flags|volset|copied|method|dest_seek|threshold|size|age|path|hint|comment|mmlevel|slevel|Do not set the flags field for FHDB entries with migration level mmlevel, where mmlevel is an integer in the range 1 to 8. FHDB flags at mmlevel will not be obsolete.
-s setlevel The migration level for which to set FHDB flags, where setlevel is an integer in the range 0 to 8. VSM logs and outputs a warning message if setlevel is greater than 8. Specifying -m methname or -M machid further restricts which FHDB entries are modified. If -s setlevel is not specified, all levels except 0(dk) are set.
-M machid Set the flags field for FHDB entries with migration level setlevel only if they match machine ID machid and handle. When -M is not specified, entries at setlevel are modified without regard to machid only if they match handle and all entries for a particular handle have the same machine ID. VSM skips entries at setlevel that match a particular handle but have more than one machine ID, and logs an error message advising
404 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migsetdb(1M)
you to execute migsetdb with the -M option in order to set the flags field for the handle in question. Specifying -m methname further restricts which FHDB entries are modified.
hsmname Configured VSM name for the managed file system containing the database files you want to alter.
handle Set the flags field for FHDB entries with migration level setlevel only for the files with file handle handle.
label The volume label of the entry to change in the VOLDB.
-u new_user Change the user name to new_user for each entry with the volume label specified by label.
-U user (Change the password at the prompt for all VOLDB entries that match the user name specified by user.
-p Change the password at the prompt(s) for each entry with the volume label specified by label.
-P password Change the password as specified by the password variable on the command line, rather than at the prompt.
CAVEATS
◆ Using the lower case ‘p’ (-p) option to change the password at a prompt is generally more secure than using the upper case ‘P’ option ( -P) and specifying the password as part of the command line.
◆ It is possible to obsolete all entries in the FHDB for any file. This could cause them to be deleted when migrc is run to consolidate the FHDB, making the files inaccessible.
◆ The migrc command removes all FHDB, FNDB, and VOLDB entries marked dead.
◆ Do not mark entries for method name ad or ft dead; mark them obsolete instead. This prevents them from being incorrectly removed by migrc. These entries are correctly removed from the FHDB by migmdclean as it cleans the disk.
EXAMPLES
The following example for hsmname alpha sets the FHDB flags field to the condition specified in the configuration file migconf for all entries with a migration level of 6.
# migsetdb -F -s 6 alpha
The following example for hsmname beta sets the FHDB flags field to dead for all entries with method name ct and a migration level of 1.
# migsetdb -Fd -m ct -s 1 beta
Appendix A, Man Pages 405
migsetdb(1M)
The following example for hsmname chi sets the FHDB flags field to obsolete for all files specified in the worklist file wlst0001 with a migration level of 3 and a mmlevel other than 3.
# migsetdb -FO -i wlst0001 -s 3 chi
The following example for hsmname gamma sets the VOLDB flags field to dead for all entries with label FT001.
# migsetdb -Vd gamma FT001
In this case, the VSM log would show a record resembling the following:
03/31 13:56:15 [12]migsetdb[8506]: VOLDB label: FT001 flags=0010
These records indicate the flags are set to dead.
Similarly, the following example for hsmname theta clears the VOLDB flags field for all entries with label FT001.
# migsetdb -Va theta FT001
In the following example for hsmname omikron, migsetdb is called by migmove.
# migmove -s 5 omikron
In this case, the VSM log would show records resembling the following:
03/11 14:35:49 [15]migsetdb[2810]: fh=3E8ME1035 level=5: flags=0803/11 14:35:50 [15]migsetdb[2810]: fh=3E8ME1036 level=5: flags=0803/11 14:35:50 [15]migsetdb[2810]: fh=3E8ME1037 level=5: flags=08
These records indicate the flags are set to dead.
The following example for hsmname xi sets the new user name to km and prompts for a new password for all entries with label FT001 or FT002.
# migsetdb -Vp -u km xi FT001 FT002
A password is requested and confirmed for each specified volume.
Enter the password for label: FT001 user:kmReenter the password for label: FT001 user:kmEnter the password for label: FT002 user:kmReenter the password for label: FT002 user:km
These volumes now list name01 as the new user name in the VOLDB.
The following example for hsmname xi prompts once for a new password for user name lm.
# migsetdb -V -U lm xi
406 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migsetdb(1M)
To change many volumes to a new owner with a single password, you can use the previous two forms of this command in combination. In the following example for hsmname xi, the first instance sets the new user name to jn for all entries with the specified labels, and the second instance prompts once for jn’s new password.
# migsetdb -V -u jn xi VOL1 VOL2 VOL3 VOL4 VOL5 VOL6 VOL7# migsetdb -V -U jn xi
This avoids repetitive password prompts for each reassigned volume.
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/VOLDB
Volume database
dwpath/database/FHDB
File handle database
dwpath/database/FNDB
File name database for VSM
dwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
/tmp/hsm.log
Global log file for the VSM server
lgpath/hsm.hsmname.log
VSM log file. The term lgpath refers to the path name of the log file for a VSM managed file system.
SEE ALSO
VSM(1M), migconf(1M), migconfg(1M), migmove(1M), migdbcheck(1M)
Appendix A, Man Pages 407
migstage(1)
migstage(1)
NAME
migstage - cache one or more files before recalling from secondary storage
SYNOPSIS
/usr/openv/hsm/bin/migstage [-w] [-R] pathname [pathname ...]
/usr/openv/hsm/bin/migstage [-w] [-R] -f filelist
A more advanced command synopsis for use by experienced administrators who can determine expected results is as follows:
/usr/openv/hsm/bin/migstage [-w] [-R] [-c] [-m method] [-n -levelno] [[-f filelist ] [pathname [pathname ...]]
DESCRIPTION
The migstage command examines a set of files and caches them back to disk. Optionally, migstage will wait until all of the files have been cached before exiting.
This command lets you cache one or more migrated files before you need to access them in order to avoid caching delays at the time of access.
The specified files are cached in their entirety, even when partial file caching is enabled.
migstage attempts to optimize the reload operation by grouping all of the files for a given volume ID and hsmname together.
Generally the VSM state must be Active to stage a file, although a root user can stage files when VSM is in Maintenance state. The migd migration daemon need not be running.
OPTIONS
-w Specifies that migstage is to wait for all of the files to be cached back to disk before exiting. The default is to initiate caching and then exit while caching operations continue in the background.
-R Specifies that if migstage encounters a directory name in a filelist, it will stage all files in that directory and its subdirectories.
-c Specifes that migstage ignores checksum (crc) errors when caching files. Normally, caching from tape fails if the crc computed from the data does not match the crc in the granule header.When -c is specified, the cache operation succeeds even if the crc check fails. This option is intended to be used only as a last resort when a file cannot be recovered the usual way. The file data cached back with the -c option may not be the originalfile data.
408 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migstage(1)
-m method Stage the file from the specified method. The method is one of ad, ct, dt, mt, op, ow, ft, nb, or dk storage methods.
-n levelno Stage the file from the specified levelno. The levelno is a number from 1 to 8 that is associated with a migration level from which you want the file to be staged. migstage ignores checksum (crc) errors when caching files. Normally, when caching a file from tape the cache operation fails if the crc computed from the data does not match the crc in the granule header.
pathname Files or directories that migstage should pre-cache. If a directory is specified, or the -R option was used, all files in the directory and its subdirectories are cached. May be given as a relative path or absolute path. You can specify multiple files or directories, or use standard regular expressions. Wildcards are recognized.
-f filelist Pre-cache the files listed in filelist. The format of filelist is one file name per line, showing either the full pathname of each file or a pathname relative to the current directory in which migstage is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.
EXAMPLES
1. The following command pre-caches all files in the current directory and its subdirectories, even if the directory was not migrated as a part of a group.
# migstage -R . &
The prompt returns quickly, and caching continues in the background.
2. The following command stages all files listed in stagelist and waits for all staging to complete before exiting.
# migstage -w -f stagelist
The file stagelist reads as follows:
/usr/mydir/subdir/f1/*/usr/yourdir/subdir/f2
3. The following command pre-caches all files whose file names begin with the string June_23.
# migstage June_23*
SEE ALSO
VSM(1M), fls(1), miggroup(1), migungroup(1), migloc(1), migtie(1)
Appendix A, Man Pages 409
migtestbadness(1M)
migtestbadness(1M)
NAME
migtestbadness - allows you to check what effect changing the threshold computation parameters has on migration operations
SYNOPSIS
/usr/openv/hsm/bin/migtestbadness hsmname pathname [threshold threshold_formula 2 [lowwater | kilobytes_to_reduce] test_mode number_of_files]
DESCRIPTION
The migtestbadness command lets you assess the results of configuring different values for threshold, minimum file age and file size, weighting factors and weight operators to determine the amount of free space that could be selected during a typical migration operation.
You can see the graphical results of running such tests by invoking the VSM File System Analyzer and selecting What If.
Each test of a file system lists the files that have calculated thresholds exceeding the specified threshold and computes the total file space that could be freed by this operation. This total file space is recomputed each time migtestbadness is run with different values for the file system attributes.
By testing different file systems in this way, you can choose the optimum values to use in VSM configuration.
The values for each migtestbadness option can be customized.
OPTIONS
hsmname The VSM name under which the swept file system is defined.
pathname The directory to sweep. It should be specified as a full absolute path.
threshold The threshold value for this test. Files that exceed this value are identified as migratable. If not configured, the default value is 30
threshold_formulaAll of the threshold criteria to be used in this test. Files that have a threshold factor greater than this value are identified. The formula is as follows:threshold_result=(age_weight (min_age)) weight_operator (size_weight (min_size))On the command line, the values are specified in the following order:
410 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migtestbadness(1M)
threshold min_age min_size age_weight size_weight weight_operator
The age is always the number of days since the last access or since last modification, whichever is greater.The values used in the formula are all user-configurable and are descibed as follows:threshold: The threshold value for this test. Files that exceed this value are identified as migratable. If not configured, the default value is 30.min_age: Age of the file. Include files that have not been accessed or modified within this time. If not configured, the default value is 1.min_size: Size of file (in kilobytes). Include files that are at least this large. If not configured, the default value is 1.age_weight: Weighting to be used for age in the threshold factor. If not configured, the default value is 1.size_weight: Weighting to be used for size in the threshold factor. If not configured, the default value is 1.weight_operator: The operator to be used in calculating the threshold factor. If not configured, the default is 0:0 = multiply1 = add2 = site selectedIf 2 (site selected) is used, migsweep.site.sh is called.
2 File system type is hsm.
lowwater To identify all available files, set lowwater=0. If lowwater does not equal 0, you must specify kilobytes_to_reduce to stop this test. This is a user-configurable value. If not configured, the default is 0.If lowwater is larger than 0, you must also set the kilobytes_to_reduce value.
kilobytes_to_reduceThe maximum amount of free space to be found before stopping this test. This value is valid and must be specified if lowwater does not equal 0. If lowwater=0, this value, if specified, is ignored.You must set the kilobytes_to_reduce value if lowwater is larger than 0.
test_mode List files to output. This user-configurable value defaults to 1:1 = print header messages2 = don’t print headers
number_of_filesThe maximum number of files to be found before migtestbadness stops. This user-configurable value defaults to 0, which equals no limit.
Appendix A, Man Pages 411
migtestbadness(1M)
EXAMPLES
1. To perform its tests, migtestbadness works through its formulas as follows:
a. Is the age of the file greater than min_age? If the answer is no, the file is not selectable. If the answer is yes, the command moves to the next step.
b. Is the size of the file greater than min_size? If the answer is no, the file is not selectable. If the answer is yes, the command moves to the next step.
c. Calculate the threshold of the file bases on the threshold_formula. Move to the next step.
d. Is the threshold of the file greater than or equal to result of the threshold_formula? If the answer is yes, the file is selectable for migration. If the answer is no, the file is not selectable.
Therefore, if you wanted to select files for migration that are 9 hours old, regardless of size, the beginning of the migtestbadness command would be as follows for a managed file system named delta:
# migtestbadness delta /delta 9 0 0 24 0 1
The age_weight is set to 24 because the value for threshold is in hours.
Following the command through its calculation, its sequence to determine that a file is selectable if it is more than 9 hours old regardless of size, is as follows:
a. 9/24 is greater than 0, so the file is selectable.
b. min_size will be greater than 0 in this calculation because any existing file is more than 0 KB, so the file is selectable.
c. (9/24 x 24) +0 =9
d. 9 is greater than or equal to 9, so the file is selectable for migration.
2. In the following test, the hsmname is sigma_6.
The pathname is /sigma_6.
The threshold_formula is as follows: threshold is 1; min_age is 1; min_size is 1; age_weight is 1; size_weight is 1; weight_operator is 1.
The file system type is 2.
kilobytes_to_reduce=4000:
412 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migtestbadness(1M)
The test_mode and number_of_files are not specified and default printing headers and no limit being set on the number of selectable files.
# migtestbadness sigma_6 /sigma_6 1 1 1 1 1 1 2 4000age + size = badness pathname--- ---- ------- --------1.10 1025 1026 /sigma_6/test1/retrieve_file.1.67131.11 1025 1026 /sigma_6/test1/retrieve_file.1.78139.04 10 19 /sigma_6/test1/19.04 10 19 /sigma_6/test1/22.10 100 102 /sigma_6/test1/filler.93.78132.10 100 102 /sigma_6/test1/filler.94.78132.10 100 102 /sigma_6/test1/filler.95.78132.10 100 102 /sigma_6/test1/filler.96.78132.10 100 102 /sigma_6/test1/filler.97.78131.11 1025 1026 /sigma_6/test1/retrieve_file.1.98052.10 100 102 /sigma_6/test1/filler.15.98052.10 100 102 /sigma_6/test1/filler.16.98052.10 100 102 /sigma_6/test1/filler.17.98052.10 100 102 /sigma_6/test1/filler.18.98052.10 100 102 /sigma_6/test1/filler.19.98052.10 10 12 /sigma_6/test1/filler.20.98052.10 10 12 /sigma_6/test1/filler.21.98052.10 10 12 /sigma_6/test1/filler.22.98052.10 10 12 /sigma_6/test1/filler.23.98052.10 10 12 /sigma_6/test1/filler.24.98052.10 100 102 /sigma_6/test1/filler.9.10960selected: 21 files, 4077 Kbytes 3 migrated files 3051 Kbytes
3. In the following test, the hsmname is sigma_6.
The pathname is /sigma_6.
The threshold_formula is as follows: threshold is 30; min_age is 2; min_size is 1; age_weight is 1; size_weight is 1; weight_operator is 0.
The file system type is 2.
The kilobytes_to_reduce is 400.
The test_mode and number_of_files are not specified and default printing headers and no limit being set on the number of selectable files.
# migtestbadness sigma_6 /sigma_6 30 2 1 1 1 0 2 400age + size = badness pathname--- ---- ------- --------2.10 100 102 /sigma_6/test1/filler.93.78132.10 100 102 /sigma_6/test1/filler.94.7813
Appendix A, Man Pages 413
migtestbadness(1M)
2.10 100 102 /sigma_6/test1/filler.95.78132.10 100 102 /sigma_6/test1/filler.96.78132.10 100 102 /sigma_6/test1/filler.97.7813selected: 5 files, 460 Kbytes 0 migrated files 0 Kbytes
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/migconf
Configuration file for managed file systems
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
VSM(1M), migconf(1M
414 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migtie(1)
migtie(1)
NAME
migtie - designate the key caching file(s) for a caching group
SYNOPSIS
/usr/openv/hsm/bin/migtie -a | -d groupname file_path [file_path]...
/usr/openv/hsm/bin/migtie -a | -d -h hsmname groupname file_handle [file_handle]...
/usr/openv/hsm/bin/migtie [-l] hsmname groupname
/usr/openv/hsm/bin/migtie -f -a | -d groupname
DESCRIPTION
The migtie command lets users add, delete, or list key caching files for a caching group. A caching group is a list of files to be cached together. A caching group file defines this list.
The following steps outline the general rules for migrating files as a group.
1. Create a caching group file before using migtie.
If the caching group file is a zero length file, every file in the directory containing the caching group file will be cached back along with every file in all of its subdirectories.
If the caching group file contains pathnames relative to the current directory, it will cache all files and directories specified in the caching group file. If a directory is cached, every file within that directory all of its subdirectories will be cached. Wildcard characters are recognized.
If the caching group file contains full file pathnames, every file in the caching group will be cached back. Wildcard characters are not recognized. Directory names are ignored.
Key caching files may be, but need not be, listed in the caching group file.
The name of the caching group file is .groupname. Locate the .groupname file at a level in the managed file system higher than or equal to all of the key caching files to which it is tied, and include it in the user’s .migstop file to prevent its migration.
2. Choose which files you will designate as key caching files. Use the migtie command to tie one or more of these key caching files to a caching group file.
Users can use migtie to add, delete, or list only those key caching files which they own. The command exits if it encounters a key caching file not owned by the command user.
Appendix A, Man Pages 415
migtie(1)
Whenever a key caching file is cached, all files listed in the caching group file tied to it are also cached. The key caching file and all files listed in the caching group file are cached in their entirety, even when partial file caching is enabled.
Files can appear in more than one caching group file, as shown in the examples. A key caching file may only be tied to one caching group file. A caching group file may list a key caching file for another caching group.
This command may be run without regard to whether the migd migration daemon is running, but the VSM state must be Active, unless you have root privileges. Root users can run the command if the VSM state is Maintenance.
OPTIONS
-a Add key caching files for a caching group.
-d Delete key caching files for a caching group.
-f A file containing a list of pathnames that will be added or deleted.
Note You must use -f if any file names contain white space.
-l List the key caching files for a caching group (default).
-h Identify key caching files by file handle rather than by file path.
groupnameIdentifies the caching group file listing the files to be cached together. The groupname cannot exceed eleven characters.
hsmname Configured VSM name for the managed file system to use for migtie.
file_path Absolute or relative pathname of the key caching file(s).
file_handle File handle of the key caching file(s).
CAVEATS
◆ Creating a caching group file of zero length or one containing relative pathnames can increase caching activity unnecessarily if used in situations where it is not necessary to cache entire directories and their subdirectories at one time.
◆ When migtie designates a file to be a key caching file it modifies the comments field of the file’s FHDB entry. Only files with a FHDB comments field containing “Auto VSM run” or “User selected” or a term with a dot “.” prefix can be designated to be key caching files.
◆ If you choose a file to designate as a key caching file while it is still in premigration, and then cache that file before it has been fully migrated to secondary storage, the designation will be lost when the file is later re-migrated. Although this is a rare
416 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migtie(1)
occurrence, you can ensure that the designation will not be lost by using the migloc command to verify the migrated status of the file before either initially designating the file or caching it for the first time.
◆ If you cache the files in a caching group tied to a key caching file before all the copies of those files have been made, re-migrating the files at a later time will create new file handles. Execute migtie again for each of these files.
◆ If you change the name or full path of any file listed in a caching group file, caching a key caching file tied to that caching group file will no longer cache the changed file unless you modify the caching group file accordingly.
◆ A reference only to the slice portion of a key caching file will not cause the files listed in the caching group file to be cached.
◆ If a key caching file has not been purged, caching it will not cause the files listed in the caching group file to be cached.
◆ If the key caching files are renamed after they are included in a caching group, they no longer work as key caching files.
◆ You must use the -f option if you will use file names with white space in them.
◆ The miggroup command is implemented using a tie group named MigGroup. Using this same name in your own migtie command will interfere with any current or future use of miggroup in this file system.
EXAMPLE 1
Create a caching group file in /home/user1/.month_tie for the following caching group:
/home/usr1/monthly_project/run_project.1/home/usr1/monthly_project/run_project.2/home/usr1/monthly_project/data.1/home/usr1/monthly_project/data.2/home/usr1/quarterly_project/data/home/boss/reports/monthly_project/user1/her_input
Designate key caching files for this caching group with the following command:
# migtie -a month_tie /home/usr1/monthly_project/run_project.1 \ /home/usr1/monthly_project/run_project.2
When the user executes either program run_project.1 or run_project.2, VSM will automatically cache all of the files listed in /home/usr1/.month_tie. Normal read, write, and execute permissions pertain to these cached files.
If the user accesses only /home/usr1/monthly_project/data.1, which is not a key caching file, no other files would be cached automatically.
Appendix A, Man Pages 417
migtie(1)
EXAMPLE 2
Create a caching group file in /home/user1/.month_tie for the following caching group:
monthly_projectquarterly_project/d*
Designate key caching files for this caching group with the following command:
# migtie -a month_tie /home/usr1/monthly_project/run_project.?
When the user executes either program run_project.1 or run_project.2, VSM will automatically cache all of the files listed in /home/usr1/.month_tie. This includes all files in the /home/user1/monthly_project directory and its subdirectories as well as any files or directories beginning with the character d in the /home/user1/quarterly_ project directory.
EXAMPLE 3
Create a caching group file in /home/user1/.quarter_tie for the following caching group:
/home/usr1/monthly_project/data/output/home/usr1/quarterly_project/data/home/boss/reports/monthly_project/user1/her_input
Designate a key caching file for this caching group with the following command:
# migtie -a quarter_tie /home/usr1/quarterly_project/run_project
When the user executes the program run_project, VSM will automatically cache all of the files listed in /home/usr1/.quarter_tie. Note that the key caching file does not need to be listed in /home/usr1/.quarter_tie for this to occur.
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
SEE ALSO
VSM(1M), gethsm(1), migin(1M), miggroup(1), migungroup(1), migstage(1)
418 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migtscan(1M), migopscan(1M)
migtscan(1M), migopscan(1M)
NAME
migtscan, migopscan - scan tapes or optical volumes for file granules
SYNOPSIS
/usr/openv/hsm/bin/migtscan [-F] [-r] [-b block_size] [-P pool_name] [-n] [-s] [-t] hsmname volume_label method
/usr/openv/hsm/bin/migopscan [-F] [-r] [-P pool_name] [-n] [-s] hsmname volume_label method
DESCRIPTION
The migtscan and migopscan commands scan the specified tape (ct, dt, or mt) or optical platter (op or ow) volume_label. The resulting display contains information about the volume as a whole and also about each granule on the volume.
When VSM migrates a file to secondary storage, it writes the file as granules. The granule size is configured for the method name (ct, dt, mt, op, or ow) during VSM configuration. Each granule on tape also contains FHDB, FNDB, and VOLDB entry information.
The migtscan and migopscan commands create three output files: FHDB.label, FNDB.label, VOLDB.label, in the dwpath/database directory. The structure of these files is the same as the FHDB, FNDB, and VOLDB database files. These files may be used to rebuild the FHDB, FNDB, and VOLDB if they are corrupted or damaged (see migdbcheck(1M)).
You can sort and merge FHDB.label and FNDB.label files for different volumes to recreate the FHDB and FNDB. Similarly, merging VOLDB.label files for different volumes can recreate the VOLDB.
Note When recreating the VOLDB, be sure to merge the VOLDB file in the /usr/var/openv/hsm/example/database directory to include the entry for the dk method.
OPTIONS
-F Force scan the volume for VSM granules in case the volume identity is not in the VOLDB. This parameter is optional. If omitted, the volume must be registered in the VOLDB. If the volume is registered, VOLDB scans to the end of the tape (for migtscan) or the end of the platter (for migopscan), and will not use the VOLDB file count.
Appendix A, Man Pages 419
migtscan(1M), migopscan(1M)
-b block_size
This number represents the block size, in bytes, that VSM uses on reads. The default is the size recorded in the volume label (see below).-b block_size applies only to migtscan.
-P pool_nameThis represents the media pool name that VSM uses. When -F is used, the default is HSM. When -F is not used, the default is the poolname found in the volume_label entry in the VOLDB.
-n Do not compress or convert FHDB entries for files found on the volume. When the -n option is used, no FNDB.label file is produced. This option is useful for examining what is actually written on the media. The FHDB.label file produced with the -n option must be run through migfdbconvert before it can be merged into the real FHDB and FNDB.
-r Read granule data. The default behavior is to skip the reading of granule data. StorageTek 9840 VolSafe tape drives will scan faster if the this option is specified.
-t Use values of file and record numbers that were recorded on tape. When not specified, use actual values. The actual values may differ from the recorded values in some cases; the actual value is needed for VSM to cache files correctly. -t applies only to migtscan.
-s Silently scan the volume and create FHDB.label and VOLDB.label files, but do not display information on stdout.
hsmname Configured VSM name for the managed file system containing the database that has information on the desired volume.
volume_labelTape volume label used when registering the volume. This parameter is required.
method Method name under which the volume is registered (ct, dt, or mt for migtscan, and op or ow for migopscan).
CAVEATS
◆ Some tape drives, such as the StorageTek 9840 VolSafe drives, will scan faster if you specify the -r option.
◆ Results of scanning a tape volume that does not conform to VSM standards are unknown.
420 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migtscan(1M), migopscan(1M)
EXAMPLE
The following example uses method mt to scan a tape volume named lostid. The resulting display shows a list of granule information for files archived on the volume.
The FHDB.lostid and VOLDB.lostid files are created in the VSM database directory.
# migtscan alpha lostid mt VOLUME LOSTID registered to HSM VOLUME particulars =====>> 000003E8V00001098 LOSTID mt 09600000 0072DB69 #23 -------------------------- 000003E8M00001342 V00001098 mt 00005B8C 00000000 00005B8C #1 1 #1 1 /home/ckb/ed000003E8M00001343 V00001098 mt 00005B8C 00000000 00005B8C #2 1 #2 1 /home/ckb/anINFO: Found trailer label EOV1
Volume information on the display includes (in order):
Volume handle Volume label Method Total capacity of the volume Total space in use on the volume Number of files on the volume.
File granules information on the display includes (in order):
File handle Volume ID Method File size in hexOffset in hex of the granule in the file Granule size in hexRecorded filemark number after which the granule residesRecorded offset from the file mark to the granuleComputed filemark number after which the granule residesComputed offset from the file mark to the granuleFile name.
The recorded file mark number should equal the computer file mark number. The recorded offset should equal the computed file mark.
number is the granule number recorded on the tape, and should equal the computed granule number. The computed granule number is based on the scan of the tape. Similarly, the recorded file number is the file number recorded on the tape, and should equal the computed file number.
Appendix A, Man Pages 421
migtscan(1M), migopscan(1M)
FILES
The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories.
dwpath/database/FHDB
File handle database for VSM
dwpath/database/FNDB
File name database for VSM
dwpath/database/VOLDB
Volume database for VSM
dwpath/database/migconf
Configuration file for managed file systems
dwpath/database/FHDB.label
File handle database for current volume
dwpath/database/FNDB.label
File name database for current volume. It contains some fields that are moved from the dwpath/database/FHDB.label
dwpath/database/VOLDB.label
Volume database for current volume
/usr/var/openv/hsm/database/migconfg
Global configuration file for the VSM server
SEE ALSO
migdbcheck(1M), mediacheck(1M), migconf(1M), migconfg(1M), migdbrpt(1M), migreg(1M), migadscan(1M), migftscan(1M), mignbscan(1M)
422 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migunmigrate(1)
migunmigrate(1)
NAME
migunmigrate - completely unmigrate a previously migrated file
SYNOPSIS
/usr/openv/hsm/bin/migunmigrate filename [filename ...]
/usr/openv/hsm/bin/migunmigrate -f filelist
DESCRIPTION
The migunmigrate command lets users request that VSM unmigrate specified files. Users can unmigrate files that they own only if the system administrator provides the proper permissions before users can use this command.
Use the fls or migloc command to determine if a file has been migrated or premigrated and/or cached.
Files can be unmigrated regardless of whether or not they are already cached; however, to achieve maximum caching performance, you should stage the files with migstage before unmigrating them.
This command requires an Active VSM state and a running migd migration daemon.
OPTIONS
filename Files that migunmigrate should process. May be given as a relative path or absolute path. You can specify multiple files or use standard regular expressions. Wildcards are recognized.
-f filelist Unmigrate the files listed in filelist. The format of filelist is one file name per line: either the full pathname of each file or a pathname relative to the directory in which migunmigrate is executed, not the directory in which the file(s) in the filelist resides. Wildcards are not recognized.
EXIT STATUS
The following exit values are returned:
0 All files were successfully unmigrated.
<0 An error prevented any processing from occurring.
>0 The exit status indicates the number of files for which a problem was encountered.
SEE ALSOfls(1), migloc(1), migstage(1)
Appendix A, Man Pages 423
migVSMshutdown(1M)
migVSMshutdown(1M)
NAME
migVSMshutdown - this command shuts down VSM.
SYNOPSIS
/usr/openv/hsm/bin/migVSMshutdown [hsmname]
DESCRIPTION
The migVSMshutdown command shuts down VSM. When you invoke S78hsmveritas, irixrc.sh, or hpuxrc.sh with the stop option, the script runs migVSMshutdown.
A migVSMshutdown command executes the following VSM processes:
1. migVSMstate -w -s -idle [hsmname] changes the state of each Active file system to Idle.
2. stopmigd stops migd and migvold. Executed only if no hsmname was specified.
3. stopmigrd, which stops migrd. Executed only if no hsmname is specified.
4. HSMKiller hsmname stops all VSM processes. May be executed if migd was not running or was unable to idle a file system.
OPTIONS
hsmname When specified, this is the specific VSM-managed file system processed by migVSMshutdown. When not specified, all VSM-managed file systems are process by migVSMshutdown.
SEE ALSO
VSM(1M), migrc(1M), migrd(1M), migconfg(1M), startmigd(1M), migdbcheck(1M), mignospace(1M), migVSMstate(1M), migVSMstartup(1M)
424 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migVSMstartup(1M)
migVSMstartup(1M)
NAME
migVSMstartup - starts VSM.
SYNOPSIS
/usr/openv/hsm/bin/migVSMstartup [-D] [-T] [-N] [-C] [hsmname]
DESCRIPTION
The migVSMstartup command starts VSM. When you invoke S78hsmveritas, irixrc.sh, or hpuxrc.sh with the start option, it runs migVSMstartup. The startup scripts are installed so that they automatically run when the system boots in multi-user mode (run level 2)
A migVSMstartupdown command executes the following VSM processes:
1. migVSMstate -c -s maintenance hsmname sets the VSM state to Maintenance for each active file system that was incorrectly shutdown.
2. startmigd starts the migd, migvold, and migrd daemons.
3. migrc -L hsmname clears locks within VSM for each hsmname in Maintenance state.
4. migadd_trailer.sh, which, for for each hsmname in Maintenance state, adds missing tape trailer labels to tapes if the -T is specified .
5. mignospace hsmname invokes migVSMstartup without the -D, -T, or -N options so that these options are not run. For each hsmname in Maintenance state, mignospace hsmname does nospace processing for the file system if the used space exceeds the configured threshold and the -N option is specified.
6. migdbcheck hsmname invokes migVSMstartup without the -D, -T, or -N options so that these options are not run. For each hsmname in Maintenance state, migdbcheck hsmname finds problems, but does not fix them, if the following occur: -D is specified for VSM, migrc cleaned some locks, or there are tapes without trailer labels.
7. migVSMstartup clears the Maintenance state for hsmname if the threshold is acceptable and it detects no other problems.
OPTIONS
-D Run migdbcheck if there appear to be problems. Not run by default.
Appendix A, Man Pages 425
migVSMstartup(1M)
-T Run migadd_trailer.sh on volumes that have missing trailers. Not run by default.
-N Run mignospace if the file system open space is less than the configured threshold. Not run by default.
-C Run migdbconvert on hsmname if the databases for hsmname are in VSM release 3.4 or 3.4.1 format, and convert the databases to VSM release 4.5 format.
hsmname When specified, this is the specific managed file system processed by migVSMstartup. When not specified, all managed file systems are processed by migVSMstartup.
SEE ALSO
VSM(1M), migrc(1M), migrd(1M), migconfg(1M), startmigd(1M), migdbcheck(1M), mignospace(1M), migVSMshutdown(1M), migVSMstate(1M)
426 VERITAS Storage Migrator System Administrator’s Guide for UNIX
migVSMstate(1M)
migVSMstate(1M)
NAME
migVSMstate - changes or displays the state of a VSM managed file system
SYNOPSIS
/usr/openv/hsm/bin/migVSMstate [-s state] [-c] [-w] [-v] [hsmname]
DESCRIPTION
The migVSMstate command changes or displays the state of hsmname. This command allows VSM to be gracefully shutdown. Should a system interrupt (such a crash) occur, migVSMstate is part of recovery during a shutdown and startup.
migVSMstate sets the following states:
◆ Idle: When hsmname is in this state, VSM can mount or unmount the file system. No other activity is allowed on this file system.
◆ Idling: When hsmname is in this state, VSM can remove files. All VSM processes will cleanup and terminate. mignospace processing cannot start. Once all VSM activity has completed, migd will change the state of hsmname to idle. This transitional state is not set by migVSMstate; a managed file system will go through this state as part of the process of becoming Idle.
◆ Maintenance: When hsmname is in this state, VSM cannot cache files or start mignospace processing.
◆ Inactive: When hsmname is in this state, no VSM activity is allowed.
◆ Active: When hsmname is in this state, VSM activity is allowed.
If no option is specified, migVSMstate displays the current state setting.
OPTIONS
-s idle Causes hsmname to start idling down and go into Idle state. If -w was specified, migVSMstate will not exit until the state becomes Idle.
-s maintenance
Changes hsmname to Maintenance state.
-s active Changes hsmname to Active state.
-s inactiveChanges hsmname to Inactive state. A managed file system cannot go from Active to Inactive; it must go through Idle or Maintenance state and then to Inactive.
Appendix A, Man Pages 427
migVSMstate(1M)
-s maintenance -cPlaces hsmname in the Maintenance state, but only if hsmname was not correctly shutdown or correctly idled.
-w When used with -s idle, migVSMstate will wait to exit until the state becomes Idle.
-v Verbose mode messages go to STDOUT or STDERR, as well as the log files.
hsmname When specified, this is the specific VSM-managed file system processed by migVSMstate. When not specified, this implies that all VSM-managed file systems are processed by migVSMstate.
SEE ALSO
VSM(1M), migrc(1M), migrd(1M), migconfg(1M), startmigd(1M), migdbcheck(1M), mignospace(1M), migVSMshutdown(1M), migVSMstartup(1M)
428 VERITAS Storage Migrator System Administrator’s Guide for UNIX
rebuild_ihand(1M)
rebuild_ihand(1M)
NAME
rebuild_ihand - rebuild the VSM IHAND file
SYNOPSIS
/usr/openv/hsm/bin/rebuild_ihand hsmname
DESCRIPTION
The rebuild_ihand command reconstructs a lost or corrupted inode-to-handle (IHAND) file if the managed file system is intact.
This command will not detect all discrepancies between the file system and the FHDB; run migdbcheck to do this. You must also stop and restart the migd migration daemon or send it an INT signal after the IHAND file has been replaced.
The output of rebuild_ihand is a reconstructed IHAND file in dwpath/database/hsmname.IHAND.pid. To use this reconstructed IHAND file, copy it to the real IHAND file in dwpath/database/hsmname.IHAND.
The exit status of rebuild_ihand is a count of the number of errors encountered. A zero status indicates there were no errors. Error messages are written to stderr and to the VSM logfile.
This command may be run without regard to the VSM state, but the VSM daemons must not be running.
OPTIONS
hsmname VSM name of the managed file system for which you want to rebuild the IHAND file.
FILES
The term dwpath refers to the path name of the directory containing the database and workdir directories. The path name of this directory is site configurable
dwpath/database/hsmname.IHAND
Inode-to-handle file for VSM
dwpath/database/hsmname.IHAND.pid
Reconstructed inode-to-handle file for VSM
SEE ALSO
ihprint(1M)
Appendix A, Man Pages 429
startmigd(1M)
startmigd(1M)
NAME
startmigd - start the VSM migration, volume, and request daemons
SYNOPSIS
/usr/openv/hsm/bin/startmigd [-m | -r | -v ] [-t time]
DESCRIPTION
The startmigd command starts the VSM migration daemon (migd), the volume daemon (migvold), and the request daemon (migrd).
You should ensure migd, migvold, and migrd are started as part of system startup. The startup scripts copied during installation do this for you automatically.
On startup, migd and migrd read the configuration files. If you manually change the configuration file while the daemons are running, you can stop and restart the daemon so that they pick up the changes, or you can signal the daemons as follows:
# kill -INT ‘cat /usr/var/openv/hsm/workdir/migd.pid‘# kill -HUP ‘cat /usr/var/openv/hsm/workdir/migrd.pid‘
If you use VSM-Java to make configuration changes, a signal is automatically sent to migd and migrd.
OPTIONS
-m Start only the migration daemon (migd).
-r Start only the migration request daemon (migrd)
-v Start only the volume daemon (migvold).
-t time Sets the time interval in seconds that determines the frequency with which the migd migration daemon checks the high-water mark threshold. The default is 60.
Note The default behavior is to start all VSM daemons.
CAVEATS
◆ You must start the migd migration daemon before you can mount the managed file systems.
◆ If the migration daemon is not running or the managed file system state is not Active, migrated files cannot be accessed. If migd stops, you can use the VSM log files to help determine the cause of failure.
430 VERITAS Storage Migrator System Administrator’s Guide for UNIX
startmigd(1M)
EXAMPLE
The following command starts the migration, volume, and request daemons, with results similar to those shown:
# startmigdINFO: VSM request daemon migrd started.INFO: VSM volume daemon migvold started.INFO: VSM migration daemon migd started with frequency 60.
FILES/usr/var/openv/hsm/workdir/migd.pid
The process ID (pid) of the VSM migration daemon (if it is running)
/usr/var/openv/hsm/workdir/migvold.pid
The process ID (pid) of the VSM volume daemon (if it is running).
/usr/var/openv/hsm/workdir/migrd.pid
The process ID (pid) of the VSM request daemon (if it is running).
SEE ALSO
VSM(1M), HSMKiller(1M), migconf(1M), migconfg(1M), stopmigd(1M), stopmigrd(1m), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)
Appendix A, Man Pages 431
stopmigd(1M)
stopmigd(1M)
NAME
stopmigd - stop the VSM migration and volume daemons
SYNOPSIS
/usr/openv/hsm/bin/stopmigd [-m | -v]
DESCRIPTION
The stopmigd command stops the VSM migration daemon (migd) and the VSM volume daemon (migvold). The daemons should only be stopped in the event of a problem. When VSM is installed, the migration daemon becomes an integral part of the operating system software on that machine.
The stopmigd command only terminates migd and migvold. Use stopmigrd to stop the migrd migration request daemon. Use migVSMshutdown to halt all running VSM processes.
OPTIONS
-m Stop only the migration daemon (migd).
-v Stop only the volume daemon (migvold).
The default is to stop both the VSM migration and volume daemons.
The exit value (n) is the number of daemons stopped.
CAVEATS
◆ If migd is not running, you cannot do the following:
- On Solaris and HP-UX systems, you cannot remove files from the managed file system.
- Users cannot access migrated files.
- Automatic migrations do not occur when free space is above the high-water threshold and a user attempts to open a migrated file.
◆ If the migvold volume daemon is not running, users cannot read migrated files from tape or optical volumes.
◆ Current VSM migration and caching operations run to completion but may leave incorrect results after stopmigd stops the VSM daemons.
432 VERITAS Storage Migrator System Administrator’s Guide for UNIX
stopmigd(1M)
EXAMPLE
The following command stops both the migration and volume daemons, and returns messages similar to those shown if the daemons were running when the command was issued:
# stopmigdINFO: VSM migration daemon migd stopped.INFO: VSM volume daemon migvold stopped.
FILES/usr/var/openv/hsm/workdir/migd.pid
The process ID (pid) of the VSM migration daemon (if it is running)
/usr/var/openv/hsm/workdir/migvold.pid
The process ID (pid) of the VSM volume daemon (if it is running)
SEE ALSO
VSM(1M), startmigd(1M), migVSMstartup(1M), migVSMshutdown(1M), HSMKiller(1M)
Appendix A, Man Pages 433
stopmigrd(1M)
stopmigrd(1M)
NAME
stopmigrd - stop the VSM request daemon migrd
SYNOPSIS
/usr/openv/hsm/bin/stopmigrd
DESCRIPTION
The stopmigrd command stops the VSM request daemon (migrd). The daemon should only be stopped in the event of a problem. When VSM is installed, the migration request daemon becomes an integral part of the operating system software on that machine.
The stopmigrd command only terminates migrd. Use stopmigd to stop the migd and migvold daemons. Use migVSMshutdown to halt all running VSM processes.
CAVEATS
◆ If the request daemon is not running, VSM-Java applications cannot connect to the server.
◆ Some state changes rely on the request daemon to make changes to the global configuration file. If the request daemon is not running, migVSMstate may not be able to make a requested state change.
FILES/usr/var/openv/hsm/workdir/migrd.pid
The process ID (pid) of the VSM request daemon (if it is running)
SEE ALSO
migrd(1M), VSM(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M), HSMKiller(1M)
434 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM(1M)
VSM(1M)
NAME
VSM - VERITAS Storage Migrator (VSM)
DESCRIPTION
VERITAS Storage Migrator (VSM) increases the amount of file space available to users by migrating files from a local online managed file system to secondary storage (such as magnetic tape or another disk) as space is needed in the online file system.
Administrators can schedule migration operations to occur automatically. When properly configured, VSM selects files for migration based on configurable criteria such as file size and file age.
When a user accesses a migrated file, it is automatically retrieved from secondary storage and cached in the online file system. Except for the delay to perform the retrieval, users and programs are unaware that file migration and retrieval are taking place.
VSM uses directly connected tape, optical disk, or magnetic disk devices as well as magnetic disk file systems on remote volume servers for secondary storage. Media Manager provides the interface to the tape and optical storage devices. Support for large-capacity library devices with robotic access mechanisms eliminates the need for operator action to either migrate or cache files.
VSM lets you use numerous secondary storage methods: disk file for premigration (dk), alternate magnetic disk (ad), three tape methods (ct, dt, and mt), two optical disk methods (op and ow), remote using FTP (ft), and NetBackup (nb). The nb method migrates files using VERITAS NetBackup.
VSM is able to share storage volumes and devices with other applications like VERITAS NetBackup through the use of a common Media Manager.
VSM supports multilevel migration. Administrators may configure up to eight migration levels, and can schedule migrated files to move from one level to another based on site-specified criteria. With multilevel migration, you can configure and manage cost-effective storage hierarchies that make best use of your storage equipment investment.
VSM enables administrators to export migrated files from one managed file system and import them into another managed file system.
The following sections group VSM commands by function.
MANAGING FILE MIGRATION
migbatch(1M)
Premigrate files and copy to secondary storage
Appendix A, Man Pages 435
VSM(1M)
migfind(1M)
Determine the full pathname of a file on secondary storage
mignospace(1M)
Purge or migrate files to make disk space available
miglow(1M)
Start mignospace if file system is above high-water mark
MANAGING MULTILEVEL MIGRATION
migmove(1M)
Move migrated files from one migration level to another level
migsetdb(1M)
Alter the flags field in the FHDB or the VOLDB
MANAGING FILE CACHING
migin(1M)
Cache a file from secondary storage to disk
migstage(1)
Pre-cache files to avoid caching delays
migtie(1)
Designate the key caching file(s) for a caching group
MANAGING MEDIA
migreg(1M)
Register and label volumes for VSM
migcons(1M)
Consolidate VSM tape and optical volumes
migselect(1M)
Select volumes for consolidation based on specified criteria
migrecycle(1M)
Reregister an empty volume
migmdclean(1M)
Remove obsolete entries from media
436 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM(1M)
migftscan(1M)
Scan an ft remote volume and reconstruct database entries
MANAGING VSM PROCESSES
startmigd(1M)
Start migration and volume daemons
stopmigrd(1m)
Stop migration and volume daemons
migrc(1M)
Clear locks, remove defunct lock files, restart migrations
migconsweep(1M)
Enable constant file system sweeping
mignewlog(1M)
Copy or delete global or individual VSM log file
migVSMstate(1M)
Changes file system state to Maintenance, Idle, Idling, Inactive, or Active.
migVSMstartup(1M)
Start migration and volume daemons; used in place of startmigd
migVSMshutdown(1M)
Stop migration and volume daemons; used in place of stopmigd and HSMKiller
HSMKiller(1M)
Kill active VSM processes and release tape requests
MANAGING VSM
ihprint(1M)
Print or alter the IHAND file
rebuild_ihand(1M)
Rebuild the IHAND file from the FHDB
migalter(1M)
Display or alter regions, events, or attributes
migcleanup(1M)
Appendix A, Man Pages 437
VSM(1M)
Display or clean up DMAPI sessions
RECOVERING DATA
migreconstruct(1M)
Reconstruct damaged or deleted migrated files
migin(1M)
Restore a file from secondary storage to disk.
USER CONTROLS
fls(1)
List and show migration status of files
gethsm(1)
Display the hsmname for files and directories
migcat(1)
Concatenate and display migrated files without caching them
miggroup(1), migungroup(1)
Group/Ungroup files for migration and caching
migloc(1)
Show location of migrated file
migpurge(1)
Purge a specific file or files
migrate(1)
Premigrate a specific file or files
migstage(1)
Pre-cache files to avoid caching delays
migtie(1)
Designate the key caching file(s) for a caching group
migunmigrate(1)
Request that a migrated file be unmigrated
EXPORTING AND IMPORTING MIGRATED FILES
mignbimport(1M)
438 VERITAS Storage Migrator System Administrator’s Guide for UNIX
VSM(1M)
Export VSM files
mignbimport(1M)
Import VSM files
MANAGING DATABASES
migactivate
Activate FHDB entries for files with obsolete VSM file handles
migdbconvert(1M)
Convert VSM release3.4 or 3.4.1 FHDB to VSM release 4.5 FHDB and FNDB
migdbcheck(1M)
Check the FHDB, FNDB, and/or the VOLDB for consistency with the file system
mediacheck(1M)
Check the media, FHDB, and FNDB for consistency
migsetdb(1M)
Alter the flags field in the FHDB and FNDB or the VOLDB
OBTAINING REPORTS
migadscan(1M)
Provide information on contents of archive disk volumes
migtscan(1M), migopscan(1M)
Provide information on contents of tape or optical volumes
miggetvol(1M)
List volumes in ascending order of percentage utilization
migdbdir(1M)
List global configuration values from migconfg
migdbrpt(1M)
Provide FHDB, FNDB, and VOLDB information on files and volumes
migchecklog(1M)
List the most recent messages from an error log file
migftscan(1M)
Scan an ft remote volume and reconstruct database entries
Appendix A, Man Pages 439
VSM(1M)
mignbscan(1M)
Scan a NetBackup volume and reconstruct database entries
TUNING MIGRATIONS
migconsweep(1M)
Enable constant file system sweeping
migtestbadness(1M)
Evaluate configuring different file system attributes
GRAPHICAL USER INTERFACES
migsa
VSM-Java, the Java-based Administrative interface, is used to complete administrative tasks on VSM-managed file systems and servers. On a Windows system, select Start > Programs > VERITAS Storage Migrator > Unix Administration. On HP-UX or Solaris systems, launch the VSM-Java Administration interface with the following command:
/usr/openv/java/migsa &
migfb
◆ The Java-based File Browser interface is used to migrate files, as well as purge and view migrated files. On a Windows system, select Start > Programs > VERITAS Storage Migrator > Unix File Browser. On HP-UX or Solaris, launch the VSM File Browser interface with the following command:
/usr/openv/java/migfb &
Note Man pages are not available for the above graphical user interfaces.
440 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Enterprise Agent for Storage Migrator
B The Enterprise Agent for Storage Migrator lets you define your VSM resources and group them for failover situations.Enterprise Agent for Storage Migrator has two VERITAS Cluster Server (VCS) agents:
◆ The Storage Migrator Agent (StorageMigratorAgent) monitors the VSM daemons.
◆ The Storage Migrator File System Agent (StorageMigratorFSAgent) manages VSM file system resources.
These agents are typically configured together to manage VSM resources. These agents allow managed file systems to fail over independently.
Enterprise Agent for Storage Migrator is designed to support active-active configurations. If, however, you are using locally attached tapes, you can use only the active-inactive configuration, an example of which is explained in “Manual Active-Inactive Configuration using NetBackup” on page 453. Active-active configurations work only with ft and ad methods, an example of which is explained in “Manual Active-Active Configuration using FTP” on page 450.
Also consider the following as you plan your configuration:
◆ One or more managed file systems can be configured as VCS resources. These resources are then configured in a VCS resource group.
◆ The managed file systems must reside on shared disks and be available to all systems in the cluster. VSM database and log files must also reside on separate shared disks available to all systems. They must be configured as Mount resource types.
◆ All StorageMigratorFS Agent resources must be created for failover purposes. Each resource includes the managed file system, database and log file directories, and dependency statements, as required.
441
◆ The StorageMigrator resource is included in a group by itself, so that the Parallel attribute can be set by the user. Doing this allows for active-active configurations. The following table shows the StorageMigrator Agent and StorageMigratorFS Agents and resources.
The following table summarizes StorageMigrator Agent operations. The StorageMigrator Agent has unique online, offline, monitor, and clean scripts:
Components and Resources for Enterprise Agent for Storage Migrator
Agent Name Resource Name Resource Group
StorageMigrator theDaemons StorageMigratorGroup
StorageMigratorFS Hsm_X StorageMigratorFSGroup
Operations for the StorageMigrator Agent
Description Manages the VSM daemons
Operations - monitor - Verifies that the VSM daemons (migd, migrd, and, when applicable, migvold) are running.
- online - Calls migVSMstartup to start the VSM daemons.
- offline - Calls migVSMshutdown to stop the VSM daemons. If any managed file systems are Active, they are put in Maintenance state.
- clean - Calls migVSMshutdown to stop the VSM daemons.
Detecting Daemon Failure
The daemon is considered offline if one of the following applies:
- The daemon.pid file for migd, migrd, or (when applicable) migvold does not exist or is empty.
- The processes associated with the process IDs listed in the daemon.pid files do not exist in the /proc directory.
442 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Limitations
The following table summarizes StorageMigratorFS Agent operations. The StorageMigratorFS Agent has unique online, offline, monitor, and clean scripts:
LimitationsThe following limitations apply to Enterprise Agent for Storage Migrator:
◆ When using Media Manager, the Enterprise Agent for Storage Migrator supports only active-inactive configurations.
◆ Enterprise Agent for Storage Migrator is tested in a two-node configuration, although it is designed to work in two- to 32-node configurations.
◆ VSM may not support quick restart for all interruptions.
InstallationBefore you begin, make sure you can install, configure, and use VCS and NetBackup Cluster Server Agent in a configuration. You will need the following resources for using Enterprise Agent for Storage Migrator:
◆ NetBackup Cluster Agent version 1.3.0, if using locally attached tapes.
Operations for the StorageMigratorFS Agent
Description Manages file systems under VCS control
Operations - monitor - Verifies that the managed file system is mounted and that an entry exists for it in migconfg (the global configuration file). Also tests for status in the resource.vsm.agent.state file.*
- online - Adds the manged file system entry to the migconfg file, calls migVSMstartup to start VSM, and sets its state to Active. Also echoes online to the resource.vsm.agent.state file.*
- offline - Calls migVSMshutdown to idle the managed file system, echoes offline to the resource.vsm.agent.state file*, and removes the entry from the migconfg file.
- clean - The same as offline.
Detecting Daemon Failure
The managed file system is considered offline if it is mounted and no entry for it appears in the migconfg file.
* An example resource.vsm.agent.state file name isvsmfs_hsm2.vsm.agent.state.
Appendix B, Enterprise Agent for Storage Migrator 443
Installation
◆ VCS version 1.3.0 or 2.0.
◆ NetBackup version 4.5
◆ VSM version 4.5.
◆ VxFS version 3.3 or 3.4.
◆ A VCS cluster, consisting of at least two systems running Solaris OS versions 2.6, 2.7, or 2.8.
◆ At least one shared disk for managed file systems, VSM databases, and the /usr/openv directory.
◆ A shared library for migration, if you are using tapes.
Pre-InstallationYou need the following before you install the Enterprise Agent for Storage Migrator:
◆ VERITAS Cluster Server software distribution 1.3.0 or 2.0 CD.
◆ NetBackup software distribution 4.5 CD.
◆ VSM version 4.5 CD.
◆ VERITAS Volume Manager (VxVM) 3.1 CD
◆ If using locally attached tapes, NetBackup Cluster Agent 1.3.0 or later.
◆ A shared disk for /usr/openv directory.
◆ Shared disks or file systems for the managed file systems, database and log directories
Caution Make sure the /usr/var/openv/hsm directory is not mirrored or replicated from another node in the cluster.
Installation
▼ On a new system, complete the following steps:
1. Install VERITAS Cluster Server as explained in the Cluster Server Installation Guide.
2. Install VERITAS Volume Manager (VxVM) 3.1 as explained in the Volume Manager Installation Guide.
3. Install NetBackup as explained in the NetBackup DataCenter Installation Guide - UNIX and Media Manager Device Configuration Guide - UNIX.
444 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General Configuration
Note You must install NetBackup on each node in the cluster.
4. If you want to failover NetBackup, install Enterprise Agent for NetBackup as explained in the Enterprise Agent for NetBackup, Installation and Configuration Guide.
Note You must install the Enterprise Agent for NetBackup on each node in the cluster.
5. Install VSM as explained in the VSM installation guide.
Note You must install VSM on each node in the cluster.
6. Install the Cluster Server Agent for Storage Migrator using the same installation script used for VSM installation. You must have a valid license key.
Note You must install the Cluster Server Agent for Storage Migrator on each node in the the cluster.
The Enterprise Agent for Storage Migrator contains the following files:
/opt/VRTSvcs/bin/StorageMigrator/StorageMigratorAgent/opt/VRTSvcs/bin/StorageMigrator/online/opt/VRTSvcs/bin/StorageMigrator/offline/opt/VRTSvcs/bin/StorageMigrator/clean/opt/VRTSvcs/bin/StorageMigratorFS/StorageMigratorFSAgent/opt/VRTSvcs/bin/StorageMigratorFS/online/opt/VRTSvcs/bin/StorageMigratorFS/offline/opt/VRTSvcs/bin/StorageMigratorFS/clean/etc/VRTSvcs/conf/StorageMigratorTypes.cf/etc/VRTSvcs/conf/agent_config.sh
General ConfigurationTo ensure proper failover behavior, configure the Enterprise Agent for Storage Migrator so that it matches your VSM configuration.
This document describes possible configurations that cover the most common cases. You need to customize these configurations to suit your needs.
The typical configurations are as follows:
◆ Active-inactive configuration with NetBackup.
◆ Active-inactive configuration with FTP method
Appendix B, Enterprise Agent for Storage Migrator 445
General Configuration
Import FilesBefore you begin the configuration, import the StorageMigratorTypes.cf file that contains the type definitions for both the StorageMigrator and StorageMigratorFS types using hagui, as follows:
1. Run the hagui & command.
2. Log into the cluster.
3. Select File > Import Types.
4. Select the StorageMigratorTypes.cf file.
5. Click Import.
6. Exit the interface.
VSM ConfigurationConfigure each managed file system (hsmname) as follows:
◆ The managed file system must be shared among nodes in the cluster
◆ VSM databases and logs are shared among nodes in the cluster
Note The managed file system configuration is only done on one node in the cluster.
Agent Configuration UtilityEnterprise Agent for Storage Migrator contains a configuration utility called agent_config.sh. This utility attempts to create resources, resource groups, and dependencies based on the VSM configuration it finds on the system. To use this utility, VSM must be properly configured, mounted, and Active.
The agent_config.sh utility does not create low level resources. It creates the following:
◆ A StorageMigrator resource to handle the daemons.
◆ Either a single StorageMigratorFS group, if active-inactive configuration is requested, or a separate StorageMigratorFS group for each VSM to be configured for failover.
◆ Mount resources for the databases, logs, and managed file systems it finds.
446 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General Configuration
◆ If it finds that the block devices for the managed file systems are presented by VERITAS Volume Manager, it creates DiskGroup resources for disk group failover.
The agent_config.sh utility lists systems for which it can configure resources. Selected systems will have managed file system resources configured. The agent_config.sh utility will list managed file systems that should be configured for cluster management.
The syntax for agent_config.sh is as follows:
/etc/VRTSvcs/conf/agent_config.sh [-i[o] | -u]
Note You run agent_config.sh only on the node where you configured the managed file systems.
To configure managed file systems in separate resource groups, which allows the default active-active configuration, run the following command:
# /etc/VRTSvcs/conf/agent_config.sh -i
To configure managed file systems in one resource group, run the following command:
# /etc/VRTSvcs/conf/agent_config.sh -io
It may be necessary, based on how systems in your cluster are configured, to add resources and dependencies manually in order to ensure proper failover behavior. Use the hagrp and harcs commands to show all resources, resource groups, and dependencies have been created. If any requisite groups, resources, or dependencies were not created, create them manually as described in “Manual Configuration.”
To unconfigure an existing VSM Cluster Server configuration that was configured by agent_config, run the following command:
# /etc/VRTSvcs/conf/agent_config.sh -u
Manual ConfigurationBefore configuring Enterprise Agent for Storage Migrator, determine what file systems will be configured and their respective attributes.
You need to know the block device of the managed file system.
You also need to know the following, found either in VSM-Java or the migconfg global configuration file:
◆ The hsmname, which is the name of the VSM managed file system
◆ Database path
◆ Log file path
Ensure that you do the following when you configure:
Appendix B, Enterprise Agent for Storage Migrator 447
General Configuration
◆ Create a global configuration file (/usr/var/openv/hsm/databse/migconfg) that is different for each system in the cluster. Do no share or replicate this directory.
◆ Ensure that managed file systems are available on each system in the cluster. You can use shared disks or replication.
◆ Ensure that the VSM databases and the log files are available on each system in the cluster. You can use shared disks or replication to achieve this.
◆ Ensure that database path and the log file path are not in a managed file system.
◆ Determine primary systems for the managed file systems. On each primary system, configure VSM managed file systems.
◆ Ensure that the log file path is available to each system in the cluster and is set to be a shared file system. VSM-Java selects a default log file path name. After configuring the file system, you must change the default log file path name to a file system that resides on a shared disk
▼ If any of the file systems, including those containing databases, logs, and managed file systems, must be shared (exported), configure them with the Share Agent:
1. Configure the Mount and StorageMigratorFS resources. This is fully explained in “Manual Active-Inactive Configuration using NetBackup” on page 453.
2. Configure matching Share resources. The Share PathName is the same as the MountPoint in the Mount type and StorageMigratorFS type.
3. Make the Share resources dependent upon the StorageMigratorFS or Mount resource. This allows file systems to be mounted before they are shared. If this dependency is not created, the file system mount requests will fail with a busy error.
The figure “Sample Hardware Configuration” on page 449 shows a cluster with two nodes: trixie and pixie. Both these nodes are running Solaris 2.7. The configuration is outlined as follows:
◆ The node pixie is the primary system for the managed file system hsm1.
◆ The node cranberry is not part of the cluster. It is used by the ft method.
◆ /hsm1 and /hsm2 are managed file systems. They are available to trixie and pixie on shared disk drives.
◆ /db1 is a shared file system for the /hsm1 databases.
◆ /db2 is a shared file system for the /hsm2 databases.
◆ /log1 a shared file system for the /hsm1 logs.
◆ /log2 a shared file system for the /hsm2 logs.
◆ The shared file systems must be on disks available to all nodes in the cluster.
448 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General Configuration
Sample Hardware Configuration
/log1
/db2
/db1
/hsm2
/hsm1
NODE NODEPRIVATE NETWORK
HP DLTLIBRARY
trixie pixie
PUBLIC NETWORK
FTP SERVER
cranberry
/log2
Appendix B, Enterprise Agent for Storage Migrator 449
General Configuration
▼ To configure the Enterprise Agent for Storage Migrator:
1. Configure a VCS cluster as described in the Cluster Server User’s Guide.
2. Configure managed file systems on the primary node.
3. Select the appropriate configuration option based on your needs, and follow the steps provided in that section:
- “Manual Active-Inactive Configuration using NetBackup” on page 453.
- “Manual Active-Active Configuration using FTP” on page 450.
Note The configurations in this document are examples. They do not necessarily represent the only way to configure Enterprise Agent for Storage Migrator.
Manual Active-Active Configuration using FTP
The following figure shows how parts of Enterprise Agent for Storage Migrator in an active-inactive configuration are dependent on others.
450 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General Configuration
Dependencies for Active-Active Configuration with FTP
This configuration can be explained as follows:
◆ pixie is the primary node for hsm1.
◆ trixie is the primary node for hsm2.
◆ Two StorageMigratorFS Agent resource groups, StorageMigratorFSGroup1 and StorageMigratorFSGroup2, are necessary.
◆ The Parallel attribute for the StorageMigratorGroup is set to be online on all systems simultaneously.
◆ In an active-active configuration, the /usr/openv directory on both nodes must be available only to that node.
StorageMigratorFSGroup1
StorageMigratorGroup
StorageMigratorFSGroup1 and StorageMigratorFSGroup2 require StorageMigratorGroup.
StorageMigratorFS
StorageMIgrator theDaemons
StorageMigratorFS
NBUGroup is not used in this configuration.
hsm1
hsm2
.StorageMigratorFSGroup1 and StorageMigratorFSGroup2 are independent of each other.
StorageMigratorFSGroup2
Mount log1Mount db1
Mount log2Mount db2
Appendix B, Enterprise Agent for Storage Migrator 451
General Configuration
▼ To complete an active-active configuration with the FTP method:
1. Add one StorageMigrator Agent resource type in the cluster:
# hagrp -add StorageMigratorGroup# hagrp -modify StorageMigratorGroup Parallel 1# hagrp -modify StorageMigratorGroup SystemList pixie 1 trixie 2# hares -add theDaemons StorageMigrator StorageMigratorGroup
Note Repeat step 2 and step 3 for each managed file system. Set the resource name equal to the managed file system name and use appropriate resource attributes.
2. Create the StorageMigratorFSAgent resource group 1:
# hagrp -add StorageMigratorFSGroup1# hagrp -modify StorageMigratorFSGroup1 SystemList pixie 1 trixie 2
3. Add the managed file system resource to the group:
# hares -add hsm1 StorageMigratorFS StorageMigratorFSGroup1# hares -modify hsm1 MountPoint /hsm1# hares -modify hsm1 BlockDevice /dev/dsk/c1t2d0s6# hares -modify hsm1 DatabasePath /db1/hsm/database/hsm1# hares -modify hsm1 LogFilePath /log1/hsm/logs/hsm1# hares -modify hsm1 HsmName hsm1
4. Add /db1 as a Mount resource:
# hares -add db1 Mount StorageMigratorFSGroup1# hares -modify db1 MountPoint /db1# hares -modify db1 BlockDevice /dev/dsk/c1t2d0s5# hares -modify db1 FSType vxfs
5. Create /log FS /log1:
# hares -add log1 Mount StorageMigratorFSGroup1# hares -modify log1 MountPoint /log1# hares -modify log1 BlockDevice /dev/dsk/c6t6d0s6# hares -modify log1 FSType vxfs
6. Create StorageMigratorFSGroup2:
# hagrp -add StorageMigratorFSGroup2# hagrp -modify StorageMigratorFSGroup2 SystemList pixie 2 trixie 1
7. Add the managed file system resource to the group:
# hares -add hsm2 StorageMigratorFS StorageMigratorFSGroup2# hares -modify hsm2 MountPoint /hsm2
452 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General Configuration
# hares -modify hsm2 BlockDevice /dev/dsk/c1t2d0s3# hares -modify hsm2 DatabasePath /db2/hsm/database/hsm2# hares -modify hsm2 LogFilePath /log2/hsm/logs/hsm2# hares -modify hsm2 HsmName hsm2
8. Add /db2 as a Mount resource:
# hares -add db2 Mount StorageMigratorFSGroup2# hares -modify db2 MountPoint /db2# hares -modify db2 BlockDevice /dev/dsk/c1t2d0s5# hares -modify db2 FSType vxfs
9. Create /log FS /log2:
# hares -add log2 Mount StorageMigratorFSGroup2# hares -modify log2 MountPoint /log2# hares -modify log2 BlockDevice /dev/dsk/c7t2d1s6# hares -modify log2 FSType vxfs
10. Set up dependencies:
# hares -link hsm1 db1# hares -link hsm2 db2# hares -link hsm1 log1# hares -link hsm2 log2# hagrp -link StorageMigratorFSGroup1 StorageMigratorGroup \online local# hagrp -link StorageMigratorFSGroup2 StorageMigratorGroup \online local
11. Enable the resources in the groups:
# hagrp -enableresources StorageMigratorGroup# hagrp -enableresources StorageMigratorFSGroup1# hagrp -enableresources StorageMigratorFSGroup2
12. Make the VCS configuration read-only:
# haconf -dump -makero
Manual Active-Inactive Configuration using NetBackup
The following figure shows how parts of Enterprise Agent for Storage Migrator in an active-inactive configuration are dependent on others.
Appendix B, Enterprise Agent for Storage Migrator 453
General Configuration
Dependencies for Active-Inactive Configuration with NetBackup
▼ To complete an active-inactive configuration with NetBackup:
1. Start VCS:
# hastart -force
2. Make the VCS configuration read/write:
# haconf -makerw
3. Configure the Enterprise Agent for NetBackup. An example NBUGroup definition follows:
group NBUGroup (SystemList = { pixie, trixie })
Mount openv_mnt (MountPoint = "/usr/openv"
BlockDevice = "/dev/dsk/c1t2d0s4"FSType = vxfs)
StorageMigratorFSGroup
StorageMigratorGroup
NBUGroup
StorageMigratorFSGroup requires StorageMigratorGroup, which requires NBUGroup.
Mount /mnt1
StorageMigratorFS
StorageMigrator
theDaemons
hsm1
454 VERITAS Storage Migrator System Administrator’s Guide for UNIX
General Configuration
NetBackup netBackup (ServerType = NBUMaster)
NetBackup requires openv_mnt
4. If you have not yet done so, import the StorageMigratorTypes.cf file that contains the type definitions for both the StorageMigrator and StorageMigratorFS types using hagui, as follows:
a. Run the hagui & command.
b. Log into the cluster.
c. Select File > Import Types.
d. Select the StorageMigratorTypes.cf file.
e. Click Import.
f. Exit the interface.
5. Add one VSM resource type in the cluster, as follows:
# hagrp -add StorageMigratorGroup# hagrp -modify StorageMigratorGroup Parallel 0# hagrp -modify StorageMigratorGroup SystemList pixie 1 trixie 2# hares -add theDaemons StorageMigrator StorageMigratorGroup
6. Create the StorageMigratorFS resource group:
# hagrp -add StorageMigratorFSGroup# hagrp -modify StorageMigratorFSGroup SystemList pixie 1 trixie 2
Note Repeat step 7 and step 8 for each managed file system. Set the resource name equal to the managed file system name, and use other attributes as appropriate.
7. Add the managed file system resource to the group:
# hares -add hsm1 StorageMigratorFS StorageMigratorFSGroup# hares -modify hsm1 HsmName hsm1# hares -modify hsm1 MountPoint /hsm1# hares -modify hsm1 BlockDevice /dev/dsk/c1t2d0s6# hares -modify hsm1 DatabasePath /db1/hsm/database/hsm1# hares -modify hsm1 LogFilePath /db1/hsm/logs/hsm1
Appendix B, Enterprise Agent for Storage Migrator 455
Sample Configuration File Entries
8. Add /db1 as a Mount resource:
# hares -add db1 Mount StorageMigratorFSGroup# hares -modify db1 MountPoint /db1# hares -modify db1 BlockDevice /dev/dsk/c1t2d0s5# hares -modify db1 FSType vxfs
9. Add /log1 as a Mount resource:
# hares -add log1 Mount StorageMigratorFSGroup# hares -modify log1 MountPoint /db1# hares -modify log1 BlockDevice /dev/dsk/c1t2d0s5# hares -modify log1 FSType vxfs
10. Set up the dependencies:
# hagrp -link StorageMigratorGroup NBUGroup online local# hares -link hsm1 db1# hares -link hsm1 log1# hagrp -link StorageMigratorFSGroup StorageMigratorGroup online \ local
11. Enable the resources in the groups:
# hagrp -enableresources StorageMigratorGroup# hagrp -enableresource StorageMigratorFSGroup
12. Make the VCS configuration read-only:
# haconf -dump -makero
Sample Configuration File EntriesThe following are example entries as they could appear in your /etc/VRTSvcs/conf/config/main.cf and /etc/VRTSvcs/conf/StorageMigratorTypes.cf files after completing one of the example configuration scenarios.
Sample /etc/VRTSvcs/conf/config/main.cf file entries:
group StorageMigratorFSGroup (SystemList = { pixie, trixie })
StorageMigrator theDaemons ( )
456 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Maintaining Your System
StorageMigratorFS hsm1 ( HsmName = "hsm1"
MountPoint = "/hsm1"BlockDevice = "/dev/dsk/c1t2d0s6"DatabasePath = "/db1/hsm/database/hsm1/"LogFilePath = "/log1/hsm/logs/hsm1")
Mount db1 (MountPoint = "/db1"BlockDevice = "/dev/dsk/c1t2d0s5"FSType = vxfs)
Mount /log1(MountPoint = "/log"BlockDevice = "/dev/dsk/c1t2d0s16"FSType = vxfs)
Sample of /etc/VRTSvcs/conf/StorageMigratorTypes.cf entries:
type StorageMigrator (static str LogLevelstr dvstatic str ArgList[] = { dv }NameRule = ""
)
type StorageMigratorFS (static str LogLevel
static str ArgList[] = { HsmName, MountPoint, BlockDevice, DatabasePath, LogFilePath }NameRule = ""str MountPointstr BlockDevicestr DatabasePathstr LogFilePathstr HsmName
Maintaining Your SystemYou can monitor, configure, and change the resources in the cluster by using either the VCS interface or VCS commands.
Appendix B, Enterprise Agent for Storage Migrator 457
Removing the Enterprise Agent for Storage Migrator
If you find a handle mismatch on a migrated file after a managed file system has been failed over to a different node in the cluster, you should synchronize the major numbers in the /etc/name_to_major file in each of the nodes in the cluster using the haremajor command.
Read the following cautionary statements to ensure that the Enterprise Agent for Storage Migrator works smoothly at your site
Caution When a managed file system is under VCS control, always leave its state Active. Failure to do so will cause the system to fault. If you need to change the state, use the hagrp command to ensure that the StorageMigratorFSGroup is offline.
Caution While the resource is online, do not manually unmount file systems managed and used by the Enterprise Agent for Storage Migrator.
Caution When the Enterprise Agent for Storage Migrator is Active, do not add and remove entries from VSM global configuration files on any system in the cluster. The StorageMigratorFS Agent automatically adds and removes entries as required for configuration.
Caution If you create entries in the /etc/vfstab for the file systems, make sure they are set so they will not mount at boot. If they mount at boot, there could be concurrency violations during failover.
Caution Do not share (export) /usr/openv/, VSM databases, or managed file systems without using the VCS Share resource. If they are shared, the StorageMigratorFS Agent resources will fail to mount the file systems. See “General Configuration” on page 445 for more information.
Removing the Enterprise Agent for Storage MigratorThe following procedure explains how to remove the Enterprise Agent for Storage Migrator.
▼ To remove the Enterprise Agent for Storage Migrator:
1. Unlink all groups you do not want to take offline from the StorageMigrator and StorageMigratorFS groups.
2. Set the StorageMigrator and StorageMigratorFS groups to offline.
458 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Getting Help
3. Remove the resources from the groups and remove the groups themselves.
4. Stop the StorageMigrator and StorageMigratorFS Agents that were started by VCS.
5. Remove the software package VRTSsmvcs by running the pkgrm command. This will remove the files installed by the installation script.
Getting HelpIf you have questions about Enterprise Agent for Storage Migrator, access the website below:
http://support.veritas.com
Appendix B, Enterprise Agent for Storage Migrator 459
Getting Help
460 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Notes on Supported Optical Media
C If you use optical storage media, you should know the following information about VSM and NetBackup support of optical disks.The following is true of supported hardware:
◆ HP Optical drives support some older optical platters as read-only.
◆ When attempting to write to an optical platter that is supported as read-only, the media will be reported as needing write enabled, regardless of the physical write protect tab setting.
◆ Although Media Manager can format optical platters, VERITAS strongly urges you to use preformatted platters.
The following is true of operating system platform support:
◆ All platforms and operating systems do not support all available sector sizes for optical platters.
◆ The format of optical platters is platform-specific. Optical platters written on one platform cannot be read on another platform.
◆ The Solaris 8 6/00 release introduced volume manager (vold), which attempts to manage all removable media devices. When vold manages an optical disk, NetBackup cannot access it.
To enable NetBackup access, so that optical disks will then work as they did before this change, edit /etc/vold.conf to comment out the following line:
#use rmdisk drive /dev/rdsk/c*s2 dev_rmdisk.so rmdisk%d
The following is true of NetBackup support of optical media:
◆ Optical platters with a capacity larger than 5.2 GB are not supported.
◆ NetBackup does write a maximum of 2 GB of data per side of an optical platter. This provides a maximum of 4 GB of data per platter. Additional platter capacity is unused.
◆ NetBackup supports HP 92279T, HP 92289T, and HP 92279F media on AIX platforms. VSM does not run on AIX platforms.
461
VSM supports the following sector sizes and capacity combinations on HP-UX, Solaris, and IRIX:
Supported Optical Media
Platform Model SectorSize
Capacity Type Notes about NetBackup Support
HP-UX HP 92279T* 512 1.2GB WriteMany
HP 92289T 512 1.2GB WriteOnce
HP 92279F 512 2.3GB WriteMany
HP 92289F 512 2.3GB WriteOnce
SONY EDM4100B 512 4.1GB WriteMany
SONY CWO4100B 512 4.1GB WriteOnce
HP C7988A* 512 9.1GB WriteMany Media Manager can mount this media. VSM writes to it, but NetBackup does not.
HP 92298T 1024 1.3GB WriteMany
HP 92290T 1024 1.3GB WriteOnce
HP 92280F 1024 2.6GB WriteMany
HP 92290F 1024 2.6GB WriteOnce
HP 88143J 1024 4.8GB WriteMany
HP 88145J 1024 4.8GB WriteOnce
HP C7987A 1024 9.1GB WriteMany Media Manager can mount this media. VSM writes to it, but NetBackup does not.
HP 88147J 2048 5.2GB WriteMany
HP 88146J 2048 5.2GB WriteOnce
HP C7985A 2048 8.6GB WriteMany Media Manager can mount this media. VSM writes to it, but NetBackup does not.
* See the following HP web site for more information about compatibility for these optical platters: http://www.products.storage.hp.com/eprise/main/storage/DisplayPages/compatibility.htm?DataPage=rewritable-disks
462 VERITAS Storage Migrator System Administrator’s Guide for UNIX
HP-UX(continued)
HP C7985A 2048 8.6GB WriteMany Media Manager can mount this media. VSM writes to it, but NetBackup does not.
HP C7986A 2048 8.6GB WriteOnce Media Manager can mount this media. VSM writes to it, but NetBackup does not.
HP C7983A 4096 9.1GB WriteMany Media Manager can mount this media. VSM writes to it, but NetBackup does not.
HP C7984A 4096 9.1GB WriteOnce Media Manager can mount this media. VSM writes to it, but NetBackup does not.
Solaris HP 92279T 512 1.2GB WriteMany
HP 92289T 512 1.2GB WriteOnce
HP 92279F 512 2.3GB WriteMany
HP 92289F 512 2.3GB WriteOnce
SONY EDM4100B 512 4.1GB WriteMany
SONY CWO4100B 512 4.1GB WriteOnce
HP C7988A 512 9.1GB WriteMany Media Manager can mount this media. VSM writes to it, but NetBackup does not.
IRIX HP 92279T 512 1.2GB WriteMany
HP 92289T 512 1.2GB WriteOnce
HP 92279F 512 2.3GB WriteMany
HP 92289F 512 2.3GB WriteOnce
HP 92298T 1024 1.3GB WriteMany
HP 92290T 1024 1.3GB WriteOnce
HP 92280F 1024 2.6GB WriteMany
HP 92290F 1024 2.6GB WriteOnce
Supported Optical Media
Platform Model SectorSize
Capacity Type Notes about NetBackup Support
Appendix C, Notes on Supported Optical Media 463
464 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Glossary
ad method
The method name for migrating to alternate disk.
alternate copy
The second copy of a migrated file. See also primary copy.
alternate level
The migration level that pertains to the second copy of a migrated file. VSM-Java designates the level for the Alternate copy of a file as Alternate Level: 2 and the multilevel migration levels associated with it as Alternate Level: 4, and so on. See also primary level.
API
Application Programming Interface. See also DMAPI.
archiving
The process of backing up files and directories to a storage unit and then deleting the original files and directories.
backup
The process of copying and saving files and directories to storage media.
badness
See threshold, move threshold, and purge threshold. References in this manual to badness have been changed to threshold, although “badness” is still used in some commands and scripts. Badness refers to the parameters used for selecting files to be migrated, moved, or purged.
caching
The process of copying migrated files back to the managed file system for access.
465
caching delay
The length of time an application is blocked after accessing migrated data and before the data is available online (cached).
concurrent recording
The process of copying data to more than one storage device at the same time. Sometimes called concurrent stripes.
configuration file (migconf)
The file that contains the migration parameters for a single managed file system. The default path name for this file is dwpath/database/migconf.
configuration file, global (migconfg)
The file that defines a collection of managed file systems along with their attributes. The default path name for this file is /usr/var/openv/hsm/database/migconfg.
configured slice
The portion of the front of a file retained on disk for user access even when the file is completely migrated.
consolidation
See volume consolidation.
ct method
The method name for migrating to STK-9840 technology cartridge tapes (8mm double-density). VSM-Java refers to this storage method as Tape 2. Densities for storage methods are configurable.
daemon
A program that runs in the background and performs some task (for example, starting other programs when they are needed). See migd daemon, migrd daemon, and migvold daemon.
defragmenting directories
Data in a directory can be grouped, then migrated and cached as a one entity. When you defragment a directory, you first cache any previously migrated data and then migrate all data in the directory to a minimal number of tapes. Defragmenting reduces the mount and search time whenever the grouped directory is cached.
466 VERITAS Storage Migrator System Administrator’s Guide for UNIX
demand delay parameter
The time in seconds a mount request waits before VSM unmounts a similar unused volume.
device manager
The part of Media Manager that allocates or deallocates drives based on availability.
directory groups
Directories that have been grouped so its files and those in its subdirectories will be selected for migration, premigrated, migrated, purged, and cached as one entity.
dk method
The method name used for copies of a file not yet copied to secondary storage. The dk method is not available as a secondary storage method.
DMAPI
Data Management Application Programming Interface. DMAPI is the interface between Storage Migrator and the operating system kernel.
dt method
The method name for migrating DLT 7000 technology tapes. VSM-Java refers to this method as Tape 3. Densities for storage methods are configurable.
dwpath
The pathname of the managed file system directory containing the database and workdir directories.
effective slice
The variable portion of a migrated file that can be partially cached (copied back) to disk if partial file caching is enabled.
empty volume
A volume that contains no active or obsolete files. See recycling.
ENOSPC
The error condition indicating there is no space left on a device.
Glossary 467
export
The process of removing migrated files from one managed file system that will be imported to another managed file system. See also import.
file handle
A unique sequence number that VSM uses to identify migrated files and unmodified cached files. File handles are stored in the VSM databases for the managed file system.
FHDB
The file handle database. Each managed file system uses a separate file handle database. The default path name for this file is dwpath/database/FHDB.
FNDB
The file name database. Each managed file system uses a separate file name database. The default path name for this file is dwpath/database/FNDB.
free space
The space in the managed file system that is open for creating new files.
free space parameter
The disk utilization point at which VSM begins to free disk space by deleting purge candidates. This value is expressed as a percentage of unused space. If the freespace parameter is set to 10, VSM will begin to delete purge candidates when the file system is 90% full. Sometimes referred to as the high-water mark.
ft method
The method name for migrating to a remote volume using FTP.
FTP
File Transfer Protocol.
global configuration file
See configuration file, global (migconfg).
global stop file
See stop file, global.
468 VERITAS Storage Migrator System Administrator’s Guide for UNIX
granule
VSM can divide migrated files into granules (parts of files) when it copies them to secondary media. A granule is the smallest unit of a file; it is never split across volumes. The size of the granule is configurable.
grouped directory
See directory groups.
GUI
Graphical User Interface. The VSM GUI is called VSM-Java.
handle
See file handle.
hierarchical storage management (HSM)
The process of automatically migrating selected files from a managed file system to secondary storage while maintaining transparent user access to those files.
hierarchy
A managed file system and its migration attributes; used by VSM-Java.
high-water mark
See free space parameter.
hint value
See volume set availability.
HSM
See hierarchical storage management (HSM).
In previous versions of documentation for this product, HSM referred to VERITAS Storage Migrator. All such references are now VSM server.
HSMDEV entry
The hsmname in the global configuration file that specifies the attributes of a managed file system.
hsmname
The name of a managed file system. This is usually the same as the file system mount point. The maximum length is 32 characters.
Glossary 469
IHAND file
The inode-to-handle file, containing inode and handle information about migrated files. The default path name for this file is dwpath/database/hsmname.IHAND.
import
The process of adding migrated files to one managed file system that previously have been exported from another managed file system. See also export.
inode
The data structure that defines the existence of a single file.
level, migration
See migration level.
library volume set availability
The volume set availability (the configuration parameter that designates how long it takes VSM to access data on secondary storage) of a stripe is set to library to specify that VSM needs the minimum time to access data. Generally library indicates online storage (such as tape or disk). library is the default for the primary copy of a file.
low-water mark
The disk utilization point at which VSM stops selecting migration candidates. This value is expressed as a percentage of used disk space. If the low-water mark is set to 80, VSM will stop selecting migration candidates when the managed file system is 80% full.
managed file systems
The combination of components that VSM uses to organize and manage file data.
managed server
See VSM server.
media
The physical tapes, optical disks, or disks upon which data is stored.
Media Manager
The VERITAS software that provides device management and removable media management of tapes and optical disks. VSM requires Media Manager to operate.
470 VERITAS Storage Migrator System Administrator’s Guide for UNIX
method name
The name assigned to a set of parameters referring to storage device and media. See storage method.
migd daemon
The migration daemon. The default path name for this file is /usr/openv/hsm/bin/admincmd/migd.
migrate file, global
A list of files or directories that the administrator wants VSM to select for migration.
migrate file, local
A list of files or directories that a user wants VSM to select for automatic migration.
migration
The process of copying files to secondary storage while retaining the file names in the managed file system and providing access to file data.
migration level
The numbered level associated with the location of a migrated file copy on secondary storage. The primary level stores the first copy of a file and is required for migration. VSM has up to eight multilevel migration levels.
migration candidates
The files that VSM determines can be migrated according to predefined selection criteria configured by the VSM administrator.
migrd daemon
The migration request daemon used for VSM-Java. The default path name for this file is /usr/openv/hsm/bin/admincmd/migrd.
migvold daemon
The volume daemon. The default path name for this file is /usr/openv/hsm/bin/admincmd/migvold.
MOTAB
Mount table file. The MOTAB file is used to keep track of all volumes mounted for read access only. The migvold will create the MOTAB file if it does not exist.
Glossary 471
move threshold
The calculated value for a file that determines whether or not it is selected to be moved from one migration level to another. Formerly called move badness.
mount point
The location of a file system on a disk that logically connects to a system’s directory structure. This connection makes the file system available to users and applications. A file system’s mount point is usually the same as its hsmname, but this is not required.
mt method
The method name for migrating to Sony AIT-2 technology 8 mm tapes. In VSM-Java, this method is named Tape 1. Densities for storage methods are configurable.
multilevel migration
The process of moving migrated files to and from up to eight migration levels (locations on secondary storage) with VSM.
nb method
The method name for using NetBackup to make copies of files for migration.
Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release.
Several disadvantages exist in using the NetBackup method, as described in the VERITAS Storage Migrator System Administrator’s Guide for UNIX. Read this information before you consider configuring the nb method.
NetBackup policy
Defines the backup policy for a group of one or more clients that have similar backup requirements.
NFS
Network File System. A Sun Microsystems client-server application that allows network access to shared files.
offline storage
Storage media not physically loaded in a storage unit.
472 VERITAS Storage Migrator System Administrator’s Guide for UNIX
op method
The method name for migrating to optical disk as tape with random seek. The default for this method is rewritable optical disk, but the value is configurable.
operator volume set availability
The volume set availability (the configuration parameter that designates how long it takes VSM to access data on secondary storage) of a stripe was set to operator to specify operator intervention was required to mount volumes. The value operator is not configurable using VSM-Java.
ow method
The method name for migrating to optical disk as tape with random seek. The default for this method is write-once, read many (WORM) optical disk, but the value is configurable.
partial file caching
The VSM process that allows read access to a migrated file without caching the entire file.
policies, NetBackup
See NetBackup policy.
premigration
The first step in the migration process, during which files are assigned a file handle and put on a migration work list.
primary copy
The first copy of a migrated file. See also alternate copy and primary level.
primary level
The migration level that pertains to the first copy of a migrated file. VSM-Java designates the level for the Primary copy of a file as Primary Level: 1 and the multilevel migration levels associated with it as Primary Level: 3, and so on. See also alternate level.
pseudodevice
A UNIX device with a /dev entry and a device driver that does not require a real device for I/O.
purge
The process of deleting files from local disk that have been copied to secondary storage.
Glossary 473
purge candidates
The managed files that have been copied to one or more secondary storage devices and remain on local disk. VSM can purge these files to manage the configured threshold of free space in the file system.
purge mark
The disk utilization point at which VSM stops deleting purge candidates. This value is expressed as a percentage of used disk space. If the purge mark is set to 85, VSM will stop deleting purge candidates when the managed file system is 85% full.
purge threshold
The calculated value for a migrated file that determines whether or not it is selected to be purged. Formerly called purge badness.
quota parameter
The maximum number of bytes that each user can restrict from migration.
recycling
The process of recovering wasted space on storage media by reregistering an empty volume.
remote volume server
The server upon which a remote volume resides.
remote storage
The storage of migrated files on a remote volume server. See ft method and ad method.
restore
The process of recovering selected files and directories from a previous backup and returning them to their original directory locations (or to an alternate directory).
secondary storage
Storage of migrated files on storage units connected locally to the managed server.
slice
The configured amount of the front of a migrated file that remains on local disk to enable rapid access. See also configured slice and effective slice.
474 VERITAS Storage Migrator System Administrator’s Guide for UNIX
sparse file
A file with large amounts of blank space in it. Such files save disk space because the file system does not allocate disk space to the file until blank space is taken up by data.
stop file, global
A list of files or directories of files that the administrator does not want to migrate.
stop file, local
A list of files or directories of files that a user does not want to migrate.
storage method
The specification of how migrated files are copied to different migration locations in secondary storage. A storage method consists of one or more stripes (location parameters).
storage unit
The type of storage device on which VSM or NetBackup stores files. It may be a robotic device or a single tape drive.
stripe
The set of location parameters used to define a storage method: method name, volume set number, volume set availability, and pool name. A storage level consists of stripes.
threshold
The calculated value for a file that determines whether or not it is selected to be migrated. References in this manual to badness have been changed to threshold, although the term badness is still used in some commands and scripts.
threshold, move; threshold, purge
See move threshold; purge threshold.
unmount delay parameter
The time in seconds that a volume mounted in read mode can remain mounted pending another read request.
volume set availability
The volume set availability (the configuration parameter that designates how long it takes VSM to access data on secondary storage) of a stripe is set to vault to specify that VSM needs the maximum time possible to access data. Generally vault indicates offline, or even off site, storage. vault is the default for the Alternate copy of a file.
Glossary 475
VOLDB
The VSM volume database, which contains attributes of each volume registered with VSM. The default path name for this file is dwpath/database/VOLDB
volume
A tape, optical disk, or disk partition that has been registered and labeled.
volume consolidation
The process of moving file data from volumes to be recycled to other volumes and updating the VSM databases. See also empty volume and recycling.
volume manager
See Media Manager.
volume pool
A group of volumes to be used for one purpose that are protected from access by other applications and users.
volume set
One or more volumes sharing the same method name and volume set number.
volume set availability
The configuration parameter that specifies how quickly VSM can access data on secondary storage. The value library specifies immediate availability; the value vault specifies offline storage. The value operator is not configurable using VSM-Java; it was formerly used to specify that operator intervention was required to mount volumes.
volume set number
The number assigned to a volume when media is registered (labeled). See storage method.
VSM-Java
Graphical user interface to VSM configuration, administration. and management tools.
VSM server
The server on which the managed file systems reside and VSM software executes.
WORM
Write Once, Read Many; the acronym for optical disks or tapes that can be written to one time and read many times.
476 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Index
AAccelerated file space availability
configuration 130file increment 131overview 30performance trade-offs 69space increment 131time increment 131
AccessibilityVSM-Java 90
Access-time bias (volume set availability) 62Action menu
VSM-Java 100Active state
managed file systems 193managedfile systems 8
Activity barVSM-Java 94
Activity statessee States
ad method 60overview 1
Administration interfacesee VSM-Java
Age weightconfiguring 134moving files 83purging files 81selecting files 75
Alternate leveldefinition 465
Alternate magnetic disksee ad method
APIs
definition 465Append flag 119Architecture
overview 6Architecture, VSM 6Archiving
definition 465
BBackups
definition 465managed file systems 190NetBackup requirement 6VSM databases 190VSM procedure 191
Badnesssee Thresholds
Basic Configuration Wizard 103block_size parameter 120bpbkar and bpbtar
NetBackup requirement 6
CCaches
choosing copy to use 15, 17, 20, 31, 62definition 465delays
definition 466demand delay parameter 15multilevel migration 31optimizing performance 64overview 13partial file caching 17Reporting Tool and 163total and partial file caching
477
trade-offs 68total file caching 16unmount delay parameter 15
CapacityAdvanced Configuration Wizard 120, 122
Cautionschanging the IHAND file 195configuring two drives for two copies 57database directory 49editing VSM databases 232, 251FlashBackup 190forced registration 66NetBackup
backup retention 191policy conflicts 190
NFS mount point 3Partial VSM restore 191Restore previous VOLDB 190volume management 202
Characters, specialsupported in VSM 74
Class, NetBackupsee NetBackup policy
Commandsgethsm 264HSMKiller 266ihprint 268Man pages 261migactivate 273migadscan 275migalter 278migbatch 24, 281migcat 284migchecklog 285migcleanup 288migconf 290migconfg 306migcons 310migconsweep 314migdbcheck 316migdbdir 327migdbrpt 328migfind 333
migftscan 335miggetvol 339miggroup 341migin 346miglicense 348migloc 350miglow 29, 353migmdclean 354migmove 358mignbexport 363mignbimport 367mignbscan 371mignewlog 375mignospace 377migpolicy 380migpurge 30, 382migrate 30, 383migrc 386migrd 388migreconstruct 389migrecycle 392migreg 395migselect 400migsetdb 402migstage 408migtestbadness 410migtie 415migtscan 419migungroup 341migunmigrate 423migVSMshutdown 424migVSMstartup 425migVSMstate 427rebuild_ihand 429startmigd 430stopmigd 432stopmigrd 434VSM 435
Concurrent recordingdefinition 466example 63restraints on 64
ConfigurationBasic Configuration Wizard 103files
478 VERITAS Storage Migrator System Administrator’s Guide for UNIX
definition 466migconf 56migconfg (global), definition 466
globaloverview 45planning 46
migrate (.migrate) file 218migstop (.migstop) file 218overview 45parameters
free space 468scripts 200storage devices 91update fstab file 200
Configuration paneScheduling tool 176
Configure menuVSM-Java 100
Configured slicedefinition 466recommended minimum 16
Consolidationvolume
multilevel migration 32one step 208overview 204two step 210
volumesdefinition 466
Copied dataReporting Tool 164
Copiesconcurrent recording 63configuring number of 57, 116parameter 116which to cache first 62
Copy processor 34copydb files
description 240multilevel migration 34overview 12
ct methoddefinition 466description 59overview 1
Customizationfile migration criteria 84file purging criteria 84migration policy 227migsweep.site 84, 242migsweepm.site 243
DDaemons
definition 466migd
overview 7migrd
starting 89migvold
overview 8starting 198starting and stopping 197
Data comparisonsof file systems 182
Database directory, location 39Database tools
VSM-Java 151Databases
backing up 190caution for editing 232, 251cautions when choosing 49checking consistency of 195choosing directories for 49description 232determining directories 49dwpath
definition 467file handle
see FHDBfile handle (FHDB)
definition 468file name
see FNDBfiles contained in 39list of 232managed
backup and delete 157migrating files 157searching 156
Index 479
managed server 233Media Manager 21migconf file 49Oracle
see Oracle archive redo logsproblem solving 251reports 249space requirements 51volume
see VOLDBDead data
consolidating volumes 204FHDB flags field 233multilevel migration 32recycling volumes 208, 213
Dead FHDB entriesmultilevel migration
move flags 150dead_man_timeout parameter 121, 123, 124Defragmenting
directories, definition 466Delayed labeling 125Deleted files
reloading 258demand delay parameter
Advanced Configuration Wizard 121caches 15definition 467
density parameterAdvanced Configuration Wizard 120
Device managerdefinition 467
Devicesstorage methods for 58
Directoriesremote volume server 42, 127
Directory groupsee Directory-level migration
Directory-level migration 20definition 20, 467
Diskmagnetic
see dk method, ad method, ft method
opticalsee Optical disk
Disk filestorage methods
see dk methodDisk space
ENOSPC errordefinition 467
FHDB 50management
overview 22dk method
definition 467overview 1
DMAPIdefinition 467token 197
Documentationrelated xxii
dt methoddefinition 467description 59overview 1
dump commandbacking up standard file systems 190backing up VSM databases 190cautions 191
dwpathdefinition 467
EEdit menu
VSM-Java 97Effective date
Scheduling tool 175Effective slice
definition 467Emergency file space parameters 30Empty volumes
definition 467recycling 213
End of tape flag 119
480 VERITAS Storage Migrator System Administrator’s Guide for UNIX
ENOSPCdefinition 467error 30
Exportsdescription 35of migrated files
definition 468overview 35planning 230
FFHDB 10, 49, 233
clear locks 252definition 468description 49, 233disk space 50estimated disk space 50fixing 251flags field
description 233multilevel migration 34
location 39, 307lock file
description 242location 307
number of entries 49problem solving for 251recovering 255space requirements 50template 42updating 12, 34
File Browser 167grouping directories 171main screen 167managing job activity 171migrating files 172migration 167purging files 172
File Export/Importsee Exportssee Imports
File handledefinition 468sequence file 242unassignable 255
File handle databasesee FHDB
File incrementaccelerated file space availability 30, 69configuring 131mignospace command and 28
File marks 229File menu
VSM-Java 97File name database
see FNDBFile servers
Macintosh 47VSM managed 476
File sliceconfigured
configuring 130definition 16replaces effective slice 19space requirements 48
effectivedefinition 16replaces configured slice 19, 68
overview 15size
configuring 130File slices
configureddefinition 466
effectivedefinition 467
File space, accelerated availability 30File System Analyzer
comparing data 182file system scans 182
deleting 188main screen 180menus 181testing migration policies 187
File systemscreating
fstab file 200managed
backing up 190
Index 481
checking consistency of 195considering number of files 48definition 45idle state 197inode requirements 48log files 245making free space on 196migration thresholds 70purge thresholds 80rules for choosing 46space for slice 48
mountingdemand delay 467
scans 182unmount delay parameter 475
File-handle-sequence filedescription 242location 39, 307rebuilding 255
Filenamesspecial characters
supported 74Files
disk 1not to migrate 46remote volume server 42
Flags fieldFHDB 233VOLDB 238
FlashBackup, caution for 190FLUSH file
definition and use 229location 40
FNDBdefinition 468
Free spacecreating on file systems 196definition 468file systems 196parameter
definition 468Free space parameter
default value 73description 22migration
configuring 132planning guidelines 73
fspathlocation 36
fstab fileupdating
for managed file systems 200ft method
definition 468overview 2partial file caching 17
FTPft method 2port number 123
Ggethsm command
man page 264GLABEL file 43Global log file
file systems in Maintenance state 195viewing 244
Global migrate filedefinition 471
Global stop filedefinition 475
gran_size parameterdescription 121, 122, 124
Granulesdefinition 469description 12file-handle entries for 49
Grouped filesmigration of 171
GUIsee VSM-Java
HHelp menu
VSM-Java 101Hierarchy
VSM-Javadefinition 469description 93
High-water mark
482 VERITAS Storage Migrator System Administrator’s Guide for UNIX
see Free space parameterHSMDEV entry
definition 469see also hsmname parameter
HSMKiller commandkilling blocked processes 252man page 266releasing tape requests 260
hsmname parameterdefinition 469
IID_LABEL file 43, 244Idle state 8, 193, 197Idling state 8, 193IHAND file
administering 198caution for changing 195check and fix 200creating 198definition 470description 198extending 199format 198location 40, 307recover 200space requirements 50, 199
ihprint commandman page 268
Illegal characters, file names 74imageID
nb method 203Imports
description 35of migrated files
definition 470overview 35planning 230
Inactive state 8, 193Inodes
definition 470managed file systems 48
InstallationVSM
overview 90
JJava
VSM-Java Administrator interface 89
Job activitymanagement
File Browser 171
LLabel
volumefor tape media 125
Label, volumealternate disk 125for FTP 126for NetBackup 128for tape media 66
lgpath parameteroverview 40
libraryvolume set availability
planning 62Links, symbolic 218, 219Local migrate file
definition 471Local stop file
definition 475Locks, clearing VSM 252Log files 248
choosing paths 51global log file, location 40linking global 200managed file systems
viewing 245managing 247messages, level of
location 41viewing 244, 245VSM-Java
creating for 248Logs
Oracle archive redo 153VSM management of Oracle redo logs 151
Low-water mark
Index 483
configuring 132default values 70definition 470description 22planning guidelines 70
MMacintosh file servers 47Magnetic disk
media 1Maintenance state 8, 193Man pages 261Managed directory
Oracle archive redo logs 130Managed file system
reportsReporting Tool 162
Managed file systemsdefinition 470
Managed server, definition 2Management tasks
scheduling with VSM-Java 173Managing VSM 189Manuals
related xxiiMedia
consolidate volumes 208definition 470magnetic disk 1monitoring usage 202moving volumes offline 214not enough tapes available 260optical
notes on support 461recycling 208registration
automatic, tape & optical 12, 203, 204
releasing tape requests 260reports 249storage methods to use 58
Media Managerconfiguring storage devices 91definition xxiii, 470device manager
definition 467installation 90overview 21shared storage devices 2terminology used xxiii
mediacheck commandfixing the FHDB 251
MenusAction
VSM-Java 100Configure
VSM-Java 100Edit
VSM-Java 97File
VSM-Java 97File System Analyzer 181Help
VSM-Java 101View
VSM-Java 98VSM-Java 97
Method namesdefinition 471migrating files 58
METHOD1-8examples 64name parameters
ct 59dt 59mt 59nb 61op 59ow 59
names to use formagnetic disk storage 58NetBackup 58NFS file system 58optical disk storage 58remote storage 58tape storage 58
overviewMETHOD1-2 57METHOD3-8 67
volume set availability
484 VERITAS Storage Migrator System Administrator’s Guide for UNIX
parameter 62MicroSoft platforms
for VSM-Java 90migactivate command
man page 273migadscan command
archive disk report 250man page 275
migalter commandman page 278
migattr driver 192migbatch command 24
calling from VSM-Java 223, 225, 226man page 281
migcat commandman page 284
migchecklog commandman page 285
migcleanup commandman page 288
migconf commandman page 290
migconf filedescription 243location 40, 307overview 56planning worksheet 49template 42
migconfg commandman page 306
migconfg filelocation 41overview 45planning worksheet 46template 41
migcons commandman page 310recycling volumes with 208
migconsweep commandman page 314
migcopy commandoverview 7
migd daemon 7definition 471starting and stopping 197
migdbcheck commandman page 316used to fix VOLDB 253
migdbdir commandman page 327
migdbrpt commandman page 328migration database report 250
migfind commandman page 333
migftscan commandman page 335remote volume report 250
miggetvol commandman page 339
miggroup commanddirectory level migration 20man page 341
migin commandman page 346reloading deleted files 258
miglicense commandman page 348
migloc commandman page 350
miglow commandman page 353overview 29
migmdclean commandman page 354
migmerge.sh script 34migmove command
creating work lists 34man page 358
mignbexport commandman page 363
mignbimport commandman page 367
mignbscan commandman page 371
mignewlog command 248man page 375
mignospace commandman page 377
migopscan command
Index 485
optical volume report 250migpolicy
example script 42migpolicy command
man page 380migpolicy script
creating work lists 12customizing 227modifying 65template 42
migpolicy.scriptchanging 42
migpurge commandman page 382overview 30
Migratedefinition 471see also Migration
migrate (.migrate) filefile system sweeps 25rules for creating 218, 219
migrate commandman page 383overview 30
Migrate filesee also Migratesee also Migration
Migrate file, globalfile system sweeps 25location 41migration control 218
Migrated filesexporting
definition 468Migration
automaticoverview 22
best times for 53control, global 218database report 250directory level 20example schedule 54File Browser and 172file selection
configuring 133
criteria 76overview 73procedure for planning 76
frequency 54management overview 22minimum file age
planning 74minimum file size 23
planning 74overview 9performance 229planning 45policies
testing with File System Analyzer 187
restarting 259scheduling 53, 222see also Migration leveltape 229thresholds
overview 70planning procedure 56
time to complete 48, 54with migbatch command 24with miglow command 29with migrate command 30
Migration candidatedefinition 471
Migration levelsdefinition 470see also Migration
migrc commandman page 386restarting migrations with 259
migrd commandman page 388
migrd daemondefinition 471starting 89starting and stopping 197
migrd.logcreating 248
migreconstruct commandman page 389
migrecycle command
486 VERITAS Storage Migrator System Administrator’s Guide for UNIX
man page 392migreg command
man page 395migsa command 89migselect command
man page 400volume consolidation 208
migsetdb commandman page 402
migstage commandman page 408partial file caching 17
migstop (.migstop) filerules for creating 218, 219
migsweep.sitechanging 42description 242template 42
migsweepm.sitechanging 42description 243template 42
migtestbadness commandman page 410
migtie commandman page 415partial file caching 17
migtscan commandman page 419tape volume report 250
migungroup commandman page 341
migunmigrate commandman page 423
migvold daemondefinition 471overview 8starting and stopping 197
migVSMshutdown commandexplained 197man page 424VSM states 9
migVSMstartup command 192man page 425startup problems 195
VSM states 9, 193migVSMstate command
man page 427VSM states 9
migworker script 12, 34Minimum file age
for migrationdescription 23guideline for setting 76
Minimum file sizefor migration
description 23guideline for setting 76
mode bit field, fls command 5MOTAB, location 41Mount table, global 41Mounts
demand delay parameterdefinition 467
unmount delay parameter 475Move flags, configuring 150Move threshold
definition 475file
formula for 82site-specified 243weighting factors 82
Movingminimum file age
planning 82minimum file size
planning 82mt method
definition 472description 59overview 1
Multilevel migrationcaches 31copydb files 240definition 472file selection
criteria 81minimum file age
planning 82minimum file size
Index 487
planning 82overview 31, 33volume consolidation 32, 34work lists 240
Nnb method
defining NetBackup policy for 128definition 472description 61overview 2partial file caching 17
nb volumescleaning 203
NetBackupcaution for 190file backup with 190migrated files 191nb method 2policy
caution for 190defining 128
requirement for VSM 6retention, caution for 191schedule
defining 128servers 128slice value lost 191storage
nb method 61support of optical disk 461
Next-volume-set filesdescription 242location 39, 307
NFS (Network File System)mount point 3mounted file system
managing 46operations 197rules for using 3
NTplatform for VSM-Java 90
OObsolete data
backup retention period 191
cleaning nb volumes 203consolidating volumes 204FHDB flags field 233multilevel migration 32recycling volumes 213
Obsolete FHDB entriesbackup retention period 191consolidating volumes 204, 207, 208, 210for modified cached files 14multilevel migration
move flags 150Obsolete flag 122, 123, 124Offline storage 214
definition 472op method
definition 473description 59overview 1
operatorvolume set availability
planning 62Optical disk
notes on support 461op method 1, 59ow method 1, 59write once, read many (WORM) 59
Options treeScheduling tool 175
Oraclearchive redo log management 151
Oracle archive redo logsbackup and delete 157management 151, 152migrating files 157searching 156
Oracle databasessee Oracle archive redo logs
ow methoddefinition 473description 59overview 1
PPartial file caching
488 VERITAS Storage Migrator System Administrator’s Guide for UNIX
Configuring with VSM-Java 130definition 473disabling 19, 130ft method 17nb method 17overview 17purging files 20, 80total file caching trade-offs 68
Partial VSM restore, caution for 191Pathname length, requirements 74Performance
constant sweeping 31migrating small files 229migration to tape 229Reporting Tool 165trade-offs
accelerated file space availability 69constant sweeping 31, 230partial file caching 68
Planningdatabase directories 49global configuration 46migration requirements 45migration thresholds 70purge thresholds 80storage methods 57summary procedure 84
Policiesmigration
testing with File System Analyzer 187
Policysee NetBackup policy
Poolsvolume
media management 21multiple 63
VSM volume pool 119port_number parameter 123Power down
remote volume server 198Premigration
calling from VSM-Java 223, 225, 226definition 473
overview 24Primary copy
definition 473Primary level
definition 473Problem solving
automatic removal or migration failure 259clear FHDB locks 252create new log files 248fix FHDB 251fix FHSEQF 255fix VOLDB 253recover FHDB and VOLDB 255release tape requests 260reload deleted files 258reports 249restart migrations 259startup 195user file access 259volumes
insufficient 260Process id (pid)
migd 41migvold 42
Processes, killing VSM 252, 260Pseudodevice
definition 473Purge mark
configuring 132default values 71definition 474description 22planning guidelines 71
Purge thresholdsdefinition 474file
formula for 81site-specified 75, 242weighting factors 81
Purgesmigpurge command 30minimum file age
planning 81minimum file size
Index 489
planning 81partially cached files 20, 80problems with automated 259thresholds
overview 80with File Browser 172
Qquota parameter
configuring 130definition 474planning 67
RRead ahead
configuring 130explained 18
rebuild_ihand commandman page 429
Recovery operations 9, 195Recycling
volumes 208, 213definition 474
Redo LogsOracle
VSM managmement 151Remote migration
ft method 2Remote storage
ad method 60definition 474nb method 61
Remote volume serverdefinition 474description 2, 126shutdown 198
Reporting Tool 158data copied reports 164data retrieval (caching) reports 163data retrieval reports 163file and space usage 161lperformance reports 165main window 158managed file system reports 162menus 159performance reports 165
setting preferences 160starting 158
Reports, media and database 249Restart time window
Scheduling tool 175restore command
backing up standard file systems 190backing up VSM databases 190cautions 191
Restoresdefinition 474
Run daysScheduling tool 175
SScans
deletingFile System Analyzer 188
performingFile System Analyzer 182
Schedulesbacking up VSM databases 190component configuration
Scheduling tool 175configuration pane 176effective date 175for migrations 53, 222general options 175management tasks
using VSM-Java 173migrations 53, 222options tree list 175restart time window 175restarting tasks 177run days 175settings
Scheduling tool 177summary
Scheduling tool 178summary of configured tasks 178time window 175
Scheduling toolconfiguration pane 176general options 175
490 VERITAS Storage Migrator System Administrator’s Guide for UNIX
main window 173options tree list 175restart time window 175run days 175schedule component configuration 175schedule summary 178scheduling tool 177tasks
restarting 177time window 175
Scriptsmigmerge.sh 34shutdown 197startup 192
Secondary storagedefinition 474
Serversmanaged 2remote 2
Session id (sid)migd 41
Shutdownactivity states 196overview 193remote volume server 198scripts
for all platforms 197shutting down VSM
see also ShutdownSize weight
configuring 134overview 75, 81, 83
Slicesee File slice
Small file migrationSpace increment
accelerated file space availability 30, 69configuring 131used with mignospace command 28
Sparse filedefinition 475
startmigd command 89man page 430
Startupproblems 195scripts 192VSM
overview 9Startup scripts 192States
fixing the FHDB 251VSM activity 8
Stop fileglobal
location 41migration control 218
stopmigd commandman page 432
stopmigrd commandman page 434
Stopping VSMsee Shutdown
stopping VSM operationssee also Shutdown, VSM
Storage devicesinstallation 90
Storage methodsconfigure with VSM-JavaI 118criteria for selecting 64ct 466definition 475dk 467dt 467effect of media cost 64ft 468mt 472nb 472op 473overview, file migration 11overview, multilevel file migration 33ow 473planning overview 57reconfiguring 228
Stripesconcurrent recording 63definition 475description 58
Index 491
multiple 63, 64, 67sweep.restart file 25Sweeps
file systemconstant 31round-robin 25
Symbolic links 218, 219
TTape marks
frequency 229Tapes
ct, dt, and mt methods 59duplicating 215missing trailer labels 196not enough available 260performance 229random seek 1releasing requests 260supported tape methods 1
Tasksrestarting
Scheduling tool 177Templates
database files 42file-handle database file 42migconf file 42migconfg file 41migsweep.site 42migsweepm.site 42sample.migpolicy.script 42volume database file 42
Thresholdfile
examples 77, 78formula for 74selections 134site-specified 84, 242weighting factors 74
Thresholdsdefinition 475
Time incrementaccelerated file space availability 30, 69configuring 131
used with mignospace command 28Time window
Scheduling tool 175Timestamp
nb method 203Tokens, DMAPI 197Toolbar
VSM-Java 95Total file caching
overview 16partial file caching trade-offs 68
Trailer labelstapes 196
UUNIX platforms
for VSM-Java 90Unmount
managed file systems 196unmount delay parameter 15, 121, 475User operations
overview 5
Vvault
volume set availabilityplanning 62
View menuVSM-Java 98
VOLDB 237caution for restoring 190, 254definition 476description 237fixing 253flags field
description 238multilevel migration 34
location 39lock file
description 242location 39
recovering 255removing entries 214template 42updating 12
Volume database
492 VERITAS Storage Migrator System Administrator’s Guide for UNIX
see VOLDBVolume label
for alternate disk 125for FTP 126for NetBackup 128for tape media 66, 125
Volume poolsdefinition 476multiple 63VSM 119
Volume set availability 62planning 62
Volume setsconcurrent recording 63definition 476description 58moving volumes between 214next set to use 242
Volumesallocation 21assignments 21consolidation
definition 466one step 208overview 204two step 210
damaged 214, 238definition 476destroyed 214empty
definition 467full 238lost 214management 201management of
overview 21Media Manager xxiiimonitoring usage 202mount points 42moving offline 214recycling 208unused 202
Volume-sequence filedescription 242location 39
VSM serverdefinition 476
VSM states 8fixing the FHDB 251
VSM-JavaAction menu 100Activity bar (bottom pane) 94advanced configuration wizard 113Bottom Pane 94configuration wizards 135Configure menu 100configure volume pools 119database tools 151definition 476Edit menu 97File menu 97file system properties 129Help menu 101hierarchies in 93Left Pane 93log files
creating log 248managing 247viewing 244, 245
login 91main screen 92manual configuration 145menus 97overview 89PC platforms 90premigrate and copy files 223, 225, 226reconfiguration 147restarting migrations with 259Right Pane 93setting states 9starting daemons 198starting interface 89, 193starting migrd daemon 89stopping Daemons 198toolbar 95tools
backup and delete 157for migrating files 172for Oracle archive redo logs 153
Index 493
for purging files 172migrating database archive redo logs 157migrating grouped files 171searching databases 156see also File Browser, File System Analyzer, Reporting Tool, Scheduling Tool, Managing Oracle Archive Redo Log Tool
UNIX platforms supported 90View menu 98volume recycling 215volume registration 124
WWeight operator
configuration with VSM-Java 134
move thresholdoverview 83
purge thresholdoverview 81
threshold formulaoverview 75
Windowsplatforms for VSM-Java 90
Work directorylocation 38
Work listsdescription 240multilevel migration 34overview 12
Write Once, Read Many (WORM) 59definition 476
494 VERITAS Storage Migrator System Administrator’s Guide for UNIX