1. Overview

1.1 Introduction

DataCore FileFly® is a heterogeneous Data Management System. It automates and manages the tiering and movement of data between file systems, object stores, and cloud storage services. Use cases include storage cost optimization, backup optimization and workload placement.
In a tiering scenario, files are migrated from primary storage locations to secondary storage locations. Files are demigrated transparently when accessed by a user or application. FileFly® also provides a range of Disaster Recovery options.

1.2 System Components

Figure 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.

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.

DataCore FileFly Agent

DataCore FileFly Agent performs file operations as directed by Admin Portal Policies. The FileFly Agent is also responsible for retrieving tiered 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.

Open

Figure 1.1: FileFly® System Overview

When installed in a Gateway configuration, DataCore FileFly Agent does not allow tiering of files from that server, instead, the FileFly Agent provides access to third-party protocols and devices. Device specific configuration details (such as sensitive encryption keys and authentication details) are isolated from the file servers.
Optionally, Gateways can be configured for High-Availability (HA).

DataCore FileFly FPolicy Server

FileFly FPolicy Server provides tiering support for NetApp filers via 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).

DataCore FileFly LinkConnect Server

FileFly LinkConnect Server provides link-based tiering 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).

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.3 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.
Upon logging in to the FileFly Admin Portal, the ‘Dashboard’ will be displayed – we will come back to the dashboard in §1.4. For now, the remainder of this section will follow the Admin Portal’s navigation menu.

1.3.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. You will 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.3.2 Sources

Sources describe volumes or folders to which Policies may be applied (i.e., locations from which data may be transferred).
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.

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 will not be traversed.
On the Source Details page, the directory tree may be expanded and explored in the ‘Subdirectory Filtering’ section. By default, the entire source will be included.

1.3.3 Destinations

Destinations are storage locations that Policies may write files to. Platform-specific information for all supported destinations is detailed in Chapter 5.
Optionally, a Destination may be configured to use Write Once Read Many (WORM) semantics for migration operations. This option is useful when the underlying storage device has WORM-like behavior, but is exposed using a generic protocol.

1.3.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 §A.1 (p.66))

• regular expressions, e.g. /2004-06-[0-9][0-9]n.log/ (see §A.2 (p.67))

Note that:

• files match if any one of the patterns in the list match version 4.8 4

• whitespace before and after each pattern is ignored

• patterns are case-insensitive by default (see §A.3 (p.67))

• 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.3.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.3.6 Tasks

A Task selects one or more Policies for execution.
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 Appendix E for more details.

Launching Tasks

While Tasks may be launched manually, it is often more desirable to enable a Task’s schedule with a specific start time and optional repeat configuration.
If multiple Tasks are scheduled to launch simultaneously, Policies on each Source are grouped such that only a single traversal of each file system is required.

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.3.7 Browser

The built-in Browser enables examination of a variety of source / destination locations. Features include:

• Metadata display and sorting

• Optional filtering based on filename pattern or Rules

• Download, upload, and deletion of files

1.3.8 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 tiering strategy

• a breakdown of the most common file types

• optionally, a breakdown of file ownership

Secure links to reports may be shared with other members of your organization without the need to grant these users Admin Portal login access. Either share individual reports or share all reports generated by a Policy on an ongoing basis. To limit access to reports by IP address / subnet, refer to §C.2 (p.70).

1.3.9 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.3.10 Settings

The Admin Portal ‘Settings’ page allows configuration of a wide range of global settings including:

• email notification

• configuration backup (see §3.3 (p.15))

• security roles (see §C.2 (p.70))

• work hours

• Admin Portal logging

Additionally, it is possible to:

• view and update the product license

• suspend the scheduler to prevent scheduled Tasks launching while maintenance procedures are being performed

• update the TLS certificate for the Admin Portal web interface

Server-specific settings and plugin configuration are available via the ‘Servers’ page.

1.3.11 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.4 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 via the ‘Launch Task. . . ’ control.
The ‘Notices’ panel summarizes system issues that need to be addressed by the administrator. For instance, 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.4.1 Storage Charts

‘Primary’ and ‘Secondary’ storage charts may be read together to gain insight into the impact of currently configured tiering 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.

For instance, a Migration Policy consumes secondary storage in order to release primary storage.

By contrast, demigration consumes primary storage immediately, but defers release until later. Specifically, 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.4.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 via the ‘Servers’ page – see §1.3.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.4.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 launch 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 (p.19) instead.

For further information about each supported storage platform, refer to Chapter 5.

2.1 Installing DataCore 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.

System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2022

  • Windows Server 2019

  • Windows Server 2016

• Minimum 12GB RAM

• Minimum 10GB disk space for log files

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

Setup

1. Run DataCore FileFly Tools.exe

2. Follow the instructions on screen

2.1.1 Initial Configuration

After completing the installation process, FileFly Tools must be configured via the Admin Portal web interface. The FileFly Admin Portal will be opened automatically and can be found later via the Start Menu.

The web interface will lead you through the process of initial configuration: refer to the ‘Notices’ panel on the ‘Dashboard’ to ensure that all steps are completed.
Consider configuring additional users or IP restrictions – see §C.2 (p.70).

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 (tiering). It is essential for the agent to be installed on all machines from which files will be migrated.

By contrast, 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 Gateway’.

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

System Requirements

• Supported Windows Server operating system:

  • Windows Server 2022

  • Windows Server 2019

  • Windows Server 2016

  • Minimum 8GB RAM

  • Minimum 2GB disk space for log files

  • Active clock synchronization (e.g. via 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.

Setup

1. Run the DataCore FileFly Agent.exe

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

2.2.3 DataCore FileFly Gateway for Linux

System Requirements

• A dedicated x86 64 server with a supported operating system:

  • Red Hat Enterprise Linux (RHEL) 9

  • Ubuntu Server 22.04 LTS

• Minimum 8GB RAM

• Minimum 2GB disk space for log files

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

Setup – RHEL

In a root terminal:

1. tar xzf DataCore FileFly Gateway Agent rhel9 4 8.tgz

2. DataCore FileFly Gateway Agent rhel9 4 8/install.sh

3. Follow the instructions to activate the agent via FileFly Admin Portal

Setup – Ubuntu

In a root terminal:

1. tar xzf DataCore FileFly Gateway Agent ubuntu22 4 8.tgz

2. DataCore FileFly Gateway Agent ubuntu22 4 8/install.sh

3. Follow the instructions to activate the agent via FileFly Admin Portal

2.2.4 DataCore FileFly FPolicy Server for NetApp Filers

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

System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2022

  • Windows Server 2019

  • Windows Server 2016

• Minimum 8GB RAM

• Minimum 2GB disk space for log files

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

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.5 DataCore FileFly LinkConnect Server

A DataCore FileFly LinkConnect Server provides link-based tiering 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.

System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2022

  • 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. via NTP)

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 (p.42) for OneFS and §5.2 (p.31) for Windows file servers. Other devices are not supported.

2.3 LinkConnect Client Deployment

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. Ensure 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.

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, 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 doing so will cause the client driver to stop functioning.

Client Driver Removal

In the unlikely event that the LinkConnect client driver must be removed, please complete the following steps:

1. Open an Administrator command prompt

2. sc delete mwilcflt

3. fsutil behavior set symlinkEvaluation R2R:

4. Reboot

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. It is therefore advisable to take steps to ensure that 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 Analyze 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

4. Launch the Task

5. When the Task has finished, view the report(s) on the ‘Reports’ page

3.2.2 Configure Tiering

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 will indicate the amount of data that will be 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 secondary tier 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. Launch the task

When the task has 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 will help you 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 will preserve policy configuration and server registrations as well as per-server settings and storage plugin configuration.

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, credentials etc.

• 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\

Restore Process

1. Ensure that the server to be restored to has the same FQDN and IP address 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\

Note: Restore from any backup (or virtual machine snapshot) that is more than 6 months old may fail due to certificate expiry. Contact DataCore Support for assistance if this occurs.

3.3.2 Per-Server Logs

Backing up the configuration on each server is not necessary since such configuration is already included in the above FileFly Tools backup process. You may optionally backup server logs from the logs location on each server – by default these are located at:

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

• Linux: /var/opt/datacore/filefly-agent/log

Note: Do not attempt to restore logs back into an active installation, since this will
interfere with log rotation.

3.4 Storage Backup

Each stub on a primary storage tier is associated with a corresponding MWI file on a secondary storage tier. During the normal process of migration and demigration the relationship between stub and MWI file is maintained.

The recommendations below ensure that the consistency of this relationship is maintained even after files are restored from backup.

3.4.1 Backup Planning

Ensure that the restoration of stubs is included as part of your backup & restore test regimen.

When using Scrub policies, ensure 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 below).

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 the Admin Portal ‘Settings’ page.

Important: It will NOT be possible to safely restore stubs or MigLinks from a backup set taken more than one grace period ago.

Additional Planning

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

3.4.2 Restore Process

1. Click ‘Settings’ → ‘Scheduler’ → ‘Suspend scheduler’

2. Restore the primary volume

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

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

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

4. Click ‘Settings’ → ‘Scheduler’ → ‘Start scheduler’

If restoring the primary volume to a different server (a server with a different FQDN), the following preparatory steps will also be 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

Windows
Enterprise Windows backup software should 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.

NetApp Filers

Please consult §5.3.5 (p.38) regarding snapshot restore on NetApp Filers.

3.5 Production Readiness Checklist

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 (p.25)

Antivirus

Generally, antivirus software will not cause demigrations during normal file access. However, some antivirus software will demigrate files when performing scheduled file system scans.

Prior to production deployment, always check that installed antivirus software does not cause unwanted demigrations. Some software may need to 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 will change on upgrade).

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).

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

Platform Considerations

For further information on platform-specific interoperability considerations, please refer to the appropriates 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.3.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.

FileFly Agent for Windows

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

2. Resolve any warnings displayed on the ‘Dashboard’

FileFly Gateway for Linux (RHEL)

In a root terminal:

1. tar xzf DataCore FileFly Gateway Agent rhel9 4 8.tgz

2. DataCore FileFly Gateway Agent rhel9 4 8/install.sh

3. Resolve any warnings displayed on the ‘Dashboard’

FileFly Gateway for Linux (Ubuntu)

In a root terminal:

1. tar xzf DataCore FileFly Gateway Agent ubuntu22 4 8.tgz

2. DataCore FileFly Gateway Agent ubuntu22 4 8/install.sh

3. Resolve any warnings displayed on the ‘Dashboard’

FileFly NetApp FPolicy Server

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

2. Resolve any warnings displayed on the ‘Dashboard’

FileFly LinkConnect Server

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