top of page

bits, bytes & other nibbles

  • Writer's pictureDATASTOR

How Many Stores Do I Need?


Customers often ask, “How many stores do I need?” That’s a proper question to ask as you plan and modify your DATASTOR installation.  And as often is the case in life, an ounce of prevention is worth a pound of cure.


A store is a self-contained, self-describing storage location that is the destination for your protected data.  It resides on a storage device formatted with any number of supported file systems. In all but small installations we recommend at minimum using two stores, a store for unstructured data (file server data) and a store for structured data (database data). You may also want to consider a third store for a document management system that is static content, meaning the files are stored but never edited nor deleted. Why? First, note that in each case there would be no additional storage requirement on the volumes that contain the stores. Global Single Instance Storage takes place at the store level, but since we are dealing with unique data types there would be minimal crossover between the three stores in comparison to a single store.


So, now for the benefits of creating multiple stores. First, you’ll see store tasks running in a shorter timeframe, e.g. verify and purge tasks. Store tasks can be lengthy processes, and they usually run at the store level. The more items in the store, the more processing is required. If you have ever monitored a purge process and wondered when it would end you were experiencing this behavior. Purge has to account for all the data stored in the entire store to determine what items in the store are no longer referenced by any of the various protection plans targeting it. If the store had half the items in it due to having a second store, then the purge process would have half the scan time and half the restore point catalogs to read through. Purge runtime is an important consideration when you are running low on disk space, as well. You do not want to delay backups waiting for free disk space to arrive. This should be handled through proper scheduling and monitoring of your checkup reports, but if you find yourself in that unenviable position of needing a purge to complete, you’ll be thankful at having multiple, smaller stores.


Because stores cannot span volumes, you may also benefit from placing multiple stores on more than one existing storage devices or volumes. If your volume experiences corruption and requires repair, the repair process on a smaller volume will be faster than by putting your stores on a single massive volume. We do fully support using very large volumes of 4, 6, or 8 TB or more, but if your data size and rate of growth permits, consider 2 TB volumes.


The follow up question from customers is sometimes, “What can I do if I already have a single store but want a second store?”


Well, luckily you can transition your archives from one store to a second store, using the Archive Manager features. If you wanted your Exchange backups to reside in a second store, for example, you could ‘Add a store’ on a desired volume, perhaps naming it ‘Exchange’. Then, create a store copy task between the two stores, selecting only the Exchange backup for copy. (Obviously, but worth pointing out, if you were putting the second store on the same volume as the first, you would need adequate free disk space to hold the copied archive until the first could be deleted). During the copy, you might need to let the Exchange backup run to the original store one or more times. Simply wait for the copy task to complete, then run it again to pick up the new restore points, then, before the plan runs again, set the Exchange plan to target the new store. After confirming everything is running as expected, simply delete the archive from the original store and run purge to recover disk space. (Hey, you could also forgo the copy, and just set the plan to target the new store going forward. Expire the original archive over time until you can finally just delete it).


Finally, our cloud and tape vaulting, requires a cache location used to store vaulting information, but also used as a landing space for data recovered from the vault. Plan to set aside a volume or disk space at least as large as the size of your largest (deduplicated) archive for that.

bottom of page