version 4.0 | document revision 1

1 Overview

1.1 Introduction

DataCore FileFly provides policy-based file tiering for Windows files and SMB shares. It automates and manages the movement of files from primary storage locations to lower cost object storage residing on-premises or on public clouds. The source locations may be Windows File Servers and SMB file shares exported by NetApp and Isilon NAS devices. The destinations include DataCore Swarm Object Storage as well as public cloud storage providers adhering to the S3 protocol such as Amazon S3, Microsoft Azure, Google Cloud Storage, Wasabi Cloud and others.
Files are migrated from primary storage locations to the object store. Files are demigrated transparently when accessed by a user or application. FileFly also provides a range of Disaster Recovery options.

1.1.0.1 What is Migration?

From a technical perspective, file migration can be summarized as follows: first, the file content and corresponding metadata are copied to secondary storage as an MWI file/object. Next, the original file is marked as a 'stub' and truncated to zero physical size (while retaining the original logical size for the benefit of users and the correct operation of applications). The resulting stub file remains on primary storage in this state until such time as a user or application requests access to the file content, at which point the data is automatically returned to primary storage.
Each stub encapsulates the location of the corresponding MWI data on secondary storage, without the need for a database or other centralized component.

1.2 Conventions used in this Book

References to labels, values and literals in the software are in 'quoted italics'.
References to actions, such as clicking buttons, are in bold.
References to commands and text typed in are in fixed font.
Notes are denoted: Note: This is a note.
Important notes are denoted: Important: Important point here.

1.3 System Components

1.1 provides an overview of a FileFly deployment. All communication between FileFly components is secured with Transport Layer Security (TLS). The individual components are described below.

 
FileFly System Overview

1.3.0.1 DataCore FileFly Admin Portal

FileFly Admin Portal is the system's policy manager. It provides a centralized web-based configuration interface, and is responsible for task scheduling, server monitoring and file reporting. It lies outside the data path for file transfers.

1.3.0.2 DataCore FileFly Agent

DataCore FileFly Agent performs file operations as directed by Admin Portal Policies. The FileFly Agent is also responsible for retrieving file data from secondary storage upon user / application access.
File operations include migration and demigration, as well as a range of operations to assist disaster recovery. Data is streamed directly between agents and storage without any intermediary staging on disk.
When installed in a Gateway configuration, FileFly Agent does not allow migration of files from that server.
Optionally, Gateways can be configured for High-Availability (HA).

1.3.0.3 DataCore FileFly FPolicy Server

FileFly FPolicy Server provides migration support for NetApp filers using the NetApp FPolicy protocol. This component is the equivalent of DataCore FileFly Agent for NetApp filers.
FileFly FPolicy Server may also be configured for High-Availability (HA).

1.3.0.4 DataCore FileFly LinkConnect Server

FileFly LinkConnect Server provides link-based migration support for either Dell EMC OneFS or as an alternative method for migrating files from Windows Server volumes in the case where an agent may not be installed directly on the file server. This component performs a similar role to DataCore FileFly Agent for SMB shares.
FileFly LinkConnect Server may also be configured for High-Availability (HA).

1.3.0.5 DataCore FileFly DrTool

DataCore FileFly DrTool is an additional application that assists in Disaster Recovery.
Note: This functionality is not included with Community Edition licenses.

1.4 FileFly Admin Portal Concepts

DataCore FileFly Admin Portal is the web-based interface that provides central management of a FileFly deployment. It is installed as part of the FileFly Tools package.
When entering the FileFly Admin Portal, the 'Dashboard' displays – more on the dashboard in §1.5. The remainder of this section follows the Admin Portal's navigation menu.

1.4.1 Servers

The 'Servers' page displays the installed and activated agents across the deployment of FileFly. Health information and statistics are provided for each server or cluster node. Use this page when activating the other components in your system.
Click a Server's ellipsis control to:

• view additional server information

• configure storage plugins

• add / retire / restart cluster nodes

• upgrade a standalone server to high-availability

• view detailed charts of recent activity

• edit server-specific configuration (see Appendix E)

1.4.2 Sources

Sources describe volumes or folders to which Policies may be applied (e.g., locations on the network from which files may be Migrated).
A Source location is specified by a URI. Platform-specific information for all supported sources is detailed in Chapter 5. A filesystem browser is provided to assist in setting the URI location interactively.

1.4.2.1 Subdirectory Filtering

Within a given Source, individual directory subtrees may be included or excluded to provide greater control over which files are eligible for policy operations. Excluded directories are not traversed.
In the Source editor, the directory tree may be expanded and explored in the 'Subdirectory Filtering' section. By default, the entire source is included.

1.4.3 Destinations

Destinations are storage locations that Policies may write files to (e.g., locations on the network to which files are Migrated). Platform-specific information for all supported sources is detailed in Chapter 5.
Optionally, a Destination may be configured to use Write Once Read Many (WORM) semantics for migration operations. No attempt is made thereafter to update the resultant secondary storage objects. This option is useful when the underlying storage device has WORM-like behavior, but is exposed using a generic protocol.

1.4.4 Rules

Rules allow a specific subset of files within a Source or Sources to be selected for processing.
Rules can match a variety of metadata: filename / pathname, size, timestamps / age, file owner, and attribute flags. A rule matches if all of its specified criteria match the file's metadata. However, rules can be negated or compounded as necessary to perform more complex matches.
You will be able to simulate your Rules against your Sources during Policy creation.
Some criteria are specified as comma-separated lists of patterns:

• wildcard patterns, e.g. *.doc (see Appendix A.1)

• regular expressions, e.g. /2004-06-[0-9][0-9]\.log/ (see Appendix A.2)

Note that:

• files match if any one of the patterns in the list match

• whitespace before and after each pattern is ignored

• patterns are case-insensitive

• filename patterns starting with '/' match the path from the point specified by the Source URI

• filename patterns NOT starting with '/' match files in any subtree

• literal commas within a pattern must be escaped with a backslash

1.4.5 Policies

A Policy specifies an operation to perform on a set of files. Depending on the type of operation, a Policy will specify Source(s) and/or Destination(s), and possibly Rules to limit the Policy to a subset of files.
Each operation has different parameters, refer to Chapter 4 for a full reference.

1.4.6 Tasks

A Task schedules one or more Policies for execution. Tasks can be scheduled to run at specific times, or can be run on-demand using the Quick Run control on the 'Dashboard'.
While a Task is running, its status is displayed in the 'Running Tasks' panel of the 'Dashboard'. When Tasks finish they are moved to the 'Recent Tasks' panel.
Operation statistics are updated in real-time as the task runs. Operations will automatically be executed in parallel, see E for more details.
If multiple Tasks are scheduled to start simultaneously, Policies on each Source are grouped such that only a single traversal of each file system is required.

1.4.6.1 Completion Notification

When a Task finishes running, regardless of whether it succeeds or fails, a completion notification email may be sent as a convenience to the administrator. This notification email contains summary information similar to that available in the 'Recent Tasks' panel on the 'Dashboard'.
To use this feature, either:

• check the 'Notify completion' option when configuring the Task, or

• click the notify icon on a running task on the 'Dashboard'

1.4.7 Reports

Reports – generated by Gather Statistics Policies – contain charts detailing:

• a 30-day review of access and change activity

• a long-term trend chart to assist with planning migration strategy

• a breakdown of the most common file types

• optionally, a breakdown of file ownership

1.4.8 Recovery

The 'Recovery' page provides access to multiple versions of the recovery files produced by each Create Recovery File From Source/Destination Policy. Retention options may be adjusted in 'Settings'.
Refer to Chapter 6 for more information on performing recovery operations.

1.4.9 Settings

The FileFly Admin Portal 'Settings' page allows the configuration of a wide range of global settings including:

• email notification

• configuration backup (see §3.3)

• work hours

• Admin Portal logging

• user interface language selection

It is also possible to suspend the scheduler, to prevent scheduled Tasks starting while maintenance procedures are being performed.
Server-specific settings and plugin configuration are available on the 'Servers' page.

1.4.10 Help

The 'Help' page provides version information, as well as links to documentation and support resources. You may also view the global log, or generate a system diagnostic file (support.zip) for use when contacting DataCore Support.

1.5 FileFly Admin Portal Dashboard

The 'Dashboard' provides a concise view of the FileFly system status, current activity, and recent task history. It may also be used to run Tasks on-demand using the Quick Run control.
The 'Notices' panel, displayed on the expandable graph bar, summarizes system issues that need to be addressed by the administrator. This panel will guide you through initial setup tasks such as license installation.
The circular 'Servers' display shows high-level health information for the servers/clusters in the FileFly deployment.

1.5.1 Storage Charts

'Primary' and 'Secondary' storage charts may be read together to gain insight into the impact of currently configured migration policies on primary and secondary storage consumption over time. Each bar indicates an amount of storage space consumed or released. Consumed storage is indicated by a positive bar, while released storage is shown in the negative. Stacked bars indicate the contributions of the different operations by color.
A Migration Policy consumes secondary storage in order to release primary storage.
Demigration consumes primary storage immediately, but defers release until later. Either the primary storage is released by a Quick-Remigrate, or the associated secondary storage is released by a Scrub.
In a complex environment, these charts provide insight into patterns of user-behavior and policy activity.
Click on a bar to zoom in to an hourly breakdown for the chosen day.

1.5.2 Other Charts

The 'Processed' line chart graphs both the rate of operations successfully performed and data processed over time. Data transfer and bytes Quick-Remigrated (i.e. without any transfer required) are shown separately.
The 'Operations' breakdown chart shows successful activity by operation type across the whole system over time. Additionally, per-server operations charts are available using the 'Servers' page – see §1.4.1.
The 'Operations' radar chart shows a visual representation of the relative operation profile across your deployment. Two figures are drawn, one for each of the two preceding 7-day periods. This allows behavioral change from week to week to be seen at a glance.

1.5.3 Task Control & History

Per-file operation details (including any error messages) may be viewed by clicking a Task's log icon. It is also possible to start and stop Tasks, update task configuration, or request a completion notification for a task that is already in progress.

2 Deployment

Refer to these instructions during initial deployment and when adding new components. For upgrade instructions, please refer to §3.7 instead.
For further information about each supported storage platform, refer to Chapter 5.

2.1 Installing FileFly Tools

The DataCore FileFly Tools package consists of the FileFly Admin Portal and the FileFly DrTool application (not licensed for Community Edition users). FileFly Tools must be installed before any other components.

2.1.0.1 System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2019

  • Windows Server 2016

  • Windows Server 2012 R2

  • Windows Server 2012

• Minimum 4GB RAM

• Minimum 2GB disk space for log files

• Active clock synchronization (e.g. using NTP)

2.1.0.2 Setup

1. Run DataCore FileFly Tools.exe

2. Follow the instructions on screen

After completing the installation process, FileFly Tools must be configured using the Admin Portal web interface. The FileFly Admin Portal will be opened automatically and can be found later using the Start Menu.
The web interface will lead you through the process of initial configuration: refer to the 'Notices' panel on the 'Dashboard' to verify all steps are completed.

2.2 Installing FileFly Agents

Each FileFly Agent server may fulfill one of two roles, selected at installation time.
In the 'FileFly Agent for migration' role, an agent assists the operating system to migrate and demigrate files. It is essential for the agent to be installed on all machines from which files will be migrated.
In the 'FileFly Gateway agent' role, an agent provides access to external devices and storage services. While it does allow access to local disk and mounted SAN volumes, it does not provide local migration source support. Storage plugins will normally be deployed on Gateways.

2.2.1 High-Availability Gateway Configuration

A high-availability gateway configuration is recommended. Such FileFly Gateways must be activated as 'High-Availability FileFly Gateways'.

2.2.1.1 High-Availability Gateway DNS Setup

At least two FileFly Gateways are required for High-Availability.

1. Add each FileFly Gateway server to DNS

2. Create an FQDN that resolves to all of the IP addresses

3. Use this FQDN when activating the HA Servers

4. Use this FQDN (or a CNAME alias to it) in FileFly Destination URIs

Example:

• gw-1.example.com → 192.168.0.1

• gw-2.example.com → 192.168.0.2

• gw.example.com → 192.168.0.1, 192.168.0.2

Note: The servers that form the High-Availability Gateway cluster must NOT be members of a Windows failover cluster.

2.2.2 DataCore FileFly Agent for Windows Servers

2.2.2.1 System Requirements

• Supported Windows Server operating system:

  • Windows Server 2019

  • Windows Server 2016

  • Windows Server 2012 R2

  • Windows Server 2012

• Minimum 4GB RAM

• Minimum 2GB disk space for log files

• Active clock synchronization (e.g. using NTP)

Note: When installed in the Gateway role, a dedicated server is required, unless it is to be co-located on the FileFly Tools server. When co-locating, create separate DNS aliases to refer to the Gateway and the FileFly Admin Portal web interface.

2.2.2.2 Setup

1. Run the DataCore FileFly Agent.exe

2. Follow the instructions to activate the agent using FileFly Admin Portal

2.2.3 DataCore FileFly FPolicy Server for NetApp Filers

A DataCore FileFly FPolicy Server provides migration support for one or more NetApp Filers through the FPolicy protocol. This component is the equivalent of DataCore FileFly Agent for NetApp Filers. Typically FileFly FPolicy Servers are installed in a high-availability configuration.

2.2.3.1 System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2019

  • Windows Server 2016

  • Windows Server 2012 R2

  • Windows Server 2012

• Minimum 4GB RAM

• Minimum 2GB disk space for log files

• Active clock synchronization (e.g. using NTP)

2.2.3.2 Setup

Installation of the FileFly FPolicy Server software requires careful preparation of the NetApp Filer and the FileFly FPolicy Server machines. Instructions are provided in §5.3.

2.2.4 DataCore FileFly LinkConnect Server

A DataCore FileFly LinkConnect Server provides link-based migration support for one or more Dell EMC OneFS or Windows SMB shares. This component performs a similar role to DataCore FileFly Agent without the need for software to be installed directly on the NAS or file server.

2.2.4.1 System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2019

  • Windows Server 2016

• Minimum 2GB disk space for log files (on the system volume)

• Minimum 1TB disk space for LinkConnect Cache (as a single NTFS volume)

• RAM: 8GB base, plus:

  • 4GB per TB of LinkConnect Cache

  • 0.5GB per billion link-migrated files

• Active clock synchronization (e.g. using NTP)

2.2.4.2 Setup

Installation of the FileFly LinkConnect Server software requires careful configuration of both the NAS / file server and the FileFly LinkConnect Server machines. Instructions are provided in §5.4 for OneFS and §5.2 for Windows file servers. Other devices are not supported.

2.3 LinkConnect Client Deployment

2.3.0.1 Installation

Having deployed one or more LinkConnect Servers, all Windows clients that will need to access link-migrated files will require the LinkConnect Client Driver to be installed as follows:

1. Verify the client machine is joined to the Active Directory domain

2. Run DataCore FileFly LinkConnect Client Driver.exe

3. Follow the prompts

Alternatively, to ease deployment, the installer may be run in silent mode by specifying /S on the command line. Note that when upgrading the driver silently, the updated driver will not be loaded until the next reboot.
Important: Client Driver versions newer than the installed FileFly LinkConnect Server version should not be deployed.

2.3.0.2 Deployment Considerations

Access to NAS / file server shares containing files that have been link-migrated must use the domain credentials of the logged-in Windows desktop session. When a user accesses a link-migrated file, the client driver will transparently redirect the access to the FileFly LinkConnect Server if required. This redirected access will use the same logged-in Windows desktop session credentials.
Installation of the client driver will enable remote symlink evaluation in Windows. If remote symlink evaluation was disabled prior to client driver installation (this is the default behavior in Windows 10), the driver will continue to prevent remote symlink access for other symlinks. Do not disable remote symlink evaluation (e.g. by group policy) after installation since performing this causes the client driver to stop functioning.

3 Usage

3.1 DNS Best Practice

Storage locations in DataCore FileFly are referred to by URI. Relationships between files must be maintained over a long period of time. Verify the FQDNs used in these URIs are valid long-term, even as individual server roles are changed or consolidated.
In a production deployment, always use Fully Qualified Domain Names (FQDNs) in preference to bare IP addresses.
It is recommended to create DNS aliases for each logical storage role for each server. For example, use different DNS aliases when storing your finance department's data as opposed to your engineering department's data – even if they initially reside on the same server.

3.2 Getting Started

3.2.1 Analyzing Volumes

Once the software has been installed, the first step in any new FileFly deployment is to analyze the characteristics of the primary storage volumes. The following steps describe how to generate file statistics reports for each volume.
In the FileFly Admin Portal web interface:

1. Create Sources for each volume to analyze

2. Create a 'Gather Statistics' Policy and select all defined Sources

3. Create a Task for the 'Gather Statistics' Policy

   • For now, disable the schedule

4. On the 'Dashboard', click the quick run icon

5. Run the Task

6. When the Task has finished, view the report(s) on the 'Reports' page3.2.2 Migrating Files

Using the information from the reports, create a rule to select files for migration. A typical rule might limit migrations to files modified more than six months ago. The reports' long-term trend charts indicate the amount of data migrated by a 'modified more than n months ago' rule – adjust the age cutoff as necessary to suit your filesystems.
To avoid unnecessary migration of active files, be conservative with your first Migration Rule – it can be updated to migrate more recently modified files on subsequent runs.
Once the Rule has been created:

1. Create a Destination to store your migrated data

   • see Chapter 5 for platform-specific instructions

2. Create a Migration Policy and add the Source(s), Rule, and Destination

3. Use the 'Simulate rule matching…' button to explore the effect of your rule

4. Create a Task for the new Policy

5. Run the task

When the task is completed, check the corresponding 'Recent Tasks' entries on the 'Dashboard'. Click on the log icon to review any errors in detail.
Migration is typically performed periodically: configure a schedule on the Migration Task.

3.2.3 Next Steps

Chapter 4 describes all FileFly Policy Operations in detail and helps to get the most out of FileFly.
The remainder of this chapter gives guidance on using FileFly in a production environment.

3.3 Configuration Backup

This section describes how to backup DataCore FileFly configuration (for primary and secondary storage backup considerations, see §3.4).

3.3.1 FileFly Tools

Backing up the DataCore FileFly Tools configuration preserves policy configuration and server registrations as well as per-server settings and storage plugin configuration.

3.3.1.1 Backup Process

Configuration backup can be scheduled on the Admin Portal's 'Settings' page. A default schedule is created at installation time to backup configuration once a week.
Configuration backup files include:

• Policy configuration

• Server registrations

• Per-Server settings, including plugin configuration, keys, etc.

  • Note: FileFly FPolicy Server configuration is not included – see §3.3.2.1

• Recovery files

• Settings from the Admin Portal 'Settings' page

• Settings specified when FileFly Tools was installed

It is strongly recommended that these backup files are retrieved and stored securely as part of your overall backup plan. These backup files can be found at:
C:\Program Files\DataCore FileFly\data\AdminPortal\configBackups
Additionally, log files may be backed up from:

• C:\Program Files\DataCore FileFly\logs\AdminPortal\

• C:\Program Files\DataCore FileFly\logs\DrTool\

3.3.1.2 Restore Process

1. Verify the server to be restored and has the same FQDN as the original server

2. If present, uninstall DataCore FileFly Tools

3. Run the installer: DataCore FileFly Tools.exe

   • use the same version that was used to generate the backup file

4. On the 'Installation Type' page, select 'Restore from Backup'

5. Choose the backup zip file and follow the instructions

6. Optionally, log files may be restored from server backups to:

   • C:\Program Files\DataCore FileFly\logs\AdminPortal\

   • C:\Program Files\DataCore FileFly\logs\DrTool\

3.3.2 Per-Server Configuration

Backing up the configuration on each server will allow for easier redeployment of agents in the event of a disaster.

3.3.2.1 Windows Backup Process

On each Windows Server backup the entire installation directory.
e.g. C:\Program Files\DataCore FileFly\

3.3.2.2 Windows Restore Process

On each replacement server:

1. Reinstall with the same version of the installer

2. Stop the 'DataCore FileFly Agent' service

3. Restore the contents of the following directories from the backup:

   • C:\Program Files\DataCore FileFly\data\FileFly Agent\

   • C:\Program Files\DataCore FileFly\logs\FileFly Agent\

4. Restart the 'DataCore FileFly Agent' service

3.4 Storage Backup

Each stub on primary storage is linked to a corresponding MWI file on secondary storage. During the normal process of migration and demigration, the relationship between the stub and MWI file is maintained.
The recommendations below guarantee the consistency of this relationship is maintained even after files are restored from the backup.

3.4.1 Backup Planning

Verify the restoration of stubs is included as part of the backup & restore test regimen.
When using Scrub policies, verify the Scrub grace period is sufficient to cover the time from when a backup is taken to when the restore and Post-Restore Revalidate steps are completed (see §3.4.2).
It is strongly recommended to set the global minimum grace period accordingly to guard against the accidental creation of scrub policies with insufficient grace. This setting may be configured on that FileFly Admin Portal 'Settings' page.
Important: It is NOT possible to safely restore stubs or MigLinks from a backup set taken more than one grace period ago.

3.4.1.1 Additional Planning

To complement standard backup and recovery solutions, and to allow the widest range of recovery options, it is recommended to schedule a 'Create Recovery File From Source' Policy to run after each migration.

3.4.2 Restore Process

1. Suspend the scheduler in FileFly Admin Portal

2. Restore the primary volume

3. Run a 'Post-Restore Revalidate' policy against the primary volume

   • To verify all stubs are revalidated, run this policy against the entire primary volume, NOT against the migration source

   • This policy is not required when only WORM destinations are in use

4. Restart the scheduler in FileFly Admin Portal

If restoring the primary volume to a different server (a server with a different FQDN), the following preparatory steps are required:

1. On the 'Servers' page, retire the old server (unless still in use for other volumes)

2. Install FileFly Agent on the new server

3. Update Sources as required to refer to the FQDN of the new server

4. Perform the restore process as above

3.4.3 Platform-specific Considerations

3.4.3.1 Windows

Most enterprise Windows backup software respect FileFly stubs and back them up correctly without causing any unwanted demigrations. For some backup software, it may be necessary to refer to the software documentation for options regarding Offline files.
When testing backup software configuration, test that backup of stubs does not cause unwanted demigration.
Additional backup testing may be required if Stub Deletion Monitoring is required. Please refer to Appendix E for more details.

3.4.3.2 NetApp Filers

Please consult §5.3.5 for information regarding snapshot restore on NetApp Filers.

3.5 Production Readiness Checklist

3.5.0.1 Backup

1. Check your FileFly configuration is adequately backed up – see §3.3

2. Review the storage backup and restore procedures described in §3.4

3. Check backup software can backup stubs without triggering demigration

4. Check backup software restores stubs and that they can be demigrated

5. Schedule regular 'Create Recovery File From Source' Policies on your migration sources – see §4.10

3.5.0.2 Antivirus

Generally, antivirus software does not cause demigrations during normal file access. Some antivirus software demigrates files when performing scheduled file system scans.
Prior to production deployment, always check that installed antivirus software does not cause unwanted demigrations. Some software must be configured to skip offline files in order to avoid these inappropriate demigrations. Consult the antivirus software documentation for further details.
If the antivirus software does not provide an option to skip offline files during a scan, DataCore FileFly Agent may be configured to deny demigration rights to the antivirus software. Refer to Appendix E for more information.
It may be necessary for some antivirus products to exempt the DataCore FileFly Agent process from real-time protection (scan-on-access). If the exclusion configuration requires the path of the executable to be specified, be sure to update the exclusion whenever FileFly is upgraded (since the path changes on upgrade).

3.5.0.3 Other System-wide Applications

Check for other applications that open all the files on the whole volume. Audit scheduled processes on file servers – if such processes cause unwanted demigration, it may be possible to block them (see Appendix E).

3.5.0.4 Monitoring and Notification

To facilitate proactive monitoring, it is recommended to:

1. Configure email notifications to monitor system health and Task activity

2. Enable syslog – see Appendix E

3.5.0.5 Platform Considerations

For further information on platform-specific interoperability considerations, please refer to the appropriate sections of Chapter 5.

3.6 Policy Tuning

Periodically re-assess file distribution and access behavior:

1. Run 'Gather Statistics' Policies

   • Examine reports

2. Examine Server statistics – see §1.4.1

   • For more detail, examine demigrates in file server agent.log files

Consider:

• Are there unexpected peaks in demigration activity?

• Are there any file types that should not be migrated?

• Should different rules be applied to different file types?

• Is the Migration Policy migrating data that is regularly accessed?

• Are the Rules aggressive enough or too aggressive?

• What is the data growth rate on primary and secondary storage?

• Are there subtrees on the source file system that should be addressed by separate policies or excluded from the source entirely?

3.7 System Upgrade

When a FileFly deployment is upgraded from a previous version, FileFly Tools must always be upgraded first, followed by all Server components.
Run:

• DataCore FileFly Tools.exe

3.7.1 Automated Server Upgrade

Where possible, it is advisable to upgrade Server agents using the automated upgrade feature by clicking the upgrade system icon on the 'Servers' page.
The automated process transfers installers to each server and performs the upgrades in parallel to minimize downtime. If a server fails or is offline during the upgrade, manually upgrade it later. Once the automated upgrade procedure is finalized, the 'Servers' page will update to display the health of the upgraded servers.
Following the upgrade, resolve any warnings displayed on the 'Dashboard'.

3.7.2 Manual Server Upgrade

Follow the instructions appropriate for the platform of each server as described below.

3.7.2.1 FileFly Agent for Windows

1. Run DataCore FileFly Agent.exe and follow the instructions

2. Resolve any warnings displayed on the 'Dashboard'

3.7.2.2 FileFly NetApp FPolicy Server

1. Run DataCore FileFly NetApp FPolicy Server.exe and follow the instructions

2. Run DataCore FileFly NetApp Cluster-mode Config.exe and follow the instructions

3. Resolve any warnings displayed on the 'Dashboard'

3.7.2.3 FileFly LinkConnect Server

1. Run DataCore FileFly LinkConnect Server.exe and follow the instructions

2. Resolve any warnings displayed on the 'Dashboard'

4 Policy Operation Reference

This chapter describes the various operations that may be performed on selected files by FileFly Admin Portal policies.

4.1 Gather Statistics Operation

Requires: Source(s) Included in Community Edition: yes
Generate statistics report(s) for file sets at the selected Source(s). Optionally include statistics by the file owner. By default, owner statistics are omitted which generally results in a faster policy run. Additionally, rules may be used to specify a subset of files on which to report rather than the whole source.

4.2 Migrate Operation

Requires: Source(s), Rule(s), Destination Included in Community Edition: yes
Migrate file data from selected Source(s) to a Destination. Stub files remain at the Source location as placeholders until files are demigrated. File content is transparently demigrated (returned to primary storage) when accessed by a user or application. Stub files retain the original logical size and file metadata. Files containing no data are not migrated.
Each Migrate operation is logged as a Migrate, Remigrate, or Quick-Remigrate.
A Remigrate is the same as a Migrate except it explicitly recognizes that a previous version of the file had been migrated in the past and that stored data pertaining to that previous version is no longer required and so is eligible for removal using a Scrub policy.
A Quick-Remigrate occurs when a file has been demigrated and NOT modified. In this case, it is not necessary to retransfer the data to secondary storage so the operation can be performed very quickly. Quick-remigration does not change the secondary storage location of the migrated data.
Optionally, quick-remigration of files demigrated within a specified number of days may be prevented. This option can be used to avoid quick-remigrations occurring in an overly aggressive fashion.
Additionally, this policy may be configured to pause during the globally configured work hours.
Note: For Sources using a FileFly LinkConnect Server, such as Dell EMC OneFS shares, see §4.9 instead.

4.3 Quick-Remigrate Operation

Requires: Source(s), Rule(s) Included in Community Edition: yes
Quick-Remigrate demigrated files that do not require data transfer, enabling space to be reclaimed quickly. This operation acts only on files that have not been altered since the last migration.
Optionally, files demigrated within a specified number of days may be prevented. This option can be used to avoid quick-remigrations occurring in an overly aggressive fashion.
Additionally, this policy may be configured to pause during the globally configured work hours.

4.4 Scrub Destination Operation

Requires: Destination (non-WORM) Included in Community Edition: yes
Remove unnecessary stored file content from a migration destination. This is a maintenance policy that should be scheduled regularly to reclaim space.
A grace period must be specified which is sufficient to cover the time from when a backup is taken to when the restore and corresponding Post-Restore Revalidate policy would complete. The grace period effectively delays the removal of data sufficiently to accommodate the effects of restoring primary storage from backup to an earlier state.
Use of scrub is usually desirable to maximize storage efficiency. In order to also maximize performance benefits from quick-remigration, it is advisable to schedule migration / quick-remigration policies more frequently than the grace period.
To avoid interactions with migration policies, Scrub tasks are automatically paused while migration-related tasks are in progress.
Scrub Policies may be configured to generate log output only without actually removing files.
Important: Source(s) MUST be backed up within the grace period.

4.5 Post-Restore Revalidate Operation

Requires: Source(s) Included in Community Edition: yes
Scan all stubs present on a given Source, revalidating the relationship between the stubs and the corresponding files on secondary storage. This operation is required following a restore from backup and should be performed on the root of the restored source volume.
If only Write Once Read Many (WORM) destinations are in use, this policy is not required.
Important: This revalidation operation MUST be integrated into backup/restore procedures, see §3.4.1.

4.6 Demigrate Operation

Requires: Source(s), Rule(s) Included in Community Edition: yes
Return migrated file content back to files on the selected Source(s). This is useful when a large batch of files must be demigrated in advance.
Prior to running a Demigrate policy, be sure that there is sufficient primary storage available to accommodate the demigrated data.
This operation may be used with both Migrated and Link-Migrated files.

4.7 Advanced Demigrate Operation

Requires: Source(s), Rule(s) Included in Community Edition: yes
Demigrates files with advanced options:

• Disconnect files from destination – remove destination information from demigrated files (both files demigrated by this policy and files that have already been demigrated); it is not possible to quick-remigrate these files

• A Destination Filter may optionally be specified in order to demigrate/disconnect only files that were migrated to a particular destination

Prior to running an Advanced Demigrate policy, be sure that there is sufficient primary storage available to accommodate the demigrated data.

4.8 Premigrate Operation

Requires: Source(s), Rule(s), Destination Included in Community Edition: yes
Premigrate file data from selected Source(s) to a Destination in preparation for migration. Files on primary storage are not converted to stubs until a Migrate or Quick-Remigrate Policy is run. Files containing no data are not premigrated.
This can assist with:

• a requirement to delay the stubbing process until secondary storage backup or replication has occurred

• reduction of excessive demigrations while still allowing an aggressive Migration Policy.

Premigration is, as the name suggests, intended to be followed by full migration/quick-remigration. If this is not done, a large number of files in the premigrated state may slow down further premigration policies, as the same files are rechecked each time.
By default, files already premigrated to another destination are skipped when encountered during a premigrate policy.
This policy may also be configured to pause during the globally configured work hours.
Note: Most deployments do not use this operation, but use a combination of Migrate and Quick-Remigrate instead.

4.9 Link-Migrate Operation

Requires: Source(s), Rule(s), Destination Included in Community Edition: yes
For platforms that do not support standard stub-based migration, Link-Migrate file data from selected Source(s) to a Destination.
Files at the source location are replaced with FileFly-encoded links (MigLinks) which allow client applications to transparently read data without returning files to primary storage. If an application attempts to modify a link, the file is automatically returned to primary storage and then modified in-place. Files containing no data are skipped by this policy.
MigLinks present the original logical size and file metadata.
Since MigLinks remain links when read by client applications, there is no analogue of quick-remigration for link-migrate.
This policy may be configured to pause during the globally configured work hours.
Note: To perform link-migration to Swarm targets, the destination should use the s3generic scheme, see §5.8.

4.10 Create Recovery File From Source Operation

Requires: Source(s), Rule(s) Included in Community Edition: no
Generate a disaster recovery file for DataCore FileFly DrTool by analyzing files at the selected Source(s). FileFly DrTool can use the generated file(s) to recover or update source files.
Note: Recovery files generated from Source account for renames.

4.11 Create Recovery File From Destination Operation

Requires: Destination Included in Community Edition: no
Generate a disaster recovery file for DataCore FileFly DrTool by reading the index and analyzing files at the selected Destination without reference to the associated primary storage files.
Note: Recovery files from Destination may not account for renames.
Important: It is strongly recommended to use 'Create Recovery File From Source' in preference where possible.

4.12 Erase Cached Data Operation

Requires: Source(s), Rule(s) Included in Community Edition: yes
Erases cached data associated with files by the Partial Demigrate feature (NetApp Sources only).
Important: The Erase Cached Data operation is not enabled by default. It must be enabled in 'Settings' → 'Additional Options'.

5 Source and Destination Reference

The following pages describe the characteristics of the Sources and Destinations supported by DataCore FileFly. Planning, setup, usage, and maintenance considerations are outlined for each storage platform.
IMPORTANT: Read any relevant sections of this chapter prior to deploying FileFly in a production environment.

5.1 Microsoft Windows

5.1.1 Migration Support

Windows NTFS volumes may be used as migration sources. On Windows Server 2016 and above, ReFS volumes are also supported as migration sources.
Windows stub files can be identified by the 'O' (Offline) attribute in Explorer. Depending on the version of Windows, files with this flag may be displayed with an overlay icon.
Note: If it is not possible to install the DataCore FileFly Agent directly on the file server, see §5.2 for an alternative solution using Link-Migration.

5.1.2 Planning

5.1.2.1 Prerequisites

• A license that includes an appropriate entitlement for Windows

When creating a production deployment plan, please refer to §3.5.

5.1.2.2 Cluster Support

Clustered volumes managed by Windows failover clusters are supported. However, the Cluster Shared Volume (CSVFS) feature is NOT supported. On Windows Server 2012 and above, when configuring a 'File Server' role in the Failover Cluster Manager, 'File Server for general use' is the only supported File Server Type. The 'Scale-Out File Server for application data' File Server Type is NOT supported.
When using clustered volumes in FileFly URIs, verify that the resource FQDN appropriate to the volume is specified rather than the FQDN of any individual node.

5.1.3 Setup

5.1.3.1 Installation

See Installing FileFly Agent for Windows §2.2.2

5.1.4 Interoperability

This section describes Windows-specific considerations only and should be read in conjunction with §3.5.

5.1.4.1 Microsoft Storage Replica

FileFly supports Microsoft Storage Replica.
If Storage Replica is configured for asynchronous replication, a disaster failover effectively reverts the volume to a previous point in time. This kind of failover is directly equivalent to a volume restore operation (albeit to a very recent state).
As with any restore, a Post-Restore Revalidate Policy (see §4.5) should be run across the restored volume within the scrub grace period window. This verifies the correct operation of any future scrub policies by accounting for discrepancies between the demigration state of the files on the (failed) replication source volume and the replication destination volume.
Important: integrate this process into your recovery procedures prior to the production deployment of asynchronous storage replication.

5.1.4.2 Microsoft DFS Namespaces (DFSN)

DFSN is supported. FileFly Sources must be configured to access volumes on individual servers directly rather than through a DFS namespace. Users and applications may continue to access files and stubs using DFS namespaces as normal.

5.1.4.3 Microsoft DFS Replication (DFSR)

DFSR is supported for:

• Windows Server 2019

• Windows Server 2016

• Windows Server 2012 R2

FileFly Agents must be installed (selecting the migration role during installation) on EACH member server of a DFS Replication Group prior to running migration tasks on any of the group's Replication Folders.
If adding a new member server to an existing Replication Group where FileFly is already in use, FileFly Agent must be installed on the new server first.
When running policies on a Replicated Folder, sources should be defined such that each policy acts upon only one replica. DFSR replicates the changes to the other members as usual.
Read-only (one-way) replicated folders are NOT supported. However, read-only SMB shares can be used to prevent users from writing to a particular replica as an alternative.
Due to the way DFSR is implemented, care should be taken to avoid writing to stub files that are being concurrently accessed from another replica.
In the rare event that DFSR-replicated data is restored to a member from backup, verify DFSR services on all members are running and replication is fully up-to-date (check for the DFSR 'finished initial replication' Windows Event Log message), then run a Post-Restore Revalidate Policy using the same source used for migration.

5.1.4.4 Retiring a DFSR Replica

Retiring a replica effectively creates two independent copies of each stub, without updating secondary storage. To avoid any potential loss of data:

1. Delete the contents of the retired replica (preferably by formatting the disk, or at least disable Stub Deletion Monitoring during the deletion)

2. Run a Post-Restore Revalidate Policy on the remaining copy of the data

If it is strictly necessary to keep both, now independent, copies of the data and stubs, then run a Post-Restore Revalidate Policy on both copies separately (not concurrently).

5.1.4.5 Preseeding a DFSR Replicated Folder Using Robocopy

The most common use of Robocopy with FileFly stubs is to preseed or stage initial synchronization. When performing such a preseeding operation:

• for new Replicated Folders, verify the 'Primary member' is set to be the original server, not the preseeded copy

• both servers must have FileFly Agent installed before preseeding

• add a "Process Exclusion" to Windows Defender for robocopy.exe (allow a while for the setting to take effect)

• on the source server, preseed by running robocopy with the /b flag (to copy stubs as-is to the new server)

• once preseeding is complete and replication is fully up-to-date (check for the DFSR 'finished initial replication' Windows Event Log message), it is recommended to run a Post-Restore Revalidate Policy on the original FileFly Source

Note: If the process above is aborted, be sure to delete all preseeded files and stubs (preferably by formatting the disk, or at least disable Stub Deletion Monitoring during the deletion) and then run a Post-Restore Revalidate Policy on the original FileFly Source.

5.1.4.6 Robocopy (Other Uses)

Robocopy demigrates stubs as they are copied by default. This is the same behavior as Explorer copy-paste, xcopy, etc.
Robocopy with the /b flag (backup mode – must be performed as an administrator) copies stubs as-is.
Robocopy /b is not recommended. If stubs are copied in this fashion, the following must be considered:

• for a copy from one server to another, both servers must have DataCore FileFly Agent installed

• this operation is essentially a backup and restore in one step, and thus inappropriately duplicates stubs that are intended to be unique

  • after the duplication, one copy of the stubs should be deleted immediately

  • run a Post-Restore Revalidate policy on the remaining copy

  • this process renders the corresponding secondary storage files non-scrubbable, even after they are demigrated

• to prevent Windows Defender triggering demigrations when the stubs are accessed in this fashion:

  • always run the robocopy from the source end (the file server with the stubs)

  • add a "Process Exclusion" to Windows Defender for robocopy.exe (allow a while for the setting to take effect)

5.1.4.7 Windows Data Deduplication

If a Windows source server is configured to use migration policies and Windows Data Deduplication, it should be noted that a given file can either be deduplicated or migrated, but not both at the same time. FileFly migration policies automatically skip files already deduplicated. Windows skips FileFly stubs when deduplicating.
When using both technologies, it is recommended to configure Data Deduplication and Migration based on file type such that the most efficacious strategy is chosen for each type of file.
Note: Microsoft's legacy Single Instance Storage (SIS) feature is not supported. Do not use SIS on the same server as DataCore FileFly Agent.

5.1.4.8 Windows Shadow Copy

Windows Shadow Copy – also known as Volume Snapshot Service (VSS) – allows previous versions of files to be restored, e.g. from Windows Explorer. This mechanism cannot be used to restore a stub. Restore stubs from backup instead – see §3.4.

5.1.5 Behavioral Notes

5.1.5.1 Symbolic Links

Symbolic links (symlinks) are skipped during traversal of the file system. This guarantees files are not seen – and thus acted upon – multiple times during a single execution of a given policy. If it is intended that a policy should apply to files within a directory referred to by a symbolic link, either verify the Source encompasses the real location at the link's destination, or specify the link itself as the Source.

5.1.5.2 Mount-DiskImage

On Windows 8 or above, VHD and ISO images may be mounted as normal drives using the PowerShell Mount-DiskImage cmdlet. This functionality can also be accessed using the Explorer context menu for an image file.
A known limitation of this cmdlet is that it does not permit sparse files to be mounted (see Microsoft KB2993573). Since migrated image files are always sparse, they must be demigrated prior to mounting. This can be achieved either by copying the file or by removing the sparse flag with the following command:
fsutil sparse setflag <file_name> 0

5.1.6 Stub Deletion Monitoring

On Windows, the FileFly Agent can monitor stub deletions to identify secondary storage files that are no longer referenced in order to maximize the usefulness of Scrub Policies. This feature extends not only to stubs that are directly deleted by the user, but also to other cases of stub file destruction such as overwriting a stub or renaming a different file over the top of a stub.
Stub Deletion Monitoring is disabled by default. To enable it, please refer to Appendix E.

5.2 Microsoft Windows using FileFly LinkConnect Server

5.2.1 Link-Migration Support

This section details the configuration of a DataCore FileFly LinkConnect Server to enable Link-Migration of files from Windows Server SMB shares. This option should be used when it is not possible to install DataCore FileFly Agent directly on the Windows file server in question. For other cases – where FileFly Agent can be installed on the server – please refer to 5.1.
Refer to §4.2 and §4.9 for details of the Migrate and Link-Migrate operations respectively.
Link-Migration works by pairing a Windows SMB share with a corresponding LinkConnect Cache Share. Typically a top-level share on each Windows file server volume is mapped to a unique share (or subdivision) on a FileFly LinkConnect Server. Multiple file server shares may use Cache Shares / subdivisions on the same FileFly LinkConnect Server if desired.
Once this configuration is completed, Link-Migrate policies convert files on the source Windows Server SMB share to links pointing to the destination files using the LinkConnect Cache Share, according to configured rules.
Link-Migrated files can be identified by the 'O' (Offline) attribute in Explorer. Depending on the version of Windows, files with this flag may be displayed with an overlay icon.

5.2.2 Planning

5.2.2.1 Prerequisites

• An NTFS Cache Volume of at least 1TB – see §2.2.4

• A FileFly license that includes an entitlement for FileFly LinkConnect Server.

• A supported secondary storage destination (excluding scsp and scspdirect)

When creating a production deployment plan, please refer to §3.5.

5.2.2.2 File Server System Requirements

• Windows Server 2016 or higher

• The server must NOT have the Active Directory Domain Services role

5.2.2.3 Client Requirements

Windows clients require a supported 64-bit Windows operating system:

• Windows 10

• Windows Server 2019

• Windows Server 2016

• Windows Server 2012 R2

In order to access link-migrated files, the LinkConnect Client Driver must be installed on each client machine – see §2.3.

5.2.2.4 Network

Place the DataCore FileFly LinkConnect Server on the same subnet and same switch as the corresponding Windows file server(s) to minimize latency.
Additionally, the FileFly LinkConnect Server must be joined to the same domain as the Windows file server and the Windows client machines.

5.2.2.5 Antivirus Considerations

Verify Windows Defender or any other antivirus product installed on the FileFly LinkConnect Server is configured to omit scanning/screening on the LinkConnect Cache Volume and any Windows file server SMB shares.

5.2.2.6 High-Availability for FileFly LinkConnect Server

Consider whether High-Availability (HA) is required in your environment (either now or in the future). If so, LinkConnect Servers must be installed in a DFSN configuration from the outset.
LinkConnect Cache Shares are configured for HA by exposing the share name at the domain level using DFSN. If not using HA, it is possible to use either a simple share on a standalone server, or a share exposed at the domain level using DFSN. The latter is always recommended to allow transition to an HA configuration in the future.

5.2.2.7 Regular Maintenance Activity

Each configured MigLink source is periodically scanned to perform maintenance tasks such as MigLink ACL propagation and Link Deletion Monitoring (see §5.2.2.8).
In an HA configuration, this scanning activity is performed by a single caretaker node, as can be seen on the Admin Portal Servers page. A standalone FileFly LinkConnect Server always performs the caretaker role.

5.2.2.8 Link Deletion Monitoring

Link Deletion Monitoring (LDM) identifies secondary storage files that are no longer referenced in order to facilitate the recovery of storage space by Scrub Policies. This feature extends not only to MigLinks that are demigrated or directly deleted by the user, but also to other cases such as overwriting a MigLink or renaming a different file over the top of a MigLink.
Unlike SDM, LDM requires a number of maintenance scans to determine that a given secondary storage file is no longer referenced. Interrupting the maintenance process (e.g. by restarting the caretaker node or transitioning the caretaker role) delays the detection of unreferenced secondary storage. For optimal and timely storage space recovery, verify LinkConnect Servers can run uninterrupted for extended periods.
Warning: in order to avoid LDM incorrectly identifying files as deleted – leading to unwanted data loss during Scrub – it is critical to verify users cannot move/rename MigLinks out of the scanned portion of the directory tree within the filesystem. This can be achieved by always creating the share used for your 'miglinkSource' at the root of the filesystem. An additional share may be created solely for this purpose.
To utilize LDM, it must first be enabled on a per-share basis.

5.2.3 Setup

5.2.3.1 Create a LinkConnect User

Provision a user on the Windows domain for the exclusive use of your LinkConnect service(s). This user does not need to be a member of Domain Admins.

5.2.3.2 Configure Windows File Server

On the file server:

1. Add the LinkConnect User to the the local Administrators group

2. Add 'Full Control' permissions for this user to each share

   • be sure to configure the share, not the folder permissions

5.2.3.3 Installation

On each FileFly LinkConnect Server machine:

1. Add the user created above to the local 'Administrators' group

2. Assign the 'Log on as a service' privilege to this user

3. Run the DataCore FileFly LinkConnect Server.exe

4. Follow the prompts to complete the installation

5. Follow the instructions to activate the installation

   • the Servers page report the server is unconfigured

5.2.3.4 Cache Share Creation

On your cache volume (e.g. X:), navigate to X:\1bf8ce99-8c8a-4092-9c98-2b9c850c57a1\shares.
To create each Cache Share:

• Create a new folder with the desired share name

• Right click → Properties → Sharing → Advanced Sharing…

• Tick 'Share this folder'

• Share name must match the folder name exactly (including case)

• Permissions:

  • Everyone: Allow 'Read' only

  • No other permissions

5.2.3.5 Service Configuration

On the Admin Portal 'Servers' page, edit the configuration of the FileFly LinkConnect Server. In the 'Manual Overrides' panel, add the following options:

where ALIAS_FQDN is either the FQDN of the FileFly LinkConnect Server (standalone mode), or of the DFSN domain (standalone or high-availability).
For each share mapping, add:

where:

• miglinkSourceType must be set to exactly win

• MAPPING_NUMBER starts at 0 for the first share mapping in this file – mappings must be numbered consecutively

• WIN_FQDN/WIN_SHARE describes the file server share to be mapped

• CACHE_SHARE is a LinkConnect Cache Share name (created above

  • this value is CASE-SENSITIVE

• SUBDIV must be the single decimal digit 1

• SECRET_KEY is at least 40 ASCII characters – this key protects against counterfeit link creation