1 Introduction

1.1 What is Caringo FileFly?

Caringo FileFly is a heterogeneous Data Management System. It automates and manages the movement of data from primary storage locations to Caringo Swarm or CloudScaler object storage.
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 will remain 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 will be 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

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

1.3.0.1 Caringo 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, policy simulation, server monitoring, and file reporting. It lies outside the data path for file transfers.

1.3.0.2 Caringo FileFly Agent

Caringo FileFly Agent performs file operations as directed by Admin Portal Policies. 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 Caringo FileFly FPolicy Server

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

1.3.0.4 Caringo FileFly DrTool

Caringo FileFly DrTool is an additional application that assists in Disaster Recovery scenarios.

2 Deployment

This chapter will cover:

• Installing Caringo FileFly Tools

• Installing Caringo FileFly Agent on file servers

• Installing Caringo FileFly Gateways as required

• Getting started with FileFly policies

• Production readiness

Refer to these instructions during initial deployment and when adding new components. For upgrade instructions, please refer to Chapter 8 instead.

For further details and usage instructions for each platform, refer to Chapter 4.

2.1 DNS Best Practice

In a production deployment, Fully Qualified Domain Names (FQDNs) should always be used in preference to bare IP addresses.

Storage locations in Caringo 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.

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.

2.2 Installing FileFly Tools

The Caringo FileFly Tools package consists of the FileFly Admin Portal and the FileFly DrTool application. The FileFly Admin Portal provides central management of policy execution while the FileFly DrTool is used in disaster recovery situations.

FileFly Tools must be installed before any other components.

2.2.1 System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2016

  • Windows Server 2012 R2 (Apr 2014 update rollup)

  • Windows Server 2012

  • Windows Server 2008 R2 SP1

• Minimum 4GB RAM

• Minimum 2GB disk space for log files

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

Internet Explorer 11 or higher (possibly on a separate workstation) will be required to access the FileFly Admin Portal web interface.

2.2.2 Setup

1. Run Caringo FileFly Tools.exe

2. Follow the instructions on screen

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 interface will lead you through the process for installing your license.

For production licensed installations, a 'Backup & Scrub Grace Period' setup page will be displayed. Please read the text carefully and set the minimum grace period as appropriate and after consulting with your backup plan – see also §7.2. This value may be revised later via the 'Settings' page.

2.3 Installing FileFly Agents

Once FileFly Tools installation is complete, proceed to install Caringo FileFly Agents as described below. FileFly Agents perform file operations as directed by Admin Portal Policies. Also, in the case of user/application initiated demigration, agents retrieve the file data from secondary storage autonomously.

2.3.1 FileFly Agent Server Roles

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 Gateway role, the agent provides access to CloudScaler and Swarm destinations.

2.3.2 High-Availability Gateway Configuration

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

2.3.2.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 a single alias that maps to each of the IP addresses

3. Use this alias in FileFly destination URIs, never individual nodes

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.
For further DNS recommendations, refer to §2.1.

2.3.3 Installing Caringo FileFly Agent for Windows Servers

2.3.3.1 System Requirements

• Supported Windows Server operating system:

  • Windows Server 2016

  • Windows Server 2012 R2 (Apr 2014 update rollup)

  • Windows Server 2012

  • Windows Server 2008 R2 SP1

• Minimum 4GB 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.

2.3.3.2 Setup

1. Run the Caringo FileFly Agent.exe

2. Select install location

3. Select migration or Gateway role as appropriate, refer to §2.3.1

4. If installing a FileFly Gateway, select the desired plugins

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

2.3.3.3 Activation

• If no clustering is required, activate as a 'Standalone Server'

• If installing the FileFly Gateway for High-Availability, activate as a High-Availability FileFly Gateway

• If the server is part of a Windows failover cluster, and this clustered resource is to be used as a FileFly Source, activate as a Windows failover cluster node

For further information see §5.3.1.
Important: If any type of clustering is used, ensure that FileFly Agent for Windows is installed on ALL cluster nodes.

2.3.4 Installing Caringo FileFly FPolicy Server for NetApp Filers

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

2.3.4.1 System Requirements

• A dedicated server with a supported operating system:

  • Windows Server 2016

  • Windows Server 2012 R2 (Apr 2014 update rollup)

  • Windows Server 2012

  • Windows Server 2008 R2 SP1

• Minimum 4GB RAM

• Minimum 2GB disk space for log files

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

2.3.4.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 §4.2.
Note: Legacy 7-Mode Filers require a different procedure at FileFly FPolicy Server installation time – see §4.3.

2.4 Installing Config Tools

In addition to the components described above, it may also be necessary to install one or more Config Tools. Full details are provided where required for each storage platform in Chapter 4.

2.5 Getting Started

2.5.1 Analyzing Volumes

Once the software has been installed, the first step in any new Caringo 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 (see Chapter 5 for full documentation):

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. On the 'Overview' tab, click Quick Run

5. Click on the Task's name to run it immediately

6. When the Task has finished, expand the details by clicking on the Task name under 'Recent Task History'

7. Click Go to Task to navigate to the 'Task Details' page

8. Access the report by clicking on View Last Stats

Pay particular attention to the 'Last Modified % by size' graph. This graph will help identify how much data would be affected by a migration policy based on the age of files.

Examine 'File types by size' to see if the data profile matches the expected usage of the volume.

2.5.2 Preparing for Migration

Using the information from the reports, create tasks to migrate files:

1. Prepare a destination for migrated files – see Chapter 4

2. Create a Destination in FileFly Admin Portal

3. Create a Rule and a Migration Policy

   • A typical rule might limit migrations to files modified more than six months ago – do not use an 'all files' rule

   • To avoid unnecessary migration of active files, be conservative with your first Migration Policy

4. Create a Task for the new Policy

   • For now, disable the schedule

5. Save the task, then click on its name to open the 'Task Details' page

6. Click Simulate Now to run a Task simulation

7. Examine the resultant reports (view the Task and click View Last Stats)

If the results of simulation differ from expectations, it may be necessary to modify the rules and re-run the simulation.
Note: The simulation reports created above show details of the subset of files matched by the rules in the policies only.
Note: Reports are generated for simulations only – a real Task run will log each file operation, but will not generate a statistics report.

2.5.3 Running and Scheduling Migration

Use Quick Run on the 'Overview' tab to run the migration Task immediately.

Migration is typically performed periodically: configure a schedule on the migration Task's details page.

2.5.4 Next Steps

Chapter 3 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.

2.6 Production Readiness Checklist

2.6.0.1 Backup

Refer to Chapter 6 for details of how to backup FileFly configuration.

Next, be sure to test that your backup and restore software respects stubs appropriately. Specifically:

1. Review the backup and restore procedures described in Chapter 7

2. Check backup software can backup stubs without triggering demigration

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

As an additional measure to increase the range of available restore options, schedule regular 'Create DrTool File From Source' Policies on your migration sources.

2.6.0.2 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 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, Caringo FileFly Agent may be configured to deny demigration rights to the antivirus software. Refer to §13.5 for more information.

It may be necessary for some antivirus products to exempt the Caringo FileFly Agent process from real-time protection (scan-on-access). For example, using Microsoft Security Essentials (MSE), it is necessary to add e.g. C:\Program Files\Caringo FileFly\FileFly Agent\<version>\mwi_clmb.exe to the 'Excluded Processes' list. Be sure to update the exclusion whenever FileFly is upgraded.

2.6.0.3 Other System-wide Applications

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

2.6.0.4 Monitoring and Notification

To facilitate proactive monitoring, it is recommended to configure one or both of the following mechanisms:

1. Configure email notifications to monitor system health and Task activity – see §5.10

2. Enable syslog on agents – see §13.1

2.6.0.5 Platform Considerations

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

2.7 Policy Tuning

Periodically re-assess file distribution and access behavior:

1. Run 'Gather Statistics' Policies

   • Examine reports

2. Examine Server statistics – see §5.3

   • 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 Policy Operations

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

User interface operation is further detailed in Chapter 5.

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

Statistics reports can be retrieved from FileFly Admin Portal – see §5.8.6.

3.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 will be 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 will not be migrated.

Each Migrate operation will be 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 via 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 skipped. 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.

3.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 skipped. 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.

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

Important: Source(s) MUST be backed up within the grace period.

3.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 §7.2.

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

3.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 will no longer be 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

It is recommended that this operation be used only after consultation with a Caringo engineer. Prior to running an Advanced Demigrate policy, be sure that there is sufficient primary storage available to accommodate the demigrated data.

3.8 Simple 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 will not be converted to stubs until a Migrate or Quick-Remigrate Policy is run. Files containing no data will not be 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 will be skipped when encountered during a premigrate policy.

This policy may also be configured to pause during the globally configured work hours.

Note: Most deployments will not use this operation, but will use a combination of Migrate and Quick-Remigrate instead.

3.9 Create DrTool File From Source Operation

Requires: Source(s), Rule(s) Included in Community Edition: no

Generate a disaster recovery file for Caringo 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: DrTool files generated from Source will account for renames.

DrTool files can be retrieved from FileFly Admin Portal – see §5.8.7.

3.10 Create DrTool File From Destination Operation

Requires: Destination Included in Community Edition: no

Generate a disaster recovery file for Caringo FileFly DrTool by reading the index and analyzing files at the selected Destination without reference to the associated primary storage files.

Note: DrTool files from Destination may not account for renames.

Important: It is strongly recommended to use 'Create DrTool File From Source' in preference where possible.

3.11 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 the advanced section on the Admin Portal 'Settings' page.

4 Sources and Destinations

The following pages describe the characteristics of the Sources and Destinations supported by Caringo 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.

4.1 Microsoft Windows

4.1.1 Migration Support

Windows NTFS volumes may be used as migration sources. On Windows Server 2016, ReFS volumes are 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.

4.1.2 Planning

4.1.2.1 Prerequisites

• A license that includes an appropriate entitlement for Windows

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

4.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, ensure that the resource FQDN appropriate to the volume is specified rather than the FQDN of any individual node.

4.1.3 Setup

4.1.3.1 Installation

See Installing FileFly Agent for Windows §2.3.3

4.1.4 Usage

4.1.4.1 URI Format

win://{servername}/{drive letter}/[{path}]
Where:

• servername – Server FQDN or Windows Failover File Server Resource FQDN

• drive letter – Windows volume drive letter

Examples:
win://fs1.example.com/d/projects win://fs2.example.com/e/
Note: Share names and mapped drives are not supported.

4.1.5 Interoperability

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

4.1.5.1 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 via DFS namespaces as normal.

4.1.5.2 Microsoft DFS Replication (DFSR)

DFSR is supported for:

• Windows Server 2016

• Windows Server 2012 R2

• Windows Server 2008 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 will replicate 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, ensure that DFSR services on all members are running and that 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.

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

4.1.5.4 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, ensure that 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.

4.1.5.5 Robocopy (Other Uses)

Robocopy will, by default, demigrate stubs as they are copied. This is the same behavior as Explorer copy-paste, xcopy, etc.

Robocopy with the /b flag (backup mode – must be performed as an administrator) will copy 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 Caringo 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 will render the corresponding secondary storage files un-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)

4.1.5.6 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 will automatically skip files that are 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 Caringo FileFly Agent.

4.1.5.7 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 Chapter 7.

4.1.6 Behavioral Notes

4.1.6.1 Junction Points & Symlinks

With the exception of volume mount points, junction points will be skipped during traversal of the file system. Symlinks are also skipped. This ensures that 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 junction point, either ensure that the Source encompasses the real location at the junction point's destination, or specify the junction point itself as the Source.

4.1.6.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 via 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

4.1.7 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 §13.2.

4.2 NetApp Filer (Cluster-mode)

This section describes support for 'Cluster-mode' NetApp Filers. For '7-mode' Filers (that is, 7.x Filers and 8.x Filers operating in '7-mode'), see §4.3.

4.2.1 Migration Support

Migration support for sources on NetApp Vservers (Storage Virtual Machines) is provided via NetApp FPolicy. This requires the use of a Caringo FileFly FPolicy Server. Client demigrations can be triggered via SMB or NFS client access.

Please note that NetApp Filers currently support FPolicy for Vservers with FlexVol volumes but not Infinite volumes.

When accessed via SMB on a Windows client, NetApp stub files can be identified by the 'O' (Offline) attribute in Explorer. Files with this flag may be displayed with an overlay icon. The icon may vary depending on the version of Windows on the client workstation.

4.2.2 Planning

4.2.2.1 Prerequisites

• NetApp Filer(s) must be licensed for the particular protocol(s) to be used (FPolicy requires a CIFS license)

• A FileFly license that includes an entitlement for FileFly NetApp FPolicy Server

Caringo FileFly FPolicy Servers require EXCLUSIVE use of SMB connections to their associated NetApp Vservers. This means Explorer windows must not be opened, drives must not be mapped, nor should any UNC paths to the filer be accessed from the FileFly FPolicy Server machine. Failure to observe this restriction will result in unpredictable FPolicy disconnections and interrupted service.
When creating a production deployment plan, please refer to §2.6.

4.2.2.2 Filer System Requirements

Caringo FileFly FPolicy Server requires that the Filer is running: