Comments on: Process vs. Technology http://www.thestoragealchemist.com/process-vs-technology/ Turning Storage Technology into IT Gold Fri, 18 May 2012 03:39:36 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Glenn Grabowski http://www.thestoragealchemist.com/process-vs-technology/comment-page-1/#comment-40 Glenn Grabowski Tue, 05 May 2009 22:12:44 +0000 http://www.backupandbeyond.com/?p=74#comment-40 Great stuff, Steve. Couldn't agree more. While I agree we're at an inflection point where data growth and traditional backup methods can't ensure a business's objectives are met, we're also at another inflection point. Economic woes have caused IT Shops to trim their talent and budgets while trying to grow whatever business they still have. Backup technology is often, as you say, put on the back burner. Enter Data De-Dupe. It looks tempting because it "reduces the storage footprint" in the datacenter, etc. However, some de-dupe technology is too expensive on paper so a "free feature" on an array/filer is often chosen as a "quick fix", or band-aid. My standpoint is that de-dupe technology is only part of the solution and is, on the surface, a band-aid. It has its place but it doesn't attack the root of the problem: poor data management. The same process that Steve speaks of that makes change difficult also ignores how data is managed during its lifecycle. Whether we use source-based or target-based de-dupe SW/HW, we're not addressing how data is truly managed. The easy way out is to ignore the issue for a rainy day and address it later. In the meantime, IT Shops will buy the most storage they can afford(with or without de-dupe "built in") and try to tread water. Now, I'm a realist. I know data lifecycle management has been bandied about for a decade(or more) with few winning vendors delivering the ROI they promised, which leads me to the second inflection point I brought up earlier. With dwindling budgets and staff, now is the time to either: 1. invest a little in data management tools, or a services engagement, and decide what information even belongs in the datasets customers struggle to backup nightly, or, 2. use some good old fashioned elbow grease to analyze your data. The goal would be to reduce your primary dataset FIRST. Then, decide if you even need de-dupe. Again, I'm a realist. Archiving software isn't perfect and isn't simple to deploy but once you "get to know" your data, you can use elbow grease again, if necessary, to move the old data off the primary dataset. Like Steve says, it's process vs. technology. Getting a grasp of your data is a process and technological challenge. However, I think it's the key regardless of the type of data de-dupe eventually chosen. Great stuff, Steve. Couldn’t agree more.
While I agree we’re at an inflection point where data growth and traditional backup methods can’t ensure a business’s objectives are met, we’re also at another inflection point. Economic woes have caused IT Shops to trim their talent and budgets while trying to grow whatever business they still have. Backup technology is often, as you say, put on the back burner. Enter Data De-Dupe. It looks tempting because it “reduces the storage footprint” in the datacenter, etc. However, some de-dupe technology is too expensive on paper so a “free feature” on an array/filer is often chosen as a “quick fix”, or band-aid. My standpoint is that de-dupe technology is only part of the solution and is, on the surface, a band-aid. It has its place but it doesn’t attack the root of the problem: poor data management. The same process that Steve speaks of that makes change difficult also ignores how data is managed during its lifecycle. Whether we use source-based or target-based de-dupe SW/HW, we’re not addressing how data is truly managed. The easy way out is to ignore the issue for a rainy day and address it later. In the meantime, IT Shops will buy the most storage they can afford(with or without de-dupe “built in”) and try to tread water.
Now, I’m a realist. I know data lifecycle management has been bandied about for a decade(or more) with few winning vendors delivering the ROI they promised, which leads me to the second inflection point I brought up earlier. With dwindling budgets and staff, now is the time to either:
1. invest a little in data management tools, or a services engagement, and decide what information even belongs in the datasets customers struggle to backup nightly, or,
2. use some good old fashioned elbow grease to analyze your data.

The goal would be to reduce your primary dataset FIRST. Then, decide if you even need de-dupe. Again, I’m a realist. Archiving software isn’t perfect and isn’t simple to deploy but once you “get to know” your data, you can use elbow grease again, if necessary, to move the old data off the primary dataset.

Like Steve says, it’s process vs. technology. Getting a grasp of your data is a process and technological challenge. However, I think it’s the key regardless of the type of data de-dupe eventually chosen.

]]>