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

Source Storage Location Best Practices - General

Note: A BlackPearl gateway 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.

Source Storage Location Best Practices - NAS Storage

When creating a NAS share on a Windows host, several permissions are inherited by the share. If a permission does not already exist on the Windows host, it is created.

Inherited permissions from archive and restore target directories may conflict with permissions StorCycle attempts to archive or restore from the original source objects and directories. When permissions conflict, the operation may generate warnings, errors, and may make changes to file accessibility. Typically these permissions are CREATOR_OWNER, CREATOR_GROUP, AND EVERYONE.

Spectra Logic recommends disabling inheritance for both archive and restore target directories as described below. This allows the StorCycle solution to preserve the existing permissions of the source object during archive and restore operations.

Note: BlackPearl NAS source storage does not support symlinks.

When creating a new NAS share, configure the share with the following permissions:

Local Administrators - Full Control - This folder, files and subfolders.
SYSTEM - Full Control - Full Control - This folder, files and subfolders.
If you created a custom StorCycle user, set the permission to StorCycle Service Account - Full Control - This folder, files and subfolders.
Inheritance should be disabled by clicking "Disable Inheritance".
Remove all other permissions.

Versioning

When versioning is enabled, multiple versions of a file from the source storage location are kept on the target storage location after multiple migrate / store jobs. Each file name has a code appended to the file name that indicates the date and time that the migrate / store job started, in the format yyyymmddhhmmss using a 24-hour clock using UTC time. Versioning can be configured on a per source storage location basis to create versions for all files in the source or only files that changed, and to keep a set number of versions of a file, deleting the oldest when necessary.

Notes:   l HTML and Symbolic Links are not supported in Migrate / Store jobs from versioned sources.
l If a versioned source is used in multiple projects, Spectra Logic recommends that each project uses a different working directory.
l When packing is enabled on a target, and a versioned source is used with keep XX versions, the StorCycle solution is not able to delete older versions from the target. If a job is restored from a target with packing enabled and which contains a versioned file which has been deleted due to keep XX versions, the StorCycle solution does not include the deleted file in the restore, even if it still exists in a pack. The deleted version does not exist in the StorCycle database and the restore job completes without warnings or errors.
l The StorCycle solution assumes that all files with the exact same file name and directory path are the same file for versioning, and determines change criteria based on file size and hash. If a versioned file is removed from a source location, and then replaced with a different file with an identical file name, the StorCycle solution continues versioning the new file with the identical file name as if it was an edited version of the old file.
l The StorCycle solution does not track content to determine which version of the file is current. If an older version of the file is restored to the source and then archived again, it is now considered the newest version of the file.

Configuring Versioning

Configuring versioning is a step in the configuration process for all types of source storage location. See Configuring Storage.

IMPORTANT 

Spectra Logic recommends that a versioned source is only used in one migrate / store project at a time.

Versioning cannot be disabled for an existing source after a migrate / store job from the source is used, and it cannot be enabled for an existing source that was previously used.

Changed Files Only option - If selected, a new version is created only when the file changes (file modified time and hash changes). If not selected a new version is created whenever there is a migrate / store job from the source storage location. The Changed Files Only option can be enabled or disabled at any time.

Versions to Keep option - If selected, the StorCycle solution keeps the specified number of versions on the target storage location. Each day at midnight UTC, the StorCycle solution determines the number of versions of a file on target storage locations and automatically deletes the oldest copies if there are more than specified. If not selected, versions are not automatically deleted. This option is compatible with both standard versioning and Changed Files Only versioning. The Versions to Keep option can be enabled or disabled at any time.

Note: When a versioned file is deleted from a target, the associated job is updated to remove information about the file so that an attempt to restore the file cannot occur.

IMPORTANT 

Versions to Keep applies to all projects associated with a source location. If two independent projects are using the same source to two different targets, the StorCycle solution will maintain XX versions across all projects. For example, if the storage location is configured to keep 3 versions and Project A has already created 3 versions, after Project B migrates / stores the same source to a different target, the StorCycle solution will automatically remove a version from Project A’s target.

Storage Location Security

To add storage location security to a new or existing source storage location, an administrator can assign an AD / LDAP group to the source storage location which restricts access to scan, migrate / store, and restore jobs, as well as file listings associated with the source, to members of the designated group and administrators. If AD / LDAP is not configured, access is restricted to administrators. The StorCycle solution queries the AD / LDAP server if a user attempts to configure a new restore job to or scan or migrate / store job from the controlled source. For recurring jobs (scans and migrate / stores), the StorCycle solution queries the domain server each time it attempts to initiate the job.

The StorCycle solution also queries the server when a user tries to access information regarding a job to / from a controlled source, such as the Catalog File Listings. The StorCycle solution does not query the AD / LDAP server when assigning groups to source locations, so groups can be assigned without the domain server configured and non-existent groups can be assigned.

Configuring storage location security is a step in the configuration process for all types of source storage location. See Configuring Storage.

Notes:   l Spectra Logic recommends that top level domain groups (not nested groups) be created specifically for the use of managing StorCycle access. Due to the complexity of domain groups, heavily nested groups may introduce search query issues for the StorCycle solution. The AD/LDAP settings include a search query which will be used to query the domain server and will assist in some nested group searches.
l Modifications to the AD/LDAP group search query should only be performed by system administrators who have an understanding of the organizations domain settings.
l StorCycle supports the configuration of only a single domain server and only a single AD group can be assigned to a source location.

What is Restricted - StorCycle Administrators are never restricted. If a Storage Manager or Restore User is not a member of the configured source domain group, they will not be able to perform the following actions:

Scans on controlled source storage locations
Migrate / store jobs from controlled sources
Restore jobs which came from the controlled sources
Restore jobs to the control sources (which originated from another source)
(continued on next page)
Viewing of catalog file listings associated with the controlled source
Notes:   l If a group is assigned to a source that does not actually exist on the domain, the StorCycle solution allows the configuration, but only administrators are able to access the source.
l If a group is assigned but an AD / LDAP domain is not configured, only administrators have access to the source.
l Job details, such as job completion and job statistics are not restricted for any user.
l File names are visible in warnings and error messages.
l Access permission determination occurs when the job starts, so that any changes in group membership are taken into account.

Job ownership - Within the Job Details page for scans, migrate / stores, and restores, the StorCycle solution lists the ‘Created By’ user. This is the user whose permissions are assessed during recurring jobs. If a job is edited, a new field is present in the Job Details called ‘Updated By’. If an Updated By user exists, the StorCycle solution uses this user’s group memberships to assess permissions.

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 BlackPearl system or cloud storage location, make sure the target is using versioning to avoid migrate / store job failures. See the Spectra BlackPearl Converged Storage System User Guide for details.
If the target is a Spectra or non-Spectra NAS storage location, you can select different sub-directories to avoid the conflict.

Encryption Best Practices

The StorCycle solution supports single key encryption for all storage targets. The key is saved in memory. If the server reboots, the password must be reentered.

CAUTION 

Safely store the encryption password. If you lose the encryption password, you are not able to access the data stored by the StorCycle solution after a server reboot.

IMPORTANT 

Once encryption is enabled and the encryption password is set, it cannot be disabled and the password cannot be changed.

IMPORTANT 

StorCycle encryption does not protect the file name and metadata information on the target.

IMPORTANT 

Only users with a Crypto Officer role can enable or disable encryption. See Configure Users for more information about different user types.

Note: Using encryption may have a performance impact on the server CPU.

Retention Policy Best Practices

Note: Retention policies are only supported for data center and enterprise licenses.

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.
Pending delete notifications are sent approximately five days before the delete occurs. Retention policies that are less than 5 days do 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.

Spectra NAS Snapshot Best Practices

When configuring a Spectra NAS storage location, you can select to Enable Snapshot to create a snapshot after a migrate / store job, a retention policy delete, or a delete files job using this target location.

Notes:   l A volume configured for snapshots must already exist on the Spectra NAS system.
l Existing storage locations which have been used in a job can have snapshots enabled and will begin taking snapshots with the next migrate / store job.
l For maximum protection from ransomware, the Spectra NAS volume should be configured for read-only and should not be used by any user or application besides the StorCycle solution – no data should be added, modified, or deleted from this volume outside of the StorCycle solution.
l As a best practice, only a single Spectra NAS storage location should be configured per volume.
l If a Spectra NAS volume is shared by multiple StorCycle Spectra NAS storage locations, all locations must be configured with either read / write or read-only.
l A snapshot is taken even when no objects are sent by a job, or the job fails.
l Snapshots are managed and restored by the Spectra NAS system.

CAUTION 

Restoring to an earlier snapshot on the volume leads to loss of data (and access) from the StorCycle solution. Migrate / store operations following the restore point will no longer be restore-able from the StorCycle solution.

Continue with Configuring Storage