Open topic with navigation
Storage Location Best Practices
To monitor the cost savings from migrating from the Primary Storage Tier to the Perpetual Storage Tier, for each storage location enter a department (see Configure Departments) and a cost per terabyte (TiB). StorCycle will then monitor the amount of data moved between storage locations and calculate an associated cost savings.
The use of local storage (for example \\localhost\c$) for source or target storage locations is not currently supported.
Source Storage Location Best Practices
|
Note:
|
Currently, a BlackPearl system cannot be configured as a source storage location. |
StorCycle Storage Locations that are sources of data (data to be migrated) can be configured to be at the top-level directory of a storage server share or at a sub-directory lower down in the directory structure path.
Consider the following when deciding where to place the StorCycle source Storage Locations:
|
•
|
Do the directories contain data for different departments or groups and is tracking of storage usage and cost by department/group desired? If so, each department/group should have its own Storage Location. |
|
•
|
Are there different pools of data that will have different methods of being scanned or archived? For example, some data may need to be scanned weekly whereas other data never needs to be scanned. Or, one pool of data may be archived manually by project or directory, whereas another pool of data is automatically archived on a scheduled basis based on the age of the data. If these different types of pools of data exist, then each should have their own Storage Location. |
Target Storage Location Best Practices
StorCycle Storage Locations that are targets for migrated data can be configured to be at the top-level directory of a storage server share, at a sub-directory lower down in the directory structure path, or to buckets depending on the storage type.
Consider the following when deciding the StorCycle target Storage Locations to create:
|
•
|
To avoid potential directory and file name conflicts on the target, create enough unique target Storage Locations so that data from multiple storage location sources is not migrated / stored to the same storage location targets (buckets or directories). For example, if source Storage Locations A and B both contain a top-level directory dir1 which contains a file file1.txt, and the file from both locations are migrated to the same target, there could be an error or a re-write of data due to both storage locations having data with the same file path and file name. |
|
•
|
The StorCycle solution should be the only application / user using the target storage path (Spectra NAS, non-Spectra NAS, S3, or BlackPearl system). | • | You should not modify files once they are on the target. If a file is changed on the target after being migrated / stored, a restore using the StorCycle solution will fail due to a checksum error. |
| • | You should not add or remove files, folders, or objects from a target storage location |
|
|
•
|
If the target is a Spectra or non-Spectra NAS storage location, you can select different sub-directories to avoid the conflict. |
Retention Policy Best Practices
|
Note:
|
Retention policies are only supported for data center and enterprise licenses. See Licensing for more information. |
A storage location retention policy allows you to select the desired number of days to retain files on a storage location before the StorCycle solution automatically deletes the files for compliance or capacity recovery.
|
•
|
Spectra Logic recommends that the root of a target is never used for a storage location with a retention policy. |
|
•
|
When adding a retention policy to an existing target storage location, any existing Symbolic or HTML links may be broken when the retention policy runs. |
|
•
|
Audit files for retention policy / deletes are stored in a StorCycle system directory (C:\Program Files\Spectra Logic Corporation\Spectra StorCycle\audit or $HOME/.ssc/audit) which should be backed up regularly. |
|
•
|
Pending Delete notifications should be enabled for all Administrator users. See Configure Users. |
|
•
|
Pending delete notifications are sent approximately five days before the delete occurs. Retention policies which are less than 5 days will not generate warning emails ahead of time. |
|
•
|
Spectra Logic recommends never changing a Retention policy after it is configured, to prevent unintended deletion of data. |
|
•
|
Targets which are using a retention policy should utilize a specific naming scheme to help administrators and users understand which targets have retention policies. |
Continue with Configuring Storage