Remote storage with solid SSPs - I assume you mean trusted SSPs with serious management teams and the like. Hopefully running close to profitability?
I believe remote storage is very important for DR purposes. Whether it is disk or tape or whatever - it is important to be able to recover data when you have a site disaster. Remote storage can also be great for archiving old data that you don't want to have cluttering up your storage any longer.
However, remote storage for on-line data is still pretty tough because of bandwidth concerns. Block based mirroring is pretty much out of the question. That said, I think there is a lot of value in being able to replicate database information to a remote site. I'm not talking about mirroring here, but information replication. It's not just a storage problem because you need a system to apply the updates. Several companies make replication products including Oracle, Veritas and Data Mirror. Other RDBMs besides Oracle may also have homegrown or third- party replication, I'm just not up to speed on them.Beyond the DB replication, I believe there can be valuable benefits for storing file data at a solid SSP. The SSP could take over the administration of the file system for you and offload your staff. This could involve such things as managing backups, maintaining historical file versions and archiving unused files. A customer needs to be able to communicate to the SSP what they want done, but after that, it could be a real benefit to the customer.
n the future it will be possible for a local IT administrator to establish metadata tags that would signal how files are to be treated by the SSP. This will be extremely valuable because it allows local IT staff to prescribe the management of data but offloads the automated physical management to the SSP. This is a great division of labor to be sure.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in our Storage Networking discussion forum at http://searchstorage.discussions.techtarget.com/WebX?replyToMessage@7.uALMagHuauI^1@.ee83ce4!viewtype=convdate
This was first published in December 2001