DATASTOR software intelligently protects data on company servers using protection plans and efficiently stores the data in a central repository on a disk volume called a store. Plan and prepare storage up front to minimize the need to reorganize storage down the line. For larger Enterprise level roll outs protecting multiple terabytes of data, consider our best practices. Small to medium size businesses may not need to follow each recommendation.

  • For multiple-Terabyte, discrete data sets, create a separate store for each data type protected. That is, create a separate store for Exchange, SQL, File server data, or document management data types.

  • Create one store per disk volume.  DATASTOR Shield version 9.0 will quickly scan the Master File Table of the volume instead of performing a 'find first, find next' directory scan during execution of store tasks, when there is one store per disk volume.

  • Size the disk volume according to the anticipated size of the store at the end of the maximum retention period, plus 10%.

  • Create a separate volume for vaulting. Vaulting to cloud or tape requires a cache on disk to hold vault metadata and to stage data pulled from a vault back to disk during data recovery. Plan a separate volume for the cache location that is at least double the size of the largest archive restore point in the vault (the amount stored on disk on its initial execution).

To achieve maximum performance of maintenance tasks requires proper planning of the number, location, and size of stores. Consider these further best practices.

  • Best performance is achieved when the store is on a volume that appears as a local disk in Windows, using internal, DAS, SAN, or iSCSI attached storage, as opposed to using a NAS share. 

  • Format the volume with the NTFS file system. Stores may be created on NTFS, FAT32 or EXFAT volumes. The fast scan only works with NTFS volumes.

  • A single store may not span multiple volumes. DATASTOR does not support mount points or junction points within the store itself.

  • Cross-server Single Intance Storage data reduction takes place between all protected servers storing data in the same store . Cross-server deduplication does not take place between stores. Group your servers with the highest level of identical data in the same store.

  • When carving a volume out of a SAN device with multiple spindles (hard disks) for use by a store, be careful not to share the same spindles (hard disks) used for production data. If you do and a RAID failure occurs you could lose both your production data and the protected data in the stores with no recovery option available to you.

  • Microsoft best practice is to create a volume with a GUID Partition Table for large volumes. A partition created in Windows with a GUID Partition Table (GPT) may be extended without re-initializing the volume and losing the store. An MBR volume may not. Click this link for more information http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx

  • Consider limiting the store size to 2 Terabytes per store as a rule of thumb. However, this is not a hard limit. If your environment requires a store larger than 2 TB you must format the volume with a GUID Partition Table. The store size recommendation centers around the amount of time required to perform data maintenance tasks. With one large volume it would take considerable time to run chkdsk or defrag if something happened to the logical disk. 

  • Take into consideration growth in the size of the store as protection plans continue to run. 

  • If you are limited to a 2 TB volume due to a virtual machine or SCSI device limitation keep in mind that the store has a hard limit. Once full you will need to expire and purge data to recover disk space for plans to continue to run to the targeted store. Plan the number of remote servers, data set size, and retention period accordingly.