EMC VNX File-Level Retention · PDF fileEMC VNX File -Level Retention Overview 4 Executive summary EMC® VNX File-Level Retention (FLR) is an optional licensed software feature used

White Paper

Abstract

This white paper explains the concepts and benefits of VNX™ File-Level Retention. It includes a technical overview of this software feature and information on how to manage and use it. June 2012

EMC® VNX™ File-Level Retention Overview

2 EMC VNX File-Level Retention - Overview

Copyright © 2012 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners. Part Number h10684.2


Table of Contents

Executive summary ....................................................................................... 4

Business case .................................................................................................................... 4

Solution overview............................................................................................................... 4

Key results and recommendations...................................................................................... 5

Introduction ................................................................................................. 5

Purpose.............................................................................................................................. 5

Scope................................................................................................................................. 5

Audience ............................................................................................................................ 5

Terminology ....................................................................................................................... 5

FLR configuration and design .......................................................................... 6

Configuration ..................................................................................................................... 7

Requirements ................................................................................................................. 7

FLR-C (Compliance) and FLR-E (Enterprise)...................................................................... 8

Feature overview ............................................................................................................ 9

Management ................................................................................................................ 15

Interoperability with other VNX File features ................................................................. 17

How to lock files on an FLR-enabled file system ............................................................ 19

Design Considerations ..................................................................................................... 19

Conclusion ................................................................................................ 21


Executive summary EMC® VNX File-Level Retention (FLR) is an optional licensed software feature used to protect files in a NAS environment from deletion or modification until a specified retention date. FLR enables you to create a permanent, unalterable set of files and directories, and it ensures the integrity of the data. Locked, or protected, files are commonly referred to as WORM files (write-once, read-many).

Business case

All data goes through some form of an information lifecycle. Files are created and can be deleted in the future. With the introduction of new regulations and compliance requirements, data now has extended lifecycles that require longer maintenance periods. The rate at which files are being created is increasingly greater than the rate at which files are being deleted. Fixed-content data typically consumes more than half of an average organization’s storage resources. The trend at which data is growing and the need to retain the data can strain existing storage resources and command more investment into data storage than the projected budget allows.

Safeguarding business data is an essential business practice in many industries. Protecting data may be part of a company policy for self-regulation or it may be due to a regulatory mandate. For some industries, such as health care, finance, and telecommunications, it is not only a good business practice but it is a requirement that the solution used to protect files is robust and meets the regulatory compliance specifications that govern those industries. A file-level retention feature must have the flexibility of retaining files to meet the need for self-regulation and of protecting files to comply with more stringent regulatory requirements.

Solution overview

VNX FLR provides a software infrastructure in the VNX NAS environment for files to be locked, that is, protected from deletion or modification by users or storage administrators. FLR provides a cost-effective solution for NAS files throughout their lifecycle. It also has a compliance option, by which its file-level retention process meets the regulatory requirements of the United States Securities and Exchange Commission (SEC) for digital storage.

FLR is enabled per file system so that you have the flexibility to use regular file systems and FLR-enabled file systems in your NAS environment. FLR also allows the administrator to distinguish FLR-enabled file systems by the level of protection they require: self-regulation or compliance. Individual files within FLR-enabled file systems can be locked with their own unique retention dates. Only when the retention date of a locked file has expired can that file be deleted.

With FLR, files created on VNX file systems do not need to be transferred to a specialized storage product for file-level retention. They can stay on cost-effective NAS storage, which reduces the need to invest in a more expensive storage product


for data protection with compliance. Files stored on a VNX file system can take advantage of storage efficiency features such as thin provisioning and file deduplication and compression to further reduce the storage footprint.

Key results and recommendations

VNX FLR is a software technology that addresses the need for cost-effective file retention. Files created on NAS storage can stay on cost-effective NAS storage over the course of their lifecycle. FLR provides the flexibility to manage file systems that have different file-retention requirements. Whether the intention to ensure data integrity is for self-regulated business practices or for compliance requirements, FLR meets the business need to protect files in a VNX NAS environment.

Introduction

Purpose

This white paper provides an understanding of what VNX FLR is, how it functions, and why it is used.

Scope

This paper presents a technical overview of VNX FLR and its features. It also provides information on how to manage FLR and how to implement it in a VNX NAS environment.

Audience

This white paper is intended for people who have a basic understanding of VNX Unified Storage or, at a minimum, have NAS storage knowledge.

Terminology

Append-only state – State of a file when the data in it cannot be modified or deleted, but the file can have new data added at the end. Once a file in the append-only state has been written to, you can transition it to the 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.

Epoch date – An instant in time chosen as the origin of a particular era. In computer systems, time is expressed as the number of time units that have elapsed since a specified epoch date (also called reference date). On UNIX systems, time is expressed in number of seconds since January 1, 1970.

Epoch mapping year – A year value that can be applied to a file system to change the way retention times are interpreted based on the epoch date.

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 it cannot be altered. If the expired file is empty, you can transition it to the append-only state.

File-level retention (FLR) – FLR lets you store data on standard rewritable disks using NFS or CIFS operations to create a permanent, unalterable set of files and directories.

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.

Locked state – State of a file in a file system enabled for FLR when the file’s read/write permission is changed to read-only and a retention date is set. Files committed to the locked state cannot be altered or deleted until their retention date has passed. “Locked” and “protected” are used synonymously in this paper.

Network File System (NFS) – Distributed file system providing transparent access to remote file systems. NFS allows all network systems to share a single copy of a directory.

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 a file in a file system not enabled for FLR. Until or unless it is locked, it can be renamed, modified, or deleted.

Retention date – Date until which a locked file in an FLR-enabled file system is 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 with the file system’s FLR clock to determine whether a file’s retention date has passed.

FLR configuration and design FLR provides a cost-effective solution for files created on VNX file systems to stay on VNX storage throughout their lifecycle. As files age, the reason for file availability changes from active use to recordkeeping and compliance. For FLR to meet these requirements, it must provide NAS clients, particularly CIFS and NFS, the ability to easily lock files while protecting themselves from accidental or malicious attempts to delete or modify these locked files. In offering a file-level retention solution for compliance, the software product must be able to meet specific regulations that govern the various industries whose companies use VNX.


Configuration

This section discusses:

Requirements

FLR-C (Compliance) vs. FLR-E (Enterprise)

Feature Overview

Management

Interoperability with other VNX File features

How to lock files on an FLR-enabled file system

Requirements

Some industries look to implement file-level retention policies as a form of self-regulated good business practice. To provide a robust solution that can uphold the file-level retention policies set forth by companies, it is important that the infrastructure can protect files from accidental deletion and modification as well as from malicious attempts to delete and modify files by individuals who have access to the NAS storage environment. Other industries look to implement file-level retention policies in response to government regulations such as those for medical, telecommunications, financial, and pharmaceutical industries.

To meet requirements for robustness and government regulations, the FLR infrastructure has multiple components to ensure protection of files and to audit events that take place on an FLR-enabled file system. Furthermore, FLR is designed to meet the rules specified by U.S. SEC Rule 17a-4(f), which regulates the storage, retrieval, and management of electronic records for certain exchange members, brokers, and dealers. With many industries adopting strict regulations that align closely with SEC Rule 17a-4(f), it has become essential to introduce a file-level retention solution that can meet the SEC requirements.

VNX FLR offers two options to enable a file system for file-retention capabilities: Enterprise and Compliance. An Enterprise-enabled file system, FLR-E, is used by companies that want to regulate themselves as a good business practice. A Compliance-enabled file system, FLR-C, is used by companies that want to meet the regulations set forth by the SEC. These regulations are described in more detail in the following paragraphs.

The first requirement of SEC Rule 17a-4(f), found in the SEC ruling and requirements, is to preserve the records exclusively in a non-rewritable, non-erasable format. To address this requirement, FLR-C is designed to prevent any modification or deletion of locked files by either users or administrators until a specified retention date has passed.


The second requirement of SEC rule 17a-4(f) is to automatically verify the quality and accuracy of the storage media recording process. To address this requirement, an FLR-C file system provides block-level checksum (bit-level verification codes) and bit-level verification (also known as disk scrubbing).

Block-level checksums are calculated at the time the data is recorded and are maintained by VNX. When the data is read back from the disk, the VNX verifies the checksums to ensure that the data has not been altered since it was written.

Periodically, a bit-level verification of the physical storage media and block-level checksums is performed to ensure that there are no hardware failures at the media level.

The third requirement of SEC rule 17a-4(f) is to serialize the original and, if applicable, duplicate units of storage media and also to timestamp the information on the storage media for the required retention period. To address this requirement, all files created in an FLR-C file system have a unique name (the full directory path and file name) that identifies them. The “last modified” timestamp records the time at which the files were last written to before being committed. For those files that are committed, the “last accessed” timestamp records the date until which the file is protected.

The fourth requirement of SEC rule 17a-4(f) is to have the capacity to readily download indexes and records (files) preserved on the electronic storage media to any medium acceptable under paragraph (f), as required by the commission or the self-regulatory organizations of which the exchange member, broker, or dealer belongs. To address this requirement, the record names and timestamps (metadata) and the content of the records (data) stored in an FLR-C file system can be:

Copied by using standard NAS protocols

Replicated to an alternate location by using VNX Symmetrix® Remote Data Facility (SRDF), VNX MirrorView™, or VNX Replicator

Backed up through Network Data Management Protocol (NDMP)

The rule also requires that the organization provide “an audit system for accountability regarding the input of records into the storage system.” An FLR activity log is maintained in each FLR-enabled file system to support this requirement.

FLR-C (Compliance) and FLR-E (Enterprise)

VNX FLR comes with two options that differ in the level of strictness in enforcing retention policies. Each file system can be enabled with one of the two options: FLR-C (Compliance) or FLR-E (Enterprise).

FLR-C protects data from changes made by users through NAS protocols such as CIFS, NFS, and FTP, and from changes resulting from administrators’ actions. It meets the requirement of SEC Rule 17a-4(f). An FLR-C file system with locked files cannot be deleted.


FLR-E protects data from changes made by users through NAS protocols. However, a VNX administrator with the appropriate authorization can delete an FLR-E file system even if it contains protected files.

In both FLR-C and FLR-E file systems, you cannot modify or delete files that are in the locked state. Additionally, the path to a file in the locked state is protected from modification, which means that you cannot delete or rename a directory on a FLR-enabled file system if it contains protected files.

Feature overview

A retention policy for each file is controlled by an attribute. The attribute identifies the file to the system as an FLR file, which has metadata needed for the Data Mover to process the file. The metadata includes the retention date and the state (for example, not locked, locked, append-only, or expired). Although the FLR attribute protects the file, the storage environment plays an important part in determining the level of protection. If an administrator can manipulate the environment by changing the system clock or circumvent the protection by deleting the file’s container (for example, the file system) to modify a locked file, the required protection solution is defeated.

Retention Dates

The retention period is the period from the current time to the user-specified date during which a file is protected. Locked files use the file’s access time attribute to store the retention date. To lock and set a retention date to a file, change the access time attribute to the intended date in the future and set the file to read-only. This applies to retention dates prior to January 19, 2038.

Beyond that date, it is not possible to follow the same procedure to set the retention date because of the 32-bit architecture and the UNIX epoch date that VNX Data Movers use. Using a 32-bit signed integer and the UNIX epoch date of January 1, 1970, to determine the date, the latest possible date is January 19, 2038. However, for FLR via CIFS and NFS, you can change the way the file system interprets the dates by changing epoch mapping year. Changing the default epoch mapping year from 1970 to a later year means that the 32-bit signed integers that were used to represent dates from 1970 to the epoch mapping year now represent future dates beyond 2038. An administrator can set the epoch mapping year in Unisphere™.

For example, if the epoch mapping year is 2003, dates between 1970 and 2003 represent dates after 2038. The formula to use to determine the actual retention date: <retention date entered> - <epoch date = 1970> + 2038. Setting a date of 1974 means the file will be locked until 2042 (1974-1970+2038). Changing the epoch mapping year to 2003 extends the maximum retention period 33 years beyond 2038 because the 33 years between 1970 and 2003 no longer represent those years. It is important to note that retention dates between the epoch mapping year and 2038 use the same 32-bit integers as before the epoch mapping year was changed. In the previous example, if you enter a retention date of 2004, it is interpreted as a date in 2004.


File States

Figure 1 shows the four states a file can be in when it is stored in an FLR-enabled file system.

Figure 1. State diagram

Not locked – All files start as not locked. A not locked file is an unprotected file that is treated as a file in a non-FLR file system. In an FLR file system, the state of an unprotected file can change to locked or remain as not locked.

Locked – A locked file has a set retention period that prevents users from modifying the file data or extending, deleting, or renaming the file. A locked file remains in this state until its retention period expires. An administrator can perform two actions on a locked file:

Modify the file retention date to extend the existing retention period.

If the locked file is initially empty, move the file to the append-only state.

Append-only – You cannot delete or rename the file, or modify the data in an append-only file, but you can add data to it. The append-only feature enables users to append data to a locked file without changing existing data.

It is a state that you can set only on an empty file in the locked state. An append-only file does not have a retention period, but it cannot be deleted. After modifying an append-only file, it can be converted back to a traditional locked file or can remain in the append-only state forever. Transitioning back to the locked state requires a retention period either specifically set by the user or the VNX with a default retention period. After data is written to an append-only file and the file is converted back to the locked state, you cannot change the file back to the append-only state.

Some applications interpret appending a file as extending a new file to the desired size and then appending new data afterward. That to a file server is creating empty space on a file followed by modification of the empty space, which is not allowed.

Expired – When the retention period ends, the file transitions from the locked state to the expired state. You cannot modify or rename a file in the expired state, but you can delete the file. An expired file can have its retention period extended such that the file transitions back to the locked state. An empty expired file can also transition to the append-only state.


The following subsections describe the components in the FLR infrastructure that secure the environment in which FLR files are stored and strengthen the protection of FLR files.

Retention periods

When enabling FLR at file-system creation, you have the option to set the default, minimum, and maximum retention periods. You can change these settings after file-system creation.

The default retention date is used when an explicit retention date is not set when locking a file. If you do not set the default retention period, the default retention period is infinite.

The minimum and maximum retention periods allow the administrator to enforce retention dates that fall within a specified range. For example, you set the minimum and maximum retention periods to 30 days and 1 year, respectively, for a file system. If a user attempts to set a retention period of 20 days to a file, FLR automatically locks it with the minimum retention period of 30 days. If a user attempts to set a retention period of 5 years to a file, FLR automatically locks it with the maximum retention period of 1 year. If a user attempts to lock a file for 90 days, it is allowed. The default retention period must fall between the minimum and maximum retention periods.

Auto-lock

Auto-lock can be enabled after creating the FLR file system. Auto-lock automatically locks files in the file system with the default retention period if they have not been modified for a user-specified period of time. A parameter called the Policy Interval is used to track the user-specified period of time.

Auto-delete

Auto-delete is another feature that can be enabled after creating the FLR file system. When this feature is enabled, FLR automatically delete files with expired retention periods.

Tamper-proof clock

A software clock mechanism in FLR addresses the issue of malicious administrators attempting to delete protected content before its expiration date by tampering with the system clock.

FLR includes a tamper-proof software clock set once for each file system. The value of the FLR clock is initialized by synchronizing it with the current Data Mover system time when the FLR file system is first mounted.

The FLR clock has some flexibility for file system downtime, movement of file systems between Data Movers, and so on. The FLR clock is periodically stored in the file system. When an FLR-enabled file system is unmounted or mounted as read-only, the FLR clock does not advance. After the file system is remounted as read/write, the FLR clock continues to advance. This prevents locked files from being deleted


prematurely, although it might cause locked files from expiring longer than is required.

Because the FLR clock might not always be synchronized with the Data Mover system clock, the FLR clock can adjust itself to changes in the Data Mover system clock. If the Data Mover clock is turned back such that the FLR clock is ahead of the system clock, the FLR clock resets back to the current time. If the Data Mover clock is ahead of the FLR clock, the FLR clock gradually adjusts to that change. The FLR clock is allowed to advance only 138 seconds per hour if it is behind the current value of the system clock. The FLR clock can catch up at most two weeks per year if necessary. This implementation prevents administrators from deleting protected files early because the slow rate of change makes attacks of this nature impractical.

FLR enables authorized administrators to restore from previous point-in-time views for FLR-E file systems. The FLR clock adjusts accordingly. Point-in-time restores are prohibited for FLR-C file systems.

File system protection

To meet the SEC Rule 17a-4(f) requirement, FLR-C prohibits destructive operations on an FLR-C file system that contains protected files. If there are no protected files, you can delete the file system.

FLR-E treats this scenario differently. VNX alerts the administrator to the presence of protected content on the FLR-E file system and requires a confirmation from the administrator before deletion.

Although this feature prevents destructive actions against protected content at the file-system level for FLR-C file systems, it does not protect committed content at the disk level. An authorized administrator can destroy the LUNs that the file system resides on by using management tools such as Unisphere and NaviSecCLI. However, the intent of SEC Rule 17a-4(f) requirement is to prevent modification of individual files without trace or record. VNX FLR-C meets this requirement because an administrator cannot target individual files for deletion.

Additionally, you cannot enable Multi-Path File System (MPFS) and Parallel Network File System (pNFS) on an FLR-C file system. This is to prohibit malicious MPFS clients from writing to the array.

Data verification

FLR-C (but not FLR-E) includes an enhancement for write verification. SEC Rule 17a-4(f) requires that the storage system ensure the integrity of the stored data by reading back the data written to the file system.

If the data that is read back from the storage system does not match the data in memory, the Data Mover attempts to write and read back two more times. If a mismatch still occurs, the Data Mover logs a message in the Data Mover server log and generates an event on the VNX to inform the administrator before panicking the Data Mover. This event is meant to explain the reason why the Data Mover panicked.


Users may experience performance degradation because of the write verification feature. When this feature is enabled, every write results in an additional read of the data that was just written. As a result, a write operation to an FLR-C file system occurs at approximately 20–40 percent of a normal file system performance.

This performance loss also affects replication sessions for an FLR-C file system with low transfer rates. You must ensure that the recovery point objective (RPO) of the replication session is set properly. If the max_time_out_sync parameter is not set to a reasonable value, the RPO might not be met.

A server parameter controls the data verification feature. By default, data verification is disabled. Changes to the parameter take effect immediately without the need for a system reboot.

Default “Hard” Infinite Retention Period

Based on the intent of the SEC 17a-4(f) ruling, it is prudent for files without a set expiration date to have a permanent retention period.

FLR-C adheres to this ruling by applying a “hard” infinite retention period to committed files that have no explicit retention date. The retention period cannot be decreased.

FLR-E retains the “soft” infinite retention period in this scenario. This means that the infinite retention period can be reduced by setting a date afterwards.

You can avoid this behavior by setting a finite default retention period. When no explicit retention date is set for a file, the default retention period is used.

Activity log

Because an FLR file system is used in environments that are subject to strict regulations, both FLR-C and FLR-E record events that pertain to successful changes and to attempts to change protected data on the file system. The activity log records the user, time of event, and the type of action taken against protected files.

The FLR log has a fixed naming convention, flr.log [timestamp], and is stored in the root directory of each FLR file system. The FLR log has a maximum size of 10 MB. Logs that meet the limit are converted to locked files, and subsequent events are written to another file with the same naming convention. A converted log file is set with the longest retention period that exists for the files referred to in this particular FLR log.

The administrator is responsible for deleting old log files. If there is insufficient space in the file system to update the activity log, operations are not allowed to proceed and warnings are logged in the Data Mover server log, the sys_log, and posted as an alert to the administrator.

The activity log captures the following events:

Create append-only file

Set file to locked state

Extend retention period on a locked or expired file


Attempt to make a locked or expired file writable

Delete or attempt deletion of a protected (locked, expired, append-only) file

The following information accompanies a recorded event:

Time of event (software clock maintained by the file system)

Action (events described above)

Full file name (with absolute path)

Unique identifier (UID) or security identifier (SID) of the user who performed or attempted the action

Event-specific information:

The retention date and time if a locked file is committed

Success or failure if a locked file is deleted or if there is an attempt to delete it

FLR-C vs. FLR-E

Table 1 shows the features that are available in the FLR-C and FLR-E file systems.

Table 1. FLR-C and FLR-E features

Feature FLR-C FLR-E Default/minimum/maximum retention periods

Auto-lock and auto-delete Tamper-proof clock File system protection Cannot delete with

protected files Can delete with protected files

Data verification X Default “hard” infinite retention

X

Activity log Append-only files


Management

Licensing

FLR is a licensed feature that includes both FLR-C and FLR-E options. You can activate the license by using the Unisphere software or the Control Station command line interface (CLI). When you enable the FLR license, you get both FLR-C and FLR-E functionalities.

Enabling

Figure 2 shows the File Level Retention section in the New File System window in Unisphere. To enable FLR on a file system, select the desired FLR option (Enterprise or Compliance) in the New File System window or in the New File System Wizard in Unisphere. You cannot enable FLR on an existing file system.

Figure 2. Enabling FLR on the New File System window in Unipshere

Configuring and Monitoring in Unisphere

Figure 3 shows the FLR Settings tab on the File System Properties window of an FLR-enabled file system. It displays the FLR setting (Enterprise or Compliance) and whether there are any protected files on the file system.

FLR Clock Time is a non-modifiable 24-hour software clock maintained by the file system. The value in field Last Currently Locked File Will Expire On is equal to the maximum data retention time of all the locked files on the file system. This field provides the difference between the FLR clock time and the maximum data retention date. The maximum retention date is displayed in parentheses.


On this tab, you can also check or configure the default, minimum, and maximum retention periods. There is also a section to configure auto-lock and auto-delete. At the bottom of the FLR Settings tab, you can change the epoch mapping year. The parameter is called Earliest valid retention year. By default it is set to 2003.

Figure 3. FLR Settings tab on the File System Properties window

File system deletion

Unisphere enables an administrator with full file-system privileges to delete an FLR file system. When an administrator attempts to delete a file system, Unisphere directs the administrator to a confirmation screen. The confirmation screen is customized to indicate the FLR setting and the existence of protected files if the file system is FLR enabled:

FLR-C – The confirmation screen displays an error if the file system has any protected files. The OK button is disabled if the FLR-C file system has protected files.

FLR-E – The confirmation screen displays a warning if the file system has protected files or is in the process of scanning the Last Currently Locked File Will Expire on value. However, the administrator can ignore the warning and choose to delete the file system.


Interoperability with other VNX File features

Antivirus Scanning

You can run an antivirus scan on FLR file systems by using Common AntiVirus Agent (CAVA). When an infected locked file is identified, the resident AV engine records the infection and its location in the log file of the resident scan engine. Administrators cannot repair or remove an infected file. They can delete the file only after its retention date has passed. However, administrators can change the file's permission to restrict read access, ensuring that the file is unavailable to users. CAVA’s scan-on-first-read functionality does not detect a virus in a locked file. A subsequent scan of the file system is necessary to detect viruses on locked files.

Deduplication

You can enable VNX File Deduplication and Compression on an FLR-C or FLR-E file system without compromising the protection offered to the data on the file system. Locked files are eligible for processing but the access-time check will not be used to determine their eligibility.

VNX FileMover archiving

Archiving an FLR file system is not supported. It is not possible to use a file system with FLR enabled as primary storage in a VNX FileMover environment. VNX cannot protect the locked files if the data is archived to a secondary storage system that is outside the control of VNX. However, it is possible to archive from a non-FLR file system to an FLR file system.

NDMP backup

FLR supports NDMP backup and restore, but it does not preserve the FLR attribute. It is possible to back up protected files from an FLR file system and restore them to a non-FLR file system. You can also back up from a non-FLR file system and restore them to an FLR file system.

When you restore an expired locked file to an FLR file system, the file is committed with the default retention period. If the default retention period is set to an infinite retention period, a FLR-E file system treats the infinite retention period as “soft”, which means that you can decrease the retention period. If the expired file is restored to a FLR-C file system, the infinite retention period is “hard”, which means that you cannot decrease the retention period, and you cannot delete the file.

FLR-enabled file systems support NDMP Volume Backup (NVB). When you restore the FLR file system by using the full destructive restore method, you preserve the protection status of the files. However, the Control Station does not recognize the file system as an FLR file system. Therefore, you can delete it in the same way that you can delete a regular file system.

SnapSure checkpoints

FLR-C – A SnapSure™ checkpoint of an FLR-C file system inherits the associated FLR attributes. To support the SEC ruling that the integrity of the protected data must be


ensured, the checkpoints are subject to the same requirement of data verification as the protected file system. Therefore, the checkpoints also satisfy the requirements of the SEC ruling. To write to the file system that requires updates to the save volume (SavVol), data verification is required on the write to the production file system and on the write to the SavVol.

Writable checkpoints are not supported by FLR-C file systems because of the design behavior of a writable checkpoint when the SavVol is full. When the SavVol is at full capacity, additional changes to a writable checkpoint internally delete the old checkpoint to free up the necessary space. This behavior fails the SEC compliance requirement that protected files cannot be deleted unless their retention periods have expired. Thus, checkpoint restore on an FLR-C file system is also not supported and is blocked by the Control Station.

FLR-E – FLR-E file systems support checkpoints and do not conform to the SEC compliance requirements. Writable checkpoints are also supported in FLR-E file systems. When you restore a checkpoint to an FLR-E file system, the subsequent confirmation screen alerts the administrator that restoring the checkpoint can possibly overwrite protected files.

Replication

FLR-C – For VNX Replicator create and file-system copy operations, replication of an FLR-C file system is enabled 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 file system is automatically created from a storage pool with the same FLR setting. The destination Data Mover must also have an FLR license.

This also applies for one-time file-system copy operations.

For Replicator start operations, replication is enabled when the source file system has FLR-C enabled, and the destination file system has FLR-C enabled and does not have protected files.

For Replicator start with reverse operations, replication is enabled when the original source file system has FLR-C enabled with no changes made to the protected files since the source file system went down, and the original destination file system also has FLR-C enabled.

FLR-E – For VNX Replicator create and file-system copy operations, replication of an FLR-E file system is enabled when:

The source file system has FLR-E enabled, and the destination file system has FLR-E enabled.

The source file system has FLR-E enabled, and the destination file system is automatically created from a storage pool with the same FLR setting. The destination Data Mover must also have an FLR license.


This also applies for one-time file-system copy operations. All other replication operations behave as they do with a regular file system.

How to lock files on an FLR-enabled file system

FLR provides the software infrastructure to protect files from deletion or modification by users and storage administrators. The procedure to lock a file requires the use of CIFS or NFS protocols.

Locking an NFS file requires setting the access time to the desired retention date and then changing the permission bits to read-only. Once successfully locked, the permission details show the file has read-only access and the access date lists the retention date.

Files in a CIFS environment should use an EMC application called the VNX FLR Toolkit. The Toolkit provides increased functionality to administer and monitor files on FLR-enabled file systems. The Toolkit is installed on a client in the same domain as the FLR file systems you wish to access. The Toolkit requires a domain administrative account to operate.

With the Toolkit, the user can manually lock files with the desired retention date by using the General tab and the FLR Attributes tab on the File Properties screen. The FLR Attributes tab comes with the installation of the Toolkit. In addition, there is a Monitor Service application that allows the administrator to set policies to automatically lock files created on a specific directory or file system and to automatically handle files that have expired retention periods. The Toolkit also provides a Dashboard to monitor FLR-enabled file systems and generate reports on them. Currently, the FLR Toolkit supports CIFS files only.

FLR also has native capability to automatically lock files and automatically delete files with expired retention periods. Unlike the auto-lock and auto-delete features on the FLR Toolkit, auto-lock and auto-delete features on the VNX apply to CIFS and NFS files.

Design Considerations Non-FLR, FLR-C, and FLR-E file systems can exist on the same system.

You must select the required FLR setting (off, Enterprise, or Compliance) when you create the file system. You cannot change the setting after the file system is created.

You can enable VNX File Deduplication and Compression on an FLR-enabled file system. It does not affect the integrity of the data.

FLR-E is intended for self-regulated archiving. FLR-C is intended to assist companies that have to comply with regulations such as the U.S. SEC ruling 17a-4(f).

CAVA’s scan-on-first-read functionality does not detect a virus in a locked file. A subsequent scan of the file system is necessary to detect viruses on locked files.


For VNX Replicator:

You cannot create a replication session or copy a session unless the source and destination file systems have the same FLR type: Enterprise or Compliance. Also, when you create a file system replication, you cannot use an FLR-C destination file system that contains protected files.

You cannot start a replication session if an FLR-C destination file system contains protected files and you have made updates to the files in the destination file system.

You cannot start a switched-over replication session in the reverse direction when an FLR-C original source file system contains protected files and you have made updates to the original source since the switchover.

You can create a file system with FLR enabled as secondary storage for a FileMover environment. You cannot enable the FileMover functionality with an FLR-enabled file system as primary storage.

Although FLR supports all backup functionality, the FLR attribute is not preserved in the NDMP backup. Therefore, the VNX File administrator must ensure that the file system is restored to a VNX file system with FLR enabled. If you restore a file from an NDMP backup where the retention date has expired, the file is set with the default retention period after it is restored.

You cannot enable FLR on the root file system of the nested mount.

You cannot use the FLR features of NFS v4.1 to manage the FLR state of files in an FLR-enabled file system. NFS v4.1 clients must use the same mechanisms as NFS v3 clients.

You cannot create a writable checkpoint of an FLR-C file system. However, you can create a writable checkpoint of an FLR-E file system.

You cannot use MPFS to access the data in an FLR-C file system.

You cannot upgrade from an FLR-E file system to an FLR-C file system.

Most file copy tools preserve the last modified time of a file being copied. When copying files into an FLR file system with native 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.


Conclusion VNX FLR provides a cost-effective solution for files in a NAS environment to continue to reside on a VNX file system even when they require file-level retention to ensure data integrity for the remainder of their lifecycle. FLR provides a robust software infrastructure that protects locked files from accidental or malicious attempts of modification or deletion. No matter the level of enforcement required, FLR is suitable if you are looking to self-regulate your record-keeping practices and if you are required to meet strict compliance rules of U.S. SEC Rule 17a-4 (f) for digital data storage. FLR is simple to manage and use, and it allows you to take advantage of the VNX File storage efficiency features to reduce the storage footprint.

Documents

EMC VNX File-Level Retention · PDF fileEMC VNX File -Level Retention Overview 4 Executive summary EMC® VNX File-Level Retention (FLR) is an optional licensed software feature used