EMC® VNX® Series
Release 8.1
Using VNX® File-Level Retention
P/N 300-015-101 Rev 01
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748-9103
1-508-435-1000
www.EMC.com
Copyright © 1998 - 2013 EMC Corporation. All rights reserved.
Published August 2013
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 regulatory document for your product line, go to the Technical
Documentation and Advisories section on EMC Powerlink.
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.
Corporate Headquarters: Hopkinton, MA 01748-9103
2
Using VNX File-Level Retention
Contents
Preface.....................................................................................................7
Chapter 1: Introduction...........................................................................9
Overview................................................................................................................10
System requirements.............................................................................................10
Restrictions and limitations.................................................................................11
User interface choices...........................................................................................12
Related information..............................................................................................13
Chapter 2: Concepts.............................................................................15
Overview................................................................................................................16
FLR-E and FLR-C...................................................................................................16
Tamperproof FLR clock........................................................................................17
Transition between states.....................................................................................17
Minimum, default, and maximum retention periods......................................19
Automatic file locking..........................................................................................20
Automatic file deletion.........................................................................................20
FLR epoch year......................................................................................................20
Data verification....................................................................................................21
Replication..............................................................................................................21
Activity log.............................................................................................................21
What FLR cannot protect against........................................................................22
Chapter 3: Configuring.........................................................................23
Enable the FLR license..........................................................................................24
Create an FLR-enabled file system.....................................................................25
Using VNX File-Level Retention
3
Contents
Chapter 4: Managing Files in an FLR-Enabled File System................27
View file permissions............................................................................................28
Set a retention date on NFS..................................................................................29
Set a retention date on CIFS.................................................................................30
Verify the retention date setting..........................................................................30
Lock a file on NFS..................................................................................................31
Lock a file on CIFS.................................................................................................32
Verify a file's locked state.....................................................................................32
Delete an expired file............................................................................................33
Chapter 5: Managing an FLR-Enabled File System............................35
Query an FLR-enabled file system......................................................................36
Modify a retention period for a file system.......................................................37
Reset an epoch date...............................................................................................39
Enable automatic file locking...............................................................................40
Enable automatic file deletion.............................................................................42
Set write verification.............................................................................................43
Restore a checkpoint to an FLR-E–enabled file system...................................43
Copy existing files to an FLR-enabled file system............................................44
Delete an FLR-enabled file system......................................................................44
Chapter 6: Troubleshooting..................................................................47
EMC E-Lab Interoperability Navigator..............................................................48
VNX user customized documentation...............................................................48
Known problems...................................................................................................48
Error messages.......................................................................................................48
EMC Training and Professional Services...........................................................49
Appendix A: CIFS and NFS API Details for Managing Files................51
Overview................................................................................................................52
Set or extend the retention date for an NFS file................................................52
Set or extend the retention date for a CIFS file.................................................52
Lock a file from an NFS client.............................................................................53
Lock a file from a CIFS client...............................................................................53
Delete a locked file from an NFS or CIFS client................................................54
Appendix B: SEC Ruling 17a-4(f) Requirements..................................55
4
Using VNX File-Level Retention
Contents
SEC ruling...............................................................................................................56
EMC file-level retention with compliance.........................................................57
Appendix C: FLR Activity Log File.........................................................59
Overview................................................................................................................60
Log file events........................................................................................................60
Glossary..................................................................................................63
Index.......................................................................................................65
Using VNX File-Level Retention
5
Contents
6
Using VNX File-Level Retention
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.
Using VNX File-Level Retention
7
Preface
Special notice conventions
EMC uses the following conventions for special notices:
Note: Emphasizes content that is of exceptional importance or interest but does not relate to personal
injury or business/data loss.
Identifies content that warns of potential business or data loss.
Indicates a hazardous situation which, if not avoided, could result in minor or
moderate injury.
Indicates a hazardous situation which, if not avoided, could result in death or
serious injury.
Indicates a hazardous situation which, if not avoided, will result in death or serious
injury.
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 EMC Online Support
(registration required) at http://Support.EMC.com.
Troubleshooting—Go to EMC Online Support at http://Support.EMC.com. After
logging in, locate the applicable Support by Product page.
Technical support—For technical support and service requests, go to EMC Customer
Service on EMC Online Support at http://Support.EMC.com. After logging in, locate
the applicable Support by Product page, and choose either Live Chat or Create a service
request. To open a service request through EMC Online Support, you must have a
valid support agreement. Contact your EMC sales representative for details about
obtaining a valid support agreement or with questions about your account.
Note: Do not request a specific support representative unless one has already been assigned to
your particular system problem.
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:
techpubcomments@EMC.com
8
Using VNX File-Level Retention
1
Introduction
Topics included are:
◆
◆
◆
◆
◆
Overview on page 10
System requirements on page 10
Restrictions and limitations on page 11
User interface choices on page 12
Related information on page 13
Using VNX File-Level Retention
9
Introduction
Overview
File-level retention (FLR) is an EMC® VNX® series software feature for protecting files from
modification or deletion until a specified retention date. By using file-level retention, you
can archive data to FLR storage on standard rewritable magnetic disks through NFS or CIFS
operations. FLR allows you to create a permanent, unalterable set of files and directories
and ensure the integrity of data.
There are two different types of file-level retention available: enterprise (FLR-E) and
compliance (FLR-C).
◆
FLR-E protects data content from changes made by users through CIFS, NFS, and FTP.
◆
FLR-C protects data content from changes made by users through CIFS, NFS, and FTP,
from changes made by administrators, and also meets the requirements of SEC rule
17a-4(f).
An FLR-enabled file system:
◆
Safeguards data by ensuring integrity and accessibility
◆
Simplifies the task of archiving data for administrators
◆
Improves storage management flexibility
Chapter 2 provides more details.
This document is part of the VNX series documentation set and is intended for use by system
administrators responsible for managing an FLR-enabled file system.
System requirements
Table 1 on page 10 describes the EMC VNX series software, hardware, network, and storage
configurations.
Table 1. System requirements
10
Software
VNX series version 8.1
Hardware
◆
VNX Data Mover
◆
VNX series system
Network
No specific network requirements
Storage
No specific storage requirements
License
Use of file-level retention functionality requires the purchase and activation of an FLR license
Using VNX File-Level Retention
Introduction
Restrictions and limitations
If any of this information is unclear, contact your EMC Customer Support Representative
for assistance:
◆
You must set the level of file-level retention wanted (off, enterprise, or compliance) at
file system creation. After the file system has been created, you cannot change it.
◆
You can enable VNX File Deduplication and Compression on an FLR-enabled file system.
The integrity of the data will not be affected.
◆
In FLR-E–enabled file systems, files that are in the locked state cannot be modified or
deleted by VNX for file clients and users. In FLR-C–enabled file systems, files that are in
the locked state cannot be modified or deleted by VNX for file clients, users, and
administrators. The path to a file in the locked state is also protected from modification.
As a result, a directory on an FLR-enabled file system cannot be renamed or deleted if
it contains any files or subdirectories. An FLR-C–enabled file system is also locked if it
contains protected files.
◆
Starting with systems that use version 5.6.43.9, both FLR-E and FLR-C allow the deletion
of empty locked files and empty append-only files. However, any locked or append-only
file that contains data is protected. Prior to version 5.6.43.9, FLR protected empty locked
files from being deleted.
◆
FLR-E is intended for self-regulated archiving. FLR-C is intended to assist companies
that have to comply with regulations such as the United States Securities and Exchange
(SEC) ruling 17a-4(f).
◆
The antivirus (AV) administrator should update the virus definition files on all resident
AV engines in the Common AntiVirus Agent (CAVA) pools, and periodically run a full
scan of the file system to detect infected locked files. To run a full file scan from the
Control Station, use the server_viruschk -fsscan command. When an infected locked file
is discovered, the resident AV engine records the presence of the infection and its location
in the log file of the resident scan engine. An administrator cannot repair or remove an
infected file. The file can be deleted only after its retention date has passed. However,
the administrator can change the file's permission bits and restrict read access to make
the file unavailable to users. CAVA's scan-on-first-read functionality does not detect a
virus in a locked file. Using VNX Event Enabler provides more details about virus definition
updates.
◆
Most file copy tools preserve the last modified time of a file being copied. When copying
files into an FLR file system with automatic file locking enabled, if you did not modify
files to copy within the automatic file lock policy interval specified on the FLR file system,
the file copies are locked almost immediately after being copied into the FLR file system.
The files immediately meet the criteria for being locked automatically. For example, the
lock policy interval is set to 30 minutes. File A was modified 15 minutes ago. File B was
modified 60 minutes ago. File A is not locked when copied into the FLR file system
because its modification time is less than the lock policy interval. However, File B is
locked when copied into the FLR file system because its modification time is more than
the lock policy interval.
Restrictions and limitations
11
Introduction
◆
For VNX Replicator:
•
You cannot create a replication session or copy session unless both the source and
destination file systems have the same FLR type, either off, enterprise, or compliance.
Also, when creating a file system replication, you cannot use an FLR-C–enabled
destination file system that contains protected files.
•
You cannot start a replication session if an FLR-C–enabled destination file system
contains protected files and updates have been made to the destination.
•
You cannot start a switched-over replication session in the reverse direction when an
FLR-C–enabled, original source file system contains protected files, and updates have
been made to the original source since the switchover.
◆
It is not possible to enable the VNX FileMover functionality on a file system with file-level
retention enabled. Therefore, you cannot use a file system with file-level retention enabled
as primary storage in a FileMover environment. However, you can create a file system
with file-level retention enabled as secondary storage.
◆
Although file-level retention supports all backup functionality, the FLR attribute is not
preserved in the NDMP backup. Therefore, the VNX administrator must make sure that
the files are restored to a file system with file-level retention enabled.
◆
The root file system of the nested mount cannot be a file system with file-level retention
enabled.
◆
The file-level retention features of NFSv4.1 cannot be used to manage the locked state
of files in an FLR-enabled file system. NFSv4.1 clients must use the same mechanisms
as NFSv3 clients.
◆
You cannot create a writeable checkpoint of an FLR-C–enabled file system. However,
you can create a writeable checkpoint of an FLR-E–enabled file system.
◆
When using SMB 2.0 or higher, some versions of Windows, such as Windows 2008,
Windows Vista, and Windows 7, will cache file attribute changes by default without
confirming that the changes occurred on the file server. While this provides improved
performance, it also means that attempting to change a locked file in an FLR file system
from read-only to writable may appear to succeed when it does not. It can take a few
minutes for the Windows client to correct its cache and file attributes display.
You can resolve this issue by reducing or disabling the Windows client file information
cache as described in http://technet.microsoft.com/en-us/library/ff686200 (WS.10).aspx.
User interface choices
The VNX system offers flexibility in managing networked storage that is based on your
support environment and interface preferences. This document describes how to configure
and manage FLR files and an FLR-enabled file system by using the VNX command line
interface (CLI). You can also perform some of these tasks by using the EMC Unisphere®
software.
12
Using VNX File-Level Retention
Introduction
The Unisphere software online help contains additional information about managing your
system.
Installing Management Applications on VNX for File includes instructions on launching the
Unisphere software.
Related information
Specific information related to the features and functionality described in this document are
included in:
◆
VNX Command Line Interface Reference for File
◆
Online VNX man pages
◆
Parameters Guide for VNX for File
EMC VNX documentation on EMC Online Support
The complete set of EMC VNX series customer publications is available on EMC Online
Support. To search for technical documentation, go to http://Support.EMC.com. After
logging in to the website, click Support by Product and type VNX series in the Find a
Product text box. Then search for the specific feature required.
VNX wizards
Unisphere software provides wizards for performing setup and configuration tasks. The
Unisphere online help provides more details on the wizards.
Related information
13
Introduction
14
Using VNX File-Level Retention
2
Concepts
The file-level retention concepts are:
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Overview on page 16
FLR-E and FLR-C on page 16
Tamperproof FLR clock on page 17
Transition between states on page 17
Minimum, default, and maximum retention periods on page 19
Automatic file locking on page 20
Automatic file deletion on page 20
FLR epoch year on page 20
Data verification on page 21
Replication on page 21
Activity log on page 21
What FLR cannot protect against on page 22
Using VNX File-Level Retention
15
Concepts
Overview
File-level retention allows you to set file-based permissions on a file system to limit write
access for a specified retention date. File-level retention is enabled on a specified file system
only at creation time. When a new file system is created and enabled for file-level retention,
it is persistently marked as an FLR-enabled file system and the FLR setting cannot be changed.
After a file system is created and enabled with file-level retention, an administrator can
apply FLR protection on a per-file basis.
A file in an FLR-enabled file system is always in one of four possible states: not locked,
locked, append-only, or expired. You manage files in the locked state by setting retention
dates that, until the dates have passed, prevent the files from being modified or deleted.
FLR files can be grouped by directory or batch process, thus enabling you to manage the
file archives on a file system basis, or to run a script to locate and delete files in the expired
state. Use the FLR Toolkit, which contains a suite of applications that enables users to manage
the retention states of files in an FLR-enabled file system, including deletion of expired files.
To access the FLR Toolkit, go to EMC Online Support. After logging in to EMC Online
Support, locate the applicable Support by Product page. Search for FLR Toolkit to access
information for the FLR Toolkit.
FLR-E and FLR-C
FLR-E protects data content from changes made by users through CIFS, NFS, and FTP. An
appropriately authorized administrator can delete an FLR-E–enabled file system, even if it
has files in the locked state on it.
FLR-C:
◆
Protects data content from changes made by users through CIFS, NFS, and FTP.
◆
Protects data from changes made by administrators.
◆
Meets the requirements of SEC rule 17a4(f).
An FLR-C–enabled file system cannot be deleted if it has files in the locked state on it.
In both FLR-E–enabled file systems and FLR-C–enabled file systems, files that are in the
locked state cannot be modified or deleted. The path to a file in the locked state is also
protected from modification. As a result, a directory on an FLR-enabled file system cannot
be renamed or deleted if it contains any files or subdirectories. Locked files can be deleted
only after their retention date has passed. A retention date is the date and time when a file's
FLR protection expires. If you do not specify a retention date before you lock the file in either
an FLR-E–enabled file system or an FLR-C–enabled file system, the file will be locked until
the current time plus the default retention period currently configured on the file system.
16
Using VNX File-Level Retention
Concepts
Tamperproof FLR clock
The FLR clock is tamperproof. The clock is set one time, and is maintained for each file
system. The file system's FLR clock value is initialized by synchronizing it with the current
Data Mover system time when the file system is first mounted on a Data Mover.
While a file system is unmounted or is mounted read-only, its FLR clock is not updated.
When mounted read/write again, the file system's FLR clock resumes where it left off. The
FLR clock loses time if an FLR file system is unmounted and then remounted because there
is no compensation made for the time period when the file system was offline. This prevents
expired FLR files from being deleted before they should be.
An FLR clock might also lose time if an FLR-E–enabled file system is restored to a previous
point in time using an EMC SnapSure™ or EMC TimeFinder®/FS restore operation. These
operations are not supported for FLR-C–enabled file systems.
A replication session is created only to a destination file system that is mounted read-only.
The data from the source file system is synchronized to the destination file system in
synchronization intervals (known as SLA/RPO/RTO). The synchronization interval is specified
during the create operation. As part of synchronization, the clock is also updated on the
destination file system that is mounted read-only.
If the FLR clock is behind the current value of the system clock, it is advanced by up to 138
seconds per hour to adjust with the Data Mover system clock. This allows the FLR clock to
adjust at a rate of approximately two weeks per year, if necessary. Adjustments made to the
Data Mover system clock, either manually or by network time protocol (NTP), do not affect
the FLR clocks of file systems. The only exception to this is if the Data Mover clock is adjusted
backwards to a point in time prior to the current value of the FLR clock. In this case, the FLR
clock is also adjusted backwards to stay aligned with the Data Mover system clock.
An FLR clock will never be ahead of the system time of the Data Mover that it is mounted
on. If an FLR-enabled file system is mounted on a Data Mover whose system clock is behind
the FLR clock associated with the file system, the FLR clock is reset back to match the Data
Mover system time.
Transition between states
A file in an FLR-enabled file system transitions between four possible states of not locked,
locked, append-only, or expired, based on the file's last access time (LAT) and read-only
permission.
When a file is created, it is in the not locked state. A file that is not locked is treated exactly
as a file in a file system that is not enabled for file-level retention. It can be renamed, modified,
or deleted.
Note: A file's current state is not visible to the user. Also, access to a file that is not locked causes the
file's LAT to change. For example, antivirus scanning, backing up, or searching file contents modifies
the LAT on a file.
Tamperproof FLR clock
17
Concepts
When you change the permissions on a file that is not locked from read/write to read-only,
the file transitions from the not locked state to the locked state. A locked file cannot be
modified or deleted by VNX clients or users. Also, the path to any locked file is protected
from modification. This means a directory on an FLR-enabled file system cannot be renamed
or deleted unless it does not contain any protected files. Locked files can be deleted only
after their retention date has passed.
Important: If you use Windows Explorer to make a file in an FLR file system read-only, it sets the atime
of the file to the current date and time before making it read-only. This results in locking the file for
the default retention period in effect on the file system. If you want to use Windows Explorer to set
or manage retention dates, or to lock files in an FLR-enabled file system, you must install the FLR
Toolkit. The Toolkit contains a suite of applications that enables users to manage the retention states
of files in an FLR-enabled file system. To access the FLR Toolkit, go to EMC Online Support. After
logging in to EMC Online Support, locate the applicable Support by Product page. Search for FLR Toolkit
to access information for the FLR Toolkit.
A retention date specifies the date and time when a file's FLR protection expires. EMC
suggests specifying a retention date before you lock the file. You can set a file's retention
date by modifying the file's LAT through NFS or CIFS operations. If you do not specify a
retention date before you lock the file in an FLR file system, the file will be locked for the
default retention period that is set on the file system at the time the file is locked.
Note: The infinite retention date appears as Dec 31, 1969.
If a file is empty, it could transition between the locked and append-only states. You do not
have to set a retention date on a file to convert it from a locked file into an append-only file.
The transition from locked to append-only is performed by manipulating an empty file to
read-only and back to writable again. As long as a file remains empty, it can cycle between
the locked and append-only states.
The append-only state should be used by applications that send sequential data. If the data
received by the Data Mover is not sequential, a request to modify or delete the file is rejected.
Append-only files do not support the non-sequential addition of data. While in an
append-only state, data may be appended only to the end of the file. Any data already in
the file cannot be modified or deleted. A typical use case for the append-only state is a log
file, which only appends new data.
Once a file in the append-only state has been written to, putting it into the locked state by
making it read-only locks the file into that state until its retention date has passed.
A file transitions from the locked state to the expired state when its retention date has passed.
A file in the expired state can be deleted by the file's owner or the administrator, but cannot
be altered.
18
Using VNX File-Level Retention
Concepts
Note: For systems that use version 7.1 and later, Enable automatic file deletion on page 42 describes
how to automatically delete files in an expired state. For systems that use version 7.0 and earlier,
file-level retention does not perform automatic deletion of files in an expired state. Expired files must
be deleted explicitly or by using the FLR Toolkit. To access the FLR Toolkit, go to EMC Online Support.
After logging in to EMC Online Support, locate the applicable Support by Product page. Search for
FLR Toolkit to access information for the FLR Toolkit.
If necessary, you can revert a file from the expired state back to the locked state by extending
its retention date to a date beyond the original retention date. To extend a retention date,
change the file's LAT to a time that extends beyond the original expiration date. Although
you can extend a file's retention date, you cannot shorten it. If you specify a new access time
that is earlier than the current access time for the file, the system rejects the command. With
the exceptions of extending a file's retention date and modifying a user or group's read
permissions to the file, the file's metadata is not editable during the retention period.
While copying a read-only file from a regular file system to an FLR-enabled file system, the
file is not locked. Upon completion of the read-only file copy, the file stays in the not locked
state. To lock a read-only file, you must:
1. Copy the file to an NFS or CIFS file system enabled for file-level retention.
2. Change permission on the file to read/write.
3. Set a retention date.
4. Lock the file.
Additionally, file systems with file-level retention enabled always enforce synchronization
of Windows (CIFS) read-only bit and UNIX (NFS) read/write mode.
Minimum, default, and maximum retention periods
For systems that use version 7.1 and later, you can set minimum, default, and maximum
retention periods by using either the CLI nas_fs command or a file system properties' FLR
Settings tab in the Unisphere software:
◆
A minimum retention period specifies the shortest period for which files on an FLR-enabled
file system can be locked and protected from deletion. The default value for the minimum
retention period is 1 day. Any attempt to lock a file for less than the minimum retention
period results in the file being locked until the current system time plus the minimum
retention period is reached. The minimum retention period must be less than or equal
to the maximum retention period. The minimum retention period can be set to Y for
years, M for months, D for days, or infinite. Setting the value to infinite means that the
files can never be deleted.
◆
A default retention period is used in an FLR-enabled file system when a file is locked and
a retention period is not specified. That is, the file's atime value is greater than the "epoch
year" but less than the current system time when the file is locked. The default retention
period must be greater than or equal to the minimum retention period, and less than or
equal to the maximum retention period. The default retention period can be set to Y for
years, M for months, D for days, or infinite. The default value for the default retention
Minimum, default, and maximum retention periods
19
Concepts
period is infinite, which means that the files can never be deleted. The system will ensure
that the default retention period is always less than or equal to the maximum retention
period.
◆
A maximum retention period specifies the longest period for which files on an FLR-enabled
file system can be locked and protected from deletion. The default value for the maximum
retention period is infinite, which means that the files can never be deleted. Any attempt
to lock a file for more than this maximum retention period results in the file being locked
until the current system time plus the maximum retention period is reached. The
maximum retention period can be set to Y for years, M for months, D for days, or infinite.
Modifying the minimum, default, or maximum retention period value does not affect files
that are currently locked in a file system.
Automatic file locking
You can specify whether to automatically lock files in an FLR-enabled file system, as well
as a policy interval for how long to wait after files are modified before the files are
automatically locked. When enabled, auto-locked files are set with the default retention
period value. The system default for automatic file locking is disabled. The system default
for the policy interval is 1 hour.
Note: Most file copy tools preserve the last modified time of a file being copied. When copying files
into an FLR file system with automatic file locking enabled, if you did not modify files to copy within
the automatic file lock policy interval specified on the FLR file system, the file copies are locked almost
immediately after being copied into the FLR file system. The files immediately meet the criteria for
being locked automatically. For example, the lock policy interval is set to 30 minutes. File A was
modified 15 minutes ago. File B was modified 60 minutes ago. File A is not locked when copied into
the FLR file system because its modification time is less than the lock policy interval. However, File
B is locked when copied into the FLR file system because its modification time is more than the lock
policy interval.
Automatic file deletion
You can specify whether to automatically delete locked files from an FLR-enabled file system
once their retention periods have expired. The system default for automatic file deletion is
disabled.
FLR epoch year
You can specify the base year used for calculating the retention date of a file beyond 2038:
◆
20
When a file is locked with its atime set to a value greater than or equal to the FLR epoch
year value, the file’s retention date is set to the file’s atime value.
Using VNX File-Level Retention
Concepts
◆
When a file is locked with its atime set to a value less than the FLR epoch year value, the
file's retention date is set to 2038 + (atime_year - 1970).
You can specify values from 2000 to 2037. The default value is 2003. The maximum value
for the retention period is December 31, 2104 11:59:59 p.m. Trying to set a date beyond this
value generates an error.
Data verification
Data verification ensures the integrity of the data written to disk by performing a read back
of the data that was written to the FLR-C–enabled file system. This write verification
functionality, disabled by default, is available for FLR-C–enabled file systems only. To be
SEC rule 17a4(f) compliant , you must manually enable write verification. Set write
verification on page 43 contains information on enabling write verification.
If the data read back from the storage does not match the data in memory, the Data Mover
reattempts the write and read back twice more, for a total of three times. If there is still a
mismatch, the Data Mover logs a message to the Data Mover server log and panics the Data
Mover, which identifies that data is corrupt. The Data Mover panic ensures that the data
verification failure will not go unnoticed.
Note: If write verification is enabled, all write operations on all FLR-C file systems mounted on the
Data Mover will be read back and verified to see whether the data has been written correctly. The
system performance may degrade during this procedure due to the amount of operations that are
being performed.
Replication
For VNX Replicator create and file system copy operations, replication on an FLR-C–enabled
file system is allowed when:
◆
The source file system has FLR-C enabled, and the destination file system has FLR-C
enabled and does not have protected files.
◆
The source file system has FLR-C enabled and the destination is a storage pool.
You can start a replication session when the source file system has FLR-C enabled and the
destination file system has FLR-C enabled and does not have protected files.
You can start a replication session with the reverse option when the original source file
system has FLR-C enabled and does not have protected files and the original destination
file system has FLR-C enabled.
Activity log
The activity log file contains events that successfully changed or attempted to change
protected data on an FLR-enabled file system. The activity log file is named
Data verification
21
Concepts
"flrLogyyyymmddhhmm" where the yyyymmddhhmm timestamp suffix is the FLR clock
time when the file was created. In situations such as a security breach, this log is helpful to
find information, such as the credentials of the user and time of event. Examples of events
that would trigger a logging action are locking a file, deleting an expired file, and so on. The
activity log can be used as part of the business processes required to satisfy the auditing
requirement of SEC rule 17a-4(f). The standard CIFS auditing functionality that a Data Mover
supports can also be used in this way, but it is not specifically focused on FLR events.
If there is insufficient space in the file system to update the activity log, warnings are logged
in the Data Mover server log but messages are not logged in the activity log.
Appendix C describes additional FLR activity log file information.
What FLR cannot protect against
While FLR protects your data from harm, there are some scenarios and situations which are
beyond the control of the system and may result in data loss. The following are some scenarios
that may occur but are beyond the scope of the FLR and SEC requirements:
◆
FLR does not by itself offer any protection against the physical failure of disk drives or
storage arrays. Protection of data from these types of failure relies on mechanisms such
as RAID and replication of data to a second site.
◆
FLR does not protect data against the actions of anyone who has physical access to the
system. For example, someone could manually remove and destroy disk drives and
thereby destroy the data they contain.
◆
FLR does not offer any protection to FLR file systems affected by corruption of the system
configuration database or software bugs. The system will automatically detect corruption
of its configuration database and “dial-home.”
◆
FLR does not provide any protection against someone with access to the system's
management tools that can delete (or unbind) the LUNs (disks) that a file system is built
on, thereby destroying the file system itself and the data it contains. This type of attack:
•
Cannot be targeted at specific files (the entire file system is destroyed)
•
Is unlikely to go unnoticed (one or more file systems will disappear and the Data
Mover will panic)
•
Destroys data rather than allow it to be modified
For these reasons and others, it is important to physically maintain either backups or replicas
of file systems. Logically separate them from the file system production copy by using
features such as VNX SnapSure, VNX Replicator, and offsite backups.
22
Using VNX File-Level Retention
3
Configuring
The tasks to configure an FLR-enabled file system are:
◆
◆
Enable the FLR license on page 24
Create an FLR-enabled file system on page 25
Using VNX File-Level Retention
23
Configuring
Enable the FLR license
1. Open your web browser and log in to the Unisphere software with your administrative
username and password.
2. Select your system from the All systems drop-down menu.
3. Select Settings.
4. From the task list, under More Settings, select Manage Licenses for File.
5. Select File-level Retention Licensed.
6. Click Apply.
7. Click OK.
8. After the license is enabled, restart the management application to see the feature in the
user interface.
24
Using VNX File-Level Retention
Configuring
Create an FLR-enabled file system
Note: Ensure that the system clock is set to the correct time before creating and mounting an
FLR-enabled file system. The file system's FLR clock is set when the system is first mounted.
Action
To create an FLR-enabled file system, use this command syntax:
$ nas_fs -name <name> -create [size=<integer>[T|G|M]] pool=<pool>
[worm={enterprise|compliance|off}[-default_retention {<def_integer>{Y|M|D}
|infinite}] [-min_retention {<min_integer>{Y|M|D}|infinite}]
[-max_retention {<max_integer>{Y|M|D}|infinite}]]
where:
<name> = name of the file system.
<integer> = size of the file system.
<pool> = storage pool for the file system.
<def_integer> = default retention period that is used in an FLR-enabled file system when a file is locked and a retention
period is not specified. This value must be greater than or equal to the minimum retention period, and less than or equal
to the maximum retention period. Specify Y for years, M for months, D for days, or infinite. The default value for the default
retention period is infinite, which means that the files can never be deleted.
<min_integer> = shortest retention period for which files on an FLR-enabled file system can be locked and protected
from deletion. This value must be less than or equal to the maximum retention period. Any attempt to lock a file for less
than the minimum retention period results in the file being locked until the current system time plus the minimum retention
period is reached. The default value for the minimum retention period is 1 day. Specify Y for years, M for months, D for
days, or infinite. Setting infinite means that the files can never be deleted.
<max_integer> = longest retention period for which files on an FLR-enabled file system can be locked and protected
from deletion. Any attempt to lock a file for more than this maximum retention period results in the file being locked until
the current system time plus the maximum retention period is reached. Specify Y for years, M for months, D for days, or
infinite. The default value for the maximum retention period is infinite, which means that the files can never be deleted.
Example:
To create an FLR-enabled file system ufs4, with a size of 100 GB, by using the clar_r5_performance pool, with file-level
retention set to enterprise, a minimum retention period of 30 days, a default retention period of 60 days, and a maximum
retention period of 10 years, type:
$ nas_fs -name ufs4 -create size=100G pool=clar_r5_performance worm=enterprise
-min_retention 30D -default_retention 60D -max_retention 10Y
Create an FLR-enabled file system
25
Configuring
Output
id
= 18
name
= ufs4
acl
= 0
in_use
= False
type
= uxfs
worm
= enterprise with no protected files
worm_clock= Clock not initialized
worm Max Retention Date= NA
worm Default Retention Period= 60 Days
worm Minimum Retention Period= 30 Days
worm Maximum Retention Period= 10 Years
FLR Auto_lock= off
FLR Policy Interval= 3600 seconds
FLR Auto_delete= off
FLR Epoch Year= 2003
volume
= v125
pool
= clar_r5_performance
member_of = root_avm_fs_group_3
rw_servers=
ro_servers=
rw_vdms
=
ro_vdms
=
auto_ext = no,thin=no
deduplication
= unavailable
stor_devs =
BB005056830430-0019,BB005056830430-0016,BB005056830430-0015,BB0050568304300010
disks
= d16,d13,d12,d7
Note
To enable file-level retention, the worm option can be set to either enterprise or compliance. Off disables file-level retention
capability. If a worm option is not specified, the default value is off.
26
Using VNX File-Level Retention
4
Managing Files in an
FLR-Enabled File System
The tasks to manage files in an FLR-enabled file system are:
◆
◆
◆
◆
◆
◆
◆
◆
View file permissions on page 28
Set a retention date on NFS on page 29
Set a retention date on CIFS on page 30
Verify the retention date setting on page 30
Lock a file on NFS on page 31
Lock a file on CIFS on page 32
Verify a file's locked state on page 32
Delete an expired file on page 33
Using VNX File-Level Retention
27
Managing Files in an FLR-Enabled File System
View file permissions
1. On the VNX for file, create a new file in an FLR-enabled file system.
2. Verify the file permission bits and LAT by typing:
$ ls -l --time-style=full-iso --time=atime
The command to list files is dependent on the client operating system.
Note: You can also use the ls -lu command to verify the file permission bits and LAT.
Output:
total 16
drwxr-xr-x
2 root
root
lost+found
-rw-r--r-1 32770 32770
New Text Document.txt
8192 2008-01-21 14:27:23.000000000 -0500
16 2008-01-21 14:42:18.000000000 -0500
Note: The write permission bit (-rw-r--r--) on the New Text Document.txt file indicates the file is
either not locked or in the append-only state.
28
Using VNX File-Level Retention
Managing Files in an FLR-Enabled File System
Set a retention date on NFS
Action
To set the retention date for an NFS file, use this command syntax:
$ touch -at <time> <filename>
where:
<time> = year, month, day, and hour of the retention date
<filename> = name of the file
For example:
To set the retention date for an NFS file to January 24, 2008, 8 a.m. from the CLI, type:
$ touch -at 200801240800 rp012408
Output
None
Notes
You can also set the retention date for a file on NFS from the application by using the utime system call. Transition between
states on page 17 provides more details about setting a retention date.
Dates between the current epoch year on the file system (default is 2003) and 2038 are set directly on the file. To set
dates beyond 2038, you need to set the atime of the file as an offset from January 1, 1970. Dates below the epoch year
set on the file system are mapped above 2038 by subtracting 1970 from the year portion of the file’s atime and adding the
remainder to 2038 to arrive at the desired retention date. For example, if you set the access time on the file to 1/1/1999,
when the file is locked, it is set with a retention date of 1/1/2067. This date was arrived at by using the following calculation:
2038+(1999-1970)=2067.
The current epoch year set on the file system is the maximum offset beyond 2038 that you can use. For example, with
the epoch year for the file system set to its default of 2003, any atime between January 1, 1970 and December 31, 2002
will be mapped above 2038 (by subtracting 1970 from the year portion of the file’s atime and adding the remainder to
2038). Adjusting the epoch year of the file system to its maximum of 2037 means that any date between January 1, 1970
and December 31, 2036 will be mapped above 2038. Therefore, the maximum retention date that you can set on a file is
December 31, 2104. For example, file system epoch year=2037; file atime=December 31, 2036; retention date becomes
2038+(2036-1970)=2104.
Set a retention date on NFS
29
Managing Files in an FLR-Enabled File System
Set a retention date on CIFS
Action
To set a retention date for a file on CIFS, use the WIN API SetFileTime function.
There is no standard Windows utility to set the file’s atime.
You can also use the FLR Toolkit to set a retention date. To access the FLR Toolkit, go to EMC Online Support. After
logging in to EMC Online Support, locate the applicable Support by Product page. Search for FLR Toolkit to access information for the FLR Toolkit.
Important: Windows Explorer does not contain the capability of setting a retention date for a file in an FLR-enabled file
system. If you want to use Windows Explorer to set or manage retention dates in an FLR-enabled file system, you must
install the FLR Toolkit.
Output
None
Verify the retention date setting
Action
To verify the retention date set on the file, type:
$ ls -l --time-style=long-iso --time=atime
Output
total 16
drwxr-xr-x
-rw--r--r--
2 root
1 32770
root
32770
8192 2008-01-21 14:27 lost+found
16 2008-01-24 08:00 New Text Document.txt
Note
The retention date is set to 2008-01-24 08:00 on the New Text Document.txt file.
30
Using VNX File-Level Retention
Managing Files in an FLR-Enabled File System
Lock a file on NFS
Action
To lock a file on NFS by changing a file’s access permission to read-only from the CLI, use this command syntax:
$ chmod -w <filename>
where:
<filename> = name of the file
You can also change a file’s access permission to read-only from an application by using the chmod system call to clear
all write permissions.
The chmod command can specify file permissions symbolically or numerically. Modify the permissions on a file by using
the combination that best suits the requirements. The execute permission does not prevent the file-level retention lock.
The chmod a-w <filename> command is an alternate option to chmod 444 <filename>.
Output
None
Lock a file on NFS
31
Managing Files in an FLR-Enabled File System
Lock a file on CIFS
Action
To lock a file on CIFS, change a file’s access permission to read-only by using one of the following methods:
◆
Use WIN API to call the SetFileAttributes function.
◆
From a Windows client, set the file attribute to read-only.
◆
From a Windows client, run the ATTRIB command. You can also lock a file by using the FLR Toolkit, which contains
a suite of applications that enables users to manage the states of files in an FLR-enabled file system. To access the
FLR Toolkit, go to EMC Online Support. After logging in to EMC Online Support, locate the applicable Support by
Product page. Search for FLR Toolkit to access information for the FLR Toolkit.
Output
None
Important Notes
◆
If you use Windows Explorer to make a file in an FLR file system read-only, it sets the atime of the file to the current
date and time before making it read-only. This results in locking the file for the default retention period in effect on the
file system. If you want to use Windows Explorer to lock files in an FLR-enabled file system, you must install the FLR
Toolkit.
◆
For systems that use version 7.0 and earlier, when using Windows Explorer to copy read-only files either into or
within an FLR file system, or between FLR file systems, the protection state of the file's copy depends on whether the
Windows client making the copy uses the SMB1 or SMB2 protocol. If the Windows client uses SMB1, then the destination file will be read-only, but not protected. If the Windows client uses SMB2, the destination file will be read-only
and locked with an infinite retention date. This infinite date can be reduced in an FLR-E file system, but not in an FLRC file system. Turning off the read-only bit on the source files (if possible) before copying them will avoid any potential
confusion.
◆
For systems that use version 7.1 and later, when using Windows Explorer to copy read-only files either into or within
an FLR file system, or between FLR file systems, the protection state of the file's copy depends on whether the Windows
client making the copy uses the SMB1 or SMB2 protocol. If the Windows client uses SMB1, then the destination file
will be read-only, but not protected. If the Windows client uses SMB2, the destination file will be read-only and locked
for the default retention period configured on the file system.Turning off the read-only bit on the source files (if possible)
before copying them will avoid any potential confusion.
Verify a file's locked state
Action
To verify that a file is locked, type:
$ ls -l --time-style=long-iso --time=atime
32
Using VNX File-Level Retention
Managing Files in an FLR-Enabled File System
Output
total 16
drwxr-xr-x
-r--r--r--
2 root
1 32770
root
32770
8192 Jan 21 14:27 lost+found
16 2008-01-24 08:00 New Text Document.txt
Note
The permission bits for the New Text Document.txt file have changed from rw to r. read-only indicates the file is locked.
Ensure that the file's LAT is a future time or the retention time is set to the file system default.
Delete an expired file
1. Verify the date and time on the Data Mover by typing:
$ server_date server_2
Output:
server_2 : Thu Jan 24 08:20:20 EST 2008
2. Verify the date and time on the saved file by typing:
$ ls -l --time-style=long-iso --time=atime
Output:
total 16
drwxr-xr-x
2 root
-r--r--r-1 32770
Document.txt
root
32770
8192 2008-01-21 14:27 lost+found
16 2008-01-21 08:00 New Text
The retention date 2008-01-21 08:00 on the New Text Document.txt file is less than the
date and time of the file system's FLR clock, Thu Jan 24 08:20:20 EST 2008, which indicates
the file is in the expired state.
Note: If a file is not in the expired state, any attempt to delete the file will fail.
3. Delete the expired file.
Delete an expired file
33
Managing Files in an FLR-Enabled File System
34
Using VNX File-Level Retention
5
Managing an FLR-Enabled
File System
The tasks to manage an FLR-enabled file system are:
◆
◆
◆
◆
◆
◆
◆
◆
◆
Query an FLR-enabled file system on page 36
Modify a retention period for a file system on page 37
Reset an epoch date on page 39
Enable automatic file locking on page 40
Enable automatic file deletion on page 42
Set write verification on page 43
Restore a checkpoint to an FLR-E–enabled file system on page 43
Copy existing files to an FLR-enabled file system on page 44
Delete an FLR-enabled file system on page 44
Using VNX File-Level Retention
35
Managing an FLR-Enabled File System
Query an FLR-enabled file system
Action
To query an FLR-enabled file system to determine if it is enabled for file-level retention, and display an FLR clock value,
retention dates, automatic file lock value, and automatic file delete value, use this command syntax:
$ nas_fs -info <fs_name>
where:
<fs_name> = name of the file system
Example:
To query the file system ufs4, type:
$ nas_fs -info ufs4
Output
id
= 16
name
= ufs4
acl
= 0
in_use
= False
type
= uxfs
worm
= enterprise with no protected files
worm_clock= Clock not initialized
worm Max Retention Date= NA
worm Default Retention Period= infinite
worm Minimum Retention Period= 1 Day
worm Maximum Retention Period= infinite
FLR Auto_lock= off
FLR Policy Interval= 3600 seconds
FLR Auto_delete= off
FLR Epoch Year= 2003
volume
= v121
pool
= clar_r5_performance
member_of = root_avm_fs_group_3
rw_servers=
ro_servers=
rw_vdms
=
ro_vdms
=
auto_ext = no,thin=no
deduplication
= unavailable
thin_storage = True
tiering_policy = Auto-tier
compressed= False
mirrored = False
auto_provision= False
stor_devs =
BB005056830430-0019,BB005056830430-0016
disks
= d16,d13
36
Using VNX File-Level Retention
Managing an FLR-Enabled File System
Note
◆
The worm (FLR) option for the ufs4 file system is worm=enterprise with no protected files to indicate the file system
is enabled for file-level retention but no files are locked. This option could also be set to worm=compliance. When a
file system is not enabled for file-level retention, the worm option is worm=off.
◆
The following data appears only if worm=enterprise or compliance:
◆
◆
worm_clock
◆
worm Max Retention Date
◆
worm Default Retention Period
◆
worm Minimum Retention Period
◆
worm Maximum Retention Period
◆
FLR Auto_lock
◆
FLR Policy Interval
◆
FLR Auto_delete
◆
FLR Epoch Year
The FLR clock stops ticking when the file system is mounted read-only or is unmounted.
Modify a retention period for a file system
You can modify the default, minimum, and maximum retention periods for a file system.
Modifying a retention period value does not affect files that are currently locked in a file
system.
Action
To modify a retention period for a file system, use this command syntax:
$ nas_fs -modify <fsname> -worm [-default_retention {<def_integer>{Y|M|D}
|infinite}] [-min_retention {<min_integer>{Y|M|D}|infinite}]
[-max_retention {<max_integer>{Y|M|D}|infinite}]
where:
<fsname> = name of the file system
<def_integer> = default retention period that is used in an FLR-enabled file system when a file is locked and a retention
period is not specified. This value must be greater than or equal to the minimum retention period, and less than or equal
to the maximum retention period. Specify Y for years, M for months, D for days, or infinite. The default value for the default
retention period is infinite, which means that the files can never be deleted.
<min_integer> = shortest retention period for which files on an FLR-enabled file system can be locked and protected
from deletion. This value must be less than or equal to the maximum retention period. Any attempt to lock a file for less
than the minimum retention period results in the file being locked until the current system time plus the minimum retention
period is reached. Specify Y for years, M for months, D for days, or infinite. The default value for the minimum retention
period is 1 day. Setting infinite means that the files can never be deleted.
Modify a retention period for a file system
37
Managing an FLR-Enabled File System
Action
<max_integer> = longest retention period for which files on an FLR-enabled file system can be locked and protected
from deletion. Any attempt to lock a file for more than this maximum retention period results in the file being locked until
the current system time plus the maximum retention period is reached. Specify Y for years, M for months, D for days, or
infinite. The default value for the maximum retention period is infinite, which means that the files can never be deleted.
Example:
To modify FLR file system worm_ufs2 with a default retention period of 5 years, type:
$ nas_fs -modify worm_ufs2 -worm -default_retention 5Y
Output
id
= 40
name
= worm_ufs2
acl
= 0
in_use
= True
type
= uxfs
worm
= enterprise with no protected files
worm_clock= Fri Jul 29 11:14:27 EDT 2011
worm Max Retention Date= No protected files created
worm Default Retention Period= 5 Years
worm Minimum Retention Period= 30 Days
worm Maximum Retention Period= 5 Years
FLR Auto_lock= off
FLR Policy Interval= 3600 seconds
FLR Auto_delete= off
FLR Epoch Year= 2003
volume
= v117
pool
= clar_r5_performance
member_of = root_avm_fs_group_3
rw_servers= server_2
ro_servers=
rw_vdms
=
ro_vdms
=
auto_ext = no,thin=no
deduplication
= Off
stor_devs =
BB005056830430-0019,BB005056830430-0016
disks
= d16,d13
disk=d16
stor_dev=BB005056830430-0019 addr=c0t1l9
disk=d16
stor_dev=BB005056830430-0019 addr=c16t1l9
disk=d13
stor_dev=BB005056830430-0016 addr=c0t1l6
disk=d13
stor_dev=BB005056830430-0016 addr=c16t1l6
38
Using VNX File-Level Retention
server=server_2
server=server_2
server=server_2
server=server_2
Managing an FLR-Enabled File System
Reset an epoch date
Action
To reset an epoch date, use this command syntax:
$ -modify <fs_name> -worm -reset_epoch <year>
where:
<fs_name> = name of the file system
<year> = epoch value used to calculate the maximum date that locked files can be retained. Type an integer from 2000
to 2037. The default value is 2003.
Example:
To reset the FLR epoch date for file system ufs4 to 2000, type:
$ nas_fs -modify ufs4 -worm -reset_epoch 2000
Output
id
= 14
name
= ufs4
acl
= 0
in_use
= True
type
= uxfs
worm
= enterprise with no protected files
worm_clock= Fri Jul 29 12:18:36 EDT 2011
worm Max Retention Date= No protected files created
worm Default Retention Period= 10 Years
worm Minimum Retention Period= 30 Days
worm Maximum Retention Period= 11 Years
FLR Auto_lock= off
FLR Policy Interval= 3600 seconds
FLR Auto_delete= off
FLR Epoch Year= 2000
volume
= v117
pool
= clar_r5_performance
member_of = root_avm_fs_group_3
rw_servers= server_2
ro_servers=
rw_vdms
=
ro_vdms
=
auto_ext = no,thin=no
deduplication
= Off
stor_devs =
BB005056830430-0019,BB005056830430-0016
disks
= d16,d13
disk=d16
stor_dev=BB005056830430-0019 addr=c0t1l9
disk=d16
stor_dev=BB005056830430-0019 addr=c16t1l9
disk=d13
stor_dev=BB005056830430-0016 addr=c0t1l6
disk=d13
stor_dev=BB005056830430-0016 addr=c16t1l6
server=server_2
server=server_2
server=server_2
server=server_2
Reset an epoch date
39
Managing an FLR-Enabled File System
Note
For systems that use version 7.0 and earlier, you can set a maximum retention year of 2038. For systems that use version
7.1 and later, by using the epoch value you can now set a maximum value for the retention period up to December 31,
2104 11:59:59 p.m. Trying to set a date beyond this value generates an error.
Enable automatic file locking
Action
To enable automatic file locking in an FLR-enabled file system, use this command syntax:
$ -modify <fs_name> -worm [-auto_lock {enable[-policy_interval <integer>
{M|D|H}]|disable}]
where:
<fs_name> = name of the file system.
<integer> = an interval for how long to wait after files are modified before the files are automatically locked in an FLR-
enabled file system.Type an integer and specify M for minutes, D for days, or H for hours.The policy interval has a minimum
value of 1 minute and a maximum value of 366 days. The default value is 1 hour.
Example:
To enable FLR automatic file locking with a policy interval of 30 minutes for file system ufs4, type:
$ nas_fs -modify ufs4 -worm -auto_lock enable -policy_interval 30M
40
Using VNX File-Level Retention
Managing an FLR-Enabled File System
Output
id
= 14
name
= ufs4
acl
= 0
in_use
= True
type
= uxfs
worm
= enterprise with no protected files
worm_clock= Fri Jul 29 12:24:44 EDT 2011
worm Max Retention Date= No protected files created
worm Default Retention Period= 10 Years
worm Minimum Retention Period= 30 Days
worm Maximum Retention Period= 11 Years
FLR Auto_lock= on
FLR Policy Interval= 1800 seconds
FLR Auto_delete= off
FLR Epoch Year= 2000
volume
= v117
pool
= clar_r5_performance
member_of = root_avm_fs_group_3
rw_servers= server_2
ro_servers=
rw_vdms
=
ro_vdms
=
auto_ext = no,thin=no
deduplication
= Off
stor_devs =
BB005056830430-0019,BB005056830430-0016
disks
= d16
disk=d16
stor_dev=BB005056830430-0019 addr=c0t1l9
disk=d16
stor_dev=BB005056830430-0019 addr=c16t1l9
server=server_2
server=server_2
Note
Most file copy tools preserve the last modified time of a file being copied. When copying files into an FLR file system with
automatic file locking enabled, if you did not modify files to copy within the automatic file lock policy interval specified on
the FLR file system, the file copies are locked almost immediately after being copied into the FLR file system. The files
immediately meet the criteria for being locked automatically. For example, the lock policy interval is set to 30 minutes. File
A was modified 15 minutes ago. File B was modified 60 minutes ago. File A is not locked when copied into the FLR file
system because its modification time is less than the lock policy interval. However, File B is locked when copied into the
FLR file system because its modification time is more than the lock policy interval.
Enable automatic file locking
41
Managing an FLR-Enabled File System
Enable automatic file deletion
Action
To enable automatic file deletion in an FLR-enabled file system, use this command syntax:
$ -modify <fs_name> -worm [-auto_delete {enable|disable}]
where:
<fs_name> = name of the file system
Example:
To enable FLR automatic file deletion for file system ufs4, type:
$ nas_fs -modify ufs4 -worm -auto_delete enable
Output
id
= 14
name
= ufs4
acl
= 0
in_use
= True
type
= uxfs
worm
= enterprise with no protected files
worm_clock= Fri Jul 29 12:26:42 EDT 2011
worm Max Retention Date= No protected files created
worm Default Retention Period= 10 Years
worm Minimum Retention Period= 30 Days
worm Maximum Retention Period= 11 Years
FLR Auto_lock= on
FLR Policy Interval= 1800 seconds
FLR Auto_delete= on
FLR Epoch Year= 2000
volume
= v117
pool
= clar_r5_performance
member_of = root_avm_fs_group_3
rw_servers= server_2
ro_servers=
rw_vdms
=
ro_vdms
=
auto_ext = no,thin=no
deduplication
= Off
stor_devs =
BB005056830430-0019,BB005056830430-0016
disks
= d16,d13
disk=d16
stor_dev=BB005056830430-0019 addr=c0t1l9
disk=d16
stor_dev=BB005056830430-0019 addr=c16t1l9
disk=d13
stor_dev=BB005056830430-0016 addr=c0t1l6
disk=d13
stor_dev=BB005056830430-0016 addr=c16t1l6
42
Using VNX File-Level Retention
server=server_2
server=server_2
server=server_2
server=server_2
Managing an FLR-Enabled File System
Set write verification
Action
To set write verification, use this command syntax:
$ server_param <movername> -facility FLRCompliance -modify writeverify
-value <new_value>
where:
<movername> = name of the Data Mover
<new_value> = enable (1) or disable (0) the write verification capability. The range of values is 0 to 1, and the default
value is 1.
Example:
To enable write verification on server_2, type:
$ server_param server_2 -facility FLRCompliance -modify writeverify
-value 1
Output
server_2 : done
Restore a checkpoint to an FLR-E–enabled file system
Action
To restore a checkpoint to an FLR-E–enabled file system, use this command syntax:
$ /nas/sbin/rootfs_ckpt <fs_name_ckpt1> -name <fs_name_ckpt2> -Restore -Force
where:
<fs_name_ckpt1> = name of the checkpoint that will be restored to the PFS
<fs_name_ckpt2> = name for the new checkpoint automatically created in the restore process
If no name is specified, the system creates the new checkpoint by using a standard naming convention.
Note
The -Force option must be used to restore an FLR-E–enabled file system. Otherwise, the restore operation fails with an
error: “requires -Force option.”
Set write verification
43
Managing an FLR-Enabled File System
Copy existing files to an FLR-enabled file system
You can use a variety of tools, such as VNX File System Migration (also known as CDMS)
and emcopy, to copy files or an entire file system to an FLR-enabled file system. Upon
completion of the read-only file copy:
1. Change permission on the file to read/write.
2. Set a retention date.
3. Lock the file.
Delete an FLR-enabled file system
You can delete an FLR-E–enabled file system, with and without locked files. You can delete
an FLR-C–enabled file system without locked files, but you cannot delete an FLR-C–enabled
file system with locked files.
Action
To delete an FLR-enabled file system, use this command syntax:
$ nas_fs -delete <fs_name> -Force
where:
<fs_name> = name of the file system
Example:
To delete an FLR-E–enabled file system worm_ufs1, type:
$ nas_fs -delete worm_ufs1 -Force
Output:
id
= 805
name
= worm_ufs1
acl
= 0
in_use
= False
type
= uxfs
worm
= enterprise
volume
= v630
rw_servers=
ro_servers=
rw_vdms
=
ro_vdms
=
auto_ext = no,thin=no
stor_devs = APM00043305843-000D,APM00043305843-0008,APM00043305843-0017,
APM00043305843-0013
disks
= d26,d14,d21,d8
Example:
To delete an FLR-C–enabled file system worm_ufs2, type:
$ nas_fs -delete worm_ufs2
44
Using VNX File-Level Retention
Managing an FLR-Enabled File System
Action
Output:
Error 13423542289: File system worm_ufs2 cannot be deleted because it
contains protected files.
Note
The -Force option must be used to delete an FLR-E file system with file-level retention enabled. Otherwise, the delete
operation fails with an error: “must specify -Force to delete WORM filesystem.”
Delete an FLR-enabled file system
45
Managing an FLR-Enabled File System
46
Using VNX File-Level Retention
6
Troubleshooting
As part of an effort to continuously improve and enhance the performance
and capabilities of its product lines, EMC periodically releases new versions
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, contact your EMC Customer Support Representative.
Problem Resolution Roadmap for VNX contains additional information about
using EMC Online Support and resolving problems.
Topics included in this chapter are:
◆
◆
◆
◆
◆
EMC E-Lab Interoperability Navigator on page 48
VNX user customized documentation on page 48
Known problems on page 48
Error messages on page 48
EMC Training and Professional Services on page 49
Using VNX File-Level Retention
47
Troubleshooting
EMC E-Lab Interoperability Navigator
The EMC E-Lab™ Interoperability Navigator is a searchable, web-based application that
provides access to EMC interoperability support matrices. It is available on EMC Online
Support at http://Support.EMC.com. After logging in, in the right pane under Product and
Support Tools, click E-Lab Navigator.
VNX user customized documentation
EMC provides the ability to create step-by-step planning, installation, and maintenance
instructions tailored to your environment. To create VNX user customized documentation,
go to: https://mydocs.emc.com/VNX.
Known problems
Table 2 on page 48 describes known problems that might occur when using file-level
retention, and presents workarounds.
Table 2. Known problems and workarounds
Known problem
Workaround
The current state of the file is not visible Check the permissions on the file. A file with read-only permission is either
to the user.
locked or in the expired state. If the LAT of the file is less than the current
time on the Data Mover, the file is in the expired state.
Cannot easily distinguish between a
Set the LAT to an earlier date and time.
locked file and a read-only file that is
copied or transferred through FTP in to a ◆ If the operation fails, the file is locked.
file system with file-level retention en◆
If the operation succeeds, the file is not locked.
abled.
Error messages
All event, alert, and status messages provide detailed information and recommended actions
to help you troubleshoot the situation.
To view message details, use any of these methods:
◆
Unisphere software:
•
◆
48
Right-click an event, alert, or status message and select to view Event Details, Alert
Details, or Status Details.
CLI:
Using VNX File-Level Retention
Troubleshooting
•
◆
Celerra Error Messages Guide:
•
◆
Type nas_message -info <MessageID>, where <MessageID> is the message
identification number.
Use this guide to locate information about messages that are in the earlier-release
message format.
EMC Online Support:
•
Use the text from the error message's brief description or the message's ID to search
the Knowledgebase on EMC Online Support. After logging in to EMC Online Support,
locate the applicable Support by Product page, and search for the error message.
EMC Training and Professional Services
EMC Customer Education courses help you learn how EMC storage products work together
within your environment to maximize your entire infrastructure investment. EMC Customer
Education features online and hands-on training in state-of-the-art labs conveniently located
throughout the world. EMC customer training courses are developed and delivered by EMC
experts. Go to EMC Online Support at http://Support.EMC.com for course and registration
information.
EMC Professional Services can help you implement your system efficiently. Consultants
evaluate your business, IT processes, and technology, and recommend ways that you can
leverage your information for the most benefit. From business plan to implementation, you
get the experience and expertise that you need without straining your IT staff or hiring and
training new personnel. Contact your EMC Customer Support Representative for more
information.
EMC Training and Professional Services
49
Troubleshooting
50
Using VNX File-Level Retention
Appendix A
CIFS and NFS API Details for
Managing Files
Topics included are:
◆
◆
◆
◆
◆
◆
Overview on page 52
Set or extend the retention date for an NFS file on page 52
Set or extend the retention date for a CIFS file on page 52
Lock a file from an NFS client on page 53
Lock a file from a CIFS client on page 53
Delete a locked file from an NFS or CIFS client on page 54
Using VNX File-Level Retention
51
CIFS and NFS API Details for Managing Files
Overview
File-level retention does not require a separate API, although an API is available through
the EMC Velocity Partner program that allows you to perform more complex tasks. File-level
retention works by enhancing standard NFS and CIFS requests with new semantics when
targeting an FLR-enabled file system. Application programs can use standard file access
APIs for manipulating FLR files. Each operation is described as to how it is encoded within
the NFS or CIFS protocol, and how it is invoked by using standard file access APIs.
Set or extend the retention date for an NFS file
Operation description: The application sets the retention date for a file from an NFS client.
Prerequisite: The file is stored on an FLR-enabled file system.
Protocol description: Involves the NFS setAttr procedure with an explicit value provided
for the atime attribute, which corresponds to a future time.
Interface description: An application should use a system call to change the file's LAT
attribute to the appropriate expiration time of the retention date. The utime system call
works on standard UNIX and Linux systems. From the command line, a user can use the
touch command to change the file's LAT attribute to the desired retention date’s expiration
time.
Errors: If the file is locked, the retention date cannot be shortened. If the new access time
specified is earlier than the current access time for the file, the server rejects the command.
Set or extend the retention date for a CIFS file
Operation description: The application sets the retention date for a file from a CIFS client.
Important: Windows Explorer does not contain the capability of setting a retention date for a file in an
FLR-enabled file system. If you want to use Windows Explorer to set or manage retention dates in an
FLR-enabled file system, you must install the FLR Toolkit. To access the FLR Toolkit, go to EMC Online
Support. After logging in to EMC Online Support, locate the applicable Support by Product page.
Search for FLR Toolkit to access information for the FLR Toolkit.
Prerequisite: The file is stored on an FLR-enabled file system.
Protocol description: Involves CIFS transactions TRANS2_SET_PATH_INFORMATION or
TRANS2_SET_FILE_INFORMATION, which use the SMB_INFO_STANDARD information
level to set the LastAccessTime field to a value representing a future time.
Interface description: The Windows setFileTime function sets the date and time a file was
created, last accessed, or last modified:
52
Using VNX File-Level Retention
CIFS and NFS API Details for Managing Files
BOOL SetFileTime(
HANDLE hFile,
const FILETIME *lpCreationTime,
const FILETIME *lpLastAccessTime,
const FILETIME *lpLastWriteTime);
Errors: If the file is locked, the retention date cannot be shortened. If the new access time
specified is earlier than the current access time for the file, the server rejects the command.
Lock a file from an NFS client
Operation description: The application locks a file from an NFS client.
Protocol description: Involves an NFS setAttr request with a value for the Mode field in
which each of the write permission bits (owner, group, and others) are set to zero.
Interface description: An application needs to clear three write permission bits (owner,
group, and others) in the file's mode bits by using a system call chmod, which works on
standard UNIX and Linux systems. From the command line, a user can run the chmod
command to clear three write permission bits in the file's mode bits.
Lock a file from a CIFS client
Operation description: The application locks the file from a CIFS client.
Important: If you use Windows Explorer to make a file in an FLR file system read-only, it sets the atime
of the file to the current date and time before making it read-only. This results in locking the file for
the default retention period in effect on the file system. If you want to use Windows Explorer to lock
files in an FLR-enabled file system, install the FLR Toolkit which contains a suite of applications that
enables users to manage the states of files in an FLR-enabled file system. To access the FLR Toolkit,
go to EMC Online Support. After logging in to EMC Online Support, locate the applicable Support
by Product page. Search for FLR Toolkit to access information for the FLR Toolkit.
For systems that use version 7.0 and earlier, when using Windows Explorer to copy read-only files
either into or within an FLR file system, or between FLR file systems, the protection state of the file's
copy depends on whether the Windows client making the copy uses the SMB1 or SMB2 protocol. If
the Windows client uses SMB1, then the destination file will be read-only, but not protected. If the
Windows client uses SMB2, the destination file will be read-only and locked with an infinite retention
date. This infinite date can be reduced in an FLR-E file system, but not in an FLR-C file system. Turning
off the read-only bit on the source files (if possible) before copying them will avoid any potential
confusion.
For systems that use version 7.1 and later, when using Windows Explorer to copy read-only files either
into or within an FLR file system, or between FLR file systems, the protection state of the file's copy
depends on whether the Windows client making the copy uses the SMB1 or SMB2 protocol. If the
Windows client uses SMB1, then the destination file will be read-only, but not protected. If the Windows
client uses SMB2, the destination file will be read-only and locked for the default retention period
configured on the file system. Turning off the read-only bit on the source files (if possible) before
copying them will avoid any potential confusion.
Lock a file from an NFS client
53
CIFS and NFS API Details for Managing Files
Protocol description: Involves CIFS transactions TRANS2_SET_PATH_INFORMATION or
TRANS2_SET_FILE_INFORMATION, which use the SMB_INFO_STANDARD information
level to set the FILE_ATTRIBUTE_READONLY bit in the Attributes field.
Interface description: An application needs to set the read-only attribute for the file. The
Windows setFileAttributes function sets a file's attributes:
BOOL SetFileAttributes(
LPCTSTR lpFileName,
DWORD dwFileAttributes);
From the user interface (such as Windows Explorer), a user can set the read-only attribute
of a file by using the Properties ➤ General tab.
Note: File-level retention mandates the synchronization of the DOS read-only bit and the UNIX mode
bits.
Delete a locked file from an NFS or CIFS client
Operation description: The application or user deletes a file from an NFS or CIFS client that
has been previously locked.
Prerequisite: The retention date set for the file has passed. When a file is in the expired state,
it can be deleted.
Protocol description: Involves a standard NFS or CIFS file deletion request.
Interface description: Standard file deletion system call or user interface command.
54
Using VNX File-Level Retention
Appendix B
SEC Ruling 17a-4(f)
Requirements
This section includes information about the SEC ruling requirements and
how FLR handles the requirements.
Topics included are:
◆
◆
SEC ruling on page 56
EMC file-level retention with compliance on page 57
Using VNX File-Level Retention
55
SEC Ruling 17a-4(f) Requirements
SEC ruling
This section explains the SEC ruling 17a-4(f) requirements.
If electronic storage media is used by a member, broker, or dealer, it shall comply with the
following requirements:
56
◆
The member, broker, or dealer must notify its examining authority designated pursuant
to section 17(d) of the Act prior to employing electronic storage media. If employing any
electronic storage media other than optical disk technology (including CD-ROM), the
member, broker, or dealer must notify its designated examining authority at least 90
days prior to employing such storage media. In either case, the member, broker, or dealer
must provide its own representation or one from the storage medium vendor or other
third party with appropriate expertise that the selected storage media meets the conditions
set forth in this paragraph (f)(2).
◆
The electronic storage media must:
•
Preserve the records exclusively in a non-rewritable, non-erasable format.
•
Verify automatically the quality and accuracy of the storage media recording process.
•
Serialize the original and, if applicable, duplicate units of storage media, and time-date
for the required period of retention the information placed on such electronic storage
media.
•
Have the capacity to readily download indexes and records preserved on the electronic
storage media to any medium acceptable under this paragraph (f) as required by the
Commission or the self-regulatory organizations of which the member, broker, or
dealer is a member.
Using VNX File-Level Retention
SEC Ruling 17a-4(f) Requirements
EMC file-level retention with compliance
Refer to EMC Online Support for the EMC white paper.
To address the first requirement of SEC rule 17a-4(f), FLR-C is designed to prevent any
modification or deletion of locked files (records) by both users and administrators until a
specified retention date has passed.
To address the second requirement of SEC rule 17a-4(f) and ensure the quality and accuracy
of the storage media recording process for data written into an FLR-C–enabled file system,
block level checksums (bit-level verification codes) and bit-level verification (also known
as a “disk scrubbing”) are used:
◆
Block level checksums are calculated at the time of recording and maintained by the disk
storage system. These checksums are verified by the disk storage system when data is
read back from disk to ensure it has not been altered since it was written.
◆
Periodically, a bit-level verification of the physical storage media and block checksums
is performed to ensure that there are no hard failures at the media level.
To address the third requirement of SEC rule 17a-4(f), all files (records) created in an
FLR-C–enabled file system have a name (the full directory path and filename) that uniquely
identifies them. The “last modified” timestamp records the time at which the files were last
written to before being locked. For those files that are locked, the “last access time” timestamp
records the date until which they will be retained.
To address the fourth requirement of SEC rule 17a-4(f), as well as customers’ own
requirements, both the record names and timestamps (metadata) and the content of the
records (data) stored in an FLR-C–enabled file system can be one of the following:
◆
Copied by using standard network data access protocols such as CIFS and NFS
◆
Replicated to an alternate location by using EMC VNX SRDF®, EMC VNX MirrorView™,
or VNX Replicator
◆
Backed up by using NDMP
The rule also requires that organizations provide “an audit system providing for
accountability regarding the inputting of records into the storage system.” The FLR activity
log maintained in each FLR file system is intended to be used in support of this requirement.
EMC believes that the functionality provided in the compliance version of VNX FLR satisfies
the requirements of the US Exchange and Securities Commission (SEC) rule 17a-4(f).
In addition to what is described above, while FLR provides protection for your data from
harm, there are some scenarios and situations which are beyond the control of the system,
and therefore may result in data loss.
The following are some scenarios that may occur but are beyond the scope of the FLR and
SEC requirements:
EMC file-level retention with compliance
57
SEC Ruling 17a-4(f) Requirements
◆
FLR does not by itself offer any protection against the physical failure of disk drives or
storage arrays. Protection of data from these types of failure relies on mechanisms such
as RAID and replication of data to a second site.
◆
FLR does not protect data against the actions of anyone who has physical access to the
system. For example, someone could manually remove and destroy disk drives and
thereby destroy the data they contain.
◆
FLR does not offer any protection to FLR file systems affected by corruption of the VNX
system configuration database or software bugs. The system will automatically detect
corruption of its configuration database and “dial-home.”
◆
FLR does not provide any protection against someone with access to the VNX storage
array management tools that can delete (or unbind) the LUNs (disks) that a file system
is built on, thereby destroying the file system itself and the data it contains. This type of
attack:
•
Cannot be targeted at specific files. The entire file system is destroyed.
•
Is unlikely to go unnoticed. One or more file systems will disappear and the Data
Mover will panic.
•
Destroys data rather than allowing it to be modified.
For these reasons and others, it is important to physically maintain either backups or replicas
of file systems, and to logically separate them from the file system production copy by using
features such as SnapSure, VNX Replicator, and offsite backups.
58
Using VNX File-Level Retention
Appendix C
FLR Activity Log File
Topics included are:
◆
◆
Overview on page 60
Log file events on page 60
Using VNX File-Level Retention
59
FLR Activity Log File
Overview
By default, the VNX system logs all activity associated with successfully changing or
attempting to change protected data on an FLR-enabled file system. These events are logged
to a log file in the FLR-logs sub-directory of the root directory of the file system.
The activity log file is an append-only file which grows to approximately 10 MB in size. The
log file is named flrLogyyyymmddhhmm where the yyyymmddhhmm timestamp suffix is
the FLR clock time when the file was created. When it reaches its maximum size, a new
activity log file is created. Old log files are converted to FLR files with a retention date that
is set to the maximum retention date of files that the activity log refers to. This means that
the activity log is retained at least as long as any of the files to which it refers.
The administrator must delete old log files.
Log file events
The following events are captured in the FLR activity log file:
◆
An append-only file is created.
◆
A file is set to the locked state.
◆
A retention date is extended for a locked or expired file.
◆
An operation is attempted on a locked or expired file to make it writable.
◆
An operation deletes or attempts to delete a protected (locked, expired, append-only)
file.
Note: When a Windows CIFS client deletes an empty expired file, the FLR activity log records this as
the creation of an append-only file, followed by its deletion. This is because when deleting read-only
files, Windows clients first make the file writable. The empty expired file becomes an append-only
file, and then the Windows clients delete the file. The message states that an append-only file was
deleted.
The following associated information for each event is captured in the FLR log file:
60
◆
Time of event, relative to the FLR clock maintained for the file system.
◆
Event action, such as create an append-only file.
◆
Inode number and generation count number of the file to which the event applies. The
inode number and generation count of a file uniquely identify it.
◆
The UID and GID (user identifier) of the user who performed or attempted the action.
◆
Event-specific information:
•
For a locked file, the new retention date and time
•
For the extension of the retention date and time, the new retention date and time
Using VNX File-Level Retention
FLR Activity Log File
•
For a delete or attempted delete operation, whether the operation succeeded or failed
Table 3 on page 61 provides a brief description of an activity log event and an example.
Table 3. Activity log events
Brief description
Log example
User created an append-only file.
Sun Oct 19 14:48:40 2008 : Create a worm append-only file
: Inode No = 26 : Generation No = 1224427648 : Uid = 201
: Gid = 201 : FileMode = 664 : RP = Infinite : Passed
User locked a file with a retention date that is specified by
the value of the last access time of the file.
Tue Oct 14 09:35:38 2008 : Worm commit clean file : Inode
No = 1082 : Generation No = 1223984104 : Uid = 0 : Gid =
1 : FileMode = 444 : RP = Tue Oct 21 09:35:37 2008 :
Passed
User extended the retention date of a locked file.
Wed Oct 15 07:39:26 2008 : Extend Retention Period on
worm committed file : Inode No = 22 : Generation No =
1224056308 : Uid = 201 : Gid = 201 : FileMode = 444 : Old
RP = Wed Oct 15 07:40:00 2008 : New RP = Wed Oct 15
07:50:00 2008 : Passed
User extended the retention date of an expired file. It becomes locked again.
Sun Oct 19 14:54:24 2008 : Extend Retention Period on
worm expired file : Inode No = 21 : Generation No =
1224427555 : Uid = 201 : Gid = 201 : FileMode = 444 : Old
RP = Sun Oct 19 14:47:00 2008 : New RP = Sun Oct 19
15:15:00 2008 : Passed
User attempted to make a locked file writeable. This should Sun Oct 19 15:57:48 2008 : Make writeable worm committed
fail.
file : Inode No = 24 : Generation No = 1224431800 : Uid =
201 : Gid = 201 : FileMode = 664 : RP = Sun Oct 19 16:30:00
2008 : Failed
User locked an append-only file and it became a standard
locked file.
Sun Oct 19 17:19:12 2008 : Worm commit worm appendonly file : Inode No = 26 : Generation No = 1224436571 :
Uid = 201 : Gid = 201 : FileMode = 444 : RP = Infinite :
Passed
User attempted to delete a locked file. This should fail.
Tue Oct 14 09:43:42 2008 : Delete worm committed file :
Inode No = 6567 : Generation No = 1223980799 : Uid = 0 :
Gid = 0 : FileMode = 444 : RP = Tue Oct 14 09:55:00 2008
: Failed
User deleted an expired file.
Sun Oct 19 14:56:28 2008 : Delete worm expired file : Inode
No = 19 : Generation No = 1224427141 : Uid = 201 : Gid =
201 : FileMode = 444 : RP = Sun Oct 19 14:44:00 2008 :
Passed
User attempted to delete an append-only file. This should
fail.
Tue Oct 14 10:53:49 2008 : Delete worm append-only file :
Inode No = 15 : Generation No = 1223988975 : Uid = 0 :
Gid = 0 : FileMode = 644 : RP = Infinite : Failed
Log file events
61
FLR Activity Log File
Table 3. Activity log events (continued)
Brief description
Log example
User attempted to rename or move a directory with a locked N/A
file in it. The rename or move should fail but a message will
not be logged in the activity log.
User attempted to modify the existing content of an append- N/A
only file. The operation should fail but a message will not be
logged in the activity log.
Finding a file
To find a file, search the file system from an NFS client by using the UNIX find utility.
Use this command syntax:
$ find . -inum <inode_number> -print
where:
<inode_number> = “Inode No” from the log message
Finding a username from a UID
To get a username from the corresponding UID, on the Control Station’s CLI use this
command syntax:
$ server_cifssupport <movername> -list -secmap -uid <uid>
where:
<movername> = the name of the Data Mover that is hosting the FLR file system
<uid> = “Uid” from the log message
If the UID is not found by using the command above, then the UID was supplied by an
NFS client. Query the UNIX client nameservice instead.
Finding a username from a GID
To get a username from the corresponding GID, on the Control Station’s CLI use this
command syntax:
$ server_cifssupport <movername> -list -secmap -gid <gid>
where:
<movername> = the name of the Data Mover that is hosting the FLR file system
<gid> = “Gid” from the log message
If the GID is not found by using the command above, then the GID was supplied by an
NFS client. Query the UNIX client nameservice instead.
62
Using VNX File-Level Retention
Glossary
A
append-only state
State of a file when the data in it cannot be modified, but the file can have new data appended
to the end of it. In addition, the file itself cannot be deleted. Once a file in the append-only state
has been written to, changing it to the locked state by making it read-only locks it into that state
until its retention date has passed.
C
CLEAN state
See not locked state.
Common Internet File System (CIFS)
File-sharing protocol based on the Microsoft Server Message Block (SMB). It allows users to
share file systems over the Internet and intranets.
D
Data Mover
In VNX for file, a cabinet component that is running its own operating system that retrieves
data from a storage device and makes it available to a network client. This is also referred to as
a blade.
E
expired state
State of a file when its retention date has passed. A file in the expired state can be reverted back
to the locked state or deleted from the FLR-enabled file system, but cannot be altered.
F
file-level retention (FLR)
FLR lets you store data on standard rewritable magnetic disks by using NFS or CIFS operations
to create a permanent, unalterable set of files and directories.
See also append-only state, expired state, locked state, not locked state, and retention date.
Using VNX File-Level Retention
63
Glossary
FLR clock
Non-modifiable, per file system clock used to track the retention date. It is initialized when an
FLR-enabled file system is mounted read/write on a Data Mover. It does not advance when a
file system is unmounted or mounted read-only.
FLR state
See locked state.
L
LAT
Last access time of a file.
locked state
State of a file when its read/write permission is changed to read-only in a file system enabled
for file-level retention. Files committed to the locked (WORM) state cannot be altered or deleted
until their retention date has passed.
N
network file system (NFS)
Network file system (NFS) is a network file system protocol that allows a user on a client
computer to access files over a network as easily as if the network devices were attached to its
local disks.
not locked state
Initial state of a file when it is created. A file that is not locked is treated in the same manner as
any file in a file system not enabled for file-level retention (FLR). This means it can be renamed,
modified, and deleted until the time that the file is locked.
R
retention date
Date until which a locked file in an FLR-enabled file system will be protected. Users and
applications manage a file's retention date by using NFS or CIFS to set the file's last access time
to a future date and time. The retention timestamp is compared to the file system's FLR clock
to determine whether a file's retention date has passed.
64
Using VNX File-Level Retention
Index
A
expired file, deleting 33
expired state, deleting a locked file 33, 54
ATTRIB command 32
F
C
file system
copying files 19, 44
creating an FLR file system 25
deleting 44
querying 36
file-level retention
creating an FLR file system 25
modifying a default retention period 37
modifying a maximum retention period 38
modifying a minimum retention period 37
transition between states 17
FLR API
committing a file to the locked state 53
Force option 43, 45
fs_ckpt command 43
function
SetFileAttributes 32
SetFileTime 30
CAVA (Common AntiVirus Agent) 11
checkpoint
restoring 43
chmod command 31
CIFS
committing a file to the locked state 32, 53
lock a file 32
command
ATTRIB 32
chmod 31
fs_ckpt 43
touch 29
committing a file to the locked state
CIFS 32, 53
NFS 31, 53
Common AntiVirus Agent 11
copying files to an FLR file system 19, 44
creating FLR system 25
L
deleting
an FLR file system 44
expired file 33
locked file 54
last access time See LAT 17
LAT (last access time) 17
lock a file
CIFS 32, 53
NFS 31, 53
locked state, verifying 32
E
M
EMC E-Lab Navigator 48
error messages 48
messages, error 48
modifying a default retention period 37
D
Using VNX File-Level Retention
65
Index
modifying a maximum retention period 38
modifying a minimum retention period 37
N
NFS
committing a file to the locked state 31, 53
lock a file 31
not locked state, and copying files 19
SEC rule 17a-4(f) 56, 57
secondary storage 12
setting a retention date
CIFS 30, 52
NFS 29, 52
state, concepts 17
synchronization, Windows 19
T
Q
troubleshooting 47
querying a file system 36
V
R
verifying
locked state 32
retention date 30
VNX FileMover 12
VNX Replicator 12
restoring a checkpoint to an FLR file system 43
retention date
setting for CIFS 30, 52
setting for NFS 29, 52
verifying 30
retention date, default 18
W
Windows synchronization 19
S
scan on first read 11
66
Using VNX File-Level Retention