Commentary

George Crump
 

Migration Relief

In my last entry on migration migraines we discussed the challenges of moving from one primary storage provider to another and went through a few solutions. One of the best methods to make migrations easier is to keep the amount of data on primary storage at a minimum, but what do you do about archives that will grow to petabytes in size?

In my last entry on migration migraines we discussed the challenges of moving from one primary storage provider to another and went through a few solutions. One of the best methods to make migrations easier is to keep the amount of data on primary storage at a minimum, but what do you do about archives that will grow to petabytes in size?Moving from one primary storage platform to another is a fact of life. New suppliers will continue to emerge which offer compelling advantages over your current supplier, or new technologies altogether such as solid state disk may cause the need to change primary storage suppliers. The answer as I have written about is to move inactive data off primary storage as soon as you can. Keeping primary storage small not only keeps costs in line, it also makes migration between platforms easier by keeping the data set small.

The potential pitfall of aggressive archiving is that the capacity of that archive will and should get very large over time. Archives of 50 terabytes to 100 terabytes will become commonplace and over the next five or six years, PB-sized archives will not be uncommon. Data sets of this size not only make migration impossible; they make tasks like backup a challenge. Does this invalidate the disk archive concept? No. Growth is inevitable. You have to choose where you want that growth to happen and a platform to deal with that growth. As I stated in a prior post on the potential cost savings of archives, you want to grow your storage in the area where it costs the least and that area is the archive. How, then, do you deal with large archives? You need to design the archive to be a permanent fixture in the data center. The answer is scalability, massive scalability. This is where "real" archive solutions come into play, systems that were designed from the ground up to provide archiving as opposed to dense, cheap RAID boxes.


More Storage Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

Companies like Copan Systems and Permabit all have systems that can scale close to 1 PB and both will exceed that number as drive capacities continue to grow. They get there differently. Copan Systems uses densely packed power-managed drives, while Permabit uses grid architecture to offer scale. The point is that they both can scale, offer key redundancy capabilities, and offer functionality that will routinely check the health of the data and drives in the system. They are designed for long-term retention of data. Even with all this scalability, technology will continue to march on. The ability to upgrade these architectures without moving data is going to be critical and is something for you to pay attention to. This is something that cloud storage may seem ideal for and a topic we will address tomorrow. I am participating in a Cloud Storage 101 Webinar this coming Wednesday at 3 p.m. EDT. If you are interested, please click here.

Track us on Twitter: http://twitter.com/storageswiss.

Subscribe to our RSS feed.

George Crump is founder of Storage Switzerland, an analyst firm focused on the virtualization and storage marketplaces. It provides strategic consulting and analysis to storage users, suppliers, and integrators. An industry veteran of more than 25 years, Crump has held engineering and sales positions at various IT industry manufacturers and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links