Sie sind auf Seite 1von 520

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:
support@veritas.com

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