EMC DiskXtender File System Manager for UNIX/Linux...EMC DiskXtender File System Manager for UNIX/Linux Release 3.5. SP1 Administrator’s Guide 9 Preface As part of an effort to improve

EMC CorporationCorporate Headquarters:

Hopkinton, MA 01748-9103

1-508-435-1000www.EMC.com

EMC® DiskXtender®

File System Manager for UNIX/LinuxRelease 3.5. SP1

Administrator’s GuideP/N 300-012-244

REV A02

EMC DiskXtender File System Manager for UNIX/Linux Release 3.5. SP1 Administrator’s Guide2

Copyright © 2004-2011 EMC Corporation. All rights reserved.

Published July, 2011

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their respective owners.

EMC DiskXtender File System Manager for UNIX/Linux Release 3.5. SP1 Administrator’s Guide 3

Preface................................................................................................................................9

Chapter 1 IntroductionFile system-based storage management ........................................ 14

Files always available to applications......................................14Data management.......................................................................15

Console-based administration ........................................................ 16Console Client ............................................................................ 16

Flexible topology............................................................................... 17Minimum topology ................................................................... 17Complex topology ..................................................................... 17Topology guidelines .................................................................. 18

Chapter 2 Console overviewConsole software............................................................................... 20

Console Server ............................................................................20Console Agent .............................................................................20Console Client .............................................................................21

Management domain ....................................................................... 22Single computer domain ...........................................................22Multiple computer domain .......................................................23

Console Client ................................................................................... 24Starting Console Client ..............................................................24

Administration .................................................................................. 26Adding a user..............................................................................26Removing a user .........................................................................28Changing your password ..........................................................28Changing a user's password .....................................................28

Contents


Contents

Monitoring......................................................................................... 30Clearing the events window ..................................................... 30Domain events ............................................................................ 30Domain activities ........................................................................ 32Host events .................................................................................. 34File system events....................................................................... 35File system activities .................................................................. 37File system state.......................................................................... 38

Chapter 3 File System ConfigurationPreliminary tasks .............................................................................. 44

Back-end module types ............................................................. 44Preliminary tasks for Centera module .................................... 45Preliminary tasks for FTP module ........................................... 52Preliminary tasks for NFS module........................................... 54

Configuring a file system ................................................................ 57Overriding configuration for file system subsets .................. 57Configure a file system .............................................................. 57Centera module .......................................................................... 64FTP module ................................................................................. 67NFS module................................................................................. 68

Viewing a file system configuration .............................................. 70Editing a file system configuration ................................................ 71Deleting a file system configuration .............................................. 72

Chapter 4 Extended RulesCreating an extended rule ............................................................... 74

Match string ................................................................................ 74Creating an extended rule......................................................... 80

Viewing extended rules ................................................................... 86Editing an extended rule ................................................................. 87Deleting an extended rule ............................................................... 88Copying extended rules................................................................... 89

Chapter 5 Scheduled JobsScheduled jobs overview ................................................................. 92

Effect on existing file system settings...................................... 93Delete Old Files job .................................................................... 94Prune job ...................................................................................... 95

Creating a scheduled job ................................................................. 96Creating a scheduled job ........................................................... 96

5EMC DiskXtender File System Manager for UNIX/Linux Release 3.5. SP1 Administrator’s Guide

Contents

Viewing a scheduled job ............................................................98Editing a schedule.......................................................................99Deleting a schedule...................................................................100

Time elements .................................................................................. 102Creating a new time element...................................................102Editing a time element .............................................................107Deleting a time element ...........................................................107

Chapter 6 Advanced UTDM Mount OptionsCentera system data retention....................................................... 110

Performance impact..................................................................110Requirements.............................................................................111Enabling Centera system data retention................................111Setting retention for a file system ...........................................113Setting retention for a group of files ......................................114Restoring incremental backups...............................................115

Read-only ......................................................................................... 117Mounting read-only..................................................................118

Direct-read........................................................................................ 120Memory-mapping.....................................................................120Mounting direct-read ...............................................................120

Chapter 7 Backup and RecoveryData to back up................................................................................ 124

FSM-related files outside of UTDM file systems..................124Files and data in UTDM file systems .....................................125

Backup software .............................................................................. 126FSM-aware backup software...................................................126Other backup software.............................................................127Snapshot software.....................................................................127

Recovering a lost file system ......................................................... 128Recovering an FTP module file system........................................ 130EMC Avamar ................................................................................... 132

EMC Avamar requirements ....................................................132Backup with Avamar software ...............................................134Recovery with Avamar software ............................................134Recovering persistent statistics with EMC Avamar ............135

EMC NetWorker .............................................................................. 137Requirements.............................................................................137Backup with NetWorker software..........................................137Recovery with NetWorker software ......................................138


Contents

EMC NetWorker 64-bit Linux version......................................... 141Requirements ............................................................................ 141Backup with EMC NetWorker 64-bit Linux version........... 142Recovery with EMC NetWorker 64-bit Linux version........ 142Recovering persistent statistics with EMC NetWorker 64-bit Linux version ............................................................................ 143

NetBackup software ....................................................................... 145NetBackup requirements......................................................... 145Backup with NetBackup software ......................................... 147Recovery with NetBackup software ...................................... 148Recovering persistent statistics with NetBackup software 148

FSM tools.......................................................................................... 150Backup with FSM tools ............................................................ 150Recovery with FSM tools......................................................... 151Recovering persistent statistics with FSM tools................... 153

Snapshots with SnapView ............................................................. 154Quiescing a UTDM file system............................................... 154Resuming UTDM file system activity ................................... 156Recovering a UTDM file system snapshot............................ 156

Import data from SM to FSM ........................................................ 158

Chapter 8 MaintenanceProcesses .......................................................................................... 164

Core processes........................................................................... 164Console processes..................................................................... 169

File administration.......................................................................... 172Manual migration, purge, and retrieval................................ 172

Periodic back-end system cleanup............................................... 175Centera system.......................................................................... 176Cleanup on FTP or NFS module back-end systems............ 178

Appendix A Command ReferenceCommand quick reference ............................................................ 182Command usage ............................................................................. 185

Setting the DMAP_ROOT_PATH.......................................... 185Setting the FSM environment ................................................ 185Administrative commands .................................................... 185File management commands................................................. 200Backup and recovery commands .......................................... 205


Title Page

1 Tasks permitted for operators and administrators .................................... 272 Columns on the Events for All Hosts window ........................................... 323 Columns on the All FSM Activities window .............................................. 334 Columns on the Events windows ................................................................. 355 Columns on the Events windows ................................................................. 366 Columns on the Activities window.............................................................. 387 File System State window .............................................................................. 398 Purge tab on the File System State window ................................................ 409 Migrate tab on the File System State window............................................. 4010 Staging tab on the File System State window ............................................. 4011 Destroy tab on the File System State window............................................. 4112 Recover tab on the File System State window ............................................ 4113 Available back-end module types ................................................................ 4514 Choices for the Authentication Type field................................................... 5415 Determining path of back-end mount point when using Solaris zones.. 5516 Determining full path when using Solaris zones ....................................... 5817 Checksum setting choices .............................................................................. 5918 Retention Period settings ............................................................................... 6419 Descriptions of Collision Avoidance settings ............................................. 6620 Possible keyword values in match string expressions............................... 7521 Possible operator values in match string expressions ............................... 7522 Possible variable values in match string expressions ................................ 7723 Possible Filesize-Units values in match string expressions ...................... 7824 Operator precedence in a match string ........................................................ 7825 Descriptions of Checksum settings............................................................... 8326 Descriptions of Retention Period settings ................................................... 8427 Scheduled job comparison ............................................................................. 9228 Components of a schedule............................................................................. 9329 Effect of a scheduled job on file system settings......................................... 9430 Delete Old Files job differences..................................................................... 95

Tables


Tables

31 Components of a time element ................................................................... 10232 Recurrence options ....................................................................................... 10333 Mounting with Centera system data retention......................................... 11234 Mounting read-only...................................................................................... 11935 Mounting direct-read ................................................................................... 12136 Supported backup software ........................................................................ 12637 FSM recovery commands............................................................................. 15138 Mounting a file system for utdm_recdmattrf ........................................... 15739 Administrative commands .......................................................................... 18240 File management commands....................................................................... 18341 Backup and restore commands................................................................... 18342 Options for fsmprivdelete............................................................................ 18743 Options for deldmsession ............................................................................ 18844 Options for dx_read_log .............................................................................. 18945 Severity levels ................................................................................................ 19046 Brevity levels.................................................................................................. 19147 Options for dxuldmclip................................................................................ 19248 Options for dxuldmdelclips ........................................................................ 19449 Options for expand_dmattrf........................................................................ 19550 Options for getdmattr................................................................................... 19751 Options for getfileattr ................................................................................... 19752 Options for dxstat ......................................................................................... 19853 Options for dxprstat ..................................................................................... 19854 Options for dxhardlink................................................................................. 19955 Options for getimplist .................................................................................. 20056 Options for getmiglist................................................................................... 20157 getmiglist file list columns........................................................................... 20258 Options for getpurgelist ............................................................................... 20359 getpurgelist file list columns headings ...................................................... 20460 Options for dxbuildtar ................................................................................. 20661 Options for dxcliplink .................................................................................. 20762 Options for dxdmload.................................................................................. 20863 Options for dxuldm_tar ............................................................................... 20964 Options for dmattrrecoverfs........................................................................ 21065 Options for getrecoverlist ............................................................................ 21166 getrecoverlist file list columns..................................................................... 21167 Options for utdm_fs_freeze......................................................................... 212


Preface

As part of an effort to improve and enhance the performance and capabilities of its product lines, EMC periodically releases revisions of its hardware and software. Therefore, some functions described in this document may not be supported by all versions of the software or hardware currently in use. For the most up-to-date information on product features, refer to your product release notes.

If a product does not function properly or does not function as described in this document, please contact your EMC representative.

Audience This guide is part of the EMC DiskXtender File System Manager for UNIX/Linux, release 3.5. SP1 documentation set, and is intended for use by system administrators.

Readers of this guide are expected to be familiar with the following topics:

◆ The organization’s data archiving strategy, in particular:

• Average archived file size

• Anticipated total number of files and total bytes to be archived

• File access norms: frequency of access during creation, edit, and archive phases

• Special file requirements, such as for shorter access times, multiple fail-safe copies, and optimal file stub size

• Backup strategies for data in the file systems

10 EMC DiskXtender File System Manager for UNIX/Linux Release 3.5. SP1 Administrator’s Guide

Preface

◆ The network details of all computer systems and hardware devices to be used, including:

• IP addresses

• TCP/IP routing information

• Switch, router, firewall, and network-attached device configurations

◆ The administration details of all involved storage targets

Relateddocumentation

Related documents include:

◆ The EMC DiskXtender File System Manager for UNIX/Linux Release 3.5 SP1 Release Notes

◆ The EMC DiskXtender File System Manager for UNIX/Linux Release 3.5 SP1 HP-UX Version Installation Guide

◆ The EMC DiskXtender File System Manager for UNIX/Linux Release 3.5 SP1 Solaris Version Installation Guide

◆ The EMC DiskXtender File System Manager for UNIX/Linux Release 3.5 SP1 AIX Version Installation Guide

◆ The EMC DiskXtender File System Manager for UNIX/Linux Release 3.5 SP1 Linux Version Installation Guide

◆ The EMC DiskXtender File System Manager for UNIX/Linux Release 3.5 SP1 Console Client for Microsoft Windows Installation Guide

Conventions used inthis guide

EMC uses the following conventions for notes and cautions.

Note: A note presents information that is important, but not hazard-related.

IMPORTANT!An important notice contains information essential to operation of the software.


Preface

Typographical conventionsEMC uses the following type style conventions in this document:

Normal Used in running (nonprocedural) text for:• Names of interface elements (such as names of windows,

dialog boxes, buttons, fields, and menus)• Names of resources, attributes, pools, Boolean expressions,

buttons, DQL statements, keywords, clauses, environment variables, functions, utilities

• URLs, pathnames, filenames, directory names, computer names, filenames, links, groups, service keys, file systems, notifications

Bold Used in running (nonprocedural) text for:• Names of commands, daemons, options, programs,

processes, services, applications, utilities, kernels, notifications, system calls, man pages

Used in procedures for:• Names of interface elements (such as names of windows,

dialog boxes, buttons, fields, and menus)• What user specifically selects, clicks, presses, or types

Italic Used in all text (including procedures) for:• Full titles of publications referenced in text• Emphasis (for example a new term)• Variables

Courier Used for:• System output, such as an error message or script • URLs, complete paths, filenames, prompts, and syntax when

shown outside of running text

Courier bold Used for:• Specific user input (such as commands)

Courier italic Used in procedures for:• Variables on command line• User input variables

< > Angle brackets enclose parameter or variable values supplied by the user

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means “or”

{ } Braces indicate content that you must specify (that is, x or y or z)

... Ellipses indicate nonessential information omitted from the example


Preface

Where to get help EMC support, product, and licensing information can be obtained as follows.

Product information — For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at:

http://Powerlink.EMC.com

Technical support — For technical support, go to EMC Customer Service on Powerlink. To open a service request through Powerlink, you must have a valid support agreement. Please contact your EMC sales representative for details about obtaining a valid support agreement or to answer any questions about your account.

Your comments Your suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Please send your opinion of this document to:

[email protected]

http://powerlink.emc.com

Introduction 13

1

This chapter covers the following topics:

◆ File system-based storage management ......................................... 14◆ Console-based administration ......................................................... 16◆ Flexible topology................................................................................ 17

Introduction


Introduction

File system-based storage managementEMC® DiskXtender® File System Manager for UNIX/Linux (FSM), release 3.5. SP1 is a data management solution that uses DMAPI-enabled (UTDM) file systems to transparently archive data on the following back-end storage systems:

◆ EMC Centera® Content Addressed Storage System (Centera system)

◆ Locally accessible disk resources

FSM transparently manages multiple local UTDM file systems. When necessary, it migrates and purges data from the file systems based on user-defined rules.

FSM frees up space by transferring the actual data associated with a file system object to a back-end system, while retaining the object’s metadata in the file system. This means that a migrated and purged file is fully available through the file system, but uses very little of the file system’s space.

Files always available to applicationsWhen an application starts a read or write operation on data that has been migrated and purged, FSM invisibly triggers a retrieval of that data. The data is returned to the file system and the operation is completed. The user is not required to initiate operations to import or export data. Data written to an FSM file system is fully available for all read and write operations without user intervention.

Access to migrated and purged data is the same as access to locally stored data, except for the possibility of a slight delay during the retrieval of data that has been purged from the file system.

Information that can be provided from the file’s metadata, or from data contained in the locally retained stub file, is available without triggering a retrieval from the back-end system. This enables many queries to be completed at local disk speed, even for large files which have been migrated and purged.

File system-based storage management 15

Introduction

Data managementFSM creates a transparent management layer on top of the native file system. The management layer uses a Data Management Application Programming Interface (DMAPI) to do the following:

◆ Interact with the file system

◆ Manage extended file attribute information

◆ Handle requests for migration, purging, and retrieval operations

FSM migrates data to one or more back-end systems and manages data protection, retention, and replication on those systems. To fulfill requests for purged data, FSM retrieves the data from the appropriate back-end system.


Introduction

Console-based administrationFSM provides a console-style administrative tool to perform most administrative tasks. The tool, the FSM Console, permits the administration of multiple UTDM file systems, UTDM file system hosts, and management domains. A management domain is a logical grouping of UTDM file system hosts controlled by the same FSM Console Server.

Console Client FSM Console Client can be run on any supported host to administer a management domain, as long as the supported host has TCP/IP access to the following management domain components:

◆ Console Server

◆ All UTDM file system hosts

Console Client can be run simultaneously on multiple hosts.

You can use Console Client to perform tasks in the following categories:

◆ Administration◆ Configuration◆ Extended Rules◆ Monitoring

Flexible topology 17

Introduction

Flexible topologyFSM can be set up with many different combinations of hosts, file systems, protocols, and back-end systems.

An FSM host is a computer where:

◆ Core processes are installed and running

◆ Console Agent is installed and running

◆ At least one UTDM file system is available

Minimum topology A minimal FSM installation involves the following:

◆ FSM host with Console Server installed and running

◆ One UTDM file system

◆ One back-end system

Complex topology A complex management domain might involve all of the following:

◆ One FSM host with Console Server installed and running

◆ Multiple FSM hosts, including all of the supported operating systems

◆ Multiple UTDM file systems on each FSM host, including all supported file system types

◆ Multiple back-end systems, including Centera systems, and locally accessible disk resources

◆ Additional Centera systems that act as replication servers

◆ Console Client administration from multiple hosts


Introduction

Topology guidelines Meet the following guidelines to successfully set up a management domain:

◆ Only one Console Server may run in the management domain

◆ All FSM hosts must have Console Agent installed and running

◆ All FSM hosts must have TCP/IP communication with the Console Server host system

◆ All Console Client hosts must have TCP/IP communication with the Console Server host and all FSM hosts

Console overview 19

2


◆ Console software................................................................................ 20◆ Management domain......................................................................... 22◆ Console Client .................................................................................... 24◆ Administration ................................................................................... 26◆ Monitoring .......................................................................................... 30

Console overview


Console overview

Console softwareThe Console software provides the interface to work with FSM hosts and UTDM file systems. An administrator can perform the following tasks by using the Console software:

◆ Configure new UTDM file systems.

◆ Edit the configuration of existing UTDM file systems.

◆ Delete the configuration information for existing UTDM file systems.

◆ Copy rule sets between UTDM file systems.

◆ Create and manage extended rules.

The Console software consists of the following applications:

◆ Console Server

◆ Console Agent

◆ Console Client

Console ServerConsole Server provides authentication services to a management domain. All FSM hosts in a management domain are controlled by the same Console Server.

Console Server must be installed on only one computer in a management domain and the computer must have TCP/IP access to all FSM hosts in its domain. Normally the computer on which it is installed also has Console Agent installed.

The computer on which Console Server is installed may also have Console Client installed.

Console AgentConsole Agent interacts with the processes and UTDM file systems on an FSM host. It acts as an intermediary between an FSM host and Console Client. It must be installed on each FSM host being managed.

Console software 21

Console overview

Console ClientConsole Client can be installed on any computer with TCP/IP access to the management domain. It provides an administrative interface to the management domain.

Console Client can be active on several computers simultaneously and should be installed on every computer that is used to administer file systems.

Console Client can run on a computer with or without Console Server and Console Agent.


Console overview

Management domainA management domain can exist entirely on a single computer or it can include multiple computers. A management domain consists of the following components:

◆ One Console Server

◆ At least one Console Client

◆ At least one FSM host

Each FSM host must have the following:

• One set of FSM core processes (core processes)

• One FSM Console Agent (Console Agent)

• At least one UTDM file system

A UTDM file system is one that is first formatted as a native file system and then initialized to create a DMAPI attributes file in its root directory. The installation guides provide more information about this.

Single computer domainThe following tasks must be completed to set up a management domain on a single computer:

1. Ensure the computer meets the installation requirements.

2. Install the core processes.

3. Install the Console Server.

4. Install a Console Agent.

5. Install the Console Client.

6. Prepare at least one UTDM file system.

7. Configure each UTDM file system.

Management domain 23

Console overview

Multiple computer domainA management domain can consist of many computers. All of the computers in the management domain must have TCP/IP communication with the following:

◆ Computer that is running Console Server

◆ Each computer that is running Console Client

A multiple computer management domain might consist of the following separate computers:

◆ Console Server running on a single FSM host computer

◆ Console Agent running on multiple FSM host computers

◆ Console Client running on several computers


Console overview

Console ClientConsole Client is an interface application for working with FSM hosts and UTDM file systems. An encrypted username and password combination (account) is used to authenticate Console Client users and determine permissions.

A default administrative account is provided with Console Client. This default account has the username system and the password system. To increase the security of the management domain, the password for this account should be changed right after the software is installed. “Changing a user's password” on page 28 provides information about how to do this.

You can install Console Client on several supported operating systems. The release notes provide a complete list of the operating systems supported by Console Client.

Starting Console ClientTo start Console Client:

◆ On UNIX and Linux hosts:

1. Allow X window connections:

xhost +

2. Set the DISPLAY environment variable:

setenv DISPLAY local_host:0.0

where local_host is the hostname of the local system or its IP address.

Depending on the configuration of the network, you can use the local system’s hostname or the IP address. The IP address can be either an IPv4 or IPv6 format IP address to match the protocol used by your network.

3. Run the Console Client application:

/opt/fsm/client/File_System_Manager_Console_Client &

where /opt/fsm is the full path to the FSM installation directory.

The Login to FSM Console window appears.

4. In Username, type a valid username.

5. In Password, type the password.

Console Client 25

Console overview

6. In FSM Server, type the hostname or IP address for the management domain’s Console Server.

You can use either an IPv4 or IPv6 format IP address to match the protocol used by your network.

7. Click OK.

The main Console Client window appears.

◆ On Windows:

1. Click:

Start > Programs > File System Manager Console Client > File System Manager Console Client

The Login to FSM Console window appears.

2. In Username, type a valid username.

3. In Password, type the password.

4. In FSM Server, type the hostname or IP address for the management domain’s Console Server.

You can use either an IPv4 or IPv6 format IP address to match the protocol used by your network.

5. Click OK.

The main Console Client window appears.

Security timeout Console Client is configured to close down the connection with Console Server after 20 minutes of inactivity. This security feature cannot be modified.

Online help The online help provides convenient descriptions of Console Client’s menus, shortcuts, windows, and wizards.

To access the online help from the main Console Client window, on the Help menu, click Contents and Index (or press F1).

To access the online help from a wizard, click the Help button (or press Alt+F1).


Console overview

AdministrationUse the Console Client Administration menu to manage all user accounts in a management domain. The specific management domain is determined by the name of the Console Server host entered during login.

Use the Administration menu to manage user accounts through the following commands:

◆ Manage User Accounts

◆ Change User Password

CAUTION!The Console Client application installs with a default account with the username and password as system. The role of the default account is Administrator.The account cannot be deleted. To maintain the security of the management domain, change the default password after the initial login. “Changing a user's password” on page 28 provides more information.

Adding a userTo add an user:

1. On the Administration menu, select Manage User Accounts.

2. In Username, type the new username.

A valid username is five to eight characters with at least one alphabetic character. A new username cannot match the following:

• Any other username in the management domain.

• The password of the currently logged-in user.

3. In Password, type the new password.

A valid password is five to eight characters with at least one alphabetic character. It cannot match the password of the current logged-in user.

4. In Confirm Password, retype the new password.

Administration 27

Console overview

The value in Confirm Password must match the value in Password.

5. In Role, select a role for the new user account.

Select either Operator or Administrator. Table 1 on page 27 provides the functions available for each role.

6. Click Add.

7. Click OK.

Note: Use Clear on the Manage User Accounts window to clear the following fields: Username, Password, and Confirm Password.

Table 1 Tasks permitted for operators and administrators

Task Operator Administrator

View all activities Yes Yes

View all events Yes Yes

Monitor file system Yes Yes

View file system configuration Yes Yes

View file system events Yes Yes

Change own password Yes Yes

View Help Yes Yes

View About Yes Yes

Manage user accounts No Yes

Create new file system configuration No Yes

Edit file system configuration No Yes

Commit changes No Yes

Delete file system configuration No Yes

Copy extended rule No Yes


Console overview

Removing a userTo remove a user account:


The Manage User Accounts window appears.

2. From the Username list, select the username of the account to be removed.

Note: The system account cannot be removed. Delete is not available when this account is selected.

3. Click Delete.

The Delete User prompt appears.

4. Click Yes.

The account is removed.

5. Click OK.

Changing your passwordTo change your password:

1. On the Administration menu, select Change User Password.

The Change Password window appears.

2. In Password, type your new password.

3. In Confirm Password, type the new password again.

4. Click OK.

Changing a user's passwordAn administrator may change a user's password:


The Manage User Accounts window appears.

2. From the Username list, select a username.

3. In Password, type the new password.

Administration 29

Console overview

4. In Confirm Password, type the new password.

5. Click Update.

6. Click OK.


Console overview

MonitoringTo view events, activities, and status in a management domain, use the monitoring windows.

The following regions may be monitored:

◆ Domain Events

◆ Domain Activities

◆ Host Events

◆ File System Events

◆ File System Activities

◆ File System State

Note: Events and state information for file systems on an FSM host are cleared when that FSM host is restarted. Restarting an FSM host also clears that host’s events from the Events for All Hosts window.

Clearing the events windowAn administrator can clear all events, or select events to clear from any of the Events windows.

All eventsTo clear all events, click Clear All Events.

All events clear, including events that are not displayed under the currently selected event type.

Select eventsTo clear a group of events:

1. In the Filter field, select an event type to display.

2. Select each event to be cleared.

3. Click Clear Checked Events.

Domain eventsThe events for all file systems in a management domain can be viewed. The displayed events, however, do not include the following:

Monitoring 31

Console overview

◆ Events that were cleared

◆ Events that occurred before the host computer was last restarted

Viewing domainevents

To display the events for a management domain:

1. On the View menu, select All Events.

The Events for All Hosts window appears.

2. (Optional) On the View menu, select Refresh to refresh the display.

The Last Refreshed value changes and the Events for All Hosts window updates.

3. (Optional) In the Filter field, select a severity level to display a subset of the events.

Select one of the severity levels:

• All

• None

• Low

• Medium

• High

• Extreme

The filtered events appear.

Table 2 on page 32 provides a description of the columns on the Events for All Hosts window.


Console overview

Domain activitiesThe activities for all file systems in a management domain can be viewed.

To display all activities in a management domain:

1. On the View menu, select All Activities.

The All FSM Activities window appears at the top of the workspace pane.

2. In the Filter field, select the type of activities to display.

Table 2 Columns on the Events for All Hosts window

Column Description

Host Name of the host on which the event occurred.

File System Name of the file system that generated the event.

Severity Severity level of the event.Severity is one of the following: • None• Low • Medium • High• Extreme

Timestamp Date and time that the event occurred.

Event Type Type of event.Event type is one of the following:• Debug• Info• Notice• Warning• Error• Critical• Alert• Emergency

Message Description of the event.

Monitoring 33

Console overview

The activities are filtered to show only the type of activities selected.

The following activities types may be selected:

• All

• Purge

• Migrate

• Staging

• Destroy

• Recover

The filtered domain activities appear.

Table 3 on page 33 provides a description of the columns on the All FSM Activities window.

Table 3 Columns on the All FSM Activities window

Column Description

Host Name of the host for the activity

File System Name of the file system for the activity

File System ID File system ID for the activity

Backend Level Priority of the back-end systemEither Level 1 (primary) or Level 2 (secondary).

Backend Type Back-end module typeOne of the following:• Centera• FTP• NFS

Activity Type Activity typeOne of the following: • Purge • Migrate • Stage • Destroy • Recover

Filename Name of the file that is the subject of the activity


Console overview

Host eventsThe events for an individual host can be viewed. The displayed events do not include the following:



Viewing events for ahost

To display all events for a host:

1. On the tree pane, select the host.

2. On the View menu, select Events.

The Events window appears.


The Last Refreshed value changes and the Events window updates.


The events are filtered to show only the selected severity level.

Select one of the following severity levels:

• All

• None

• Low

• Medium

• High

• Extreme

The filtered events appear.

Bytes to Move Target amount of data (in bytes) to be moved by the activity

Bytes Moved Current amount of data (in bytes) that was moved by the activity

Progress Graphical progress bar

Table 3 Columns on the All FSM Activities window (continued)

Column Description

Monitoring 35

Console overview

Table 4 on page 35 provides a description of the columns on the Events window.

File system eventsThe events for an individual file system can be viewed. The displayed events do not include the following:



Viewing events for afile system

To display all events for a file system:

1. On the tree pane, select the file system.

Table 4 Columns on the Events windows

Column Description

Host Name of the host

File System Name of the file system that generated the event

Severity Severity level of the eventSeverity is one of the following: • None• Low • Medium • High• Extreme

Timestamp Date and time that the event occurred

Event Type Type of eventEvent type is one of the following:• Debug• Info• Notice• Warning• Error• Critical• Alert• Emergency

Message Description of the event


Console overview

2. On the View menu, select Events.

The Events window appears at the top of the workspace pane.


The Last Refreshed value changes and the Events window updates.


The events are filtered to show only the severity level selected.

Select one of the following severity levels:

• All

• None

• Low

• Medium

• High

• Extreme

The filtered events appear. Table 5 on page 36 provides a description of the columns on the Events window.

Table 5 Columns on the Events windows (page 1 of 2)

Column Description

Host Name of the host

File System Name of the file system that generated the event

Severity Severity level of the eventSeverity is one of the following: • None• Low • Medium • High• Extreme

Monitoring 37

Console overview

File system activitiesYou can use Console Client to view the activities for a file system.

To display all activities for a file system:


2. On the View menu, select Monitoring.

The Activities window appears at the bottom of the workspace pane.

3. In the Filter field, select the type of activities to display.

The activities are filtered to show only the type of activities selected.

Select one of the following activity types:

• All

• Purge

• Migrate

• Staging

• Destroy

• Recover

Timestamp Date and time that the event occurred

Event Type Type of eventEvent type is one of the following:• Debug• Info• Notice• Warning• Error• Critical• Alert• Emergency

Message Description of the event

Table 5 Columns on the Events windows (page 2 of 2)

Column Description


Console overview

The filtered activities appear. Table 6 on page 38 provides a description of the columns on the Activities window.

File system stateUse Console Client to view information about the state of a managed file system.

To display the state of a file system:


2. On the View menu, select Monitoring.

The File System State window appears at the top of the workspace pane. General state information appears on the left side of the window. Table 7 on page 39 provides a description of the available information.

Table 6 Columns on the Activities window

Column Description

Activity Type Type of activityType is one of the following: • Purge • Migrate • Stage • Destroy • Recover

Backend Level Priority of the back-end systemEither Level 1 (primary) or Level 2 (secondary)

Backend Type Back-end module typeOne of the following:• Centera• FTP• NFS

Filename Name of the file that is the subject of the activity

Bytes to Move Target amount of data (in bytes) to be moved by the activity

Bytes Moved Current amount of data (in bytes) moved by the activity

Progress Graphical progress bar

Monitoring 39

Console overview

3. (Optional) From the View menu, select Refresh to refresh the display.

The Last Refreshed value changes, and the File System State window and the Activities window update.

4. On the File System State window, click a tab to display information for a specific activity type.

The following tabs are available:

• Purge, described in Table 8 on page 40.

• Migrate, described in Table 9 on page 40.

• Staging, described in Table 10 on page 40.

• Destroy, described in Table 11 on page 41.

• Recover, described in Table 12 on page 41.

Table 7 File System State window

Field name Description

File System Name Name of the file system

File System ID File system ID

Module Module type for the file system

File System Path Full path to the mount point for the file system

Total Size Total size of the file system

Used Space Number of megabytes of data in the file system

High Watermark Value set for the file system's high-water mark

Used Space (graphical display)

Graphical display showing the percentage of file system space used

Maximum Inodes Total number of inodes allowed in the file system

Used Inodes Total number of file system inodes used

Used Inodes (graphical display)

Graphical display showing the percentage of file system inodes used


Console overview

Table 8 Purge tab on the File System State window

Field Description

Purge Attempts Number of attempts to purge files from the file system

Purge Errors Number of errors during all of the file system's purge attempts

Purge Attempts on Purged Files

Number of purge attempts on previously purged files

Bytes Purged Since Last Reboot

Total bytes purged

Table 9 Migrate tab on the File System State window

Field Description

Migration Attempts

Number of attempts to migrate files from the file system

Migration Errors Number of errors during all of the file system's migration attempts

Migration Attempts on Migrated Files

Number of migration attempts on previously migrated files

Bytes Migrated Since Last Reboot

Total bytes migrated

Table 10 Staging tab on the File System State window

Field Description

Staging Attempts Number of attempts to stage files into the file system

Staging Errors Number of errors during all of the file system's staging attempts

Staging Attempts on Staged Files

Number of staging attempts on previously staged files

Bytes Staged Since Last Reboot

Total bytes staged

Monitoring 41

Console overview

Table 11 Destroy tab on the File System State window

Field Description

Files Destroyed Total number of files reclassified on the back-end system as destroyed, after being deleted from the file system.

Files Not Renamed

Total number of files that could not be renamed on the back-end system.“Periodic back-end system cleanup” on page 175 provides more information about renaming deleted files on the back-end system.

Table 12 Recover tab on the File System State window

Field Description

Recovery Attempts

Number of attempts to recover file data from the back-end system, after a recovery from backup is completed in the file system

Recovery Errors Number of errors during file data recovery attempts


Console overview

File System Configuration 43

3


◆ Preliminary tasks................................................................................ 44◆ Configuring a file system.................................................................. 57◆ Viewing a file system configuration................................................ 70◆ Editing a file system configuration ................................................. 71◆ Deleting a file system configuration ............................................... 72

File SystemConfiguration


File System Configuration

Preliminary tasksA UTDM file system configuration is a set of attributes that define how the UTDM file system is managed. Each file system has its own set of required and optional attributes.

Console Client simplifies file system configuration tasks by displaying all relevant attributes, checking all entered values, and applying configuration changes to the file system.

Before you can configure a file system, you must complete the following tasks:

◆ Create a native file system, initialize the file system for UTDM, and mount the file system on an FSM host.

These tasks are described in the installation guides.

◆ Decide on a Level 1 back-end type and, optionally, a Level 2 back-end type to use with the file system.

◆ Perform any preliminary setup steps required for each selected back-end system.

Back-end module typesYou must designate either one or two back-end systems for a file system. When two back-end systems are selected, migrated file data is written to both. Data is retrieved from the Level 1 (primary) back-end system unless it is unavailable. If the Level 1 back-end system is unavailable, then data is retrieved from the Level 2 (secondary) back-end system.

The steps required to configure a file system differ slightly based on which back-end type is selected as primary and, optionally, which is selected as secondary.

For both primary and secondary, an administrator may choose from the back-end module types shown in Table 13 on page 45.

Preliminary tasks 45


A mixture of back-end module types can be used for a file system, for the file systems on a host, and for all file systems in a management domain.

Each back-end module type has preliminary tasks that must be completed before you configure a file system to use it. Those tasks are described in the following sections:

◆ “Preliminary tasks for Centera module” on page 45

◆ “Preliminary tasks for FTP module” on page 52

◆ “Preliminary tasks for NFS module” on page 54

Preliminary tasks for Centera moduleComplete the following tasks to use the Centera module:

◆ Ensure that the FSM host can establish a connection with the Centera system’s interface addresses. If replication is used, also confirm that there is a connection with the replication server’s interface addresses.

◆ Create a Centera system pool to use with FSM file systems.

◆ Configure the Centera system to grant appropriate permissions to FSM. If replication is used, also configure the replication server.

◆ If Pool Entry Authorization (PEA) is used, create and install a valid PEA file on the FSM host. If replication is used, create a PEA file that authenticates FSM with both the primary Centera system and the replication server.

◆ Enable Centera system data retention.

Table 13 Available back-end module types

Back-end module types Description

Centera Centera system

FTP Standards-compliant FTP or FTPS servera

NFS Standards-compliant NFS accessible disk resources

a. In order to facilitate recovery on an FTP or FTPS server, the server must be capable of providing FSM with local disk-like access to the back-end data. This may be provided by using NFS or any other protocol that provides FSM with such access. ““Recovery with FSM tools” on page 151” on page 129 describes the recovery procedure in this configuration.



Check connectivity FSM uses TCP/IP to communicate with Centera systems. Before configuring a UTDM file system to use a Centera system, and optionally a Centera system replication server, confirm that there is a connection between the FSM host and the IP addresses of the Centera systems.

Centera systems do not respond to ping packets. The dxuldmcenteraping tool is provided with the FSM to confirm that there is a connection with a Centera system.

Release 3.5 SP1 introduces a change in the strategy when contacting the primary and secondary Centera system. FSM now uses uses LAZY_OPEN strategy to open a pool connection with Centera. Earlier releases of FSM were using NORMAL_OPEN strategy to connect to Centera. The NORMAL_OPEN strategy tries to open a pool connection with all primary, secondary, and replica Centera system before establishing the connection. In contrast, the LAZY_OPEN strategy opens pool connection only with primary Centera system and connects to secondary or replica Cenetera system only when required.

To confirm connectivity:

1. Log in as root to the FSM host system.

2. Set the FSM environment.

“Setting the FSM environment” on page 185 provides information on setting the FSM environment.

3. For each Centera system IP address, run the dxuldmcenteraping command:

dxuldmcenteraping -a emc-address [emc-address...]

where emc-address is an IP address for a network interface on the Centera system, in IPv4 format. Additional IP addresses, separated by spaces, may be specified.

“dxuldmcenteraping” on page 191 provides more information about the command.

Failure to connect to the IP addresses for a Centera system indicates a network problem that should be corrected before the file system is configured.

Create a Centerasystem pool for FSM

FSM file systems can use the default Centera system pool but it is recommended that you create a pool that is used only by FSM file systems. An FSM-only pool simplifies Centera system to Centera



system migrations, such as when you move the back-end data to a newer generation Centera system.

Configure Centerasystem permissions

FSM requires read, write, and query permissions on a Centera system. This set of permissions can be provided in one of the following ways:

◆ Configure the Centera system’s Anonymous profile to grant these permissions.

Use of the Anonymous profile eliminates the PEA file requirement. However, the Anonymous profile constitutes a potential security hazard because it does not authenticate applications during the PEA process. It should be disabled.

◆ Use the PEA process to create an application profile for FSM that grants the necessary permissions.

“Create and install a PEA file” on page 47 provide more information on setting the permissions.

Create and install aPEA file

The PEA process is used by a Centera system to grant access rights to applications. The specific access rights that are granted are determined by application profiles created on the Centera system.

The application profile that is used by FSM must have the following access rights:

◆ Read (r)

◆ Write (w)

◆ Exist (e)

In order to be authorized to use an application profile, FSM must provide the Centera system with the profile’s name and key. FSM reads the information from a PEA file located on the FSM host and passes it to the Centera system during the PEA process.

To create and install a PEA file:

1. On the Centera system, create an application profile that grants Read, Write, and Exist rights.

Application profiles are created by using the Centera system’s CLI commands profile create or profile update.

In order to have the profile create or profile update commands output a PEA file, type yes when asked if a Pool Entry Authorization should be created.



The Centera system's documentation provides more information about application profile creation.

2. Copy the resultant PEA file from the CLI host to the FSM host.

3. As root, limit access to the PEA file:

chmod 600 /path/my.pea

where /path/my.pea is the full path of the PEA file.

4. For each file system that uses the Centera module, type the full path of the PEA file in the Authentication Path option.

“Centera module” on page 64 provides information on the Authentication Path options.

Verify PEA accessTo verify that a PEA file can be used to access a Centera system:

1. Log in as root on the host system.


“Setting the FSM environment” on page 185 provides information on setting the FSM environment.

3. Run dxuldmcenteraping:

dxuldmcenteraping -a centeraIP?pathtopea

where:

• centeraIP is one of the IP addresses on the Centera system, in IPv4 format.

• pathtopea is the full path to the PEA file.

Note: This command verifies that the PEA file may be used to access the Centera system. It does not check whether correct permissions are provided by the PEA file.

“dxuldmcenteraping” on page 191 provides more information about dxuldmcenteraping.

Centera pool entry authorization for replicationThe PEA process may be used with Centera replication as a way to authenticate FSM on both the primary and replication Centera systems.

The PEA file used in a replication environment must provide authentication information for each of the Centera systems.



The composition of a PEA file used in a replication environment depends on whether you provide the path to a random-bit file when you run the profile create or profile update commands. The random-bit file can be used as additional input during key generation.

The following methods may be used:

◆ Generate the key by providing a random-bit file.

The same file must be used on each Centera system. This method creates a PEA file with a single key that is accepted on each Centera system.

◆ Generate the key without providing a random-bit file.

A different key is created on each Centera system based on various machine-based values. Each key must be copied into the PEA file. This creates a PEA file with several keys, one for each Centera system.

Replication PEA file created with a random-bit file

To use a replication PEA file created with a random-bit file:

1. On the primary Centera system, create an application profile by using a random-bit file.

The application profile must grant Read, Write, and Exist rights. In order to have the profile create or profile update commands output a PEA file, type yes when asked if a Pool Entry Authorization should be created.

The Centera system's documentation provides more information about application profile creation.

2. On each replication system, create an application profile by using the same random-bit file.

The application profile on each replication system should use the same name as the one on the primary system. The profile should, at a minimum, grant Read and Exist rights.

3. Copy the PEA file created with the primary system from the CLI host to the FSM host.







“Configuring a file system” on page 57 provides information on configuring a file system.

6. For each file system that uses the Centera module, type the IP address, in IPv4 format, for each available interface on each replication server in the Replication Server Addresses option.

“Configuring a file system” on page 57 provides information on configuring a file system.

7. Verify access by using the PEA file.

“Verify PEA access” on page 48 describes how to verify access.

Replication PEA file created without the use of a random-bit file

To use a replication PEA file created without the use of a random-bit file:

1. On the primary Centera system, create an application profile without using a random-bit file.

The application profile must grant Read, Write, and Exist rights. In order to have the profile create or profile update commands output a PEA file, type yes when asked if a Pool Entry Authorization should be created.

The Centera system’s documentation provides more information about application profile creation.

2. On each replication system, create an application profile without using a random-bit file.

The application profile on each replication system should use the same name as the one on the primary system. The profile should, at a minimum, grant Read and Exist rights.

3. Copy the key portion of the PEA file created with each replication system into the PEA file created with the primary system, as shown in Example 1 on page 50.

Example 1 Replication environment PEA file created without a random-bit file

The primary Centera system PEA file without the key from a replication server looks like this:

<pea version="1.0.0"><defaultkey name="FSM1">



<credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential></defaultkey><key type="cluster" id="74cf2446-1dd2-11b2-bee7-9e82e41faa5c" name="FSM1"><credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential></key></pea>

The primary Centera system PEA file after adding the key from a replication server looks like this (added key is in bold font):

<pea version="1.0.0"><defaultkey name="FSM1"><credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential></defaultkey><key type="cluster" id="74cf2446-1dd2-11b2-bee7-9e82e41faa5c" name="FSM1"><credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential></key><key type="cluster" id="d76d509c-1dd1-11b2-b10d-bd6b5ed0b4e6" name="FSM1"><credential id="csp1.secret" enc="base64 ">YqgqywOqJ9nsKC7uQFeztUyFcM</credential></key></pea>

4. Copy the resulting PEA file from the CLI host to the FSM host.





“Configuring a file system” on page 57 describes how to configure a file system.

7. For each file system that uses the Centera module, type the IP address in IPv4 format for each available interface on each replication server in the Replication Server Addresses option.

“Configuring a file system” on page 57 describes how to configure a file system.

8. Verify access by using the PEA file.



“Verify PEA access” on page 48 describes how to verify the access.

Enable Centerasystem data retention

Retention of data from a UTDM file system that is migrated to a Centera system is enabled by using the Retention Period or the Retention Class settings. However, unless Centera system data retention is enabled for the file system, these retention settings do not protect data in the file system.

To provide retention both on the back-end system and in the file system, mount the file system with the bckendreten mount option. “Centera system data retention” on page 110 provides information on enabling Centera system data retention.

Preliminary tasks for FTP moduleComplete the following tasks to use the FTP module:

1. Ensure that the FSM host can establish a connection to the back-end server:

• FTP server (FTP Protocol set to Native FTP)

• FTPS server (FTP Protocol set to Native FTP)

2. Create a username and password combination on the back-end server for the file system.

3. Obtain the full path to the target directory.

4. Ensure that the file system host can obtain local disk-like access to the back-end server.

Check connectivity Connectivity between the FSM host and the back-end server can be confirmed by using the ping command. Use the ping command with the same interface address or hostname that you will use in FTP Host.

To confirm connectivity:

1. Log in as root on the FSM host system.

2. Run ping:

ping backendIPwhere backendIP is the value to be used in FTP Host. This is normally the IP address of the back-end server, in either IPv4 or IPv6 format as dictated by the network. Alternatively, if the back-end server’s hostname is to be used, replace backendIP with the hostname in the above command.



Failure to connect to the IP address indicates a network problem that should be corrected before the file system is configured. Failure to connect to the hostname usually indicates a name service problem.

FTP username andpassword

FSM authenticates itself with the back-end server by using a username and password. This combination of values must be created on the back-end server before it can be used by a UTDM file system. Documentation for other FTP/FTPS servers provides information on creating FTP usernames and passwords.

A single username and password combination can be used by all UTDM file systems, or individual combinations can be used by each FSM host or each UTDM file system.

Target path Before configuring a file system, determine the full path of the directory on the back-end server that is to be the top-level migration target. Type this path as the Target Path value for the file system. “FTP module” on page 67 describes the target path value.

The path is in UNIX format and is relative to the root of the FTP server.

Another commonly used target path naming convention is /FSM/file_system, where:

◆ / is the root of the FTP directory structure on the FTP server.

◆ file_system is the name of the file system.

Choose anauthentication type

Choose either a standard FTP connection or a secure FTP connection for native FTP servers.

IMPORTANT!The FTP module supports only active mode. When deciding on an authentication type, be aware that using an encrypted control channel can prevent a firewall from opening a port for the data channel.



Table 14 on page 54 provides information about the authentication type choices.

To successfully use either TLS or SSL, the back-end server must provide a public key certificate.

Local disk-like access Local disk-like access is normally established by using the NFS protocol but other protocols are allowed, as long as the directory specified in the target path can be mounted locally by the FSM host.

Preliminary tasks for NFS moduleComplete the following tasks to use the NFS module:

◆ Determine the mount point of the back-end system.

◆ Create an NFS check directory on the back-end system.

Back-end mount point The module can be used with a disk resource that acts as a back-end system, such as any of the following:

◆ Local secondary disk

◆ Network-attached storage (NAS) disk

◆ Storage area network (SAN) disk

When the NFS module is used, determine the full path to the local mount point of the back-end system. Type this path as the Target Path value for the file system. “NFS module” on page 68 provides information on configuring a file system’s Target Path value.

The instructions provided with the hardware describe how to mount a disk resource as a back-end system.

After the back-end system is mounted, the mount point can easily be determined by using mount.

To determine the mount point:

Table 14 Choices for the Authentication Type field

Authentication typeControl channel encrypted Data channel encrypted Cryptographic protocol

None No No None

TLS Yes No Transport layer security

SSL Yes No Secure socket layers




2. On the command line, type mount without any options:

mountAll mounted file systems are listed, with their mount point.

Determining back-end mount point when using Solaris zonesFor Solaris zones, the expression of the full path to the mount point of the back-end system depends upon the zone in which FSM is installed and the zone in which the back-end system is mounted. Table 15 on page 55 describes how to determine the full path when using Solaris zones.

Create an NFS check directoryThe NFS check directory is an empty subdirectory at the top level of the back-end mount point. The NFS check directory must be named UTDMNFS. The name is case-sensitive. It must be typed in uppercase. No specific permissions are required for the check directory.

FSM uses the NFS check directory to ensure that the exported directory is correctly mounted on the FSM host. The NFS check directory can be seen by FSM only when the exported directory is properly mounted on the FSM host. FSM will not migrate files until it sees the NFS check directory.

Note: Although a disk resource back-end system may not use the NFS protocol, the core processes will not migrate data unless the NFS check directory is found at the top level of the mount point.

To create an NFS check directory:


Table 15 Determining path of back-end mount point when using Solaris zones

Configuration Path

• FSM installed in global zone• Back-end system is mounted in

global zone

Use the global zone full path of the mount point.

• FSM installed in local zone• Back-end system is mounted in same

local zone

Use local representation of the local mount point.Example: When the local zone is mounted at /export/zone01 and the back-end system’s local mount point is /mnt/backend01, then the full path to the mount point is /mnt/backend01.



2. To ensure the back-end system is mounted, type mount without any options:

mount

If the back-end system is not listed as one of the mounted file systems, then, for a disk resource back-end system, mount the resource as described in the instructions provided with the hardware.

3. Change the current working directory to the top level of the back-end system.

4. Create the NFS check directory:

mkdir UTDMNFS

Configuring a file system 57


Configuring a file systemConfiguring a file system is the final step in the process of preparing to manage a UTDM file system.

With this release you can configure a Level 1 and a Level 2 back-end system. When you configure both, migrated data is written to both.

The Level 1 back-end system is the file system’s primary back-end system. Data is always retrieved from the Level 1 back-end system unless that back-end system is unavailable to the file system. If the Level 1 back-end system is unavailable, then data is retrieved from the Level 2 back-end system.

When you configure two back-end systems for a file system, you can select from any of the module types for each. Normally you should configure the back-end type that stages data fastest as the Level 1 back-end system.

Overriding configuration for file system subsetsWhen you configure a file system, you create settings that tell FSM how to manage the files in that file system. You can override the settings for subsets of the files by using extended rules. Chapter 4, “Extended Rules,” provides information about:

◆ Defining a file system subset

◆ Creating an extended rule

◆ Working with extended rules

Configure a file systemTo configuring a file system:

1. Create, initialize, and mount a UTDM file system.

The installation guides describe the procedures.

2. Start Console Client and log in to the management domain that controls the file system’s FSM host.

“Starting Console Client” on page 24 describes how to start Console Client and how to log in to a management domain.

3. On the tree pane, select the file system’s host computer.



4. Select File > New > File System Configuration.

5. Select the Level 1 (primary) back-end type from the following choices: Centera, FTP, or NFS.

6. (Optional) Check the Level 2 box.

7. (Optional) Select the Level 2 (secondary) back-end type.

8. Click OK.

9. In File System Name, type a reference name for the file system.

The name may be any combination of ASCII characters, from 1 to 64 characters in length. The name cannot match the name of any other file system on the host.

10. In File System Path, type the path for the UTDM file system.

Use the full path to the UTDM file system's mount point.

For Solaris zones the expression of a file system’s full path depends upon the zone in which FSM is installed and the zone of the file system. Table 16 on page 58 describes how to determine the full path when using Solaris zones.

Table 16 Determining full path when using Solaris zones

Configuration Path

• FSM installed in global zone• File system installed in global zone

Use the global zone full path of the file system.

• FSM installed in global zone• File system installed in local zone

Use global representation of the local file system's path.Example: When the local zone is mounted at /export/zone01 and the file system's local path is /mnt/filesystem01, then the path required is /export/zone01/mnt/filesystem01.

• FSM installed in local zone• File system installed in same local

zone

Use local representation of the file system's path.Example: When the local zone is mounted at /export/zone01 and the file system's local path is /mnt/filesystem01, then the path required is /mnt/filesystem01.



11. In Checksum, select a checksum setting as described in Table 17 on page 59.

When the value of Checksum is changed to either Checksum During Migration or Checksum During Migration and Staging, a checksum is not calculated for files that were migrated while the value of Checksum was No Checksumming. Checksums are calculated only for files that are migrated after the change.

Note: Checksumming is disabled for back-end systems that use the Centera module and have Enable Multiple Streams Per File Stage option selected.

12. Click Next.

13. (Optional) In Delay Until Purge Candidacy, set the number of minutes after a migrated file is last accessed before it can be purged.

The range is 1 to 2,147,483,647 minutes. The default is 10 minutes.

14. (Optional) In Minimum File Size to Purge, set the minimum size a file must be before it can be purged.

The range is 0 to 2,147,483,647 bytes (2 GB). The default is 0.

15. (Optional) In Sleep Interval Until Next Purge, set the number of minutes, after a system-initiated purge run completes, before the file system is again checked for files that can be purged.

Table 17 Checksum setting choices

Choice Description

No checksumming Checksums will not be generated.Use this setting to decrease the CPU requirements caused by data movement. This is the default setting because of its lower CPU requirements.

Checksum during migration Checksum is generated for each file as it is migrated.This is the recommended setting. It creates a checksum for each migrated file without the additional CPU impact caused by creating a checksum during staging.

Checksum during migration and staging Checksum is generated for each file as it is migrated. The checksum is regenerated and compared to the original as the file is staged.Use this setting if increased CPU impact is not an issue, if file integrity is critical, or to troubleshoot migration and staging problems.This setting is overridden by the staging setting of Partial Read Size. When that setting is enabled, a checksum is calculated only during migration.



The range is 1 to 5,256,000 minutes. The default is 10 minutes.

Note: When the sleep interval elapses, the file system is checked against its high-water mark. If the high-water mark is met or exceeded, a purge eligibility check is conducted.

16. (Optional) In Concurrent Files Purged, set the number of purge threads that can be started.

The range is 1 to 128 files. The default is 1.

Note: When the maximum number of threads is reached, files are queued until a thread becomes free.

17. (Optional) In File Stub Size, set the number of kilobytes of a file that are left in the file system when the file is purged.

The range is 0 to 131,072 KB (128 MB). The default is 0.

Note: The data is measured in kilobytes from the head of the file.

18. (Optional) In High Watermark, set the percent of file system capacity that is reached before automatic purging is started.

The range is 1 to 100 percent, but must be higher than the value of low-water mark. The default is 90 percent.

19. (Optional) In Low Watermark, set the percent of file system capacity that is reached before automatic purging is stopped.

The range is 1 to 100 percent, and must be less than the high-water mark. The default is 80 percent.

20. In the File Time Purge Policy section, select either Purge on Last Modification Time or Purge on Last Access Time.

The File Time Purge Policy setting determines the starting point for the Delay Until Purge Candidacy period:

• Purge on Last Modification Time starts the period after the last modification of a file.

• Purge on Last Access Time starts the period after the last time the file was accessed.

21. Click Next.



22. (Optional) In Delay Until Migrate Candidacy, set the number of minutes after a file is last modified before it can be migrated.


23. (Optional) In Minimum File Size to Migrate, set the minimum number of bytes that a file must be before it can be migrated.

The range is 0 to 2,147,483,647 bytes (2 GB). The default is 0.

24. (Optional) In Sleep Interval Until Next Migration, set the number of minutes after a system-initiated migration run completes before the file system is again checked for files to migrate.

The range is 1 to 5,256,000 minutes. The default is 30 minutes.

25. (Optional) In Concurrent Files Migrated, set the number of migration threads that can be started.



26. (Optional) Set Purge After Migrate:

• Click Select to enable immediate purging of migrated files.

• Click Clear to enable purging only after the number of minutes are set in Delay Until Purge Candidacy.

27. (Optional) Select Enable Data Compression and set a data compression level.

When you enable this setting, the file system data is compressed before it is migrated.

The compression level range is 0 to 9. Level 1 gives the fastest throughput, level 9 gives the greatest compression, and level 0 gives no compression at all (the input data is simply copied a block at a time).

Level 6 represents a good compromise between speed and compression.

The higher the compression you set the more the file system host's CPU will be utilized.



Note: Selecting Enable Data Compression prevents the use of the staging settings: Partial Read Size and Full File Staging.

28. In the File Time Migration Policy section, select either Migrate on Last Modification Time or Migrate on Last Access Time.

This setting determines the starting point for the Delay Until Migrate Candidacy period:

• Migrate on Last Modification Time starts the period after the last modification of a file.

• Migrate on Last Access Time starts the period after the last time the file was accessed.

29. Click Next.

30. (Optional) Clear Full File Staging, to set a partial read size.

The default is full file staging, which means that all data for a file are returned to the file system when the file is staged.

Full File Staging is disabled if Enable Data Compression is selected in the migration settings.

31. (Optional) In Partial Read Size, set the size in megabytes of file data chunks to return to the file system when a file is staged.

Partial Read Size is disabled if Enable Data Compression is selected in the migration settings, or if Full File Staging is selected on the staging settings.

The Checksum during Migration and Staging setting is overridden when Partial Read Size is enabled. A checksum is calculated only on files when they are migrated because partial staging prevents checksum calculations during staging.

The range is 1 to 2048 MB (2 GB). The range of data staged spans the offset of the data requested.

Data is retrieved in chunks from the highest partial read size boundary immediately before the requested data to the lowest partial read size boundary immediately after the requested data. Example 2 on page 63 provides further information.



Example 2 Partial read size

A file is 1,073,741,824 bytes (1 GB). The file system’s Partial Read Size is set to 2,097,152 bytes (2 MB). The data requested is 4 MB in size and is located at offset 104,857,601 bytes (1 byte past the 100 MB block boundary).

The data staged is the data from offset 104,857,600 bytes (100 MB is the highest "partial read size boundary" immediately before the requested data) to 111,149,056 bytes (106 MB is the lowest "partial read size boundary" immediately after the requested data).

Note: Partial Read Size does not apply when the FTP module is used with the Native FTP protocol.

32. (Optional) In Concurrent Files Staged, set the number of staging threads that can be started.



33. Click Next.

34. (Optional) In Concurrent Files Destroyed, set the number of threads that can be started to flag back-end data as deleted, for files that have been deleted from the file system.

Deletion flags are described in “Periodic back-end system cleanup” on page 175.



35. Click Next.

36. Complete the module-specific configuration for the selected Level 1 back-end system.



Procedures for module-specific configurations are explained in the following sections:

• “Centera module” on page 64

• “FTP module” on page 67

• “NFS module” on page 68

Centera moduleTo complete the Centera module portion of a configuration:

1. In Connect Addresses, type the IP address or hostname of each available network interface on the Centera system.

Use the standard IPv4 "dotted quad" format for each IP address (nnn.nnn.nnn.nnn) and separate each address by using a comma without a space.

2. (Optional) In Retention Period, select Do Not Set, None, Default, Infinite, or Days as described in Table 18 on page 64.

If valid retention classes exist on the Centera system, Retention Period should be left at its default value, and Retention Class should be used to specify an appropriate retention class for the file system.

3. (Optional) In Retention Class, type the name of a valid Centera system retention class.

Table 18 Retention Period settings

Setting Description

Do not set Deleted data is retained for the period specified by the Centera system. This is the default and has the same result as selecting Default.

None Deleted data is immediately available for purging from the Centera system.

Default Deleted data is retained for the period specified by the Centera system.

Infinite Deleted data is never available for purging from the Centera system.

Days Deleted data is not available for purging from the Centera system until after the specified number of days.If you select Days, then set the number of days. The range is 1 to 36,500 days.



If valid retention classes exist on the Centera system, you can use Retention Class to enable retention of the file system’s data on the Centera system. This setting overrides the value of Retention Period.

4. (Optional) In Replication Server Addresses, type the IP address of each of the replication server's available network interfaces.

Use the standard, IPv4 "dotted quad" format for each IP address (nnn.nnn.nnn.nnn) and separate each address by using a comma without a space.

5. (Optional) In Centera Profile Path, type the full local path to the PEA file.

“Create and install a PEA file” on page 47 provides more information about PEA files.

6. (Optional) In Buffer Size, clear Use Default and type a buffer size.

The range is 1 to 10,240 KB (10 MB). The default value is 1 KB.

Note: Buffer Size is the amount of memory allocated by the Centera system for temporary storage of data that requires further processing.

7. (Optional) In Timeout, clear Use Default and type the number of seconds before a file system operation times out.

The range is 10 to 600 seconds (10 minutes). The default value is 10 seconds.

Note: Timeout is the number of seconds the Centera system waits for an operation to finish before a timeout failure occurs.

8. (Optional) In Retry Count, clear Use Default and type a limit on the number of retries.

The range is 0 to 99 retries. The default is the retry count set by the Centera system administrator.

Note: Retry Count is the number of times to retry unsuccessful Centera system operations.

9. (Optional) In Retry Sleep, clear Use Default and type the number of seconds between retries.



The range is 0 to 100 seconds.

Note: Retry Sleep is the number of seconds that the Centera system waits before retrying an unsuccessful operation.

10. (Optional) In Embedded Data Size, clear Use Default and type the size of data that may be embedded in an EMC C-Clip™.

The range is 0 to 65536 bytes (64 KB). The default is the size set by the Centera system administrator.

Note: Embedded Data Size is the limit on the size of data BLOBs that are embedded in the Centera system C-Clip. Data BLOBs over the limit are referenced in the C-Clip, but stored elsewhere.

11. (Optional) In Prefetch Size, clear Use Default and type the size of memory on the Centera system to allocate for data transfers.

The range is 1 to 1024 KB (1 MB).

12. (Optional) In Collision Avoidance, set how the Centera system should handle identical data BLOBs, as described in Table 19 on page 66.

13. (Optional) Select Enable Multiple Streams Per File Stage, and set Streams Per File and Minimum Stream File Size.

When Enable Multiple Streams Per File Stage is selected it allows multiple threads to be started for each staging request. This can enhance staging performance from a Centera system. Checksumming is fully disabled when this setting is selected.

Set the number of threads in Streams Per File. The range is 1 to 32, however in this release no significant improvement has been shown for settings above 8.

Table 19 Descriptions of Collision Avoidance settings

Setting Description

Default Identical data BLOBs are handled according to the Centera system default setting.

On Identical data BLOBs are handled separately, with unique ID numbers.

Off Identical data BLOBs are handled as a single BLOB, with one ID number.



Set the minimum file size for which multiple threads are used in Minimum Stream File Size. Files that are less than this size will be staged using only one thread. The minimum size for this setting is 100 MB. The default value is 1024 MB.

Note: Enable Multiple Streams Per File Stage is disabled for Centera system back-end systems that have Partial Read Size enabled, and when the file system has been mounted with the readthru option (direct-read capability).

14. Click Next.

15. (Optional) If you selected a Level 2 back-end system, complete the module-specific configuration related to it.

Procedures for additional module-specific configurations are explained in the following sections:



16. On the Finish and Commit panel, click Finish.

The configuration is validated, saved, and committed. The file system is ready to use and extended rules may be created.

FTP moduleTo complete the FTP module portion of a configuration:

1. In Target Path, type the full path of the target directory on the back-end system.

“Target path” on page 53 provides more information about the target directory.

2. In FTP Host, type the hostname or IP address of the back-end FTP server.

The hostname must be 64 characters or less. The IP address can be in either IPv4 or IPv6 format to match the protocol used by your network.

3. In FTP User ID, type the user ID to log in to the back-end FTP server.

The user ID must be 64 characters or less.



4. In FTP Password, type the password to log in to the back-end FTP server.

The password must be unencrypted, and must be 64 characters or less.

5. (Optional) In FTP Port, type the port that the back-end FTP server listens on.

The range is 1 to 65000. The default is port 21, the standard FTP and FTPS port.

6. (Optional) In Local Host IP Address, type a hostname, or IP address, for the file system host.

This setting is available for hosts with multiple network interfaces. Use a hostname, or an IP address, for the selected network interface.

The hostname must be 64 characters or less. The IP address can be in either IPv4 or IPv6 format to match the protocol used by your network. The default uses the host's primary hostname and IP address.

7. In Authentication Type, select None, TLS, or SSL.

“Choose an authentication type” on page 53 provides information about this choice.

8. Click Next.







NFS moduleTo complete the NFS module portion of a configuration:



1. In Target Path, type the full path for the local mount point of the target directory on the back-end system.

“Back-end mount point” on page 54 provides more information.

CAUTION!The directory specified in Target Path must contain the NFS Check Directory or migration will not occur. For Solaris zones, the expression of the full path to the mount point of the back-end system depends upon the zone in which FSM is installed and the zone in which the back-end system is mounted. Table 15 on page 55 describes how to determine the full path when using Solaris zones provides more information about the NFS Check Directory.

2. Click Next.









Viewing a file system configurationTo view an existing file system’s configuration:


The procedure to start Console Client and log in to a management domain is described in “Starting Console Client” on page 24.


3. On the View menu, select Configuration.

The View File System Configuration window appears at the top of the workspace pane.

All attributes for the file system appear on the View File System Configuration window. “Configuring a file system” on page 57 describes each of the attributes.

Editing a file system configuration 71


Editing a file system configurationTo edit a file system configuration:


“Starting Console Client” on page 24 explains the procedure to start Console Client and log in to a management domain.


3. On the Edit menu, select File System Configuration.

The File System Configuration wizard opens in edit mode. Attributes that cannot be edited are dimmed.

4. Make changes as needed and click Next to go to the next panel.

“Configuring a file system” on page 57 describes each of the attributes.


The edited configuration is validated, saved, and committed.



Deleting a file system configurationTo delete a file system configuration along with all of the extended rules assigned to the file system:


“Starting Console Client” on page 24 explains the procedure to start Console Client and log in to a management domain.


3. On the Edit menu, select Delete File System.

The Delete File System prompt appears.

4. Click Yes.

The file system configuration and all extended rules are deleted.

Note: Deleting a file system configuration does not affect any of the following: the UTDM file system, data in the file system, or data migrated to the back-end system.

Extended Rules 73

4


◆ Creating an extended rule................................................................. 74◆ Viewing extended rules..................................................................... 86◆ Editing an extended rule................................................................... 87◆ Deleting an extended rule................................................................. 88◆ Copying extended rules .................................................................... 89

Extended Rules


Extended Rules

Creating an extended ruleExtended rules enable you to modify the data management policies for a select group of files in a file system. An extended rule overrides the file system’s configuration for the selected files.

Affected files are determined by the match strings that you specify. The metadata for each file in the file system is compared to the match string to form the group of files affected by the extended rule.

An extended rule is created by specifying the following:

◆ Criteria for selecting a set of files

◆ Data management settings to apply to a set of files

Match stringEvery extended rule uses a match string to define the set of files covered by the rule. A match string is one or more expressions used to select a group of files.

A match string can consist of several expressions separated by the AND operator and the OR operator. When the match string contains several operators, use parentheses to control the effects of operator precedence and associativity, as explained in “Operator precedence and associativity” on page 78.

A match string cannot exceed 127 characters, including space characters.

Parentheses Parentheses are used in match strings to control the order in which operators are applied and expressions are evaluated.

Parenthesis may be used with any of the following:

◆ One expression

◆ Several expressions

◆ Nested groups

One or more left-parenthesis can be added to the beginning of a match string, and after the AND and OR operators. You must add one or more right-parenthesis after an expression or expression group to close each open left-parentheses.

Expressions Match string expressions have the following format:

Creating an extended rule 75

Extended Rules

KeywordOperatorVariable[Filesize-Units]

KeywordTable 20 on page 75 describes the possible keyword values.

OperatorTable 21 on page 75 describes the possible operator values.

Table 20 Possible keyword values in match string expressions

Keyword value Description

FILENAME Relative or full pathnameTo specify a particular directory, use the full pathname including the mount point of the file system.After you type this value, it is placed in quotes by the software.

UID User IDYou can type this value in quotes (string value) or without quotes (numeric value).

GID Group IDYou can type this value in quotes (string value) or without quotes (numeric value).

FILESIZE File size

Table 21 Possible operator values in match string expressions (page 1 of 2)

Operator value Description

== Keyword is equal to Variable.

<> Keyword is not equal to Variable.

> Used only when the value of Keyword is FILESIZE, or when Keyword is UID or GID, and Variable is numeric.File size is greater than the Variable number of Filesize-Units, or UID or GID is greater than Variable.


Extended Rules

VariableThe characteristics of Variable differ depending upon the context:

◆ String value when used with FILENAME (value you type is placed in quotes by the software)

◆ String value when used with UID or GID and in quotes

◆ Integer value when used with UID or GID and not in quotes

◆ Integer when used with FILESIZE

Table 22 on page 77 describes the possible variable values.

>= Used only when the value of Keyword is FILESIZE, or when Keyword is UID or GID, and Variable is numeric.File size is greater than, or equal to, the Variable number of Filesize-Units; or UID or GID is greater than, or equal to, Variable.

< Used only when the value of Keyword is FILESIZE, or when Keyword is UID or GID, and Variable is numeric.File size is less than the Variable number of Filesize-Units; or UID or GID is less than Variable.

<= Used only when the value of Keyword is FILESIZE, or when Keyword is UID or GID, and Variable is numeric.File size is less than, or equal to, the Variable number of Filesize-Units; or UID or GID is less than, or equal to, Variable.

Table 21 Possible operator values in match string expressions (page 2 of 2)

Operator value Description


Extended Rules

Example 3 Matching files in several directories by filename

You need an extended rule to apply to all files in a file system whose name starts with the letters "imp". The file system consists of many directories and subdirectories.

In the extended rule wizard you select the FILENAME keyword and type the string "imp", without the quotes. The following appears:

IF FILENAME=="imp*"

This string does not match the entire set.

You select FILENAME and type the string */imp*. The following appears:

IF FILENAME=="*/imp*"

This string matches the entire set.

Table 22 Possible variable values in match string expressions

Variable type Description

String When Keyword is FILENAME, UID, or GID.For UID or GID, a value is an integer unless it is in quotes. For FILENAME, all values are strings and are placed in quotes by the software.Variable is a text string of 120 characters or less, representing a regular expression. Parentheses are not permitted. Wildcards may be used. However, the directory path symbol (/) must be included when creating a wildcard string expression that matches the beginning of the name of files that exist in more than one directory. This is described further in Example 3 on page 77.

Integer When Keyword is FILESIZE, UID, or GID.For UID or GID, a value is an integer unless it is in quotes.When used with FILESIZE, it is an integer that represents the number of Filesize-Units. A FILESIZE comparison is formed by using the integer typed in Variable and the units selected in Filesize-Units.When not in quotes and used with UID or GID, it is an integer that represents a numeric user ID or group ID. The value of Variable must be numeric in this usage or the evaluation will fail.


Extended Rules

Filesize-UnitsThe Filesize-Units value is only used when the value of Keyword is FILESIZE. Table 23 on page 78 explains the possible values for Filesize-Units.

Operator precedenceand associativity

When several operators exist in a match string, the operators are applied in the order of their precedence. If operators of equal precedence exist in the match string, they are applied by using the associativity rule.

Placing an expression in parentheses causes that expression to be evaluated before the operator precedence and associativity rules are applied.

Operator precedence and associativity are shown in Example 4 on page 79.

PrecedenceTable 24 on page 78 shows the precedence of match string operators.

Table 23 Possible Filesize-Units values in match string expressions

Filesize-Units value Description

bytes Bytes

KB Kilobytes

MB Megabytes

GB Gigabytes

Table 24 Operator precedence in a match string

Precedence order Operator

First < and <=

Second > and >=

Third == and <>

Fourth AND

Fifth OR


Extended Rules

AssociativityOperators of equal precedence are applied left-to-right.

Example 4 Operator precedence and associativity

Match String 1 (displayed):

(FILENAME=="*data*" OR FILENAME=="*info*") AND UID<>123

The group of files defined by this match string contains both of the following:

◆ All files in the file system that do not have the user ID 123, and have the string "data" in their pathname.

Note: This includes files whose pathname includes a directory with "data" in its name. The matching logic views a pathname as a single string expression. The character (/), normally considered a directory path character, is treated the same as any other character.

◆ All files in the file system that do not have the user ID 123, and have the string "info" in their pathname.

In Match String 1, the OR operator is applied before the AND operator because of the parentheses around the first two expressions. The expression "UID not equal to 123" ("UID<>123") is applied to the resulting two sets of files.

Match String 2 (displayed):

FILENAME=="*data*" OR FILENAME=="*info*" AND UID<>123

The group of files defined by this match string is different from the group defined by Match String 1.

The Match String 2 group contains both of the following:

◆ All files in the file system that have the string "data" in their pathname

◆ All files in the file system that do not have the user ID 123, and do have the string "info" in their pathname

In Match String 2, the AND operator is applied before the OR operator. The expression "UID not equal to 123" ("UID<>123") is applied only to the set of files generated by the expression:

FILENAME=="info"


Extended Rules

Creating an extended ruleTo create an extended rule:



2. On the tree pane, select the file system that will use the extended rule.

Note: Only a file system that is managed by FSM can use extended rules.

3. On the View menu, select Extended Rules.

The file system's Extended Rules tab appears.

4. On the Extended Rules tab, click Create New Rule.

The Extended Rule wizard appears.

5. In Rule Name, type a name for the new rule.

The name may be any combination of ASCII characters, from 1 to 32 characters in length. The name cannot match the name of any other extended rule in the file system.

6. (Optional) In Migrate Candidacy Delay, specify a number of minutes after a matched file is last accessed before it can be migrated.


7. (Optional) In Purge Candidacy Delay, specify a number of minutes after a matched and migrated file is last accessed before it can be purged.


8. Form a match string:

a. (Optional) Click the left-parenthesis to type one or more left-parenthesis.

Parentheses are used to control operator precedence and associativity.

b. Select one of the following keywords: FILENAME, UID, GID, FILESIZE.


Extended Rules

The keyword defines the type of metadata used to define the matched set of files.

Select one of the following operators:

== , <> , > , >= , < , or <=.

c. Type a value in the text box, as follows:

– For the FILENAME keyword, type a string.– For the UID keyword, type a quoted string, or an integer.– For the GID keyword, type a quoted string, or an integer.– For the FILESIZE keyword, type an integer.

Note: Wildcard characters may be used for keyword FILENAME, and for keywords UID and GID when a quoted string is used. The scale of the integer typed for keyword FILESIZE is determined by the size units.

d. (For keyword FILESIZE only) Select the size units: bytes, KB, MB, or GB.

e. Click Add.

The expression is added to the Match String.

f. (Optional) Type one or more right-parenthesis to enclose an expression or expression group.

The parentheses appear in the Match String.

g. (Optional) Click AND or OR.

The operator appears in the Match String.

h. (Optional) Click NOT to modify an AND or OR operator.

An exclamation mark appears following the AND or OR operator, changing them to AND NOT and OR NOT.

i. (Optional) Repeat step a through step h to add another expression to the Match String.

j. Click the right-parenthesis to close all open left-parentheses.

The number of right-parentheses in the Match String must equal the number of left-parentheses.


Extended Rules

Note: Click Undo to remove the latest element added to the Match String (an expression is considered a single element). Click Clear to remove all elements from the Match String.

9. Click Next.

The Actions and Checksum panel appears.

10. (Optional) Select Do Not Migrate to prevent migration of matched files.

11. (Optional) Select Do Not Purge to prevent purging of matched files.

12. (Optional) Select Purge After Migrate to allow immediate purging of matched and migrated files.

The default is to use the file system's Delay Until Purge Candidacy setting.

13. (Optional) Select Enable Data Compression and set a data compression level.

When you enable this setting, file system data is compressed before it is migrated. Data compression level 1 is the least amount of compression and level 9 is the highest.

The higher the compression you set the more the file system host's CPU will be utilized.

Note: Selecting Enable Data Compression prevents the use of the staging setting Partial Read Size.

14. (Optional) In Stub Size, set the number of kilobytes retained in the file system for matched files.

The range is 0 to 131,072 KB (128 MB). The default is 0.

15. In Checksum, select a checksum setting, as described in Table 25 on page 83.


Extended Rules

16. In File Time Purge Policy, select either Purge on Last Modification Time or Purge on Last Access Time.

This setting determines the starting point for the Delay Until Purge Candidacy period:

• Purge on Last Modification Time starts the period after the last modification of a file.

• Purge on Last Access Time starts the period after the last time the file was accessed.

17. In File Time Migration Policy, select either Migrate on Last Modification Time or Migrate on Last Access Time.

This setting determines the starting point for the Delay Until Migrate Candidacy period:

• Migrate on Last Modification Time starts the period after the last modification of a file.

• Migrate on Last Access Time starts the period after the last time the file was accessed.

18. Click Next.

19. Complete the module-specific extended rule actions for the Level 1 back-end system.

Table 25 Descriptions of Checksum settings

Setting Description

Use file system checksum value Checksums are generated as specified in the file system's Checksum setting.This is the default.

No checksumming Checksums will not be generated for matched files.

Checksum during migration A checksum is generated for each matched file when it is migrated.

Checksum during migration and staging A checksum is generated for each matched file when it is migrated. The checksum is regenerated and compared to the original when the file is staged.


Extended Rules

Procedures for module-specific configurations are explained in the following sections:

• “Centera module actions” on page 84

• “NFS actions” on page 85

• “FTP actions” on page 85

20. (Optional) If you selected a Level 2 back-end system, complete the module-specific extended rule actions related to it.

21. Click Finish.

The extended rule is validated, saved, and committed.

Centera moduleactions

To configure extended rule actions for a Centera module back-end system:

1. In Retention Period, select one of the settings described in Table 26 on page 84.

If you select Days, then set the number of days. The range is 1 to 36,500 days.

2. In Retention Class, type the name of a valid Centera system retention family to apply to matched files.

3. Click Next.


Table 26 Descriptions of Retention Period settings

Setting Description

Do Not Set Deleted data for matched files is retained for the period specified by the Centera system.This is the default and has the same result as selecting Default.

None Deleted data for matched files is immediately available for purging from the Centera system.

Default Deleted data for matched files is retained for the period specified by the Centera system.

Infinite Deleted data for matched files is never available for purging from the Centera system.

Days Deleted data for matched files is not available for purging from the Centera system until after the specified number of days.


Extended Rules

5. Click Finish.


NFS actions There are no extended rule actions specific to an NFS back-end system. All general actions are applied.

To finish creating the extended rule:

1. Click Next.


3. Click Finish.


FTP actions There are no extended rule actions specific to an FTP back-end system. All general actions are applied.

To finish creating the extended rule:

1. Click Next.


3. Click Finish.



Extended Rules

Viewing extended rulesTo view the extended rules for a file system:





The file system's Extended Rules tab appears.

The Extended Rules tab displays all rules for the file system.

For each rule, the columns on the Extended Rules tab list the rule's general actions. The columns correspond to the actions described in “Creating an extended rule” on page 74.

For each rule, the Extended Rules tab also displays any back-end system specific actions. The actions listed correspond to the actions described in “Centera module actions” on page 84.

Editing an extended rule 87

Extended Rules

Editing an extended ruleAn administrator may edit an extended rule. To edit an extended rule:




3. On the View menu, select Extended Rule.

The Extended Rules tab appears.

4. Select an extended rule to edit.

5. Click Edit Rule.

The Extended Rule wizard opens in edit mode. Attributes that cannot be edited are dimmed.

6. Make changes as needed and click Next to go to the next panel.

“Creating an extended rule” on page 74 provides more information about individual settings.

Note: The Extended Rule wizard in edit mode is identical to the Extended Rule wizard, except that the match string Undo button is unavailable. The match string may not be edited by using Undo. To edit the match string, click Clear. This clears the existing match string so that a new match string can be created.


The edited extended rule is validated, saved, and committed.


Extended Rules

Deleting an extended ruleAn administrator may delete an extended rule. After deletion, the extended rule is no longer applied to the file system.

Deleting an extended rule does not affect the following:

◆ The file system’s configuration information

◆ The file system’s data

To delete an extended rule:




3. On the View menu, select Extended Rule.

The Extended Rules tab appears.

4. Select an extended rule to delete.

5. Click Delete Rule.

A confirmation prompt appears.

6. Click Yes.

The extended rule is deleted.

Copying extended rules 89

Extended Rules

Copying extended rulesAn administrator may copy extended rules between file systems in the same management domain. This copies only the selected extended rules. File system configuration information and file system data are not copied.

To copy extended rules:

1. Start Console Client and log in to the management domain that controls the FSM hosts for the file systems.


2. From the Edit menu, select Copy Extended Rule.

The Copy Extended Rule window appears.

3. In Copy From File System, select an FSM host and file system to copy from.

4. In Copy To File System, select an FSM host and file system to copy to.

Note: The file system selected in Copy To File System must use the same back-end module as the file system selected in Copy From File System.

5. In Extended Rule, select an extended rule to copy, or select Copy Entire Rule Set.

Selecting Copy Entire Rule Set copies all of the extended rules for the selected file system.

6. Click OK to perform the copy operation.

The selected extended rules are copied


Extended Rules

Scheduled Jobs 91

5

This chapter describes schedules in the following topics:

◆ Scheduled jobs overview .................................................................. 92◆ Creating a scheduled job................................................................... 96◆ Time elements................................................................................... 102

Scheduled Jobs


Scheduled Jobs

Scheduled jobs overviewScheduled jobs allow you to define automatic run periods and blackout periods for the following file system jobs:

◆ Migrate

◆ Purge

◆ Delete Old Files

◆ Prune

For each managed file system, you can create one Migrate job and one Purge job. You can also create one Delete Old Files job and one Prune job for each of the file system’s back-end systems.

Table 27 on page 92 compares each job before and after a scheduled job is created for it.

Table 27 Scheduled job comparison

Job type Without a scheduled job With a scheduled job

Migrate Runs automatically. Checks for migration candidates on the interval defined by the file system's Sleep Interval Until Next Migration setting.

Runs automatically during defined runtimes. Checks for migration candidates on the interval defined by the runtime element. Stops running during defined blackout times.

Purge Runs automatically. Checks for purge candidates on the interval defined by the file system’s Sleep Interval Until Next Purge setting.

Runs automatically during defined runtimes. Checks for purge candidates on the interval defined by the runtime element. Stops running during defined blackout times.

Delete Old Files

Must be run manually as described in “Periodic back-end system cleanup” on page 175.

Runs automatically during defined runtimes. Deletes orphaned files on the back-end system (as described in “Delete Old Files job” on page 94) on the interval defined by the runtime element. Stops running during defined blackout times.

Prune Will not run. Runs automatically during defined runtimes. Only runs on the Level 1 back-end system, and only if the file system also has a Level 2 back-end system. Stops running during defined blackout times.Files on the Level 1 back-end system are “pruned” (marked as deleted) when the number of days since their migration exceeds the number of days set in the expiration period. Pruned files become available for removal by back-end system cleanup or Delete Old Files jobs.File system data is not affected by pruning and files are not removed from the Level 2 back-end system.

Scheduled jobs overview 93

Scheduled Jobs

A scheduled job consists of a standard file system job with an assigned schedule. Table 28 on page 93 describes the assigned schedule components.

Effect on existing file system settings

A scheduled job can honor some file system settings and overrule others.

Table 29 on page 94 explains the settings that are honored and that are overruled. Whether the settings will be honored or overruled depends on the type of job scheduled.

Table 28 Components of a schedule

Component Description

Name Descriptive label for the schedule. The Name value must be unique for each schedule created for a file system.

Description Information about the schedule's purpose.

Run Time Time perioda during which the task is started regularly on the wake-up interval. More than one Run Time may be assigned to a schedule.

Note: Blackout times have priority over runtimes. Jobs do not run during time periods in which blackout time segments coincide with runtime segments.

a. Time periods are defined by the assigned time elements. Time elements are described in “Creating a scheduled job” on page 96.

Black Out Time Time period that the task cannot be run. More than one Black Out Time value may be assigned to a schedule.


Scheduled Jobs

Delete Old Files jobThe Delete Old Files job removes files on a back-end system that have become orphaned because the files have been deleted from the file system. Those files are marked for deletion by FSM but are not automatically removed. “Periodic back-end system cleanup” on page 175 explains the effect that Delete Old Files jobs have.

If a file system has two back-end systems, the Delete Old Files job runs only for the back-end system that is selected. The behavior of a scheduled Delete Old Files job changes depending on the type of back-end target. Table 30 on page 95 explains the difference in the Delete Old Files job that changes depending on the type of the back-end target.

Table 29 Effect of a scheduled job on file system settings

Job type Honored settings Overruled settings Effect

Migrate • Delay Until Migrate Candidacy

• Minimum File Size to Migrate

• Extended Rules

Sleep Interval Until Next Migration

After a migrate job is scheduled, migration of eligible files is started only during the job's runtimes. No files are migrated during the job's blackout times.During runtimes, the eligibility logic specified by the file system settings is applied.Extended rules are only applied during scheduled runtimes.

Purge • Delay Until Purge Candidacy

• Minimum File Size to Purge

• Concurrent Files Purged• File Stub Size• High Watermark• Low Watermark• Concurrent Files Migrated• Extended Rules

• Sleep Interval Until Next Purge

• Purge After Migrate

After a purge job is scheduled, purge of eligible files is started only during the job's runtimes. No files are purged during the job's blackout times.A scheduled purge job can also overrule an enabled Purge After Migrate setting by preventing the immediate purging of files that are migrated during the purge job's blackout times.During runtimes, the eligibility logic specified by the file system settings is applied.Extended rules are only applied during scheduled runtimes.

Delete Old Files Concurrent Files Destroyed None None

Prune None None None

Scheduled jobs overview 95

Scheduled Jobs

Prune jobThe Prune job removes files from a Level 1 back-end system after a set number of days (expiration period). This clears the Level 1 back-end system of older files, but the availability of all files is not affected. When files that have been pruned are needed, they are retrieved from the Level 2 back-end system.

Prune jobs have the following characteristics:

◆ Run only on Level 1 back-end systems

◆ Run only when the file system has both Level 1 and Level 2 back-end systems

◆ Cannot be run manually

◆ Files must be migrated before they are eligible for pruning

◆ Files do not need to be purged to be eligible for pruning

Table 30 Delete Old Files job differences

Module type Description

Centera The Delete Old Files job applies to all eligible file data from all UTDM file systems that share the same virtual pool on a Centera system.

Note: To avoid performance issues on the Centera system, schedule a Delete Old Files job only on one UTDM file system in any virtual pool. Because the job runs for all UTDM file systems in the virtual pool, scheduling more than one job wastes resources on the Centera system.

FTP The Delete Old Files job is not available for an FTP module back-end system. This task must be performed on the back-end host. “Periodic back-end system cleanup” on page 175 describes how to do this.

NFS The Delete Old Files job applies to the selected file system only.


Scheduled Jobs

Creating a scheduled jobIn overview, creating a scheduled job involves the following tasks:

1. Select a file system.

2. Select a job type: Migrate, Purge, Delete Old Files, or Prune.

3. If creating a Delete Old Files or Prune job, select a back-end system.

4. If creating a Delete Old Files and Prune job, set the Age or Expiration Period.

5. Create a named schedule.

6. Create time elements.

7. Add time elements to the Run Times and Black Out Times of the schedule.

8. Assign the schedule to the job.

For each managed file system you can create the following jobs:

◆ One Migrate job

◆ One Purge job

◆ One Delete Old Files job for the Level 1 back-end system and one for the optional Level 2 back-end system

◆ One Prune job for the Level 1 back-end system only

Schedules that you create may be assigned to more than one scheduled job and may be used on more than one file system.

Creating a scheduled jobTo create a scheduled job:

1. On the tree pane, select the file system that will use the scheduled job.

2. On the View menu, select Schedules.

The Schedules window is displayed with the file system listed in File System.

3. Select the Jobs tab, and in Job Type select a job type to assign to the schedule.

Creating a scheduled job 97

Scheduled Jobs

4. (For Delete Old Files and Prune jobs only) In Backend, select the Level 1 or Level 2 back-end system.

This setting only affects Delete Old Files and Prune jobs.

Note: To schedule a Prune job, the Level 1 back-end system must be selected. The Assigned Schedule section is not available, and a Prune job cannot be scheduled if the Level 2 back-end system is selected (or if the file system has only a Level 1 back-end system).

5. (For Delete Old Files and Prune jobs only) Set a number of days:

• Delete Old Files job, in Age (days), set the number of days that must pass, after the deletion of a file from the file system, before the file's data is eligible to be deleted from the selected back-end system.

The default is 365 days. The range is 0 to 999,999 days.

Note: Back-end system data can be used to restore files that are mistakenly deleted from the file system. To maximize this safeguard, set the Age value high to retain back-end data as long as possible.

• For a Prune job, in Expiration Period, set the number of days that must pass, after migration, before a file is pruned.

The default is 365 days. The range is 1 to 999,999 days.

6. Select the Schedules tab, and in the Configured Schedules section click the Create a New Schedule icon.

7. On the Create a New Schedule box, type a name for the schedule and click OK.

Note: The schedule's name must be unique among all schedules on the file system's host. Use a descriptive name to make the schedule easier to recognize.

8. On the Schedules tab, in the Time Elements section, click the Add a New Time Element icon to open the Create a New Time Element wizard.

9. Use the Create a New Time Element wizard to create and save the time elements required for the new schedule.

“Creating a new time element” on page 102 describe how to use this wizard.


Scheduled Jobs

10. Select a time element to add as a runtime for the schedule, and click the Add the Selected Time Elements to the Current Run Times icon.

Repeat this process to add any other time elements to Run Times.

Note: Blackout times have priority over runtimes. Jobs do not run during time periods in which blackout time segments coincide with runtime segments.

11. Select a time element to add as a blackout time for the schedule, and click the Add the Selected Time Elements to the Current Black Out Times icon.

Repeat this process to add any other time elements to Black Out Times.

12. Click Save.

The new schedule is added to Configured Schedules.

13. In the Assigned Schedule section, click the Select a Schedule to Use icon.

14. On the Choose a Schedule box, select the name of the schedule you created, and click OK.

The scheduled job is created and is assigned to the file system. It is graphically displayed in the monthly and daily calendars.

Viewing a scheduled jobScheduled jobs are graphically and textually displayed on the Jobs tab.

To view the Jobs tab for a file system:



The Schedules window is displayed.

3. Select the Jobs tab.

The Jobs tab displays the schedules for each job type in the calendar month section.


Scheduled Jobs

4. In Month and Year, select the month and year that you wish to view.

The calendar month displays the selected month.

5. In the calendar month section, click on a day of the month.

The job schedules for that day are graphically portrayed in the day view, and textually displayed in the Time Spans view.

Editing a scheduleEditing a schedule involves the following tasks:

◆ Remove all assigned tasks from the schedule.

◆ Remove time elements that need to be changed from the schedule's Run Times and Black Out Times.

◆ Edit time elements and create new time elements.

◆ Add time elements to the schedule's Run Times and Black Out Times.

◆ Save the schedule.

To edit a schedule:

1. On the tree pane, select the file system that uses the schedule.


The Schedules window appears.

3. On the Jobs tab, in the Selected Jobs section, select a Job Type that is assigned to the schedule.

4. In the Assigned Schedule section, click the Revert Back icon.

Repeat steps 3 and 4 for each Job Type that is assigned to the schedule.

5. On the Schedules tab, in the Configured Schedules section, select the schedule.

6. In the schedule's Run Times section, select a time element to remove or edit and click Remove.

Repeat this for each time element that you wish to remove or edit.

7. In the schedule's Black Out Times section, select a time element to remove or edit and click Remove.


Scheduled Jobs

Repeat this step for each time element to remove or edit.

8. In the Time Elements section, click the Add a New Time Element icon to create a new time element, or select an existing time element and click Edit the Selected Time Element to edit it.

Both actions open the Create a New Time Element wizard. “Creating a new time element” on page 102 explains how to use the wizard to configure and save the time element.

Repeat this for each time element to add to the edited schedule.

9. Select a time element to add as a runtime for the schedule, and click the Add the Selected Time Element to the Current Run Times icon.

Repeat this process to add any other time elements to Run Times.

10. Select a time element to add as a blackout time for the schedule, and click the Add the Selected Time Element to the Current Black Out Times icon.

Repeat this process to add any other time elements to Black Out Times.

11. Click Save.

The new schedule is added to Configured Schedules and is ready to use.

To complete the schedule, a task must be assigned. “Creating a scheduled job” on page 96 explains how to assign a completed task.

Deleting a scheduleDeleting a schedule involves the following tasks:

◆ Remove all assigned tasks from the schedule.

◆ Delete the schedule.

To delete a schedule:

1. On the tree pane, select the file system that uses the schedule.


The Schedules window appears.

3. On the Jobs tab, in the Selected Jobs section, select a job type that is assigned to the schedule.


Scheduled Jobs


Repeat steps 3 and 4 for each job type that is assigned to the schedule.

5. On the Schedules tab, in the Configured Schedules section, select the schedule and click the Delete the Selected Schedule icon.

The schedule is deleted.


Scheduled Jobs

Time elementsTime elements are the building blocks of a schedule. Before you can create a scheduled job you must create at least one time element. Table 31 on page 102 describes the components of a time element.

“Creating a scheduled job” on page 96 describes how to create a scheduled job by using the available time elements.

Creating a new time elementTo create a new time element:

1. On the Schedules tab, in the Time Elements section, click the Add a New Time Element icon.

The Create a New Time Element wizard launches.

2. Select one of the recurrence options.

Table 32 on page 103 describes the options.

Table 31 Components of a time element

Component Description

Recurrence The calendar cycle that provides the framework for the schedule. This can be daily, weekly, monthly, yearly, weekends, or weekdays.

Wake-up interval Time interval on which the task is started. The task is started at each wake-up interval during the runtime. However, if the task is already running from a previous wake-up, additional processes are not started.

Note: The wake-up interval is determined based on the host’s internal clock, not the last start or finish of the job. For example, a 15 minute wake-up interval with a daily recurrence would check if the job is running and start it if it is not at: midnight, 12:15 A.M., 12:30 A.M., 12:45 A.M., and so forth.

Start time Beginning of the time period included in a time element.

End time End of the time period included in a time element.

Time elements 103

Scheduled Jobs

3. Click Next.

The fields on the wizard's second screen change depending upon the recurrence option selected.

To complete the creation of a time element go to the relevant section:

• “One Specific Time” on page 103

• “Daily” on page 104

• “Monthly” on page 104

• “Weekends” on page 105

• “Weekly” on page 105

• “Yearly” on page 106

• “Weekdays” on page 106

One Specific Time To complete a time element that uses the One Specific Time recurrence option:

1. In Wake Up Interval, specify the number of minutes that should pass between checks to see if the job is running and, if it is not, start the job.

Table 32 Recurrence options

Name Description

One Specific Time Starts a job on a specific date and time and does not recur.

Daily Starts a job every day at a specific time.

Monthly Starts a job on a specific day of the month at a specific time and recurs each month.

Weekends Starts a job at a specific time on Saturday and Sunday and recurs every Saturday and Sunday.

Weekly Starts a job on a specific day of the week at a specific time and recurs every week.

Yearly Starts a job on a specific month, day of the month, and time and recurs every year.

Weekdays Starts a job at a specific time on each weekday (Monday-Friday) and recurs every weekday.


Scheduled Jobs

During specified runtime, the job is checked on the wake-up interval to see if it is running. If the check shows that the job has finished, it is started again. The wake-up interval is determined from the host’s internal clock, not from when the job last started or finished.

2. In Year, specify the year for the time element.

3. In From, specify the month, day, and time to start.

This is the one time at which the time element starts the job running.

4. In Until, specify the month, day, and time that the time element stops running, or select Do not stop.

A Do not stop selection configures the time element to start at the start time and run until the end of the year.

5. Click Finished.

Daily To complete a time element that uses the Daily recurrence option:


2. In From, specify a start time.

This is the time every day at which the time element starts the job running.

3. In Until, specify the time that the time element stops running, or select Do not stop.

A Do not stop selection configures the time element to start at the start time and run until the end of the day.

4. Click Finished.

Monthly To complete a time element that uses the Monthly recurrence option:


2. In From, specify the day of the month and time to start.

This is the time every month at which the time element starts the job running.

Time elements 105

Scheduled Jobs

3. In Until, specify the day of the month and time that the time element stops running, or select Do not stop.

A Do not stop selection configures the time element to start at the start time and run until the end of the month.

4. Click Finished.

Weekends To complete a time element that uses the Weekends recurrence option:



This is the time every Saturday and Sunday at which the time element starts the job running.


A Do not stop selection configures the time element to start at the start time and run until the end of the day.

4. Click Finished.

Weekly To complete a time element that uses the Weekly recurrence option:


2. In From, specify the day of the week and time to start.

This is the time every week at which the time element starts the job running.


Scheduled Jobs

3. In Until, specify the day of the week and time that the time element stops running, or select Do not stop.

A Do not stop selection configures the time element to start at the start time and run until the end of the week.

4. Click Finished.

Yearly To complete a time element that uses the Yearly recurrence option:


2. In From, specify the month, day, and time to start.

This is the time every year at which the time element starts the job running.

3. In Until, specify the month, day, and time that the time element stops running, or select Do not stop.

A Do not stop selection configures the time element to start at the start time and run until the end of the year.

4. Click Finished.

Weekdays To complete a time element that uses the Weekdays recurrence option:



This is the time every weekday at which the time element starts the job running.


A Do not stop selection configures the time element to start at the start time and run until the end of day.

4. Click Finished.

Time elements 107

Scheduled Jobs

Editing a time elementTo edit a time element:

1. On the Schedules tab, in the Time Elements section, select the time element.

2. Click the Add a New Time Element icon.

The Create a New Time Element wizard launches with selected time element’s settings.

3. Use the wizard to edit the time element settings and click Finished.

Deleting a time elementDeleting a time element involves the following tasks:

◆ Remove the time element from each schedule in a file system.

◆ Delete the time element.

To delete a time element:

1. On the tree pane, select the file system that uses the time element.


The Schedules window is displayed.

3. On the Jobs tab, in the Selected Jobs section, select a Job Type that is assigned to a schedule that uses the time element.


5. Repeat steps 3 and 4 for each job type that is assigned to a schedule that uses the time element.

6. Repeat steps 3, 4, and 5 for each schedule that uses the time element.

7. On the Schedules tab, in the Configured Schedules section, select the schedule.

8. If the time element is in the schedule's Run Times section, select it and click Remove.

9. If the time element is in the schedule's Black Out Times section, select it and click Remove.


Scheduled Jobs

10. Repeat steps 7, 8, and 9 for each schedule that uses the time element.

11. On the Schedules tab, in the Time Elements section, select the time element and click the Delete the Selected Time Element icon.

Advanced UTDM Mount Options 109

6

This chapter describes the following mount options:

◆ Centera system data retention........................................................ 110◆ Read-only .......................................................................................... 117◆ Direct-read......................................................................................... 120

Advanced UTDMMount Options


Advanced UTDM Mount Options

Centera system data retentionCentera system data retention uses the bckendreten mount option to provide a mechanism to prevent the following data operations in the file system and on the back-end system:

◆ Overwrite

◆ Truncation

◆ Removal

◆ Modification of its metadata

◆ Modification of its retention period

These operations cannot be initiated in the file system or on the Centera system by any process, including non-FSM processes, for files that have been migrated or that are eligible for migration. A file is eligible for migration if it has not been modified for at least the period specified in the file system’s Delay Until Migrate Candidacy value.

When a file is subject to Centera system data retention, the file’s data cannot be changed during the retention period, in the file system or on the Centera system. Data on a secondary back-end system is not protected by this data retention mechanism.

Performance impactUTDM file systems that are mounted with the bckendreten mount option generate a retention event to the core processes when a file modification operation is attempted. This event determines whether the modification is allowed.

The core processes instruct the UTDM file system to deny the attempt if either of the following is true for a file:

◆ The file is migrated and there is an unexpired retention period for its data on the Centera system.

◆ The file is not migrated and has not been modified within the period specified in the file system’s Delay Until Migrate Candidacy value. There is also a Centera Retention Period or Centera Retention Class associated with the file.

The retention events can have a performance impact on file modification operations. A slight impact can occur because the core

Centera system data retention 111


processes must query the Centera system for the applicable retention period.

Retention events will not adversely impact normal file creation operations. UTDM file systems do not generate a retention event during the first minute after a file is created or modified.

RequirementsCentera system data retention requires the following:

◆ The Centera system must use one of the following license models:

• Governance Edition (GE)

• Compliance Edition Plus (CE+)

◆ The UTDM file system must use the Centera system as its primary back-end system.

◆ The UTDM file system configuration must specify at least one of the following:

• A value in Retention Class

• A value in Retention Period other than None

• An extended rule that sets a retention period or retention class

◆ The file system must be mounted with the bckendreten mount option.

◆ The FSM host system and the Centera should be in the same time zone for retention to be in sync.

Enabling Centera system data retentionTo set Centera system data retention periods, first enable retention for the file system. Retention is specified by using the bckendreten option when mounting the file system.

To enable Centera system data retention for a file system:

1. Log in to the file system’s host as root.


“Setting the FSM environment” on page 185 provides more information.

3. Stop all FSM processes:



kill.fsm

4. If the file system is mounted, unmount it:

umount [-f] /file-system

where /file-system is the full path to the file system’s mount point.

Note: On Linux systems, the -f option must be used when you unmount a UTDM type file system. This is because the file system is viewed as busy by the operating system.

5. Table 33 on page 112 shows the various methods to mount the file system.

The variables for the procedures shown in Table 33 on page 112 are as follows:

• fstype is the native type of the file system.

• blkdev is the full path to the block special device.

• mntpnt is the full path to the mount point.

• chardev is the full path to the character special device.

• log is the log file that is generated for the logical volume.

Table 33 Mounting with Centera system data retention (page 1 of 2)

Mounting method Procedure

Command line(All operating systems, except Linux and AIX)

As root, run the following mount command:mount-F utdm -o fstype=fstype,bckendreten /blkdev /mntpnt

Command line(Linux only)

As root, run the following mount command:mount-t utdm -o fstype=fstype,bckendreten /blkdev /mntpnt

Command line(AIX only)

As root, run the following mount command:mount-V utdm -o fstype=fstype,bckendreten /blkdev /mntpnt



6. Restart the FSM processes:

rc.fsm

Centera system data retention is enabled for the file system.

Setting retention for a file systemTo set Centera system data retention for all files in a file system:

1. Mount the file system by using the bckendreten mount option.

“Enabling Centera system data retention” on page 111 provides more information.


“Starting Console Client” on page 24 describes how to start Console Client and log in to a management domain.



File system table(Solaris only)

As root, edit the /etc/vfstab file so that the entry for the file system uses the bckendreten option, as shown here:/blkdev /chardev /mntpnt utdm 2 yes fstype=fstype,bckendreten

Save the file and mount the file system:mount /mntpnt

File system table(Linux and HP-UX only)

As root, edit the /etc/fstab file so that the entry for the file system uses the bckendreten option, as shown here:/blkdev /mntpnt utdm fstype=fstype,bckendreten 0 2


File system table(AIX only)

As root, edit the /etc/filesystems file so that the options line of the file system’s entry includes the bckendreten option:options=rw,fstype=fstype,log=/dev/log,bckendreten


Table 33 Mounting with Centera system data retention (page 2 of 2)




The File System Configuration wizard opens in edit mode.

5. Click Next until the Level 1 - Centera Backend panel appears.

6. In Retention Class, type the name of a Centera system retention class.

Note: If a suitable retention class does not exist on the Centera system, you can specify a retention period. However, Retention Period cannot be None if Retention Class is empty.

7. Click Next until the Finish and Commit panel appears.

8. Click Finish.

The configuration is validated, saved, and committed. The file system is ready to use and Centera system data retention is active.

Note: Steps 1 through 8 describe how to edit an existing file system configuration to set Centera system data retention. You may edit other file system configuration parameters when performing these steps. You can also set Centera system data retention when a file system is first configured.

Setting retention for a group of filesTo set Centera system data retention for a group of files in a file system:

1. Mount the file system by using the bckendreten mount option.

“Enabling Centera system data retention” on page 111 provides more information.





5. On the Extended Rules tab, click Create New Rule.

The Extended Rule wizard appears.

6. In Rule Name, type a name for the new rule.



The name may be any combination of ASCII characters, from 1 to 32 characters in length. The name cannot match the name of any other extended rule in the file system.

7. Form a match string that identifies the group of files.

“Creating an extended rule” on page 74 provides information about forming a match string.

8. Click Next until the Centera Actions panel for the primary back-end system appears.

9. In Retention Class, type the name of a valid Centera system retention class.

Note: If a suitable retention class does not exist on the Centera system, you can specify a retention period. However, Retention Period cannot be None if Retention Class is empty.


11. Click Finish.

The extended rule is validated, saved, and committed. The file system is ready to use and Centera system data retention is active for the specified group of files.

Note: Steps 1 through 11 describe how to create an extended rule to set Centera system data retention for a group of files. You may specify other extended rule parameters when performing these steps. You can also edit an existing extended rule to add Centera system data retention.

Restoring incremental backupsCentera system data retention can prevent the use of incremental backups to restore some files to a UTDM file system. The affected files are those that have all of the following characteristics:

◆ The file is not a migration candidate when the full backup is created.

◆ The file is modified after the full backup is created and before incremental backup is created.

◆ The time between the creation of the full backup and the restoring of the incremental backup is greater than the value of the Delay Until Migrate Candidacy value.



When all of these characteristics are true for a file, the UTDM file system allows the restore of the file from the full backup, but rejects the restore of the file from the incremental backup.

To restore incremental backups while using Centera system data retention:





The File System Configuration wizard opens in edit mode. Attributes that cannot be edited are unavailable.

4. Click Next until the Optional Migration Settings panel appears.

5. Increase the value of Delay Until Migrate Candidacy.

The value of Delay Until Migrate Candidacy is expressed in minutes. It must be increased to be greater than the number of minutes from the time of the full backup to the time of the restore.


7. Click Finish.

The edited configuration is validated, saved, and committed.

8. Perform a restore by using the incremental backup.

9. Change Delay Until Migrate Candidacy back to its original value.

Restore of the incremental backup is complete.

Read-only 117


Read-onlyThis release provides the utdmro mount option to permit a UTDM file system to be mounted read-only.

A read-only mounted UTDM file system functions the same as a standard read-only mounted file system, with one exception: when the UTDM read-only mount option is used, the .DMATTR file is allowed to function normally.

This exception is required to permit the file system to exchange data with the back-end system and perform DMAPI processing.

A read-only, mounted UTDM file system permits the following file system activity:

◆ Reading files

◆ Reading files by using direct-read

◆ Directory traversals

◆ Migration

Files that are ready to migrate after the file system is mounted read-only will not be migrated.

◆ Purge

◆ Staging

◆ Backup

◆ Recovery processing

To perform a recovery, mount the file system normally with Read/Write permissions and perform the complete recovery of the file system before the file system is remounted in read-only mode.

IMPORTANT!A UTDM file system must be mounted read-write before a recovery can be performed.

A read-only mounted UTDM file system does not allow:

◆ File deletions

◆ File permissions or attribute changes

◆ File data modification or truncations



Mounting read-onlyTo mount a UTDM file system read-only:





kill.fsm





5. Table 34 on page 119 explains the methods to mount the file system.







Read-only 119


Table 34 Mounting read-only



As root, run the following mount command:mount -F utdm -o fstype=fstype,utdmro /blkdev /mntpnt


As root, run the following mount command:mount -t utdm -o fstype=fstype,utdmro /blkdev /mntpnt


As root, run the following mount command:mount -V utdm -o fstype=fstype,utdmro /blkdev /mntpnt


As root, edit the /etc/vfstab file so that the entry for the file system uses the bckendreten option, as shown here:/blkdev /chardev /mntpnt utdm 2 yes fstype=fstype,utdmro



As root, edit the /etc/fstab file so that the entry for the file system uses the bckendreten option, as shown here:/blkdev /mntpnt utdm fstype=fstype,utdmro 0 2



As root, edit the /etc/filesystems file so that the options line of the file system’s entry includes the bckendreten option:options=rw,fstype=fstype,log=/dev/log,utdmro




Direct-readThe readthru mount option enables a direct-read on a UTDM file system. Direct-read enhances file system performance by delivering file data from the back-end system directly to a requesting application’s buffers without first writing the data into the file system.

Direct-read works with multiple back-end systems. If the primary back-end system cannot be read, the direct-read request is made of the secondary back-end system.

The direct-read mount option can be used on any UTDM file system. However, only the following back-end modules support it:

◆ NFS

◆ Centera

When a file system that is mounted with direct-read requests data from an unsupported back-end system, the data is staged into the file system and then transferred to the application’s buffers.

Direct-read applies only to reading a file. If the file’s data is altered in any way, then the file is staged into the file system as it would be without direct-read.

Note: The readthru mount option does not work for pruned and compressed files.

Memory-mappingApplications that use the mmap function call to perform memory mapping of file data cannot benefit from direct-read. When an application uses this function, the back-end data is staged into the file system as it would be without direct-read.

In particular, Solaris uses the mmap function call in many of its system utilities, such as cat and cp. The GNU versions of these utilities do not use the mmap function and allow direct-read to work.

Mounting direct-readTo mount a UTDM file system direct-read:

Direct-read 121






kill.fsm





5. Table 35 on page 121 provides information on the various methods used to mount the file system.







Table 35 Mounting direct-read (page 1 of 2)



As root, run the following mount command:mount -F utdm -o fstype=fstype,readthru /blkdev /mntpnt


As root, run the following mount command:mount -t utdm -o fstype=fstype,readthru /blkdev /mntpnt


As root, run the following mount command:mount -V utdm -o fstype=fstype,readthru /blkdev /mntpnt




As root, edit the /etc/vfstab file so that the entry for the file system uses the readthru option, as shown here:/blkdev /chardev /mntpnt utdm 2 yes fstype=fstype,readthru



As root, edit the /etc/fstab file so that the entry for the file system uses the readthru option, as shown here:/blkdev /mntpnt utdm fstype=fstype,readthru 0 2



As root, edit the /etc/filesystems file so that the options line of the file system’s entry includes the readthru option:options=rw,fstype=fstype,log=/dev/log,readthru


Table 35 Mounting direct-read (page 2 of 2)


Backup and Recovery 123

7

This chapter describes backup and recovery of UTDM file systems. Topics include:

◆ Data to back up................................................................................. 124◆ Backup software ............................................................................... 126◆ Recovering a lost file system .......................................................... 128◆ Recovering an FTP module file system ........................................ 130◆ EMC Avamar .................................................................................... 132◆ EMC NetWorker............................................................................... 137◆ EMC NetWorker 64-bit Linux version .......................................... 141◆ NetBackup software ........................................................................ 145◆ FSM tools........................................................................................... 150◆ Snapshots with SnapView .............................................................. 154◆ Import data from SM to FSM ......................................................... 158

Backup and Recovery


Backup and Recovery

Data to back upData that exists solely in UTDM file systems should be backed up regularly to guard against loss caused by inadvertent data deletions or hardware failure. However, migrated data is protected by the back-end system and does not need to be backed up through the file system.

When you create a backup strategy for FSM, consider the types of files and data that make up the management domain. These can be generally grouped into the following types:

◆ FSM-related files outside of UTDM file systems

◆ Files and data in UTDM file systems

FSM-related files outside of UTDM file systemsAt a minimum, the following FSM-related files and directories should be backed up and recovered by using normal backup and recovery methods:

◆ All of /opt/fsm/etc and its subdirectories

◆ /etc/dxuldm.path

◆ /etc/fsm.path

An existing FSM installation can be recovered by reinstalling the software and restoring these files and directories from backup sets.

CAUTION!If the FSM software must be reinstalled, complete the reinstall before restoring the FSM-related files from backups. This prevents the reinstalled software from overwriting the backup versions of files.

Data to back up 125

Backup and Recovery

Files and data in UTDM file systemsInclude the following data in backups of UTDM file systems:

◆ Unmigrated file data

◆ Stub data for migrated files

◆ Metadata for all files in the file system

◆ .DMATTR_STAT file present in the root of the UTDM filesystem, which contains the FSM statistical information for the corresponding file system.

The backup software described in this chapter automatically includes these entities and excludes unnecessary data from backup sets.


Backup and Recovery

Backup softwareThe backup software described in Table 36 on page 126 may be used when backing up and recovering data in FSM file systems.

IMPORTANT!Centera data retention can prevent the use of incremental backups to restore some files to a UTDM file system. “Restoring incremental backups” on page 115 explains how to work around this expected limitation.

FSM-aware backup softwareEMC NetWorker (except for NetWorker, 64-bit Linux version) and FSM backup tools are FSM-aware, and do not cause migrated data to be included in the backup set. Excluding migrated data results in the following advantages:

◆ Shorter backup sessions

◆ Smaller backup sets

◆ Significantly less network traffic

Table 36 Supported backup software

Backup software Usage notes

EMC Avamar® version 5.0 SP2 (5.0.2-41)

All FSM-supported platforms.

EMC NetWorker®, release 7.6.x, UNIX version, 64-bit

All FSM-supported 64-bit platforms, except Linux.EMC NetWorker, release 7.6.x, 64-bit Linux version is not FSM-aware. “EMC NetWorker 64-bit Linux version” on page 141 describes how to use it to back up and recover FSM file systems.

Veritas NetBackup Server version 7 All FSM-supported platforms.Standard backups only.

FSM backup tools All FSM-supported platforms.

EMC SnapView™ Snapshots on all FSM-supported versions of HP-UX and Solaris.

Backup software 127

Backup and Recovery

Other backup softwareAs described in Table 36 on page 126, FSM works with the following backup software that is not FSM-aware:

◆ NetWorker, 64-bit Linux version

◆ Veritas NetBackup

◆ EMC Avamar

When these products are used to back up a UTDM file system, FSM uses its integrated third-party backup support to transparently exclude migrated data from the backup set.

Snapshot softwareUTDM file systems can be backed up by using SnapView software. Since only the UTDM file system is included in a snapshot, SnapView does not back up purged data.


Backup and Recovery

Recovering a lost file systemA backup set for a UTDM file system is restored into the existing file system. However, when the file system is lost this cannot be done. The UTDM file system must be replaced. After the file system is replaced, the backup set can be restored into it and the UTDM file system recovered.

Note: Because a snapshot is a complete copy of the disk partition, it is not necessary to perform the steps listed in this section when you use a SnapView snapshot to restore a lost file system. The lost UTDM file system is replaced when the snapshot is restored.

Until version 3.5, FSM stored statistical data information, such as the data migrated to the primary backup or purged data, in shared memory. After a system reboot, the FSM statistics were lost.

Release 3.5 SP1 adds a statistical file called the .DMATTR_STAT that duplicates statistical data available in the shared memory. The statistical data available on the shared memory is now updated on the .DMATTR_STAT file too. Now although the data in the shared memory is lost, it is automatically restored because the data exists in the .DMATTR_STAT file. This process happens seamlessly without any user intervention. Therefore, backing-up the .DMATTR_STAT file is required to get the persistent FSM statistics after restoring the lost file system.

To replace a lost UTDM file system:

1. Create a native file system of the same type and same capacity (or greater) as the lost file system.

2. If any of the following are lost, restore them from normal backup sets:

• All of /opt/fsm/etc and its sub-directories

• /etc/dxuldm.path

• /etc/fsm.path

Note: A restored UTDM file system must use the same back-end information as the lost file system. This information is contained in files that exist in /opt/fsm/etc and its sub-directories. By restoring these files, you ensure that the recovered UTDM file system can access its back-end data.

Recovering a lost file system 129

Backup and Recovery

3. Initialize it for UTDM by creating .DMATTR and .DMATTR_STAT.

The installation guides provide information on creating the .DMATTR and .DMATTR_STAT.

4. Recover the persistent statistics of the lost FSM file system.

• “Recovering persistent statistics with EMC Avamar” on page 135

• “Recovering persistent statistics with EMC NetWorker 64-bit Linux version” on page 143

• “Recovering persistent statistics with NetBackup software” on page 148

• “Recovering persistent statistics with FSM tools” on page 153

5. Complete the appropriate procedure to restore the file system from its backup sets:

• “Recovery with Avamar software” on page 134

• “Recovery with NetWorker software” on page 138

• “Recovery with NetBackup software” on page 148

• “Recovery with FSM tools” on page 151


Backup and Recovery

Recovering an FTP module file systemA file system that uses the FTP module with the native FTP protocol cannot create hard links to the data on the back-end system after recovery. This is because the standard FTP command set does not provide the necessary control over the back-end file system.

Instead, after the file system has been restored from backup, the file system recovery is completed by mounting the back-end system by using NFS or a similar protocol that provides local disk-like access.

To recover a file system that uses the FTP module with the native FTP protocol:

1. Restore the file system by using the appropriate recovery method for the software that created the backup.

2. By using NFS, or a similar protocol, mount the back-end file system on the FSM host.

3. Use Console Client to edit the file system configuration:

• Change the Backend Type to NFS.

• Change the Target Path to the local mount point of the back-end file system.

4. Log in to the FSM host as root.



6. Run the dmattrrecoverfs tool:

dmattrrecoverfs -p dirpath [-i threads]

where:

• dirpath is full path of the managed file system.

• threads is the number of parallel forked threads that dmattrrecoverfs can start.

Appendix A, “Command Reference,” provides more information on the dmattrrecoverfs tool.

Recovering an FTP module file system 131

Backup and Recovery

7. After dmattrrecoverfs has finished the synchronization, use Console Client to edit the file system and return it to its original configuration.

The recovery is complete.


Backup and Recovery

EMC AvamarEMC Avamar is not FSM-aware. FSM version 3.5 SP1 introduces support for EMC Avamar.

EMC Avamar is a backup and recovery solution that utilizes the patented data de-duplication technology to identify redundant data at the source. It, thereby, reduces redundant data before it is transmitted through the local area network (LAN) or wide area network (WAN). Avamar de-duplicated backups function like full backups and can be recovered in just one step, without restoring full backups and subsequent incrementals.

EMC Avamar requirementsTo use Avamar software to back up UTDM file systems, the following requirements must be met:

◆ One of the following software versions must be used:

• EMC Avamar Server version 5.0 SP2 (5.0.2-41)

◆ Only standard backups may be run.

◆ To view UTDM filesystem from Avamar Server, update /var/avamar/avtar.cmd file with “--forcefs=utdm" so that Avamar recognizes UTDM filesystem.

◆ The file /opt/fsm/etc/backupcmds must contain the names of the Avamar backup commands.

◆ The file /opt/fsm/etc/restorecmds must contain the names of the Avamar restore commands.

◆ The .DMATTR file can be excluded from the Avamar backup using the Avamar mcgui or mccli commands.

Preparing to useAvamar software

To prepare to use Avamar software:

1. Install the Avamar software.




EMC Avamar 133

Backup and Recovery

4. Exclude the .DMATTR file from backup using mccli or mcgui. Refer EMC Avamar documentation for more details.

5. Change the working directory:

cd /opt/fsm/etc

6. Copy backupcmds.default to backupcmds:

• For Linux platforms - cp backupcmds.default.linux-emt64 backupcmds

• For other platforms - cp backupcmds.default backupcmds

7. Copy the appropriate restorecmds.default file to restorecmds:

cp restorecmds.default.platform restorecmds

where platform is one of the following operating systems for the FSM host:

• aix_solaris for AIX and Solaris

• hpux_linux for HP-UX

• linux_emt64 for Linux

8. Restart FSM to load the contents of backupcmds and restorecmds into the kernel:

kill.fsmrc.fsm

The core processes are stopped and restarted, and the names of the Avamar commands are loaded into the kernel.

User-initiated backupand restore

User-initiated backups and restores are those that are started on a client node. These backups and restores do not check the exclude_list file. The .DMATTR files can be manually excluded from these backups by using the flag --exclude with avtar command. The Avamar documentation provides more information about user-initiated backups and restores.

Note: A user-initiated restore of a .DMATTR file will fail with an error message. If the .DMATTR files are not excluded from a user-initiated backup, they must be excluded from a user-initiated restore. To do this, refer to the Avamar documentation.


Backup and Recovery

Backup with Avamar softwareAfter the requirements described in “EMC Avamar requirements” on page 132 and “Preparing to use Avamar software” on page 132 are met, a backup of a UTDM file system by using Avamar software is the same as a backup of any other file system that uses a standard backup.

During a backup, FSM creates one or more DMAPI sessions and associates files with those sessions. A cron job is run every 10 minutes to start the utility utdm_backupcleanup to clean up those sessions. This cron job is installed in root’s crontab when FSM is installed. This activity is transparent to file system operations.

Backup sessions may be viewed by using the FSM tool prtdmsession. The output for a backup session takes the following form:

BACKUP filesystem PID ParentPID avtar.bin

where:

◆ filesystem is the name of the UTDM file system.

◆ PID is the process ID for the session.

◆ ParentPID is the parent process ID.

◆ avtar.bin is the name of the Avamar command.

For more information about using prtdmsession, see “prtdmsession” on page 197.

Recovery with Avamar softwareAfter the requirements described in “EMC Avamar requirements” on page 132 and “Preparing to use Avamar software” on page 132 are met, recovery of a UTDM file system by using Avamar software is the same as the recovery of any other file system.

Note: If the .DMATTR_STAT file is part of a backup set then, it must be excluded from the restore.

The FSM metadata for each recovered file has the recover bit set. When a file with the recover bit set is accessed, it is automatically synchronized.

The dmattrrecoverfs tool is also started by an hourly cron job that is installed in root’s crontab. When dmattrrecoverfs is started, it scans

EMC Avamar 135

Backup and Recovery

the file system for files with the recover bit set and synchronizes any it finds.

During a recovery, FSM creates one or more DMAPI sessions and associates files with those sessions. A cron job is run every 10 minutes to start the utility utdm_backupcleanup to clean up those sessions.

Recovery sessions may be viewed by using the FSM tool prtdmsession. The output for a recovery session takes the following form:

RESTORE filesystem PID ParentPID avtar.bin

where:




◆ avtar is the name of the Avamar command.

“prtdmsession” on page 197 provides more information about using prtdmsession.

Recovering persistent statistics with EMC AvamarTo recover persistent statistics:




3. Mount the filesystem as native filesystem.

4. Change the current working directory to the root of the file system that is being restored.

5. Recover the .DMATTR_STAT file to the root of the filesystem from the backup set using EMC Avamar.

6. Unmount the filesystem.

7. Mount the filesystem as an UTDM filesystem.

8. Stop all FSM processes and restart with new information by using the following commands:


Backup and Recovery

kill.fsmrc.fsm

9. Run the dxstat command to get the persistent statistics.

“dxstat” on page 197 provides information on the command.

EMC NetWorker 137

Backup and Recovery

EMC NetWorkerEMC NetWorker is FSM-aware. This sophisticated backup tool detects an FSM file system and performs an intelligent backup of all data and metadata in the file system. These backups do not trigger any staging of data from the back-end system.

In the event that data recovery is required, this software restores the backed-up data and initiates a background process that reestablishes all links between restored metadata and data existing on the file system’s back-end system. This background process is called synchronization.

IMPORTANT!EMC NetWorker, 64-bit Linux version is not FSM-aware. “EMC NetWorker 64-bit Linux version” on page 141 describes how to back up an FSM file system on this platform.

RequirementsTo use NetWorker for backup and recovery of FSM file systems, the required path information and permissions must be available.

Path information To back up an FSM file system by using this software, the file /etc/fsm.path must exist on the file system’s host. This file is automatically created during FSM installation and should not be removed.

Permissions The nsrexecd daemon controls automated backup and recovery operations of file systems. It is configured with permission to set its user ID as root (suid root). This permission is required for backup and recovery of FSM file systems and should not be changed.

Note: Manual NetWorker backup and recovery operations must be performed with root permissions.

Backup with NetWorker softwareNetWorker backups of FSM file systems are performed just like NetWorker backups of any other file system. The software automatically detects FSM file systems and performs automatic and


Backup and Recovery

manual backups without triggering data retrieval from the back-end system.

A full backup set for a FSM file system consists of the following:

◆ Unmigrated file data

◆ Stub data for migrated files

◆ Metadata for all files in the file system

The size of backup sets is significantly reduced. Only the metadata for successfully migrated files is backed up.

Note: Migrated file data is recovered by using the metadata backup and the data objects stored on the back-end system.

The .DMATTR file is normally included in the save set created by the NetWorker software. This file can become quite large and does not need to be backed up. It is a volatile file and is completely re-created during recovery.

Note: The .DMATTR_STAT file cannot be backed up by EMC NetWorker versions, which are FSM-aware.

To prevent these files from being backed up:

1. Use the Application Specific Module (ASM) called Skip to create a directive that excludes the .DMATTR and .DMATTR_STAT files from the save set.

2. During creation of the save set, select the directive in the Directives attribute of the Create Client window.

Note: The NetWorker documentation provides more information on creating NetWorker directives and applying directives to save sets.

Recovery with NetWorker softwareNetWorker recovery of an FSM file system is performed just like NetWorker recovery of any other file system. The entire file system, or just one or more files, may be recovered.

When the software restores file data to an FSM file system, the file system’s metadata is automatically synchronized with the data on the

EMC NetWorker 139

Backup and Recovery

back-end system. This synchronization process ensures full access to files that are purged at the time of the backup.

Note: Recovery of file system statistics is not supported for all NetWorker versions which are FSM-aware because they do not support backup of .DMATTR_STAT file.

The following steps describe the synchronization process:

1. A partial or complete recovery of a FSM file system is performed.

After the recovery, the following data is immediately available:

• Unmigrated file data

• Stub data

• Metadata

Note: Migrated data becomes available as it is synchronized by the cron job described in step 3.

2. As the NetWorker software performs the file system recovery, it automatically lists each recovered file’s pathname in a file called rec.date.pid, where:

• date is the current date.

• pid is the process ID associated with the NetWorker client process.

The rec.date.pid file exists on the FSM host system in the /opt/fsm/adm/recdir directory.

3. A cron job periodically checks the rec.date.pid file for recovered files, and synchronizes each file it finds.

During installation of FSM, a cron job is installed in root’s crontab. This job checks the rec.date.pid file for recovered file entries. When a recovered file entry is found, a background synchronization process starts to synchronize the file’s metadata and data.

After the file is synchronized, the file entry is removed from the rec.date.pid file and the file’s data is accessible through the file system.


Backup and Recovery

After a NetWorker recovery, the file system is immediately available to be used. However, the full data for a file that has been migrated is not available until synchronization of the file is complete.

You can shorten the time required to synchronize and access a recovered file by performing a manual synchronization that uses the dxuldmrecover command. Appendix A, “Command Reference,” provides more information on this command.

Backups must be restored into a file system that uses the same back-end system as the original file system. This provides access to the data stored on the back-end system.

EMC NetWorker 64-bit Linux version 141

Backup and Recovery

EMC NetWorker 64-bit Linux versionEMC 64-bit Linux version software is not FSM-aware. However, new technology in this release enables FSM to detect that this software is being used and transparently exclude migrated data from the backup set.

RequirementsTo use NetWorker 64-bit Linux version software to back up UTDM file systems, the following requirements must be met:

◆ The file /opt/fsm/etc/backupcmds must exist.

◆ The file /opt/fsm/etc/restorecmds must exist.

Preparation To prepare to use NetWorker 64-bit Linux version software:

1. Install the NetWorker software.





cd /opt/fsm/etc

5. Create the backupcmds file:

cp backupcmds.default.Linux-emt64 backupcmds

6. Create the restorecmds file:

cp restorecmds.default.Linux-emt64 restorecmds

7. Use the NetWorker Application Specific Module (ASM) "Skip" to create a directive that excludes the .DMATTR file from the save set.

Note: The .DMATTR_STAT file should also be included in the backup if persistent FSM statistics is needed after restore.

8. During creation of the save set, select the directive in the Directives attribute of the Create Client window.


Backup and Recovery

9. Load backupcmds and restorecmds into the kernel:

kill.fsmrc.fsm

The core processes are stopped and restarted with the new information.

Backup with EMC NetWorker 64-bit Linux versionAfter the requirements described in “Requirements” on page 141 and “Preparation” on page 141 are met, a backup of a UTDM file system by using NetWorker software is the same as a backup of any other file system that uses a standard backup.



BACKUP filesystem PID ParentPID NWCommand

where:




◆ NWCommand is the name of the NetWorker command.


Recovery with EMC NetWorker 64-bit Linux versionAfter the requirements described in “Requirements” on page 141 and “Preparation” on page 141 are met, recovery of a UTDM file system by using NetWorker software is the same as the recovery of any other file system.

If the .DMATTR_STAT is part of a backup set, then the .DMATTR_STAT file should be excluded from restore. The FSM metadata for each recovered file has the recover bit set. When a file with the recover bit set is

EMC NetWorker 64-bit Linux version 143

Backup and Recovery

accessed it is automatically synchronized. The dmattrrecoverfs tool is also started by an hourly cron job that is installed in root’s crontab. When dmattrrecoverfs is started, it scans the file system for files with the recover bit set and synchronizes any it finds.



RESTORE filesystem PID ParentPID NWCommand

where:




◆ NWCommand is the name of the NetWorker command.


Recovering persistent statistics with EMC NetWorker 64-bit Linux versionTo recover persistent statistics:




3. Mount the file system as native file system.


5. Recover the .DMATTR_STAT file to the root of the file system from the backup set using EMC NetWorker.

6. Unmount the file system.

7. Mount the file system as an UTDM file system.


Backup and Recovery


kill.fsmrc.fsm

9. Run the dxstat command to verify the FSM statistics are recovered.


NetBackup software 145

Backup and Recovery

NetBackup softwareNetBackup software is not FSM-aware. However, FSM detects that NetBackup software is used and transparently excludes migrated data and the .DMATTR file from the backup set.

FSM detects a NetBackup backup or restore operation by comparing the NetBackup commands that access FSM files to command names written in the files backupcmds and restorecmds. FSM installation places default versions of these files in the /opt/fsm/etc directory (where /opt/fsm is the full path to the FSM installation directory). These default versions can be used to create the files backupcmds and restorecmds for use with NetBackup.

NetBackup requirements◆ To use NetBackup software to back up UTDM file systems, the

following requirements must be met: Only standard backups may be run.

For example, the FlashBackup package is not supported.

◆ The file /opt/fsm/etc/backupcmds must contain the names of the NetBackup backup commands.

◆ The file /opt/fsm/etc/restorecmds must contain the names of the NetBackup restore commands.

◆ Each NetBackup client machine must have its .DMATTR files listed in the file /usr/openv/netbackup/exclude_list.

The .DMATTR file is not needed to restore files from a NetBackup backup.

The .DMATTR_STAT file must be included in the NetBackup backup to recover persistent statistics.

Preparing to use NetBackup softwareTo prepare to use NetBackup software:

1. Install the NetBackup software.





Backup and Recovery

4. Add the full path for each .DMATTR file on the FSM host to the NetBackup exclude_list file:

echo "/dmattrpath" >> /usr/openv/netbackup/exclude_list

where /dmattrpath is the full path to one of the .DMATTR files on the FSM host.

Repeat this command for each .DMATTR file on the FSM host.

Example 5 on page 146 provides more information.


cd /opt/fsm/etc

6. Copy backupcmds.default to backupcmds:

• For Linux platforms - cp backupcmds.default.linux-emt64 backupcmds

• For other platforms - cp backupcmds.default backupcmds

7. Copy the appropriate restorecmds.default file to restorecmds:

cp restorecmds.default.platform restorecmds

where platform is one of the following operating systems for the FSM host:

• aix_solaris for AIX and Solaris

• hpux_linux for HP-UX

• linux_emt64 for Linux

8. Restart FSM to load the contents of backupcmds and restorecmds into the kernel:

kill.fsmrc.fsm

The core processes are stopped and restarted, and the names of the NetBackup commands are loaded into the kernel.

Example 5 Adding files to the exclude_list file

An FSM host has two UTDM file systems with the following pathnames:

◆ /mnt/utdm_fs1

◆ /mnt/utdm_fs2


Backup and Recovery

Run the following commands to add the two .DMATTR files to the exclude_list:

echo "/mnt/utdm_fs1/.DMATTR" >> /usr/openv/netbackup/exclude_listecho "/mnt/utdm_fs2/.DMATTR" >> /usr/openv/netbackup/exclude_list

User-initiated backupand restore

User-initiated backups and restores are those that are started on a client node. These backups and restores do not check the exclude_list file. The .DMATTR files can be manually excluded from these backups. The NetBackup documentation provides more information about user-initiated backups and restores.

Note: A user-initiated restore of a .DMATTR file will fail with an error message. If the .DMATTR files are not excluded from a user-initiated backup, they must be excluded from a user-initiated restore. More formation is provided in the NetBackup documentation.

Backup with NetBackup softwareAfter the requirements described in “NetBackup requirements” on page 145 and “Preparing to use NetBackup software” on page 145 are met, a backup of a UTDM file system by using NetBackup software is the same as a backup of any other file system that uses a standard backup.



BACKUP filesystem PID ParentPID NBCommand

where:




◆ NBCommand is the name of the NetBackup command.



Backup and Recovery

Recovery with NetBackup softwareAfter the requirements described in “NetBackup requirements” on page 145 and “Preparing to use NetBackup software” on page 145 are met, recovery of a UTDM file system by using NetBackup software is the same as the recovery of any other file system.

If the .DMATTR_STAT file is part of a backup set, then the .DMATTR_STAT file must be excluded from restore. The FSM metadata for each recovered file has the recover bit set. When a file with the recover bit set is accessed, it is automatically synchronized.

The dmattrrecoverfs tool is also started by an hourly cron job that is installed in root’s crontab. When dmattrrecoverfs is started, it scans the file system for files with the recover bit set and synchronizes any it finds.



RESTORE filesystem PID ParentPID NBCommand

where:




◆ NBCommand is the name of the NetBackup command.


Recovering persistent statistics with NetBackup softwareTo recover persistent statistics:





Backup and Recovery

3. Mount the file system as native file system.


5. Recover the .DMATTR_STAT file to the root of the file system from the backup set using NetBackup.




kill.fsmrc.fsm




Backup and Recovery

FSM toolsFSM includes tools that perform basic backup and recovery operations for FSM file systems. These tools can be used to:

◆ Back up a file system, without triggering data retrieval.

◆ Partially or completely recover a file system’s data.

◆ Synchronize recovered metadata with data on the back-end system.

The tools are located in the /opt/fsm/adm/bin directory.

Backup with FSM toolsTo manually back up an FSM file system, use dxuldm_tar. This tool is based on tar and includes the ability to back up data in an FSM file system without triggering data retrieval.

The .DMATTR_STAT file must be included in the backup if persistent FSM statistics is needed after restore. When using dxuldm_tar, the .DMATTR file should be excluded from the backup by using the --exclude option. The .DMATTR file is rebuilt during recovery so backing it up is unnecessary.

Note: The .DMATTR can become quite large. Excluding it can significantly decrease the time required to back up a file system.

Backing up a filesystem with FSM tools

To manually create a full backup of a file system:




3. Change the current working directory to the root of the file system that is being backed up.

FSM tools 151

Backup and Recovery

4. Run dxuldm_tar:

dxuldm_tar --exclude=.DMATTR -cvf tarfile

where tarfile is the full pathname of the backup archive file.

The period at the end of the command indicates that the backup should include all files in the current working directory and all subdirectories.

If the command is run from the root of the file system, then run the following command:

dxuldm_tar --exclude=.DMATTR -cvf tarfile <UTDM filesystem mount dir>/* <UTDM file system mount dir>/ .DMATTR_STAT

where tarfile is the full pathname of the backup archive file and <UTDM file system mount dir> is the mount directory of the UTDM file system.

Recovery with FSM toolsRecovery of a file system consists of the following tasks:

◆ Restore the data to the file system.

◆ Synchronize the file system’s metadata with the data stored on the back-end system.

Table 37 on page 151 shows the task performed by each FSM tool during recovery.

Users may access a file system as soon as dxuldm_tar finishes a recovery. The FSM metadata for each recovered file has the recover bit set. When a file with the recover bit set is accessed, it is automatically synchronized.

The dmattrrecoverfs tool is also started by an hourly cron job that is installed in root’s crontab. When dmattrrecoverfs is started, it scans

Table 37 FSM recovery commands

Task Command

To recover a file system, directory, or individual file. dxuldm_tar

To scan file system for files with the recover bit set and synchronize all of the data for those files with the data on the back-end system.

dmattrrecoverfs


Backup and Recovery

the file system for files with the recover bit set and synchronizes any it finds.

Recovering a filesystem with FSM tools

To recover a file system:





4. Run dxuldm_tar:

dxuldm_tar -xvf tarfile

where tarfile represents the full path of the file system’s backup file.

If the .DMATTR_STAT file is part of a backup set, run:

dxuldm_tar --exclude=.DMATTR_STAT -xvf tarfileThe dxuldm_tar command extracts the entire backup archive into the current directory, maintaining the original file system structure.

The file system is recovered. Data for files is synchronized automatically by dmattrrecoverfs which is started by the script dxuldmhourlycronscript. The script dxuldmhourlycronscript is started by an hourly cron job that is installed in root’s crontab when FSM is installed.

Recovered files may be accessed immediately. When a recovered file that has not been synchronized is accessed, it is automatically synchronized.

Recovering individualfiles with FSM

commands

To recover a file:




3. Change the current working directory to the root of the file system that was backed up.

4. Run dxuldm_tar:

FSM tools 153

Backup and Recovery

dxuldm_tar -xvf tarfile rel-filepath

where:

• tarfile represents the full path of the backup file.

• rel-filepath represents the relative path of the file being restored (relative to the root of the file system that was backed up).

The file is recovered and may be accessed immediately. A recovered file that has not been synchronized is automatically synchronized when it is accessed.

Recovering persistent statistics with FSM toolsTo recover persistent statistics:




3. Mount the filesystem as native filesystem.

4. Change the current working directory to the root of the file system that is being restored and run the following command:

dxuldm_tar -xvf tarfile .DMATTR_STAT




kill.fsmrc.fsm




Backup and Recovery

Snapshots with SnapViewThis release provides three tools to support snapshots of UTDM file systems with SnapView. The tools do the following:

◆ Quiesce a mounted UTDM file system to permit a snapshot to be created.

◆ Resume the UTDM file system activity after a snapshot is created.

◆ Set the recover bit on all migrated files in a restored snapshot.

The SnapView documentation provides more information on creating and restoring a snapshot.

Note: The ability to produce SnapView snapshots of UTDM file systems is not available on all of the operating systems that are supported by this release. The release notes provide an up-to-date list of the operating systems on which it is available.

“Setting the FSM environment” on page 185 describes how to set the FSM environment.

Quiescing a UTDM file systemThe FSM tool, utdm_fs_freeze, quiesces mounted UTDM file systems for a specified number of seconds. This causes the following:

◆ Any thread waiting to access the file system is suspended.

◆ All current operations are concluded.

◆ A flush of any dirty buffers in the file system occurs.

◆ A stable image on the disk is created.

Use utdm_fs_freeze to prepare a mounted file system for a snapshot. This tool is not required when the file system is not mounted.

To quiesce a UTDM file system:



Snapshots with SnapView 155

Backup and Recovery

IMPORTANT!A snapshot must be completed before the file system resumes activity or it may be corrupt. Use the -t option for utdm_fs_freeze to specify sufficient time to complete the snapshot.

3. Run utdm_fs_freeze:

utdm_fs_freeze -t sec mountpoint

where:

• sec is the number of seconds to quiesce the file system.

This can be from 1 to the maximum time-out value. The default for the maximum time-out value is 300 seconds.

Note: The maximum time-out value can be changed by using the FSM tool, set_freeze_timeout.

• mountpoint is the full path of the directory on which the file system is mounted.

The SnapView snapshot may now be created.

File system activity automatically resumes after the number of seconds specified by the -t option. To resume file system activity before that time, use utdm_fs_thaw.

Determiningmaximum time-out

value

To determine the current maximum time-out value:



3. Run get_freeze_timeout:

get_freeze_timeout

The current maximum time-out value is displayed.

Setting the maximumtime-out value

To set the maximum time-out value:




Backup and Recovery

3. Run set_freeze_timeout:

set_freeze_timeout newtimeout

where newtimeout is the number of seconds of the new time-out value.

The maximum time-out value is changed to the new value.

Resuming UTDM file system activityThe FSM tool, utdm_fs_thaw, resumes activity for UTDM file systems that have been quiesced by using utdm_fs_freeze. After utdm_fs_thaw is run, all suspended threads are allowed to complete. This tool is used after a snapshot is created by using SnapView.

To resume activity on a UTDM file system:




3. Run utdm_fs_thaw:

utdm_fs_thaw mountpoint

where mountpoint is the full path of the directory on which the file system is mounted.

Recovering a UTDM file system snapshotThe FSM tool, utdm_recdmattrf, processes UTDM file systems that are restored from SnapView snapshots. The tool sets the recover bit on all migrated files in the recovered file system. When these files are accessed, the core processes create a new namespace for the files and reset the recover bits.

A new namespace for migrated files prevents conflicts that would occur if both the original and the restored file system accessed the back-end data from the same namespace.

To recover a UTDM file system snapshot:



Snapshots with SnapView 157

Backup and Recovery

3. Mount the file system that was recovered from a snapshot by using the file system’s native type, as shown in Table 38 on page 157.

The variables for the mount procedures are as follows:

• fstype is the native type of the file system (not utdm).

• blkdev is the full path to the file system’s block special device.

• mntpnt is the full path to the file system’s mount point.

4. Run utdm_recdmattrf:

utdm_recdmattrf /dmattrpath

where /dmattrpath is the full path to the .DMATTR file of the restored snapshot.

When the command prompt is returned (exit status 0), the restored UTDM file system snapshot is recovered.

5. Unmount the file system:

umount /mntpnt

6. Mount the file system as an utdm file system.

The appropriate operating system specific installation guide provides more information on mounting the file system.

Table 38 Mounting a file system for utdm_recdmattrf

Operating system Procedure

All operating systems, except Linux and AIX

As root, run the following mount command:mount-F fstype /blkdev /mntpnt

Linux As root, run the following mount command:mount-t fstype /blkdev /mntpnt

AIX As root, run the following mount command:mount-V fstype /blkdev /mntpnt


Backup and Recovery

Import data from SM to FSMEMC DiskXtender for UNIX/Linux Store Manager, which was a component of DiskXtender, provides a central data storage repository that utilizes a unified namespace and delivers shared file access by using FTP or NFS.

To import data from SM to FSM:

1. Install FSM with Centera as a backend. The installation guides provide more information on installing FSM.

2. Mount SM through NFS by using the following command:

mount -o intr,port=2050 137.69.XX.XX:/DISKXTENDER/ /tmp/IMPORT_DIR

3. To ensure the SM file system is mounted, type:

mount | grep DISKXTENDER

The following output is displayed:

137.69.XX.XXX:/DISKXTENDER/ on /tmp/IMPORT_DIR type nfs (rw,intr,port=2050,addr=137.69.44.XXX)

4. In the FSM system with SM mounted through NFS, change the directory to point to the SM mount point and perform the following to populate the UTDM file system with SM data:

a. Run the dxprtstat utility for all the files in SM. The output generated to a file in the local file system displays the DXUL-SM object attributes information that is necessary to load objects into a FSM file system.

Example:

dxprtstat -i {} \; > /tmp/dxprtstat.out

The following is an example of how the output appears:

PATH: /tmp/IMPORT_DIR/temp/100_100_R_001TYPE: FILEMODE: 0750SIZE: 1UID: 0GID: 0ATIME: 0x494128d4MTIME: 0x494128d4CTIME: 0x494128d4

Import data from SM to FSM 159

Backup and Recovery

FILETARGET: ./c5/93/abcdefab00004f5254f88da156fdd293@54f88da1@IMPORTPATH: /tmp/IMPORT_DIR/temp/100_100_R_002

b. Run the dxhardlink utility to create hard links in the SM directory HARDLINKSDIR for SM data that are imported to FSM.

Example:

dxhardlink -t /tmp/IMPORT_DIR/HARDLINKDIR < /tmp/dxprtstat.out

c. Run the dxbuildtar utility to generate a .tar file in the local file system.

Example:

dxbuildtar -f /tmp/dxbuildtar.tar -p /tmp/IMPORT_DIR/ < /tmp/dxprtstat.out

The output of the .tar file looks like the SM file system directory structure as below:

…-rwxr-x--- root/root 1024 2008-12-11 14:51:00 ./temp/100_100_R_004-rwxr-x--- root/root 1024 2008-12-11 14:51:00 ./temp/100_100_R_005-rwxr-x--- root/root 1024 2008-12-11 14:51:00 ./temp/100_100_R_006-rwxr-x--- root/root 1024 2008-12-11 14:51:00 ./temp/100_100_R_007-rwxr-x--- root/root 1024 2008-12-11 14:51:00 ./temp/100_100_R_008

d. Change the working directory to FSM File directory. Run the dxdmimport utility to load objects to an FSM file system from a tar file:

/opt/fsm/adm/smtodm/dxdmimport -xUvf /tmp/dxbuildtar.tar

Imported files in FSM will not look the same as normal files in FSM. The following is an example of how a getfileattr on a file that is just imported would appear:

getfileattr ./100_100_R_001dt_path: /mnt/utdm/2SMRESTORZE/temp/./100_100_R_001


Backup and Recovery

dt_handle: 32-F9C57356476C4F4823380000000000007AC1C380000000000102000000000000dt_ino: 14371dt_mode: FILE 750dt_nlink: 1dt_uid: 0dt_gid: 0dt_size: 1dt_atime: 1425659730 Fri 06 Mar 2015 04:35:30 PM UTCdt_mtime: 1229007060 Thu 11 Dec 2008 02:51:00 PM UTCdt_ctime: 1425659730 Fri 06 Mar 2015 04:35:30 PM UTCdt_blksize: 4096dt_blocks: 0dmattr0: usiversn (UVDM 1.1)dmattr1: usiismig (1)dmattr2: usiispur (1)dmattr3: usifilev (1)dmattr4: usiopath (./c5/93/abcdefab00004f5254f88da156fdd293@54f88da1@IMPORT)dmattr5: usimtime (494128d4)dmattr6: usimigct (494128d4)dmattr7: usipurtm (494128d4)numregions: 1regoff0: 0 regsz0: 0 regflg0: rwtApplFlags: MIGRATED|PURGED|IMPORT_PENDINGRevPath: 2SMRESTORZE/temp/100_100_R_001

5. Stop the FSM services and edit the DXULDM.conf file.

For FTP, add the following:

IMP_0_MODULE:1:FTPIMP_0_FTPHOST:1:137.69.44.XXXIMP_0_FTPPORT:1:1021IMP_0_FTPUSER:1:rootIMP_0_FTPPASSWORD:1:foobarIMP_0_FTPDIRECT:1:On IMP_0_TARGET:1:<path where the hardlinks are created in SM in step b >

For NFS, add the following:

IMP_0_MODULE:1:NFSIMP_0_TARGET: <path where the SM NFS is mounted>

6. Restart the FSM services.

The file system is imported. Attempting to read data with import_pending flag will automatically move the whole data from SM to FSM by dxuldmimportfs which is started by the script

Import data from SM to FSM 161

Backup and Recovery

dxuldmhourlycronscript. The script dxuldmhourlycronscript is started by an hourly cron job that is installed in root’s crontab when FSM is installed.

Note: Do not use the FSM GUI for any FSM configuration changes until all SM data is migrated to FSM or Centera. FSM GUI does not understand the new parameters entered in the DXULDM.conf file and any trigger to rewrite or update will result in loss of information in the DXULDM.conf file.


Backup and Recovery

Maintenance 163

8


◆ Processes............................................................................................ 164◆ File administration........................................................................... 172◆ Periodic back-end system cleanup ................................................ 175

Maintenance


Maintenance

ProcessesFSM consists of the following general categories of processes:

◆ “Core processes” on page 164

◆ “Console processes” on page 169

Core processesThe FSM core processes do the following:

◆ Monitor the status of file systems.

◆ Migrate file data to the back-end system.

◆ Purge file data from file systems.

◆ Retrieve data from the back-end system.

◆ Provide file system information to Console Agent.

◆ Perform task requested by Console Agent.

For each managed file system, the following core processes are started:

◆ Two migpurged processes

◆ Two uvdmigd processes

The migpurgedprocess

A migpurged process monitors each file system to determine when to do the following:

◆ Migrate file data

◆ Purge file data

The parameters of the monitoring that migpurged performs vary based on the file system’s configuration.

Two migpurged processes start for each file system:

◆ The first process is a persistence daemon and restarts the primary daemon as needed.

◆ The second process is the primary daemon and performs the file system management tasks.

The uvdmigd process The uvdmigd process ensures that migrated and purged file data is available as needed. When a request is made for file data that resides on the Centera system, the uvdmigd process:

Processes 165

Maintenance

◆ Calls the migin process to retrieve the data

◆ Monitors the retrieval

◆ Notifies the system that the data is available

Two uvdmigd processes are started for each file system:

◆ The first process is a persistence daemon and restarts the primary daemon as needed.

◆ The second process is the primary daemon and performs the file system management tasks.

During a data retrieval, the requesting process waits until sufficient data is retrieved for its operation to complete. Other processes seeking access to the same data also wait. Processes initiating operations that require data already in the file system proceed without delay.

Deleted filesThe uvdmigd process monitors the file system for files that are removed by users. When a migrated file is deleted from the file system, uvdmigd calls the migdestroy process. The migdestroy process sets a flag on the back-end system to indicate that the file has been deleted from the file system. The indicator that is used varies depending upon the type of back-end system.

Centera systemWhen a file is deleted from a file system that uses a Centera system back-end system, a flag is set in each of the C-Clips for the file. The flag is used to indicate that the file has been deleted from the file system.

The file’s data and C-Clips remain on the Centera system until removed by an administrator. “Centera system” on page 176 provides more information.

FTP or NFS module back-end systemWhen a file is deleted from a file system that uses either an FTP or NFS module back-end system, the migdestroy process renames the file on the back-end system by appending the extension .deleted to the filename.

These renamed files remain on the back-end system until removed by an administrator. “Cleanup on FTP or NFS module back-end systems” on page 178 provides more information.


Maintenance

Starting and stoppingcore processes

FSM is designed to start when the host system boots up, and to stop when the host system shuts down.

During installation, the rc.fsm script is placed in the host system’s startup directory to provide for an orderly startup when the host is booted. The rc.fsm script can also be used to start the FSM processes manually as described in “Manually starting core processes” on page 166.

Commands contained in the rc.fsm script perform initialization tasks and start the processes. The script does the following:

◆ Parses the configuration file to determine the following:

• File systems to manage

• Configuration settings for each file system

◆ Starts the core processes for each file system.

◆ Starts Console Agent and, if present on the host, Console Server.

During installation, the kill.fsm script is placed in the host system’s shutdown directory to provide for an orderly shutdown of the core processes when the host is shutdown. The kill.fsm script can also be used to stop the FSM processes manually as described in “Stopping FSM processes” on page 167.

Setting the FSM environmentMost FSM command-line tasks require that you set the FSM environment before running the command. “Setting the FSM environment” on page 185 provides more information.

Manually starting core processesAn administrator may start the core processes manually by using the rc.fsm script.

When installed as recommended, FSM starts automatically each time the system boots up. This is the preferred method of starting the core processes. It ensures that the environment is set up properly, and the required processes are started for every file system.

IMPORTANT!All UTDM file systems must be mounted before running rc.fsm. Normally these file systems are mounted by using the file system table file during boot up.

Processes 167

Maintenance

Manually starting the core processesTo manually start the core processes:




3. Run the rc.fsm script:

/opt/fsm/etc/rc.fsm

The core processes start for each file system.

Stopping FSM processesWhen installed as recommended, FSM stops automatically each time the system shuts down. This is the preferred method of stopping the FSM processes. It ensures that for every file system that is being managed, all pending tasks are completed before shutdown occurs.

Manually stopping processesAn administrator can manually stop the core processes by using the kill.fsm script.

Effect of manually stopping processes

The core processes should rarely be stopped. Stopping the processes results in an inability to migrate data to, retrieve data from, and manage data on the back-end system. Requests that involve any of these tasks remain pending until the required process is restarted. After the process is restarted, pending requests complete.

Note: When it is necessary to stop the core processes, such as when a file system must be unmounted, use the kill.fsm script. This script terminates all core processes for all file systems. Restart those processes as soon as possible, either by rebooting the system or by manually running the rc.fsm script.

Manually stopping the core processes

To manually stop the core processes:





Maintenance

3. Run the kill.fsm script:

/opt/fsm/etc/kill.fsm

All core processes on the host stop.

Note: The kill.fsm script does not unmount file systems. If the core processes for a file system will not be restarted, be sure to manually unmount that file system.

Monitoring coreprocesses

The performance of each process can be monitored through its log. All logs for core processes are located in /opt/fsm/adm/log. When a log reaches 10 MB, it is archived by appending a timestamp to its file name and creating a new log.

The timestamp that is appended to an archived log is in the following format:

.YYYYMMDDhhmmss

where:

◆ YYYY is the four-digit year.

◆ MM is the two-digit month.

◆ DD is the two-digit day.

◆ hh is the two-digit hour.

◆ mm is the two-digit minute.

◆ ss is the two-digit second.

Each file system has the following logs for its core processes:

◆ migpurged_fsid.t (current log)

◆ uvdmigd_fsid.t (current log)

◆ migpurged_fsid.t.timestamp (archived log)

◆ uvdmigd_fsid.t.timestamp (archived log)

where:

• fsid is the file system ID

• .timestamp is the timestamp of an archived log.

The logs are recorded in a tokenized text format to reduce their size. To view a log’s contents in a meaningful fashion, use the log viewing command, dx_read_log.

Processes 169

Maintenance

Note: An administrator may provide localized, custom log results by using the dx_read_log command. The command replaces tokens in a log with messages from the Common Message File (CMF) and the optional Site Message File (SMF). The SMF, if it exists, is searched first. The messages in the SMF file can be changed to provide users with custom log results.

Viewing a logTo use dx_read_log to view a log:




3. Run dx_read_log:

dx_read_log option -l /opt/fsm/adm/log/log-file

where:

• option is a viewing option.

• log-file is the name of the log.

Note: A detailed description of the options available for dx_read_log is available in “dx_read_log” on page 188.

Console processesThe FSM Console processes consist of the Console Server and the Console Agent.

The Console Server runs on one host in the management domain. It does the following:

◆ Maintains user accounts and roles

◆ Negotiates authentication between Console Client and Console Agents

The Console Agent runs on each FSM host. It provides the following:

◆ Initial authentication

◆ File system monitoring

◆ File system configuration


Maintenance

Starting and stoppingConsole processes

The Console processes start and stop automatically when the host’s core processes are started and stopped. You should not start or stop the Console processes any other way unless you are instructed to by the EMC Customer Support.

Monitoring Consoleprocesses

The performance of all Console Server and Console Agent processes is recorded in a log on the computer that hosts the process. The logs are located in the following directory:

/opt/fsm/logs

Console Server logThe Console Server log is named:

FSMConsoleServer.log

This log grows until it reaches the number of kilobytes specified by the value of the fsm.log.size parameter in the following file:

/opt/fsm/etc/FsmConsoleServer.properties

This value can be changed by editing the file to uncomment the parameter and change its value. The default is 5,000,000 KB.

When the maximum size is reached, the log is archived and a new log is started. Archived logs have a timestamp appended to their filename.

To reclaim space you can manually remove the archived logs.

Console Agent logThe Console Agent log is named:

FSMConsoleAgent.log

This log grows until it reaches the number of kilobytes specified by the value of the fsm.log.size parameter in the following file:

/opt/fsm/etc/FsmConsoleAgent.properties

This value can be changed by editing the file to uncomment the parameter and change its value. The default is 5,000,000 KB.

When the maximum size is reached, the log is archived and a new log is started. Archived logs have a timestamp appended to their filename.

To reclaim space you can manually remove the archived logs.

Processes 171

Maintenance

Command output logsBoth Console processes produce a second set of logs. These are the command output logs, which contain the messages that are normally displayed on a console.

The Console Server command output log is named:

FSMConsoleServer_log

The Console Agent command output log is named:

FSMConsoleAgent_log

These logs grow at a much slower rate, but their size is controlled by the same parameter as the Console Server log and the Console Agent log. To reclaim space you can manually remove the archived versions of these logs.


Maintenance

File administrationFSM provides tools to perform administrative tasks on individual files.

Manual migration, purge, and retrievalAn administrator can manually migrate, purge, and retrieve individual files as needed.

Manually migrating afile

To manually migrate a file:




3. Change the working directory to the directory that contains the file that you want to migrate.

4. Run migout:

migout filename

where filename is the name of the file.

Upon successful migration, migout displays the following message:

Successfully migrated file filename

Note: If this message does not appear, the file was not migrated.

Manually purging files To manually purge files:




3. Change the working directory to the directory that contains the file.

File administration 173

Maintenance

4. Run purge:

purge filename


Upon successful purging, purge displays the following message:

Successfully purged file filename.

Note: If this message does not appear, the file was not purged. Manual purging fails if the file’s Purge attribute has been set to NEVER, or if the file has not been migrated.For files which have not been migrated, the purge command displays the message: "File filename has not been migrated."

The successful completion of the purge operation can be verified by using the list command, ls -ls, on the file both before and after purging. The number of data blocks occupied by the file on the file system is less after successful purging.

Note: Only files that are eligible for purging can be manually purged. To be eligible for purging, a file must have been successfully migrated and must be unchanged since the migration. As expected, an attempt to purge a file that contains data that has not been migrated will fail.

Manually retrievingfiles

The uvdmigd process automatically retrieves a purged file when needed. Very large files can cause a noticeable time delay while the file data is retrieved. To manage this time delay, the large file can be retrieved in advance.

To manually retrieve files:




3. Change the working directory to the directory that contains the file.

4. Run the list command, ls -ls:

ls -ls filename



Maintenance

The number of blocks that the file occupies in the file system are displayed.

5. Run migin:

migin filename


6. Run the list command:

ls -ls filename


The number of blocks occupied by the file on the file system increases after the file’s data is successfully retrieved.

Periodic back-end system cleanup 175

Maintenance

Periodic back-end system cleanupFiles which have been deleted from a file system are not automatically removed from the back-end system. This permits the recovery of inadvertently removed files. Chapter 7, “Backup and Recovery,” provides more information on recovery.

When a user deletes or removes a file from a file system, the following occurs:

1. The uvdmigd process reads the file’s DMAPI attributes to determine if the file has been migrated.

2. If the file has been migrated, uvdmigd calls the migdestroy process.

3. The migdestroy process sets a flag on the back-end system to indicate that the file has been deleted from the file system.

The indicator that is used varies depending upon the type of back-end system.

Periodically, an administrator should make available for purging the deleted file data that is stored on the back-end system. This is called cleanup.

For the following back-end module types, cleanup may be scheduled to run automatically by using Console Client:

◆ Centera

◆ NFS

Chapter 5, “Scheduled Jobs,” and the online help describe this. Back-end systems that use the FTP module require manual cleanup.

On all back-end system types you may perform manual cleanup. This is described in the following sections:

◆ “Centera system” on page 176

◆ “Cleanup on FTP or NFS module back-end systems” on page 178

IMPORTANT!Only perform cleanup of data on the back-end system when you are sure that it is not needed. Purging data from the back-end system permanently removes it. This data cannot be recovered.


Maintenance

Centera systemFor file systems that use the Centera module, cleanup on the Centera system is performed from the FSM host by using the dxuldmdelclips command to identify and mark a range of files. Cleanup is performed simultaneously for all Centera module file systems on a host.

The dxuldmdelclips command must have query permission on the Centera system to perform its tasks. If the default permissions are changed to deny query permission for anonymous profiles, this permission must be provided through a PEA file.

The file system’s PEA file is identified through its Centera Profile Path value. “Preliminary tasks for Centera module” on page 45 provides more information.

Cleaning a Centerasystem

To clean up a Centera system:




3. Run dxuldmdelclips:

dxuldmdelclips -a emc-address[?/PEA-file] -v

where:

• emc-address is one of the IP addresses listed in the Connect Addresses value.

“Centera module” on page 64 provides more information.

• /PEA-file is the full path to a PEA file which provides read, write, exist, and query permissions.

Note: The ?/PEA-file portion of the command is included if authentication is required by the Centera system.

For all file systems, the file data that was deleted more than one year before the current date is marked for purging. All C-Clips, linked to the deleted files, are also marked.


Maintenance

This procedure is demonstrated in Example 6 on page 177.

Note: To mark the data for a specific range of files, follow the procedure described in “dxuldmdelclips” on page 193.

Example 6 Periodic Centera system cleanup

In this example, the following parameters are assumed:

◆ The Centera system has an IP address of 137.69.44.212.

◆ The Centera system administrator has provided a PEA file which provides read, write, exist, and query permissions.

◆ The PEA file is located at /etc/rweq.pea.

To clean up all files deleted more than a year ago, set the FSM environment and run the following command:

dxuldmdelclips -a 137.69.44.212?/etc/rweq.pea -v

Restarting the task The -v option to dxuldmdelclips causes the command to display status information after every 100 C-Clip deletions. This information may be used to restart the task if it stops prior to completion.

To restart an incomplete dxuldmdelclips task:

1. Note the last displayed timestamp from the incomplete dxuldmdelclips run.

The timestamp is displayed as seconds since the epoch.




4. Use dxuldmdelclips with the -t option:

dxuldmdelclips -a emc-address?/PEA-file -v -t starttime

where:

• emc-address is one of the IP addresses listed in the Connect Addresses value.

“Centera module” on page 64 provides more information.


Maintenance

• /PEA-file is the full path to a PEA file which provides read, write, exist, and query permissions.

• starttime is the last displayed timestamp from the incomplete dxuldmdelclips run.

The cleanup task starts and mark data as available for purging. Only data that was deleted during the time range specified is marked as available for purging.

The default values for dxuldmdelclips marks files that were deleted in the time range between the following two dates:

• The time specified by starttime.

• The date that is one year before when the command is run.

Cleanup on FTP or NFS module back-end systemsCleanup for back-end systems that use the NFS or FTP modules is performed on the back-end host. This cleanup is performed on a directory by directory basis.

Cleaning a back-endsystem that uses

either the FTP or NFSmodule

To clean up a back-end system that uses either the FTP or NFS module:

1. Log in as root on the back-end host.

2. Change the working directory to the directory that contains the deleted file data.

3. Run find with the -atime option:

find . -name *.deleted -atime +n -print > list-file &

where:

• n is an integer that represents the number of days since last access.

• list-file is the name of a temporary file to hold the results of the find command.

4. Review list-file. If it includes files which should be kept, repeat the command with a greater value for the number of days since last access.

5. If every file listed in list-file can be removed, type the find command with the -exec switch that calls the rm command:

find . -name *.deleted -atime +n -exec rm {} \; &


Maintenance

where n is an integer representing the number of days since last access.

The files listed in list-file are removed.


Maintenance

Command Reference 181

AInvisible Body Tag

This appendix covers the following topics:

◆ Command quick reference.............................................................. 182◆ Command usage .............................................................................. 185

Command Reference


Command Reference

Command quick referenceThe tables in this appendix list the commands used with this software release:

◆ Table 39 on page 182 lists administrative commands.

◆ Table 40 on page 183 lists file management commands.

◆ Table 41 on page 183 lists backup and restore commands.

“Command usage” on page 185 provides detailed information about each command.

Except where otherwise specified, all commands are located in /opt/fsm/adm/bin. and the commands are described in man pages located in /opt/fsm/man, where /opt/fsm is the full path to the FSM installation directory.

To access the man pages, set the FSM environment, and type man followed by the name of one of the commands. “Setting the FSM environment” on page 185 provides information on setting the FSM environment.

Table 39 Administrative commands (page 1 of 2)

Command Description

fsmprivdelete Deletes the FSM generated C-Clips that are marked as Deleted irrespective of their retention period.

deldmsession Deletes abandoned DMAPI sessions.

dx_read_log Preprocesses logs by replacing tokens with messages, and displays the result.

dxuldmcenteraping Tests connectivity with network interfaces on a Centera system and displays the result. When a connection is successfully made, the hardware and firmware values for the Centera system are displayed.

dxuldmcheckconf Checks the configuration file for inconsistent and insufficient entries.

dxuldmclip Displays the C-Clip associated with a given address and C-Clip ID.

dxuldmdelclips Searches a range of C-Clips and marks those for deleted files as available for purging from the Centera system.

expand_dmattrf Expands a file system’s .DMATTR file.

getdmattr Reports the value of a specific FSM attribute for one or more files.

getfileattr Reports all FSM and DMAPI debugging information for a file.

183

Command Reference

prtdmsession Prints information that describes all the DMAPI sessions that run on the local computer.

dxstat Prints DXUL-FSM migrate, purge, stage, delete, recover and import statistics.

dxprtstat Generates output that describes the attribute information necessary to load a new object into an FSM file system that is a mirror image of what the object looks like through the DXUL-SM interface.

dxhardlink Generates hardlinks within the DXUL-SM system.

dxdmimport Loads objects into an FSM managed file system.

Table 40 File management commands

Command Description

getimplist Retrieves a list of files in an FSM managed file system which need to be imported.

getmiglist Displays a list of files that need to be migrated.

getpurgelist Displays a list of files that need to be purged.

migin Retrieves data from the back-end system.

migout Migrates data to the back-end system.

migpurgestate Displays the migration and purge status of files.

purge Purges file data from a file system.

Table 41 Backup and restore commands (page 1 of 2)

Command Description

dxbuildtar Generates a tar-formatted file that is used to load objectsinto a UTDM file system.

dxcliplink Creates a link to a C-Clip and prints out the C-Clip attributes required to create a UTDM file system’s stub file linked to the data represented by the C-Clip.

dxdmload Loads objects into a UTDM file system from a file generated by dxbuildtar.

dxuldm_tar Backs up and restores file systems, without triggering a retrieval of migrated and purged data.

Table 39 Administrative commands (page 2 of 2)

Command Description


Command Reference

dmattrrecoverfs Synchronizes all file system metadata with data stored on the back-end system.

get_freeze_timeout Displays the current maximum time a UTDM file system can be frozen.

getrecoverlist Returns a list of files that need to be recovered into a UTDM file system.

set_freeze_timeout Sets the maximum time a UTDM file system can be frozen.

utdm_fs_freeze Temporarily suspends access to a UTDM file system.

utdm_fs_thaw Permits access to a UTDM file system that was put in a suspended state by utdm_fs_freeze.

utdm_recdmattrf Finalizes recovery of a UTDM file system from a snapshot.

Table 41 Backup and restore commands (page 2 of 2)

Command Description

185

Command Reference

Command usageThe commands are described in the following sections:

◆ “Administrative commands” on page 185

◆ “File management commands” on page 200

◆ “Backup and recovery commands” on page 205

Setting the DMAP_ROOT_PATHBefore using any of the FSM commands, the environment variable DMAP_ROOT_PATH must be set to the full path of the FSM installation directory. The FSM installation directory is the top-level FSM directory (the directory which contains the adm, bin, etc, and man subdirectories). The default path to this directory is /opt/fsm.

The DMAP_ROOT_PATH is set by setting the FSM environment as described in “Setting the FSM environment” on page 185.

Setting the FSM environmentMost FSM command-line tasks require that you set the FSM environment before you run the command.

To set the FSM environment, type the correct source command for your current shell:

◆ C shell (csh) and Turbo C shell (tcsh), type:

source /opt/fsm/etc/fsm.login


◆ Bourne shell (sh), Bourne Again shell (bash), and Korn shell (ksh), type:

. /opt/fsm/etc/fsm.profile


Administrative commandsThe administrative commands are described in the following sections:

◆ “fsmprivdelete” on page 186


Command Reference

◆ “deldmsession” on page 188

◆ “dx_read_log” on page 188

◆ “dxuldmcenteraping” on page 191

◆ “dxuldmcheckconf” on page 192

◆ “dxuldmclip” on page 192

◆ “dxuldmdelclips” on page 193

◆ “expand_dmattrf” on page 195

◆ “getdmattr” on page 196

◆ “getfileattr” on page 197

◆ “prtdmsession” on page 197

◆ “dxstat” on page 197

◆ “dxprtstat” on page 198

◆ “dxhardlink” on page 199

◆ “dxdmimport” on page 199

fsmprivdelete Use the fsmprivdelete command to delete the FSM generated C-Clips that are marked as Deleted from the Centera system and record the audit information describing the reason for deleting the C-Clips. The C-Clips are created on the Centera systems when the FSM managed file system objects are removed.

The command is successful only if the Delete or Privilege delete capability is enabled. These capabilities are associated with the access profile on a Centera system. The command runs with the privileged-delete capability only if both the capabilities are enabled.

fsmprivdelete logs all the successfully deleted C-Clips into a file under <DMAP_ROOT_PATH>/adm/log/fsmprivdel.log.

Following are the scenarios where the C-Clips are deleted:

◆ If the delete capability is enabled, it deletes only the FSM generated C-Clips that are marked as Deleted and whose retention period is expired. It cannot delete C-Clips that are marked as deleted, but the retention period is not expired.

◆ If the privileged-delete capability is enabled, it deletes all the FSM generated C-Clips that are marked as deleted, irrespective of the retention period attribute value.

187

Command Reference

Syntax<DMAP_ROOT_PATH>/adm/emc/fsmprivdelete -a centera_connect [-r file] [-y] -c clipid

IMPORTANT!Use this utility with caution because the C-Clips deleted from the Centera system cannot be restored.

OptionsTable 42 on page 187 describes the options for fsmprivdelete.

Table 42 Options for fsmprivdelete

Option Description

-a The connection string for the Centera system to query. This starts with a comma separated dotted decimal string that specifies the IP addresses of the Centera system to contact. The string can be appended with a question mark (?) followed by a path to a Centera authentication file (PEA). The Centera anonymous profile is used if no PEA file is supplied. The PEA file is used to grant the proper authentication and the capabilities such as read, write, exist, delete, privileged-delete, and query on Centera.

-r file The filename containing the reason for the delete operation, which is recorded as an audit string in the reflections created on a Centera system. If -r option is not specified, then the command prompts for typing the audit string for deletion. The FSM attaches a header containing the command name, fsm version, hostname on which the command is invoked, and the current time of deletion of C-Clip, to the specified audit string.

-c clipid C-Clip ID object on Centera system specified in string format.

file_clipids The filename containing the list of C-Clips ID objects on Centera system. Each line in the file contains one C-Clips ID specified in string format.

-i num_threads The number of threads used in parallel to delete the clips. By default, it does not create any posix threads. The main process itself executes the deletion operation.The maximum number of threads is restricted to 64.

-y If this option is specified, it never prompts for a confirmation before deleting the C-Clips. It continues with the delete operation. Also, it does not prompt to type a reason string for auditing purpose.


Command Reference

deldmsession Use the deldmsession command to remove abandoned DMAPI sessions.

DMAPI sessions become abandoned due to unexpected termination of a process. These sessions normally cause no problems and are removed when the system is rebooted. However, in some instances, a file system cannot be successfully unmounted if an abandoned DMAPI session is left active.

When using the deldmsession command, avoid accidental removal of active DMAPI sessions. If active sessions are removed, FSM processes terminate and file system activity is blocked until those processes are restarted.

Syntaxdeldmsession [[-s session-string]|[-i session-id]] -n

OptionsThe options for deldmsession are described in Table 43 on page 188.

dx_read_log The dx_read_log command starts a log preprocessor that expands token logs into plain text format. It replaces the tokens with messages from the Common Message File (CMF) and the optional Site Message File (SMF). If the SMF exists, it is searched first. After all replacements are made, the requested portion of the processed log is displayed.

Syntaxdx_read_log -l /log-file [-s [-|=|+] severity] [-T begintime] [-E endtime] [-d begindate] [-D enddate] [-p] [-h]

OptionsThe options for dx_read_log are described in Table 44 on page 189.

Table 43 Options for deldmsession

Option Description

-s session-string The -s option takes the argument session-string, which is the label of the session to be removed.

-i session-id The -i option takes the argument session-id, which is the integer identification number for the session being removed.

-n The -n option prevents deldmsession from responding to system events.

189

Command Reference

Table 44 Options for dx_read_log (page 1 of 2)

Option Description

-l /log-file The -l option takes the argument /log-file, that represents the full path to the log to be read. This option is required.

-s severity The -s option takes the argument severity, which is an integer that represents a severity level, 0-9, and returns messages related to that level.When severity is preceded by:• A minus sign (-), then all messages equal to or less than the level

specified by severity are returned.• An equal sign (=), then all messages equal to the level specified by

severity are returned. This is the default.• A plus sign (+), then all messages equal to or greater than the level

specified by severity are returned.Table 45 on page 190 describes the severity levels.

-b brevity The -b option takes the argument brevity, which is an integer that represents a brevity level, 0-3, and displays information within that level of detail.Table 46 on page 191 shows the brevity levels that are available.

-t number The -t option takes the argument number, which is an integer that represents the number of messages to display from the end of the log. This argument is similar to the tail command.

-c number The -c option takes the argument number, which is an integer that represents the number of messages to display from the end of the log. The display is continuous.

-T begintime The -T option takes the argument begintime which is a time value, in the format hh:mm:ss. All messages, generated after the specified time, are displayed. When this option is used with the -E option, a time segment can be specified.

-E endtime The -E option takes the argument endtime which is a time value in the format hh:mm:ss. All messages generated before the specified time are displayed. When this option is used with the -T option, a time segment can be specified.

-d begindate The -d option takes the argument begindate which is a date value in the format yy/mm/dd. All messages generated after the specified date are displayed. When this option is used with the -D option, a date segment can be specified.


Command Reference

Severity levels

The -s option accepts an integer argument that is used to filter messages based on a severity level. The severity levels described by each integer argument (0-9) are shown in Table 45 on page 190.

-D enddate The -D option takes the argument enddate which is a date value in the format yy/mm/dd. All messages generated before the specified date are displayed. When this option is used with the -d option, a date segment can be specified.

-p The -p option displays the current dx_read_log program parameters. No log messages are returned.

-h The -h option returns dx_read_log help. No log messages are returned.

Table 44 Options for dx_read_log (page 2 of 2)

Option Description

Table 45 Severity levels

Level Name Description

9 Panic Problems that are not recoverable. The process terminated.

8 Severe Major problems that require administrative action.

7 Warning Potential problems detected by system.

6 Recover Problems encountered by processes, from which the processes successfully recovered.

5 Info General process information.

4 Debug4 Debug messages with the highest level of detail.

3 Debug3 Debug messages with a level of detail lower than level 4.



0 Debug0 Debug messages with the lowest level of detail.

191

Command Reference

Brevity levels

The -b option takes an integer (0-3) that determines the amount of detail displayed. The brevity levels are shown in Table 46 on page 191.

dxuldmcenteraping The dxuldmcenteraping command checks connectivity with the network interfaces on a Centera system. A Centera system does not respond to packets sent by the ping command.

When a specified IP address is available, dxuldmcenteraping displays the following for that address:

Address: IP-addressInfo Version: infoversionCapacity: capacityFree Space: freeCluster ID: cluster-idCluster Name: cluster-nameVersion: versionReplica Address: replica-address

When dxuldmcenteraping encounters an unavailable IP address, it displays the following:

Unable to open cluster at address (IP-address). Error (FP_NO_POOL_ERR)

Syntaxdxuldmcenteraping -a emc-address [emc-address...]

OptionThe dxuldmcenteraping command takes the option emc-address which is an IP address for a network interface on a Centera system. Optionally, additional IP addresses, separated by spaces, may be specified.

Table 46 Brevity levels

Level Description

0 Message arguments only

1 Normal

2 Detailed messages

3 Further explanation


Command Reference

dxuldmcheckconf Use the dxuldmcheckconf command to check the configuration file for inconsistencies. The configuration file contains necessary configuration information for all FSM file systems. The dxuldmcheckconf command stops on the first inconsistency it finds and returns the inconsistent attribute’s name, and information about the inconsistency.

Optionally, the command can be called through the rc.fsm startup script to prevent FSM from starting with configuration errors.

Syntaxdxuldmcheckconf [-v]

OptionThe -v option toggles on verbose mode. In this mode, when no error is detected, a summary of the configuration settings for each file system that is specified in the configuration file is returned. When verbose mode is off, and no error is detected, the command prompt is returned.

dxuldmclip The dxuldmclip command retrieves and displays the information contained in a file’s associated C-Clip. The C-Clips are metadata files located on a Centera system back-end system. Example 7 on page 193 shows the C-Clip information displayed by dxuldmclip.

Syntaxdxuldmclip -a emc-address -c clipid

OptionsThe options for dxuldmclip are described in Table 47 on page 192.

Table 47 Options for dxuldmclip

Option Description

-a emc-address The -a option takes the argument emc-address which is one of the IP addresses specified for the Connect Addresses attribute.

-c clipid The -c option takes the argument clipid which is the ID string for a file’s associated C-Clip.To obtain clipid, type the command:getdmattr -a usiopath filepath

where filepath is the full path to the file. The value returned is clipid.

193

Command Reference

Example 7 Using dxuldmclip to obtain C-Clip information for a file

# getdmattr -a usiopath /utdm.1/file01usiopath value for file /utdm.1/file01 is: 743NEV737O694e23DFUNDMBPT20# dxuldmclip -a 137.69.44.247 -c 743NEV737O694e23DFUNDMBPT20Clip name: FSM_utdm.1Clip ID: 743NEV737O694e23DFUNDMBPT20 Created on: 2002.12.04 21:22:42 GMT Number of Blobs: 1 Number of Bytes in Blobs: 104857600 Tag: FILE_ATTRIBUTES (META_VERSION) = (Version 1.0) (TARGET) = (utdm.1) (UID) = (0) (GID) = (1) (MIGRATE_TIME) = (1039036962) (PATH_NAME) = (/utdm.1/file01) Tag: VERSION_1 (VERSION_TIME) = (1039036962) (VERSION_SIZE) = (104857600) Tag: OLD_CCLIPS No Attributes for this tag

dxuldmdelclips The dxuldmdelclips command examines a range of C-Clips for those representing deleted files and marks them as available for purging from the Centera system. The C-Clips marked as available for purging are not automatically purged. “Centera module” on page 64 provides more information about purging.

Only C-Clips linked to files that have been deleted from the file system are marked by this command. When the C-Clips are marked, the data storage space associated with C-Clip can be reclaimed by the Centera system’s purging routine.

The FSM file system must have query permission on the Centera system to use the dxuldmdelclips command. If the default permissions are changed to deny query permission for anonymous profiles, this permission must be provided through a PEA file.

The file system’s PEA file is identified through its Centera Profile Path value. “Preliminary tasks for Centera module” on page 45 provides more information.

“Cleaning a Centera system” on page 176 shows an example of the dxuldmdelclips command.


Command Reference

Syntaxdxuldmdelclips -a emc-address[?/PEA-file] [-t starttime] [-e endtime] [-m age] [-n num-to-del] [-v]

OptionsThe options for dxuldmdelclips are described in Table 48 on page 194.

Table 48 Options for dxuldmdelclips

Option Description

-a emc-address[?/PEA-file]

The -a option takes the argument emc-address which is one of the IP addresses specified for the file system’s Connect Addresses attribute.“Centera module” on page 64 provides more information on the Connect Addresses attribute.An optional (but required, in most cases) argument is /PEA-file, the full path to a PEA file. This argument follows a question mark that is appended to the emc-address argument. The PEA file must provide read, write, exist, and query permissions.

-t starttime The -t option takes the argument starttime which is an integer value that represents the number of seconds since the epoch.The time represented by starttime is used as the starting point for the range of C-Clips evaluated for marking. The default is 0, which means the starting point is the oldest C-Clip for the file system.“Restarting the task” on page 177 provides an example showing how to use this option to restart a dxuldmdelclips run.

-e endtime The -e option takes the argument endtime which is an integer value that represents the number of seconds since the epoch.The time represented by endtime is used as the ending point for the range of C-Clips evaluated for marking. The default is -1, which means the end point is the most recent C-Clip for the file system.

-m age The -m option takes the argument age which is an integer value that represents the number of days old a C-Clip must be before it is evaluated for marking.The default value is 365, which means only C-Clips older than one year will be marked as available for purging.

-n num-to-del The -n option takes the argument num-to-del which is an integer that represents the number of C-Clips that can be marked in the current dxuldmdelclips run.When the range of C-Clips available for marking exceeds num-to-del, the oldest C-Clips are marked first. The default value is -1, which means all eligible C-Clips will be marked.

-v The -v option toggles on verbose output.When verbose output is on, a message is sent to stdout after every 100 C-Clip deletions, and the final tally of deletions is sent to stdout at the end of the run.

195

Command Reference

expand_dmattrf The expand_dmattrf command is used to make changes to a file system’s .DMATTR file. The following changes can be made by using this tool:

◆ Increase the number of files handled.

◆ Increase the number of attribute blocks handled.

◆ Add space at the end of the file.

◆ Change the file system’s aggregate information.

Before using this command, the file system on which the .DMATTR file resides must be mounted by using its native format.

IMPORTANT!Before using this command, make a backup of the original .DMATTR file to permit recovery if errors occur with the new .DMATTR file.

Syntaxexpand_dmattrf [-f files] [-a blocks] [-z size] [-g agginfo] [-o elements] [-h heads] [-t fs] [-v|-q] path newpath

OptionsAt lease one of the action options must be used: -f, -a, -z, -g, -o, or -h. The file system type, -t, option is only required when the attribute file is converted from a version 1 header format to a version 2 header format. Specifying both the quiet, -q, and verbose, -v, options causes an error.

The options for expand_dmattr are described in Table 49 on page 195.

Table 49 Options for expand_dmattrf (page 1 of 2)

Option Description

-f files The -f option takes the argument files which is an integer that represents the new number of supported files.

-a blocks The -a option takes the argument blocks which is an integer that represents the new number of supported attribute blocks.

-z size The -z option takes the argument size which is an integer that represents the new size of the .DMATTR file in bytes.


Command Reference

getdmattr The getdmattr command displays the value of one of the FSM file attributes for one or more files.

Syntaxgetdmattr -a attribute-name filelist

-g agginfo The -g option takes the argument agginfo, which is a colon-separated triple that consists of the following aggregate information values:• Number of aggregates• Number of inodes per aggregate• Initial inode offset for each aggregateFor example, the triple 4:4194304:128 sets the new aggregate information to be 4 aggregates, each one with 4,194,304 inodes and an initial 128 inode offset.

-o elements The -o option takes the argument elements which is an integer that represents the new number of hash table elements in the overflow area.

-h heads The -h option takes the argument heads which is an integer that represents the new number of hash table list heads in the overflow area. Increase this number to create more list heads and thereby shorten the lists that are traversed when searching for a hash table element in the overflow area.

Note: An increase in this value causes more space to be allocated to the list heads in the .DMATTR file.

-t fs The -t option takes the argument fs which is the native (underlying) file system type on which the .DMATTR file resides. This option should only be used, and is required, when the attribute file must be converted from a version 1 header format to a version 2 header format.

-v The -v option turns on verbose mode. This causes the display of messages that describe the changes being made.

-q The -q option turns on quiet mode. This significantly reduces the display of messages.

path The variable path represents the full path of the .DMATTR file on the native file system.

newpath The variable newpath represents the output path, that is, the full path of the .DMATTR file generated by this command.

Table 49 Options for expand_dmattrf (page 2 of 2)

Option Description

197

Command Reference

OptionsThe options for getdmattr are described in Table 50 on page 197.

getfileattr Use the getfileattr command to display all FSM and DMAPI debugging information for a file.

Syntaxgetfileattr [-u] filepath

OptionsThe options for getfileattr are described in Table 51 on page 197.

prtdmsession The prtdmsession command displays information for all current DMAPI sessions.

Syntaxprtdmsession

dxstat Use the dxstat command to print DXUL-FSM migrate, purge, stage, delete, recover, and import statistics. It also prints information on activities that are in progress. If no options are passed, all statistics are printed.

Table 50 Options for getdmattr

Option Description

-a attribute-name The -a option takes the argument attribute-name, which is one of the FSM file attributes.

filelist The getdmattr command takes the argument filelist, which is the full path description of one or more files. For multiple files, separate each path description by a space.

Table 51 Options for getfileattr

Option Description

-u The -u option toggles on streamed output. When this option is toggled on, the output of the command is one continuous, unstructured stream.

filepath The getfileattr command takes the argument filepath, which is the full path to the file about which information is sought.


Command Reference

Syntax dxstat [-f pathname] [-m] [-p] [-s] [-d] [-r] [-i]

OptionsThe options for dxstat are described in Table 52 on page 198.

dxprtstat Use the dxprtstat command to generate output that describes the attribute information necessary to load a new object into an FSM file system that is a mirror image of what the object looks like through the DXUL-SM interface.

Syntaxdxprtstat [-i] pathname

Options The options for dxprstat are described in Table 53 on page 198.

Table 52 Options for dxstat

Option Description

-f pathname The path to the file system being managed whose statistics are to be printed.

-m Print migrate statistics.

-p Print purge statistics.

-s Print stage statistics.

-d Print delete statistics.

-r Print recover statistics.

-i Print import statistics.

Table 53 Options for dxprstat

Option Description

-i Import files into FSM.

pathname Pathname to the object.

199

Command Reference

Note: dxprtstat should be used in conjunction with the system find command when mirroring objects under a particular directory tree. -i option should be passed when files are being imported from DXUL-SM to FSM.

dxhardlink The dxhardlink command is used to generate hardlinks within the DXUL-SM system. These hardlinks are generated in such a way that they can be used by the FSM system to access file data.

If the dxhardlink command fails part way through for any reason, it can be retried with no ill effects (it simply skips over work already done).

The DXUL-SM file system to be loaded with hardlinks must be NFS accessible.

Syntaxdxhardlink -t target_DXSM_directory [-v]

OptionsThe options for dxhardlink are described in Table 54 on page 199.

dxdmimport The dxdimport command is used to load objects into an FSM managed file system. These objects should mirror those objects processed during the find/dxprtstat step of the conversion process.

Syntaxdxdmimport [Same as GNU tar(1)]

OptionsThe only options that should be used are xUf and possibly v. The U option should always be used to guarantee clean loads if objects already exist in the file system.

Table 54 Options for dxhardlink

Option Description

-t target_DXSM_directory The path within the DXUL-SM file system which is a target of the FSM managed file system to be loaded with mirrored objects.

-v Generate output for every hard link attempt.


Command Reference

File management commandsThe file commands are described in the following sections:

◆ “getimplist” on page 200

◆ “getmiglist” on page 201

◆ “getpurgelist” on page 202

◆ “migin” on page 204

◆ “migout” on page 204

◆ “migpurgestate” on page 204

◆ “purge” on page 205

getimplist The getimplist command is used to retrieve a list of files in an FSM managed file system which need to be imported. This utility is dependent on UTDM specific file system commands that are only available on certain platforms. UTDM allows for migration algorithms that scale.

Syntaxgetimplist -p pathname [-a age] [-c cookie] [-n number] [-s size] [-k]

OptionsThe options for getimplist are described in Table 56 on page 201.

Table 55 Options for getimplist (page 1 of 2)

Option Description

-p pathname The path to the file system being managed

-a age The age in minutes since the import candidates were created. Any files created within the last "age" in minutes will not be a import candidate. This is an optional parameter and if not supplied all import candidates will be returned.

-c cookie The -c option takes the argument cookie that identifies a location to start the search. This allows for retrievals of only partial import lists, and the ability to start a new import list where the last import list left off. This will allow for import algorithms to be written which do not require an entire list of all import candidates before import can be started. This is an optional parameter and if not supplied the search will start at the beginning of the file system.

201

Command Reference

getmiglist The getmiglist command retrieves a list of files that need to be migrated.

Syntaxgetmiglist -p fspath [-a age] [-c cookie] [-n num] [-s size] [-k]

OptionsThe options for getmiglist are described in Table 56 on page 201.

-n number The -n option takes the argument number which is the maximum number of candidates to return in the import list. If this parameter is not supplied then all import candidates will be returned.

-s size The -s option takes the argument size which represents the bytes size of a file. Only files whose size is greater than or equal to the size are returned. If size if not supplies then the default size is 0 bytes.

-k The -k option does not print out the file list. At end of processing just print out the number of files to import plus the number of bytes included in all import candidates.

Table 55 Options for getimplist (page 2 of 2)

Option Description

Table 56 Options for getmiglist (page 1 of 2)

Option Description

-p fspath The -p option takes the argument fspath which is the full path of the managed file system.This value is required.

-a age The -a option takes the argument age which is the age in minutes since a file was last modified. All files modified within the time specified by age are excluded from the list.This is an optional value. The default is 0 which ignores when a file was last modified.

-c cookie The -c option takes the argument cookie which is an integer representing a location in a previously returned list of files. This value allows you to start a new getmiglist request from a particular point in a previously returned list. Only files with cookies greater than or equal to cookie are included in the new list.This is an optional value. The default returns all files regardless of their cookie.


Command Reference

List formatThe getmiglist file list is in the following format:

Migration Weight-Blocks-Cookie-Handle-Path

The meaning of each column is described in Table 57 on page 202.

getpurgelist The getpurgelist command retrieves a list of files that need to be purged.

Syntaxgetpurgelist -p fspath [-a age] [-c cookie] [-n num] [-s size] [-k]

-n num The -n option takes the argument num which is the maximum number of files to include on the list.This is an optional value. The default returns all files.

-s size The -s option takes the argument size which is the size of a file in bytes. Only files bigger than or the same as size are included on the list.This is an optional value. The default returns all files.

-k The -k option causes getmiglist to return a summary only. The summary includes the total number of files that need to be migrated and the total combined size of the migration candidates, in bytes.This is an optional value. The default returns the file list.

Table 56 Options for getmiglist (page 2 of 2)

Option Description

Table 57 getmiglist file list columns

Option Description

Migration Weight Represents how likely a file is to be migrated relative to the other migration candidates.

Blocks Number of file system blocks used to hold the file.

Cookie Integer that represents a file’s location on the file list.

Handle Unique identifier for a file.

Path Full path of the file relative to the mount point of the file system. If this cannot be determined, the list displays the string "UNKNOWN".

203

Command Reference

OptionsThe options for getpurgelist are described in Table 58 on page 203.

List formatThe getpurgelist file list is in the following format:

Purge Weight-Blocks-Cookie-Handle-Path

The meaning of each column Heading is described in Table 59 on page 204.

Table 58 Options for getpurgelist

Option Description


-a age The -a option takes the argument age which is the age in minutes since a file was last accessed or modified. All files accessed or modified within the time specified by age are excluded from the list.This is an optional value. The default is 0 which ignores when a file was last accessed or modified.

-c cookie The -c option takes the argument cookie which is an integer representing a location in a previously returned list of files. This value allows you to start a new getpurgelist request from a particular point in a previously returned list. Only files with cookies greater than or equal to cookie are included in the new list.This is an optional value. The default returns all files regardless of their cookie.

-n num The -n option takes the argument num which is the maximum number of files to include on the list.This is an optional value. The default returns all files.

-s size The -s option takes the argument size which is the size of a file in bytes. Only files bigger than or the same as size are included on the list.This is an optional value. The default returns all files.

-k The -k option causes getpurgelist to return a summary only. The summary includes the total number of files that need to be purged and the total combined size of the purge candidates, in bytes.This is an optional value. The default returns the file list.


Command Reference

migin Use the migin command to retrieve purged file data from the back-end system.

The migin command takes the argument filelist, which is the full path description of one or more files. For multiple files, separate each path description by a space.

“Manually retrieving files” on page 173 provides migin examples.

Syntaxmigin filelist

migout Use the migout command to migrate file data to the back-end system.

The migout command takes the argument filelist, which is the full path description of one or more files. For multiple files, separate each path description by a space.

“Manually migrating a file” on page 172 provides migout examples.

Syntaxmigout filelist

migpurgestate Use the migpurgestate command to display the migration and purge status of a file. For each file specified, migpurgestate displays one of the following messages:

◆ file is not a file.

◆ file is not migrated and not purged.

◆ file is migrated and not purged.

◆ file is migrated and purged.

Table 59 getpurgelist file list columns headings

Heading Description

Purge Weight Represents how likely a file is to be purged relative to the other purge candidates.

Blocks Number of file system blocks used to hold the file.

Cookie Integer representing a file’s location on the file list.



205

Command Reference

where file is the full path of the specified file.

The migpurgestate command takes the argument filelist, which is the full path description of one or more files. For multiple files, separate each path description with a space.

Syntaxmigpurgestate filelist

purge Use the purge command to remove file data from a file system. Only files which have been successfully migrated are eligible to be purged. Purging a file removes all of a file’s data except for a portion from the head of the file equal to the value of the Stub Size attribute. “Configuring a file system” on page 57 provides more information about Stub Size.

The space occupied by the purged data is available for use by other files.

The purge command takes the argument filelist, which is the full path description of one or more files. For multiple files, separate each path description with a space.

“Manually purging files” on page 172 provides purge examples.

Syntaxpurge filelist

Backup and recovery commandsThe backup and recovery commands are described in the following sections:

◆ “dxbuildtar” on page 206

◆ “dxcliplink” on page 206

◆ “dxuldm_tar” on page 208

◆ “dmattrrecoverfs” on page 209

◆ “get_freeze_timeout” on page 210

◆ “getrecoverlist” on page 210

◆ “set_freeze_timeout” on page 211

◆ “utdm_fs_freeze” on page 212

◆ “utdm_fs_thaw” on page 213


Command Reference

◆ “utdm_recdmattrf” on page 213

dxbuildtar The dxbuildar command is used to create an archive file, in tar format, that can be used to load objects into a UTDM file system. This command takes the output of dxcliplink (for a Centera module Centera system back-end) and creates a tar format file. The resulting file is used with dxdmload to create stub files that point to the back-end data.

This command is located at:

/opt/fsm/adm/smtodm/dxbuildtar


Syntaxdxbuildar -f output_file -p prefix

OptionsThe options for dxbuildtar are described in Table 60 on page 206.

Example 8 on page 207 provides an example of this command.

dxcliplink The dxcliplink command parses a Centera system C-Clip and produces a file containing the attribute information that is needed to establish a UTDM file system link to the data represented by the C-Clip.

Syntaxdxcliplink -p pathname -o outputfile

OptionsThe options for dxcliplink are described in Table 61 on page 207.

Table 60 Options for dxbuildtar

Option Description

-f output_file The -f option takes the argument output_file, which is the full pathname of the resulting archive file.

-p prefix The -p option takes the argument prefix, which is the segment of the pathnames produced by dxcliplink that is not part of the path for the objects in the UTDM file system.

207

Command Reference

Example 8 Recovering data from a Centera system back-end

In this example, a connection to the data represented by two C-Clip files, ABC and DEF, must be restored to a UTDM file system mounted at /mnt/utdm.1. The pathname contains the segment /mnt/utdm.1, which is the segment of the full pathnames for ABC and DEF that is not needed in the pathname relative to the UTDM file system.

Perform the following steps:



2. Create the file /tmp/dxclips.in that contains each C-Clip ID, one per line separated by a line feed (LF) character.

3. Run dxcliplink to obtain the necessary C-Clip attribute information:

dxcliplink -p /mnt/utdm.1 -o /tmp/dxclipinfo.out < /tmp/dxclips.in

4. Run dxbuildtar to generate a tar-format file containing the attribute information from the C-Clips:

dxbuildtar -p /mnt/utdm.1 -f file.tar < /tmp/dxclipinfo.out

5. Run dxdmload to load the attribute information into the UTDM file system:

dxdmload -xUfv file.tar

dxdmload Use the dxdmload command to load the information in a file created by dxbuildtar into a UTDM file system.

This command is located at:

/opt/fsm/adm/smtodm/dxdmload


Table 61 Options for dxcliplink

Option Description

-p pathname The -p option takes the argument pathname, which is the full path to the mountpoint of a UTDM file system that is configured with a Centera system back-end.

-o outputfile The -o option takes the argument outputfile, which is the full path of the output file.


Command Reference

Syntaxdxdmload -xUfv dxtarfile

OptionsThe options for dxdmload are described in Table 62 on page 208.

Example 8 on page 207 provides an example of this command.

dxuldm_tar Use the dxuldm_tar command to back up and recover data in file systems. Data that exists on the back-end system is not backed up by this command. Only data resident in a file system, and not migrated, is backed up.

Always exclude the .DMATTR files from backup by using the --exclude option.

The dxuldm_tar command is based on the GNU version of tar. However, the command is enhanced so that it determines the file system objects required for backup.

“FSM tools” on page 150 provides step-by-step instructions on the use of dxuldm_tar.

Syntaxdxuldm_tar --exclude=.DMATTR -cvf tarfile [dir|.]

dxuldm_tar -xvf tarfile [filelist]

OptionsThe options for dxuldm_tar are described in Table 63 on page 209.

Table 62 Options for dxdmload

Option Description

-x The -x option causes dxdmload to extract the information in the file specified by the -f option into the UTDM file system specified by the same file.

-U The -U option ensures that files that exist in the UTDM file system are unlinked and recreated rather than being overwritten.

-f dxtarfile The -f option takes the argument dxtarfile, which is a tar-formatted file created by dxbuildtar.

-v The -v option produces verbose output.

209

Command Reference

dmattrrecoverfs The dmattrrecoverfs command synchronizes the metadata for recovered migrated files with the corresponding data on the back-end system. Use this command after a file system is recovered by using NetWorker software. The dmattrrecoverfs command reestablishes the link between each recovered migrated file and the file’s data on the back-end system.

For NetBackup and FSM backup tools, recovered migrated files have the recover bit set. When a file with the recover bit set is accessed, dmattrrecoverfs is automatically called to synchronize the file’s data.

The dmattrrecoverfs command is also started by an hourly cronjob that is installed in root’s crontab. When dmattrrecoverfs is started, it scans the file system for files with the recover bit set and synchronizes any it finds.

The dmattrrecoverfs command can be run while the file system is in use.

Table 63 Options for dxuldm_tar

Option Description

-cvf tarfile The -c option instructs the dxuldm_tar command to create an archive.The -v option displays filenames as they are added to the archive file.The -f option takes two arguments:• The first argument is tarfile, which is the full path description for the location where

the archive should be created.• The second argument is dir, which is a the full path description of the top-level

directory to be archived.When dir is a directory, dxuldm_tar recursively archives all subdirectories and files beneath the given directory.Optionally, a period character at the end of the command can be used to indicate the current working directory.

-xvf tarfile The -x option instructs the command to extract an archive.The -v option displays filenames as they are extracted.The -f option takes the argument tarfile, which is the full path description for an archive to extract. The archive is extracted into the current working directory.

filelist The dxuldm_tar command takes the argument filelist, which is the full path description of one or more files.For multiple files, separate each path description by a space. When filelist is provided, dxuldm_tar only extracts the specified files. If filelist includes a full path to a directory which matches a directory path in the archive, then the directory is recursively extracted.


Command Reference

Syntaxdmattrrecoverfs -p dirpath [-i threads]

OptionsThe options for dmattrrecoverfs are described in Table 64 on page 210.

get_freeze_timeout The get_freeze_timeout command retrieves the maximum number of seconds that a file system may be frozen by using utdm_fs_freeze. This number is called the maximum freeze timeout.

The maximum freeze timeout default value is 300 seconds, but it may be changed on a host-by-host basis by using set_freeze_timeout.

Syntaxget_freeze_timeout

getrecoverlist The getrecoverlist command retrieves a list of files that need to be recovered.

Syntaxgetrecoverlist -p fspath [-k]

OptionsThe options for getrecoverlist are described in Table 65 on page 211.

Table 64 Options for dmattrrecoverfs

Option Description

-p dirpath The -p option takes the argument dirpath, which is the full path to the top-level directory to be scanned. This parameter is required.

-i threads The -i option takes the argument threads, which is the number of parallel forked threads dmattrrecoverfs can start. The range is between 1 and 64. The default is 1.

211

Command Reference

List formatThe getrecoverlist file list is in the following format:

Cookie-Handle-Path

The meaning of each column heading is described in Table 66 on page 211.

set_freeze_timeout The set_freeze_timeout command sets the maximum number of seconds that a file system may be frozen by using utdm_fs_freeze. This number is called the maximum freeze timeout.

The maximum freeze timeout default value is 300 seconds, the range of permissible values is 0 seconds to 600 seconds.

Syntaxset_freeze_timeout maxtime

OptionThe set_freeze_timeout command takes one required argument, maxtime, which is the new maximum freeze timeout in seconds.

Table 65 Options for getrecoverlist

Option Description


-k The -k option causes getrecoverlist to return a summary only. The summary includes the total number of files that need to be recovered and the total combined size of the recovery candidates, in bytes.This is an optional value. The default returns the file list.

Table 66 getrecoverlist file list columns

Heading Description

Cookie Integer representing a file’s location on the file list.




Command Reference

utdm_fs_freeze The utdm_fs_freeze command quiesces and suspends access to a mounted UTDM file system for a specified number of seconds. This allows you to generate a snapshot of a mounted file system without the possibility of file system activity causing a corrupted snapshot.

At the end of the specified time period, the activity on the file system is automatically resumed, that is, made available for normal use. The snapshot must be completed before the file system is thawed to avoid a corrupted snapshot.

You can resume file system activity before the expiration of the suspension period by using utdm_fs_thaw.

Note: The utdm_fs_freeze command should be used only on mounted file systems.

Syntaxutdm_fs_freeze [-t timeout] mountpoint

OptionsThe options for utdm_fs_freeze are described in Table 67 on page 212.

Table 67 Options for utdm_fs_freeze

Option Description

-t timeout The -t option takes the argument timeout which is the number of seconds the file system remains frozen. At the expiration of timeout seconds, the file system is automatically thawed.This parameter is optional. The default is the maximum freeze timeout. If specified, it must be less than that value. The default maximum freeze timeout is 300 seconds.“get_freeze_timeout” on page 210 and “set_freeze_timeout” on page 211 provide more information about the maximum freeze timeout.

mountpoint The utdm_fs_freeze command takes the argument mount point which is the full path to the mount point for the file system.This value is required.

213

Command Reference

Freeze describedWhen you run utdm_fs_freeze, the following actions are taken for the specified file system:

◆ Current operations are allowed to finish.

◆ Any thread attempting to access the file system is suspended.

◆ Dirty buffers are flushed.

◆ A stable image of the file system is created on the disk.

Any thread that was suspended by utdm_fs_freeze remains suspended until the file system is thawed, either by the expiration of the specified time period or by running utdm_fs_thaw.

utdm_fs_thaw The utdm_fs_thaw command resumes activity on a mounted UTDM file system that was quiesced with utdm_fs_freeze.

This command resumes all threads that were suspended when the file system was quiesced.

Syntaxutdm_fs_thaw mountpoint

OptionThe utdm_fs_thaw command takes one required argument, mountpoint, which is the full path to the mount point for the file system.

utdm_recdmattrf The utdm_recdmattrf command recovers a file system that is restored from a snapshot. This command initiates the process of creating a valid namespace for each migrated file in the recovered snapshot.

IMPORTANT!The utdm_recdmattrf command must be run on the file system before it is used in read/write mode.

The utdm_recdmattrf command processes the restored file system’s .DMATTR file and sets the Recover attribute for each migrated file. The core processes detect the Recover attribute on a file and create a new namespace for the file during the first operation on it. The Recover attribute is then unset.


Command Reference

Syntaxutdm_recdmattrf pathname

OptionThe utdm_recdmattrf command takes one required argument, pathname, which is the full path of the recovered file system’s .DMATTR file.


Symbols.deleted extension

disk resource 165DXUL-SM 165

.DMATTR filebackup 145, 150dxuldm_tar 208expand_dmattrf 195NetBackup exclude_list 133, 147NetBackup recovery 133, 147NetWorker 138utdm_recdmattrf 214

Aactions

Centera 84disk resource 85NFS 85

activitiesdomain 32file system 37

adding, user 26administration

Console 26files 172

administrativecommands 185

Agent, Console 20associativity 78audience 9AVALONidm 176

clean-up 176preliminary tasks 45, 52, 54

Bbackend

Centera 64clean-up 175deleted files 165FTP 67IDM 64module 44mount point 54NFS 54, 68types 44

backup 123.DMATTR file 138, 145, 150commands 205FSM tools 135, 150FSM-related files 124FTP module file system 130general 123NetBackup 134, 142, 147NetWorker 132, 137NetWorker, 64-bit Linux version 141software 126UTDM file systems 125utilities 205

CCentera

actions 84backend 64module 45, 52, 54See also EMC Centera

changing password, user 28check directory, NFS 55

Index


Index

clean-upAVALONidm 176backend 175disk resource 178DXUL-SM 178EMC Centera 176find 178periodic 175storage target 178

clearing events 30Client, Console 24command reference

administrative 185backup 205dx_read_log 188dxbuildtar 206dxcliplink 206dxdmload 207dxuldm_tar 206dxuldmcenteraping 191dxuldmcheckconf 192dxuldmclip 192dxuldmdelclips 193dxuldmrecover 140expand_dmattrf 195file management 200get_freeze_timeout 210getdmattr 196getfileattr 197getmiglist 201getpurgelist 202getrecoverlist 210migin 204migout 204migpurgestate 204prtdmsession 197purge 205quick reference 182set_freeze_timeout 211utdm_fs_freeze 212utdm_fs_thaw 213utdm_recdmattrf 213

commandsadministrative 185backup 205internal 166quick reference 182

recovery 205usage 185

completion message, purge 173compression

levels 61partial read size 62

configurationdeleting 72disk resource 68editing 71file system 43, 57NFS 68viewing 70

configuring file system 57connect addresses, dxuldmdelclips 194connectivity

DXUL-SM 52EMC Centera 46FTP 52

Consoleadministration 26overview 21starting Client 24

consoleprocesses 169

Console Agent 20Console Client 24

IPv6 24, 25monitoring 30starting 24

console processeslogs 170monitoring 170stopping 170

console processes , starting 170Console Server 20conventions 10core processes

general 164monitoring 168

Ddata management utilities 200data retention

EMC Centera 52, 111EMC Centera requirements 111


Index

general 91, 109deldmsession 188deleted files

backend 165general 165migdestroy 175

deletingconfiguration 72extended rules 88

determiningmaximum time-out 155

direct-read 120mounting 120

disk resourceactions 85clean-up 178configuration 68preliminary tasks 54

dmap_root_path, setting 185DMAPI 15DMAPI attributes file, snapshot 213dmattrrecoverfs 209domain

activities 32events 30

dx_read_logcommand reference 188monitoring processes 168options 190severity levels 190

dxbuildtar 206dxcliplink 206dxdmload 207dxuldm_tar

command reference 206options 209using 150

dxuldmcenteraping, command reference 191dxuldmcheckconf, command reference 192dxuldmclip 192dxuldmdelclips

command reference 193connect addresses 194EMC Centera 176purge 193restart 177

dxuldmrecover 140

DXUL-SMclean-up 178connectivity 52

Eediting

configuration 71extended rules 87

effect of manually stopping, processes 167EMC Centera

clean-up 176connectivity 46data retention 52, 111data retention requirements 111dxcliplink 206dxuldmdelclips 176IPv4 64PEA file 47PEA file permissions 176, 194permissions 47preliminary tasks 45, 52, 54purge 175

EMC Centera data retentionenabling 111performance 110setting for a file system 113setting for files 114

EMC Centera, IPv4 46, 48enable data compression 61, 62events

clearing 30domain 30file system 35host 34, 35

examplemigin 174migout 172

expand_dmattrf, command reference 195expressions 74extended rules 73

copying 89creating 74deleting 88editing 87viewing 86


Index

Ffile deletion, uvdmigd 175file management, command reference 200file system

activities 37configuration 43, 57configuring 57events 35recovery 128retention 113state 38

filesadministration 172deleted 165management commands 200retention 114

find, clean-up 178freeze 154

maximum time-out 155snapshot 154SnapView 154UTDM file systems 154

FSMinternal commands 166migpurged 164monitoring 168starting 166stopping 167uvdmigd 164

FSM environment, setting 185FSM tools

backup 135, 150FSM-aware software 126FSM-related files, backup 124FTP

backend 67connectivity 52IPv6 52, 67preliminary tasks 52username and password 53

Gget_freeze_timeout

command reference 210snapshot 210SnapView 210

getdmattr, command reference 196getfileattr, command reference 197getmiglist, command reference 201getpurgelist, command reference 202getrecoverlist, command reference 210

Hhost, events 34, 35hostname database 45, 52, 54hosts 45, 52, 54

IIDM

backend 64preliminary tasks 45, 52, 54

incremental backups, recovery 115individual filesystems, monitoring 172internal commands, FSM 166internal, commands 166IPv4 24, 25, 46, 48, 64, 67IPv6 52, 67

Console Client 24, 25

Llogs

console processes 170

Mmaintenance 163management commands, files 200management domain 22management utilities 200manual

starting FSM processes 166stopping FSM processes 167

manual data retrieval, uvdmigd 173manually starting, processes 166manually stopping, processes 167match string 74maximum time-out

determining 155freeze 155setting 155snapshot 155


Index

migdestroydeleted files 175process 165

migincommand reference 204example 174uvdmigd 165

migoutcommand reference 204example 172

migpurgedFSM 164process information 164

migpurgestate, command reference 204minimum topology 17module

backend 44Centera 45, 52, 54

monitoringConsole Client 30console processes 170core processes 168FSM 168individual filesystems 172

monitoring processes, dx_read_log 168mount options 109

direct-read 120mounting 120

EMC Centera data retentionenabling 111performance 110setting for a file system 113setting for files 114

read-only 117mounting 118

readthru 120utdmro 117

mount point, backend 54

NNetBackup

.DMATTR file 133, 147backup 134, 142, 147exclude_list 133, 147recovery 134, 142, 148requirements 145

user-initiated backup 133, 147user-initiated restore 133, 147

NetWorker.DMATTR file 138backup 132, 137path information 137permissions 137recovery 138required file 137requirements 137

NFSactions 85check directory 55configuration 68preliminary tasks 54

NFS module 54, 68

Oonline help 25options

dx_read_log 190dxuldm_tar 209

overview, Console 21

Pparentheses 74path information, NetWorker 137PEA file 47performance 110periodic cleanup 175periodic, clean-up 175permissions

EMC Centera 47EMC Centera PEA file 176, 194NetWorker 137

precedence 78preliminary tasks 44

AVALOMidm 45, 52, 54disk resource 54EMC Centera 45, 52, 54FTP 52IDM 45, 52, 54NFS 54

process informationmigpurged 164uvdmigd 164


Index

processes 164console 169effect of manually stopping 167manually starting 166manually stopping 167uvdmigd 164

prtdmsession, command reference 197prune job 95purge

command reference 205completion message 173dxuldmdelclips 193EMC Centera 175

Qquick reference

commands 182utilities 182

quick reference, utilities 182quiesce. See freeze

Rread-only 117

mounting 118recovery 123

commands 205file system 128FTP module file system 130general 123incremental backups 115native FTP 130NetBackup 134, 142, 148NetWorker 138NetWorker, 64-bit Linux version 141snapshot 156software 126

removing, user 28required file, NetWorker 137requirements

NetBackup 145NetWorker 137

restart, dxuldmdelclips 177restoring incremental backups 115retention

file system 113files 114

Sscheduled jobs

comparison 92delete old files 92, 97delete old files job, backend differences 94deleting 100editing 99effect on existing settings 93job types 92migrate 92overview 92prune 92, 95, 97purge 92reoccurrence options 102

daily 104monthly 104one specific time 103weekdays 106weekends 105weekly 105yearly 106

schedule components 93time element

creating 102deleting 107editing 107overview 102

viewing 98Server, Console 20set_freeze_timeout

command reference 211snapshot 211SnapView 211

settingdmap_root_path 185FSM environment 185maximum time-out 155stub size 174

severity levels, dx_read_log 190snapshot 127

DMAPI attributes file 213freeze 154get_freeze_timeout 210maximum time-out 155recovery 156set_freeze_timeout 211


Index

SnapView 154thaw 156utdm_fs_freeze 212utdm_fs_thaw 213utdm_recdmattrf 213

SnapViewfreeze 154get_freeze_timeout 210set_freeze_timeout 211snapshot 154thaw 156utdm_fs_freeze 212utdm_fs_thaw 213utdm_recdmattrf 213

softwarebackup 126recovery 126

Solariszones 55

back-end mount point 55starting

Console Client 24console processes 170FSM 166

starting Client, Console 24starting FSM processes, manual 166state, file system 38stopping

console processes 170FSM 167

stopping FSM processes, manual 167storage target, clean-up 178stub size

setting 174

Tthaw

snapshot 156SnapView 156utdm file system 156

time elements 102creating 102

topology 17topology guidelines 18types, backend 44

Uusage, commands 185user

adding 26changing password 28removing 28

user-initiated backup, NetBackup 133, 147user-initiated restore, NetBackup 133, 147username and password, FTP 53utdm file system, thaw 156UTDM file systems

backup 125freeze 154

utdm_fs_freezecommand reference 212snapshot 212SnapView 212

utdm_fs_thawcommand reference 213snapshot 213SnapView 213

utdm_recdmattrf.DMATTR file 214command reference 213snapshot 213SnapView 213

utilitiesadministrative 185backup 205backup and recovery 205file management 200quick reference 182

uvdmigdfile deletion 175FSM 164manual data retrieval 173migin 165process information 164processes 164

Vviewing

configuration 70extended rules 86


Index

Zzones, Solaris 55

Documents

EMC DiskXtender File System Manager for UNIX/Linux...EMC DiskXtender File System Manager for UNIX/Linux Release 3.5. SP1 Administrator’s Guide 9 Preface As part of an effort to improve