h7258.2 data domain cta ig

Integration Guide

October 2011

EMC Data Domain and EMC Cloud Tiering Appliance Integration Guide

2EMC Data Domain and EMC Cloud Tiering Appliance Integration Guide

Copyright 2011 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 h7258.2


Table of Contents

About this document ............................................................................................... 5Audience ............................................................................................................................ 5Related documents ............................................................................................................ 5

Configuration overview ............................................................................................ 6Restrictions and specific behaviors .................................................................................... 6Prerequisites ...................................................................................................................... 7

Archive source configuration ................................................................................... 8For NFS-only data ............................................................................................................... 9For CIFS data ...................................................................................................................... 9

Data Domain DDOS 4.x system configuration ......................................................... 10Create the repository path for the Data Domain on an NFS client ...................................... 10Create the NFS export on the Data Domain ....................................................................... 11Enable the Retention Lock feature (optional) .................................................................... 12

Data Domain DDOS 5.0 system configuration ......................................................... 13MTree setup and configuration ......................................................................................... 13Configure an export in an MTree on the Data Domain system ............................................ 14Create the repository path for the Data Domain on an NFS client ...................................... 16Enable the Retention Lock feature (optional) .................................................................... 17

General recommendations ..................................................................................... 19Data set profile ................................................................................................................. 19Usage profile .................................................................................................................... 19Scheduling operations ..................................................................................................... 19

Configuring the Cloud Tiering Appliance with Data Domain ..................................... 21Configure the Data Domain system as an archive target ................................................... 21

Configure Data Domain as a file server ......................................................................... 21Configure the Data Domain NAS repository ................................................................... 23

Define the archive rules ......................................................................................... 25Name the policy ............................................................................................................... 25Define the file matching criteria ........................................................................................ 27Specify the target ............................................................................................................. 28Create a schedule for the policy ........................................................................................ 29

Perform a test archive ............................................................................................ 31Retrieve an archived file ........................................................................................ 31

If the stub has been deleted ............................................................................................. 32Data retention ....................................................................................................... 34

Create the policy .............................................................................................................. 34


Define the file matching criteria ........................................................................................ 35Specify the target ............................................................................................................. 35Create a schedule for the policy ........................................................................................ 36

Using with the Data Domain Archiver ..................................................................... 37About the Data Domain Archiver ....................................................................................... 37Data Movement Policies ................................................................................................... 37Deduplication ................................................................................................................... 38Storage ............................................................................................................................ 38Mixed Use ........................................................................................................................ 38Recommended best practices........................................................................................... 39Configuring data movement ............................................................................................. 40


About this document

The EMC Cloud Tiering Appliance replaces the EMC File Management Appliance in v7.5. All references to EMC File Management Appliance/VE in previous versions of this document have been changed in this document to Cloud Tiering Appliance and applies to all software versions with which the Data Domain system is compatible.

This document explains how to configure an EMC Data Domain system as an archive target for the EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE software. Please confirm you have the most recent version of the Integration Guide specific to your environment before proceeding to ensure you have the latest best practices information.

This document is applicable for the following versions of the EMC Cloud Tiering Appliance and Cloud Tiering Appliance Virtual Edition software:

EMC Cloud Tiering Appliance or Cloud Tiering Appliance/VE 7.3.1 and 7.4 EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE 7.5 and later Consult the Cloud Tiering Appliance and Cloud Tiering Appliance/VE compatibility matrix on Powerlink for the latest supported software and storage tiering configurations.

This document is applicable for:

Data Domain systems running DDOS version 4.7.3 and later, 4.8, 4.9, and 5.0 Data Domain Archiver running DDOS version 5.0.x If you are using a Data Domain Archiver, refer to Using with the Data Domain Archiver on page 37 for additional information relevant to DD Archiver features.

Audience

This guide is intended for customers, technical field consultants, and customer engineers who have familiarity with either Data Domain operations and/or the EMC Cloud Tiering Appliance or Cloud Tiering Appliance/VE.

Related documents

The Data Domain and EMC Cloud Tiering Appliance documents referred to in this guide provide additional information for configuring and using the Data Domain as an archive/Tier 2 target with the Cloud Tiering Appliance.

To view the Cloud Tiering Appliance documentation, visit Cloud Tiering Appliance on Powerlink. The following documents are recommended:

All documents in the Cloud Tiering Appliance and Cloud Tiering Appliance/VE Electronic Distribution.


EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Getting Started Guide

File Archiving from EMC Celerra to Data Domain with EMC File Management Appliance White Paper

File Archiving from NetApp to EMC Data Domain with EMC File Management Appliance White Paper

Documentation for the Data Domain system is available at https://my.datadomain.com/documentation.

Configuration overview Configuring a Data Domain system as an archive or Tier 2 target for the Cloud Tiering Appliance involves these basic steps:

1. Configure the source for the archive data (EMC VNX or Celerra or NetApp storage system) as a filer on the Cloud Tiering Appliance following the steps outlined in the EMC Cloud Tiering Appliance and Cloud Tiering Appliance/VE Getting Started Guide.

2. Create the repository path for the Data Domain on an NFS client.

3. (Optional) Install any licenses and enable them on the Data Domain system.

4. Create the NFS export for the archive data on the Data Domain.

5. Configure the Data Domain as a file server on the Cloud Tiering Appliance. Also configure a NAS repository, selecting the NFS export on the Data Domain and specifying the NFS protocol.

6. Create archive policies and schedules.

7. Perform a test archive and verify that it finishes successfully.

8. Verify archived data can be recalled.

These steps are covered in more detail in this guide and in the Cloud Tiering Appliance and Data Domain product documentation.

Restrictions and specific behaviors

The following restrictions apply in a Cloud Tiering Appliance Data Domain environment:

The Data Domain system is not intended to be deployed as primary storage (Tier 1 file system) when used in a Cloud Tiering Appliance environment.

The Cloud Tiering Appliance v7.5 supports the Data Domain retention lock feature. Earlier versions do not.

When using EMC Celerra as the Tier 1 filer, the minimum DART version is 5.6.47. Use of the EMC VNX as a Tier 1 filer requires Cloud Tiering Appliance v7.4 or later.


When using the Data Domain replication feature, DDOS 4.9.1.5 or 4.9.3 and later is required in a Cloud Tiering Appliance environment.

Prerequisites

The following are required when integrating the Cloud Tiering Appliance with Data Domain:

A Data Domain system with DD OS 4.7.3 or later. The Data Domain system must be deployed as a Tier 2 or lower NAS repository.

A second Data Domain system if you want to configure replication. A Cloud Tiering Appliance version 7.3.1 or later. The following licenses are optional:

Data Domain Replication licenses, if replication between Data Domain systems is to be configured.

A Data Domain Archiver license if the Data Domain system is a DD Archiver A Data Domain Retention Lock license (required only if this feature is to be used). Cloud Tiering Appliance v7.5 and later is required when using the Data Domain Retention Lock feature.


Archive source configuration The Cloud Tiering Appliance supports EMC Celerra, EMC VNX, or a NetApp storage system as an archive source when you use Data Domain as an archive target. Refer to Figure 1 and Figure 2 for an illustration of the data paths with these archive sources.

A single archive source can be configured with multiple Cloud Tiering Appliances at the same time, but more than one Cloud Tiering Appliance should never be used to archive data from a single file system.

EMCCTA

DataDomain(SecondaryFileSystem)

EMCCelerra/VNX(PrimaryFileSystem

NFS CIFS

NFS

NFS

NFS FileMover

Figure 1 EMC Celerra/VNX deployment with Data Domain in a Cloud Tiering Appliance environment


Figure 2 NetApp deployment with Data Domain in a Cloud Tiering Appliance environment

For NFS-only data

To archive/recall NFS-only data to the Data Domain, create NFS exports in the file system on the archive source that you will use as the source NAS repository as described in the archive source documentation.

For CIFS data

To archive CIFS data to the Data Domain, create CIFS shares in the file system on the archive source as described in the archive source documentation.

In order to recall CIFS data that has been stubbed from the Data Domain, the Cloud Tiering Appliance must use an NFS path to retrieve the data, as the Cloud Tiering Appliance requires that a complete NFS datapath exist between the archive source and target. Follow the steps described in the Cloud Tiering Appliance documentation to configure the archive source with the Cloud Tiering Appliance.


Data Domain DDOS 4.x system configuration Follow the instructions in this section if you are using DDOS 4.7, 4.8, or 4.9. If your Data Domain system is running DDOS 5.0, go to Data Domain DDOS 5.0 system configuration on page 13. The home page of the Data Domain GUI displays the DDOS version.

This section assumes that the Data Domain system is 192.168.36.30. You can also use the fully-qualified domain name in your environment.

Please refer to the NFS section of the Data Domain 4.x Administrators Guide for detailed instructions on how to configure a Domain Domain system when using the NFS protocol.

Create the repository path for the Data Domain on an NFS client 1. Make sure that the NFSD daemon is running on an NFS client. # /sbin/service nfs status

If the NFS service is not enabled, issue the following command to enable the NFS client:

# /sbin/service nfs start Confirm that the NFS service is running by using the following command:

# /sbin/service nfs status 2. Create a local directory (dd in this example) on the NFS client. # mkdir /mnt/dd 3. Mount the Data Domain /backup volume to the local directory on the NFS client

following the mount options for your operating system.

For Linux:

# mount t nfs o hard,intr,vers=3,tcprsize=32768,wsize=32768,bg 192.168.36.30:/backup /mnt/dd

For Solaris:

# mount F nfs o hard,intr,vers=3,proto=tcp,rsize=32768,wsize=32768 192.168.36.30:/backup /mnt/dd 4. Verify the mount. # ls ltr /mnt/dd 5. Change to the newly created directory and create a subdirectory (archive1 in

this example) within the local directory (/dd).

# cd dd # mkdir archive1


Create the NFS export on the Data Domain

By default, you can export the entire Data Domain directory structure (for example, //192.168.36.30:/backup) via NFS to all clients or to selected clients. However, this is not a recommended practice. Clients should be configured to have access only to those exports that are assigned to those clients.

Data Domain must be set up so that both the Cloud Tiering Appliance and the primary file system (VNX, Celerra, or NetApp) have access to the NFS export (or exports) to which archive data will be written or recalled.

All Data Domain commands are executed via an SSH session.

1. Establish an SSH session with the Data Domain system as sysadmin or as a user with the sysadmin privilege.

2. Determine the current NFS client access level by running the DD OS command nfs show clients. The output in the following example shows that the access for the Data Domain export /backup is open to all clients as indicated by the *:

# nfs show clients path client options ----------------- ---------- ---------------------------------- /backup * (rw,no_root_squash,no_all_squash,secure) ----------------- ---------- ---------------------------------- 3. Create an NFS export under /backup on the Data Domain system to receive the

archive data from the Cloud Tiering Appliance. In this example, archive1 will be created and accessible by the Cloud Tiering Appliance:

# nfs add /backup/archive1 192.168.36.48 NFS export for "/backup/archive1" added. 4. Give access to the archive source to the NFS export you created in step 3 using the

Data Domain CLI. This is required to recall archived data from the Data Domain system.

In this example, the source is a Celerra and has an IP address of 192.168.36.82.

# nfs add /backup/archive1 192.168.36.82 (insecure) NFS export for "/backup/archive1" added. When using a Celerra or VNX as the archive source in this environment, Celerra/VNX access to the export must be specified as insecure. The default value is secure.

5. Confirm that the export has been configured correctly using the nfs show clients command. In this example, /backup/archive1 should appear in the path list, accessible by the Cloud Tiering Appliance (192.168.36.48) and by the Celerra (192.168.36.82).

# nfs show clients path client options --------------- ------------ --------------------------------------- /backup * (rw,no_root_squash,no_all_squash,secure) /backup/archive1 192.168.36.48 (rw,no_root_squash,no_all_squash,secure)


/backup/archive1 192.168.36.82 (rw,no_root_squash,no_all_squash,insecure) --------------- ------------ ---------------------------------------

Enable the Retention Lock feature (optional)

This optional feature is only supported with Cloud Tiering Appliance v7.5 and later.

Data Domain Retention lock software enables you to easily implement deduplication with file locking to satisfy IT governance and compliance policies for active archive protection. Data Domain Retention Lock also enables electronic data shredding on a per-file basis to ensure that deleted files have been disposed of in an appropriate and permanent manner, in order to main confidentiality of classified material, limit liability, and enforce privacy requirements.

If using the Retention Lock feature, do the following steps to install the Retention Lock license, enable the feature, and specify the retention period during which the file cannot be deleted or modified. The default minimum retention period is 12 hours and the default maximum retention period is 5 years. The maximum retention period in a CIFS environment can be 70 years.

When using DDOS 4.x, you will have the ability to configure only a single retention lock period for the filesystem.

The retention period is specified in the format [number][unit]. Possible unit values are min, hr, day, mo, year.

For more information on the Retention Lock feature and its commands, please refer to the Data Domain Retention Lock Software User Guide.

1. Establish an SSH session with the Data Domain system as sysadmin or as a user with the sysadmin privilege.

2. Add the Data Domain Retention Lock license by entering this command: # license add license_number 3. Enable the Retention Lock feature with this command: # filesys retention-lock enable 4. Set the minimum or maximum retention period with this command: # filesys retention-lock option set min-retention-period [number][unit] # filesys retention-lock option set max-retention-period [number][unit] 5. Verify your retention lock settings with the following commands: # filesys retention-lock status # filesys retention-lock option show min-retention-period # filesys retention-lock option show max-retention-period


Data Domain DDOS 5.0 system configuration Follow the instructions in this section if you are using DDOS 5.0. If your Data Domain systemis running DDOS 4.x, go to Data Domain DDOS 4.x system configuration on page 10. The home page of the Data Domain GUI displays the DDOS version.

MTree setup and configuration

DDOS 5.0 introduces MTrees (managed trees). An MTree is a logical partition of the namespace in the Data Domain filesystem that can be used to group files for management purposes such as a distinct snapshot schedule, replication, retention, etc.

EMC recommends that you create a separate MTree for each export you plan to use for archiving.

To create an MTree:

1. Click the Data Management > MTree tab.

2. In the MTree overview area, click Create. The Create MTree dialog box appears.

3. Enter a name for the MTree in the MTree Name text box. For example, enter fmaarchdata as the MTree name.

4. Click OK. The new MTree displays in the MTree table (Figure 3).


Figure 3 Creating an MTree

5. Repeat steps 2-4 to create one or more additional MTrees.

Configure an export in an MTree on the Data Domain system

Follow the steps in this section to provide access to the export in the MTree, fmaarchdata, to the Cloud Tiering Appliance and the tier 1 system

1. ClickData Management > MTree tab to navigate to the MTree view. 2. Select the MTree and click Create Export in the MTree Summary. The Create

Export dialog box appears (Figure 4).


Figure 4 Create NFS Exports dialog

3. If desired, create an export for the MTree by adding it to the Directory Path.

4. In the Clients area, select an existing client or click the + icon to create a client. The Clients dialog box appears (Figure 5).

Figure 5 Client dialog box


a. Enter the IP address of the Cloud Tiering Appliance in the Client text box and select any options. Click OK.

b. Click the + sign to add the tier 1 archive source client information. Click OK.

When using a Celerra or VNX as the archive source in a Cloud Tiering Appliance environment, access to the export must be specified as insecure. The default value is secure.

c. Click OK

Create the repository path for the Data Domain on an NFS client 1. Make sure that the NFSD daemon is running on an NFS client. # /sbin/service nfs status

If the NFS service is not enabled, issue the following command to enable the NFS client:

# /sbin/service nfs start Confirm that the NFS service is running by using the following command:

# /sbin/service nfs status 2. Create a local directory (dd in this example) on the NFS client. # mkdir /mnt/dd 3. Change directories to the Data Domain mount point (/mnt/dd) and create a new

directory. Give the directory a descriptive name that indicates to which Data Domain export it corresponds (nfsdd in this example).

# cd /mnt/dd # mkdir nfsdd 4. Mount the Data Domain export to the local directory on the NFS client following

the mount options for your operating system.

For Linux:

# mount t nfs o hard,intr,vers=3,tcprsize=32768,wsize=32768,bg 192.168.36.30:/data/col1/ /mnt/dd/nfsdd

For Solaris:

# mount F nfs o hard,intr,vers=3,proto=tcp,rsize=32768,wsize=32768 192.168.36.30:/data/col1/ /mnt/dd/nfsdd 5. Verify the mount. # ls ltr /mnt/dd/nfsdd


Enable the Retention Lock feature (optional)

This optional feature is only supported with Cloud Tiering Appliance v7.5 and later.

Data Domain Retention lock software enables you to easily implement deduplication with file locking to satisfy IT governance and compliance policies for active archive protection. Data Domain Retention Lock also enables electronic data shredding on a per-file basis to ensure that deleted files have been disposed of in an appropriate and permanent manner, in order to main confidentiality of classified material, limit liability, and enforce privacy requirements.

If using the Retention Lock feature, do the following steps to install the Retention Lock license, enable the feature, and specify the retention period during which the file cannot be deleted or modified. The default minimum retention period is 12 hours and the default maximum retention period is 5 years. The maximum retention period in a CIFS environment can be 70 years.

The retention period is specified in the format [number][unit]. Possible unit values are min, hr, day, mo, year.

With DDOS 5.0 and later, you will be able to have a different retention period for each MTree configured. It will also allow different retention periods for each Vault Store Partition configured with the supports Retention Lock option.

Add the Data Domain Retention Lock license:

1. Click the System Settings > Licenses tabs. If Retention Lock is not listed, add the retention lock license as follows:

a. In the Licensed Features pane, click Add. The Add License Key dialog box appears.

b. In the License Key text box, enter the license key.

c. Click OK. The added license appears in the license list.

2. Click the Data Management > MTree tabs. MTree summary information appears.

3. Select the MTree to which retention is to be applied and click on its Summary tab.

4. Scroll down to the Retention Lock area and click Edit. The Modify Retention Lock dialog box appears (Figure 6).


Figure 6 Modify Retention Lock dialog

5. Click the Enable check box to enable Retention Lock on the Data Domain system.

6. To modify the minimum or maximum retention period (the feature must be enabled first), modify the minimum or maximum time period:

a. Type a number for the interval in the text box (for example, 5 or 14). b. From the drop-down list, select an interval (minutes, hours, days, years). To

reset the minimum or maximum retention period to the default, click Default.

c. Click OK.

7. Repeat steps 3-6 for each additional MTree to which a Retention Period is to be applied.

For more information on the Retention Lock feature and its CLI commands, please refer to the Data Domain Retention Lock Software User Guide.


General recommendations When configuring Cloud Tiering Appliance Data Domain environment, please keep in mind the recommendations discussed in this section.

In file archiving environments, there are several factors that impact the effectiveness of the solution. Understanding your environment and how the user experience is affected by the factors discussed here can help you architect a successful solution. This section looks at three key areas and best practices that can be put in place to mitigate negative behavior. These areas are:

Data set profile Usage profile Scheduling of operations Data set profile

The number of files is important when using Data Domain systems. Data Domain systems can only comfortably handle 100 million files. Please keep this in mind when deploying a single system with both archive and backup workloads. Exceeding this limit will severely affect system overall performance.

Usage profile

The usage pattern of your end-users often dictate when certain operations should be scheduled in order to ensure that both enough resources are available to support those operations and they complete in a timely manner.

EMC recommends establishing end-user count sizing numbers and operations (file opens/reads/ reads+writes) using simple internal nfsstat/netstat mechanisms during these operations. This information will assist in the design related to tiering policies, backup schedules, and replication type.

Since data newer than 90 days old is accessed more frequently, EMC also recommends only migrating files older than 90 days to Data Domain to minimize the write activity and maximize the availability of the entire solution for end-users.

Scheduling operations

When deploying Data Domain as the Tier 2 storage with a Cloud Tiering Appliance, it is very important to take into consideration the scheduling of operations (backups, replication, cleaning). These operations consume resources and as such, impact performance.

To ensure optimal performance with the Data Domain system in this configuration, EMC recommend the following:

Ensure that backups and replication have completed before normal business hour (i.e. 7:00AM to7:00PM) end-user access to the Data Domain as a Tier 2 device. This will ensure optimal performance from the Data Domain.


Cleaning can also be scheduled on a daily, weekly, or monthly basis. For datasets with millions of files, please be aware that cleaning may take several days and consume system resources.

Establish archive policies with an understanding of these background operations and when they occur.

By archiving data that doesnt change frequently (older than 90 days) or not at all, cleaning operations need not be scheduled as aggressively thereby minimizing access delays experienced by end users during data recalls.


Configuring the Cloud Tiering Appliance with Data Domain Follow the steps in this section to configure the Cloud Tiering Appliance to use the Data Domain system as an archive target.

These steps apply whether you are archiving data in NFS exports or CIFS shares on the archive source to the Data Domain system.

Configure the Data Domain system as an archive target

Configuring the EMC Data Domain system as an archive target involves defining the EMC Data Domain system as a file server and creating a NAS repository for the archive data to the Cloud Tiering Appliance.

Configure Data Domain as a file server 1. In the Configuration tab of the Cloud Tiering Appliance GUI, click File Servers

under the Server Configuration menu on the left (Figure 7).

Figure 7 Cloud Tiering Appliance Configuration selections

2. Click New to create a new file server (Figure 8).


Figure 8 Create a new file server

3. Select Data Domain for the File Server Type (Figure 9).

Figure 9 Select the File Server Type

4. Enter a logical name for the server and the IP address of the Data Domain system (Figure 10). When entering the IP address, type the IP, and then click Add. Click Commit.


Figure 10 Enter the name and IP address of the EMC Data Domain system

Configure the Data Domain NAS repository 1. Click the Configuration tab. Select NAS Repository and NAS Group under the

Server Configuration menu.


Figure 11 NAS Repository List and NAS Group List

2. Click New to create a NAS repository (Figure 12).


Figure 12 Create New NAS Repository

3. Enter a name for the NAS repository.

4. Select the file server for the Data Domain you created earlier, and then select the NFS protocol.

5. Click Browse, and select the NFS repository you configured on the Data Domain.

6. Click Save Repository.

Define the archive rules After the Data Domain has been configured as an archive target, create an archive policy to move data from the archive source to the Data Domain NAS repository. This involves the following steps:

Naming the policy and providing retention details Defining the file matching criteria for moving data between tiers Specifying the target repository Creating a schedule for the policy These steps apply whether you are archiving data in NFS exports or CIFS shares to the Data Domain system.

Name the policy 1. Click the Policies tab on the main page of the Cloud Tiering Appliance GUI (Figure

13).


Figure 13 Policies main page

2. Click the Create new policy link in the upper right corner of the screen. The Create Policy window appears (Figure 14).


Figure 14 Create Policy screen

3. Begin creating the policy.

a. Specify a name for the policy.

b. Select archive as the Policy Type.

c. Optional: specify the length of time you want the EMC Data Domain system to retain the data. See Data retention on page 34 for more information on setting this parameter.

d. Specify a Delayed Stubbing Period of 0.

EMC recommends changing this value to 0 (zero) if the NAS repository is not being replicated.

Define the file matching criteria 1. Click Add Rule to define how files are selected for archive (Figure 15).


Figure 15 Define the file matching criteria

a. Click the desired File Attribute and Operator, and specify a value for the attribute.

b. Click Add to Rule.

c. Repeat steps a and b to create other file matching criteria for the rule. The Cloud Tiering Appliance will match files according to the criteria in the order created.

Specify the target 1. Once you have defined the file matching criteria, complete the policy setup in the

Select Action portion of the screen (Figure 16).


Figure 16 Policy action

a. Select Archive for the Action.

b. Choose the Add NAS Repositories option.

c. Choose NFS for Protocol.

d. Select the NAS Repository you created for the Data Domain and click Add to List.

e. Click Save Rule.

2. Click Save Policy or Save Policy & Schedule.

Create a schedule for the policy 1. Click the Schedule tab on the main page of the Cloud Tiering Appliance GUI

(Figure 17).


Figure 17 Schedule main page

2. Click the Schedule a new task link in the upper right corner of the screen. The Create Task screen appears (Figure 18).

Figure 18 Create Task screen


3. Under Select Task Type, choose the policy you want to schedule under Archive with policy.

4. Under Select Source, select the source File Server and Protocol NFS.

IMPORTANT: Always select NFS for the protocol even if you are archiving CIFS data.

5. Click Browse and select the path to the source data.

6. Under Select Archive Condition, configure the desired schedule and click Save Task.

The example settings shown in Figure 18 archive data from the ns480cifs1 server to the EMC Data Domain using a policy named test every morning at 2 A.M.

Perform a test archive Perform these steps after writing data to the archive source.

1. Click the Schedule tab on the main page of the Cloud Tiering Appliance GUI.

2. Select Archive for Show schedules of type. You will see a list of all schedules that perform an archive.

3. In the Status column, click the button next to Enable and select Run now (Figure 19).

Figure 19 Run a test archive

4. When the test archive completes, click View Summary and verify that files were archived to the Data Domain.

Retrieve an archived file If the file has been archived to the Data Domain system, but not yet stubbed, reads of that file occur with the version residing on the archive source.

If the file has been archived to the Data Domain system and stubbed on the archive source, reads of that file occur from the deduplicated version on the Data Domain.


To recall an archived file, simply utilize the stubbed file as you would the original file.

If the stub has been deleted

When a file has been archived to the Data Domain system and its stub file deleted from the source, the data is still available as it still resides on the Data Domain.

To re-create a file from a deleted stub file:

1. Select the Archived Files tab on the main page of the Cloud Tiering Appliance GUI.

2. Select View Archived Files List (Figure 20).

Figure 20 Archived File List

3. Select the Source repository, Protocol NFS, and the time period for when the file was archived. Click Get List.

4. Select the desired file from the list using its checkbox and click Recover Stub (Figure 21).


Figure 21 Recovering a deleted stub


Data retention CTA 7.5 retention supports the Data Domain Retention Lock feature. Ideally, CTA retention and Data Domain Retention Lock are used together. This prevents any modification or deletion of files under retention from occurring directly from the Data Domain export(s) during the retention period specified for the Retention Lock feature.

When CTA retention is in effect, these documents cannot be modified or deleted via CTA. CTA also allows a files stub to be subject to the retention period too.

Please note that only files that are explicitly committed by CTA to be retained files (that is archived with a policy with retention enabled) are retention locked on the Data Domain system. Files written to exports without retention set by CTA (even if Retention Lock is enabled on the Data Domain) can be modified or deleted at any time.

Files on Data Domain systems that are retention locked cannot be modified or deleted within the CTA-specified time period. Once the retention period for a file expires, the file can be deleted on the Data Domain system by CTA but not modified.

CTA retention holds documents for a user-specified amount of time. When that time expires, CTA can be set to automatically dispose of those records.

With Data Domain DDOS 4.x, a single retention period is defined for the filesystem. This retention period is in effect for all NFS exports associated with CTA retention regardless of the retention defined for that share.

With Data Domain DDOS 5.0, different retention periods can be defined on a per MTree basis. The NFS export created for that MTree will have the retention period associated with that MTree.

With CTA retention, create a separate NAS repository for each specific retention period that you want CTA to manage.

To configure an archive policy with retention:

These steps apply whether you are archiving data in NFS exports or CIFS shares to the Data Domain system.

Create the policy

Make sure you install the Data Domain Retention Lock license and enable and configure the feature as described in Enable the Retention Lock feature (optional) on page 12 for Data Domain systems running DDOS 4.x or page 17 for Data Domain systems running DDOS 5.0.

1. Click the Policies tab on the main page of the Cloud Tiering Appliance GUI.

2. Click the Create new policy link in the upper right corner of the screen. The Create Policy window appears (Figure 14).


Figure 22 Create Policy screen

3. Begin creating the policy.

a. Specify a name for the policy.

b. Select archive as the Policy Type.

c. Specify the length of time you want the EMC Data Domain system to retain the data. This time can be specified in terms of days, weeks, months, or years.

d. Click Stub Retention to also prevent deletion of the stub created for the file on the Tier 1 filer during the specified retention period.

e. Specify a Delayed Stubbing Period of 0.

EMC recommends changing this value to 0 (zero) if the NAS repository is not being replicated.

Define the file matching criteria 1. Click Add Rule to define how files are selected for archive.

a. Click the desired File Attribute and Operator, and specify a value for the attribute.

b. Click Add to Rule.

c. Repeat steps a and b to add other file matching criteria. The Cloud Tiering Appliance will match files according to the criteria in the order specified.

Specify the target 1. Once you have defined the file matching criteria, complete the policy setup in the

Select Action portion of the screen.


a. Select Archive for the Action.

b. Choose the Add NAS Repositories option.

c. Choose NFS for Protocol.

d. Select the NAS Repository you created for the Data Domain to use with that policy and click Add to List.

e. Click Save Rule.

2. Click Save Policy or Save Policy & Schedule.

Create a schedule for the policy 1. Click the Schedule tab on the main page of the Cloud Tiering Appliance GUI.

2. Click the Schedule a new task link in the upper right corner of the screen. The Create Task screen appears.

3. Under Select Task Type, choose the policy you want to schedule under Archive with policy.

4. Under Select Source, select the source File Server and Protocol NFS.

IMPORTANT: Always select NFS for the protocol even if you are archiving CIFS data.

5. Click Browse and select the path to the source data.

6. Under Select Archive Condition, configure the desired schedule and click Save Task.


Using with the Data Domain Archiver

The information in this section is applicable only to the Data Domain Archiver.

More information about the Data Domain Archiver can be found in the Data Domain user documentation for both DDOS 5.0 and the DD Archiver.

About the Data Domain Archiver

Data Domain Archiver addresses the long-term retention requirements of scale and cost by extending the proven Data Domain architecture with an internal tiering approach. There are two tiers, sharing a common controller, management, and namespace:

An active storage tier, which operates like a standard Data Domain system used for operational recovery

A highly scalable and cost-optimized archive storage tier, to which files are migrated internally when a policy threshold (time since last modification) is passed for long-term retention

These tiers are logical divisions of the storage attached to a single controller. Data is stored first to the active tier, and once it has been on the active tier without modification for a user-defined period of time, it is moved to the archive tier. The archive tier incorporates additional fault isolation and granular recoverability, larger capacity for archival data, improved manageability, and enhanced compression.

The DD Archiver active tier operates essentially the same way as a standard Data Domain system and is sized based upon the same guidelines. For example, one could size the active tier to hold weekly fulls and daily incrementals for up to 90 days. The active tier can be configured with one to four storage shelves, with up to 96 TB usable capacity.

The archive tier consists of one or more archive units. Each archive unit is a logical grouping of storage shelves, with its own deduplication context. Each archive unit can have one to four storage shelves, with up to 96 TB of usable capacity.

Data movement from the active tier to the archive tier is transparent to the Cloud Tiering Appliance. CTA operations with the DD Archiver are the same as those with a standard Data Domain system. All of the data in the two tiers is accessible, although there might be a slight delay on initial access to data in a sealed archive unit of the archive tier. The namespace of the system is global, and not affected by data movement. No partitioning of the file system is necessary to take advantage of the two-tiered file system.

Data Movement Policies

With the DD Archiver, the data movement policies are based on when a file was last modified. This movement policy can be set differently for each MTree. For example,


files that might be updated periodically after movement to the Archiver need a different policy than ones that will not change.

For example, it is recommended that the data movement policy be set to greater than 90 days as file access significantly decreases after that time.

Deduplication

The archive tier is comprised of one or more archive units, each of which may consist of one or more entire shelfs worth of storage. In addition to the deduplication that occurs when data is first written to the active tier, there is additional compression on the contents of the data moved to an archive unit. There is no cross-deduplication among archive units.

Storage

The concept of tiering extends to the storage level. The active tier operates as if it were a standalone non-Archiver Data Domain system. The active tier must include at least one shelf worth of storage. In a sense, it acts as a cache for data that is not considered to be static. As always, the active tier should be adequately sized to hold the data that will be retained for only a short time as well as the data that accumulates for movement to the archive tier. Space reclamation occurs only on the active tier (in the current release). Space reclamation occurs via the cleaning process.

For the archive tier, an archive unit can consist of one to four shelves of storage. And, there can be multiple archive units within the archive tier. As one archive unit fills up, simply add an additional archive unit with one or more shelves of storage. For fault isolation purposes, the Archiver seals an archive unit when full allowing no additional data to be written to it. Its contents, however, are fully accessible. The Archiver then brings the next archive unit online allowing for incremental capacity growth for the long-term retention of data. Please note that space reclamation does not run on archive units (in the current release). Data moved to the archive tier that is subsequently modified or deleted will result in wasted space. Space reclamation does not run on an archive unit until all files within that unit have been expired and deleted by the application.

Mixed Use

When using the DD Archiver as a storage target for both backup and archive data, keep in mind the following:

Create separate MTrees for archive data. The default data movement policy for an MTree is 14 days, which may be fine for backup data to be stored for long term retention (2 years or greater) but not long enough for infrequently accessed data to become static (subject to very little or no modification). If desired, create multiple MTrees for data that ages at different rates.

Data that is frequently accessed should have a longer file movement policy to give it time to become more static.


Data that is being archived to the DD Archiver with no expectations of modification can be written to MTrees with aggressive data movement policies.

Size the active tier as you normally would for your backups and then calculate and add in the additional capacity needed to accommodate the archive data and its data movement policies.

Recommended best practices By design, once data is written to the DD Archiver, no modifications should occur.

Should files that are not yet static be written to the Archiver, keep them on the active tier until access is minimal.

The best use case for the DD Archiver with the Cloud Tiering Appliance is data under retention.

Ensure that the active tier is adequately sized to at any time hold data waiting to be moved to the archive tier as well as data that will never be migrated to the archive tier.

Avoid these common sizing errors: Setting a data movement policy that is overly aggressive in which data is

moved too soon. Modifying or deleting data that is present in an archive unit results in space that cannot be reclaimed until all data in that unit has been expired and deleted.

Setting a data movement policy that is too conservative. Once the active tier fills up, no more data can be written to the system.

Defining an undersized active unit, such that the active tier fills up prematurely. This can result in the use of overly aggressive movement policies to compensate for an undersized active tier.

Cloud Tiering Appliance orphan deletion will not save space consumption on DD Archiver.

Backup and/or archiving performance may be degraded while the cleaning or garbage collection process is running on the active tier. Try to schedule this process during light workloads or activity. Or, you can use the existing QoS functionality to manage cleaning and new backup data being written to DD Archiver.

Backup and/or archiving performance may be degraded while data movement to the archive tier is occurring. Try to schedule this process during light workloads or activity.

DD Archiver must always be final tier in a multi-tier policy in a CTA environment. CTA has a Repository Migration feature where customers can relocate their second

tier to a different location. Special consideration should be taken if the second tier is on the DD Archiver in terms of space reclamation.


Configuring data movement

A file is moved from the active to the archive tier based on the date it was last modified. For data integrity, the entire file is moved.

You can specify the data movement age threshold after which data that has not been modified is to be moved from the active to the archive tier. You can specify different age thresholds for each of your defined MTrees.

To set a general data movement policy:

1. Go to Data Management > File System and select the Configuration tab.

Figure 23 Data Movement Policy

2. Click the Data Movement Policys Edit button (Figure 23).


Figure 24 Data Movement Policy dialog

a. In the Data Movement Policy dialog box (Figure 24), select the threshold number of days. When the data movement starts, all the files that have not been accessed for the specified threshold number of days are moved from the active tier to the archive tier.

b. Set a schedule for the data movement policy. For example, weekly, daily, specific days, and a time in hours and minutes.

c. A file system clean is recommended after the data movement. De-select this option if you do not want the clean to occur.

To configure the age threshold for an individual MTree:

1. Go to Data Management > MTree and select the MTree whos age criteria is to be set.

2. In the MTrees Summary tab, scroll down to Data Movement Policy and click Edit.

3. Specify the age value for movement of files in this MTree to the Archive tier (Figure 25).


Figure 25 Age Threshold dialog

4. Repeat steps 1-3 to set the age value for data movement for other MTrees.

Data movement of files associated with an MTree occurs when files meeting the age criteria associated with the MTree are found when the Data Movement policy executes. Files not meeting that MTrees age criteria at the time of policy execution remain in the active tier.

h7258.2 data domain cta ig

Documents

emc data domain

data domain system

data domain ddos

emc software

cifs data

emc corporation trademarks

x system configuration

publication date