VERITAS Storage Migrator™ 4.

System Administrator’s Guide

for UNIX

March 2002
30-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.

Organization
Read 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.

Accessibility
VSM 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
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.”

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.

Preface xxiii
Getting Help

Key Combinations and Pulldown Menus

Some 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 Usage
The 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:
[email protected]

xxiv VERITAS Storage Migrator System Administrator’s Guide for UNIX

About VSM 1
VERITAS 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
volume
server
Remote
volumes

(ft, ad,
and nb
methods)
Local optical
Managed (op and ow methods) volumes
file system

(ct, dt, and mt Local tape

VSM server methods) volumes

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 Controls
As 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 Controls
You 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 VSM

Even 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 Architecture
The 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

Administrative Media
tools Manager

migd

migin
DMAPI
interface

Secondary VxFS, XFS, or

Disk
Storage OnlineJFS File System

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.

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 Features

Basic 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 States

A 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 Migration
During 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

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

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.

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 filec
Handle: 2C70C0M5BC9 20000 1/1 Mon Dec 17 19:48:23 2001
Medium: 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 Caching
Caching 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

Cache Request -- as the result of a system call, such as read()

No
File is not cached. When it cannot cache a file, VSM
Is migd active?
returns errno EPFNOSUPPORT to the
user system call, which the user will
know only if the application reports
the errno. In some cases, the
Yes process will fail silently.

Is VSM No
state Active? File is not cached.
(see page 8)

Yes

No
Is partial
Entire
caching
file is cached
enabled?

Yes

Cache part
of file

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).

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 Slices
It 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 Caching

A 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

Configured slice
Neither read request
data accessed by lies entirely within the
read requests configured slice that
resides on disk.
The file is cached in its
entirety.

Cached data

Migrated File

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 Caching

Partial 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.

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

Configured slice Neither read request

Data accessed lies entirely within the
Cached

by read requests configured slice that

data

resides on disk

File is partially cached to a point

Read-ahead
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)
Migrated file

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

Effective slice

Data accessed Neither read request lies

Cached by read requests entirely within the effective
data slice that resides on disk

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
Migrated resides on disk
File
Uncached portion of the migrated file
(that does not reside on disk)

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.

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 Migration
While 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

VSM

Managed file Mount request

system VSM for volume
volume
information
Volume Media
Database
database Manager

Robotic storage Mount request

device for volume

Operator

Manual storage
device

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

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 Parameters
The 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

Open space
VSM migd daemon detects that the
percentage of file system space open for
Free space use in the managed file system is below the
value free space value.

Open file
system space If purge candidates exist, VSM removes them
Free space to the purge mark percentage and stops.
value
If no purge candidates exist, VSM sweeps the
Purge mark
file system, selects enough files to increase
open file system space to the low-water mark
Low-water
percentage, migrates the files, and finally
mark
purges files to the purge mark percentage.

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.

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 Commands
VSM 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 migd detects

migration or that free space
command is below the
execution free space
value

Start migbatch (Calls migarch.sh and

then migworker)

Scan file system for files that meet migsweep

selection criteria

Select files and assign file handle migout

migarch.sh

Update IHAND file, file handle, and file migout

name databases

Create work list in workdir migpolicy

Copy files in work list to migcopy

secondary storage

migworker
Update databases to show location
of file data migmerge.sh

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

Administrator migd detects that file

executes the system space open for
mignospace use is less than free
miglow command
executes command space value

If file system open mignospace

space is low, miglow
runs migbatch, then
mignospace

Is VSM state
No Active or
Exit Maintenance?

Yes

Do purge
Yes
candidates
exist?

No

Cut threshold in half

Remove purge
Has purge candidates,
Select and Yes increasing free
mark been
migrate enough space to the purge
exceeded?
files to bring free mark, then exit
space to the
low-water mark
No

Cut threshold in
half, 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

miglow executes

Checks open file system space

Is
free space
less than its Exit. Enough
configured space is available
No
value?

Yes

Run migbatch to select and migrate enough files to allow mignospace to bring open file
system space to purge mark

Run mignospace to remove purge candidates, increasing open space to the purge mark

Chapter 1, About VSM 29

Basic Migration Operations and Features

User Migration Commands

If 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 Availability

Accelerated 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 Sweeps
You 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

Level Level
7 8 Tier 4

Level 7 Level 8

Level Move Level Move

5 Primary 6 Alternate Tier 3
Copy Copy

Level 5 Level 6

Move Level Move Level

Primary 3 Alternate 4 Tier 2
Files cache Copy
Copy
directly from
any level Level 3 Level 4

Level Move Level Move

1 Primary 2 Alternate Tier 1
Copy Copy

File
System Migrate Primary Primary Alternate
copy copy copy
Migrate Alternate
copy

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.

32 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 Basic Migration Operations and Features

File Movement
The 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

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

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.

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/Import
The 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 Directories

It 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 Structure

The 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

fspath file system

configured name of the mount point
hsmname
managed file system

Managed files migration

data

Databases, Work Files, Logs, and Binaries

The 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

/usr

/openv /var

/java /hsm (See “Global

Configuration File
migsa, migfb Structure” on
various NetBackup files page 41)

bin database logs

goodies admincmd hsmname (See “Log files”

on page 40)
scripts commands workdir database
tools scripts
tools See “Files See “Files
migd in dwpath” in dwpath”
commands migvold on page 38 on page 38
scripts migrd
tools

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 Structure

Global configuration information resides in the /usr/var/openv/hsm directory, as
shown in the following figure.

Global Configuration File Structure

/usr/var/openv/hsm

workdir

database example
Template files:
migd.pid database
VSM files: migvold.pid
migconfg MOTAB Template files:
Template files: volume mount points FHDB
migconfg_example migd.sid FNDB
HsmLogLevel FHSEQF
migrd.pid VOLDB
VOLSEQF
migsweep.site
migsweepm.site
sample.migpolicy.script
migconf
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

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:
FHDB
FNDB
FHSEQF
VOLDB
VOLSEQF
migsweep.site
migsweepm.site
migconf
sample.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 Directories

The 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

ftvpath
ID_LABEL

1LXXX
CMIG.pid
2LYYY MIG.pid
data_file
data_file.GLABEL

The ftvpath directory is the path to the file system containing the ft volume. This file
system contains the following types of files:

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 Configuration

The 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 Configuration

VSM 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 Configuration

All 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 Configuration

VSM 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 Caches

When 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 Configuration

VSM 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 Collection

VSM-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 Plan

The 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 Configuration

After 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 Testing

If 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 Files

Your 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 Pool
A 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 Recording

A 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

FileA Primary Level: 1 Primary copy Tape 3 Stripe

FileB Primary Level: 1 Primary copy Tape 1 Stripe

Alt
Al t

ern
ern

a
ate

te
Le
Le

ve
el:v

2l:
2

Alternate copy Tape 3 Stripe

Alternate copy
Tape 1 Stripe

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 Method

The 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

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.

Storage Method Possibilities

File System Average File Size Storage Method

/hsm1 and 18 MB Primary Level = Optical Disk Stripe

/hsm2 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

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.

Chapter 2, Planning VSM Configuration 65

Volume Properties

Volume Properties
You 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 Properties

The 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 Size
You 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 Files

Users 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-offs

Like 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 Availability

Accelerated 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 Migrated

You 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 Purged

The 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

4:00 AM
Free space
Free space value 10% 11% of disk space is open
Purge mark 15% Premigrated
files Scheduled migbatch command runs
and premigrates files to the low-water
Low-water mark 20%
mark of 20% free space

4:00 AM to 2:00 PM
Free space
Free space value 10% Premigrated More file are created
files
Purge mark 15% Disk space usage increases

Low-water mark 20% Free space decreases to 8%

2:00 PM
The mignospace command purges files
Free space value 10% Free space premigrated at 4:00 AM until free space is
at the purge mark
Purge mark 15%
Premigrated files remain on disk that use
Low-water mark 20% 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.

2:00 PM to 4:00 AM

Free space More new files are created

Free space value 10%
Purge mark 15% Disk space usage increases, but not
above the 10% free space configured
Low-water mark 20% before migbatch is scheduled to run its
daily migration.

This pattern indicates that purge marks

and low-water marks are set correctly.

72 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 Criteria for Selecting Files to Migrate

Desired Percentage of Free Space

The 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 Migrate

The 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

Files not migrated, regardless of size, because

Files greater than min_age,

they are under min_age

min_size, and threshold that can

be migrated
File Size

Files with a
calculated threshold less
than the configured threshold_formula
Files not migrated, regardless of age, because
they are under min_size

File Age

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.

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)

30

25

20 Files below minimum age for migration Files greater than min_age and
min_size that can be migrated

15
File Size (in kilobytes)

10

5
threshold=3

0 Files below minimum size for migration

0 5 10 15 20 25 30
min_age=1 File Age (in days)

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

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)

.

300

250 Files greater than min_age and

min_size that can be migrated
Files below minimum age for migration

when threshold=90
200

150
File Size (kilobytes)

100

50

Files below minimum size for migration

0
0 50 100 150 200 250 300
File Age (days)
min_age=3

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.

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)

30

25 Files greater than min_age and

min_size that can be migrated
when threshold=90 (and also when
Files below minimum age for

20 threshold=45)

15
File Size (in kilobytes)

A
10 mi dditio
gra n
ted al fil
wh es t
en hat
thr c
5 es an b t1
ho
ld= e
45
t2
0
0 5 10 15 20 25 30
min_age=3 File Age (in days)

Criteria for Purging Files

After 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:

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

Start file selection process

Is a Are
site-defined move criteria
Use default
move threshold No for migration No
move threshold
formula levels
formula
defined? specified in
migconf?

Yes Yes

Use site-defined Use move threshold

move threshold formula specified for
formula the migration level

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.

Chapter 2, Planning VSM Configuration 83

Customizing Migration, Purging, and Moving Criteria

Customizing Migration, Purging, and Moving Criteria

You 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 Procedure

The 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

Hierarchy Properties:
Managed File System Name (hsmname) _________________________
Dual Copies: _____
Level Properties
Stripe Properties
Storage Method: _____
Volume Pool Name: _____
Tape or Optical Alternate Disk NetBackup
Media Density: _____ Media Capacity: _____ Deadman timeout: _____
Media Capacity (tape): _____ Granule size: _____
Block size (tapes only):_____ Remote FTP
Granule size: _____ FTP port number: _____
Deadman timeout: _____ Deadman timeout: _____
Volume Properties
All methods Alternate Disk NetBackup
Volume label: ______________ Volume directory: ______________ Server: ______________
Force registration: _____ Remote FTP Policy: ______________
Add to current stripe:_____ Server: ______________ Schedule: ______________
Username: ______________
Password: ______________
File System Properties
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: _____%
Migration Criteria Purge Criteria Move Criteria
Min. age to migrate (days): _____ Min. age to purge (days): _____ Min. age to move (days): _____
Min. size to migrate (KB): _____ Min. size to purge (KB): _____ Min. size to move (KB): _____
Migrate files with threshold >: ____ Purge files with threshold >: ____ Move files with threshold >: ___
Age weight: _____ Age weight: _____ Age weight: _____
Size weight: _____ Size weight: _____ Size weight: _____
Weight operator: _____ Weight operator: _____ Weight operator: _____

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 Interface

Each 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 Screen
To 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 Dialog
The 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

Menu Bar
Toolbar

Right Pane

Left Pane

Bottom Pane

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

92 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 Administration Dialog

Left Pane
The 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 Pane
When 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 Pane
The 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 Toolbar
The 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 Icon

Click the Change Server icon to invoke the tool that logs out from this server
and logs in to another server.

Basic Configure Wizard Icon

Click the Basic Configuration Wizard icon to activate the Basic Configuration
Wizard.

Chapter 3, VSM-Java Overview 95

Administration Toolbar

Advanced Configure Wizard Icon

Click the Advanced Configuration Wizard icon to activate the Advanced
Configuration Wizard.

Database Configuration Wizard Icon

Click the Database Configuration Wizard icon to activate the Database
Configuration Wizard and add VSM management to Oracle archived redo logs.

New Icon
When 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 Icon
Click 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 Icon

Click 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 Icon

Click 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 Icon

Click the File System Analyzer icon to open the File System Analyzer interface.

Refresh Icon
Click 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 Bar

The 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 Menu
Use 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 Menu
Use 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

Server Selection Hierarchy Selections Managed Filesystem Selections

Non-managed Level Selections Stripe Selections

Filesystem Selection

View Menu
Use 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.

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 Menu
The 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 Menu
Use 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 Wizard

The 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 Dialog

Select 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 Dialog

Provide 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 Dialog

Select 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 Dialogs

Use 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 Dialog

The 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 Wizard

The 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 Dialog

The 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 Dialog

Enter 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 Dialog

Create 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 Dialog

The 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 Dialog

Select 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 Dialogs

Use 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 Dialogs

Use 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 Dialogs

If 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 Dialog

After 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 Changes

In 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 Wizard

The 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 Dialog

Define 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 Dialog

Select 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 Dialogs

Use 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 Dialog

The 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 Configuration

This section describes how to add to or make changes in VSM configuration.

Adding to Configured Systems

configure 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 Configurations

Use 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 Logs

Most 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 Overview

Before 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 Dialog

To 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 Dialog

This 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 Tools
This 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 Tool

Before 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 Window

The 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

Menu Bar

Left Pane

Right Pane

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 Menus

The 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.

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 Reports
Response 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 Reports
Copied 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 Browser

This 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 Login

To 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 Window

The 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

Menu bar Tool bar

Left Pane

Bottom Pane (Activity Table) Right Pane

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

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 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.

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.

170 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 File Manipulation with the File Browser

File Browser Actions

Use 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 Tool
You 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 Dialog

The 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 Settings

By 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 Summary

You 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 Analyzer

The 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 Window

The File System Analyzer main screen layout contains four functional elements, as shown
in the following figure.

File System Analyzer Main Screen

Menu bar Tool bar

Selection Pane Graph Display Pane

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.

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 Bar

The 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 Systems

The 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 Databases

Always 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 VSM
The 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:

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

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

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 Startup
You 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 VSM

VSM 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 Daemons

VSM 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 Utilities
The following sections describe VSM management utilities.

Administering Inode-to-Handle (IHAND) Files

VSM 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 removing
04 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 1440
05/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/vfstab
Update 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 File

The 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 Files
You 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 Tasks

Use 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 Volumes
Volume 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

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.

VOLn label
BOT VOLn Label EOV Media

VOLn label VOLDB entry

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.

BOT VOLn label file A file B file C EOV Media

active active active FHDB entries

FNDB entries
VOLn label VOLDB entry

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.

BOT VOLn label file A file B file C EOV Media

obsolete active obsolete FHDB entry

VOLn label VOLDB entry

Note If you are consolidating to a write-once-read-many (WORM) tape, consolidation

will create multiple EOV labels on the tape.

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

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.

BOT VOL1 label file 1A file 1B file 1C EOV Media

dead active dead FHDB entry

VOL1 label VOLDB entry

migcons copies file 1B from VOL1 to VOL2 and then makes file 1B obsolete on VOL1.

BOT VOL1 label file 1A file 1B file 1C EOV Media

BOT VOL2 label file 2A file 2B file 1B EOV Media

active active active FHDB entry

VOL2 label VOLDB entry

migcons removes all FHDB and VOLDB entries for VOL1.

BOT VOL1 label file 1A file 1B file 1C EOV Media

FHDB entry

VOLDB entry

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.

BOT VOLn label EOV Media

VOLn label VOLDB entry

Note If you are consolidating to a write-once-read-many (WORM) tape, consolidation

will create multiple EOV labels on the tape.

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

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.

BOT VOL1 label file 1A file 1B file 1C EOV Media

dead active dead FHDB entries

VOL1 label VOLDB entry

migcons copies file 1B from VOL1 to the ad volume.

BOT VOL1 label file 1A file 1B file 1C EOV Media

ad Volume file

migcons mounts the output volume using

Media Manager and copies file 1B to VOL2

BOT VOL2 label file 2A file 2B file 1B EOV Media

active active active FHDB entries

VOL2 label VOLDB entry

migcons removes FHDB and VOLDB entries for VOL1.

BOT VOL1 label file 1A file 1B file 1C EOV Media

FHDB entries

VOLDB entry

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 VOLn label EOV Media

VOLn label VOLDB entry

Note If you are consolidating to a write-once-read-many (WORM) tape, consolidation

will create multiple EOV labels on the tape.

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 Set

If 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 Volumes
If 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 Files

If 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 Migration
This section describes migration management tasks.

Controlling Global Migration

In 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

/beta

kali

.migstop .migrate
files in /beta/kali/.migstop: files in /beta/kali/.migrate:
/beta/kali/nomig1 /beta/kali/yesmigrate1
/beta/kali/nomig2 /beta/kali/yesmigrate2
/beta/kali/*proj*/nomig* /beta/kali/*proj*/yesmigrat*

kali_proj1

yesmig1 yesmig2 nomigrate1 nomigrate2 nomig8 nomig1

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

220 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 Managing Migration

Initial Set of Migrating Candidates in Control File Example

File Name Migratable? Rationale

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

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:

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

Chapter 6, Managing VSM 221

Managing Migration

Migration Candidates in Control File Example when Local .migstop Exists

File Name Migratable? Rationale

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

Scheduling Migrations
VSM 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 Commands

Most 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.

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 Methods

You 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 Marks

By 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 Sweeps

You 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 Exports

There 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 Imports

Files 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

FHDB Entry Description

Entry field Example value Description

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).

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|

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 Description

value

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

VOLDB Entry Description

Entry field Example Description

value

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.

238 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 Managing VSM Databases

VOLDB Entry Description

Entry field Example Description

value

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 fields
when it registers a NetBackup policy as a volume for
the nb method. The location field holds policy_name,
the server_user filed holds schedule, and the
server_password field holds client_name.

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,@tin
y/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

Work List (copydb) Entry Description

Entry field Example value Description

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 %000000000080009400 Path name associated with the file. Possible formats
0000570000000000000 follow:
00000000002000001ff - % indicates that a DMAPI handle follows
00000034,@tiny/kcm/
d3/f.c
- @ 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.

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.

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 Problems
This section discusses actions you can take to solve problems with VSM operations at
your site.

Viewing Log Files

The 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 Logs
VSM 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 States

If 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 Reports

You 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 Problems
Like 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 Systems

You 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 Problems

The 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|000
28000|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:
# gethsm
alpha 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/filename
alpha
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 /usr
ERROR: 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/file1
Error: hsmname is inactive.

FILES
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)

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/file94
Current IHAND entry for file94:
HANDLE MACHID FLAGS SLICE HIGHEST
13D2 2C70C0 10 0 0
DMHANDLE-LENGTH DMHANDLE
20 00000000400000090000000842042dc
00000000000000180000016963000001
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/file94
Current IHAND entry for magic:
HANDLE MACHID FLAGS SLICE HIGHEST
13D2 2C70C0 10 0 0
DMHANDLE-LENGTH DMHANDLE
20 00000000400000090000000842042dc
00000000000000180000016963000001
Modified IHAND entry for file:
HANDLE MACHID FLAGS SLICE HIGHEST
13D2 3E8 10 0 0
DMHANDLE-LENGTH DMHANDLE
20 00000000400000090000000842042dc
00000000000000180000016963000001

Do you want the IHAND entry reset? [yn] y

IHAND 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 13D2
Current IHAND entry for iota inode 13:
HANDLE MACHID FLAGS SLICE HIGHEST
0 0 10 0 0
DMHANDLE-LENGTH DMHANDLE
0
Modified IHAND entry for iota inode 13:
HANDLE MACHID FLAGS SLICE HIGHEST
0 0 0 0 0
DMHANDLE-LENGTH DMHANDLE
0
Do you want the IHAND entry reset? [yn] y
IHAND 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 loglevel
Sets 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 xi
starting migactivate xi
INFO: activated FHDB entry 3E8M13A0 inode = 107

Appendix A, Man Pages 273

migactivate(1M)

INFO: activated FHDB entry 3E8M13A1 inode = 108

INFO: activated FHDB entry 3E8M13A2 inode = 109
...
INFO: activated FHDB entry 3E8M1402 inode = 205
INFO: activated FHDB entry 3E8M1403 inode = 206
migactivate 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 AD0001
VOLUME AD0001 registered to HSM
Volume Particulars
------------------
000E7C00V00001003 AD0001 ad 00050000 00006288 #16
Volume Label Found ====> AD0001-------------------------------
E7C00M8D.2.0 <=> 00826C00 00200000 Wed Jan 9 17:48:55 2002 /Xa/sv/h1
E7C00M8D.1.0 <=> 00826C00 00000000 Wed Jan 9 17:48:55 2002 /Xa/sv/hx
E7C00M8D.5.0 <=> 00826C00 00800000 Wed Jan 9 17:48:55 2002 /Xa/sv/hs
E7C00M8D.4.0 <=> 00826C00 00600000 Wed Jan 9 17:48:55 2002 /Xa/sv/ha
E7C00M8D.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 regions
MIGRATED sets WRITE, TRUNCATE
PURGED sets READ, WRITE, TRUNCATE
CACHED sets WRITE, TRUNCATE
NOREGION, 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 errors
01/12 14:36:25 [12]migmkspace[113]: ERROR No entries
in FHDB for filehandle 1000
01/12 14:36:25 [12]migmkspace[113]: ERROR No entries
in FHDB for filehandle 107C
01/12 14:40:13 [22]migcopy[413]: ERROR choose_src_gran
no gran for as_filep=x0
01/12 14:40:13 [22]migcopy[413]: ERROR read_data: no
good source granules found
01/12 14:40:13 [22]migcopy[143]: ERROR copy_file()
/copy_gran fail
01/12 14:40:13 [22]migcopy[143]: ERROR ** FAILED TO
COPY: X107C
01/12 14:40:13 [22]migcopy[143]: ERROR ** copy_for_
method() ret=1
01/12 14:41:43 [25]migcopy[149]: ERROR choose_src_gran
no gran for as_filep=x0
01/12 14:41:43 [25]migcopy[149]: ERROR read_data: no
good source granules found
01/12 14:41:43 [25]migcopy[149]: ERROR copy_file()
/copy_gran fail
01/12 14:41:43 [25]migcopy[149]: ERROR ** FAILED
TO COPY: X107C
01/12 14:41:43 [25]migcopy[149]: ERROR ** copy_for_
method() ret=1
01/12 14:42:42 [12]migmkspace[166]: ERROR No entries
in FHDB for filehandle 1000
01/12 14:46:17 [12]migmkspace[202]: ERROR No entries
in FHDB for filehandle 1000
01/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 37100
Responding to events for sid 37100, tokens:
227
Destroying session 37100: OVT.25719.tar-create
To list the remaining sessions, execute migcleanup again:
# migcleanup
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 all sessions initiated by VSM for which the creating process
no longer exists:
# migcleanup -k
Destroying session 37098: OVT.25714.tar-create
Destroying session 37097: OVT.25713.tar-create
Destroying 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_delay
Time 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.
checksum
If 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_OBSOLETE
Media 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_APPEND
Applies 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_EOT
Applies 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_size
VSM 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_size
Block 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_timeout
The 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_number
ftp port number and used only for the ft method.
demand_delay
The 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_badness
The 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_weight
Weighting to be used for age in the move threshold formula. The
default is 1.
move_size_weight
Weighting to be used for size in the move threshold formula. The
default is 1.
move_weight_operator
The 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_flags
Mark 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.
METHOD
name=dk,
access=0,
capacity=50M,
speed=1M,
gran_size=1M,
block_size=64K

Appendix A, Man Pages 297

migconf(1M)

◆ Tape (ct)
METHOD
name=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)
METHOD
name=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)
METHOD
name=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)
METHOD
name=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)

METHOD
name=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)
METHOD
name=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)
METHOD
name=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)
METHOD
name=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_badness
The 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_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_size
Size 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_weight
Weighting to be used for age in the move threshold formula. The
default is 1.
move_size_weight
Weighting to be used for size in the move threshold formula. The
default is 1.
move_weight_operator
The 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_flags
Mark 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.
freespace
Specifies 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.
lowwater
The 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.
purgemark
The 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_size
Size 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_weight
Weighting to be used for age in the threshold formula. The default is 1.
size_weight
Weighting to be used for size in the threshold formula. The default is 1.
weight_operator
The 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.
readahead
Minimum 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_badness
The 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_age
Age 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_size
Size 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_weight
Weighting to be used for age in the purge_badness formula. The
default is 1.
purge_size_weight
Weighting to be used for size in the purge_badness formula. The
default is 0.
purge_weight_operator
The 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_time
Pause 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

FILES
dwpath/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 file
dwpath/database/FNDB.OLD.hsmname.pid.
-h Print help information about this command.
-c number_of_copies
Used 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/f0
Status: Cached code raa /alpha/usr1/7/6/4/4/1/1/2/f0
No 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 delta
00001000|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 delta
0998|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 backupdir
Specifies 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 status
7 - Mount point
8 - 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 5
33554455
The following example prints whether or not the theta file system is mounted correctly.
In this case, it is not mounted correctly.
# migdbdir theta 6
not 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_path
Reports on the file with the specified file path. The file path must be
specified with the full path.
-h file_handle
Reports 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_set
Reports 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_handle
Reports 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_HAND
File handle for the file, followed by an asterisk (*) if locked.
VOL_HAND
Handle 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_SIZE
Size 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_PATH
File 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_handle
The VSM file handle of the file. File handles are stored in the file handle
database (FHDB) for the file system.
-d DMAPI_handle
The DMAPI file handle of the file.
-m 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.
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 beta
No 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_name
Name 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_path
Path 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 HSM
Volume 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 <=> 0000
1036 00000000 Thu Apr 26 13:09:41 2001 /sd7/ov2fs/f1.c

/usr/home/acg/ft_stor1/3E8M1235.1.0.GLABEL <=> 0007

60000 0000000 Thu Apr 26 13:09:42 2001 /sd7/ov2fs/f1.x

/usr/home/acg/ft_stor1/3E8M1239.1.0.GLABEL <=> 00000

F3B 00000000 Thu Apr 26 13:09:44 2001 /sd7/ov2fs/f2.sh

/usr/home/acg/ft_stor1/3E8M123D.1.0.GLABEL <=> 000018

8E 00000000 Thu Apr 26 13:09:45 2001 /sd7/ov2fs/f3.rcs

/usr/home/acg/ft_stor1/3E8M1241.1.0.GLABEL <=> 0000

565C 00000000 Thu Apr 26 13:09:47 2001 /sd7/ov2fs/f4.o

/usr/home/acg/ft_stor1/3E8M1245.1.0.GLABEL <=> 0000

1036 00000000 Thu Apr 26 13:09:48 2001 /sd7/ov2fs/f5.c
...
/usr/home/acg/ft_stor1/3E8M1276.1.0.GLABEL <=> 0000
2000 00000000 Thu Apr 26 13:10:07 2001 /sd7/ov2fs/k8f8

/usr/home/acg/ft_stor1/3E8M127A.1.0.GLABEL <=> 0000

1000 00000000 Thu Apr 26 13:10:08 2001 /sd7/ov2fs/kef4

/usr/home/acg/ft_stor1/3E8M1283.1.0.GLABEL <=> 000045

92 00000000 Thu Apr 26 13:10:12 2001 /sd7/ov2fs/nrof.3

/usr/home/acg/ft_stor1/3E8M1287.1.0.GLABEL <=> 0000

2000 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:
label
method
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 hsm1
LABEL 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/project123
Regular 3 files 0.046080 MB
Grouped 9 files 0.101412 MB
Not 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 project123
Regular 3 files 0.046080 MB
Grouped 9 files 0.101412 MB
Not 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/project123
Regular 3 files 0.046080 MB
Grouped 9 files 0.101412 MB
Not 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_system
Path 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_handle
File 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_name
Host name of the machine on which the file resides.
owner Owner of the file.
file_pathname
Pathname of the file.
Handle fields are as follows:
mach_idMhandle
Machine ID and file handle, in hexadecimal, separated by M.
file_size File size in bytes.
gran_count
Total number of active granules of this file on all media.
date_of_migration
Date 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_count
Number 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_location
Path 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 tproga

Handle: 3E8M10E0 133 49 Mon Jan 28 12:48:36 2002
Medium: DK0000 dk.0 0 1 3e8M10e0 /sd7/ov2fs/migration/data
Medium: 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 acg1

Handle: 3E8M140A 6 2 Wed Apr 11 08:09:52 2001
Medium: DK0000 dk.0 0 1 3e8M140A /sdisk3/migration/data
Medium: FT0001 ft.1 1 1 3e8M140A.1.0 star:/sdisk4/ft_storage

SEE ALSO
fls(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_system
Full 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.volset
Selects 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 | 2
For -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 miglevel
Move 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 miglevel
Move 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 methname
Scan 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_system
The 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 policy
NetBackup 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 timeout
A 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.225
The 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_master
Name of the master NetBackup server for nb volumes. NB_master must
be the first name the server is known by to NetBackup.
policy_name
Name 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 1
Volume 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 1

Warning 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 0
Volume label Found ====> NB003 duo hsmnb2
-------------------------------
Obtaining list of granules.
Restoring granule header files
No 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 $status
4
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 $status
3
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_file
If 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_system
Full 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)

FILES
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), 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_file
Lists 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.

FILES
dwpath/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 capacity
Capacity 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

FILES
dwpath/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_number
The 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_name
The 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_point
The 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_name
Name 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_directory
Absolute 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_name
The name of the NetBackup policy.
NB_master
Name 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 AB001B
Tape 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 NB001
Capacity set to unlimited.
Registered vh_label=NB001 [at hsmnb] as vh_handle=104A
and method= nb

FILES
dwpath/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_set
The 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 ad
RAO001.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/VOLDB
Volume database for VSM.
/usr/var/openv/hsm/database/migconfg
Global 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=08
03/11 14:35:50 [15]migsetdb[2810]: fh=3E8ME1036 level=5: flags=08
03/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:km
Reenter the password for label: FT001 user:km
Enter the password for label: FT002 user:km
Reenter 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_formula
All 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 = multiply
1 = add
2 = site selected
If 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_reduce
The 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 messages
2 = don’t print headers
number_of_files
The 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 4000
age + size = badness pathname
--- ---- ------- --------
1.10 1025 1026 /sigma_6/test1/retrieve_file.1.6713
1.11 1025 1026 /sigma_6/test1/retrieve_file.1.7813
9.04 10 19 /sigma_6/test1/1
9.04 10 19 /sigma_6/test1/2
2.10 100 102 /sigma_6/test1/filler.93.7813
2.10 100 102 /sigma_6/test1/filler.94.7813
2.10 100 102 /sigma_6/test1/filler.95.7813
2.10 100 102 /sigma_6/test1/filler.96.7813
2.10 100 102 /sigma_6/test1/filler.97.7813
1.11 1025 1026 /sigma_6/test1/retrieve_file.1.9805
2.10 100 102 /sigma_6/test1/filler.15.9805
2.10 100 102 /sigma_6/test1/filler.16.9805
2.10 100 102 /sigma_6/test1/filler.17.9805
2.10 100 102 /sigma_6/test1/filler.18.9805
2.10 100 102 /sigma_6/test1/filler.19.9805
2.10 10 12 /sigma_6/test1/filler.20.9805
2.10 10 12 /sigma_6/test1/filler.21.9805
2.10 10 12 /sigma_6/test1/filler.22.9805
2.10 10 12 /sigma_6/test1/filler.23.9805
2.10 10 12 /sigma_6/test1/filler.24.9805
2.10 100 102 /sigma_6/test1/filler.9.10960
selected: 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 400
age + size = badness pathname
--- ---- ------- --------
2.10 100 102 /sigma_6/test1/filler.93.7813
2.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.7813

2.10 100 102 /sigma_6/test1/filler.96.7813
2.10 100 102 /sigma_6/test1/filler.97.7813
selected: 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.
groupname
Identifies 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_project
quarterly_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_name
This 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_label
Tape 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/ed
000003E8M00001343 V00001098 mt 00005B8C 00000000 00005B8C
#2 1 #2 1 /home/ckb/an
INFO: 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 hex
Offset in hex of the granule in the file
Granule size in hex
Recorded filemark number after which the granule resides
Recorded offset from the file mark to the granule
Computed filemark number after which the granule resides
Computed offset from the file mark to the granule
File 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 ALSO
fls(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 inactive
Changes 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 -c
Places 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:
# startmigd
INFO: 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:
# stopmigd
INFO: 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.

Components and Resources for Enterprise Agent for Storage Migrator

Agent Name Resource Name Resource Group

StorageMigrator theDaemons StorageMigratorGroup

StorageMigratorFS Hsm_X StorageMigratorFSGroup

The following table summarizes StorageMigrator Agent operations. The StorageMigrator

Agent has unique online, offline, monitor, and clean scripts:

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 The daemon is considered offline if one of the following applies:
Failure - 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:

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 The managed file system is considered offline if it is mounted and
Failure no entry for it appears in the migconfg file.

* An example resource.vsm.agent.state file name is

vsmfs_hsm2.vsm.agent.state.

Limitations
The 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.

Installation
Before 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.

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-Installation
You 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 Configuration
To 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 Files
Before 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 Configuration
Configure 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 Utility

Enterprise 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 Configuration
Before 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

PUBLIC NETWORK

NODE PRIVATE NETWORK NODE

trixie pixie

/hsm1

/hsm2

FTP SERVER

/db1 cranberry

/db2

/log1

/log2

HP DLT
LIBRARY

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

StorageMigratorFSGroup1

StorageMigratorFS
hsm1

StorageMigratorGroup
Mount db1
Mount log1 StorageMIgrator theDaemons

StorageMigratorFSGroup2

StorageMigratorFS
hsm2

Mount db2
Mount log2

StorageMigratorFSGroup1 and StorageMigratorFSGroup2 require StorageMigratorGroup.

.
StorageMigratorFSGroup1 and StorageMigratorFSGroup2 are independent of each other.
NBUGroup is not used in this configuration.

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.

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

StorageMigratorFSGroup

StorageMigratorFS
hsm1
StorageMigratorGroup

Mount /mnt1 StorageMigrator

theDaemons

NBUGroup

StorageMigratorFSGroup requires StorageMigratorGroup, which requires NBUGroup.

▼ 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
)

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 Entries

The 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 LogLevel
str dv
static str ArgList[] = { dv }
NameRule = ""
)

type StorageMigratorFS (
static str LogLevel
static str ArgList[] = { HsmName, MountPoint, BlockDevice,
DatabasePath, LogFilePath }
NameRule = ""
str MountPoint
str BlockDevice
str DatabasePath
str LogFilePath
str HsmName

Maintaining Your System

You 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 Migrator

The 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 Help
If 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 Sector Capacity Type Notes about NetBackup Support

Size

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

Supported Optical Media

Platform Model Sector Capacity Type Notes about NetBackup Support

Size

HP-UX HP C7985A 2048 8.6GB WriteMany Media Manager can mount this media. VSM
(continued) 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

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
A definition 465
Accelerated file space availability Append flag 119
configuration 130 Architecture
file increment 131 overview 6
overview 30 Architecture, VSM 6
performance trade-offs 69 Archiving
space increment 131 definition 465
time increment 131
B
Accessibility
Backups
VSM-Java 90
definition 465
Access-time bias (volume set
managed file systems 190
availability) 62
NetBackup requirement 6
Action menu
VSM databases 190
VSM-Java 100
VSM procedure 191
Active state
Badness
managed file systems 193
see Thresholds
managedfile systems 8
Basic Configuration Wizard 103
Activity bar
block_size parameter 120
VSM-Java 94
bpbkar and bpbtar
Activity states
NetBackup requirement 6
see States
ad method 60 C
overview 1 Caches
Administration interface choosing copy to use 15, 17, 20, 31,
see VSM-Java 62
Age weight definition 465
configuring 134 delays
moving files 83 definition 466
purging files 81 demand delay parameter 15
selecting files 75 multilevel migration 31
Alternate level optimizing performance 64
definition 465 overview 13
Alternate magnetic disk partial file caching 17
see ad method Reporting Tool and 163
APIs total and partial file caching

477
 trade-offs 68 migftscan 335
total file caching 16 miggetvol 339
unmount delay parameter 15 miggroup 341
Capacity migin 346
Advanced Configuration miglicense 348
Wizard 120, 122 migloc 350
Cautions miglow 29, 353
changing the IHAND file 195 migmdclean 354
configuring two drives for two migmove 358
copies 57 mignbexport 363
database directory 49 mignbimport 367
editing VSM databases 232, 251 mignbscan 371
FlashBackup 190 mignewlog 375
forced registration 66 mignospace 377
NetBackup migpolicy 380
backup retention 191 migpurge 30, 382
policy conflicts 190 migrate 30, 383
NFS mount point 3 migrc 386
Partial VSM restore 191 migrd 388
Restore previous VOLDB 190 migreconstruct 389
volume management 202 migrecycle 392
Characters, special migreg 395
supported in VSM 74 migselect 400
Class, NetBackup migsetdb 402
see NetBackup policy migstage 408
Commands migtestbadness 410
gethsm 264 migtie 415
HSMKiller 266 migtscan 419
ihprint 268 migungroup 341
Man pages 261 migunmigrate 423
migactivate 273 migVSMshutdown 424
migadscan 275 migVSMstartup 425
migalter 278 migVSMstate 427
migbatch 24, 281 rebuild_ihand 429
migcat 284 startmigd 430
migchecklog 285 stopmigd 432
migcleanup 288 stopmigrd 434
migconf 290 VSM 435
migconfg 306 Concurrent recording
migcons 310 definition 466
migconsweep 314 example 63
migdbcheck 316 restraints on 64
migdbdir 327 Configuration
migdbrpt 328 Basic Configuration Wizard 103
migfind 333 files

478 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 definition 466 Customization
migconf 56 file migration criteria 84
migconfg (global), definition 466 file purging criteria 84
global migration policy 227
overview 45 migsweep.site 84, 242
planning 46 migsweepm.site 243
migrate (.migrate) file 218
D
migstop (.migstop) file 218
Daemons
overview 45
definition 466
parameters
migd
free space 468
overview 7
scripts 200
migrd
storage devices 91
starting 89
update fstab file 200
migvold
Configuration pane
overview 8
Scheduling tool 176
starting 198
Configure menu
starting and stopping 197
VSM-Java 100
Data comparisons
Configured slice
of file systems 182
definition 466
Database directory, location 39
recommended minimum 16
Database tools
Consolidation
VSM-Java 151
volume
Databases
multilevel migration 32
backing up 190
one step 208
caution for editing 232, 251
overview 204
cautions when choosing 49
two step 210
checking consistency of 195
volumes
choosing directories for 49
definition 466
description 232
Copied data
determining directories 49
Reporting Tool 164
dwpath
Copies
definition 467
concurrent recording 63
file handle
configuring number of 57, 116
see FHDB
parameter 116
file handle (FHDB)
which to cache first 62
definition 468
Copy processor 34
file name
copydb files
see FNDB
description 240
files contained in 39
multilevel migration 34
list of 232
overview 12
managed
ct method
backup and delete 157
definition 466
migrating files 157
description 59
searching 156
overview 1

Index 479
 managed server 233 see dk method, ad method, ft
Media Manager 21 method
migconf file 49 optical
Oracle see Optical disk
see Oracle archive redo logs Disk file
problem solving 251 storage methods
reports 249 see dk method
space requirements 51 Disk space
volume ENOSPC error
see VOLDB definition 467
Dead data FHDB 50
consolidating volumes 204 management
FHDB flags field 233 overview 22
multilevel migration 32 dk method
recycling volumes 208, 213 definition 467
Dead FHDB entries overview 1
multilevel migration DMAPI
move flags 150 definition 467
dead_man_timeout parameter 121, token 197
123, 124 Documentation
Defragmenting related xxii
directories, definition 466 dt method
Delayed labeling 125 definition 467
Deleted files description 59
reloading 258 overview 1
demand delay parameter dump command
Advanced Configuration backing up standard file
Wizard 121 systems 190
caches 15 backing up VSM databases 190
definition 467 cautions 191
density parameter dwpath
Advanced Configuration definition 467
Wizard 120
E
Device manager
Edit menu
definition 467
VSM-Java 97
Devices
Effective date
storage methods for 58
Scheduling tool 175
Directories
Effective slice
remote volume server 42, 127
definition 467
Directory group
Emergency file space parameters 30
see Directory-level migration
Empty volumes
Directory-level migration 20
definition 467
definition 20, 467
recycling 213
Disk
End of tape flag 119
magnetic

480 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 ENOSPC File handle database
definition 467 see FHDB
error 30 File increment
Exports accelerated file space availability 30,
description 35 69
of migrated files configuring 131
definition 468 mignospace command and 28
overview 35 File marks 229
planning 230 File menu
VSM-Java 97
F
File name database
FHDB 10, 49, 233
see FNDB
clear locks 252
File servers
definition 468
Macintosh 47
description 49, 233
VSM managed 476
disk space 50
File slice
estimated disk space 50
configured
fixing 251
configuring 130
flags field
definition 16
description 233
replaces effective slice 19
multilevel migration 34
space requirements 48
location 39, 307
effective
lock file
definition 16
description 242
replaces configured slice 19, 68
location 307
overview 15
number of entries 49
size
problem solving for 251
configuring 130
recovering 255
File slices
space requirements 50
configured
template 42
definition 466
updating 12, 34
effective
File Browser 167
definition 467
grouping directories 171
File space, accelerated availability 30
main screen 167
File System Analyzer
managing job activity 171
comparing data 182
migrating files 172
file system scans 182
migration 167
deleting 188
purging files 172
main screen 180
File Export/Import
menus 181
see Exports
testing migration policies 187
see Imports
File systems
File handle
creating
definition 468
fstab file 200
sequence file 242
managed
unassignable 255
backing up 190

Index 481
 checking consistency of 195 configuring 132
considering number of files 48 planning guidelines 73
definition 45 fspath
idle state 197 location 36
inode requirements 48 fstab file
log files 245 updating
making free space on 196 for managed file systems 200
migration thresholds 70 ft method
purge thresholds 80 definition 468
rules for choosing 46 overview 2
space for slice 48 partial file caching 17
mounting FTP
demand delay 467 ft method 2
scans 182 port number 123
unmount delay parameter 475
G
File-handle-sequence file
gethsm command
description 242
man page 264
location 39, 307
GLABEL file 43
rebuilding 255
Global log file
Filenames
file systems in Maintenance
special characters
state 195
supported 74
viewing 244
Files
Global migrate file
disk 1
definition 471
not to migrate 46
Global stop file
remote volume server 42
definition 475
Flags field
gran_size parameter
FHDB 233
description 121, 122, 124
VOLDB 238
Granules
FlashBackup, caution for 190
definition 469
FLUSH file
description 12
definition and use 229
file-handle entries for 49
location 40
Grouped files
FNDB
migration of 171
definition 468
GUI
Free space
see VSM-Java
creating on file systems 196
definition 468 H
file systems 196 Help menu
parameter VSM-Java 101
definition 468 Hierarchy
Free space parameter VSM-Java
default value 73 definition 469
description 22 description 93
migration High-water mark

482 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 see Free space parameter J
HSMDEV entry Java
definition 469 VSM-Java Administrator
see also hsmname parameter interface 89
HSMKiller command Job activity
killing blocked processes 252 management
man page 266 File Browser 171
releasing tape requests 260
L
hsmname parameter
Label
definition 469
volume
I for tape media 125
ID_LABEL file 43, 244 Label, volume
Idle state 8, 193, 197 alternate disk 125
Idling state 8, 193 for FTP 126
IHAND file for NetBackup 128
administering 198 for tape media 66
caution for changing 195 lgpath parameter
check and fix 200 overview 40
creating 198 library
definition 470 volume set availability
description 198 planning 62
extending 199 Links, symbolic 218, 219
format 198 Local migrate file
location 40, 307 definition 471
recover 200 Local stop file
space requirements 50, 199 definition 475
ihprint command Locks, clearing VSM 252
man page 268 Log files 248
Illegal characters, file names 74 choosing paths 51
imageID global log file, location 40
nb method 203 linking global 200
Imports managed file systems
description 35 viewing 245
of migrated files managing 247
definition 470 messages, level of
overview 35 location 41
planning 230 viewing 244, 245
Inactive state 8, 193 VSM-Java
Inodes creating for 248
definition 470 Logs
managed file systems 48 Oracle archive redo 153
Installation VSM management of Oracle redo
VSM logs 151
overview 90 Low-water mark

Index 483
 configuring 132 definition 467
default values 70 installation 90
definition 470 overview 21
description 22 shared storage devices 2
planning guidelines 70 terminology used xxiii
mediacheck command
M
fixing the FHDB 251
Macintosh file servers 47
Menus
Magnetic disk
Action
media 1
VSM-Java 100
Maintenance state 8, 193
Configure
Man pages 261
VSM-Java 100
Managed directory
Edit
Oracle archive redo logs 130
VSM-Java 97
Managed file system
File
reports
VSM-Java 97
Reporting Tool 162
File System Analyzer 181
Managed file systems
Help
definition 470
VSM-Java 101
Managed server, definition 2
View
Management tasks
VSM-Java 98
scheduling with VSM-Java 173
VSM-Java 97
Managing VSM 189
Method names
Manuals
definition 471
related xxii
migrating files 58
Media
METHOD1-8
consolidate volumes 208
examples 64
definition 470
name parameters
magnetic disk 1
ct 59
monitoring usage 202
dt 59
moving volumes offline 214
mt 59
not enough tapes available 260
nb 61
optical
op 59
notes on support 461
ow 59
recycling 208
names to use for
registration
magnetic disk storage 58
automatic, tape & optical 12, 203,
NetBackup 58
204
NFS file system 58
releasing tape requests 260
optical disk storage 58
reports 249
remote storage 58
storage methods to use 58
tape storage 58
Media Manager
overview
configuring storage devices 91
METHOD1-2 57
definition xxiii, 470
METHOD3-8 67
device manager
volume set availability

484 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 parameter 62 migdbcheck command
MicroSoft platforms man page 316
for VSM-Java 90 used to fix VOLDB 253
migactivate command migdbdir command
man page 273 man page 327
migadscan command migdbrpt command
archive disk report 250 man page 328
man page 275 migration database report 250
migalter command migfind command
man page 278 man page 333
migattr driver 192 migftscan command
migbatch command 24 man page 335
calling from VSM-Java 223, 225, 226 remote volume report 250
man page 281 miggetvol command
migcat command man page 339
man page 284 miggroup command
migchecklog command directory level migration 20
man page 285 man page 341
migcleanup command migin command
man page 288 man page 346
migconf command reloading deleted files 258
man page 290 miglicense command
migconf file man page 348
description 243 migloc command
location 40, 307 man page 350
overview 56 miglow command
planning worksheet 49 man page 353
template 42 overview 29
migconfg command migmdclean command
man page 306 man page 354
migconfg file migmerge.sh script 34
location 41 migmove command
overview 45 creating work lists 34
planning worksheet 46 man page 358
template 41 mignbexport command
migcons command man page 363
man page 310 mignbimport command
recycling volumes with 208 man page 367
migconsweep command mignbscan command
man page 314 man page 371
migcopy command mignewlog command 248
overview 7 man page 375
migd daemon 7 mignospace command
definition 471 man page 377
starting and stopping 197 migopscan command

Index 485
 optical volume report 250 criteria 76
migpolicy overview 73
example script 42 procedure for planning 76
migpolicy command frequency 54
man page 380 management overview 22
migpolicy script minimum file age
creating work lists 12 planning 74
customizing 227 minimum file size 23
modifying 65 planning 74
template 42 overview 9
migpolicy.script performance 229
changing 42 planning 45
migpurge command policies
man page 382 testing with File System
overview 30 Analyzer 187
Migrate restarting 259
definition 471 scheduling 53, 222
see also Migration see also Migration level
migrate (.migrate) file tape 229
file system sweeps 25 thresholds
rules for creating 218, 219 overview 70
migrate command planning procedure 56
man page 383 time to complete 48, 54
overview 30 with migbatch command 24
Migrate file with miglow command 29
see also Migrate with migrate command 30
see also Migration Migration candidate
Migrate file, global definition 471
file system sweeps 25 Migration levels
location 41 definition 470
migration control 218 see also Migration
Migrated files migrc command
exporting man page 386
definition 468 restarting migrations with 259
Migration migrd command
automatic man page 388
overview 22 migrd daemon
best times for 53 definition 471
control, global 218 starting 89
database report 250 starting and stopping 197
directory level 20 migrd.log
example schedule 54 creating 248
File Browser and 172 migreconstruct command
file selection man page 389
configuring 133 migrecycle command

486 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 man page 392 VSM states 9, 193
migreg command migVSMstate command
man page 395 man page 427
migsa command 89 VSM states 9
migselect command migworker script 12, 34
man page 400 Minimum file age
volume consolidation 208 for migration
migsetdb command description 23
man page 402 guideline for setting 76
migstage command Minimum file size
man page 408 for migration
partial file caching 17 description 23
migstop (.migstop) file guideline for setting 76
rules for creating 218, 219 mode bit field, fls command 5
migsweep.site MOTAB, location 41
changing 42 Mount table, global 41
description 242 Mounts
template 42 demand delay parameter
migsweepm.site definition 467
changing 42 unmount delay parameter 475
description 243 Move flags, configuring 150
template 42 Move threshold
migtestbadness command definition 475
man page 410 file
migtie command formula for 82
man page 415 site-specified 243
partial file caching 17 weighting factors 82
migtscan command Moving
man page 419 minimum file age
tape volume report 250 planning 82
migungroup command minimum file size
man page 341 planning 82
migunmigrate command mt method
man page 423 definition 472
migvold daemon description 59
definition 471 overview 1
overview 8 Multilevel migration
starting and stopping 197 caches 31
migVSMshutdown command copydb files 240
explained 197 definition 472
man page 424 file selection
VSM states 9 criteria 81
migVSMstartup command 192 minimum file age
man page 425 planning 82
startup problems 195 minimum file size

Index 487
 planning 82 cleaning nb volumes 203
overview 31, 33 consolidating volumes 204
volume consolidation 32, 34 FHDB flags field 233
work lists 240 multilevel migration 32
recycling volumes 213
N
Obsolete FHDB entries
nb method
backup retention period 191
defining NetBackup policy for 128
consolidating volumes 204, 207,
definition 472
208, 210
description 61
for modified cached files 14
overview 2
multilevel migration
partial file caching 17
move flags 150
nb volumes
Obsolete flag 122, 123, 124
cleaning 203
Offline storage 214
NetBackup
definition 472
caution for 190
op method
file backup with 190
definition 473
migrated files 191
description 59
nb method 2
overview 1
policy
operator
caution for 190
volume set availability
defining 128
planning 62
requirement for VSM 6
Optical disk
retention, caution for 191
notes on support 461
schedule
op method 1, 59
defining 128
ow method 1, 59
servers 128
write once, read many (WORM) 59
slice value lost 191
Options tree
storage
Scheduling tool 175
nb method 61
Oracle
support of optical disk 461
archive redo log management 151
Next-volume-set files
Oracle archive redo logs
description 242
backup and delete 157
location 39, 307
management 151, 152
NFS (Network File System)
migrating files 157
mount point 3
searching 156
mounted file system
Oracle databases
managing 46
see Oracle archive redo logs
operations 197
ow method
rules for using 3
definition 473
NT
description 59
platform for VSM-Java 90
overview 1
O
P
Obsolete data
Partial file caching
backup retention period 191

488 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 Configuring with VSM-Java 130 overview 24
definition 473 Primary copy
disabling 19, 130 definition 473
ft method 17 Primary level
nb method 17 definition 473
overview 17 Problem solving
purging files 20, 80 automatic removal or migration
total file caching trade-offs 68 failure 259
Partial VSM restore, caution for 191 clear FHDB locks 252
Pathname length, requirements 74 create new log files 248
Performance fix FHDB 251
constant sweeping 31 fix FHSEQF 255
migrating small files 229 fix VOLDB 253
migration to tape 229 recover FHDB and VOLDB 255
Reporting Tool 165 release tape requests 260
trade-offs reload deleted files 258
accelerated file space reports 249
availability 69 restart migrations 259
constant sweeping 31, 230 startup 195
partial file caching 68 user file access 259
Planning volumes
database directories 49 insufficient 260
global configuration 46 Process id (pid)
migration requirements 45 migd 41
migration thresholds 70 migvold 42
purge thresholds 80 Processes, killing VSM 252, 260
storage methods 57 Pseudodevice
summary procedure 84 definition 473
Policies Purge mark
migration configuring 132
testing with File System default values 71
Analyzer 187 definition 474
Policy description 22
see NetBackup policy planning guidelines 71
Pools Purge thresholds
volume definition 474
media management 21 file
multiple 63 formula for 81
VSM volume pool 119 site-specified 75, 242
port_number parameter 123 weighting factors 81
Power down Purges
remote volume server 198 migpurge command 30
Premigration minimum file age
calling from VSM-Java 223, 225, 226 planning 81
definition 473 minimum file size

Index 489
 planning 81 setting preferences 160
partially cached files 20, 80 starting 158
problems with automated 259 Reports, media and database 249
thresholds Restart time window
overview 80 Scheduling tool 175
with File Browser 172 restore command
backing up standard file
Q
systems 190
quota parameter
backing up VSM databases 190
configuring 130
cautions 191
definition 474
Restores
planning 67
definition 474
R Run days
Read ahead Scheduling tool 175
configuring 130
S
explained 18
Scans
rebuild_ihand command
deleting
man page 429
File System Analyzer 188
Recovery operations 9, 195
performing
Recycling
File System Analyzer 182
volumes 208, 213
Schedules
definition 474
backing up VSM databases 190
Redo Logs
component configuration
Oracle
Scheduling tool 175
VSM managmement 151
configuration pane 176
Remote migration
effective date 175
ft method 2
for migrations 53, 222
Remote storage
general options 175
ad method 60
management tasks
definition 474
using VSM-Java 173
nb method 61
migrations 53, 222
Remote volume server
options tree list 175
definition 474
restart time window 175
description 2, 126
restarting tasks 177
shutdown 198
run days 175
Reporting Tool 158
settings
data copied reports 164
Scheduling tool 177
data retrieval (caching) reports 163
summary
data retrieval reports 163
Scheduling tool 178
file and space usage 161
summary of configured tasks 178
lperformance reports 165
time window 175
main window 158
Scheduling tool
managed file system reports 162
configuration pane 176
menus 159
general options 175
performance reports 165

490 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 main window 173 Startup
options tree list 175 problems 195
restart time window 175 scripts 192
run days 175 VSM
schedule component overview 9
configuration 175 Startup scripts 192
schedule summary 178 States
scheduling tool 177 fixing the FHDB 251
tasks VSM activity 8
restarting 177 Stop file
time window 175 global
Scripts location 41
migmerge.sh 34 migration control 218
shutdown 197 stopmigd command
startup 192 man page 432
Secondary storage stopmigrd command
definition 474 man page 434
Servers Stopping VSM
managed 2 see Shutdown
remote 2 stopping VSM operations
Session id (sid) see also Shutdown, VSM
migd 41 Storage devices
Shutdown installation 90
activity states 196 Storage methods
overview 193 configure with VSM-JavaI 118
remote volume server 198 criteria for selecting 64
scripts ct 466
for all platforms 197 definition 475
shutting down VSM dk 467
see also Shutdown dt 467
Size weight effect of media cost 64
configuring 134 ft 468
overview 75, 81, 83 mt 472
Slice nb 472
see File slice op 473
Small file migration overview, file migration 11
Space increment overview, multilevel file
accelerated file space availability 30, migration 33
69 ow 473
configuring 131 planning overview 57
used with mignospace command 28 reconfiguring 228
Sparse file Stripes
definition 475 concurrent recording 63
startmigd command 89 definition 475
man page 430 description 58

Index 491
 multiple 63, 64, 67 used with mignospace command 28
sweep.restart file 25 Time window
Sweeps Scheduling tool 175
file system Timestamp
constant 31 nb method 203
round-robin 25 Tokens, DMAPI 197
Symbolic links 218, 219 Toolbar
VSM-Java 95
T
Total file caching
Tape marks
overview 16
frequency 229
partial file caching trade-offs 68
Tapes
Trailer labels
ct, dt, and mt methods 59
tapes 196
duplicating 215
missing trailer labels 196 U
not enough available 260 UNIX platforms
performance 229 for VSM-Java 90
random seek 1 Unmount
releasing requests 260 managed file systems 196
supported tape methods 1 unmount delay parameter 15, 121, 475
Tasks User operations
restarting overview 5
Scheduling tool 177
V
Templates
vault
database files 42
volume set availability
file-handle database file 42
planning 62
migconf file 42
View menu
migconfg file 41
VSM-Java 98
migsweep.site 42
VOLDB 237
migsweepm.site 42
caution for restoring 190, 254
sample.migpolicy.script 42
definition 476
volume database file 42
description 237
Threshold
fixing 253
file
flags field
examples 77, 78
description 238
formula for 74
multilevel migration 34
selections 134
location 39
site-specified 84, 242
lock file
weighting factors 74
description 242
Thresholds
location 39
definition 475
recovering 255
Time increment
removing entries 214
accelerated file space availability 30,
template 42
69
updating 12
configuring 131
Volume database

492 VERITAS Storage Migrator System Administrator’s Guide for UNIX

 see VOLDB VSM server
Volume label definition 476
for alternate disk 125 VSM states 8
for FTP 126 fixing the FHDB 251
for NetBackup 128 VSM-Java
for tape media 66, 125 Action menu 100
Volume pools Activity bar (bottom pane) 94
definition 476 advanced configuration wizard 113
multiple 63 Bottom Pane 94
VSM 119 configuration wizards 135
Volume set availability 62 Configure menu 100
planning 62 configure volume pools 119
Volume sets database tools 151
concurrent recording 63 definition 476
definition 476 Edit menu 97
description 58 File menu 97
moving volumes between 214 file system properties 129
next set to use 242 Help menu 101
Volumes hierarchies in 93
allocation 21 Left Pane 93
assignments 21 log files
consolidation creating log 248
definition 466 managing 247
one step 208 viewing 244, 245
overview 204 login 91
two step 210 main screen 92
damaged 214, 238 manual configuration 145
definition 476 menus 97
destroyed 214 overview 89
empty PC platforms 90
definition 467 premigrate and copy files 223, 225,
full 238 226
lost 214 reconfiguration 147
management 201 restarting migrations with 259
management of Right Pane 93
overview 21 setting states 9
Media Manager xxiii starting daemons 198
monitoring usage 202 starting interface 89, 193
mount points 42 starting migrd daemon 89
moving offline 214 stopping Daemons 198
recycling 208 toolbar 95
unused 202 tools
Volume-sequence file backup and delete 157
description 242 for migrating files 172
location 39 for Oracle archive redo logs 153

Index 493
 for purging files 172 move threshold
migrating database archive redo overview 83
logs 157 purge threshold
migrating grouped files 171 overview 81
searching databases 156 threshold formula
see also File Browser, File System overview 75
Analyzer, Reporting Tool, Windows
Scheduling Tool, Managing platforms for VSM-Java 90
Oracle Archive Redo Log Tool Work directory
UNIX platforms supported 90 location 38
View menu 98 Work lists
volume recycling 215 description 240
volume registration 124 multilevel migration 34
overview 12
W
Write Once, Read Many (WORM) 59
Weight operator
definition 476
configuration with VSM-Java 134

494 VERITAS Storage Migrator System Administrator’s Guide for UNIX