version 4.0 | document revision 1
...
A Task schedules one or more Policies for execution. Tasks can be scheduled to run at specific times, or can be run on-demand via 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.
...
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.
...
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. Similarly, Windows will skip 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.
...
| Anchor | ||||
|---|---|---|---|---|
|
Similarly to the Stub Deletion Monitoring feature provided by DataCore FileFly Agents on Windows, Link Deletion Monitoring (LDM) identifies secondary storage files that are no longer referenced in order to facilitate 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. It should be noted that interrupting the maintenance process (e.g. by restarting the caretaker node or transitioning the caretaker role) will delay the detection of unreferenced secondary storage. For optimal and timely storage space recovery, ensure that 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 ensure that 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.
...
| Anchor | ||||
|---|---|---|---|---|
|
Similarly to the Stub Deletion Monitoring feature provided by DataCore FileFly Agents on Windows, Link Deletion Monitoring (LDM) identifies secondary storage files that are no longer referenced in order to facilitate 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. It should be noted that interrupting the maintenance process (e.g. by restarting the caretaker node or transitioning the caretaker role) will delay the detection of unreferenced secondary storage. For optimal and timely storage space recovery, ensure that 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 ensure that 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.
...