Storage Migrator Unixadmin

VERITAS Storage Migrator™ 4.5 System Administrator’s Guide for UNIX

March 2002 30-000704-011

Disclaimer The information contained in this publication is subject to change without notice. VERITAS Software Corporation makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. VERITAS Software Corporation shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual. Copyright Copyright © 1994-2002 VERITAS Software Corporation. All Rights Reserved. VERITAS, VERITAS SOFTWARE, the VERITAS logo, Business Without Interruption, VERITAS The Data Availability Company, VERITAS NetBackup, VERITAS NetBackup BusinesServer, VERITAS Remote Storage for Microsoft Exchange, VERITAS Cluster Server, VERITAS Storage Migrator, and VERITAS Storage Migrator Remote are trademarks or registered trademarks of VERITAS Software Corporation in the U.S. and/or other countries. Other product names mentioned herein may be trademarks or registered trademarks of their respective companies. VERITAS Software Corporation. 350 Ellis Street. Mountain View, CA 94043 Phone 650.527.8000 Fax 650.527.8050 http://www.veritas.com

Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Audience and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxii Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxii Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Type Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Notes and Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Key Combinations and Pulldown Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Command Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Chapter 1. About VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Administrative Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 User Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 NetBackup Requirement with VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 VSM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Basic Migration Operations and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 VSM Activity States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 File Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Select Files to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Assign a File Handle and Create Database Entries . . . . . . . . . . . . . . . . . . . . . . . . 10 Assign the Storage Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Create Migration Work Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 i

Copy Files to Secondary Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Update the VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 File Slices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Total File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Partial File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Directory-level Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Tape and Optical Volume Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Migration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Migration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 The migbatch Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 The mignospace Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 The miglow Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 User Migration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 The migrate Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 The migpurge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Accelerated Disk Space Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Constant Sweeps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Multilevel Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 File Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Select Files to Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 File Handles, Storage Methods, and Work Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Copy to Next Migration Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Update VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Clean Up, FHDB and VOLDB Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 File Export/Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 VSM System Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Managed File System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Databases, Work Files, Logs, and Binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Files in dwpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 ii

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Global Configuration File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Remote Volume Server Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Chapter 2. Planning VSM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 VSM Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Managed File Systems in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 File Systems to Manage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 File Systems Not to Manage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 VSM and Macintosh File Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Notes on Samba Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Number of Files and Inodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 VSM Databases in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Files in Database Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 FHDB and FNDB Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 FHDB and FNDB Space Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Inode-to-Handle File Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Total Database Space Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Log File Pathnames in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 VSM States, Space Management, and Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 States other than Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Migration Schedules in Global Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Best Times for Migrating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 How Often to Migrate Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Time Required to Complete Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Migration Schedule Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Schedules for Report Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Completing the Global Configuration Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Managed File System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Contents

iii

Initial Configuration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Storage Levels for Migrating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Method Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Tape Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Optical Disk Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Disk Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Remote FTP Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 NetBackup Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Volume Set Availability (hint value) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Volume Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Concurrent Stripes / Concurrent Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Choosing the Best Storage Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Volume Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Storage Levels for Moving Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 General File System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Slice Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Quota on Migration Stop Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Partial File Caching Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Accelerated Disk Space Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Criteria for Migrating Files (Water Marks) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Desired Percentage Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Desired Percentage Purged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Desired Percentage of Free Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Criteria for Selecting Files to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 How VSM Selects Files to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Procedure for Setting File Migration Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Criteria for Purging Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Criteria for Moving Migrated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Customizing Migration, Purging, and Moving Criteria . . . . . . . . . . . . . . . . . . . . . . . . . 84 Example Planning Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 iv

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Chapter 3. VSM-Java Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 About the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Administration Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Left Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Right Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Bottom Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Administration Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Change Server Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Basic Configure Wizard Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Advanced Configure Wizard Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Database Configuration Wizard Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 New Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Delete Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Change Properties Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 File Browser Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 File System Analyzer Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Refresh Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Administration Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 File Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Edit Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Volume Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Managing Jobs on the Activity Table (Bottom Pane) . . . . . . . . . . . . . . . . . . . . . . 99 Actions Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Management Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 VSM Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Help Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Contents

v

Chapter 4. Configuring VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Basic Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Basic Configuration - Select File System Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Basic Configuration - Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Basic Configuration - Select Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Basic Configuration - Properties Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Basic Configuration - Select Local Device Properties Dialog . . . . . . . . . . . . . . 107 Setting up VSM Volumes Using Media Manager . . . . . . . . . . . . . . . . . . . . . . . . 108 Basic Configuration - Select Remote Server Properties Dialog . . . . . . . . . . . . . 109 Basic Configuration - Select Alternate Disk Properties Dialog . . . . . . . . . . . . . 110 Basic Configuration - Select NetBackup Properties Dialog . . . . . . . . . . . . . . . . 111 Basic Configuration - Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . . . . 112 Advanced Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Advanced Configuration - Select File System Dialog . . . . . . . . . . . . . . . . . . . . . . . 114 Advanced Configuration - Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Advanced Configuration - Hierarchy Properties Dialog . . . . . . . . . . . . . . . . . . . . 116 Advanced Configuration - New Level Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Advanced Configuration - New Stripe Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Advanced Configuration - Stripe Properties Dialogs . . . . . . . . . . . . . . . . . . . . . . . 118 Stripe Properties Dialog for Tape and Optical Media . . . . . . . . . . . . . . . . . . . . 119 Stripe Properties Dialog for Alternate Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Stripe Properties Dialog for FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Stripe Properties for NetBackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Advanced Configuration - Volume Registration Dialogs . . . . . . . . . . . . . . . . . . . . 124 Volume Properties Dialog for Tape and Optical Media . . . . . . . . . . . . . . . . . . 124 Volume Properties Dialog for Alternate Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Volume Properties Dialog for FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Volume Properties Dialog for NetBackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Advanced Configuration - Alternate Level Dialogs . . . . . . . . . . . . . . . . . . . . . . . . 129 Advanced Configuration - File System Properties Dialog . . . . . . . . . . . . . . . . . . . 129 vi

VERITAS Storage Migrator System Administrator’s Guide for UNIX

File System Properties - General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 File System Properties - Additional Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 File System Properties - Water Marks Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 File System Properties - Migration Criteria and Purge Criteria Tabs . . . . . . . . 133 Advanced Configuration - Committing Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Database Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Database Configuration - Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Database Configuration - Select Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Database Configuration - Select Properties Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . 138 Select Local Device Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Select Remote Server Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Select Alternate Disk Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Select NetBackup Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Database Configuration - Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . 144 Editing the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Adding to Configured Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Adding Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Adding Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Adding Stripes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Editing Existing Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Editing Hierarchy Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Editing File System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Editing Level Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Editing Stripe Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Chapter 5. VSM-Java Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Managing Oracle Archive Redo Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Oracle Archive Redo Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Database Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Manage Archive Redo Logs Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Contents

vii

Manage Redo Log Files Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Reporting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Starting the Reporting Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Reporting Tool Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Reporting Tool Pull-Down Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Setting Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Server Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Managed File System Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Response Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Performance Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 File Manipulation with the File Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 File Browser Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 File Browser Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 File Browser Pull-down Menus and Tool Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 File Browser Left Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 File Browser Right Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 File Browser Bottom Pane and View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 File Browser Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Directory Groups Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Migration... Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Scheduling Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Scheduling Tool Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Component Configuration Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Configuring Schedule Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Restarting a Task within Its Time Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Time Windows that Extend Past Midnight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Viewing a Schedule Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 File System Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 File System Analyzer Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 File System Analyzer Pull-down Menus and Tool Bar . . . . . . . . . . . . . . . . . . . . . . 181 viii

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Using the File System Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Experimenting with Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Deleting Previous Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Chapter 6. Managing VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Backing up VSM Databases and Managed File Systems . . . . . . . . . . . . . . . . . . . . . . . . 190 Backing up VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 General VSM Backup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Starting VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Customizing Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Shutting down VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Starting and Stopping VSM Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Powering down Remote Volume Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Setting up Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Administering Inode-to-Handle (IHAND) Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Setting up fstab/vfstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Global Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Scheduling Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Managing Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Monitoring Volume Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Keeping a Supply of Unused Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Cleaning nb Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Consolidating Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 One-Step Volume Consolidation with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . 207 Command-line One-Step Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Command-line Two-Step Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Recycling Empty Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Removing Tape or Optical Volumes for Offline Storage . . . . . . . . . . . . . . . . . . . . . 214 Moving Files to a New Volume Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Contents

ix

Deleting Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Duplicating a Tape Volume from Migrated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Managing Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Controlling Global Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 General Rules for VSM Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Syntax Rules for VSM Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Control File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Scheduling Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Invoking Migration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Migrating Files to Secondary Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Managing the Free Space Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Making More Disk Space Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Move Files between Migration Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Customize the VSM Policy and Method for Migrating Files . . . . . . . . . . . . . . 227 Reconfiguring Storage Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Performance Tuning with Tape Marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Performance Tuning with Constant Sweeps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Moving Migrated Files (Export and Import) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Planning File Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Planning File Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Managing VSM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Databases on a VSM server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 File Handle Database (FHDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 File Name Database (FNDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Volume Database (VOLDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Work Lists (copydb files) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Destination Volume Database (DVDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 FHDB Lock File (FHDB.LK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 File Handle Sequence File (FHSEQF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Volume Database Lock File (VOLDB.LK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 x

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Volume Sequence File (VOLSEQF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Next-Volume-Set Files (NEXTVOLM1...NEXTVOLM8) . . . . . . . . . . . . . . . . . . 242 The migsweep.site and migsweepm.site files . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 migconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Inode to Handle File (IHAND) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 FLUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 ID_LABEL Databases on a Remote Volume Server . . . . . . . . . . . . . . . . . . . . . . . . . 244 Solving Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Viewing Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Viewing Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Automatic Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Searching Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Managing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Setting the Logging Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Making Log Files Smaller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Creating the VSM-Java Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Changing VSM States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Media and Database Information and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Database Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Fixing FHDB Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Clearing FHDB Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Fixing the Volume Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Recovering File Handle and Volume Databases . . . . . . . . . . . . . . . . . . . . . . . . . 254 Cannot Find Next File Handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Restoring Managed File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Extending Managed File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 File and Migration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Reloading Deleted Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Restarting Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Migrating, Purging, or Accessing Files Does Not Occur . . . . . . . . . . . . . . . . . . 259 Contents

xi

Releasing VSM Tape Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Having No Volumes Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Appendix A. Man Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 fls(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 gethsm(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 HSMKiller(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 ihprint(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 mediacheck(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 migactivate(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 migadscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 migalter(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 migbatch(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 migcat(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 migchecklog(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 migcleanup(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 migconf(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 migconfg(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 migcons(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 migconsweep(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 migdbcheck(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 migdbconvert(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 migdbdir(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 migdbrpt(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 migfind(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 migftscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 miggetvol(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 miggroup(1), migungroup(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 migin(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 miglicense(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

xii

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migloc(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 miglow(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 migmdclean(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 migmove(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 mignbexport(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 mignbimport(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 mignbscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 mignewlog(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 mignospace(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 migpolicy(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 migpurge(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 migrate(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 migrc(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 migrd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 migreconstruct(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 migrecycle(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 migreg(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 migselect(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 migsetdb(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 migstage(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 migtestbadness(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 migtie(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 migtscan(1M), migopscan(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 migunmigrate(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 migVSMshutdown(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 migVSMstartup(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 migVSMstate(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 rebuild_ihand(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 startmigd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 stopmigd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Contents

xiii

stopmigrd(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 VSM(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Appendix B. Enterprise Agent for Storage Migrator . . . . . . . . . . . . . . . . . . . . . . . . 441 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Pre-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Import Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 VSM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Agent Configuration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Manual Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 Manual Active-Active Configuration using FTP . . . . . . . . . . . . . . . . . . . . . . . . 450 Manual Active-Inactive Configuration using NetBackup . . . . . . . . . . . . . . . . . 453 Sample Configuration File Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 Maintaining Your System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 Removing the Enterprise Agent for Storage Migrator . . . . . . . . . . . . . . . . . . . . . . . . . 458 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Appendix C. Notes on Supported Optical Media . . . . . . . . . . . . . . . . . . . . . . . . . . 461 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

xiv

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Figures Basic VSM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Basic VSM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 File Migration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 File Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Total File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Partial File Caching, Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Partial File Caching, Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Media Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Migration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Migrating Files with migbatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Making Space Available with mignospace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Checking Free Space with miglow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Default Configuration for Multilevel Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 File Movement Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Managed File System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 VSM File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Global Configuration File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Remote Volume Server Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Concurrent Recording of Multiple Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Low-Water Mark and Purge Mark Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Minimum Age, Minimum Size, and Threshold Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Threshold Example 1 (threshold = 30) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Threshold Example 2 (threshold=90) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

xv

Threshold Example 3 (threshold=90, cut to threshold=45) . . . . . . . . . . . . . . . . . . . . . . . . . 80 Selection Criteria for Moving Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Global Configuration Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Managed File System Configuration Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 VSM-Java Main Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Login Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Components of the VSM-Java Main Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Edit Menu When Server Is Selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Bottom Pane Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Right Pane Displaying Activity Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Toolbar when Server Is Highlighted and some File Systems not Configured . . . . . . . . . . 95 Toolbar when Hierarchy Is Highlighted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 VSM-Java Menu Bar when Hierarchy Is Highlighted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Edit Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 View Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Select Filesystem Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Basic Configuration Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Select Storage Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Local Device Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Remote Server Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Alternate Disk Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 The NetBackup Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Select Filesystem Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Advanced Configuration Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Hierarchy Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 The New Level Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 The New Stripe Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 General Tab, Stripe Properties Dialog for Tape and Optical Disk . . . . . . . . . . . . . . . . . . . 119 Physical Tab, Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 xvi

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Timeout Tab, Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Alternate Disk Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 FTP Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 NetBackup Stripe Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Primary Volume Registration Dialog, FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Primary Volume Registration Dialog - NetBackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 New Level Dialog, Alternate Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 General Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Additional Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Water Marks Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Migration Criteria Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Purge Criteria Tab, Filesystem Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Login Dialog, Database Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Database Configuration Enter Values Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Select Method Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Select Local Device Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Select Remote Server Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Select Alternate Disk Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Select NetBackup Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Database Configuration Summary Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Edit > Change Hierarchy Properties Selection and Resulting Display . . . . . . . . . . . . . . . 148 Edit > Change Filesystem Properties Selection and Resulting Display . . . . . . . . . . . . . . . 149 Edit > Change Level Properties Selection and Resulting Display . . . . . . . . . . . . . . . . . . . 149 Edit > Change Level Properties Selection and Resulting Display . . . . . . . . . . . . . . . . . . . 150 Components of the Manage Archive Redo Logs Main Dialog . . . . . . . . . . . . . . . . . . . . . . 154 Manage redo log files Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Reporting Tool Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 File System Trends as Bar Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 File Browser Main Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 File Browser Actions > Migration Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 xvii

Schedule Jobs Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 File System Analyzer Main Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Number by access time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Number by modification time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Number by size Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Size by access time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Size by modification time Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Size by size Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What If File System Analyzer Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Writing and Obsoleting Files on Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Selecting a Full Volume to Consolidate with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 One-Step Consolidation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Two-Step Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Selecting an Empty Volume to Recycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Selecting a Volume to Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Files Affected by Example Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Premigrating Files with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Managing the Free Space Threshold with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Purging Files with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Moving Migrated Files with VSM-Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 VSM Global Log File View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Managed File System Log File View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Searching in the Global Log File View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Sample Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Dependencies for Active-Active Configuration with FTP . . . . . . . . . . . . . . . . . . . . . . . . . 451 Dependencies for Active-Inactive Configuration with NetBackup . . . . . . . . . . . . . . . . . . 454

xviii

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Tables Typographic Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Storage Method Possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 File Browser Icons Used in Left and Right Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Startup/Shutdown Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Initial Set of Migrating Candidates in Control File Example . . . . . . . . . . . . . . . . . . . . . . . . 220 Migration Candidates in Control File Example when Local .migstop Exists . . . . . . . . . . 221 FHDB Entry Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 FNDB Entry Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 VOLDB Entry Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Work List (copydb) Entry Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Commands for Media and Database Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Components and Resources for Enterprise Agent for Storage Migrator . . . . . . . . . . . . . . 442 Operations for the StorageMigrator Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 Operations for the StorageMigratorFS Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Supported Optical Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

xix

xx

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Preface This guide describes how to configure and manage VERITAS Storage Migrator (VSM) release 4.5. VSM runs on Solaris, HP-UX, and SGI IRIX. The VSM-Java interface runs on Solaris, HP-UX, and Windows. For specific information about supported hardware and operating systems for this software, see the VERITAS Storage Migrator Release Notes for UNIX.

Audience and Scope This guide is intended for system administrators. Its purpose is to explain how to configure and manage VSM on a UNIX platform. This guide assumes that you have the following experience: ◆

A basic understanding of system administration

◆

A good working knowledge of the UNIX operating system

◆

A basic understanding of storage management principles

See the VERITAS Storage Migrator Installation Guide for UNIX for information about installation.

Organization Read the following chapters in numerical order unless advised to see a specific section: ◆

“About VSM” on page 1 is a general overview of VSM; it tells you what the product does.

◆

“Planning VSM Configuration” on page 45 provides information about developing a migration policy for your site.

◆

“VSM-Java Overview” on page 89 describes the basics of the VSM-Java interface.

◆

“Configuring VSM” on page 103 describes how to configure VSM using the VSM-Java interface. xxi

Related Documents ◆

“VSM-Java Tools” on page 151 describes the VSM-Java tools that help you maintain VSM managed files systems.

◆

“Managing VSM” on page 189 describes how to maintain and complete daily operations on VSM and file systems it manages.

◆

“Man Pages” on page 261 contains copies of all VSM man pages (command reference).

◆

“Enterprise Agent for Storage Migrator” on page 441 describes how to configure VSM in failover mode with the Enterprise Agent for Storage Migrator.

Related Documents ◆

The VERITAS Storage Migrator Release Notes for UNIX lists the supported platforms and operating systems and describes new features and problems fixed in this release.

◆

The VERITAS Storage Migrator Installation Guide for UNIX describes how to install and configure a test system.

◆

The NetBackup Release Notes provide important information about supported platforms, operating systems, and peripheral storage equipment.

◆

The NetBackup DataCenter Installation Guide for UNIX describes how to install NetBackup.

◆

The NetBackup Media Manager Device Configuration Guide for UNIX describes how to configure storage devices controlled by Media Manager.

◆

The NetBackup DataCenter Media Manager System Administrator’s Guide for UNIX describes Media Manager, its components, and how they are used to manage media volumes, drives, and robots.

Accessibility VSM contains features that make the user interface easier to use by people who are vision impaired and by people who have limited dexterity. Accessibility features include the following: ◆

Support for assistive technologies such as screen readers and voice input software (Windows NT/2000 only)

◆

Support for keyboard (mouseless) navigation using accelerator keys and mnemonic keys

More information on these features are included in the release notes.

xxii

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Conventions

Conventions This section explains typographical and other conventions used in this guide. Note In this publication, the term Media Manager refers to the media management software that is part of NetBackup. The term volume refers to storage media such as tape or optical disk.

Type Style Typographic Conventions Typeface

Usage

Bold fixed width

Input. For example, you might see, “Type cd to change directories.”

Fixed width

Paths, commands, filenames, or output. For example, you might see, “The default installation directory is /opt/VRTSxx.”

Italics

Book titles, new terms, or used for emphasis. For example, you might see, “Do not ignore cautions.”

Sans serif (italics)

Placeholder text or variables. For example, you might see, “Replace filename with the name of your file.”

Bold type (no italics)

Graphical user interface (GUI) objects, such as fields or menu choices. For example, you might see, “Enter your password in the Password field.”

Notes and Cautions Note This is a Note. It is used to call attention to information that makes it easier to use the product or helps you to avoid problems. Caution This is a Caution. It is used to warn you about situations that can cause data loss.

Preface

xxiii

Getting Help

Key Combinations and Pulldown Menus Some keyboard command sequences use two or more keys at the same time. To describe this sequence, the keys are connected by plus signs, as follows: Press Ctrl+t Pulldown menus often require you to make more than one selection from a menu. To describe a sequence of menus meant to be selected together, the menus are connected by a greater than sign (>), as follows: Select Edit > New Stripe

Command Usage The following conventions are frequently used in the synopsis of command usage. brackets [ ] The enclosed command line component is optional. Vertical bar or pipe (|) Separates optional arguments from which the user can choose. For example, it is used when a command has the following format: command arg1|arg2

The user can use either the arg1 or arg2 variable.

Getting Help ◆

For updated information about this product, including system requirements, supported platforms, supported peripherals, and a list of current patches available from Technical Support, visit our web site: http://support.veritas.com/

◆

VERITAS Customer Support can be reached through email, as follows: [email protected]

xxiv

VERITAS Storage Migrator System Administrator’s Guide for UNIX

1

About VSM

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) Managed file system

VSM server 2

(op and ow methods)

(ct, dt, and mt methods)

Local optical volumes

Local tape volumes

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:

4

◆

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 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 Media Manager

Administrative tools

migd

migin DMAPI interface

Disk

Secondary Storage

VxFS, XFS, or 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: ◆

10

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.

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 Handle: 2C70C0M5BC9 20000 1/1 Medium: 2N512A op.1 1 1

ljgm

filec Mon Dec 17 19:48:23 2001 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.

Is migd active?

Yes

Is VSM state Active? (see page 8)

When it cannot cache a file, VSM returns errno EPFNOSUPPORT to the user system call, which the user will know only if the application reports the errno. In some cases, the process will fail silently.

No File is not cached.

Yes

Is partial caching enabled?

No Entire file is cached

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

Cached data

data accessed by read requests

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

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

Cached data

Configured slice Data accessed by read requests

Neither read request lies entirely within the configured slice that resides on disk

File is partially cached to a point beyond the read request

Read-ahead

Entire darker and lighter shaded area indicates the effective slice that resides on disk

Migrated file

18

Uncached portion of the migrated file (that does not reside on disk)

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

Read-ahead

Cached data

Effective slice

Data accessed by read requests

Neither read request lies entirely within the effective slice that resides on disk

File is partially cached to a point beyond the read request

Migrated File

Entire darker and lighter shaded area indicates the new effective slice that resides on disk 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 system

VSM volume information

Mount request for volume

Media Manager

Volume database

Robotic storage device

Database

Mount request 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 Free space value

Open file system space Free space value Purge mark Low-water mark

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

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

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 migration or command execution

migd detects that free space is below the free space value

Start migbatch

(Calls migarch.sh and then migworker)

Scan file system for files that meet selection criteria

migsweep

Select files and assign file handle

migout migarch.sh

Update IHAND file, file handle, and file name databases

Create work list in workdir

Copy files in work list to secondary storage

migout

migpolicy

migcopy

migworker Update databases to show location of file data

26

migmerge.sh

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 executes the mignospace

miglow command executes

command

If file system open space is low, miglow runs migbatch, then mignospace

mignospace

Is VSM state Active or Maintenance?

No

Exit

migd detects that file system space open for use is less than free space value

Yes

Do purge candidates exist?

Yes

No Cut threshold in half

Select and migrate enough files to bring free space to the low-water mark

Has purge mark been exceeded?

Yes

Remove purge candidates, increasing free space to the purge mark, then exit

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 configured value?

No

Exit. Enough space is available

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 7

Level 8

Level 7

Level 8

Level 5

Move Primary Copy

Level 5

Files cache directly from any level

Level 3

Move Primary Copy

File System

Migrate Primary copy

Primary copy

Move Alternate Tier 3 Copy

Level 6 Move Alternate Copy

Level 3 Level 1

Level 6

Tier 4

Level 4

Tier 2

Level 4 Move Primary Copy

Level 2

Move Alternate Tier 1 Copy

Alternate 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 file system mount point

fspath hsmname

configured name of the 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 /var

/openv /java

(See “Global Configuration File Structure” on page 41)

/hsm

migsa, migfb various NetBackup files

database

bin goodies

admincmd

scripts tools

commands scripts tools migd migvold migrd

commands scripts tools

Chapter 1, About VSM

logs (See “Log files” on page 40)

hsmname workdir

database

See “Files in dwpath” on page 38

See “Files in dwpath” on page 38

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 example

database VSM files: migconfg Template files: migconfg_example

Template files: migd.pid migvold.pid MOTAB volume mount points migd.sid HsmLogLevel migrd.pid

database Template files: FHDB FNDB FHSEQF 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 2LYYY

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

2

Planning VSM Configuration

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:

46

◆

Root (/) or any subdirectory in the root file system

◆

NFS-mounted file systems

◆

Raw disk partitions, including swap partitions

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

58

◆

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)

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

62

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. 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 Primary Level: 1

Primary copy

Tape 3 Stripe

FileB

Primary Level: 1

Primary copy

Tape 1 Stripe

Alternate copy

Tape 3 Stripe

a ern

v Le ate ern Al t

Alt

FileA

l: ve Le te 2

2 el:

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:

64

◆

Size of files

◆

Frequency with which they are accessed or modified

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

18 MB

Primary Level = Optical Disk Stripe

/hsm3

1.8 GB

Alternate Level = Optical Disk Stripe 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 value 10% Purge mark 15%

Free space 11% of disk space is open Premigrated files

Low-water mark 20%

Free space Free space value 10%

Premigrated files

Scheduled migbatch command runs and premigrates files to the low-water mark of 20% free space

4:00 AM to 2:00 PM More file are created

Purge mark 15%

Disk space usage increases

Low-water mark 20%

Free space decreases to 8%

Free space value 10%

Free space

2:00 PM The mignospace command purges files premigrated at 4:00 AM until free space is at the purge mark

Purge mark 15% Premigrated files remain on disk that use the percentage of disk space equal to the difference between the low-water mark (20%) and purge mark (15%). This 5% of disk space is available for instant access should free space be needed quickly.

Low-water mark 20%

2:00 PM to 4:00 AM Free space value 10% Purge mark 15% Low-water mark 20%

Free space

More new files are created Disk space usage increases, but not above the 10% free space configured before migbatch is scheduled to run its daily migration. This pattern indicates that purge marks and low-water marks are set correctly.

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.

Files not migrated, regardless of size, because they are under min_age

File Size

Minimum Age, Minimum Size, and Threshold Values

Files greater than min_age, min_size, and threshold that can be migrated

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

76

Set min_age to at least 1. This prevents VSM from migrating files the same day they were created. 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)

25

20

File Size (in kilobytes)

15

10

5

Files below minimum age for migration

30

0 0

Files greater than min_age and min_size that can be migrated

threshold=3 Files below minimum size for migration 5 10 15 20 25

min_age=1

30

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 Files greater than min_age and min_size that can be migrated when threshold=90

Files below minimum age for migration

250

200

File Size (kilobytes)

150

100

50

Files below minimum size for migration

0 0

50

min_age=3

100

150

200

250

300

File Age (days)

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 below minimum age for

20

15 File Size (in kilobytes)

Files greater than min_age and min_size that can be migrated when threshold=90 (and also when threshold=45)

10

5

A mi dditio gra n ted al fil wh es t en hat thr c es an b ho ld= e 45

t1 t2

0 0

5

min_age=3

10

15

20

25

30

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 site-defined move threshold formula defined?

Yes Use site-defined move threshold formula

No

Are move criteria for migration levels specified in migconf?

No

Use default move threshold formula

Yes Use move threshold formula specified for 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.

84

Complete the “Global Configuration Worksheet” on page 86.

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

86

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

____________________________________

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

Server: ______________

Force registration: _____

Volume directory: ______________ Remote FTP

Add to current stripe:_____

Server: ______________

Schedule: ______________

Policy: ______________

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: _____% Purge Criteria Migration 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

3

VSM-Java Overview 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:

90

◆

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

Non-managed Filesystem Selection

Hierarchy Selections

Level Selections

Managed Filesystem Selections

Stripe Selections

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

4

Configuring VSM 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:

112

◆

Uses default values for database paths and log files

◆

Creates the default two copies of files and migrates both to optical disk

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

5

VSM-Java Tools

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:

152

◆

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

◆

154

The Query database and show files button brings up the Manage redo log files dialog, which lets you change file management.

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:

168

◆

“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

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

170

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.

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

180

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.

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

6

Managing VSM 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:

190

◆

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.

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 02 04 08 10

◆

reloading (not migstage) removing partial cache cached, unmodified 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/dsk/sds6 /dev/dsk/sds0 /dev/dsk/sds1 /dev/dsk/sd3 /dev/dsk/sds6

/dev/rdsk/c1t6d0s1 /dev/rdsk/c1t6d0s6 /dev/rdsk/c1t3d0s0 /dev/rdsk/c1t3d0s1 /dev/rdsk/c1t3d0s3 /dev/rdsk/c1t3d0s6

/hsm2 /hsm3 /db /hsmdb /hsmbig /auspex

vxfs vxfs vxfs vxfs vxfs vxfs

2 2 2 2

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

BOT

VOLn Label

EOV

VOLn label

VOLn label

Media 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

active VOLn label

active

file C

EOV

active

Media FHDB entries FNDB entries

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

VOLn label

file A

file B

file C

obsolete

active

obsolete

EOV

Media FHDB entry

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

dead

active

dead

VOL1 label

EOV

Media FHDB entry

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 VOL2 label

active

active

FHDB entry

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

EOV

Media 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

dead

active

dead

VOL1 label

EOV

Media FHDB entries

VOLDB entry

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

file 1A ad Volume

file 1B

file 1C

EOV

file 1B

EOV

Media

file

migcons mounts the output volume using Media Manager and copies file 1B to VOL2 BOT

VOL2 label

file 2A active

file 2B active

active

Media FHDB entries

VOLDB entry

VOL2 label

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

EOV

Media 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 00000000 <=> 00001007 <=> 00001008 <=>W

LABEL POOL DK0000 AD0001 TP0004

METHOD... dk.0 ... ad.1 ... 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.

218

◆

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.

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

.migrate

.migstop files in /beta/kali/.migstop:

files in /beta/kali/.migrate:

/beta/kali/nomig1 /beta/kali/nomig2 /beta/kali/*proj*/nomig*

/beta/kali/yesmigrate1 /beta/kali/yesmigrate2 /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

220

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

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

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 reserved

reserved

234

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Managing VSM Databases FHDB Entry Description Entry field

Example value

Description

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.

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

reserved reserved reserved

reserved reserved

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

@ indicates a safe pathname with any special characters replaced as necessary to make the path UNIX-readable.

Any other character indicates an invalid path and an FNDB problem.

236

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Managing VSM Databases

Volume Database (VOLDB) The VSM volume database (VOLDB) contains one entry for each registered volume. The first entry is the disk entry (dk entry). It is required. VSM creates subsequent VOLDB entries whenever you register a volume for one of the other methods. VSM updates the database whenever it selects a volume to which it will migrate files and updates the database again when the copy is complete. The copy operation can fail, and VSM may not update some of the fields in the database, but the failure does not cause a problem in VSM. Each volume database entry contains the following fields: handle|machid|lock|flags|label|method|location|metric|date|size| reserved|inuse|files|volset|lt_file|blocks|gid|user|group| project_name|pool_name|server_name|server_user|server_password|

The migreg command redefines three VOLDB fields when registering a NetBackup policy as a volume for the nb method. The location field holds policy_name, the server_user field holds schedule, and the server_password field holds client_name. Note The NetBackup (nb) method will not be supported in the next release of VSM. For optical disk, the lt_file field holds the next byte address available, and the server_password field holds the large sector size flag. The following VOLDB is for an optical disk: 000001086|000E7C03|00000000|00000000|OP003A|op||0|3BB30833|001E4DC0| 0000038A|001E4986|0000046F|00000003|003C915B|0|0||||HSM|||2|

The following table describes the values for each field. VOLDB Entry Description Entry field

Example value

Description

handle

000001086

File handle. Unique file identifier.

machid

000E7C03

Machine ID. Machine identifier of the VSM server.

lock

00000000

Process ID (pid) of the locking process.

Chapter 6, Managing VSM

237

Managing VSM Databases VOLDB Entry Description Entry field

Example value

Description

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

locationa

238

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.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Managing VSM Databases VOLDB Entry Description Entry field

Example value

Description

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.

-

2: supports 512 block, 2048 / 4096 sector size

1: block size unknown; supports 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

Chapter 6, Managing VSM

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.

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

240

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.

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. Currently not used.

dst_seek 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 0000570000000000000 00000000002000001ff 00000034,@tiny/kcm/ d3/f.c

Path name associated with the file. Possible formats follow:

-

% indicates that a DMAPI handle follows

-

If the first character is % and the next nonnumeric characters are ,@ the path is a DMAPI handle followed by a safe path.

@ indicates that a safe path follows (a safe path has any special characters replaced as necessary to make the path UNIX-readable).

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

250

Displays information about a specific VSM file system.

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

A

Man Pages 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 INFO: activated FHDB entry 3E8M13A2 inode ... INFO: activated FHDB entry 3E8M1402 inode INFO: activated FHDB entry 3E8M1403 inode migactivate complete for xi FHDB problems 0, FHDB activates = 100

= 108 = 109 = 205 = 206 =

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

282

◆

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

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) Session (37098) Session (37097) Session (37096) Session (36959)

name: name: name: name: name:

OVT.25719.tar-create OVT.25714.tar-create OVT.25713.tar-create OVT.25712.tar-create 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) Session (37097) Session (37096) Session (36959)

name: name: name: name:

OVT.25714.tar-create OVT.25713.tar-create OVT.25712.tar-create 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:

292

ad

Alternate magnetic disk

ct

Tape

dt

Tape

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

Appendix A, Man Pages

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.

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

302

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

306

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

314

Constant sweeping uses system resources that may adversely affect overall VSM performance, particularly during periods of heavy system usage.

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:

316

◆

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. VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbcheck(1M) ◆

FHDB or FNDB entries which have been flagged obsolete are present for files that still exist. Each migration level is checked.

◆

FHDB or FNDB entries which have been flagged dead are present for files that still exist. Each migration level is checked.

◆

The FHDB or FNDB is not in sorted order.

◆

Duplicate FHDB or FNDB handles exist in the file system.

◆

The FHDB or FNDB sequence number in the FHSEQF file is incorrect.

◆

FHDB or FNDB entries exist that are flagged as locked.

◆

FHDB or FNDB entries exist that are flagged as failed.

◆

There are active dk entries in the FHDB or FNDB but the data is purged.

◆

There are files in the file system whose full pathnames exceed 1024 characters. These files cannot be selected for migration, and may eventually fill the file system.

VOLDB CHECKING The migdbcheck command checks the volume database (VOLDB) in two ways: ◆

It verifies that all files recorded in dwpath/database/FHDB and dwpath/database/FNDB have an associated entry in dwpath/database/VOLDB.

◆

It verifies that all active VOLDB entries are associated with at least one FHDB and FNDB entry.

The migdbcheck command automatically checks all file systems that use the VOLDB specified by hsmname. The following error conditions are detected by migdbcheck: ◆

Active FHDB or FNDB entries exist that reference nonexistent VOLDB entries.

◆

Active VOLDB entries exist for which there are no corresponding FHDB references.

◆

VOLDB entries exist in write mode for which there are no corresponding FHDB references.

OPTIONS -F

Check all entries in the FHDB and FNDB configured for hsmname. This is the default condition if neither -P nor -V is specified.

-P

Check consistency between dk entries and premigrated files. This overrides -F.

-V

Check all entries in the VOLDB configured for hsmname.

-v

Verbose mode; output is directed to standard output as well as to the output files.

Appendix A, Man Pages

317

migdbcheck(1M)

-r

Repair FHDB and FNDB entries. As a precaution, save a copy of the FHDB and FNDB before you alter it. See CAVEATS and EXAMPLES.

Note migdbcheck -r does not repair VOLDB entries. -s

Save the list of migrated files.

-p

Correct all file paths in the FNDB for files that are migrated and copied. The original FNDB is saved in the file dwpath/database/FNDB.OLD.hsmname.pid.

-h

Print help information about this command.

-c number_of_copies Used to override the configured number of copies. This value is used to determine if there are too few or too many copies. See EXAMPLES. hsmname

Name of the VSM managed file system to which the database belongs.

CAVEATS ◆

If migdbcheck is run while the migd migration daemon is active and the VSM state is Active, a warning message tells you that the results of this command may not be correct because of simultaneous migration activity. Nevertheless, VSM gives you an option to continue.

◆

If the -r option is specified, a warning message tells you that the results of this command may not be correct because of simultaneous migration activity. Nevertheless, VSM gives you an option to continue.

◆

If migbatch, miglow, or migmove run simultaneously with migdbcheck, the results of migdbcheck may be in error.

◆

Be sure to analyze very carefully any error messages generated by migdbcheck before taking corrective action. The examples that follow show only a few of the error situations that could arise.

EXAMPLE 1 The following example checks the file system that uses the FHDB and FNDB specified by hsmname alpha. # migdbcheck -F alpha

318

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbcheck(1M)

Typical messages in response to this command are shown below: -- INFO: There are 54 migrated files in the /alpha file system -- INFO: There are 54 migrated files. -- INFO: There are 1302 entries in the FHDB. -- INFO: 2 of the FHDB entries are place holders. -- ERROR: 1 FHDB entries with no file with a matching handle were found. -- INFO: 1 files have the error flag set. -- INFO: 2 files have fewer than 2 copies made. -- INFO: 21 files have more than 2 copies made. -- Extra copies found at level 1 -- Extra copies found at level 2

To repair FHDB entries, set the VSM state to Inactive and specify the -r option in the command: # migdbcheck -F -r alpha

A typical error message in response to this command is shown below: -- ERROR: 1 FHDB entries with no file with a matching handle were found.

You would be prompted as follows: Do you wish to set them inactive?? [aynq](n): Answering a will correct all the entries with no further prompting. Answering y will then lead to a one-by-one listing of the problem entries, as shown below. Answering n or q will move on to the next problem analysis and leave the file migdbcheck-orphan.pid in the /tmp directory. Set handle: 00001000 flags: 00000000 path: alpha/test_foo to inactive? [aynq](n):

Answering a will correct all remaining entries without prompt. Answering y will correct the entry. Answering n will not correct the entry. Answering q will stop processing the list and not correct any more errors. Another response could report extra copies found at different migration levels. -- INFO: 21 files have more than 2 copies made. -- Extra copies found at level 1 -- Extra copies found at level 2

Appendix A, Man Pages

319

migdbcheck(1M)

It is possible to alter the flags field of the FHDB entry for these extra copies using the -i argument of the migsetdb command, but the administrator must first evaluate the files to decide which flags to alter for each level. The files migdbcheck-level-X.hsmname.pid in /tmp are used to indicate the files that exist at each migration level. The character X is replaced by the appropriate migration level, 1 through 8. An error message alerts the administrator when files exist in the file system that can never be migrated because their full pathnames are too long. -- WARNING: Files with path lengths exceeding 1024 were found in the file system.

The following information message indicates that VSM has cached some premigrated files before making any copies: -- INFO: 6 cached files with no active entries in the FHDB were found.

Note If this message continually shows large numbers of files, VSM is selecting too many frequently accessed files for migration. Tune the file threshold formula to be less aggressive. VSM lists all such files in verbose mode. Run migloc on each file so identified. There is no problem if the output resembles the following: # migloc /alpha/raa/7/6/4/4/1/1/2/f0 Status: Cached code raa /alpha/usr1/7/6/4/4/1/1/2/f0 No matching entries found in the FHDB handle: A14C2. Problems getting migration data on file.

The next time the file gets migrated it will get a new handle and be placed in the copydb worklists. EXAMPLE 2 The following example checks the file system that uses the VOLDB specified by hsmname delta. # migdbcheck -V delta

Typical messages in response to this command are shown below: -- INFO: checking hsmname=delta fspath=/delta -- INFO: There are 15 entries in the VOLDB.

If you have just installed VSM and have not registered any volumes using migreg or if no files have been migrated out, the following message appears: -- WARNING: no volumes in VOLDB referenced by FHDB

320

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbcheck(1M)

If an entry is locked by the indicated process, the following message appears. This could occur if you run migdbcheck when VSM is actively being used and the migration daemon (migd) is running. See CAVEATS. -- WARNING: VOLDB entry 00001000 is locked by 4660

VSM maintains the VOLDB in sorted order. If an entry is out of order, the following message error appears: -- ERROR: /usr/var/openv/delta/database/VOLDB is not in the correct order! handle 1000 preceeded 999. You must sort the file and rerun migdbcheck. ABORTING

Use the sort command to put the VOLDB in sorted order. Another typical error message in response to this command is shown below: -- ERROR: Files on missing volid 00001000

To list all such FHDB entries, run migdbcheck in verbose mode. # migdbcheck -Vv delta 00001000|00D86BC0|00000000|0000101A|00000000|00019000| 00000000|00000000|dt|||||l|1 0 00000004|00000000||| 00000000|00000001|

A similar error message is produced by migdbrpt. The FHDB references a volume that is not in the VOLDB. In the example, volume ID 1000 was not in the VOLDB. Following the initial error is a display of the FHDB entries that reference the missing volume. Use this list to determine the specific files that the error affects and take the following actions: 1. If the missing entry exists on a recently backed up VOLDB, you may add that entry to the VOLDB. 2. Run migtscan, migopscan, migadscan, migftscan, or mignbscan on the volume. This creates a file dwpath/database/VOLDB.label. If this file looks reasonable, use an editor to insert this file into dwpath/database/VOLDB. Keep the file dwpath/database/VOLDB sorted with respect to handle and machine ID, which are the first two fields of each line. Rerun migdbcheck to determine the effect of this change. 3. If only a few files are affected, you can restore the user files from the site’s backup tapes and delete the entries from dwpath/database/FHDB. Other typical messages indicate that no file currently references this volume: -- 00000998 in VOLDB, but no FHDB reference to it -- Writing Entry 00000999 in VOLDB, but no FHDB reference to it

Appendix A, Man Pages

321

migdbcheck(1M)

This is normal if all of the files on the volumes have been cached or removed. Registered but unwritten volumes do not appear in this list. The first message indicates the writing flag is not set for the VOLDB entry; the second message indicates the writing flag is set for the VOLDB entry. To list all such VOLDB entries for these volumes, run migdbcheck in verbose mode. # migdbcheck -Vv delta 0998|00d86BC0|00000000|00000000|A00001|dt||0|3BA73139| 0230000| 0122466F|00E700019|0007a9e8|0||||HSM||| |

These volumes are good candidates for consolidation and reuse (see migcons(1M)). Before consolidating the second volume, run migdbcheck clear the write flag in its VOLDB flags field. # migsetdb -Va delta A00001

EXAMPLE 3 The following example use the -c option to determine if the correct number of copies are being made. The configuration of managed file system omikron set the number of copies to be 1. In the example, the -F option requests that both the FNDB and FHDB are checked. The -c option queries if 2 copies of any files are being made: # migdbcheck -F -c 2 xi

Typical messages in response to the command follow: -- INFO: checking hsmname=omikron fspath=/omikron -- INFO: There are 4 entries in the FHDB. -- INFO: 1 of the FHDB entries are place holders. -- INFO: There are no valid active dk entries in the FHDB. -- INFO: There are 1 migrated files in the /omikron file system -- ERROR: 1 files have fewer than 2 copies made and are not found in a copydb.

The messages tell you that there is one migrated file in omikron, that it has fewer than 2 copies made, and that is not in a worklist file waiting to be copied for a second time. The configuration is working as configured, because only one copy should be made. FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

322

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbcheck(1M)

File handle database dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database dwpath/database/FHSEQF

File handle sequence number file dwpath/database/VOLSEQF

Volume ID sequence number file dwpath/database/migconf

Configuration file for managed file systems dwpath/database/FNDB.OLD.hsmname.pid

After migdbcheck corrects paths of all migrated and copied files, this path holds the original FNDB from before the corrections were made. dwpath/workdir

VSM work directory /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server dwpath/database/hsmname.IHAND

VSM inode-to-handle file /tmp/migdbcheck-migratedfiles.hsmname.pid

List FHDB inconsistencies discovered /tmp/migdbcheck-movedfiles.hsmname.pid

List of all migrated copied files that have a path that is different than the path in the FNDB. /tmp/migdbcheck-obsolete.hsmname.pid

A list of FHDB entries other than dk entries that are obsolete or dead but the files exist as migrated files in the file system /tmp/migdbcheck-orphan.hsmname.pid

A list of migrated files that have an entry in the FHDB but the files do not exist /tmp/migdbcheck-dk-orphan.hsmname.pid

Appendix A, Man Pages

323

migdbcheck(1M)

A list of files that have an active dk entry in the FHDB but the files either do not exist or are not migrated (data not on disk) /tmp/migdbcheck-missing.hsmname.pid

A list of migrated files that do not have enough entries in the FHDB /tmp/migdbcheck-dup-handles.hsmname.pid

A list of migrated files with duplicate FHDB handles /tmp/migdbcheck-no-fhdb.hsmname.pid

A list of migrated files that do not have any entries in the FHDB /tmp/migdbcheck-cached.hsmname.pid

A list of cached files that do not have any entries in the FHDB because they were cached before any copies were made /tmp/migdbcheck-copies-needed.hsmname.pid

A list of files that do not have the required number of migrated copies /tmp/migdbcheck-error-flag.hsmname.pid

A list of files whose FHDB entry contains an error flag that is either locked or failed /tmp/migdbcheck-level-X.hsmname.pid where 1<= X <= 8

A list of files that exist at migration level X, where X represents migration levels 1 through 8, and there are more valid copies found than defined in migconf The following output files are created and used by migdbcheck to list VOLDB inconsistencies discovered: /tmp/migdbcheck-voldb-missing.hsmname.pid

A list of volumes in the FHDB that are not in the VOLDB. Verbose mode lists FHDB entries residing on the missing volumes. /tmp/migdbcheck-voldb-consolidate.hsmname.pid

A list of volumes in the VOLDB with no FHDB references. Verbose mode lists VOLDB entries for these volumes. /tmp/migdbcheck-voldb-writing.hsmname.pid

A list of volumes in the VOLDB that are in write mode with no FHDB references. Verbose mode lists VOLDB entries for these volumes. The migdbcheck command checks the environment variable TMPDIR, which allows the administrator to use a path other than the default /tmp. This can save files through system reboots or make use of a larger file system to avoid running out of space. The path defined by TMPDIR, if set, is used instead of /tmp as the directory in which to place any temporary files. The process id of the migdbcheck that is executing replaces pid. 324

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbcheck(1M)

Files which could indicate problems or which could be used to obsolete or activate FHDB or VOLDB entries are left in /tmp (or the path defined by TMPDIR). No output files should be left if migdbcheck executes successfully and finds no errors. Note Some output files created by migdbcheck may be used as input files for migsetdb. SEE ALSO migadscan(1M), migbatch(1M), migconfg(1M), migcons(1M), migdbrpt(1M), migftscan(1M), miglow(1M), mignbscan(1M), mignospace(1M), migtscan(1M), migopscan(1M), migrc(1M), migsetdb(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)

Appendix A, Man Pages

325

migdbconvert(1M)

migdbconvert(1M) NAME migdbconvert - convert FHDB into VSM 4.5 formatted FHDB and an FNDB SYNOPSIS /usr/openv/hsm/bin/migdbconvert [-b backupdir] hsmname DESCRIPTION The migdbconvert command converts VSM file databases from releases before 4.5 to VSM release 4.5 format. The file handle database (FHDB) is a text database file in the database directory for each managed file system. In VSM release 4.5, a file name database (FNDB) also exists in the database directory. You must have a properly formatted FHDB and a FNDB for VSM release 4.5. Unless the conversion is run by the VSM installation script, the managed file system being converted must be in Maintenance state. The migdbconvert command first checks to see if the current FHDB for hsmname appears to be in VSM 4.5 format. If it is, migdbconvert exits with exit status 0. If you use the -b option to specify a backup directory, the original (pre-version 4.5) FHDB is moved to backupdir/hsmname.FHDB.prev. This is done before the conversion begins. If you do not use the -b option to specify a different directory, the original (pre-version 4.5) FHDB remains in the database directory while the new FHDB and FNDB files are written. After the new files are created, the original FHDB is renamed FHDB.prev. Not specifying the -b option requires more space in the VSM database directory. You will need enough space to hold the both the old and new databases. OPTIONS -b backupdir Specifies a directory to be used for the backup copy of the FHDB. hsmname

Specifies the managed file system (hierarchy) name.

EXAMPLE The following example shows the syntax for converting the database for hsmname xi. The backup copy of the FHDB is created in the directory /conversion/theta. # /usr/openv/hsm/bin/migdbconvert -b /conversion/xi xi

SEE ALSO VSM(1) 326

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbdir(1M)

migdbdir(1M) NAME migdbdir - get VSM information from the global configuration file SYNOPSIS /usr/openv/hsm/bin/migdbdir hsmname id DESCRIPTION The migdbdir command prints the desired value or device for the specified hsmname on standard output. The id specifies the desired information. OPTIONS hsmname

Configured name of the managed file system about which to query.

id

Integer identifying the desired information. Accepted values follow: 1 - Database path (dwpath) 2 - File system path (fspath) Requires that file system by mounted. 3 - Log file path (lgpath) 4 - VSM state flag (state; the value in migconfg) 5 - File system device number 6 - Mounted status 7 - Mount point 8 - migattr driver status. Returns yes or not based on the working status of the migattr driver (Solaris only)

EXAMPLES The following example prints the device number of the managed file system delta. # migdbdir delta 5 33554455

The following example prints whether or not the theta file system is mounted correctly. In this case, it is not mounted correctly. # migdbdir theta 6 not mounted

SEE ALSO migconfg(1M)

Appendix A, Man Pages

327

migdbrpt(1M)

migdbrpt(1M) NAME migdbrpt - report on VSM migration database SYNOPSIS /usr/openv/hsm/bin/migdbrpt [-g] -f file_path hsmname /usr/openv/hsm/bin/migdbrpt [-g] -h file_handle | -H hsmname /usr/openv/hsm/bin/migdbrpt [-g] -l label | -a hsmname /usr/openv/hsm/bin/migdbrpt [-g] -m method | -a hsmname /usr/openv/hsm/bin/migdbrpt [-g] -s vol_set hsmname /usr/openv/hsm/bin/migdbrpt [-g] -v vol_handle hsmname DESCRIPTION The migdbrpt command prints reports on database information maintained by VSM. Preserving periodic migdbrpt reports helps trace volumes for important files and make decisions on volume consolidation. The system administrator can issue migdbrpt at any time. You can base enquiries about files on the following: ◆

file_path (-f option)

◆

file_handle (-h option) that VSM assigns to the file during the migration phase

The -H option displays information about all migrated files. The displayed information includes where the file is migrated, as well as the number of granules and the percentage of volume capacity for the file. You can base inquiries about volumes on the following: ◆

Volume label (-l option)

◆

Method name (-m option)

◆

Volume set (-s option)

◆

Volume handle (-v option) that VSM assigns when the volume is registered with migreg

The -a option reports on all volumes. migdbrpt displays the percentage of the volume in use and the number of both live and obsolete granules on the volume. This information is useful in making decisions on consolidating volumes (see migcons(1M)). All numbers are displayed in decimal.

328

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbrpt(1M)

The migdbrpt command also displays database entries that have duplicate file handles or duplicate volume handles. If a report indicates possible problems, use migdbcheck to verify the databases. Correct any database inconsistency immediately to guard against future catastrophe. OPTIONS -g

Prints granule-related information. You can use this parameter with any of the other options.

-f file_path Reports on the file with the specified file path. The file path must be specified with the full path. -h file_handle Reports on the file with the specified file handle (specify the file handle in hexadecimal). -H

Reports on all migrated files.

-l label

Reports on the volume with the specified label. You can use this option with the -m option to report on all volumes under a given method and label pair.

-m method Reports on all volumes registered under the specified method. -a

Reports on all volumes registered.

-s vol_set Reports on all volumes registered under the specified volume set. You can use this option with the -m option to report on all volumes under a given method and volume set pair. -v vol_handle Reports on the volume with the specified volume handle (specify the volume handle in hexadecimal). hsmname

Configured VSM name for the managed file system containing the database files from which you want to derive the report.

EXAMPLE 1 The following example prints information about the /home/pjt/f1 file. Information is displayed about what volumes the file resides on, as well as its granule count and what percentage of the volume is occupied by this file. # migdbrpt -g -f /home/pjt/f1 alpha

Appendix A, Man Pages

329

migdbrpt(1M)

The command results in a display similar to the following: FILE_HAND VOL_HAND METHOD FIL_SIZE OFFSET GRN_SIZE 0009C2EA 00000000 dk 0072C668 00000000 0072C668 L 0009C2EA * 00001004 dt 0072C668 00000000 00200000 0009C2EA * 00001004 dt 0072C668 00200000 00200000 0009C2EA * 00001004 dt 0072C668 00400000 00200000 0009C2EA * 00001004 dt 0072C668 00600000 0012C668 VOL_HAND 00000000 <=> 00001003 <=>C 00001004 <=>W

LABEL POOL METHOD DK0000 dk.0 VLS001 HSM dt.1 VLS001 HSM op.1

F 0 L L L L

GRN# SEEKINFO FI. 00000000 /home... 4980 00000000 ... 4980 00000041 ... 4980 00000082 ... 4980 000000C3 ...

CAPACITY #LGNS #OGNS GRAN_USE... 17483290624 6... 293601280 114... 375896384 57...

The columns in this display have the following meanings: FILE_HAND File handle for the file, followed by an asterisk (*) if locked. VOL_HAND Handle assigned to the volume and referenced by entries in FHDB. <*>

Indicates this volume is currently locked for use

W

Current volume to be written

<=>

Indicates the volume has been written (if not followed by a letter)

C

volume is corrupt- this volume will not be read or written

D

Indicates a dead volum

E

Indicates an empty volume

f

Do not write to this volume

F

Volume needs to be force labeled

L

Volume needs to be labeled

T

Volume needs a trailer label added or the volume is actually being written

METHOD

Method name. Valid values are ct, dt, mt, op, ow, ad, ft, nb, and dk. In some displays the volume set number is also shown.

FILE_SIZE Size of the file (hexadecimal). OFFSET

Offset from the beginning of the file for each granule.

GRN_SIZE Size of each granule in the file.

330

F

File status: O for obsolete; L for active.

GRN#

The number of the file on the media. VERITAS Storage Migrator System Administrator’s Guide for UNIX

migdbrpt(1M)

SEEKINFO Seek information for the file. FILE_PATH File path name. LABEL

Label specified when this volume was registered.

POOL

Name of the volume pool for this volume.

#LGNS

Total number of active granules on the volume. VSM derives this value from a scan of the FHDB.

#OGNS

Total number of obsolete granules on the volume. VSM derives this value from a scan of the FHDB.

GRAN_USE Space used on the volume, in bytes. PERCENT

Percentage of space used on the volume. Anything over 86% may be full. If drivers compress the data before writing it to a volume, however, PERCENT could exceed 100 and the volume may still not be full.

LOC

Path to the registered directory. This applies to methods ad, and ft.

SERVER

Server name.

USER

User name (root).

EXAMPLE 2 The following example prints a report on all volumes registered under the configured methods. # migdbrpt -a alpha

The command results in a display similar to the following (this example has been truncated on the right): VOL_HAND 00001000 00001009 00000000 00001001

<*>W <=>C <=> <=>E

LABEL OPT01A TST003 DK0000 OPT01B

POOL METHOD CAPACITY HSM op.1 375896384 HSM dt.1 293601280 dk.0 17483290624 HSM op.1 293601280

#LGNS... 572... 1140... 6083... 0...

EXAMPLE 3 The following example prints information about volume rao001 under method ct. The display will include information about the migrated files, their granule count, and the volume occupancy. # migdbrpt -g -l rao001 -m ct alpha

Appendix A, Man Pages

331

migdbrpt(1M)

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/migconf

Configuration file for managed file systems dwpath/database/FHDB

File handle database for migrated files dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server SEE ALSO migdbcheck(1M), migadscan(1M), migconf(1M), migconfg(1M), migcons(1M), migreg(1M), migtscan(1M), migopscan(1M)

332

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migfind(1M)

migfind(1M) NAME migfind - determine the full pathname of a file SYNOPSIS /usr/openv/hsm/bin/migfind -h file_handle -m machid hsmname /usr/openv/hsm/bin/migfind -d DMAPI_handle hsmname DESCRIPTION The migfind command determines the full pathname of a file, given either its VSM file handle and machine ID or its DMAPI handle. Output is displayed to standard output. Error messages go to standard error. This command may be run without regard to the VSM state or whether the migd migration daemon is running, but the managed file system must be mounted. OPTIONS -h file_handle The VSM file handle of the file. File handles are stored in the file handle database (FHDB) for the file system. -d DMAPI_handle The DMAPI file handle of the file. -m machid The integer (nonzero) identifier for the VSM-managed file system from which the file was migrated, as configured with the machid parameter in the DEFAULTS section of the dwpath/migconf file. hsmname

Configured VSM name that specifies the file system in which the file resides.

EXAMPLE The following command determines the full path of a file in hsmname beta whose VSM file handle is 1f29 and machine id is 3e8. # /usr/openv/hsm/bin/migfind -h 1f29 -m 3e8 beta /beta/acg/acg1

Appendix A, Man Pages

333

migfind(1M)

Identical results are achieved by using the DMAPI handle of the file, as follows (this command uses a UNIX continuation character; it is meant to be entered on one line). # /usr/openv/hsm/bin/migfind -d 00000000008000\ a90000000600000000000000000000001a0000010070c00080 beta /beta/acg/acg1

The following output shows the full path of a file in hsmname beta whose VSM file handle is 25c1 and machine id is 3e8, but reports that no FHDB entry exists for this file. # /usr/openv/hsm/bin/migfind -h 25c1 -m 3e8 beta INFO: No FHDB entries exist /beta/acg/acg33

The following output reports that neither the FHDB entry nor the file exist for VSM file handle 25c1 in hsmname beta and machine id 3e9. # /usr/openv/hsm/bin/migfind -h 25c1 -m 3e8 beta INFO: No FHDB entries exist No such file

The following output reports that the file with the specified DMAPI handle does not exist in hsmname beta (this command uses a UNIX continuation character; it is meant to be entered on one line). # /usr/openv/hsm/bin/migfind -d 00000000008000\ a90000000300000000000000000000001a0000010070c00090 beta No such file

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM SEE ALSO VSM(1M)

334

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migftscan(1M)

migftscan(1M) NAME migftscan - scan ft volume and reconstruct database entries for the ft storage method. SYNOPSIS /usr/openv/hsm/bin/migftscan [-F] [-n] [-s] hsmname label [server_name server_path [user]] DESCRIPTION The migftscan command scans a remote file system and displays information about the volume as a whole as well as information about each file granule on the volume. It also reconstructs the FHDB, FNDB, and VOLDB entries for all scanned granules. The remote disk volumes are registered by using the migreg command before they can be used as archive media. A file is migrated to a remote file system as a single granule. The granule header is separately archived in the remote file system as a file. The granule header contains FHDB, FNDB, and VOLDB entry information. The migftscan command creates three output files: FHDB.label, FNDB.label and VOLDB.label, in the dwpath/database directory. The structure of these files is the same as the FHDB, FNDB, and VOLDB database files. These files may be used to rebuild the FHDB, FNDB, and VOLDB if they are corrupted or damaged (see migdbcheck(1M)). Sorting and merging of FHDB.label files or FNDB.label files for different remote file systems can be used to recreate the FHDB and the FNDB. Similarly, merging multiple VOLDB.label files for different remote file systems can be used to recreate the VOLDB database. Note When you recreate the VOLDB, ensure that you merge the VOLDB file (in the directory /usr/var/openv/hsm/example/database) to include the entry for the dk method. OPTIONS The following parameters are available: -F

Appendix A, Man Pages

Force scan the volume for granules in case the volume identity is not in the volume database (VOLDB). This parameter is optional. If omitted, the volume must be registered in the volume database. If specified, the optional parameters server_name server_path user must also be supplied. A password prompt is issued.

335

migftscan(1M)

-n

Do not compress the FHDB entries for files found on the volume. When the -n option is used, no FNDB.label file is produced. This option is useful for examining what is actually written on the media. The FHDB.label file produced with the -n option must be run through migfdbconvert before it can be merged into the real FHDB and FNDB.

-s

Silently scan the volume and create FHDB.label and VOLDB.label files, but do not display information on stdout.

hsmname

Configured VSM name for the managed file system containing the database that has information on the desired volume.

label

Remote-file-system volume label used when registering the volume. This parameter is required. For a force scan, you may specify label as anything.

server_name Name of the remote volume server. This can be the internet id or number. VSM uses this name on the ftp open command as the host parameter. It must be a valid ftp host. This parameter is required when you specify -F. server_path Path of the file system on the remote volume server. This parameter is required when you specify -F. user

User name used for the ftp login request when VSM migrates or caches files from the remote volume server. If you do not specify user, then root is assumed. This parameter is required when you specify -F.

CAVEATS ◆

Only the system administrator may use this command.

◆

The remote volume server file system must be available via ftp for this command.

◆

migftscan performance depends on the number of files and FTP performance.

EXAMPLE The following example scans the archive disk volume FT005 that uses the ad method. The display shows a list of granule information for files archived on the volume. Files FHDB.FT005 and VOLDB.FT005 are created in the dwpath/database directory. # migftscan openv2 FT0005 VOLUME FT0005 registered to HSM Volume Particulars -----------------000003E8V000010AF FT0005 ft 00000B71 00000883 #31 Volume label Found ====> hare:FT0005 ---------------- /usr/home/acg/ft_stor1/3E8M122D.1.

336

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migftscan(1M)

0.GLABEL <=> 0000000000100000000 Thu Apr 26 13:09:40 2001 /sd7/ov2fs/b1f2 /usr/home/acg/ft_stor1/3E8M1231.1.0.GLABEL <=> 0000 1036 00000000 Thu Apr 26 13:09:41 2001 /sd7/ov2fs/f1.c /usr/home/acg/ft_stor1/3E8M1235.1.0.GLABEL <=> 0007 60000 0000000 Thu Apr 26 13:09:42 2001 /sd7/ov2fs/f1.x /usr/home/acg/ft_stor1/3E8M1239.1.0.GLABEL <=> 00000 F3B 00000000 Thu Apr 26 13:09:44 2001 /sd7/ov2fs/f2.sh /usr/home/acg/ft_stor1/3E8M123D.1.0.GLABEL <=> 000018 8E 00000000 Thu Apr 26 13:09:45 2001 /sd7/ov2fs/f3.rcs /usr/home/acg/ft_stor1/3E8M1241.1.0.GLABEL <=> 0000 565C 00000000 Thu Apr 26 13:09:47 2001 /sd7/ov2fs/f4.o /usr/home/acg/ft_stor1/3E8M1245.1.0.GLABEL <=> 0000 1036 00000000 Thu Apr 26 13:09:48 2001 /sd7/ov2fs/f5.c ... /usr/home/acg/ft_stor1/3E8M1276.1.0.GLABEL <=> 0000 2000 00000000 Thu Apr 26 13:10:07 2001 /sd7/ov2fs/k8f8 /usr/home/acg/ft_stor1/3E8M127A.1.0.GLABEL <=> 0000 1000 00000000 Thu Apr 26 13:10:08 2001 /sd7/ov2fs/kef4 /usr/home/acg/ft_stor1/3E8M1283.1.0.GLABEL <=> 000045 92 00000000 Thu Apr 26 13:10:12 2001 /sd7/ov2fs/nrof.3 /usr/home/acg/ft_stor1/3E8M1287.1.0.GLABEL <=> 0000 2000 00000000 Thu Apr 26 13:12:52 2001 /sd7/ov2fs/k8f2

Volume particulars are displayed in the following order: ◆

volume handle

◆

volume label

◆

method

◆

total capacity of the volume

◆

total space in use on the volume

◆

number of granules on the volume

Particulars of granules are displayed in the following order: ◆

granule file name

◆

migrated file size

Appendix A, Man Pages

337

migftscan(1M) ◆

offset of the granule in the migrated file

◆

date of archiving the granule

◆

migrated file pathname

FILES The dwpath is a directory in each managed file system that holds the database directory. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database for VSM dwpath/database/migconf

Configuration file for VSM dwpath/database/FHDB.label

File handle database for current volume dwpath/database/FNDB.label

File name database for current volume dwpath/database/VOLDB.label

Volume database for current volume server_name:/server_path

File system on the server SEE ALSO migdbcheck(1M), migconf(1M), migconfg(1M), migdbrpt(1M), migreg(1M), migadscan(1M), mignbscan(1M), migtscan(1M), migopscan(1M)

338

VERITAS Storage Migrator System Administrator’s Guide for UNIX

miggetvol(1M)

miggetvol(1M) NAME miggetvol - print a list of VSM volumes on stdout by method name in ascending order of percentage utilization SYNOPSIS /usr/openv/hsm/bin/miggetvol hsmname [method] DESCRIPTION The miggetvol command prints a list of volumes registered under the specified method. This list is sorted by method name in ascending order according to the percentage of space used on the volumes. The total size of files currently migrated to the volume determines space used on the volume. The entries in the list include the following: label method empty gran_count obsolete_gran percent_use% volume_set date_last_written

You can use miggetvol to monitor volume usage, such as required in determining when to consolidate volumes. The migselect command uses miggetvol for selection of volumes to consolidate. You must have superuser (root) privileges to use miggetvol. OPTIONS -q

Prints the command output without column headers. The default is to print the column headers. See EXAMPLES.

hsmname

Configured VSM name for the managed file system containing the database files from which you want to derive the report.

method

Method name under which miggetvol is to return information. By default, volumes under all methods are returned.

CAVEATS ◆

miggetvol does not consider granule space overhead on the volume in arriving at volume occupancy.

Appendix A, Man Pages

339

miggetvol(1M)

EXAMPLE The following command prints a list of volumes on the managed file system hsm1. # miggetvol hsm1 LABEL METHOD FLAGS GRAN_CNT OBS_GRANS C102A nb W 33 26 E102B op E 0 0 E102A op W 33 57 DK0000 dk 31 0 2N512A op 0 13 2N512B op 0 0

USE 0.00 0.00 4.46 0.00 0.00 0.00

% % % % % %

VOLSET 1 1 1 0 1 1

LAST_WRITTEN Mon Jan 14... Tue Jan 15... Wed Jan 23... Wed Dec 31... Tue Jan 15... Mon Jan 14...

A W in the third column indicates writing. E indicates empty, D indicates dead, and the minus sign (-) is a place-holder indicating none of the above. If you are using this command in a script and want to omit the column headers, you invoke it with the -q option, as follows: miggetvol -q hsm1

The output for the script would be as follows: C102A E102B E102A DK0000 2N512A 2N512B

nb op op dk op op

W E W -

33 0 33 31 0 0

26 0 57 0 13 0

0.00 0.00 4.46 0.00 0.00 0.00

% % % % % %

1 1 1 0 1 1

Mon Tue Wed Wed Tue Mon

Jan Jan Jan Dec Jan Jan

14... 15... 23... 31... 15... 14...

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/VOLDB

Volume database for VSM dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server SEE ALSO migconfg(1M), migcons(1M), migdbrpt(1M), migselect(1M) 340

VERITAS Storage Migrator System Administrator’s Guide for UNIX

miggroup(1), migungroup(1)

miggroup(1), migungroup(1) NAME miggroup, migungroup - group files for migration and caching SYNOPSIS /usr/openv/hsm/bin/miggroup [-d] [-M] [-P] dir /usr/openv/hsm/bin/miggroup -l [-v] dir /usr/openv/hsm/bin/miggroup -u dir /usr/openv/hsm/bin/migungroup dir DESCRIPTION The miggroup and migungroup commands let users premigrate and group all of the files in a directory and all of its subdirectories in VSM-managed file systems. Users with root privilege can group directories owned by any user. Other users can group their own regular directories if allowed to use this command. For nonroot users, the miggroup and migungroup perform only the premigration phase of migration. Optionally, users can also purge copied files. The files in a grouped directory do not actually migrate to secondary storage until the next time mignospace, migbatch, migrc -R, or miglow execute. Users with root privilege can also optionally copy and purge premigrated files in a grouped directory. Grouping causes files to be added to a tie group, MigGroup, as key caching files so they will be cached together when any one file in the group is cached. Files listed in global and local stop files are not included in the group. Use the -l option to determine if a directory has been grouped, and to see the status of the files in that directory. Adding the -v option gives the status of each file in the directory. If many files in the directory are already migrated, they may reside on multiple volumes. This means the directory is fragmented. The -d option will defragment the directory by caching migrated files before grouping the directory. After a grouped directory is migrated to secondary storage, accessing any purged file in the group causes VSM to transparently cache all of the files in the group back to disk. De-fragmenting a directory will cache and re-migrate previously migrated data to a minimal number of tapes, which reduces the mount time whenever the directory is cached. Directory grouping is not dynamic. If files are created in a grouped directory, removed from the directory, or moved in or out of the directory, the grouping remains the same. It is good practice, therefore, to group active directories periodically.

Appendix A, Man Pages

341

miggroup(1), migungroup(1)

Normal file selection criteria are not applicable to miggroup, but normal VSM rules apply to files that have not been grouped in grouped directories, and these files continue to be selected, migrated, and cached individually. The VSM state must be Active and the migration daemon migd must be running when you issue a miggroup command Users can ungroup a grouped directory using either the migungroup command or miggroup with the -u option. OPTIONS -d

Defragment the directory. If specified, all migrated files in the directory are cached and their FHDB entries are marked obsolete before the directory is grouped. If not specified (default), all migrated files in the directory remain migrated, and the directory is grouped. In either case, files not previously grouped are included in the grouped directory.

-M

Run migbatch to make copies of the grouped premigrated files. Available only to users with root privilege, and generates an error message if used by nonroot users. If the directory is not yet grouped, this option groups the directory.

-P

Purge copied files in the directory. If the directory is not yet grouped, using miggroup -P or migungroup -P groups the directory.

-l

List the status of a directory without grouping the directory. When the -l option is used, only one offline volume is displayed. If VSM has multiple file copies, the volume displayed is the copy that can be most quickly cached.

-v

Generate a verbose list showing the status of a directory. Must be used with the -l option.

-u

Ungroup a previously grouped directory. Previously grouped migrated files are cached individually if accessed.

dir

Path of the directory to group (relative or absolute).

CAVEATS

342

◆

By their very nature, grouped directories can increase migration and caching activity unnecessarily if used in situations where files are used individually. Group and migrate directories only where applicable.

◆

Files created in or moved to a grouped directory are not added to the group until the grouped directory is grouped again. Until they are added to the group, the grouped behavior of these files when cached is undefined.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

miggroup(1), migungroup(1) ◆

Files moved out of a grouped directory remain in the directory group. The behavior of these files when cached is undefined.

◆

Unless specifying the -l option, the directory is grouped again each time miggroup is executed.

◆

The tie group name MigGroup is reserved for miggroup. Using this name for other uses may cause unpredictable behavior. Also using migtie and miggroup on the same directory and files will cause unpredictable results.

◆

Making changes to a directory while miggroup is processing the directory may produce unpredictable behavior. Do not access migrated files, add files, or remove files in the directory being processed by miggroup.

◆

Grouping and de-fragmenting a directory does not guarantee that all grouped files will migrate together. Other migration activity in the same file system may cause other files to get intermingled with the grouped files on the same media.

◆

Running two miggroup commands on the same directory at the same time may produce undefined results.

◆

Moving grouped directories or files will cause unpredictable behavior. It is best not to group directories that will be subject to moving.

◆

De-fragmenting a directory requires disk space to cache migrated files from secondary storage. If this space is not available the de-fragmenting operation will fail. If the operation fails, create space on disk and try again. A partially completed operation to defragment a disk may leave unnecessary data from migrated files on disk.

◆

If a migrated and purged file in a grouped directory is truncated to size zero, the migration daemon migd does not cache the file, nor does it cache any of the other files in the grouped directory.

◆

Files whose pathname length exceeds 1023 characters will not be migrated.

EXAMPLES In the following example, the user requests that VSM group and premigrate all of the files in directory project123 without first de-fragmenting that directory. # miggroup /home/abc/project123

In the following example, the user defragments directory project123 before grouping and pre-migrating all of the files in that directory. # miggroup -d /home/abc/project123

If the user has root privilege, the following command defragments directory project123 before grouping, migrating, and purging all of the files in that directory. # miggroup -d -MP /home/abc/project123

Appendix A, Man Pages

343

miggroup(1), migungroup(1)

The following command uses an absolute pathname to list the number of volumes holding data for the grouped files in the project123 directory. # miggroup -l /home/abc/project123 Regular 3 files 0.046080 MB Grouped 9 files 0.101412 MB Not Grouped 3 files 0.046080 MB Migrated/Grouped files are on 1 volume.

The following command uses a relative pathname to list the number of volumes holding data for the grouped files in the project123 directory. # miggroup -l project123 Regular 3 files 0.046080 MB Grouped 9 files 0.101412 MB Not Grouped 3 files 0.046080 MB Migrated/Grouped files are on 1 volume.

The following command gives a more detailed status of directory project123 by listing the number of volumes holding data for the grouped files in that directory on a file-by-file basis. Grouped files in subdirectories are also shown. # miggroup -lv /home/abc/project123 Regular 3 files 0.046080 MB Grouped 9 files 0.101412 MB Not Grouped 3 files 0.046080 MB Migrated/Grouped files are on 1 volume. Not Yet Copied 3 files 0.046080 MB State Size File m-15360 dir1/f4 m-15360 d1/d1/d3/d4/d5/d6/f4 m-15360 f4 Volume CT0001 9 files 0.101412 MB State Size File mg11268 f1 mgt 11268 f2 mg11268 f3 mg11268 dir1/f1 mgt 11268 dir1/f2 mg11268 dir1/f3 mg11268 d1/d1/d3/d4/d5/d6/f1 mgt 11268 d1/d1/d3/d4/d5/d6/f2 mg11268 d1/d1/d3/d4/d5/d6/f3

344

VERITAS Storage Migrator System Administrator’s Guide for UNIX

miggroup(1), migungroup(1)

Either of the following two commands will ungroup directory project123. # miggroup -u /home/abc/project123 # migungroup /home/abc/project123

FILES /usr/var/openv/hsm/database/migstop Global stop file for VSM. SEE ALSO VSM(1M), migbatch(1M), migpurge(1), migrate(1), migsetdb(1M), migstage(1), migtie(1)

Appendix A, Man Pages

345

migin(1M)

migin(1M) NAME migin - cache a file from secondary storage to disk SYNOPSIS /usr/openv/hsm/bin/migin [-c] hsmname file_system machid file_handle DESCRIPTION The migin command caches a file in that has been removed or lost and therefore cannot be cached simply by accessing it. This command is useful in recovering files that were migrated or cached and then perhaps accidentally deleted. The file is cached to the original location as a regular file. It is possible to recover the file only if an FHDB entry exists for a copy of the file on secondary storage. VSM automatically removes obsolete entries from the FHDB after 7 days. This process does not restore original file ownership or mode bits. This command may be run without regard to whether the migration daemon migd is running, but the VSM state must be Active or Maintenance. OPTIONS -c

Specifes that migstage ignores checksum (crc) errors when caching files. Normally, when caching a file from tape the cache operation fails if the crc computed from the data does not match the crc in the granule header. When -c is specified, the cache operation succeeds even if the crc check fails. This option is intended to be used only as a last resort when a file cannot be recovered the usual way. The file data cached back with the -c option may not be the original file data.

hsmname

Name of the managed file sytem that is controlling migrations for the file system in which the file you are recovering resided, as configured with the hsmname parameter in the /usr/var/openv/hsm/database/migconfg file.

file_system Path to the file system that contained the file, as configured with the fspath parameter in the /usr/var/openv/hsm/database/migconfg file.

346

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migin(1M)

machid

The integer (nonzero) identifier for the VSM-managed file system from which the file was migrated, as configured with the machid parameter in the DEFAULTS section of the dwpath/migconf file.

file_handle File handle of the file you are recovering, as recorded in the FHDB. CAVEATS ◆

If a file has been designated as a key caching file by the migtie command, caching that file manually with migin will not cause all migrated files in the associated group to be cached as well.

◆

If a file has been included in a grouped directory by the miggroup command, caching that file manually with migin will not cause all migrated files in the grouped directory to be cached as well.

◆

If both a file and its directory have been removed, migin will not cache the file until you have made a new directory with its full path to replace the original directory.

◆

Manual migin is not intended to be used on existing files. If migin is used on an existing purged file, the command restores the data and leaves the file in a purged state.

EXAMPLE Assume you run migdbcheck and find that a file handle exists for a file that is not in the file system. Upon further checking you discover that you need this file. The file resided in the /project1 file system, was migrated by the managed file system zeta, the machine ID for the host is 3e8, and the file handle is 12d2. You execute the following: # migin zeta /project1 3e8 12d2

The command restores the file to its original pathname as a regular, unmigrated file. FILES /usr/var/openv/hsm/database/migconfg Global configuration file for the VSM server dwpath/database/migconf Configuration file for managed file systems SEE ALSO migdbcheck(1M), migconf(1M), migconfg(1M), migreconstruct(1M), migpurge(1), migtie(1)

Appendix A, Man Pages

347

miglicense(1M)

miglicense(1M) NAME miglicense - displays the current license capacity of VSM SYNOPSIS /usr/openv/hsm/bin/miglicense /usr/openv/hsm/bin/miglicense -l [-v] /usr/openv/hsm/bin/miglicense -u [-f] /usr/openv/hsm/bin/miglicense -a | -d textofkey DESCRIPTION The miglicense command determines the current license capacity of VSM. If used without options, miglicense displays the total valid capacity under license. The -l option displays an itemized list of each VSM license key including both valid and invalid keys. You can compare the licensed capacity with the actual current capacity used on storage media by using the -u option. VSM issues a warning message when current capacity exceeds 90% of licensed capacity, and an error message when current capacity exceeds licensed capacity. When current capacity exceeds licensed capacity, VSM suppresses further migrations with migcopy until additional license keys are added. Licensing is enforced when migcopy migrates data using the following storage methods: optical (op and ow), tape (ct, dt, and mt), and NetBackup (nb). Capacity includes active and obsolete granules, but not any granules marked dead. Note The nb method will not be supported after the VSM 4.5 release. VSM calculates current capacity and increments the total as new migrations occur, recording the sum in either /usr/var/openv/hsm/database/CAPACITY_USED1 or /usr/var/openv/hsm/database/CAPACITY_USED2. When VSM periodically recalculates current capacity, only one copy of each migrated file is counted, regardless of how many copies exist and the levels on which they are located. Note VERITAS recommends the practice of making two copies of each migrated file.

348

VERITAS Storage Migrator System Administrator’s Guide for UNIX

miglicense(1M)

OPTIONS -l [-v] Lists the text value and capacity of each VSM license key. The -verbose option is for debugging or customer support, and also displays NetBackup keys. -u

Lists the previously calculated, current capacity used on storage media.

-f

Recalculate the current capacity used on storage media. Must be used with the -u option.

-a

Add a license key of format textofkey.

-d

Delete a license key of format textofkey.

textofkey

The text of the license key in the format AAAA-BBBB-CCCC-DDDD-EEEE-FFFF.

CAVEATS ◆

Whenever current capacity exceeds licensed capacity, VSM suppresses further migrations with migcopy. This continues until licensed capacity is increased. During this period, migrated files can continue to be cached if there is enough free space on disk to hold them.

FILES /usr/var/openv/hsm/database/CAPACITY_USED1 /usr/var/openv/hsm/database/CAPACITY_USED2

The current capacity used SEE ALSO VSM(1M)

Appendix A, Man Pages

349

migloc(1)

migloc(1) NAME migloc - display the location of a migrated file SYNOPSIS /usr/openv/hsm/bin/migloc [-R] pathname [pathname ...] /usr/openv/hsm/bin/migloc -f filelist DESCRIPTION The migloc command shows attributes of and medium (volume) location of migrated files. The output includes obsolete FHDB entries for migrated files. The resulting migloc display has the following format: Status: type mach_name owner file_pathname Handle: mach_idMhandle file_size gran_count date_of_migration Medium: label method level gran_count seek_info vol_location

Status fields (if the file is not migrated, VSM generates only this field) are as follows: type

For a migrated file, type is one of the following: Premigrated, Migrated, Cached, Purged, Staging, or Partial. For other files, type is one of the following: Regular, Directory, Bloc-spl, Char-spl, Socket, Pipe, or Symb-link.

mach_name Host name of the machine on which the file resides. owner

Owner of the file.

file_pathname Pathname of the file. Handle fields are as follows: mach_idMhandle Machine ID and file handle, in hexadecimal, separated by M. file_size

File size in bytes.

gran_count Total number of active granules of this file on all media. date_of_migration Date when the file was last migrated.

350

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migloc(1)

Medium fields are as follows: label

Volume label.

method

Volume method name and volume set number.

level

Volume migration level.

gran_count Number of granules (of the file) on this media. seek_info

Information used by VSM to get to the file on the media. The information printed depends on the volume method. For dk and ad it is the name of the corresponding file. For ct, dt and mt it consists of two numbers separated by a space ( ). The first number is the file number of the file on the volume relative to the beginning. The second number is the granule number of the first granule on the volume.

vol_location Path to file system in which the volume resides. For the ft remote method, it indicates the location of both the server and file system in the format: The method name indicates the type of media as follows: ct

Tape - as defined in migconf

dt

Tape - as defined in migconf

mt

Tape - as defined in migconf

op

Optical disk - as defined in migconf

ow

Optical disk - as defined in migconf

ad

Alternate magnetic disk

dk

Disk file (required for premigration)

ft

Remote ftp method

nb

NetBackup

Note The nb method will not be supported after the VSM 4.5 release. After migration, the file data may exist both on disk and secondary storage until mignospace releases the space from disk. If the data still exists on disk, the display shows media type dk. OPTIONS -R

Appendix A, Man Pages

Recursively list subdirectories encountered.

351

migloc(1)

pathname Files or directories that migloc should locate. If a directory is specified, all files in the directory and its subdirectories are located. May be given as a relative path or absolute path. You can specify multiple files or directories, or use standard regular expressions. Wildcards are recognized. -f filelist

Locate the files listed in filelist. The format of filelist is one file name per line, showing either the full pathname of each file or a pathname relative to the current directory in which migloc is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.

EXAMPLE 1 In the following example, the tproga file resides on cartridge tape and the data has not yet been purged. # migloc tproga Status: Handle: Medium: Medium:

Migrated aspen root tproga 3E8M10E0 133 49 Mon Jan 28 12:48:36 2002 DK0000 dk.0 0 1 3e8M10e0 /sd7/ov2fs/migration/data EXB007 ct.1 1 48 60/3055

EXAMPLE 2 In the following example, the acg1 file resides on a remote ft volume and has been purged. # migloc acg1 Status: Handle: Medium: Medium:

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

SEE ALSO fls(1)

352

VERITAS Storage Migrator System Administrator’s Guide for UNIX

miglow(1M)

miglow(1M) NAME miglow - check the VSM-managed file systems for low space SYNOPSIS /usr/openv/hsm/bin/miglow [hsmname] | file_system] DESCRIPTION The miglow command maintains and manages disk space on a managed file system by initiating migration when free space is below the freespace percentage specified in the dwpath/database/migconf file. The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. miglow is used when the migration daemon is not automatically managing the free space for a VSM-managed file system. When a managed file system is in Maintenance state, you may wish to run miglow before changing the state to Active. This command may be run without regard to whether the migration daemon (migd) is running. The VSM state must be Active or Maintenance. OPTIONS hsmname

Configured VSM name for the managed file system that you want to check.

file_system Full path name of the file system you want to check. If you do not specify an hsmname or file_system, miglow checks all managed file systems. SEE ALSO VSM(1M), migconfg(1M), migbatch(1M), mignospace(1M)

Appendix A, Man Pages

353

migmdclean(1M)

migmdclean(1M) NAME migmdclean - clean VSM migration media SYNOPSIS /usr/openv/hsm/bin/migmdclean [-O] [-i] [-a days] [-R] [-S] hsmname label.method[.volset] [label.method[.volset]]... DESCRIPTION When a user modifies or deletes migrated files, VSM does not remove the migrated files and granules from the medium, but simply marks them as obsolete in the file handle database (FHDB). VSM is unable to reuse the space on the media until all FHDB entries for the volume are obsoleted and set to dead. The migmdclean command cleans media and databases by setting obsolete FHDB entries to dead and then removing all dead FHDB entries. When all FHDB entries for a volume are dead, the -R option can remove the volume’s entry from the VSM volume database (VOLDB). You can then recycle the media by registering and relabeling it for use with VSM. By using the migselect command, you can select multiple media under different methods. You can use the migrc command to remove obsolete and dead entries (see migrc(1M)). You can also use the migcons command to consolidate volumes and free them for reuse. However, migmdclean has additional options that may be useful under certain conditions. For example, if the medium is damaged you can use the -O and -R options to forcibly obsolete database entries and remove the empty volume from VSM. For the ad and ft methods, migmdclean also attempts to remove files from the media when the MFLAG_OBSOLETE flag is specified in the dwpath/database/migconf configuration file for these methods. For the ct, dt, mt, op, and ow methods, migmdclean never attempts to remove files from the media. If all granules on the volume are already dead, use migrecycle to reregister the media and remove files. If the volume contains obsolete granules, use migcons and then reregister the media with migreg to remove files. Although it is possible to clean ow media (write once, read many), it is not possible to recycle these optical disks. Note When one side of an optical disk is consolidated, the volume entry for that input volume is not removed from the VOLDB unless and until both sides of that optical disk are empty.

354

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migmdclean(1M)

Note Although VSM sets FHDB entries to obsolete if a migrated file is modified or deleted, VSM must set these entries to dead before actually removing them from the FHDB. With the ad and ft methods, migmdclean may also unlink the file on the media so it is no longer possible to recover the data using VSM utilities. Prior to unlinking, you could recover the file by simply setting the corresponding FHDB entry back to active. In the following discussions, removal refers to unlinking and applies only to media used by the ad and ft methods. OPTIONS By default, migmdclean marks as dead all FHDB entries that have been obsolete for 7 days, regardless of the method or volume. For ad and ft volumes, the command also attempts to remove obsolete files from the media if MFLAG_OBSOLETE is set. For nb volumes, the command will expire the NetBackup image when the last FHDB entry to reference it is deleted. Note The nb method will not be supported after the VSM 4.5 release. -O

This option forces valid FHDB entries to be obsolete. If -a 0 was specified, the valid FHDB are also forced to be dead.

Caution Use the -O parameter with extreme caution, as it might prevent user access to migrated files residing on the volume. See CAVEATS. For ad and ft volumes, this option also attempts to remove the files from the media. If this option is not specified, migmdclean removes only currently obsolete entries. -i

Marks the FHDB entries as dead but inhibits removal of files from the media. If this option is not specified, VSM attempts to remove files. This option applies to the ad and ft methods.

-a days

Selects only files that have been obsoleted for the specified number of days. The default is 7 days. An important use of the age parameter [-a days] is to specify that VSM delete only those files obsoleted prior to the last full backup.

-R

Specifies that if all FHDB entries for the volume are dead, migmdclean removes the volume entry from the VOLDB. Doing this will also remove all dead volumes, not just the ones being cleaned. If this option is not specified, the volume remains in the VOLDB as a valid entry.

-S

Activate obsolete and dead FHDB entries of all files with VSM handles. migmdclean -S applies to all files with VSM handles, not just those in the specified volumes.

Appendix A, Man Pages

355

migmdclean(1M)

FHDB dk entries are not activated with migmdclean -S. hsmname

Specifies the configured VSM name for the managed file system containing the database files for the volumes that you want migmdclean to process.

label.method.volset Selects the media id that has a matching label in the volume set for the method. volset is optional. You can supply a list for this parameter. CAVEATS ◆

When migmdclean is run to clean a specified volume, it will also remove all dead volumes, not just the ones being cleaned.

◆

Locked database entries for the media will cause the cleanup operation to fail. Run migrc -L prior to running migmdclean to unlock the locked entries.

◆

Execute migdbcheck before running migmdclean to ensure database consistency.

◆

Side effects of running migmdclean -a 0 -O -R after all copies have been made:

◆

-

If there is only one migrated copy and the file is purged from premigration, the file cannot be cached and the data is lost.

-

If another active or obsolete copy exists and the file is purged from premigration, the file can still be cached.

-

Unpurged files will not be purged and can still be cached.

-

Copies of unpurged files will not be remade.

If using NetBackup in conjunction with VSM, set the age variable for migmdclean at a value higher than the longest NetBackup retention period on the managed file system. Do this by adding the following line to /usr/openv/hsm/bin/cmd/migmdclean: FLGS=”-a xxxx $FLGS”

The xxxx is the longest NetBackup retention period. Next, remove the following line: FLGS=“-a 7”

EXAMPLE The following example removes obsolete FHDB entries at least 7 days old from media in cartridge disk rao001 volume set 1. # migmdclean -a 7 alpha rao001.ct.1

356

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migmdclean(1M)

The following example selects media in alternate magnetic disk (ad) volume set 1 that have no active files and removes the granules from them. When removal is successful, the corresponding FHDB entries are marked as dead. # migmdclean alpha ‘migselect alpha 0-0 1 ad‘

FILES The term dwpath refers to the path name of the directory containing the database and workdir directories. The path name of this directory is site configurable dwpath/database/FHDB

File handle database dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database dwpath/database/migconf

Configuration file for managed file systems /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server SEE ALSO migdbcheck(1M), migreg(1M), migconf(1M), migconfg(1M), migcons(1M), migdbrpt(1M), migrc(1M), migrecycle(1M), migselect(1M), migactivate(1M)

Appendix A, Man Pages

357

migmove(1M)

migmove(1M) NAME migmove - move migrated files from one migration level to another level SYNOPSIS /usr/openv/hsm/bin/migmove [-A] [-m methname] [-f a | o | d] [hsmname | file_system] /usr/openv/hsm/bin/migmove -c 1 | 2 [-A] [-m methname] [-f a | o | d] [hsmname | file_system] /usr/openv/hsm/bin/migmove -s miglevel [-d miglevel] [-A] [-m methname] [-f a | o | d] [hsmname | file_system] DESCRIPTION The migmove command controls the movement of active migrated files from one migration level to another migration level. It scans the configured migration levels associated with the specified hsmname or file_system, selecting and moving files that meet the configured age and size criteria. A file is selected for movement if all of the following are true: ◆

The file is active (not marked error, obsolete or dead in the FHDB).

◆

The file’s calculated move threshold value is greater than or equal to the configured move threshold value for the source migration level. The file move threshold is calculated using either the standard move threshold formula (which factors in file age and size) or a site-specified move threshold formula.

◆

The destination migration level and corresponding storage method are configured in migconf.

◆

Any copy of the file at the destination migration level, even if that file has the error flag set or is marked obsolete or dead in the FHDB, will prevent a file from being selected to be moved to that level.

◆

The source migration level method name is ad, ct, dt, mt, op, or ow.

VSM supports a total of up to eight migration levels. By default the migmove command assumes there will be two migrated copies, and divides the eight migration levels into a symmetrical hierarchy where the first copy is associated with odd-numbered levels and the second copy is associated with even-numbered levels. Defaults are set accordingly. Sites can create asymmetrical hierarchies by migrating only one file copy, or by specifying both the source and destination migration levels in migmove commands.

358

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migmove(1M)

Using the VSM-Java interface you may configure move criteria for migration levels or for method names or for both. Move criteria for migration levels, if specified, take precedence over move criteria for method names, if specified. VSM first attempts to retrieve the data from the volume at the source migration level. If that fails, VSM attempts to retrieve the data from another volume regardless of its migration level, starting with the storage device with the shortest file transfer time. After a file moves from a source migration level to a destination migration level, the file at the source level can remain active or it can be marked obsolete or dead. Volumes can later be consolidated and recycled to reclaim the file space occupied by obsolete and dead files. The migmove command is generally run on a schedule created with the Scheduling tool. OPTIONS -c 1 | 2 For -c 1, move copy 1 of the migrated files. In the default configuration with all eight migration levels configured, the source migration levels 5, 3, and 1 are processed in that order. Files at level 5 move to level 7, then files at level 3 move to level 5, and then files at level 1 move to level 3. Configured source migration levels are scanned only if their respective destination migration levels are also configured. For -c 2, move copy 2 of the migrated files. In the default configuration with all eight migration levels configured, the source migration levels 6, 4, and 2 are processed in that order. Files at level 6 move to level 8, then files at level 4 move to level 6, and then files at level 2 move to level 4. Configured source migration levels are scanned only if their respective destination migration levels are also configured. The default is move both copy 1 and copy 2 files when neither -c nor -s are specified. If -c is specified, -s cannot be specified. -s miglevel Move files from the source migration level indicated by miglevel, where miglevel is an integer in the range 1 to 8. If the destination migration level -d is not specified, miglevel cannot equal 7 or 8. The default destination migration level is the source migration level +2. If -s is specified, -c cannot be specified. Note When specifying the -s level, if the data selected to move is currently on disk, then the data will come from the disk and not the -s level specified.

Appendix A, Man Pages

359

migmove(1M)

-d miglevel Move files to the destination migration level indicated by miglevel, where miglevel is an integer in the range 1 to 8. The destination migration level cannot equal the source migration level. The default is the source migration level +2. If -d is specified, -s must be specified. -A

Select all files at source level ignoring selection criteria.

-m methname Scan for this method name when selecting and moving files for all source migration levels processed. Allowed values for methname are ad, ct, dt, mt, op, and ow. Default is to scan for all allowed and configured method names for all source migration levels processed. If -m is specified, either -c or -s may also be specified. -f a | o | d For -f a, leave the FHDB entries for the selected files active at the source migration level. For -f o, mark the FHDB entries for the selected files obsolete at the source migration level. For -f d, mark the FHDB entries for the selected files dead at the source migration level. If the method name is ad, mark the FHDB entries for the selected files obsolete at the source migration level. When -f a|o|d is not specified, the default is what is specified in the migconf move flags. -h

Print help information.

hsmname

Configured VSM name for the managed file system to be processed for moving files from one migration level to another migration level.

file_system The full path name of the file system to be processed for moving files from one migration level to another migration level. The hsmname for this file system must be in the Active or Maintenance state. If neither hsmname nor file_system is specified, all hsmnames are processed. CAVEATS ◆

360

The defaults for migmove assume two migrated copies and a symmetrical hierarchy in which the first copy is associated with odd-numbered migration levels and the second copy is associated with even-numbered migration levels. To implement any other multilevel migration hierarchy, configure the migration levels you need and then specify both the source and destination migration levels in migmove commands.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migmove(1M) ◆

If migmove is interrupted by a system crash, the last incomplete move by migmove of a file to another migration level will complete when the VSM startup script migrc -M is run.

◆

migmove will deadlock and time out if the same storage unit drive is the only one available to process files at both the source migration level and the destination migration level.

◆

The migmove command can be used to restore missing copies of files at METHOD1 (or METHOD2 if two copies of files are made). Before using migmove in this manner, change the state of the hsmname to Inactive. This avoids problems that may occur if either a migbatch or mignospace operation occurs simultaneously with migmove. You must specify hsmname in the migmove syntax.

◆

Do not run migcons and migmove simultaneously if they both are taking source from the same volumes. The results of such an action are undefined.

EXAMPLES The hsmname for the file system to be processed in these examples is alpha. The following example is the most general case. # migmove alpha

It assumes there are two migrated copies and all eight migration levels are configured into a symmetrical hierarchy where the first copy is associated with odd-numbered levels and the second copy is associated with even-numbered levels. The default conditions will move selected primary and alternate files with any method name from source migration levels 5 and 6 respectively to their corresponding default destination migration levels, 7 and 8 respectively, and then process the other source migration levels in decreasing numerical sequence. After they are moved, selected files at all source migration levels are marked dead by default unless the method name is ad, in which case they are marked obsolete. In the special case where only migration levels 1, 2, and 3 are configured, this same command # migmove alpha

moves selected files with any method name only from source migration level 1 to default destination migration level 3. The following example moves only copy 2 of migrated files. Assuming all migration levels are configured, the command moves selected files with method name ct sequentially from source migration levels 6, 4, and 2 to their default destination migration levels, 8, 6, and 4 respectively. After they are moved, selected files at all source migration levels are marked dead by default. # migmove -c 2 -m ct alpha

Appendix A, Man Pages

361

migmove(1M)

The following example moves selected files with any method name from source migration level 4 to default destination migration level 6. After they are moved, selected files at source migration level 4 remain active. # migmove -s 4 -f a alpha

The following example is that of an asymmetrical hierarchy where the destination migration level is specified to be something other than the default value (source migration level plus 2). This command moves selected files with any method name from source migration level 3 to destination migration level 4. After they are moved, selected files at source migration level 3 are marked obsolete. # migmove -s 3 -d 4 -f o alpha

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database dwpath/database/FNDB

File name database for VSM dwpath/database/migconf

Configuration file for managed file systems /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server dwpath/database/migsweep.site

Site migration and purge criteria dwpath/database/migsweepm.site

Site move criteria /usr/var/openv/hsm/example/database/sample.migpolicy.script

Sample migpolicy replacement script SEE ALSO migconf(1M), migconfg(1M), migpolicy(1M), migsetdb(1M)

362

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignbexport(1M)

mignbexport(1M) NAME mignbexport - export VSM files SYNOPSIS

/usr/openv/hsm/bin/mignbexport [-s dir] [-e ExpLevel] [-S schedule] [-P policy] [-D timeout] hsmname DESCRIPTION The mignbexport command exports files from one VSM-managed file system so they can be imported into a different VSM-managed file system using the companion mignbimport command. Migrated files, if any, are not cached by either mignbexport or mignbimport. Using this command requires that NetBackup be installed and running on the server executing mignbexport. mignbexport does a user directed backup of the exported files and the FHDB entries and VOLDB entries for those exported files. These NetBackup images are exported to the site doing the mignbimport. The backup is done using a NetBackup policy that must be defined in the NetBackup configuration prior to executing mignbexport. The NetBackup policy must define a NetBackup volume pool that contains volumes that can be sent to the site doing the mignbimport. The VSM volumes that contain data for any migrated files being exported must also reside on VSM volumes that can be sent to the site doing the mignbimport. There are two ways to export files. ◆

Export all migrated and unmigrated files residing in the specified subdirectory (dir) in the managed file system.

◆

Export all migrated files residing at export level ExpLevel. In this case, do not specify the -s dir option.

After mignbexport runs, the Volumes_to_export.pid file in dwpath/database contains a list of all VSM volumes that are exported. Additionally, the exported tapes now reside in the VSMEXP volume pool, which prevents these tapes from being overwritten with migrated files. Send all the exported volumes to the site that will import the data with the mignbimport command. After mignbexport runs, the Client_name.pid file in dwpath/database contains the NetBackup client name that initiated the user directed backup. This client name is needed when doing the NetBackup import at the import site. Appendix A, Man Pages

363

mignbexport(1M)

After mignbexport -s runs, the files_to_export.pid file in dwpath/database contains a list of all files that are exported. After running mignbexport you must identify which NetBackup volumes belonging to the specified NetBackup policy were used during the mignbexport operation. Send these volumes to the site doing the mignbimport. OPTIONS -s dir

Full path of the directory to export. This must be a subdirectory in the managed file system. mignbexport moves files in dir to ExpLevel and exports all migrated and unmigrated files in dir. Prior to running mignbexport a LEVELExpLevel must be configured and there must be VSM volumes registered for this LEVELExpLevel. After mignbexport moves migrated data to these VSM volumes, the volumes are sent to the site doing the mignbimport. All files residing in dir following a mignbexport operation remain there. If -s dir is specified and there are any migrated files in dir that reside at level ExpLevel prior to running mignbexport, the command will abort with an error message. If -s dir is not specified, mignbexport will only export files that currently reside at ExpLevel. No files will be moved to ExpLevel and unmigrated files will not be exported.

-e ExpLevel Migration level of volumes to export. Valid values range from 1 to 8. Default is 8. See the -s option for an explanation of the relationship between ExpLevel and dir. -S schedule NetBackup schedule in policy to use for the user directed backup. The default is HSMEXPS. The schedule must be defined in the NetBackup configuration prior to running mignbexport. -P policy NetBackup policy to use for the user directed backup. The default is HSMEXPC. The policymust be defined in the NetBackup configuration prior to running mignbexport. The policymust use NetBackup volumes that can be moved to the site doing the mignbimport. -D timeout A deadman timeout value in minutes. If NetBackup does not respond to the user directed backup request of mignbexport within the timeout period, mignbexport will abort. The default is 60 minutes. hsmname

364

The name of the file system from which files are exported. For more information, see migconf(1M). VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignbexport(1M)

CAVEATS ◆

All systems exporting and importing files between them must have unique Machine IDs for managed file systems. Valid hexadecimal values range from 1 to FFFFFF. The default is 1000.

◆

mignbexport does not supported embedded special characters in file names, such as asterisk, backslash, newline, parenthesis, question mark, right curly brace, square bracket, tab, or vertical bar (pipe).

◆

All systems exporting and importing files between them must have unique volume labels for the VSM volumes containing the migrated files being exported. These volumes are sent to the site doing the mignbimport.

◆

All systems exporting and importing files between them must have unique volume labels for the NetBackup volumes sent to the site doing the mignbimport.

◆

All systems exporting or importing files between them must have unique NetBackup client names for the client doing the user directed backup.

◆

If mignbexport does not terminate successfully you may have to cleanup the exporting file system before trying again. If the -s option was specified, the VSM volumes containing the migrated files being exported may have to be recycled.

◆

Configure the export migration level (ExpLevel) and corresponding level before using this command.

◆

Neither the ft or nb methods are eligible to be imported or exported.

Note The nb method will not be supported after the VSM 4.5 release. EXAMPLE In the following example, the exporting site will move copies of all migrated and unmigrated files in directory /delta/export/6/4 to default level 8 for export from file system delta. The NetBackup schedule is the default HSMEXPS, and the NetBackup policy is the default HSMEXPC. # mignbexport -s /delta/export/6/4 delta

A typical response follows. Dots are printed in sequence while tapes are writing or rewinding. Waiting on NetBackup backup ... Waiting on NetBackup to complete ... The HSM volumes exported are listed in file /usr/var/openv/delta/database/Volumes_to_export.225 The NetBackup client name is listed in file /usr/var/openv/delta/database/Client_name.225

Appendix A, Man Pages

365

mignbexport(1M)

The files exported are listed in file /usr/var/openv/delta/database/files_to_export.225

After mignbexport runs, remove the VSM volumes that are listed in Volumes_to_export.pid and send them to the importing site. Then, remove this media from VOLDB and your media manager volume database. Use the NetBackup and Media Manager interfaces to identify which volumes are in policy HSMEXPC, and also send the ones that have been written to the importing site. FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database for VSM dwpath/database/migconf

Configuration file for VSM dwpath/database/Volumes_to_export.pid

A list of all VSM volumes that are exported dwpath/database/Client_name.pid

NetBackup client name SEE ALSO migconf(1M), migconfg(1M), migdbcheck(1M), migdbrpt(1M), mignbimport(1M), migmove(1M)

366

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignbimport(1M)

mignbimport(1M) NAME mignbimport - import VSM files SYNOPSIS

/usr/openv/hsm/bin/mignbimport [-i ImpLevel] [-P policy] -m client_name [-D timeout] hsmname DESCRIPTION The mignbimport command imports files previously exported using the companion mignbexport. The managed file system must be active before you import files. Using this command requires that NetBackup be installed and running on the server executing mignbimport. mignbimport does a user directed NetBackup restore of the exported files and the FHDB entries and VOLDB entries for the exported files. This restore also includes information about the original path of the exported VSM-managed file system. mignbimport merges the FHDB, FNDB, and VOLDB entries created by mignbexport into the FHDB, FNDB, and VOLDB of the importing managed file system, hsmname. When the files are restored, the portion of the path that was the original path of the exported VSM-managed file system is replaced with the path of the VSM-managed file system into which the files are being imported. The VSM volumes that were exported must be placed in the desired library before running mignbimport. These volumes retain their original volume name so they must be unique. Do not register these volumes to VSM because mignbimport will take care of this automatically. A NetBackup policy must be defined prior to running mignbimport and this policy must have the same name as the NetBackup policy used with the mignbexport. This policy must reference a NetBackup volume pool that contains only the NetBackup volumes that were written by mignbexport. The NetBackup volumes that were written by mignbexport must be imported into NetBackup at the site importing the files prior to running mignbimport. For more information on importing NetBackup images, see the NetBackup DataCenter System Administrator’s Guide for UNIX. This command may be run without regard to the VSM state, but the migd migration daemon must be running.

Appendix A, Man Pages

367

mignbimport(1M)

OPTIONS -i ImpLevel Migration level of the imported volumes. Valid values range from 1 to 8. Default is 7. mignbimport will change the FHDB entries for the imported files to indicate that the files reside at this level. mignbimport will also change the VOLDB entries for the imported volumes so they appear to be full and will never be written on again. -P policy

NetBackup policy to use for the user directed restore. It must be the same as the policy used with mignbexport. The default is HSMEXPC. The policy must be defined in the NetBackup configuration prior to running mignbimport. The policy must use NetBackup volumes that were exported from client_name and sent from the site doing the mignbexport. These volumes must be imported into NetBackup prior to running mignbimport.

-m client_name Name of the NetBackup client from which the VSM files were exported. See the dwpath/database/Client_name.pid file created when the mignbexport operation finished. -D timeout A deadman timeout value in minutes. If NetBackup has not responded within the timeout period, mignbimport will abort. The default is 60 minutes. hsmname

The name of the file system to which the files will be imported. For more information, see migconf(1M).

CAVEATS

368

◆

All systems exporting and importing files between them must have unique Machine IDs for managed file systems. Valid numerical values range from 1 to FFFFFF. Default is 1000.

◆

All systems exporting and importing files between them must have unique volume labels for the VSM volumes containing the migrated files being exported. These volumes are sent from the site doing the mignbexport.

◆

All systems exporting and importing files between them must have unique volume labels for the NetBackup volumes sent from the site doing the mignbexport.

◆

Do not run mignbimport twice on a system to import the same files without first cleaning up any errors from the first run.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignbimport(1M) ◆

Imported files lose any designations they may have as tied files, and must be redesignated. See man page migtie(1).

◆

Configure the import migration level (ImpLevel) and corresponding LEVEL before using this command.

◆

The NetBackup policy used for the user directed restore must match the NetBackup policy used in the mignbexport operation, and must be defined in the NetBackup configuration prior to running mignbimport.

◆

Imported VSM volumes must be loaded into a library prior to running mignbimport.

◆

The NetBackup volumes that were exported must be in a NetBackup pool referenced by policy, and must have been imported into NetBackup as client_name prior to running mignbimport.

◆

Neither the ft or nb methods are eligible to be imported or exported.

Note The nb method will not be supported after the VSM 4.5 release. EXAMPLE Place the NetBackup volumes containing files to be imported in the appropriate storage devices and register them with Media Manager for the importing VSM-managed file system, giving them a unique pool name. Define the NetBackup policy HSMEXPC to use this unique pool name Using NetBackup, import the client client_name. In this example, this is hat. Place the VSM volumes containing file data to be imported in the appropriate storage devices and register them with Media Manager for the importing VSM-managed file system, giving them a pool name of HSM. If this is not done, Media Manager will issue requests for the operator to assign this media. In this example, the site will import copies of files to default level 7 on file system omikron. The name of the NetBackup client is hat. # mignbimport -m hat omikron

A typical response is shown below: Waiting on NetBackup restore in Phase 1... Waiting on NetBackup restore in Phase 2... mignbimport complete.

Note The dots are printed in sequence while tapes are reading or rewinding. The imported files now are ready for access by VSM on the file system at the new location.

Appendix A, Man Pages

369

mignbimport(1M)

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database for VSM dwpath/database/migconf

Configuration file for VSM SEE ALSO migconf(1M), migconfg(1M), migdbcheck(1M), migdbrpt(1M), mignbexport(1M), migmove(1M), migtie(1)

370

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignbscan(1M)

mignbscan(1M) NAME mignbscan - scan nb volume and reconstruct database entries for the nb storage method SYNOPSIS

/usr/openv/hsm/bin/mignbscan [-s] [-h] hsmname label NB_master policy_name NB_client level DESCRIPTION Note The nb method will not be supported in the next release of VSM. The mignbscan command scans a NetBackup policy and displays information about the volume as a whole as well as information about each file granule on the volume. It also reconstructs the FHDB, FNDB, and VOLDB entries for all scanned granules. A file is migrated to NetBackup as a single granule. The granule header, <machid>M.GLABEL., is separately backed up as a file. The granule header contains FHDB, FNDB, and VOLDB entry information. The mignbscan command creates three output files: FHDB.label, FNDB.label and VOLDB.label, in the dwpath/database directory. The structure of these files is the same as the FHDB, FNDB, and VOLDB database files. These files may be used to rebuild the FHDB, FNDB, and VOLDB if they are corrupted or damaged (see migdbcheck(1M)). You can sort and merge FHDB.label and FNDB.label files for different volumes to recreate the FHDB and FNDB. Similarly, merging VOLDB.label files for different volumes can recreate the VOLDB. When recreating the VOLDB, be sure to merge the VOLDB file in the /usr/var/openv/hsm/example/database directory to include the entry for the dk method. OPTIONS The following parameters are available under migftscan: -s

Silently scan the volume and create FHDB.label and VOLDB.label files, but do not display information on stdout.

-h

Print help information.

hsmname

Configured VSM name for the managed file system containing the database containing information on the desired volume.

label

NetBackup volume label used when registering the volume. This parameter is required.

Appendix A, Man Pages

371

mignbscan(1M)

NB_master Name of the master NetBackup server for nb volumes. NB_master must be the first name the server is known by to NetBackup. policy_name Name of the NetBackup policy. The NetBackup policy must be active. NB_client

Name of the NetBackup client. Check the NetBackup GUI to identify the correct value to use for client.

level

The migration level of this volume. Valid values are 1 or 2.

EXAMPLE The following example scans the NetBackup disk volume NB003 that is registered under the nb method. The NetBackup server is duo, the NetBackup policy is hsmnb2, the NetBackup client is trio, and the migration level for this volume is 1. The display shows a list of granule information for files backed up onto the volume. The FHDB.NB003 and VOLDB.NB003 files are created in the dwpath/database directory. # mignbscan tau4 NB003 duo hsmnb2 trio 1 Volume label Found ====> NB003 duo hsmnb2 ------------------------------Obtaining list of granules. Restoring granule header files ... /tau4/migration/data/3e8M24c5.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:35 2001 /tau4/files/a /tau4/migration/data/3e8M24c6.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:36 2001 /tau4/files/b /tau4/migration/data/3e8M24c7.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:36 2001 /tau4/files/c /tau4/migration/data/3e8M24c8.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:36 2001 /tau4/files/d /tau4/migration/data/3e8M24c9.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/e /tau4/migration/data/3e8M24ca.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/f /tau4/migration/data/3e8M24cb.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/g /tau4/migration/data/3e8M24cc.GLABEL.1 <=> 00014B6B 00000000 Mon Apr 9 12:54:37 2001 /tau4/files/h

Particulars of granules displayed include (in order): granule file name, migrated file size, offset of the granule in the migrated file, date of backing up the granule, and migrated file pathname. Including an incorrect policy name in the command gives the result shown in the following example: 372

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignbscan(1M)

# mignbscan tau4 NB003 duo badname trio 1 Warning NO Volume label found active for duo badname

There are no output files, and the hsmlog contains the following message: ERROR - the specified policy does not exist in the configuration database Policy:migrate exit code:230

Including an incorrect migration level in the command gives the result shown in the following example: # mignbscan tau4 NB003 duo hsmnb2 trio 0 Volume label Found ====> NB003 duo hsmnb2 ------------------------------Obtaining list of granules. Restoring granule header files No files found in /tmp/mignbscan2.2401Z

There are no output files, and the hsmlog contains the following message: ERROR 13:29:29 INF - Status = no files specified in the file list.

Including an incorrect NetBackup client in the command gives the result shown in the following example: # mignbscan tau4 NB003 duo hsmnb2 badclient 1 # echo $status 4

The output files are deleted, and the hsmlog contains the following message: ERROR: bpflist failure ABORTING no entity was found

Including an incorrect NetBackup server in the command gives the result shown in the following example: # mignbscan tau4 NB003 badserver hsmnb2 trio 1 # echo $status 3

There are no output files, and the hsmlog contains the following message: ERROR 13:33:38 INF - Status = no entity was found.

Appendix A, Man Pages

373

mignbscan(1M)

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database for VSM dwpath/database/migconf

Configuration file for VSM dwpath/database/FHDB.label

File handle database for current volume dwpath/database/VOLDB.label

Volume database for current volume SEE ALSO migconfg(1M), migdbcheck(1M), migdbrpt(1M), migreg(1M), migadscan(1M), migftscan(1M), migtscan(1M), migopscan(1M)

374

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignewlog(1M)

mignewlog(1M) NAME mignewlog - truncate or restart and optionally make a copy of VSM logs SYNOPSIS /usr/openv/hsm/bin/mignewlog [-F] hsmname [destination_file] | GLOBAL [destination_file] DESCRIPTION VSM maintains a global log file for the VSM server and a separate log file for each hsmname in the /usr/var/openv/hsm/database/migconfg file. ◆

The pathname to the global log file is not configurable and is always /tmp/hsm.log (it may be a symbolic link).

◆

You define the log file paths for each managed file system during configuration. The term lgpath refers to these file paths.

VSM uses each hsmname’s log file lgpath and the global log file (/tmp/hsm.log) to store messages, status, and errors. To ensure that the global is maintained between boots and does not fill up the /tmp partition, you should link it to a file that resides on a file system other than /tmp. If the lgpath or /tmp/hsm.log files become too large, you can use the mignewlog command to truncate or restart them and release the associated disk space. Note that using rm to remove the global log file /tmp/hsm.log does not release the disk space associated with that file if the migration daemon (migd) is running. Before truncating or restarting any log files, you should inspect them for abnormal errors. OPTIONS -F

Used to replace the contents of the destination_file. When this is not specified, the destination_file is NOT overwritten.

hsmname

Configured VSM name for the managed file system containing the log file you want mignewlog to truncate or restart. If hsmname=GLOBAL, the command uses the global log file /tmp/hsm.log.

destination_file If you specify this parameter, mignewlog copies the log to the specified destination before truncating or restarting it. If you do not specify a destination_file, the log is removed.

Appendix A, Man Pages

375

mignewlog(1M)

CAVEATS If migration to secondary media is taking place, the disk space for lgpath is not actually released until the copy-out operation completes. FILES /usr/var/openv/hsm/database/migconfg Global configuration file for the VSM server /tmp/hsm.log

Global log file for the VSM server SEE ALSO migconfg(1M), migchecklog(1M), migrc(1M), startmigd(1M)

376

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignospace(1M)

mignospace(1M) NAME mignospace - make disk space available SYNOPSIS /usr/openv/hsm/bin/mignospace [-N] [-i | -h] hsmname | file_system DESCRIPTION The mignospace command attempts to make space available in the indicated file system. This command starts in either of two ways: ◆

The administrator executes it directly from the system prompt, from the VSM-Java interface, or with a crontab entry.

◆

A user attempts to write to the file system when the actual free space is less than the configured free space.

mignospace purges premigrated file space in a sequence determined by the purge threshold attributes configured for the file system. The default purge threshold attributes will purge space for the oldest files first, regardless of size. See migconf(1M). mignospace starts by checking for premigrated files. ◆

If some premigrated files exist that exceed the purge threshold, mignospace either purges this premigrated file space to the purgemark percentage and stops or purges all this premigrated file space and stops, whichever comes first.

◆

If premigrated files exist but none exceed the purge threshold, mignospace cuts the current the purge threshold in half and exits.

◆

If there are no premigrated files, mignospace cuts the current threshold in half and selects enough files to increase free space to the freespace parameter percentage. It then premigrates the selected files, copies them to secondary storage, and determines if any exceed the purge threshold. If some premigrated files exceed the purge threshold, mignospace either purges the file space to the purge mark percentage and stops, or it purges all the file space and stops, whichever comes first. If no premigrated files exceed the purge threshold, mignospace cuts the current purge threshold in half and exits.

migrc and migbatch reset current thresholds and current purge thresholds to their original dwpath/database/migconf values.

Appendix A, Man Pages

377

mignospace(1M)

If the migconf file specifies a lowwater value, mignospace selects only enough files to satisfy lowwater. If lowwater is unspecified, mignospace selects all files meeting the selection criteria. Files in premigration are not considered free, and files in .migrate are not used in calculating lowwater. If the migconf file specifies a purgemark value, mignospace purges only enough premigrated file space to satisfy purgemark. If purgemark is unspecified, mignospace purges all premigrated file space. Use the -i option to ignore a specified purgemark value and purge all premigrated files. The log for hsmname indicates the action taken by mignospace. OPTIONS -N

Use accelerated disk space availability. The misweep and migcopy processes will quit before the threshold is reached in order to free some of the disk more quickly.

-i

Ignore the purgemark and purge all available premigrated file space.

-h

Print help information.

hsmname

Configured VSM name for the managed file system in which you want to provide space.

file_system Full path name of the file system in which you want to provide space. CAVEATS ◆

Always maintain a sufficient number of VSM-registered tapes, optical platters, or alternate magnetic disks since mignospace may be started automatically by the system on low space conditions. See migreg(1M).

◆

The migration daemon migd and device-manager daemon (see ltid(1M)) must be running and the VSM state must be Active for mignospace to start automatically on low space conditions.

◆

Some processes spawned by mignospace create large temporary files and there may not be enough space in the /tmp directory for them. Define the environment variable TMPDIR to contain the pathname of a directory in a file system that has sufficient space available.

EXAMPLE The following example, calls mignospace to increase the space available on the file system named /mig2 and then on the hsmname alpha. # mignospace /mig2 # mignospace alpha

378

VERITAS Storage Migrator System Administrator’s Guide for UNIX

mignospace(1M)

FILES dwpath/database/migconf Configuration file for managed file systems /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server SEE ALSO VSM(1M), ltid, migconf(1M), migconfg(1M), startmigd(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)

Appendix A, Man Pages

379

migpolicy(1M)

migpolicy(1M) NAME migpolicy - specify VSM policy and method to write files to secondary storage SYNOPSIS /usr/openv/hsm/bin/migpolicy hsmname inputfile [levelno] DESCRIPTION The migpolicy command reads the input file and adds the number of copies and the destination level to migcopy’s input script. The command is used whenever the controlling commands migbatch or mignospace are run. The migpolicy command calls migpolicy.script, which is responsible for filling in fields 5 (volset), 7 (method), 13 (hint), 14 (comment), and 15 (mmlevel) of the input file, and for placing the altered information on worklists, the names of which are echoed as an exit condition. (The migpolicy.script file is found in the admincmd directory of /usr/openv/hsm/bin/.) Generally, you do not alter migpolicy or use it directly. However, it is possible to enhance the migpolicy.script to divert specific files to suitable media. You can divert files by file size, by owner, or by any other distinguishable file characteristic. You change the behavior migpolicy.script by replacing it with an alternate script. The file /usr/var/openv/hsm/example/database/sample.migpolicy.script is a sample replacement that uses the size of a file to determine whether VSM will copy it to the primary level or to the alternate level. OPTIONS hsmname

Configured VSM name for the managed file system from which you are migrating files.

levelno

Level number that migpolicy will use. Level number 1 is the primary level, 2 is the alternate level, and 3-8 are multilevel migration levels.

inputfile

List of files to be migrated; its format is similar to a copydb worklist: 0000103A|000003E8|00000000|00000100|0|00000000|ad|| 0.92|512|472|/home1/migtie/asd|library|Auto HSM run|00000001|00000000| The fields are as follows: 1

2

3

4

5

6

7

8

9

handl|machid|lock|flags|volset|copd|meth|dst_seek|age| 10 11 12 13 14 15 16 size|threshold|path|hint|comment|mmlevel|slevel| 380

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migpolicy(1M)

This file is specified in the VSM controlling scripts. CAVEATS The migration level specified in migpolicy must be a valid level defined in the dwpath/database/migconf configuration file. FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/migconf

Configuration file for managed file systems /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server /usr/var/openv/hsm/example/database/sample.migpolicy.script

Sample migpolicy replacement script /usr/openv/hsm/bin/admincmd/migpolicy.script Migration policy script currently used hsmname.copydb.method_name.vol_set_number.hint

VSM work lists SEE ALSO VSM(1M), migbatch(1M), migconf(1M), migconfg(1M), mignospace(1M)

Appendix A, Man Pages

381

migpurge(1)

migpurge(1) NAME migpurge - purge migrated file disk space SYNOPSIS /usr/openv/hsm/bin/migpurge filename [filename ...] /usr/openv/hsm/bin/migpurge -f filelist DESCRIPTION The migpurge command purges disk space used by migrated files, which makes some disk space available immediately. The files are not purged unless copies have been made. Users can purge files they own; root users can purge any files. For users, the VSM state must be Active; for root users the state can be Active or Maintenance. The migd migration daemon must be running. The system administrator can ensure all migration copies have been made before using migpurge by running migrc -R hsmname first. OPTIONS filename

Files to purge; may be a relative path or absolute path. You can specify multiple files, use standard regular expressions, or use wildcards.

-f filelist

Purge the files listed in filelist. The format of filelist is one file name per line, showing the full pathname of each file or a pathname relative to the current directory in which migpurge is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.

EXAMPLES The following command purges files listed in the input file purglist. # migpurge -f purgelist

The following command purges files f4, f5, and f6 in the current working directory. # migpurge f4 f5 f6

The following command purges all file space in the current working directory that have file names begin with the string July_15. # migpurge July_15*

SEE ALSO VSM(1M), fls(1), migloc(1), mignospace(1M), migrate(1) 382

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migrate(1)

migrate(1) NAME migrate - request premigration of a file SYNOPSIS /usr/openv/hsm/bin/migrate [-F] filename [filename ...] /usr/openv/hsm/bin/migrate [-F] -f filelist DESCRIPTION The migrate command lets users request that VSM migrate a file to secondary storage. Users can premigrate regular files that they own in VSM-managed file systems if allowed to use this command. The system administrator must provide the proper permissions before users can use this command. All files specified with a single migrate command must be in the same managed file system. The first file determines that file system. Use the fls command to determine if a file has been migrated or premigrated. The migrate command performs only the premigration phase of migration. The files do not actually migrate to secondary storage until the next time mignospace, migbatch, or miglow execute. After a file is migrated to secondary storage, accessing it causes VSM to transparently cache the file back to disk. If the migrate command is used to premigrate an unmodified cached file for which enough valid copies already exist in secondary storage, VSM does not recopy the file. VSM purges the data immediately from disk if the dk method entry for the file does not exist in the FHDB, otherwise the data is purged later by mignospace. Use the migloc command to determine whether or not file data was purged; if the file remains in premigration, migloc will show a dk method entry for the file. The migrate command creates a list of files in /tmp/migrate_list.pid that meet the migration file selection criteria. The pid is the process ID of the migrate command that is executing. This list is of the following form: age size 0|0|path|machid|handle| where the third field is a default threshold value of 0, and the fourth field is 0 which indicates the migration level for premigration. The machid and handle are both 0 if the file has never migrated before.

Appendix A, Man Pages

383

migrate(1)

OPTIONS -F

Force file migration even if the file is listed in the global stop file or a local stop file, .migstop. This argument is applicable only to Super Users or to owners of the file.

filename

Files that migrate should migate. May be given as a relative path or absolute path. You can specify multiple files or use standard regular expressions. Wildcards are recognized.

-f filelist

Migate the files listed in filelist. The format of filelist is one file name per line, showing either the full pathname of each file or a pathname relative to the current directory in which migrate is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.

CAVEATS ◆

Unless the -F argument is given, migrate will not premigrate any files listed in the global stop file or in a local stop file, .migstop, unless the stop file is overridden. A typical error response is as follows: /ov2/stop/nono found in user stopfile not allowed to migrate

The .migstop file most local to the listed file overrides other stop files higher in the directory tree. Local control files override global control files if the same file or directory is listed in both. If the same file is listed in both a .migrate file and a .migstop file at the same level, the .migrate control file overrides the .migstop file. ◆

Files whose pathname length exceeds 1023 characters will not be migrated.

◆

For non-root users, this command requires that VSM state be Active and the migration daemon migd be running. For root users, this command may be run without regard to the VSM state or whether the migration daemon is running.

EXAMPLES In the following example, the user requests that VSM migrate a file named tproga. # migrate /home/gls/tproga

In the following example, the user has a file named migrate_list that contains a list of files to be migrated, one file per line. # migrate ‘cat migrate_list‘

384

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migrate(1)

The following example uses the find command to select for migration all regular files under a directory, and then uses fls to check if they are migrated. # migrate ‘find /home/gls/hawks -type f -print‘ # fls -l /home/gls/hawks total 94 mr--r--r-- 1 root other 23368 May 9 17:20 osprey mr--r--r-- 1 root other 23368 May 9 17:21 peregrine

FILES /usr/var/openv/hsm/database/migrate Global migrate file for VSM /usr/var/openv/hsm/database/migstop

Global stop file for VSM The following output file is created and used by migrate to premigrate files: /tmp/migrate_list.pid

A list of files in the file system that meet the migration file selection criteria The pid is the process id of the migrate command that is executing. migrate checks the environment variable TMPDIR, which allows the administrator to use a path other than the default /tmp. This can save files through system reboots or make use of a larger file system to avoid running out of space. The path defined by TMPDIR, if set, is used instead of /tmp as the directory in which to place any temporary files. SEE ALSO VSM(1M), fls(1), migloc(1), migmode(1), migpurge(1)

Appendix A, Man Pages

385

migrc(1M)

migrc(1M) NAME migrc - VSM restart and cleanup operations SYNOPSIS /usr/openv/hsm/bin/migrc [-LRSMh] [-o | -O db_type] [-a age] hsmname DESCRIPTION The migrc command provides a variety of functions. Some are intended to be used when restarting VSM operations on a managed file system and some are intended to be used as part of regular VSM operations. Except for the -L option, this command may be run for file systems in the Active, Inactive, or Maintenance states. The -L option should only be used on a managed file system in the Inactive or Maintenance state. The copy activities initiated by the -R and -M options will continue even after the migrc command has completed. OPTIONS At least one of the options L, R, M, h, o or O must be specified. -L

Clear all locks. This option is intended for use only when restarting VSM operations for a file system. migrc -L may be called by the migVSMstartup command for this purpose. migrc -L can only be used for file systems in Maintenance state.

-R

Restart interrupted premigration and migration. Execute migrc -RM following a system interrupt to ensure that any unfinished migration and multilevel migration (migmove) work is completed.

-S

Activate obsolete and dead FHDB entries of all files with VSM handles. The -S option requires at least one option to be specified with it. For example, migrc -R -S HSM1 or migrc -O FHDB -S HSM1. FHDB dk entries are not activated with migrc -S.

386

-M

Restart interrupted migmove work and FHDB flag updates. Execute migrc -RM following a system interrupt to ensure that any unfinished migration and multilevel migration (migmove) work is completed.

-h

Print usage information.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migrc(1M)

-o

(A lowercase o) Remove obsolete/dead entries from all three databases: FHDB, VOLDB and COPYDB.

-O db_type (An uppercase O) Remove obsolete/dead entries from the single database type specified by db_type: FHDB, VOLDB or COPYDB. -a age

The age parameter indicates the age (in days) of obsolete entries to remove from the FHDB. The default age is 7 days. This argument only has meaning when used in conjunction with either the -O FHDB option or with the -o option as it pertains to FHDB entries.

Caution You should use the age parameter to specify removing only files that were obsoleted prior to the last full backup. hsmname

Configured VSM name for the managed file system that you want VSM to process. If you do not specify hsmname, migrc performs the selected operation(s) on all VSM-managed file systems.

CAVEATS ◆

Ensure that a sufficient number of volumes are available for migrations that may occur when you run migrc. Use migreg to register volumes.

◆

Running migrc resets the current threshold and current purge threshold to their respective values as specified in migconf.

◆

If using NetBackup in conjunction with VSM, set the age variable for migrc at a value higher than the longest NetBackup retention period on the managed file system. Do this by changing the line AGE=7 to AGE=nnn where nnn is the longest NetBackup retention period.

◆

If MFLAG_OBSOLETE is set, dk entries will stay in the FHDB when migrc is run. This allows a cached file to be returned to premigration and processed by normal purge operations. To remove these dk entries and reduce the size of the FHDB, run migmdclean.

◆

When migrc completes there may still be VSM processes running that migrc has started.

SEE ALSO VSM(1M), migconfg(1M), migreg(1M), startmigd(1M), stopmigd(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M), migactivate(1M)

Appendix A, Man Pages

387

migrd(1M)

migrd(1M) NAME migrd - VSM request daemon SYNOPSIS /usr/openv/hsm/bin/admincmd/migrd DESCRIPTION Running migrd as a command starts the migrd request daemon. You must have super-user privileges to execute this command. migrd is the VSM request daemon (migrd). You should ensure that migrd is started as part of your system startup. If migrd is not running when you run /usr/openv/java/migsa to start VSM-Java, the GUI cannot connect to the server, and the migsa command fails. SEE ALSO VSM(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)

388

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migreconstruct(1M)

migreconstruct(1M) NAME migreconstruct - Reconstruct lost or deleted migrated files SYNOPSIS /usr/openv/hsm/bin/migreconstruct [-v] [-n] [-o] [-p permissions] [-l out_file | -f | -w in_file] hsmname DESCRIPTION The migreconstruct command reconstructs migrated files either when they have been accidentally deleted or when the file system is damaged beyond repair. (The command cannot reconstruct files that have not been migrated.) The preferred way to do this is to restore migrated files from their backup copies, if created previously by NetBackup. If no backup copies exist, however, use migreconstruct to recover the migrated files. migreconstruct uses information in the file handle database (FHDB) to do the reconstruction. If you are reconstructing a damaged file system, you must first re-initialize the file system. Use fsck, newfs, or mkfs as necessary. The hsmname.IHAND (inode-to-handle) file must be removed before starting migd. The path to the managed directory must exist. And, lastly, the migration/data directories must be created in the managed directory. The migreconstruct command does not overwrite existing files unless the -o option is specified. In all other cases, it only reconstructs lost or deleted migrated files. OPTIONS The following options and parameters are available with migreconstruct: -f

Reconstructs all files that have an entry in the FHDB. This parameter may not be used with -l or -w. Default is no files are reconstructed.

-l out_file Lists in out_file all files that have an entry in the VSM file handle database (FHDB). Does not reconstruct any of these files. This parameter may not be used with -f or -w. Each line in out_file contains the following information: handle|machid|size|uid|gid|permissions|file_path The handle and machid fields are in hexadecimal; size, uid and gid are decimal; and permissions is octal. Default is no out_file. -n

Appendix A, Man Pages

Do not sort FHDB in reverse order. If the FHDB is not sorted in reverse order, the oldest version of a file will be created. The default is to sort the FHDB in reverse order. 389

migreconstruct(1M)

-o

Overwrite existing files. The default is to never recreate an existing file.

-p permissions Permissions to be used if the VSM database entry for the file does not contain the mode of the file. permissions is assumed to be an octal value; the default is 1755. Entries get their permissions from the mode information in the VSM database, with a few exceptions. All files created as a result of the -f option that do not have mode information will be given these permissions, and all entries in the out_file that do not have mode information will be given these permissions. The permission field in the in_file overrides permissions. -w in_file

Reconstructs all files listed in in_file. This parameter may not be used with -l or -f. Each line in in_file should contain the following information: handle|machid|size|uid|gid|permissions|file_path The handle and machid fields are in hexadecimal; size, uid and gid are decimal, and permissions is octal. file_path may be set to any full path in the managed file system. Default is no in_file.

-v

Verbose; lists the full path of all files reconstructed. Default is none are listed.

hsmname

Name of the file system that VSM is managing.

Note One of the options -l, -f, or -w is required to run migreconstruct. To restore accidentally deleted files, create proper in_file entries and use migreconstruct with the -w option. CAVEATS

390

◆

migreconstruct requires that the VSM state to be Active or Maintenance.

◆

All directories created by migreconstruct belong to the user of this utility, and take on whatever permissions are set in the user’s umask. This would normally be root.

◆

migreconstruct will not reconstruct files from method dk.

◆

migreconstruct will reconstruct obsolete migrated files if VSM has not yet removed their corresponding FHDB entry. Obsolete files are no longer obsolete after they have been reconstructed.

◆

Moved or renamed migrated files will be reconstructed in their original locations according to the full path recorded in the FHDB when the files were first migrated.

◆

All reconstructed files will have a 0 slice value.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migreconstruct(1M)

EXAMPLE In the following example, all files that have a full path in the FHDB of VSM-managed file system alpha will be reconstructed and granted default permission 1755. # migreconstruct -v -f alpha

In the following example, all files in VSM-managed file system openv2 with the path name /tmp/out_list will be reconstructed. # migreconstruct -w /tmp/out_list openv2

The file /tmp/out_list contains the following lines: 1861|3e8|105|0|1|1755|/home1/home1/file-23_# 1862|3e8|108|0|1|1755|/home1/home1/file-24_$ 1863|3e8|111|0|1|1755|/home1/home1/file-25_% 1864|3e8|114|0|1|1755|/home1/home1/file-26_& 1865|3e8|117|0|1|1755|/home1/home1/file-27_’

This shows the handle machid size uid gid permissions and file_path for the five files to be reconstructed. FILES dwpath/database/FHDB

File handle database dwpath/database/FNDB

File name database SEE ALSO VSM(1M), migin(1M), newfs, fsck, mkfs, pfinit(1M)

Appendix A, Man Pages

391

migrecycle(1M)

migrecycle(1M) NAME migrecycle - Reregister an empty volume SYNOPSIS /usr/openv/hsm/bin/migrecycle [-h | -a days -v volset -P poolname -d device -c capacity -s server -u user -l new_label -p password] hsmname label method DESCRIPTION The migrecycle command reregisters an empty, registered VSM volume. If the volume is not empty, an error is produced without any change in registration. A volume is considered empty either if it has no FHDB entries for granules or if all FHDB entries for granules on the volume are marked dead. The volume is reregistered with the parameters in the VOLDB unless they are specified as migrecycle options. The volume set, volume pool, device, capacity, server, and the password may be changed by supplying them on the command line. migrecycle maintains the volume assignment to the current file system and volume set. Note When one side of an optical disk is consolidated, the volume entry for that input volume is not removed from the VOLDB until both sides of that disk are empty. migrecycle first calls migmdclean -a days -R with the supplied label and method to remove dead FHDB entries. This is followed by a call to migreg, if the volume is now empty. migmdclean removes obsolete entries from the FHDB that are at least days old. Note, that 7 days is the default value for days defaults. For optical disks, migrecycle trys to recycle both sides of the disk. If migrecycle is asked to alter attributes on an optical disk, both sides of the disk must be empty before a side is recycled. VSM always cleans obsolete entries that are days old, even if the volume cannot be recycled. After a volume is reregistered, any data previously stored on it can no longer be recovered. OPTIONS The following options and parameters are available with migrecycle: -a days

392

Select only obsolete FHDB entries aged by days when cleaning the FHDB. The default value is 7 days.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migrecycle(1M)

-v volset Volume set number used to reregister this volume. If not specified, the volume set number is not changed. -P poolname The name of the volume pool if other than the default, HSM. -d device For recycling ad method volumes, this is the path to the file system. For recycling ft method volumes, this is the file system path on the remote volume server. -c capacity Capacity of the remote file system for the ft method. -s server Name of the remote volume server system for ft method. -u user

For the ft method, this is the valid ftp user name on the remote volume server system.

-p password For the ft method, this is the name of the server password. -l new_label Label used to reregister the volume. -h

Print help information.

hsmname

Configured VSM name for the managed file system containing the database that has an entry for the volume you are recycling.

label

This is the name of the label that VSM assigns to the remote file system for identification. The label is a single line of text in a file named ID_LABEL that is stored in the remote file system.

method

Volume method name. It can be ct, dt, mt, ad, op, or ft. Volumes for the ow and nb methods cannot be recycled.

Note The nb method will not be supported after the VSM 4.5 release. If the method is ft, a prompt is issued for the password when the volume is reregistered. CAVEATS ◆

When recycling an ft volume, the remote file system must be available so the ID_LABEL file, if present, can be read.

◆

If one side of a rewritable optical disk (method name op) is empty and the other contains granules, you can recycle the empty volume but not change its attributes, and the volume set number remains the same for both sides.

Appendix A, Man Pages

393

migrecycle(1M)

EXAMPLE In the following example, an mt volume EXB001 is reregistered in volume set 1. # migrecycle -v 1 alpha EXB001 mt

FILES dwpath/database/VOLDB Volume database. dwpath/database/migconf

Configuration file for the managed file system(s). SEE ALSO VSM(1M), migreg(1M), migmdclean(1M)

394

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migreg(1M)

migreg(1M) NAME migreg - Register and label volumes for VSM SYNOPSIS /usr/openv/hsm/bin/migreg [-F] [-D] [-P poolname] hsmname methname volume_set_number volume_name [volume_name]... /usr/openv/hsm/bin/migreg [-F] hsmname ad volume_set_number mount_point volume_name [mount_point volume_name]... /usr/openv/hsm/bin/migreg [-F] [-u user [-p password]] hsmname ft volume_set_number server_name server_directory capacity volume_name [server_name server_directory capacity volume_name]... /usr/openv/hsm/bin/migreg [-F] hsmname nb volume_set_number policy_name NB_master NB_client schedule capacity volume_name [schedule capacity volume_name]... DESCRIPTION The migreg command registers and labels volumes for VSM. For local secondary storage, you can register tapes for use by method names ct, dt, and mt, or optical disk surfaces for use by method name op or ow. You can also register disk partitions as alternate magnetic disk volumes for use with method name ad. Note When using migreg to register and label new, unused tape volumes, it is normal behavior to receive some routine error messages. For remote secondary storage, you can register remote file system directory names for use by method name ft. You can also register disk partitions as alternate magnetic disk volumes for use with method name ad on remote systems. You can register a NetBackup policy as a volume for use by method name nb. Note The migreg command does not register volumes for method name dk. migreg registers all volumes in the VSM volume database, dwpath/database/VOLDB for the hsmname. After registration, VSM can use these volumes on subsequent migrations requiring the corresponding method name associated with each volume. OPTIONS The following options and parameters are available with migreg: Appendix A, Man Pages

395

migreg(1M)

Caution Use the -F option with extreme caution, as it may prevent access to files already migrated to the volume. -F

Forces the relabeling of a previously labeled volume. The volume must not be registered currently in any VSM volume database. If necessary, you can use migmdclean -R to remove an entry from a VOLDB. You may also use migsetdb to set an empty volume to dead in a VOLDB so it can be removed by migrc and relabled by migreg. If -F is not specified, VSM returns an error if you attempt to register a volume that has already been labeled.

-D

Delay labeling of tape or optical disk until needed. This argument affects only volumes registered for the ct, dt, mt, op, and ow method names. If specified for other method names, VSM posts a message and then proceeds with the normal registration process. If -D is not specified, the volume is labled at the time migreg is run.

-P poolname The name of the volume pool if other than the default, HSM. -u user

User name used for the ftp login request when VSM migrates files or caches files from the server with method name ft. If not supplied on the command line, it is read from stdin. If stdin is a tty, a prompt is issued.

-p password Password used for the ftp login request with method name ft. It must be a valid password for user on the remote volume server. If not supplied on the command line, it is read from stdin. If stdin is a tty, a prompt is issued. hsmname

Configured VSM name for the managed file system containing the database in which you want to record the volume information.

methname The method name under which this volume will be recorded. Valid values are ct, dt, mt, op, and ow. Any method name used with migreg (including ad, ft, and nb) must be defined in the dwpath/database/migconf configuration file for hsmname. volume_set_number The integer number of the volume set of which this volume is a part. Setting the volume_set_number parameter to 0 causes the volume to be assigned to any volume set with the same method when it is needed for writing. A unique volume set is denoted by both the method name and volume set number. Volume sets provide a means within VSM of specifying the volumes on which a particular copy of a migrated file is placed. This is useful when a library device is being used to manage your migrations.

396

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migreg(1M)

volume_name The name of the volume to be recorded on the volume and in the volume database VOLDB. For NetBackup volumes, the volume_name is only recorded in the VOLDB, not on the volume. VSM restricts volume names to an alphabetic character followed by up to five alphanumeric characters, and converts all lower case input to upper case. mount_point The file system mount point required when registering a volume for use with method name ad. Make sure the file system is mounted before registering the volume. server_name Name of the remote volume server for ft volumes. This can be the internet id or number of the server. VSM uses this name on the ftp open command as the host parameter. It must be a valid ftp host. server_directory Absolute pathname of a directory on the host identified by server_name for use by method name ft. The user must have read and write permissions to this directory. This can be any directory on the remote volume server identified by server_name that is not already registered for VSM. capacity

Capacity, in bytes, of the remote file system or NetBackup volume that is available for VSM to use for storing migrated files. A value of 0 is interpreted as unlimited storage capacity.

policy_name The name of the NetBackup policy. NB_master Name of the master NetBackup server for nb volumes. NB_master must be the first name the server is known by to NetBackup. Note The nb method will not be supported after the VSM 4.5 release. NB_client

Name used for nb volumes to register the client under NetBackup. It must be the name used to register the client in the NetBackup policy.

schedule

The name of the NetBackup schedule.

CAVEATS ◆

Using the -F option to force write a new label destroys all information that may be on the volume.

◆

Always use the -F option if the media is already labeled and you wish to reuse the volume.

Appendix A, Man Pages

397

migreg(1M) ◆

The device-manager daemon ltid must be running if you are registering ct, dt, mt, op or ow method names.

◆

When you register one side of an optical disk, VSM also automatically registers the other side with the same volume set number. This avoids deadlocks during volume consolidation and when moving files between migration levels.

◆

If migrating two copies of a file, it is good practice to migrate copy 1 and copy 2 to different volume sets, such as to ct.1 and ct.2 or to ct.1 and dt.1. This avoids the chance of losing both copies when a volume is damaged or lost.

◆

To specify a password on the command line with the -p parameter is less secure that to let the command line prompt for input.

EXAMPLES The following example for hsmname alpha registers a dlt tape (method name dt) with the name ARC001, and assigns it to volume set number 2. # migreg alpha dt 2 ARC001

The following example for hsmname alpha registers three cartridge tapes (method name ct) with the names CT001, CT002, and CT003, and assigns them to volume set number 0. Later, when a different ct volume set needs another volume, VSM can assign this tape to that volume set and re-register it with the new volume set number. Tapes are labeled when they are needed. # migreg -D alpha ct 0 CT001 CT002 CT003

The following example for hsmname alpha registers two disk partitions on device names /dev/dsk01 and /dev/dsk02 as alternate magnetic disk volumes (method name ad) with the names ARC900 and ARC901, and assigns them to volume set number 4. # migreg alpha ad 4 /dev/dsk01 ARC900 /dev/dsk02 ARC901

The following example for hsmname alpha attempts to register two sides of optical disk AB001, but cannot do so because the volume on side B of the platter is already registered. (VSM had registered side B automatically the first time it had registered side A.) # migreg alpha op 0 AB001A AB001B Tape label: AB001B already registered to HSM

The following example for hsmname alpha registers a remote file system directory (method name ft) at pathname /sdisk3 on server greek2me with the name FTD001, and assigns it to volume set number 1 with a capacity of 600,000,000 bytes (about 572 MB). The user name is fred and the password is HsMk2$. # migreg -u fred -p HsMk2$ alpha ft 1 daneel /sdisk3 \ 600000000 FTD001

398

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migreg(1M)

The following example for hsmname alpha registers NetBackup policy hsmnb on NetBackup server duo as a NetBackup volume (method name nb), and assigns it to volume set number 1 with NetBackup schedule sk01 and infinite capacity (0). # migreg alpha nb 1 hsmnb duo duo sk01 0 NB001 Capacity set to unlimited. Registered vh_label=NB001 [at hsmnb] as vh_handle=104A and method= nb

FILES dwpath/database/VOLDB Volume database. dwpath/database/migconf

Configuration file. SEE ALSO VSM(1M), migbatch(1M), migconf(1M), migconfg(1M), migdbrpt(1M), migmdclean(1M), mignospace(1M), migsetdb(1M)

Appendix A, Man Pages

399

migselect(1M)

migselect(1M) NAME migselect - select volumes for consolidation SYNOPSIS /usr/openv/hsm/bin/migselect [-o] hsmname low_high volume_set method DESCRIPTION The migselect command selects a set of volumes for consolidation according to the percentage of volume usage. The percentage occupancy can have low-range and high-range values. This utility provides only a model in selecting the volumes and a site can modify it to meet specific requirements. The output is of the form label.method.volume_set. migcons accepts this format in a list of input volumes to consolidate. Only the system administrator may use this utility. OPTIONS -o

Causes migselect to base its selection on the percentage of a full volume that is obsolete. If this parameter is not specified, the selection is based upon the percentage of a full volume that is both active and obsolete.

hsmname

Configured VSM name for the managed file system containing the database that has information on these volumes. This parameter is required.

low_high

Volume use expressed as limits of low and high percent (for example, 20.05-30.75). This parameter is required.

volume_set The name of the volume set to use. This parameter is required. method

Method name under which migselect selects volumes. Allowed values for method are ad, ct, dt, mt, op, or ow. This parameter is required.

CAVEATS

400

◆

This command does not select volumes that have the W flag set.

◆

This command ignores dead volumes.

◆

Write overhead on the volume is not considered in choosing the low and high range values for percent occupancy. VERITAS Storage Migrator System Administrator’s Guide for UNIX

migselect(1M)

EXAMPLE The following example selects volumes in ct volume set 1 and ad volume set 1, that have percentage occupancy between 1 and 10 percent. # migselect alpha 01.00-10.00 1 ct ad RAO001.ct.1 GLS002.ad.1

The following example selects cartridge tape volumes less than 20 percent full that are on volume set 2. The output of migselect is used as input to consolidation (see migcons(1M)). # migcons alpha one ct 2 ‘migselect alpha 0.00-20.00 2 ct‘

The following example selects volumes in op volume set 1, that are at least 50 percent obsolete and consolidates them to op volume set 1. # migcons alpha one op 1 ‘migselect alpha -o 50.0-100 1 op‘

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database for VSM. /usr/var/openv/hsm/database/migconfg Global configuration file for the VSM server SEE ALSO migconf(1M), migcons(1M), miggetvol(1M), migmdclean(1M), migrecycle(1M)

Appendix A, Man Pages

401

migsetdb(1M)

migsetdb(1M) NAME migsetdb - allows you to alter the flags field in the FHDB or the VOLDB SYNOPSIS /usr/openv/hsm/bin/migsetdb -F [-a | d | O] [-h hint] [[-m methname [-L label]] -i worklist_file [-s setlevel] hsmname migsetdb -F [-a | d | O] [-h hint] [[-m methname [-L label] [-K]] [-M machid] [-s setlevel] hsmname handle [handle]... migsetdb -V [-a | C | d | e | f | l | w | R | T] hsmname label [label]... migsetdb -V [-u new_user] [-p] hsmname label [label]... migsetdb -V [-u new_user] [-P password] hsmname label [label]... migsetdb -V -U user [-P password] hsmname DESCRIPTION VSM uses the migsetdb command to select and change the state of the file handle database (FHDB), the file name database (FNDB), and volume database (VOLDB) entries automatically. Administrators can also use migsetdb to fix inconsistencies not corrected by migdbcheck. An administrator can use migsetdb to perform the following functions:

402

◆

Mark all FHDB entries as active, obsolete, or dead. Finer granularity may be used by specifying method, volume label, and level. This also allows only the last copy found with the finer granularity to be set by VSM.

◆

Mark specific file handle as active, obsolete, or dead. Finer granularity may be used by specifying method name, volume label, migration level, and -K.

◆

Alter the hint value in FHDB entries for a specific handle. This choice also allows a subchoice by method and/or level and/or volume. Also allows hint to be set for last copy found at subchoice.

◆

Alter the hint value in FHDB entries for a specific file handle. This choice allows a sub-choice by any or any combination of method, level and volume. It also allows the hint value to be set for the last copy found at method, level, and/or volume.

◆

Alter the flags field in the VOLDB to any valid value for the label(s) specified or change the only password, only the user name, or both the password and use name, for the volumes that match the label(s) specified.

◆

Change all passwords for individual users in the VOLDB. VERITAS Storage Migrator System Administrator’s Guide for UNIX

migsetdb(1M) ◆

Additionally, the command may be called by migmove to mark all FHDB entries in the supplied worklist file as active, obsolete, or dead.

migsetdb creates the file /tmp/migsetdb.pid when changing flags on FHDB entries. For changing users or passwords in the VOLDB, migsetdb creates the file /tmp/migsetdb-tmp-voldb.pid. However, migsetdb checks the environment variable TMPDIR, which allows the administrator to use a path other than the default /tmp. This can save files through system reboots or make use of a larger file system to avoid running out of space. The path defined by TMPDIR, if set, is used instead of /tmp as the directory in which to place any temporary files. The process ID of the migsetdb that is executing replaces pid. No files should be left after successful execution. This command may be run without regard to the VSM state or whether the migration daemon migd is running, except that the -L label can only be run in Maintenance state. OPTIONS Caution Inappropriate use of migsetdb may make migrated files inaccessible or make the FHDB inconsistent. -F

Make changes to the filehandle database, FHDB.

-V

Make changes to the volume database, VOLDB.

-a

Set the flags field of the specified FHDB, FNDB, or VOLDB entry to active (or 0). This is the default for the VOLDB when neither -a nor -d are specified. Default for the FHDB and FHDB when neither -a nor -d nor -O are specified is the condition specified in migconf.

-C

Set the corrupt flag field of the specified VOLDB entry. VSM does not automatically set the corrupt flag. It must be set by migsetdb.

-d

Set the flags field of the specified FHDB or VOLDB entry to dead.

-O

Set the flags field of the specified FHDB entry to obsolete.

-e

Set the flags field of the specified VOLDB entry to empty.

-f

Set the flags field of the specified VOLDB entry to full.

-h hint

A hint of l indicates Library volume set availability (highest). A hint of o indicates Operator volume set availability (lower; no longer configurable with VSM-Java). A hint of v indicates Vault volume set availability (lowest; generally offline).

-l

Set the flags field of the specified VOLDB entry to NEEDLBL, indicating that this VOLDB entry needs to be labeled.

Appendix A, Man Pages

403

migsetdb(1M)

-L label

Only change FHDB entities that reference this volume label. This option can only be run when the VSM state is Maintenance.

-K

Set only the flags for the last occurrence of handle that matches with -s level, -m methodname, and -L label. The -s, -m, and -L are required.

-w

Set the flags field of the specified VOLDB entry to write.

-R

Set the flags field of the specified VOLDB entry to NDLBLFRC, indicating that this VOLDB entry needs to be force-labeled.

-T

Set the flags field of the specified VOLDB entry to indicate no trailer label on tape.

-m methname Set the flags field for FHDB entries with migration level setlevel only if they match method name methname and either handle or the files specified in worklist_file. These method names must be defined in the dwpath/database/migconf configuration file for hsmname. When -m is not specified, entries at setlevel will be modified without regard to methname. Specifying -M machid further restricts which FHDB entries are modified. -i worklist_file Set the flags field for FHDB entries with migration level setlevel only for the files specified in worklist_file. The format of each line of worklist_file is as follows: handle|machid|lock|flags|volset|copied|method|dest_seek| threshold|size|age|path|hint|comment|mmlevel|slevel| Do not set the flags field for FHDB entries with migration level mmlevel, where mmlevel is an integer in the range 1 to 8. FHDB flags at mmlevel will not be obsolete. -s setlevel The migration level for which to set FHDB flags, where setlevel is an integer in the range 0 to 8. VSM logs and outputs a warning message if setlevel is greater than 8. Specifying -m methname or -M machid further restricts which FHDB entries are modified. If -s setlevel is not specified, all levels except 0(dk) are set. -M machid Set the flags field for FHDB entries with migration level setlevel only if they match machine ID machid and handle. When -M is not specified, entries at setlevel are modified without regard to machid only if they match handle and all entries for a particular handle have the same machine ID. VSM skips entries at setlevel that match a particular handle but have more than one machine ID, and logs an error message advising

404

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migsetdb(1M)

you to execute migsetdb with the -M option in order to set the flags field for the handle in question. Specifying -m methname further restricts which FHDB entries are modified. hsmname

Configured VSM name for the managed file system containing the database files you want to alter.

handle

Set the flags field for FHDB entries with migration level setlevel only for the files with file handle handle.

label

The volume label of the entry to change in the VOLDB.

-u new_user Change the user name to new_user for each entry with the volume label specified by label. -U user

(Change the password at the prompt for all VOLDB entries that match the user name specified by user.

-p

Change the password at the prompt(s) for each entry with the volume label specified by label.

-P password Change the password as specified by the password variable on the command line, rather than at the prompt. CAVEATS ◆

Using the lower case ‘p’ (-p) option to change the password at a prompt is generally more secure than using the upper case ‘P’ option ( -P) and specifying the password as part of the command line.

◆

It is possible to obsolete all entries in the FHDB for any file. This could cause them to be deleted when migrc is run to consolidate the FHDB, making the files inaccessible.

◆

The migrc command removes all FHDB, FNDB, and VOLDB entries marked dead.

◆

Do not mark entries for method name ad or ft dead; mark them obsolete instead. This prevents them from being incorrectly removed by migrc. These entries are correctly removed from the FHDB by migmdclean as it cleans the disk.

EXAMPLES The following example for hsmname alpha sets the FHDB flags field to the condition specified in the configuration file migconf for all entries with a migration level of 6. # migsetdb -F -s 6 alpha

The following example for hsmname beta sets the FHDB flags field to dead for all entries with method name ct and a migration level of 1. # migsetdb -Fd -m ct -s 1 beta Appendix A, Man Pages

405

migsetdb(1M)

The following example for hsmname chi sets the FHDB flags field to obsolete for all files specified in the worklist file wlst0001 with a migration level of 3 and a mmlevel other than 3. # migsetdb -FO -i wlst0001 -s 3 chi

The following example for hsmname gamma sets the VOLDB flags field to dead for all entries with label FT001. # migsetdb -Vd gamma FT001

In this case, the VSM log would show a record resembling the following: 03/31 13:56:15 [12]migsetdb[8506]: VOLDB label: FT001 flags=0010

These records indicate the flags are set to dead. Similarly, the following example for hsmname theta clears the VOLDB flags field for all entries with label FT001. # migsetdb -Va theta FT001

In the following example for hsmname omikron, migsetdb is called by migmove. # migmove -s 5 omikron

In this case, the VSM log would show records resembling the following: 03/11 14:35:49 [15]migsetdb[2810]: fh=3E8ME1035 level=5: flags=08 03/11 14:35:50 [15]migsetdb[2810]: fh=3E8ME1036 level=5: flags=08 03/11 14:35:50 [15]migsetdb[2810]: fh=3E8ME1037 level=5: flags=08

These records indicate the flags are set to dead. The following example for hsmname xi sets the new user name to km and prompts for a new password for all entries with label FT001 or FT002. # migsetdb -Vp -u km xi FT001 FT002

A password is requested and confirmed for each specified volume. Enter the password for label: FT001 user:km Reenter the password for label: FT001 user:km Enter the password for label: FT002 user:km Reenter the password for label: FT002 user:km

These volumes now list name01 as the new user name in the VOLDB. The following example for hsmname xi prompts once for a new password for user name lm. # migsetdb -V -U lm xi

406

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migsetdb(1M)

To change many volumes to a new owner with a single password, you can use the previous two forms of this command in combination. In the following example for hsmname xi, the first instance sets the new user name to jn for all entries with the specified labels, and the second instance prompts once for jn’s new password. # migsetdb -V -u jn xi VOL1 VOL2 VOL3 VOL4 VOL5 VOL6 VOL7 # migsetdb -V -U jn xi

This avoids repetitive password prompts for each reassigned volume. FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/VOLDB

Volume database dwpath/database/FHDB

File handle database dwpath/database/FNDB

File name database for VSM dwpath/database/migconf

Configuration file for managed file systems /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server /tmp/hsm.log

Global log file for the VSM server lgpath/hsm.hsmname.log

VSM log file. The term lgpath refers to the path name of the log file for a VSM managed file system. SEE ALSO VSM(1M), migconf(1M), migconfg(1M), migmove(1M), migdbcheck(1M)

Appendix A, Man Pages

407

migstage(1)

migstage(1) NAME migstage - cache one or more files before recalling from secondary storage SYNOPSIS /usr/openv/hsm/bin/migstage [-w] [-R] pathname [pathname ...] /usr/openv/hsm/bin/migstage [-w] [-R] -f filelist A more advanced command synopsis for use by experienced administrators who can determine expected results is as follows: /usr/openv/hsm/bin/migstage [-w] [-R] [-c] [-m method] [-n -levelno] [[-f filelist ] [pathname [pathname ...]] DESCRIPTION The migstage command examines a set of files and caches them back to disk. Optionally, migstage will wait until all of the files have been cached before exiting. This command lets you cache one or more migrated files before you need to access them in order to avoid caching delays at the time of access. The specified files are cached in their entirety, even when partial file caching is enabled. migstage attempts to optimize the reload operation by grouping all of the files for a given volume ID and hsmname together. Generally the VSM state must be Active to stage a file, although a root user can stage files when VSM is in Maintenance state. The migd migration daemon need not be running. OPTIONS -w

Specifies that migstage is to wait for all of the files to be cached back to disk before exiting. The default is to initiate caching and then exit while caching operations continue in the background.

-R

Specifies that if migstage encounters a directory name in a filelist, it will stage all files in that directory and its subdirectories.

-c

Specifes that migstage ignores checksum (crc) errors when caching files. Normally, caching from tape fails if the crc computed from the data does not match the crc in the granule header. When -c is specified, the cache operation succeeds even if the crc check fails. This option is intended to be used only as a last resort when a file cannot be recovered the usual way. The file data cached back with the -c option may not be the originalfile data.

408

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migstage(1)

-m method Stage the file from the specified method. The method is one of ad, ct, dt, mt, op, ow, ft, nb, or dk storage methods. -n levelno Stage the file from the specified levelno. The levelno is a number from 1 to 8 that is associated with a migration level from which you want the file to be staged. migstage ignores checksum (crc) errors when caching files. Normally, when caching a file from tape the cache operation fails if the crc computed from the data does not match the crc in the granule header. pathname Files or directories that migstage should pre-cache. If a directory is specified, or the -R option was used, all files in the directory and its subdirectories are cached. May be given as a relative path or absolute path. You can specify multiple files or directories, or use standard regular expressions. Wildcards are recognized. -f filelist

Pre-cache the files listed in filelist. The format of filelist is one file name per line, showing either the full pathname of each file or a pathname relative to the current directory in which migstage is executed, not the directory in which the file in the filelist resides. Wildcards are not recognized.

EXAMPLES 1. The following command pre-caches all files in the current directory and its subdirectories, even if the directory was not migrated as a part of a group. # migstage -R . &

The prompt returns quickly, and caching continues in the background. 2. The following command stages all files listed in stagelist and waits for all staging to complete before exiting. # migstage -w -f stagelist

The file stagelist reads as follows: /usr/mydir/subdir/f1/* /usr/yourdir/subdir/f2

3. The following command pre-caches all files whose file names begin with the string June_23. # migstage June_23*

SEE ALSO VSM(1M), fls(1), miggroup(1), migungroup(1), migloc(1), migtie(1)

Appendix A, Man Pages

409

migtestbadness(1M)

migtestbadness(1M) NAME migtestbadness - allows you to check what effect changing the threshold computation parameters has on migration operations SYNOPSIS /usr/openv/hsm/bin/migtestbadness hsmname pathname [threshold threshold_formula 2 [lowwater | kilobytes_to_reduce] test_mode number_of_files] DESCRIPTION The migtestbadness command lets you assess the results of configuring different values for threshold, minimum file age and file size, weighting factors and weight operators to determine the amount of free space that could be selected during a typical migration operation. You can see the graphical results of running such tests by invoking the VSM File System Analyzer and selecting What If. Each test of a file system lists the files that have calculated thresholds exceeding the specified threshold and computes the total file space that could be freed by this operation. This total file space is recomputed each time migtestbadness is run with different values for the file system attributes. By testing different file systems in this way, you can choose the optimum values to use in VSM configuration. The values for each migtestbadness option can be customized. OPTIONS hsmname

The VSM name under which the swept file system is defined.

pathname The directory to sweep. It should be specified as a full absolute path. threshold

The threshold value for this test. Files that exceed this value are identified as migratable. If not configured, the default value is 30

threshold_formula All of the threshold criteria to be used in this test. Files that have a threshold factor greater than this value are identified. The formula is as follows: threshold_result=(age_weight (min_age)) weight_operator (size_weight (min_size)) On the command line, the values are specified in the following order: 410

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migtestbadness(1M)

threshold min_age min_size age_weight size_weight weight_operator The age is always the number of days since the last access or since last modification, whichever is greater. The values used in the formula are all user-configurable and are descibed as follows: threshold: The threshold value for this test. Files that exceed this value are identified as migratable. If not configured, the default value is 30. min_age: Age of the file. Include files that have not been accessed or modified within this time. If not configured, the default value is 1. min_size: Size of file (in kilobytes). Include files that are at least this large. If not configured, the default value is 1. age_weight: Weighting to be used for age in the threshold factor. If not configured, the default value is 1. size_weight: Weighting to be used for size in the threshold factor. If not configured, the default value is 1. weight_operator: The operator to be used in calculating the threshold factor. If not configured, the default is 0: 0 = multiply 1 = add 2 = site selected If 2 (site selected) is used, migsweep.site.sh is called. 2

File system type is hsm.

lowwater

To identify all available files, set lowwater=0. If lowwater does not equal 0, you must specify kilobytes_to_reduce to stop this test. This is a user-configurable value. If not configured, the default is 0. If lowwater is larger than 0, you must also set the kilobytes_to_reduce value.

kilobytes_to_reduce The maximum amount of free space to be found before stopping this test. This value is valid and must be specified if lowwater does not equal 0. If lowwater=0, this value, if specified, is ignored. You must set the kilobytes_to_reduce value if lowwater is larger than 0. test_mode List files to output. This user-configurable value defaults to 1: 1 = print header messages 2 = don’t print headers number_of_files The maximum number of files to be found before migtestbadness stops. This user-configurable value defaults to 0, which equals no limit. Appendix A, Man Pages

411

migtestbadness(1M)

EXAMPLES 1. To perform its tests, migtestbadness works through its formulas as follows: a. Is the age of the file greater than min_age? If the answer is no, the file is not selectable. If the answer is yes, the command moves to the next step. b. Is the size of the file greater than min_size? If the answer is no, the file is not selectable. If the answer is yes, the command moves to the next step. c. Calculate the threshold of the file bases on the threshold_formula. Move to the next step. d. Is the threshold of the file greater than or equal to result of the threshold_formula? If the answer is yes, the file is selectable for migration. If the answer is no, the file is not selectable. Therefore, if you wanted to select files for migration that are 9 hours old, regardless of size, the beginning of the migtestbadness command would be as follows for a managed file system named delta: # migtestbadness delta /delta 9 0 0 24 0 1

The age_weight is set to 24 because the value for threshold is in hours. Following the command through its calculation, its sequence to determine that a file is selectable if it is more than 9 hours old regardless of size, is as follows: a. 9/24 is greater than 0, so the file is selectable. b. min_size will be greater than 0 in this calculation because any existing file is more than 0 KB, so the file is selectable. c. (9/24 x 24) +0 =9 d. 9 is greater than or equal to 9, so the file is selectable for migration. 2. In the following test, the hsmname is sigma_6. The pathname is /sigma_6. The threshold_formula is as follows: threshold is 1; min_age is 1; min_size is 1; age_weight is 1; size_weight is 1; weight_operator is 1. The file system type is 2. kilobytes_to_reduce=4000:

412

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migtestbadness(1M)

The test_mode and number_of_files are not specified and default printing headers and no limit being set on the number of selectable files. # migtestbadness sigma_6 /sigma_6 1 1 1 1 1 1 2 4000 age + size = badness pathname --- ---- ------- -------1.10 1025 1026 /sigma_6/test1/retrieve_file.1.6713 1.11 1025 1026 /sigma_6/test1/retrieve_file.1.7813 9.04 10 19 /sigma_6/test1/1 9.04 10 19 /sigma_6/test1/2 2.10 100 102 /sigma_6/test1/filler.93.7813 2.10 100 102 /sigma_6/test1/filler.94.7813 2.10 100 102 /sigma_6/test1/filler.95.7813 2.10 100 102 /sigma_6/test1/filler.96.7813 2.10 100 102 /sigma_6/test1/filler.97.7813 1.11 1025 1026 /sigma_6/test1/retrieve_file.1.9805 2.10 100 102 /sigma_6/test1/filler.15.9805 2.10 100 102 /sigma_6/test1/filler.16.9805 2.10 100 102 /sigma_6/test1/filler.17.9805 2.10 100 102 /sigma_6/test1/filler.18.9805 2.10 100 102 /sigma_6/test1/filler.19.9805 2.10 10 12 /sigma_6/test1/filler.20.9805 2.10 10 12 /sigma_6/test1/filler.21.9805 2.10 10 12 /sigma_6/test1/filler.22.9805 2.10 10 12 /sigma_6/test1/filler.23.9805 2.10 10 12 /sigma_6/test1/filler.24.9805 2.10 100 102 /sigma_6/test1/filler.9.10960 selected: 21 files, 4077 Kbytes 3 migrated files 3051 Kbytes

3. In the following test, the hsmname is sigma_6. The pathname is /sigma_6. The threshold_formula is as follows: threshold is 30; min_age is 2; min_size is 1; age_weight is 1; size_weight is 1; weight_operator is 0. The file system type is 2. The kilobytes_to_reduce is 400. The test_mode and number_of_files are not specified and default printing headers and no limit being set on the number of selectable files. # migtestbadness sigma_6 /sigma_6 30 2 1 1 1 0 2 400 age + size = badness pathname --- ---- ------- -------2.10 100 102 /sigma_6/test1/filler.93.7813 2.10 100 102 /sigma_6/test1/filler.94.7813

Appendix A, Man Pages

413

migtestbadness(1M)

2.10 100 2.10 100 2.10 100 selected:

102 /sigma_6/test1/filler.95.7813 102 /sigma_6/test1/filler.96.7813 102 /sigma_6/test1/filler.97.7813 5 files, 460 Kbytes 0 migrated files 0 Kbytes

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/migconf

Configuration file for managed file systems /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server SEE ALSO VSM(1M), migconf(1M

414

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migtie(1)

migtie(1) NAME migtie - designate the key caching file(s) for a caching group SYNOPSIS /usr/openv/hsm/bin/migtie -a | -d groupname file_path [file_path]... /usr/openv/hsm/bin/migtie -a | -d -h hsmname groupname file_handle [file_handle]... /usr/openv/hsm/bin/migtie [-l] hsmname groupname /usr/openv/hsm/bin/migtie -f -a | -d groupname DESCRIPTION The migtie command lets users add, delete, or list key caching files for a caching group. A caching group is a list of files to be cached together. A caching group file defines this list. The following steps outline the general rules for migrating files as a group. 1. Create a caching group file before using migtie. If the caching group file is a zero length file, every file in the directory containing the caching group file will be cached back along with every file in all of its subdirectories. If the caching group file contains pathnames relative to the current directory, it will cache all files and directories specified in the caching group file. If a directory is cached, every file within that directory all of its subdirectories will be cached. Wildcard characters are recognized. If the caching group file contains full file pathnames, every file in the caching group will be cached back. Wildcard characters are not recognized. Directory names are ignored. Key caching files may be, but need not be, listed in the caching group file. The name of the caching group file is .groupname. Locate the .groupname file at a level in the managed file system higher than or equal to all of the key caching files to which it is tied, and include it in the user’s .migstop file to prevent its migration. 2. Choose which files you will designate as key caching files. Use the migtie command to tie one or more of these key caching files to a caching group file. Users can use migtie to add, delete, or list only those key caching files which they own. The command exits if it encounters a key caching file not owned by the command user.

Appendix A, Man Pages

415

migtie(1)

Whenever a key caching file is cached, all files listed in the caching group file tied to it are also cached. The key caching file and all files listed in the caching group file are cached in their entirety, even when partial file caching is enabled. Files can appear in more than one caching group file, as shown in the examples. A key caching file may only be tied to one caching group file. A caching group file may list a key caching file for another caching group. This command may be run without regard to whether the migd migration daemon is running, but the VSM state must be Active, unless you have root privileges. Root users can run the command if the VSM state is Maintenance. OPTIONS -a

Add key caching files for a caching group.

-d

Delete key caching files for a caching group.

-f

A file containing a list of pathnames that will be added or deleted.

Note You must use -f if any file names contain white space. -l

List the key caching files for a caching group (default).

-h

Identify key caching files by file handle rather than by file path.

groupname Identifies the caching group file listing the files to be cached together. The groupname cannot exceed eleven characters. hsmname

Configured VSM name for the managed file system to use for migtie.

file_path

Absolute or relative pathname of the key caching file(s).

file_handle File handle of the key caching file(s). CAVEATS

416

◆

Creating a caching group file of zero length or one containing relative pathnames can increase caching activity unnecessarily if used in situations where it is not necessary to cache entire directories and their subdirectories at one time.

◆

When migtie designates a file to be a key caching file it modifies the comments field of the file’s FHDB entry. Only files with a FHDB comments field containing “Auto VSM run” or “User selected” or a term with a dot “.” prefix can be designated to be key caching files.

◆

If you choose a file to designate as a key caching file while it is still in premigration, and then cache that file before it has been fully migrated to secondary storage, the designation will be lost when the file is later re-migrated. Although this is a rare

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migtie(1)

occurrence, you can ensure that the designation will not be lost by using the migloc command to verify the migrated status of the file before either initially designating the file or caching it for the first time. ◆

If you cache the files in a caching group tied to a key caching file before all the copies of those files have been made, re-migrating the files at a later time will create new file handles. Execute migtie again for each of these files.

◆

If you change the name or full path of any file listed in a caching group file, caching a key caching file tied to that caching group file will no longer cache the changed file unless you modify the caching group file accordingly.

◆

A reference only to the slice portion of a key caching file will not cause the files listed in the caching group file to be cached.

◆

If a key caching file has not been purged, caching it will not cause the files listed in the caching group file to be cached.

◆

If the key caching files are renamed after they are included in a caching group, they no longer work as key caching files.

◆

You must use the -f option if you will use file names with white space in them.

◆

The miggroup command is implemented using a tie group named MigGroup. Using this same name in your own migtie command will interfere with any current or future use of miggroup in this file system.

EXAMPLE 1 Create a caching group file in /home/user1/.month_tie for the following caching group: /home/usr1/monthly_project/run_project.1 /home/usr1/monthly_project/run_project.2 /home/usr1/monthly_project/data.1 /home/usr1/monthly_project/data.2 /home/usr1/quarterly_project/data /home/boss/reports/monthly_project/user1/her_input

Designate key caching files for this caching group with the following command: # migtie -a month_tie /home/usr1/monthly_project/run_project.1 \ /home/usr1/monthly_project/run_project.2 When the user executes either program run_project.1 or run_project.2, VSM will automatically cache all of the files listed in /home/usr1/.month_tie. Normal read, write, and execute permissions pertain to these cached files. If the user accesses only /home/usr1/monthly_project/data.1, which is not a key caching file, no other files would be cached automatically.

Appendix A, Man Pages

417

migtie(1)

EXAMPLE 2 Create a caching group file in /home/user1/.month_tie for the following caching group: monthly_project quarterly_project/d*

Designate key caching files for this caching group with the following command: # migtie -a month_tie /home/usr1/monthly_project/run_project.?

When the user executes either program run_project.1 or run_project.2, VSM will automatically cache all of the files listed in /home/usr1/.month_tie. This includes all files in the /home/user1/monthly_project directory and its subdirectories as well as any files or directories beginning with the character d in the /home/user1/quarterly_ project directory. EXAMPLE 3 Create a caching group file in /home/user1/.quarter_tie for the following caching group: /home/usr1/monthly_project/data/output /home/usr1/quarterly_project/data /home/boss/reports/monthly_project/user1/her_input

Designate a key caching file for this caching group with the following command: # migtie -a quarter_tie /home/usr1/quarterly_project/run_project

When the user executes the program run_project, VSM will automatically cache all of the files listed in /home/usr1/.quarter_tie. Note that the key caching file does not need to be listed in /home/usr1/.quarter_tie for this to occur. FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM SEE ALSO VSM(1M), gethsm(1), migin(1M), miggroup(1), migungroup(1), migstage(1)

418

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migtscan(1M), migopscan(1M)

migtscan(1M), migopscan(1M) NAME migtscan, migopscan - scan tapes or optical volumes for file granules SYNOPSIS /usr/openv/hsm/bin/migtscan [-F] [-r] [-b block_size] [-P pool_name] [-n] [-s] [-t] hsmname volume_label method /usr/openv/hsm/bin/migopscan [-F] [-r] [-P pool_name] [-n] [-s] hsmname volume_label method DESCRIPTION The migtscan and migopscan commands scan the specified tape (ct, dt, or mt) or optical platter (op or ow) volume_label. The resulting display contains information about the volume as a whole and also about each granule on the volume. When VSM migrates a file to secondary storage, it writes the file as granules. The granule size is configured for the method name (ct, dt, mt, op, or ow) during VSM configuration. Each granule on tape also contains FHDB, FNDB, and VOLDB entry information. The migtscan and migopscan commands create three output files: FHDB.label, FNDB.label, VOLDB.label, in the dwpath/database directory. The structure of these files is the same as the FHDB, FNDB, and VOLDB database files. These files may be used to rebuild the FHDB, FNDB, and VOLDB if they are corrupted or damaged (see migdbcheck(1M)). You can sort and merge FHDB.label and FNDB.label files for different volumes to recreate the FHDB and FNDB. Similarly, merging VOLDB.label files for different volumes can recreate the VOLDB. Note When recreating the VOLDB, be sure to merge the VOLDB file in the /usr/var/openv/hsm/example/database directory to include the entry for the dk method. OPTIONS -F

Appendix A, Man Pages

Force scan the volume for VSM granules in case the volume identity is not in the VOLDB. This parameter is optional. If omitted, the volume must be registered in the VOLDB. If the volume is registered, VOLDB scans to the end of the tape (for migtscan) or the end of the platter (for migopscan), and will not use the VOLDB file count.

419

migtscan(1M), migopscan(1M)

-b block_size This number represents the block size, in bytes, that VSM uses on reads. The default is the size recorded in the volume label (see below). -b block_size applies only to migtscan. -P pool_name This represents the media pool name that VSM uses. When -F is used, the default is HSM. When -F is not used, the default is the poolname found in the volume_label entry in the VOLDB. -n

Do not compress or convert FHDB entries for files found on the volume. When the -n option is used, no FNDB.label file is produced. This option is useful for examining what is actually written on the media. The FHDB.label file produced with the -n option must be run through migfdbconvert before it can be merged into the real FHDB and FNDB.

-r

Read granule data. The default behavior is to skip the reading of granule data. StorageTek 9840 VolSafe tape drives will scan faster if the this option is specified.

-t

Use values of file and record numbers that were recorded on tape. When not specified, use actual values. The actual values may differ from the recorded values in some cases; the actual value is needed for VSM to cache files correctly. -t applies only to migtscan.

-s

Silently scan the volume and create FHDB.label and VOLDB.label files, but do not display information on stdout.

hsmname

Configured VSM name for the managed file system containing the database that has information on the desired volume.

volume_label Tape volume label used when registering the volume. This parameter is required. method

Method name under which the volume is registered (ct, dt, or mt for migtscan, and op or ow for migopscan).

CAVEATS

420

◆

Some tape drives, such as the StorageTek 9840 VolSafe drives, will scan faster if you specify the -r option.

◆

Results of scanning a tape volume that does not conform to VSM standards are unknown.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migtscan(1M), migopscan(1M)

EXAMPLE The following example uses method mt to scan a tape volume named lostid. The resulting display shows a list of granule information for files archived on the volume. The FHDB.lostid and VOLDB.lostid files are created in the VSM database directory. # migtscan alpha lostid mt VOLUME LOSTID registered to HSM VOLUME particulars =====>> 000003E8V00001098 LOSTID mt 09600000 0072DB69 #23 -------------------------000003E8M00001342 V00001098 mt 00005B8C 00000000 00005B8C #1 1 #1 1 /home/ckb/ed 000003E8M00001343 V00001098 mt 00005B8C 00000000 00005B8C #2 1 #2 1 /home/ckb/an INFO: Found trailer label EOV1

Volume information on the display includes (in order): Volume handle Volume label Method Total capacity of the volume Total space in use on the volume Number of files on the volume.

File granules information on the display includes (in order): File handle Volume ID Method File size in hex Offset in hex of the granule in the file Granule size in hex Recorded filemark number after which the granule resides Recorded offset from the file mark to the granule Computed filemark number after which the granule resides Computed offset from the file mark to the granule File name.

The recorded file mark number should equal the computer file mark number. The recorded offset should equal the computed file mark. number is the granule number recorded on the tape, and should equal the computed granule number. The computed granule number is based on the scan of the tape. Similarly, the recorded file number is the file number recorded on the tape, and should equal the computed file number.

Appendix A, Man Pages

421

migtscan(1M), migopscan(1M)

FILES The term dwpath refers to the path name of the directory in each managed file system containing the database and workdir directories. dwpath/database/FHDB

File handle database for VSM dwpath/database/FNDB

File name database for VSM dwpath/database/VOLDB

Volume database for VSM dwpath/database/migconf

Configuration file for managed file systems dwpath/database/FHDB.label

File handle database for current volume dwpath/database/FNDB.label

File name database for current volume. It contains some fields that are moved from the dwpath/database/FHDB.label dwpath/database/VOLDB.label

Volume database for current volume /usr/var/openv/hsm/database/migconfg

Global configuration file for the VSM server SEE ALSO migdbcheck(1M), mediacheck(1M), migconf(1M), migconfg(1M), migdbrpt(1M), migreg(1M), migadscan(1M), migftscan(1M), mignbscan(1M)

422

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migunmigrate(1)

migunmigrate(1) NAME migunmigrate - completely unmigrate a previously migrated file SYNOPSIS /usr/openv/hsm/bin/migunmigrate filename [filename ...] /usr/openv/hsm/bin/migunmigrate -f filelist DESCRIPTION The migunmigrate command lets users request that VSM unmigrate specified files. Users can unmigrate files that they own only if the system administrator provides the proper permissions before users can use this command. Use the fls or migloc command to determine if a file has been migrated or premigrated and/or cached. Files can be unmigrated regardless of whether or not they are already cached; however, to achieve maximum caching performance, you should stage the files with migstage before unmigrating them. This command requires an Active VSM state and a running migd migration daemon. OPTIONS filename

Files that migunmigrate should process. May be given as a relative path or absolute path. You can specify multiple files or use standard regular expressions. Wildcards are recognized.

-f filelist

Unmigrate the files listed in filelist. The format of filelist is one file name per line: either the full pathname of each file or a pathname relative to the directory in which migunmigrate is executed, not the directory in which the file(s) in the filelist resides. Wildcards are not recognized.

EXIT STATUS The following exit values are returned: 0

All files were successfully unmigrated.

<0

An error prevented any processing from occurring.

>0

The exit status indicates the number of files for which a problem was encountered.

SEE ALSO fls(1), migloc(1), migstage(1) Appendix A, Man Pages

423

migVSMshutdown(1M)

migVSMshutdown(1M) NAME migVSMshutdown - this command shuts down VSM. SYNOPSIS /usr/openv/hsm/bin/migVSMshutdown [hsmname] DESCRIPTION The migVSMshutdown command shuts down VSM. When you invoke S78hsmveritas, irixrc.sh, or hpuxrc.sh with the stop option, the script runs migVSMshutdown. A migVSMshutdown command executes the following VSM processes: 1. migVSMstate -w -s -idle [hsmname] changes the state of each Active file system to Idle. 2. stopmigd stops migd and migvold. Executed only if no hsmname was specified. 3. stopmigrd, which stops migrd. Executed only if no hsmname is specified. 4. HSMKiller hsmname stops all VSM processes. May be executed if migd was not running or was unable to idle a file system. OPTIONS hsmname

When specified, this is the specific VSM-managed file system processed by migVSMshutdown. When not specified, all VSM-managed file systems are process by migVSMshutdown.

SEE ALSO VSM(1M), migrc(1M), migrd(1M), migconfg(1M), startmigd(1M), migdbcheck(1M), mignospace(1M), migVSMstate(1M), migVSMstartup(1M)

424

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migVSMstartup(1M)

migVSMstartup(1M) NAME migVSMstartup - starts VSM. SYNOPSIS /usr/openv/hsm/bin/migVSMstartup [-D] [-T] [-N] [-C] [hsmname] DESCRIPTION The migVSMstartup command starts VSM. When you invoke S78hsmveritas, irixrc.sh, or hpuxrc.sh with the start option, it runs migVSMstartup. The startup scripts are installed so that they automatically run when the system boots in multi-user mode (run level 2) A migVSMstartupdown command executes the following VSM processes: 1. migVSMstate -c -s maintenance hsmname sets the VSM state to Maintenance for each active file system that was incorrectly shutdown. 2. startmigd starts the migd, migvold, and migrd daemons. 3. migrc -L hsmname clears locks within VSM for each hsmname in Maintenance state. 4. migadd_trailer.sh, which, for for each hsmname in Maintenance state, adds missing tape trailer labels to tapes if the -T is specified . 5. mignospace hsmname invokes migVSMstartup without the -D, -T, or -N options so that these options are not run. For each hsmname in Maintenance state, mignospace hsmname does nospace processing for the file system if the used space exceeds the configured threshold and the -N option is specified. 6. migdbcheck hsmname invokes migVSMstartup without the -D, -T, or -N options so that these options are not run. For each hsmname in Maintenance state, migdbcheck hsmname finds problems, but does not fix them, if the following occur: -D is specified for VSM, migrc cleaned some locks, or there are tapes without trailer labels. 7. migVSMstartup clears the Maintenance state for hsmname if the threshold is acceptable and it detects no other problems. OPTIONS -D Appendix A, Man Pages

Run migdbcheck if there appear to be problems. Not run by default. 425

migVSMstartup(1M)

-T

Run migadd_trailer.sh on volumes that have missing trailers. Not run by default.

-N

Run mignospace if the file system open space is less than the configured threshold. Not run by default.

-C

Run migdbconvert on hsmname if the databases for hsmname are in VSM release 3.4 or 3.4.1 format, and convert the databases to VSM release 4.5 format.

hsmname

When specified, this is the specific managed file system processed by migVSMstartup. When not specified, all managed file systems are processed by migVSMstartup.

SEE ALSO VSM(1M), migrc(1M), migrd(1M), migconfg(1M), startmigd(1M), migdbcheck(1M), mignospace(1M), migVSMshutdown(1M), migVSMstate(1M)

426

VERITAS Storage Migrator System Administrator’s Guide for UNIX

migVSMstate(1M)

migVSMstate(1M) NAME migVSMstate - changes or displays the state of a VSM managed file system SYNOPSIS /usr/openv/hsm/bin/migVSMstate [-s state] [-c] [-w] [-v] [hsmname] DESCRIPTION The migVSMstate command changes or displays the state of hsmname. This command allows VSM to be gracefully shutdown. Should a system interrupt (such a crash) occur, migVSMstate is part of recovery during a shutdown and startup. migVSMstate sets the following states: ◆

Idle: When hsmname is in this state, VSM can mount or unmount the file system. No other activity is allowed on this file system.

◆

Idling: When hsmname is in this state, VSM can remove files. All VSM processes will cleanup and terminate. mignospace processing cannot start. Once all VSM activity has completed, migd will change the state of hsmname to idle. This transitional state is not set by migVSMstate; a managed file system will go through this state as part of the process of becoming Idle.

◆

Maintenance: When hsmname is in this state, VSM cannot cache files or start mignospace processing.

◆

Inactive: When hsmname is in this state, no VSM activity is allowed.

◆

Active: When hsmname is in this state, VSM activity is allowed.

If no option is specified, migVSMstate displays the current state setting. OPTIONS -s idle

Causes hsmname to start idling down and go into Idle state. If -w was specified, migVSMstate will not exit until the state becomes Idle.

-s maintenance Changes hsmname to Maintenance state. -s active Changes hsmname to Active state. -s inactive Changes hsmname to Inactive state. A managed file system cannot go from Active to Inactive; it must go through Idle or Maintenance state and then to Inactive. Appendix A, Man Pages

427

migVSMstate(1M)

-s maintenance -c Places hsmname in the Maintenance state, but only if hsmname was not correctly shutdown or correctly idled. -w

When used with -s idle, migVSMstate will wait to exit until the state becomes Idle.

-v

Verbose mode messages go to STDOUT or STDERR, as well as the log files.

hsmname

When specified, this is the specific VSM-managed file system processed by migVSMstate. When not specified, this implies that all VSM-managed file systems are processed by migVSMstate.

SEE ALSO VSM(1M), migrc(1M), migrd(1M), migconfg(1M), startmigd(1M), migdbcheck(1M), mignospace(1M), migVSMshutdown(1M), migVSMstartup(1M)

428

VERITAS Storage Migrator System Administrator’s Guide for UNIX

rebuild_ihand(1M)

rebuild_ihand(1M) NAME rebuild_ihand - rebuild the VSM IHAND file SYNOPSIS /usr/openv/hsm/bin/rebuild_ihand hsmname DESCRIPTION The rebuild_ihand command reconstructs a lost or corrupted inode-to-handle (IHAND) file if the managed file system is intact. This command will not detect all discrepancies between the file system and the FHDB; run migdbcheck to do this. You must also stop and restart the migd migration daemon or send it an INT signal after the IHAND file has been replaced. The output of rebuild_ihand is a reconstructed IHAND file in dwpath/database/hsmname.IHAND.pid. To use this reconstructed IHAND file, copy it to the real IHAND file in dwpath/database/hsmname.IHAND. The exit status of rebuild_ihand is a count of the number of errors encountered. A zero status indicates there were no errors. Error messages are written to stderr and to the VSM logfile. This command may be run without regard to the VSM state, but the VSM daemons must not be running. OPTIONS hsmname

VSM name of the managed file system for which you want to rebuild the IHAND file.

FILES The term dwpath refers to the path name of the directory containing the database and workdir directories. The path name of this directory is site configurable dwpath/database/hsmname.IHAND

Inode-to-handle file for VSM dwpath/database/hsmname.IHAND.pid

Reconstructed inode-to-handle file for VSM SEE ALSO ihprint(1M)

Appendix A, Man Pages

429

startmigd(1M)

startmigd(1M) NAME startmigd - start the VSM migration, volume, and request daemons SYNOPSIS /usr/openv/hsm/bin/startmigd [-m | -r | -v ] [-t time] DESCRIPTION The startmigd command starts the VSM migration daemon (migd), the volume daemon (migvold), and the request daemon (migrd). You should ensure migd, migvold, and migrd are started as part of system startup. The startup scripts copied during installation do this for you automatically. On startup, migd and migrd read the configuration files. If you manually change the configuration file while the daemons are running, you can stop and restart the daemon so that they pick up the changes, or you can signal the daemons as follows: # kill -INT ‘cat /usr/var/openv/hsm/workdir/migd.pid‘ # kill -HUP ‘cat /usr/var/openv/hsm/workdir/migrd.pid‘

If you use VSM-Java to make configuration changes, a signal is automatically sent to migd and migrd. OPTIONS -m

Start only the migration daemon (migd).

-r

Start only the migration request daemon (migrd)

-v

Start only the volume daemon (migvold).

-t time

Sets the time interval in seconds that determines the frequency with which the migd migration daemon checks the high-water mark threshold. The default is 60.

Note The default behavior is to start all VSM daemons. CAVEATS

430

◆

You must start the migd migration daemon before you can mount the managed file systems.

◆

If the migration daemon is not running or the managed file system state is not Active, migrated files cannot be accessed. If migd stops, you can use the VSM log files to help determine the cause of failure. VERITAS Storage Migrator System Administrator’s Guide for UNIX

startmigd(1M)

EXAMPLE The following command starts the migration, volume, and request daemons, with results similar to those shown: # startmigd INFO: VSM request daemon migrd started. INFO: VSM volume daemon migvold started. INFO: VSM migration daemon migd started with frequency 60.

FILES /usr/var/openv/hsm/workdir/migd.pid The process ID (pid) of the VSM migration daemon (if it is running) /usr/var/openv/hsm/workdir/migvold.pid

The process ID (pid) of the VSM volume daemon (if it is running). /usr/var/openv/hsm/workdir/migrd.pid

The process ID (pid) of the VSM request daemon (if it is running). SEE ALSO VSM(1M), HSMKiller(1M), migconf(1M), migconfg(1M), stopmigd(1M), stopmigrd(1m), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M)

Appendix A, Man Pages

431

stopmigd(1M)

stopmigd(1M) NAME stopmigd - stop the VSM migration and volume daemons SYNOPSIS /usr/openv/hsm/bin/stopmigd [-m | -v] DESCRIPTION The stopmigd command stops the VSM migration daemon (migd) and the VSM volume daemon (migvold). The daemons should only be stopped in the event of a problem. When VSM is installed, the migration daemon becomes an integral part of the operating system software on that machine. The stopmigd command only terminates migd and migvold. Use stopmigrd to stop the migrd migration request daemon. Use migVSMshutdown to halt all running VSM processes. OPTIONS -m

Stop only the migration daemon (migd).

-v

Stop only the volume daemon (migvold).

The default is to stop both the VSM migration and volume daemons. The exit value (n) is the number of daemons stopped. CAVEATS ◆

432

If migd is not running, you cannot do the following: -

On Solaris and HP-UX systems, you cannot remove files from the managed file system.

-

Users cannot access migrated files.

-

Automatic migrations do not occur when free space is above the high-water threshold and a user attempts to open a migrated file.

◆

If the migvold volume daemon is not running, users cannot read migrated files from tape or optical volumes.

◆

Current VSM migration and caching operations run to completion but may leave incorrect results after stopmigd stops the VSM daemons.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

stopmigd(1M)

EXAMPLE The following command stops both the migration and volume daemons, and returns messages similar to those shown if the daemons were running when the command was issued: # stopmigd INFO: VSM migration daemon migd stopped. INFO: VSM volume daemon migvold stopped.

FILES /usr/var/openv/hsm/workdir/migd.pid The process ID (pid) of the VSM migration daemon (if it is running) /usr/var/openv/hsm/workdir/migvold.pid

The process ID (pid) of the VSM volume daemon (if it is running) SEE ALSO VSM(1M), startmigd(1M), migVSMstartup(1M), migVSMshutdown(1M), HSMKiller(1M)

Appendix A, Man Pages

433

stopmigrd(1M)

stopmigrd(1M) NAME stopmigrd - stop the VSM request daemon migrd SYNOPSIS /usr/openv/hsm/bin/stopmigrd DESCRIPTION The stopmigrd command stops the VSM request daemon (migrd). The daemon should only be stopped in the event of a problem. When VSM is installed, the migration request daemon becomes an integral part of the operating system software on that machine. The stopmigrd command only terminates migrd. Use stopmigd to stop the migd and migvold daemons. Use migVSMshutdown to halt all running VSM processes. CAVEATS ◆

If the request daemon is not running, VSM-Java applications cannot connect to the server.

◆

Some state changes rely on the request daemon to make changes to the global configuration file. If the request daemon is not running, migVSMstate may not be able to make a requested state change.

FILES /usr/var/openv/hsm/workdir/migrd.pid

The process ID (pid) of the VSM request daemon (if it is running) SEE ALSO migrd(1M), VSM(1M), migVSMshutdown(1M), migVSMstate(1M), migVSMstartup(1M), HSMKiller(1M)

434

VERITAS Storage Migrator System Administrator’s Guide for UNIX

VSM(1M)

VSM(1M) NAME VSM - VERITAS Storage Migrator (VSM) DESCRIPTION VERITAS Storage Migrator (VSM) increases the amount of file space available to users by migrating files from a local online managed file system to secondary storage (such as magnetic tape or another disk) as space is needed in the online file system. Administrators can schedule migration operations to occur automatically. When properly configured, VSM selects files for migration based on configurable criteria such as file size and file age. When a user accesses a migrated file, it is automatically retrieved from secondary storage and cached in the online file system. Except for the delay to perform the retrieval, users and programs are unaware that file migration and retrieval are taking place. VSM uses directly connected tape, optical disk, or magnetic disk devices as well as magnetic disk file systems on remote volume servers for secondary storage. Media Manager provides the interface to the tape and optical storage devices. Support for large-capacity library devices with robotic access mechanisms eliminates the need for operator action to either migrate or cache files. VSM lets you use numerous secondary storage methods: disk file for premigration (dk), alternate magnetic disk (ad), three tape methods (ct, dt, and mt), two optical disk methods (op and ow), remote using FTP (ft), and NetBackup (nb). The nb method migrates files using VERITAS NetBackup. VSM is able to share storage volumes and devices with other applications like VERITAS NetBackup through the use of a common Media Manager. VSM supports multilevel migration. Administrators may configure up to eight migration levels, and can schedule migrated files to move from one level to another based on site-specified criteria. With multilevel migration, you can configure and manage cost-effective storage hierarchies that make best use of your storage equipment investment. VSM enables administrators to export migrated files from one managed file system and import them into another managed file system. The following sections group VSM commands by function. MANAGING FILE MIGRATION migbatch(1M) Premigrate files and copy to secondary storage Appendix A, Man Pages

435

VSM(1M)

migfind(1M) Determine the full pathname of a file on secondary storage mignospace(1M) Purge or migrate files to make disk space available miglow(1M) Start mignospace if file system is above high-water mark MANAGING MULTILEVEL MIGRATION migmove(1M) Move migrated files from one migration level to another level migsetdb(1M) Alter the flags field in the FHDB or the VOLDB MANAGING FILE CACHING migin(1M) Cache a file from secondary storage to disk migstage(1) Pre-cache files to avoid caching delays migtie(1) Designate the key caching file(s) for a caching group MANAGING MEDIA migreg(1M) Register and label volumes for VSM migcons(1M) Consolidate VSM tape and optical volumes migselect(1M) Select volumes for consolidation based on specified criteria migrecycle(1M) Reregister an empty volume migmdclean(1M) Remove obsolete entries from media 436

VERITAS Storage Migrator System Administrator’s Guide for UNIX

VSM(1M)

migftscan(1M) Scan an ft remote volume and reconstruct database entries MANAGING VSM PROCESSES startmigd(1M) Start migration and volume daemons stopmigrd(1m) Stop migration and volume daemons migrc(1M) Clear locks, remove defunct lock files, restart migrations migconsweep(1M) Enable constant file system sweeping mignewlog(1M) Copy or delete global or individual VSM log file migVSMstate(1M) Changes file system state to Maintenance, Idle, Idling, Inactive, or Active. migVSMstartup(1M) Start migration and volume daemons; used in place of startmigd migVSMshutdown(1M) Stop migration and volume daemons; used in place of stopmigd and HSMKiller HSMKiller(1M) Kill active VSM processes and release tape requests MANAGING VSM ihprint(1M) Print or alter the IHAND file rebuild_ihand(1M) Rebuild the IHAND file from the FHDB migalter(1M) Display or alter regions, events, or attributes migcleanup(1M)

Appendix A, Man Pages

437

VSM(1M)

Display or clean up DMAPI sessions RECOVERING DATA migreconstruct(1M) Reconstruct damaged or deleted migrated files migin(1M) Restore a file from secondary storage to disk. USER CONTROLS fls(1) List and show migration status of files gethsm(1) Display the hsmname for files and directories migcat(1) Concatenate and display migrated files without caching them miggroup(1), migungroup(1) Group/Ungroup files for migration and caching migloc(1) Show location of migrated file migpurge(1) Purge a specific file or files migrate(1) Premigrate a specific file or files migstage(1) Pre-cache files to avoid caching delays migtie(1) Designate the key caching file(s) for a caching group migunmigrate(1) Request that a migrated file be unmigrated EXPORTING AND IMPORTING MIGRATED FILES mignbimport(1M) 438

VERITAS Storage Migrator System Administrator’s Guide for UNIX

VSM(1M)

Export VSM files mignbimport(1M) Import VSM files MANAGING DATABASES migactivate Activate FHDB entries for files with obsolete VSM file handles migdbconvert(1M) Convert VSM release3.4 or 3.4.1 FHDB to VSM release 4.5 FHDB and FNDB migdbcheck(1M) Check the FHDB, FNDB, and/or the VOLDB for consistency with the file system mediacheck(1M) Check the media, FHDB, and FNDB for consistency migsetdb(1M) Alter the flags field in the FHDB and FNDB or the VOLDB OBTAINING REPORTS migadscan(1M) Provide information on contents of archive disk volumes migtscan(1M), migopscan(1M) Provide information on contents of tape or optical volumes miggetvol(1M) List volumes in ascending order of percentage utilization migdbdir(1M) List global configuration values from migconfg migdbrpt(1M) Provide FHDB, FNDB, and VOLDB information on files and volumes migchecklog(1M) List the most recent messages from an error log file migftscan(1M) Scan an ft remote volume and reconstruct database entries

Appendix A, Man Pages

439

VSM(1M)

mignbscan(1M) Scan a NetBackup volume and reconstruct database entries TUNING MIGRATIONS migconsweep(1M) Enable constant file system sweeping migtestbadness(1M) Evaluate configuring different file system attributes GRAPHICAL USER INTERFACES migsa VSM-Java, the Java-based Administrative interface, is used to complete administrative tasks on VSM-managed file systems and servers. On a Windows system, select Start > Programs > VERITAS Storage Migrator > Unix Administration. On HP-UX or Solaris systems, launch the VSM-Java Administration interface with the following command: /usr/openv/java/migsa &

migfb ◆

The Java-based File Browser interface is used to migrate files, as well as purge and view migrated files. On a Windows system, select Start > Programs > VERITAS Storage Migrator > Unix File Browser. On HP-UX or Solaris, launch the VSM File Browser interface with the following command: /usr/openv/java/migfb &

Note Man pages are not available for the above graphical user interfaces.

440

VERITAS Storage Migrator System Administrator’s Guide for UNIX

B

Enterprise Agent for Storage Migrator

The Enterprise Agent for Storage Migrator lets you define your VSM resources and group them for failover situations. Enterprise Agent for Storage Migrator has two VERITAS Cluster Server (VCS) agents: ◆

The Storage Migrator Agent (StorageMigratorAgent) monitors the VSM daemons.

◆

The Storage Migrator File System Agent (StorageMigratorFSAgent) manages VSM file system resources.

These agents are typically configured together to manage VSM resources. These agents allow managed file systems to fail over independently. Enterprise Agent for Storage Migrator is designed to support active-active configurations. If, however, you are using locally attached tapes, you can use only the active-inactive configuration, an example of which is explained in “Manual Active-Inactive Configuration using NetBackup” on page 453. Active-active configurations work only with ft and ad methods, an example of which is explained in “Manual Active-Active Configuration using FTP” on page 450. Also consider the following as you plan your configuration: ◆

One or more managed file systems can be configured as VCS resources. These resources are then configured in a VCS resource group.

◆

The managed file systems must reside on shared disks and be available to all systems in the cluster. VSM database and log files must also reside on separate shared disks available to all systems. They must be configured as Mount resource types.

◆

All StorageMigratorFS Agent resources must be created for failover purposes. Each resource includes the managed file system, database and log file directories, and dependency statements, as required.

441

◆

The StorageMigrator resource is included in a group by itself, so that the Parallel attribute can be set by the user. Doing this allows for active-active configurations. The following table shows the StorageMigrator Agent and StorageMigratorFS Agents and resources.

Components and Resources for Enterprise Agent for Storage Migrator Agent Name

Resource Name

Resource Group

StorageMigrator

theDaemons

StorageMigratorGroup

StorageMigratorFS

Hsm_X

StorageMigratorFSGroup

The following table summarizes StorageMigrator Agent operations. The StorageMigrator Agent has unique online, offline, monitor, and clean scripts: Operations for the StorageMigrator Agent Description

Manages the VSM daemons

Operations

-

monitor - Verifies that the VSM daemons (migd, migrd, and, when applicable, migvold) are running.

-

online - Calls migVSMstartup to start the VSM daemons.

Detecting Daemon Failure

442

offline - Calls migVSMshutdown to stop the VSM daemons. If any managed file systems are Active, they are put in Maintenance state. clean - Calls migVSMshutdown to stop the VSM daemons.

The daemon is considered offline if one of the following applies:

-

The daemon.pid file for migd, migrd, or (when applicable) migvold does not exist or is empty.

-

The processes associated with the process IDs listed in the daemon.pid files do not exist in the /proc directory.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Limitations

The following table summarizes StorageMigratorFS Agent operations. The StorageMigratorFS Agent has unique online, offline, monitor, and clean scripts: Operations for the StorageMigratorFS Agent Description

Manages file systems under VCS control

Operations

-

monitor - Verifies that the managed file system is mounted and that an entry exists for it in migconfg (the global configuration file). Also tests for status in the resource.vsm.agent.state file.*

-

online - Adds the manged file system entry to the migconfg file, calls migVSMstartup to start VSM, and sets its state to Active. Also echoes online to the resource.vsm.agent.state file.*

-

offline - Calls migVSMshutdown to idle the managed file system, echoes offline to the resource.vsm.agent.state file*, and removes the entry from the migconfg file.

-

clean - The same as offline.

Detecting Daemon Failure

The managed file system is considered offline if it is mounted and no entry for it appears in the migconfg file. * An example resource.vsm.agent.state file name is vsmfs_hsm2.vsm.agent.state.

Limitations The following limitations apply to Enterprise Agent for Storage Migrator: ◆

When using Media Manager, the Enterprise Agent for Storage Migrator supports only active-inactive configurations.

◆

Enterprise Agent for Storage Migrator is tested in a two-node configuration, although it is designed to work in two- to 32-node configurations.

◆

VSM may not support quick restart for all interruptions.

Installation Before you begin, make sure you can install, configure, and use VCS and NetBackup Cluster Server Agent in a configuration. You will need the following resources for using Enterprise Agent for Storage Migrator: ◆

NetBackup Cluster Agent version 1.3.0, if using locally attached tapes.

Appendix B, Enterprise Agent for Storage Migrator

443

Installation ◆

VCS version 1.3.0 or 2.0.

◆

NetBackup version 4.5

◆

VSM version 4.5.

◆

VxFS version 3.3 or 3.4.

◆

A VCS cluster, consisting of at least two systems running Solaris OS versions 2.6, 2.7, or 2.8.

◆

At least one shared disk for managed file systems, VSM databases, and the /usr/openv directory.

◆

A shared library for migration, if you are using tapes.

Pre-Installation You need the following before you install the Enterprise Agent for Storage Migrator: ◆

VERITAS Cluster Server software distribution 1.3.0 or 2.0 CD.

◆

NetBackup software distribution 4.5 CD.

◆

VSM version 4.5 CD.

◆

VERITAS Volume Manager (VxVM) 3.1 CD

◆

If using locally attached tapes, NetBackup Cluster Agent 1.3.0 or later.

◆

A shared disk for /usr/openv directory.

◆

Shared disks or file systems for the managed file systems, database and log directories

Caution Make sure the /usr/var/openv/hsm directory is not mirrored or replicated from another node in the cluster.

Installation ▼

On a new system, complete the following steps: 1. Install VERITAS Cluster Server as explained in the Cluster Server Installation Guide. 2. Install VERITAS Volume Manager (VxVM) 3.1 as explained in the Volume Manager Installation Guide. 3. Install NetBackup as explained in the NetBackup DataCenter Installation Guide - UNIX and Media Manager Device Configuration Guide - UNIX.

444

VERITAS Storage Migrator System Administrator’s Guide for UNIX

General Configuration

Note You must install NetBackup on each node in the cluster. 4. If you want to failover NetBackup, install Enterprise Agent for NetBackup as explained in the Enterprise Agent for NetBackup, Installation and Configuration Guide. Note You must install the Enterprise Agent for NetBackup on each node in the cluster. 5. Install VSM as explained in the VSM installation guide. Note You must install VSM on each node in the cluster. 6. Install the Cluster Server Agent for Storage Migrator using the same installation script used for VSM installation. You must have a valid license key. Note You must install the Cluster Server Agent for Storage Migrator on each node in the the cluster. The Enterprise Agent for Storage Migrator contains the following files: /opt/VRTSvcs/bin/StorageMigrator/StorageMigratorAgent /opt/VRTSvcs/bin/StorageMigrator/online /opt/VRTSvcs/bin/StorageMigrator/offline /opt/VRTSvcs/bin/StorageMigrator/clean /opt/VRTSvcs/bin/StorageMigratorFS/StorageMigratorFSAgent /opt/VRTSvcs/bin/StorageMigratorFS/online /opt/VRTSvcs/bin/StorageMigratorFS/offline /opt/VRTSvcs/bin/StorageMigratorFS/clean /etc/VRTSvcs/conf/StorageMigratorTypes.cf /etc/VRTSvcs/conf/agent_config.sh

General Configuration To ensure proper failover behavior, configure the Enterprise Agent for Storage Migrator so that it matches your VSM configuration. This document describes possible configurations that cover the most common cases. You need to customize these configurations to suit your needs. The typical configurations are as follows: ◆

Active-inactive configuration with NetBackup.

◆

Active-inactive configuration with FTP method

Appendix B, Enterprise Agent for Storage Migrator

445

General Configuration

Import Files Before you begin the configuration, import the StorageMigratorTypes.cf file that contains the type definitions for both the StorageMigrator and StorageMigratorFS types using hagui, as follows: 1. Run the hagui & command. 2. Log into the cluster. 3. Select File > Import Types. 4. Select the StorageMigratorTypes.cf file. 5. Click Import. 6. Exit the interface.

VSM Configuration Configure each managed file system (hsmname) as follows: ◆

The managed file system must be shared among nodes in the cluster

◆

VSM databases and logs are shared among nodes in the cluster

Note The managed file system configuration is only done on one node in the cluster.

Agent Configuration Utility Enterprise Agent for Storage Migrator contains a configuration utility called agent_config.sh. This utility attempts to create resources, resource groups, and dependencies based on the VSM configuration it finds on the system. To use this utility, VSM must be properly configured, mounted, and Active. The agent_config.sh utility does not create low level resources. It creates the following:

446

◆

A StorageMigrator resource to handle the daemons.

◆

Either a single StorageMigratorFS group, if active-inactive configuration is requested, or a separate StorageMigratorFS group for each VSM to be configured for failover.

◆

Mount resources for the databases, logs, and managed file systems it finds.

VERITAS Storage Migrator System Administrator’s Guide for UNIX

General Configuration ◆

If it finds that the block devices for the managed file systems are presented by VERITAS Volume Manager, it creates DiskGroup resources for disk group failover.

The agent_config.sh utility lists systems for which it can configure resources. Selected systems will have managed file system resources configured. The agent_config.sh utility will list managed file systems that should be configured for cluster management. The syntax for agent_config.sh is as follows: /etc/VRTSvcs/conf/agent_config.sh [-i[o] | -u]

Note You run agent_config.sh only on the node where you configured the managed file systems. To configure managed file systems in separate resource groups, which allows the default active-active configuration, run the following command: # /etc/VRTSvcs/conf/agent_config.sh -i

To configure managed file systems in one resource group, run the following command: # /etc/VRTSvcs/conf/agent_config.sh -io

It may be necessary, based on how systems in your cluster are configured, to add resources and dependencies manually in order to ensure proper failover behavior. Use the hagrp and harcs commands to show all resources, resource groups, and dependencies have been created. If any requisite groups, resources, or dependencies were not created, create them manually as described in “Manual Configuration.” To unconfigure an existing VSM Cluster Server configuration that was configured by agent_config, run the following command: # /etc/VRTSvcs/conf/agent_config.sh -u

Manual Configuration Before configuring Enterprise Agent for Storage Migrator, determine what file systems will be configured and their respective attributes. You need to know the block device of the managed file system. You also need to know the following, found either in VSM-Java or the migconfg global configuration file: ◆

The hsmname, which is the name of the VSM managed file system

◆

Database path

◆

Log file path

Ensure that you do the following when you configure:

Appendix B, Enterprise Agent for Storage Migrator

447

General Configuration

▼

◆

Create a global configuration file (/usr/var/openv/hsm/databse/migconfg) that is different for each system in the cluster. Do no share or replicate this directory.

◆

Ensure that managed file systems are available on each system in the cluster. You can use shared disks or replication.

◆

Ensure that the VSM databases and the log files are available on each system in the cluster. You can use shared disks or replication to achieve this.

◆

Ensure that database path and the log file path are not in a managed file system.

◆

Determine primary systems for the managed file systems. On each primary system, configure VSM managed file systems.

◆

Ensure that the log file path is available to each system in the cluster and is set to be a shared file system. VSM-Java selects a default log file path name. After configuring the file system, you must change the default log file path name to a file system that resides on a shared disk

If any of the file systems, including those containing databases, logs, and managed file systems, must be shared (exported), configure them with the Share Agent: 1. Configure the Mount and StorageMigratorFS resources. This is fully explained in “Manual Active-Inactive Configuration using NetBackup” on page 453. 2. Configure matching Share resources. The Share PathName is the same as the MountPoint in the Mount type and StorageMigratorFS type. 3. Make the Share resources dependent upon the StorageMigratorFS or Mount resource. This allows file systems to be mounted before they are shared. If this dependency is not created, the file system mount requests will fail with a busy error. The figure “Sample Hardware Configuration” on page 449 shows a cluster with two nodes: trixie and pixie. Both these nodes are running Solaris 2.7. The configuration is outlined as follows:

448

◆

The node pixie is the primary system for the managed file system hsm1.

◆

The node cranberry is not part of the cluster. It is used by the ft method.

◆

/hsm1 and /hsm2 are managed file systems. They are available to trixie and pixie on shared disk drives.

◆

/db1 is a shared file system for the /hsm1 databases.

◆

/db2 is a shared file system for the /hsm2 databases.

◆

/log1 a shared file system for the /hsm1 logs.

◆

/log2 a shared file system for the /hsm2 logs.

◆

The shared file systems must be on disks available to all nodes in the cluster. VERITAS Storage Migrator System Administrator’s Guide for UNIX

General Configuration Sample Hardware Configuration

PUBLIC NETWORK

NODE

PRIVATE NETWORK

trixie

NODE

pixie

/hsm1

/hsm2

FTP SERVER /db1

cranberry

/db2

/log1

/log2

HP DLT LIBRARY

Appendix B, Enterprise Agent for Storage Migrator

449

General Configuration ▼

To configure the Enterprise Agent for Storage Migrator: 1. Configure a VCS cluster as described in the Cluster Server User’s Guide. 2. Configure managed file systems on the primary node. 3. Select the appropriate configuration option based on your needs, and follow the steps provided in that section: -

“Manual Active-Inactive Configuration using NetBackup” on page 453.

-

“Manual Active-Active Configuration using FTP” on page 450.

Note The configurations in this document are examples. They do not necessarily represent the only way to configure Enterprise Agent for Storage Migrator.

Manual Active-Active Configuration using FTP The following figure shows how parts of Enterprise Agent for Storage Migrator in an active-inactive configuration are dependent on others.

450

VERITAS Storage Migrator System Administrator’s Guide for UNIX

General Configuration Dependencies for Active-Active Configuration with FTP

StorageMigratorFSGroup1 StorageMigratorFS hsm1

StorageMigratorGroup Mount db1 Mount log1

StorageMIgrator theDaemons

StorageMigratorFSGroup2 StorageMigratorFS hsm2

Mount db2 Mount log2

StorageMigratorFSGroup1 and StorageMigratorFSGroup2 require StorageMigratorGroup. .

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

This configuration can be explained as follows: ◆

pixie is the primary node for hsm1.

◆

trixie is the primary node for hsm2.

◆

Two StorageMigratorFS Agent resource groups, StorageMigratorFSGroup1 and StorageMigratorFSGroup2, are necessary.

◆

The Parallel attribute for the StorageMigratorGroup is set to be online on all systems simultaneously.

◆

In an active-active configuration, the /usr/openv directory on both nodes must be available only to that node.

Appendix B, Enterprise Agent for Storage Migrator

451

General Configuration ▼

To complete an active-active configuration with the FTP method: 1. Add one StorageMigrator Agent resource type in the cluster: # # # #

hagrp hagrp hagrp hares

-add StorageMigratorGroup -modify StorageMigratorGroup Parallel 1 -modify StorageMigratorGroup SystemList pixie 1 trixie 2 -add theDaemons StorageMigrator StorageMigratorGroup

Note Repeat step 2 and step 3 for each managed file system. Set the resource name equal to the managed file system name and use appropriate resource attributes. 2. Create the StorageMigratorFSAgent resource group 1: # hagrp -add StorageMigratorFSGroup1 # hagrp -modify StorageMigratorFSGroup1 SystemList pixie 1 trixie 2

3. Add the managed file system resource to the group: # # # # # #

hares hares hares hares hares hares

-add hsm1 StorageMigratorFS StorageMigratorFSGroup1 -modify hsm1 MountPoint /hsm1 -modify hsm1 BlockDevice /dev/dsk/c1t2d0s6 -modify hsm1 DatabasePath /db1/hsm/database/hsm1 -modify hsm1 LogFilePath /log1/hsm/logs/hsm1 -modify hsm1 HsmName hsm1

4. Add /db1 as a Mount resource: # # # #

hares hares hares hares

-add db1 Mount StorageMigratorFSGroup1 -modify db1 MountPoint /db1 -modify db1 BlockDevice /dev/dsk/c1t2d0s5 -modify db1 FSType vxfs

5. Create /log FS /log1: # # # #

hares hares hares hares

-add log1 Mount StorageMigratorFSGroup1 -modify log1 MountPoint /log1 -modify log1 BlockDevice /dev/dsk/c6t6d0s6 -modify log1 FSType vxfs

6. Create StorageMigratorFSGroup2: # hagrp -add StorageMigratorFSGroup2 # hagrp -modify StorageMigratorFSGroup2 SystemList pixie 2 trixie 1

7. Add the managed file system resource to the group: # hares -add hsm2 StorageMigratorFS StorageMigratorFSGroup2 # hares -modify hsm2 MountPoint /hsm2 452

VERITAS Storage Migrator System Administrator’s Guide for UNIX

General Configuration

# # # #

hares hares hares hares

-modify -modify -modify -modify

hsm2 hsm2 hsm2 hsm2

BlockDevice /dev/dsk/c1t2d0s3 DatabasePath /db2/hsm/database/hsm2 LogFilePath /log2/hsm/logs/hsm2 HsmName hsm2

8. Add /db2 as a Mount resource: # # # #

hares hares hares hares

-add db2 Mount StorageMigratorFSGroup2 -modify db2 MountPoint /db2 -modify db2 BlockDevice /dev/dsk/c1t2d0s5 -modify db2 FSType vxfs

9. Create /log FS /log2: # # # #

hares hares hares hares

-add log2 Mount StorageMigratorFSGroup2 -modify log2 MountPoint /log2 -modify log2 BlockDevice /dev/dsk/c7t2d1s6 -modify log2 FSType vxfs

10. Set up dependencies: # hares -link # hares -link # hares -link # hares -link # hagrp -link online local # hagrp -link online local

hsm1 db1 hsm2 db2 hsm1 log1 hsm2 log2 StorageMigratorFSGroup1 StorageMigratorGroup \ StorageMigratorFSGroup2 StorageMigratorGroup \

11. Enable the resources in the groups: # hagrp -enableresources StorageMigratorGroup # hagrp -enableresources StorageMigratorFSGroup1 # hagrp -enableresources StorageMigratorFSGroup2

12. Make the VCS configuration read-only: # haconf -dump -makero

Manual Active-Inactive Configuration using NetBackup The following figure shows how parts of Enterprise Agent for Storage Migrator in an active-inactive configuration are dependent on others.

Appendix B, Enterprise Agent for Storage Migrator

453

General Configuration Dependencies for Active-Inactive Configuration with NetBackup

StorageMigratorFSGroup StorageMigratorFS hsm1 StorageMigratorGroup Mount /mnt1

StorageMigrator theDaemons

NBUGroup

StorageMigratorFSGroup requires StorageMigratorGroup, which requires NBUGroup. ▼

To complete an active-inactive configuration with NetBackup: 1. Start VCS: # hastart -force

2. Make the VCS configuration read/write: # haconf -makerw

3. Configure the Enterprise Agent for NetBackup. An example NBUGroup definition follows: group NBUGroup ( SystemList = { pixie, trixie } ) Mount openv_mnt ( MountPoint = "/usr/openv" BlockDevice = "/dev/dsk/c1t2d0s4" FSType = vxfs )

454

VERITAS Storage Migrator System Administrator’s Guide for UNIX

General Configuration

NetBackup netBackup ( ServerType = NBUMaster ) NetBackup requires openv_mnt

4. If you have not yet done so, import the StorageMigratorTypes.cf file that contains the type definitions for both the StorageMigrator and StorageMigratorFS types using hagui, as follows: a. Run the hagui & command. b. Log into the cluster. c. Select File > Import Types. d. Select the StorageMigratorTypes.cf file. e. Click Import. f.

Exit the interface.

5. Add one VSM resource type in the cluster, as follows: # # # #

hagrp hagrp hagrp hares

-add StorageMigratorGroup -modify StorageMigratorGroup Parallel 0 -modify StorageMigratorGroup SystemList pixie 1 trixie 2 -add theDaemons StorageMigrator StorageMigratorGroup

6. Create the StorageMigratorFS resource group: # hagrp -add StorageMigratorFSGroup # hagrp -modify StorageMigratorFSGroup SystemList pixie 1 trixie 2

Note Repeat step 7 and step 8 for each managed file system. Set the resource name equal to the managed file system name, and use other attributes as appropriate. 7. Add the managed file system resource to the group: # # # # # #

hares hares hares hares hares hares

-add hsm1 StorageMigratorFS StorageMigratorFSGroup -modify hsm1 HsmName hsm1 -modify hsm1 MountPoint /hsm1 -modify hsm1 BlockDevice /dev/dsk/c1t2d0s6 -modify hsm1 DatabasePath /db1/hsm/database/hsm1 -modify hsm1 LogFilePath /db1/hsm/logs/hsm1

Appendix B, Enterprise Agent for Storage Migrator

455

Sample Configuration File Entries

8. Add /db1 as a Mount resource: # # # #

hares hares hares hares

-add db1 Mount StorageMigratorFSGroup -modify db1 MountPoint /db1 -modify db1 BlockDevice /dev/dsk/c1t2d0s5 -modify db1 FSType vxfs

9. Add /log1 as a Mount resource: # # # #

hares hares hares hares

-add log1 Mount StorageMigratorFSGroup -modify log1 MountPoint /db1 -modify log1 BlockDevice /dev/dsk/c1t2d0s5 -modify log1 FSType vxfs

10. Set up the dependencies: # hagrp # hares # hares # hagrp local

-link -link -link -link

StorageMigratorGroup NBUGroup online local hsm1 db1 hsm1 log1 StorageMigratorFSGroup StorageMigratorGroup online \

11. Enable the resources in the groups: # hagrp -enableresources StorageMigratorGroup # hagrp -enableresource StorageMigratorFSGroup

12. Make the VCS configuration read-only: # haconf -dump -makero

Sample Configuration File Entries The following are example entries as they could appear in your /etc/VRTSvcs/conf/config/main.cf and /etc/VRTSvcs/conf/StorageMigratorTypes.cf files after completing one of the example configuration scenarios. Sample /etc/VRTSvcs/conf/config/main.cf file entries: group StorageMigratorFSGroup ( SystemList = { pixie, trixie } ) StorageMigrator theDaemons ( ) 456

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Maintaining Your System

StorageMigratorFS hsm1 ( HsmName = "hsm1" MountPoint = "/hsm1" BlockDevice = "/dev/dsk/c1t2d0s6" DatabasePath = "/db1/hsm/database/hsm1/" LogFilePath = "/log1/hsm/logs/hsm1" ) Mount db1 ( MountPoint = "/db1" BlockDevice = "/dev/dsk/c1t2d0s5" FSType = vxfs ) Mount /log1( MountPoint = "/log" BlockDevice = "/dev/dsk/c1t2d0s16" FSType = vxfs )

Sample of /etc/VRTSvcs/conf/StorageMigratorTypes.cf entries: type StorageMigrator ( static str LogLevel str dv static str ArgList[] = { dv } NameRule = "" ) type StorageMigratorFS ( static str LogLevel static str ArgList[] = { HsmName, MountPoint, BlockDevice, DatabasePath, LogFilePath } NameRule = "" str MountPoint str BlockDevice str DatabasePath str LogFilePath str HsmName

Maintaining Your System You can monitor, configure, and change the resources in the cluster by using either the VCS interface or VCS commands.

Appendix B, Enterprise Agent for Storage Migrator

457

Removing the Enterprise Agent for Storage Migrator

If you find a handle mismatch on a migrated file after a managed file system has been failed over to a different node in the cluster, you should synchronize the major numbers in the /etc/name_to_major file in each of the nodes in the cluster using the haremajor command. Read the following cautionary statements to ensure that the Enterprise Agent for Storage Migrator works smoothly at your site Caution When a managed file system is under VCS control, always leave its state Active. Failure to do so will cause the system to fault. If you need to change the state, use the hagrp command to ensure that the StorageMigratorFSGroup is offline. Caution While the resource is online, do not manually unmount file systems managed and used by the Enterprise Agent for Storage Migrator. Caution When the Enterprise Agent for Storage Migrator is Active, do not add and remove entries from VSM global configuration files on any system in the cluster. The StorageMigratorFS Agent automatically adds and removes entries as required for configuration. Caution If you create entries in the /etc/vfstab for the file systems, make sure they are set so they will not mount at boot. If they mount at boot, there could be concurrency violations during failover. Caution Do not share (export) /usr/openv/, VSM databases, or managed file systems without using the VCS Share resource. If they are shared, the StorageMigratorFS Agent resources will fail to mount the file systems. See “General Configuration” on page 445 for more information.

Removing the Enterprise Agent for Storage Migrator The following procedure explains how to remove the Enterprise Agent for Storage Migrator. ▼

To remove the Enterprise Agent for Storage Migrator: 1. Unlink all groups you do not want to take offline from the StorageMigrator and StorageMigratorFS groups. 2. Set the StorageMigrator and StorageMigratorFS groups to offline.

458

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Getting Help

3. Remove the resources from the groups and remove the groups themselves. 4. Stop the StorageMigrator and StorageMigratorFS Agents that were started by VCS. 5. Remove the software package VRTSsmvcs by running the pkgrm command. This will remove the files installed by the installation script.

Getting Help If you have questions about Enterprise Agent for Storage Migrator, access the website below: http://support.veritas.com

Appendix B, Enterprise Agent for Storage Migrator

459

Getting Help

460

VERITAS Storage Migrator System Administrator’s Guide for UNIX

C

Notes on Supported Optical Media

If you use optical storage media, you should know the following information about VSM and NetBackup support of optical disks. The following is true of supported hardware: ◆

HP Optical drives support some older optical platters as read-only.

◆

When attempting to write to an optical platter that is supported as read-only, the media will be reported as needing write enabled, regardless of the physical write protect tab setting.

◆

Although Media Manager can format optical platters, VERITAS strongly urges you to use preformatted platters.

The following is true of operating system platform support: ◆

All platforms and operating systems do not support all available sector sizes for optical platters.

◆

The format of optical platters is platform-specific. Optical platters written on one platform cannot be read on another platform.

◆

The Solaris 8 6/00 release introduced volume manager (vold), which attempts to manage all removable media devices. When vold manages an optical disk, NetBackup cannot access it. To enable NetBackup access, so that optical disks will then work as they did before this change, edit /etc/vold.conf to comment out the following line: #use rmdisk drive /dev/rdsk/c*s2 dev_rmdisk.so rmdisk%d

The following is true of NetBackup support of optical media: ◆

Optical platters with a capacity larger than 5.2 GB are not supported.

◆

NetBackup does write a maximum of 2 GB of data per side of an optical platter. This provides a maximum of 4 GB of data per platter. Additional platter capacity is unused.

◆

NetBackup supports HP 92279T, HP 92289T, and HP 92279F media on AIX platforms. VSM does not run on AIX platforms.

461

VSM supports the following sector sizes and capacity combinations on HP-UX, Solaris, and IRIX: Supported Optical Media Platform

Model

Sector Capacity Size

Type

HP-UX

HP 92279T*

512

1.2GB

WriteMany

HP 92289T

512

1.2GB

WriteOnce

HP 92279F

512

2.3GB

WriteMany

HP 92289F

512

2.3GB

WriteOnce

SONY EDM4100B

512

4.1GB

WriteMany

SONY CWO4100B

512

4.1GB

WriteOnce

HP C7988A*

512

9.1GB

WriteMany

HP 92298T

1024

1.3GB

WriteMany

HP 92290T

1024

1.3GB

WriteOnce

HP 92280F

1024

2.6GB

WriteMany

HP 92290F

1024

2.6GB

WriteOnce

HP 88143J

1024

4.8GB

WriteMany

HP 88145J

1024

4.8GB

WriteOnce

HP C7987A

1024

9.1GB

WriteMany

HP 88147J

2048

5.2GB

WriteMany

HP 88146J

2048

5.2GB

WriteOnce

HP C7985A

2048

8.6GB

WriteMany

*

Notes about NetBackup Support

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

See the following HP web site for more information about compatibility for these optical platters: http://www.products.storage.hp.com/eprise/main/storage/DisplayPages /compatibility.htm?DataPage=rewritable-disks

462

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Supported Optical Media Platform

Model

Sector Capacity Size

Type

Notes about NetBackup Support

HP-UX

HP C7985A

2048

8.6GB

WriteMany

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

HP C7986A

2048

8.6GB

WriteOnce

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

HP C7983A

4096

9.1GB

WriteMany

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

HP C7984A

4096

9.1GB

WriteOnce

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

HP 92279T

512

1.2GB

WriteMany

HP 92289T

512

1.2GB

WriteOnce

HP 92279F

512

2.3GB

WriteMany

HP 92289F

512

2.3GB

WriteOnce

SONY EDM4100B

512

4.1GB

WriteMany

SONY CWO4100B

512

4.1GB

WriteOnce

HP C7988A

512

9.1GB

WriteMany

HP 92279T

512

1.2GB

WriteMany

HP 92289T

512

1.2GB

WriteOnce

HP 92279F

512

2.3GB

WriteMany

HP 92289F

512

2.3GB

WriteOnce

HP 92298T

1024

1.3GB

WriteMany

HP 92290T

1024

1.3GB

WriteOnce

HP 92280F

1024

2.6GB

WriteMany

HP 92290F

1024

2.6GB

WriteOnce

(continued)

Solaris

IRIX

Appendix C, Notes on Supported Optical Media

Media Manager can mount this media. VSM writes to it, but NetBackup does not.

463

464

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Glossary ad method The method name for migrating to alternate disk. alternate copy The second copy of a migrated file. See also primary copy. alternate level The migration level that pertains to the second copy of a migrated file. VSM-Java designates the level for the Alternate copy of a file as Alternate Level: 2 and the multilevel migration levels associated with it as Alternate Level: 4, and so on. See also primary level. API Application Programming Interface. See also DMAPI. archiving The process of backing up files and directories to a storage unit and then deleting the original files and directories. backup The process of copying and saving files and directories to storage media. badness See threshold, move threshold, and purge threshold. References in this manual to badness have been changed to threshold, although “badness” is still used in some commands and scripts. Badness refers to the parameters used for selecting files to be migrated, moved, or purged. caching The process of copying migrated files back to the managed file system for access.

465

caching delay The length of time an application is blocked after accessing migrated data and before the data is available online (cached). concurrent recording The process of copying data to more than one storage device at the same time. Sometimes called concurrent stripes. configuration file (migconf) The file that contains the migration parameters for a single managed file system. The default path name for this file is dwpath/database/migconf. configuration file, global (migconfg) The file that defines a collection of managed file systems along with their attributes. The default path name for this file is /usr/var/openv/hsm/database/migconfg. configured slice The portion of the front of a file retained on disk for user access even when the file is completely migrated. consolidation See volume consolidation. ct method The method name for migrating to STK-9840 technology cartridge tapes (8mm double-density). VSM-Java refers to this storage method as Tape 2. Densities for storage methods are configurable. daemon A program that runs in the background and performs some task (for example, starting other programs when they are needed). See migd daemon, migrd daemon, and migvold daemon. defragmenting directories Data in a directory can be grouped, then migrated and cached as a one entity. When you defragment a directory, you first cache any previously migrated data and then migrate all data in the directory to a minimal number of tapes. Defragmenting reduces the mount and search time whenever the grouped directory is cached.

466

VERITAS Storage Migrator System Administrator’s Guide for UNIX

demand delay parameter The time in seconds a mount request waits before VSM unmounts a similar unused volume. device manager The part of Media Manager that allocates or deallocates drives based on availability. directory groups Directories that have been grouped so its files and those in its subdirectories will be selected for migration, premigrated, migrated, purged, and cached as one entity. dk method The method name used for copies of a file not yet copied to secondary storage. The dk method is not available as a secondary storage method. DMAPI Data Management Application Programming Interface. DMAPI is the interface between Storage Migrator and the operating system kernel. dt method The method name for migrating DLT 7000 technology tapes. VSM-Java refers to this method as Tape 3. Densities for storage methods are configurable. dwpath The pathname of the managed file system directory containing the database and workdir directories. effective slice The variable portion of a migrated file that can be partially cached (copied back) to disk if partial file caching is enabled. empty volume A volume that contains no active or obsolete files. See recycling. ENOSPC The error condition indicating there is no space left on a device.

Glossary

467

export The process of removing migrated files from one managed file system that will be imported to another managed file system. See also import. file handle A unique sequence number that VSM uses to identify migrated files and unmodified cached files. File handles are stored in the VSM databases for the managed file system. FHDB The file handle database. Each managed file system uses a separate file handle database. The default path name for this file is dwpath/database/FHDB. FNDB The file name database. Each managed file system uses a separate file name database. The default path name for this file is dwpath/database/FNDB. free space The space in the managed file system that is open for creating new files. free space parameter The disk utilization point at which VSM begins to free disk space by deleting purge candidates. This value is expressed as a percentage of unused space. If the freespace parameter is set to 10, VSM will begin to delete purge candidates when the file system is 90% full. Sometimes referred to as the high-water mark. ft method The method name for migrating to a remote volume using FTP. FTP File Transfer Protocol. global configuration file See configuration file, global (migconfg). global stop file See stop file, global.

468

VERITAS Storage Migrator System Administrator’s Guide for UNIX

granule VSM can divide migrated files into granules (parts of files) when it copies them to secondary media. A granule is the smallest unit of a file; it is never split across volumes. The size of the granule is configurable. grouped directory See directory groups. GUI Graphical User Interface. The VSM GUI is called VSM-Java. handle See file handle. hierarchical storage management (HSM) The process of automatically migrating selected files from a managed file system to secondary storage while maintaining transparent user access to those files. hierarchy A managed file system and its migration attributes; used by VSM-Java. high-water mark See free space parameter. hint value See volume set availability. HSM See hierarchical storage management (HSM). In previous versions of documentation for this product, HSM referred to VERITAS Storage Migrator. All such references are now VSM server. HSMDEV entry The hsmname in the global configuration file that specifies the attributes of a managed file system. hsmname The name of a managed file system. This is usually the same as the file system mount point. The maximum length is 32 characters. Glossary

469

IHAND file The inode-to-handle file, containing inode and handle information about migrated files. The default path name for this file is dwpath/database/hsmname.IHAND. import The process of adding migrated files to one managed file system that previously have been exported from another managed file system. See also export. inode The data structure that defines the existence of a single file. level, migration See migration level. library volume set availability The volume set availability (the configuration parameter that designates how long it takes VSM to access data on secondary storage) of a stripe is set to library to specify that VSM needs the minimum time to access data. Generally library indicates online storage (such as tape or disk). library is the default for the primary copy of a file. low-water mark The disk utilization point at which VSM stops selecting migration candidates. This value is expressed as a percentage of used disk space. If the low-water mark is set to 80, VSM will stop selecting migration candidates when the managed file system is 80% full. managed file systems The combination of components that VSM uses to organize and manage file data. managed server See VSM server. media The physical tapes, optical disks, or disks upon which data is stored. Media Manager The VERITAS software that provides device management and removable media management of tapes and optical disks. VSM requires Media Manager to operate.

470

VERITAS Storage Migrator System Administrator’s Guide for UNIX

method name The name assigned to a set of parameters referring to storage device and media. See storage method. migd daemon The migration daemon. The default path name for this file is /usr/openv/hsm/bin/admincmd/migd. migrate file, global A list of files or directories that the administrator wants VSM to select for migration. migrate file, local A list of files or directories that a user wants VSM to select for automatic migration. migration The process of copying files to secondary storage while retaining the file names in the managed file system and providing access to file data. migration level The numbered level associated with the location of a migrated file copy on secondary storage. The primary level stores the first copy of a file and is required for migration. VSM has up to eight multilevel migration levels. migration candidates The files that VSM determines can be migrated according to predefined selection criteria configured by the VSM administrator. migrd daemon The migration request daemon used for VSM-Java. The default path name for this file is /usr/openv/hsm/bin/admincmd/migrd. migvold daemon The volume daemon. The default path name for this file is /usr/openv/hsm/bin/admincmd/migvold. MOTAB Mount table file. The MOTAB file is used to keep track of all volumes mounted for read access only. The migvold will create the MOTAB file if it does not exist.

Glossary

471

move threshold The calculated value for a file that determines whether or not it is selected to be moved from one migration level to another. Formerly called move badness. mount point The location of a file system on a disk that logically connects to a system’s directory structure. This connection makes the file system available to users and applications. A file system’s mount point is usually the same as its hsmname, but this is not required. mt method The method name for migrating to Sony AIT-2 technology 8 mm tapes. In VSM-Java, this method is named Tape 1. Densities for storage methods are configurable. multilevel migration The process of moving migrated files to and from up to eight migration levels (locations on secondary storage) with VSM. nb method The method name for using NetBackup to make copies of files for migration. Caution The NetBackup (nb) method will not be supported in the next release of VSM. Choosing this method will require conversion for the next release. Several disadvantages exist in using the NetBackup method, as described in the VERITAS Storage Migrator System Administrator’s Guide for UNIX. Read this information before you consider configuring the nb method. NetBackup policy Defines the backup policy for a group of one or more clients that have similar backup requirements. NFS Network File System. A Sun Microsystems client-server application that allows network access to shared files. offline storage Storage media not physically loaded in a storage unit.

472

VERITAS Storage Migrator System Administrator’s Guide for UNIX

op method The method name for migrating to optical disk as tape with random seek. The default for this method is rewritable optical disk, but the value is configurable. operator volume set availability The volume set availability (the configuration parameter that designates how long it takes VSM to access data on secondary storage) of a stripe was set to operator to specify operator intervention was required to mount volumes. The value operator is not configurable using VSM-Java. ow method The method name for migrating to optical disk as tape with random seek. The default for this method is write-once, read many (WORM) optical disk, but the value is configurable. partial file caching The VSM process that allows read access to a migrated file without caching the entire file. policies, NetBackup See NetBackup policy. premigration The first step in the migration process, during which files are assigned a file handle and put on a migration work list. primary copy The first copy of a migrated file. See also alternate copy and primary level. primary level The migration level that pertains to the first copy of a migrated file. VSM-Java designates the level for the Primary copy of a file as Primary Level: 1 and the multilevel migration levels associated with it as Primary Level: 3, and so on. See also alternate level. pseudodevice A UNIX device with a /dev entry and a device driver that does not require a real device for I/O. purge The process of deleting files from local disk that have been copied to secondary storage.

Glossary

473

purge candidates The managed files that have been copied to one or more secondary storage devices and remain on local disk. VSM can purge these files to manage the configured threshold of free space in the file system. purge mark The disk utilization point at which VSM stops deleting purge candidates. This value is expressed as a percentage of used disk space. If the purge mark is set to 85, VSM will stop deleting purge candidates when the managed file system is 85% full. purge threshold The calculated value for a migrated file that determines whether or not it is selected to be purged. Formerly called purge badness. quota parameter The maximum number of bytes that each user can restrict from migration. recycling The process of recovering wasted space on storage media by reregistering an empty volume. remote volume server The server upon which a remote volume resides. remote storage The storage of migrated files on a remote volume server. See ft method and ad method. restore The process of recovering selected files and directories from a previous backup and returning them to their original directory locations (or to an alternate directory). secondary storage Storage of migrated files on storage units connected locally to the managed server. slice The configured amount of the front of a migrated file that remains on local disk to enable rapid access. See also configured slice and effective slice.

474

VERITAS Storage Migrator System Administrator’s Guide for UNIX

sparse file A file with large amounts of blank space in it. Such files save disk space because the file system does not allocate disk space to the file until blank space is taken up by data. stop file, global A list of files or directories of files that the administrator does not want to migrate. stop file, local A list of files or directories of files that a user does not want to migrate. storage method The specification of how migrated files are copied to different migration locations in secondary storage. A storage method consists of one or more stripes (location parameters). storage unit The type of storage device on which VSM or NetBackup stores files. It may be a robotic device or a single tape drive. stripe The set of location parameters used to define a storage method: method name, volume set number, volume set availability, and pool name. A storage level consists of stripes. threshold The calculated value for a file that determines whether or not it is selected to be migrated. References in this manual to badness have been changed to threshold, although the term badness is still used in some commands and scripts. threshold, move; threshold, purge See move threshold; purge threshold. unmount delay parameter The time in seconds that a volume mounted in read mode can remain mounted pending another read request. volume set availability The volume set availability (the configuration parameter that designates how long it takes VSM to access data on secondary storage) of a stripe is set to vault to specify that VSM needs the maximum time possible to access data. Generally vault indicates offline, or even off site, storage. vault is the default for the Alternate copy of a file.

Glossary

475

VOLDB The VSM volume database, which contains attributes of each volume registered with VSM. The default path name for this file is dwpath/database/VOLDB volume A tape, optical disk, or disk partition that has been registered and labeled. volume consolidation The process of moving file data from volumes to be recycled to other volumes and updating the VSM databases. See also empty volume and recycling. volume manager See Media Manager. volume pool A group of volumes to be used for one purpose that are protected from access by other applications and users. volume set One or more volumes sharing the same method name and volume set number. volume set availability The configuration parameter that specifies how quickly VSM can access data on secondary storage. The value library specifies immediate availability; the value vault specifies offline storage. The value operator is not configurable using VSM-Java; it was formerly used to specify that operator intervention was required to mount volumes. volume set number The number assigned to a volume when media is registered (labeled). See storage method. VSM-Java Graphical user interface to VSM configuration, administration. and management tools. VSM server The server on which the managed file systems reside and VSM software executes. WORM Write Once, Read Many; the acronym for optical disks or tapes that can be written to one time and read many times. 476

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Index definition 465 Append flag 119 Architecture overview 6 Architecture, VSM 6 Archiving definition 465

A Accelerated file space availability configuration 130 file increment 131 overview 30 performance trade-offs 69 space increment 131 time increment 131 Accessibility VSM-Java 90 Access-time bias (volume set availability) 62 Action menu VSM-Java 100 Active state managed file systems 193 managedfile systems 8 Activity bar VSM-Java 94 Activity states see States ad method 60 overview 1 Administration interface see VSM-Java Age weight configuring 134 moving files 83 purging files 81 selecting files 75 Alternate level definition 465 Alternate magnetic disk see ad method APIs

B Backups definition 465 managed file systems 190 NetBackup requirement 6 VSM databases 190 VSM procedure 191 Badness see Thresholds Basic Configuration Wizard 103 block_size parameter 120 bpbkar and bpbtar NetBackup requirement 6 C Caches choosing copy to use 15, 17, 20, 31, 62 definition 465 delays definition 466 demand delay parameter 15 multilevel migration 31 optimizing performance 64 overview 13 partial file caching 17 Reporting Tool and 163 total and partial file caching 477

trade-offs 68 total file caching 16 unmount delay parameter 15 Capacity Advanced Configuration Wizard 120, 122 Cautions changing the IHAND file 195 configuring two drives for two copies 57 database directory 49 editing VSM databases 232, 251 FlashBackup 190 forced registration 66 NetBackup backup retention 191 policy conflicts 190 NFS mount point 3 Partial VSM restore 191 Restore previous VOLDB 190 volume management 202 Characters, special supported in VSM 74 Class, NetBackup see NetBackup policy Commands gethsm 264 HSMKiller 266 ihprint 268 Man pages 261 migactivate 273 migadscan 275 migalter 278 migbatch 24, 281 migcat 284 migchecklog 285 migcleanup 288 migconf 290 migconfg 306 migcons 310 migconsweep 314 migdbcheck 316 migdbdir 327 migdbrpt 328 migfind 333 478

migftscan 335 miggetvol 339 miggroup 341 migin 346 miglicense 348 migloc 350 miglow 29, 353 migmdclean 354 migmove 358 mignbexport 363 mignbimport 367 mignbscan 371 mignewlog 375 mignospace 377 migpolicy 380 migpurge 30, 382 migrate 30, 383 migrc 386 migrd 388 migreconstruct 389 migrecycle 392 migreg 395 migselect 400 migsetdb 402 migstage 408 migtestbadness 410 migtie 415 migtscan 419 migungroup 341 migunmigrate 423 migVSMshutdown 424 migVSMstartup 425 migVSMstate 427 rebuild_ihand 429 startmigd 430 stopmigd 432 stopmigrd 434 VSM 435 Concurrent recording definition 466 example 63 restraints on 64 Configuration Basic Configuration Wizard 103 files

VERITAS Storage Migrator System Administrator’s Guide for UNIX

definition 466 migconf 56 migconfg (global), definition 466 global overview 45 planning 46 migrate (.migrate) file 218 migstop (.migstop) file 218 overview 45 parameters free space 468 scripts 200 storage devices 91 update fstab file 200 Configuration pane Scheduling tool 176 Configure menu VSM-Java 100 Configured slice definition 466 recommended minimum 16 Consolidation volume multilevel migration 32 one step 208 overview 204 two step 210 volumes definition 466 Copied data Reporting Tool 164 Copies concurrent recording 63 configuring number of 57, 116 parameter 116 which to cache first 62 Copy processor 34 copydb files description 240 multilevel migration 34 overview 12 ct method definition 466 description 59 overview 1 Index

Customization file migration criteria 84 file purging criteria 84 migration policy 227 migsweep.site 84, 242 migsweepm.site 243 D Daemons definition 466 migd overview 7 migrd starting 89 migvold overview 8 starting 198 starting and stopping 197 Data comparisons of file systems 182 Database directory, location 39 Database tools VSM-Java 151 Databases backing up 190 caution for editing 232, 251 cautions when choosing 49 checking consistency of 195 choosing directories for 49 description 232 determining directories 49 dwpath definition 467 file handle see FHDB file handle (FHDB) definition 468 file name see FNDB files contained in 39 list of 232 managed backup and delete 157 migrating files 157 searching 156 479

managed server 233 Media Manager 21 migconf file 49 Oracle see Oracle archive redo logs problem solving 251 reports 249 space requirements 51 volume see VOLDB Dead data consolidating volumes 204 FHDB flags field 233 multilevel migration 32 recycling volumes 208, 213 Dead FHDB entries multilevel migration move flags 150 dead_man_timeout parameter 121, 123, 124 Defragmenting directories, definition 466 Delayed labeling 125 Deleted files reloading 258 demand delay parameter Advanced Configuration Wizard 121 caches 15 definition 467 density parameter Advanced Configuration Wizard 120 Device manager definition 467 Devices storage methods for 58 Directories remote volume server 42, 127 Directory group see Directory-level migration Directory-level migration 20 definition 20, 467 Disk magnetic 480

see dk method, ad method, ft method optical see Optical disk Disk file storage methods see dk method Disk space ENOSPC error definition 467 FHDB 50 management overview 22 dk method definition 467 overview 1 DMAPI definition 467 token 197 Documentation related xxii dt method definition 467 description 59 overview 1 dump command backing up standard file systems 190 backing up VSM databases 190 cautions 191 dwpath definition 467 E Edit menu VSM-Java 97 Effective date Scheduling tool 175 Effective slice definition 467 Emergency file space parameters 30 Empty volumes definition 467 recycling 213 End of tape flag 119

VERITAS Storage Migrator System Administrator’s Guide for UNIX

ENOSPC definition 467 error 30 Exports description 35 of migrated files definition 468 overview 35 planning 230 F FHDB 10, 49, 233 clear locks 252 definition 468 description 49, 233 disk space 50 estimated disk space 50 fixing 251 flags field description 233 multilevel migration 34 location 39, 307 lock file description 242 location 307 number of entries 49 problem solving for 251 recovering 255 space requirements 50 template 42 updating 12, 34 File Browser 167 grouping directories 171 main screen 167 managing job activity 171 migrating files 172 migration 167 purging files 172 File Export/Import see Exports see Imports File handle definition 468 sequence file 242 unassignable 255 Index

File handle database see FHDB File increment accelerated file space availability 30, 69 configuring 131 mignospace command and 28 File marks 229 File menu VSM-Java 97 File name database see FNDB File servers Macintosh 47 VSM managed 476 File slice configured configuring 130 definition 16 replaces effective slice 19 space requirements 48 effective definition 16 replaces configured slice 19, 68 overview 15 size configuring 130 File slices configured definition 466 effective definition 467 File space, accelerated availability 30 File System Analyzer comparing data 182 file system scans 182 deleting 188 main screen 180 menus 181 testing migration policies 187 File systems creating fstab file 200 managed backing up 190 481

checking consistency of 195 considering number of files 48 definition 45 idle state 197 inode requirements 48 log files 245 making free space on 196 migration thresholds 70 purge thresholds 80 rules for choosing 46 space for slice 48 mounting demand delay 467 scans 182 unmount delay parameter 475 File-handle-sequence file description 242 location 39, 307 rebuilding 255 Filenames special characters supported 74 Files disk 1 not to migrate 46 remote volume server 42 Flags field FHDB 233 VOLDB 238 FlashBackup, caution for 190 FLUSH file definition and use 229 location 40 FNDB definition 468 Free space creating on file systems 196 definition 468 file systems 196 parameter definition 468 Free space parameter default value 73 description 22 migration 482

configuring 132 planning guidelines 73 fspath location 36 fstab file updating for managed file systems 200 ft method definition 468 overview 2 partial file caching 17 FTP ft method 2 port number 123 G gethsm command man page 264 GLABEL file 43 Global log file file systems in Maintenance state 195 viewing 244 Global migrate file definition 471 Global stop file definition 475 gran_size parameter description 121, 122, 124 Granules definition 469 description 12 file-handle entries for 49 Grouped files migration of 171 GUI see VSM-Java H Help menu VSM-Java 101 Hierarchy VSM-Java definition 469 description 93 High-water mark

VERITAS Storage Migrator System Administrator’s Guide for UNIX

see Free space parameter HSMDEV entry definition 469 see also hsmname parameter HSMKiller command killing blocked processes 252 man page 266 releasing tape requests 260 hsmname parameter definition 469 I ID_LABEL file 43, 244 Idle state 8, 193, 197 Idling state 8, 193 IHAND file administering 198 caution for changing 195 check and fix 200 creating 198 definition 470 description 198 extending 199 format 198 location 40, 307 recover 200 space requirements 50, 199 ihprint command man page 268 Illegal characters, file names 74 imageID nb method 203 Imports description 35 of migrated files definition 470 overview 35 planning 230 Inactive state 8, 193 Inodes definition 470 managed file systems 48 Installation VSM overview 90 Index

J Java VSM-Java Administrator interface 89 Job activity management File Browser 171 L Label volume for tape media 125 Label, volume alternate disk 125 for FTP 126 for NetBackup 128 for tape media 66 lgpath parameter overview 40 library volume set availability planning 62 Links, symbolic 218, 219 Local migrate file definition 471 Local stop file definition 475 Locks, clearing VSM 252 Log files 248 choosing paths 51 global log file, location 40 linking global 200 managed file systems viewing 245 managing 247 messages, level of location 41 viewing 244, 245 VSM-Java creating for 248 Logs Oracle archive redo 153 VSM management of Oracle redo logs 151 Low-water mark 483

configuring 132 default values 70 definition 470 description 22 planning guidelines 70 M Macintosh file servers 47 Magnetic disk media 1 Maintenance state 8, 193 Man pages 261 Managed directory Oracle archive redo logs 130 Managed file system reports Reporting Tool 162 Managed file systems definition 470 Managed server, definition 2 Management tasks scheduling with VSM-Java 173 Managing VSM 189 Manuals related xxii Media consolidate volumes 208 definition 470 magnetic disk 1 monitoring usage 202 moving volumes offline 214 not enough tapes available 260 optical notes on support 461 recycling 208 registration automatic, tape & optical 12, 203, 204 releasing tape requests 260 reports 249 storage methods to use 58 Media Manager configuring storage devices 91 definition xxiii, 470 device manager 484

definition 467 installation 90 overview 21 shared storage devices 2 terminology used xxiii mediacheck command fixing the FHDB 251 Menus Action VSM-Java 100 Configure VSM-Java 100 Edit VSM-Java 97 File VSM-Java 97 File System Analyzer 181 Help VSM-Java 101 View VSM-Java 98 VSM-Java 97 Method names definition 471 migrating files 58 METHOD1-8 examples 64 name parameters ct 59 dt 59 mt 59 nb 61 op 59 ow 59 names to use for magnetic disk storage 58 NetBackup 58 NFS file system 58 optical disk storage 58 remote storage 58 tape storage 58 overview METHOD1-2 57 METHOD3-8 67 volume set availability

VERITAS Storage Migrator System Administrator’s Guide for UNIX

parameter 62 MicroSoft platforms for VSM-Java 90 migactivate command man page 273 migadscan command archive disk report 250 man page 275 migalter command man page 278 migattr driver 192 migbatch command 24 calling from VSM-Java 223, 225, 226 man page 281 migcat command man page 284 migchecklog command man page 285 migcleanup command man page 288 migconf command man page 290 migconf file description 243 location 40, 307 overview 56 planning worksheet 49 template 42 migconfg command man page 306 migconfg file location 41 overview 45 planning worksheet 46 template 41 migcons command man page 310 recycling volumes with 208 migconsweep command man page 314 migcopy command overview 7 migd daemon 7 definition 471 starting and stopping 197 Index

migdbcheck command man page 316 used to fix VOLDB 253 migdbdir command man page 327 migdbrpt command man page 328 migration database report 250 migfind command man page 333 migftscan command man page 335 remote volume report 250 miggetvol command man page 339 miggroup command directory level migration 20 man page 341 migin command man page 346 reloading deleted files 258 miglicense command man page 348 migloc command man page 350 miglow command man page 353 overview 29 migmdclean command man page 354 migmerge.sh script 34 migmove command creating work lists 34 man page 358 mignbexport command man page 363 mignbimport command man page 367 mignbscan command man page 371 mignewlog command 248 man page 375 mignospace command man page 377 migopscan command 485

optical volume report 250 migpolicy example script 42 migpolicy command man page 380 migpolicy script creating work lists 12 customizing 227 modifying 65 template 42 migpolicy.script changing 42 migpurge command man page 382 overview 30 Migrate definition 471 see also Migration migrate (.migrate) file file system sweeps 25 rules for creating 218, 219 migrate command man page 383 overview 30 Migrate file see also Migrate see also Migration Migrate file, global file system sweeps 25 location 41 migration control 218 Migrated files exporting definition 468 Migration automatic overview 22 best times for 53 control, global 218 database report 250 directory level 20 example schedule 54 File Browser and 172 file selection configuring 133 486

criteria 76 overview 73 procedure for planning 76 frequency 54 management overview 22 minimum file age planning 74 minimum file size 23 planning 74 overview 9 performance 229 planning 45 policies testing with File System Analyzer 187 restarting 259 scheduling 53, 222 see also Migration level tape 229 thresholds overview 70 planning procedure 56 time to complete 48, 54 with migbatch command 24 with miglow command 29 with migrate command 30 Migration candidate definition 471 Migration levels definition 470 see also Migration migrc command man page 386 restarting migrations with 259 migrd command man page 388 migrd daemon definition 471 starting 89 starting and stopping 197 migrd.log creating 248 migreconstruct command man page 389 migrecycle command

VERITAS Storage Migrator System Administrator’s Guide for UNIX

man page 392 migreg command man page 395 migsa command 89 migselect command man page 400 volume consolidation 208 migsetdb command man page 402 migstage command man page 408 partial file caching 17 migstop (.migstop) file rules for creating 218, 219 migsweep.site changing 42 description 242 template 42 migsweepm.site changing 42 description 243 template 42 migtestbadness command man page 410 migtie command man page 415 partial file caching 17 migtscan command man page 419 tape volume report 250 migungroup command man page 341 migunmigrate command man page 423 migvold daemon definition 471 overview 8 starting and stopping 197 migVSMshutdown command explained 197 man page 424 VSM states 9 migVSMstartup command 192 man page 425 startup problems 195 Index

VSM states 9, 193 migVSMstate command man page 427 VSM states 9 migworker script 12, 34 Minimum file age for migration description 23 guideline for setting 76 Minimum file size for migration description 23 guideline for setting 76 mode bit field, fls command 5 MOTAB, location 41 Mount table, global 41 Mounts demand delay parameter definition 467 unmount delay parameter 475 Move flags, configuring 150 Move threshold definition 475 file formula for 82 site-specified 243 weighting factors 82 Moving minimum file age planning 82 minimum file size planning 82 mt method definition 472 description 59 overview 1 Multilevel migration caches 31 copydb files 240 definition 472 file selection criteria 81 minimum file age planning 82 minimum file size 487

planning 82 overview 31, 33 volume consolidation 32, 34 work lists 240

cleaning nb volumes 203 consolidating volumes 204 FHDB flags field 233 multilevel migration 32 recycling volumes 213 Obsolete FHDB entries backup retention period 191 consolidating volumes 204, 207, 208, 210 for modified cached files 14 multilevel migration move flags 150 Obsolete flag 122, 123, 124 Offline storage 214 definition 472 op method definition 473 description 59 overview 1 operator volume set availability planning 62 Optical disk notes on support 461 op method 1, 59 ow method 1, 59 write once, read many (WORM) 59 Options tree Scheduling tool 175 Oracle archive redo log management 151 Oracle archive redo logs backup and delete 157 management 151, 152 migrating files 157 searching 156 Oracle databases see Oracle archive redo logs ow method definition 473 description 59 overview 1

N nb method defining NetBackup policy for 128 definition 472 description 61 overview 2 partial file caching 17 nb volumes cleaning 203 NetBackup caution for 190 file backup with 190 migrated files 191 nb method 2 policy caution for 190 defining 128 requirement for VSM 6 retention, caution for 191 schedule defining 128 servers 128 slice value lost 191 storage nb method 61 support of optical disk 461 Next-volume-set files description 242 location 39, 307 NFS (Network File System) mount point 3 mounted file system managing 46 operations 197 rules for using 3 NT platform for VSM-Java 90 O Obsolete data backup retention period 191 488

P Partial file caching

VERITAS Storage Migrator System Administrator’s Guide for UNIX

Configuring with VSM-Java 130 definition 473 disabling 19, 130 ft method 17 nb method 17 overview 17 purging files 20, 80 total file caching trade-offs 68 Partial VSM restore, caution for 191 Pathname length, requirements 74 Performance constant sweeping 31 migrating small files 229 migration to tape 229 Reporting Tool 165 trade-offs accelerated file space availability 69 constant sweeping 31, 230 partial file caching 68 Planning database directories 49 global configuration 46 migration requirements 45 migration thresholds 70 purge thresholds 80 storage methods 57 summary procedure 84 Policies migration testing with File System Analyzer 187 Policy see NetBackup policy Pools volume media management 21 multiple 63 VSM volume pool 119 port_number parameter 123 Power down remote volume server 198 Premigration calling from VSM-Java 223, 225, 226 definition 473 Index

overview 24 Primary copy definition 473 Primary level definition 473 Problem solving automatic removal or migration failure 259 clear FHDB locks 252 create new log files 248 fix FHDB 251 fix FHSEQF 255 fix VOLDB 253 recover FHDB and VOLDB 255 release tape requests 260 reload deleted files 258 reports 249 restart migrations 259 startup 195 user file access 259 volumes insufficient 260 Process id (pid) migd 41 migvold 42 Processes, killing VSM 252, 260 Pseudodevice definition 473 Purge mark configuring 132 default values 71 definition 474 description 22 planning guidelines 71 Purge thresholds definition 474 file formula for 81 site-specified 75, 242 weighting factors 81 Purges migpurge command 30 minimum file age planning 81 minimum file size 489

planning 81 partially cached files 20, 80 problems with automated 259 thresholds overview 80 with File Browser 172

setting preferences 160 starting 158 Reports, media and database 249 Restart time window Scheduling tool 175 restore command backing up standard file systems 190 backing up VSM databases 190 cautions 191 Restores definition 474 Run days Scheduling tool 175

Q quota parameter configuring 130 definition 474 planning 67 R Read ahead configuring 130 explained 18 rebuild_ihand command man page 429 Recovery operations 9, 195 Recycling volumes 208, 213 definition 474 Redo Logs Oracle VSM managmement 151 Remote migration ft method 2 Remote storage ad method 60 definition 474 nb method 61 Remote volume server definition 474 description 2, 126 shutdown 198 Reporting Tool 158 data copied reports 164 data retrieval (caching) reports 163 data retrieval reports 163 file and space usage 161 lperformance reports 165 main window 158 managed file system reports 162 menus 159 performance reports 165 490

S Scans deleting File System Analyzer 188 performing File System Analyzer 182 Schedules backing up VSM databases 190 component configuration Scheduling tool 175 configuration pane 176 effective date 175 for migrations 53, 222 general options 175 management tasks using VSM-Java 173 migrations 53, 222 options tree list 175 restart time window 175 restarting tasks 177 run days 175 settings Scheduling tool 177 summary Scheduling tool 178 summary of configured tasks 178 time window 175 Scheduling tool configuration pane 176 general options 175

VERITAS Storage Migrator System Administrator’s Guide for UNIX

main window 173 options tree list 175 restart time window 175 run days 175 schedule component configuration 175 schedule summary 178 scheduling tool 177 tasks restarting 177 time window 175 Scripts migmerge.sh 34 shutdown 197 startup 192 Secondary storage definition 474 Servers managed 2 remote 2 Session id (sid) migd 41 Shutdown activity states 196 overview 193 remote volume server 198 scripts for all platforms 197 shutting down VSM see also Shutdown Size weight configuring 134 overview 75, 81, 83 Slice see File slice Small file migration Space increment accelerated file space availability 30, 69 configuring 131 used with mignospace command 28 Sparse file definition 475 startmigd command 89 man page 430 Index

Startup problems 195 scripts 192 VSM overview 9 Startup scripts 192 States fixing the FHDB 251 VSM activity 8 Stop file global location 41 migration control 218 stopmigd command man page 432 stopmigrd command man page 434 Stopping VSM see Shutdown stopping VSM operations see also Shutdown, VSM Storage devices installation 90 Storage methods configure with VSM-JavaI 118 criteria for selecting 64 ct 466 definition 475 dk 467 dt 467 effect of media cost 64 ft 468 mt 472 nb 472 op 473 overview, file migration 11 overview, multilevel file migration 33 ow 473 planning overview 57 reconfiguring 228 Stripes concurrent recording 63 definition 475 description 58 491

multiple 63, 64, 67 sweep.restart file 25 Sweeps file system constant 31 round-robin 25 Symbolic links 218, 219

used with mignospace command 28 Time window Scheduling tool 175 Timestamp nb method 203 Tokens, DMAPI 197 Toolbar VSM-Java 95 Total file caching overview 16 partial file caching trade-offs 68 Trailer labels tapes 196

T Tape marks frequency 229 Tapes ct, dt, and mt methods 59 duplicating 215 missing trailer labels 196 not enough available 260 performance 229 random seek 1 releasing requests 260 supported tape methods 1 Tasks restarting Scheduling tool 177 Templates database files 42 file-handle database file 42 migconf file 42 migconfg file 41 migsweep.site 42 migsweepm.site 42 sample.migpolicy.script 42 volume database file 42 Threshold file examples 77, 78 formula for 74 selections 134 site-specified 84, 242 weighting factors 74 Thresholds definition 475 Time increment accelerated file space availability 30, 69 configuring 131 492

U UNIX platforms for VSM-Java 90 Unmount managed file systems 196 unmount delay parameter 15, 121, 475 User operations overview 5 V vault volume set availability planning 62 View menu VSM-Java 98 VOLDB 237 caution for restoring 190, 254 definition 476 description 237 fixing 253 flags field description 238 multilevel migration 34 location 39 lock file description 242 location 39 recovering 255 removing entries 214 template 42 updating 12 Volume database

VERITAS Storage Migrator System Administrator’s Guide for UNIX

see VOLDB Volume label for alternate disk 125 for FTP 126 for NetBackup 128 for tape media 66, 125 Volume pools definition 476 multiple 63 VSM 119 Volume set availability 62 planning 62 Volume sets concurrent recording 63 definition 476 description 58 moving volumes between 214 next set to use 242 Volumes allocation 21 assignments 21 consolidation definition 466 one step 208 overview 204 two step 210 damaged 214, 238 definition 476 destroyed 214 empty definition 467 full 238 lost 214 management 201 management of overview 21 Media Manager xxiii monitoring usage 202 mount points 42 moving offline 214 recycling 208 unused 202 Volume-sequence file description 242 location 39 Index

VSM server definition 476 VSM states 8 fixing the FHDB 251 VSM-Java Action menu 100 Activity bar (bottom pane) 94 advanced configuration wizard 113 Bottom Pane 94 configuration wizards 135 Configure menu 100 configure volume pools 119 database tools 151 definition 476 Edit menu 97 File menu 97 file system properties 129 Help menu 101 hierarchies in 93 Left Pane 93 log files creating log 248 managing 247 viewing 244, 245 login 91 main screen 92 manual configuration 145 menus 97 overview 89 PC platforms 90 premigrate and copy files 223, 225, 226 reconfiguration 147 restarting migrations with 259 Right Pane 93 setting states 9 starting daemons 198 starting interface 89, 193 starting migrd daemon 89 stopping Daemons 198 toolbar 95 tools backup and delete 157 for migrating files 172 for Oracle archive redo logs 153 493

for purging files 172 migrating database archive redo logs 157 migrating grouped files 171 searching databases 156 see also File Browser, File System Analyzer, Reporting Tool, Scheduling Tool, Managing Oracle Archive Redo Log Tool UNIX platforms supported 90 View menu 98 volume recycling 215 volume registration 124 W Weight operator configuration with VSM-Java 134

494

move threshold overview 83 purge threshold overview 81 threshold formula overview 75 Windows platforms for VSM-Java 90 Work directory location 38 Work lists description 240 multilevel migration 34 overview 12 Write Once, Read Many (WORM) 59 definition 476

VERITAS Storage Migrator System Administrator’s Guide for UNIX