Hilbert’s Infinite Hotel Paradox<\/a> \u2013 you sort-of, kind-of never run out of capacity because you always just buy another box of tapes. Problem solved, right? (No, more a case of the can kicked down the road.) Problem “solved” and you’ve got 1,000, 10,000, 50,000 tapes in a multitude of media types that you don’t even have tape drives to read any more.<\/p>\nYet we like to focus on the real world now and tape isn’t the defacto standard any more for backup systems: it’s disk. Disk gives us great power, but with great power comes great responsibility (sorry, even though I’m not a Spiderman fan, I couldn’t resist. Tape is the opposite: tape gives us no power, and with no power comes no responsibility \u2013 yes, I’m also a Kickass fan.)<\/p>\n
For businesses that still do disk-to-disk-to-tape, where disk is treated more like a staging area and excess data is written out to tape, the problem is seemingly solved because \u2013 you guessed it \u2013 you can always just buy another box of tapes and stage more data from disk backup storage to tape storage. Again, that’s kicking the can down the road. I’ve known businesses who have had company-wide data protection policies mandating up to 3 months of online recoverability from disk getting down to two weeks or less of data stored on disk because the data to be protected has continued to grow, no scaling has been done on the storage, and \u2013 you guessed it \u2013 tape was the interim solution.<\/p>\n
Aside<\/b>: When I first joined my first Unix system administration team in 1996, my team had just recently configuring an interim DNS server which they called tmp<\/em>, because it was going to be quickly replaced by another server, which for the short term was called nc<\/em> for new computer. When I left in 2000, tmp<\/em> and nc<\/em> were still there; in fact, nnc<\/em> (yes, new-new-computer) was deployed shortly thereafter to replace nc<\/em> and eventually, a year or two after I left, tmp<\/em> was finally decommissioned.<\/p>\nInterim solutions have a tendency to stick<\/strong>. In fact, it’s a common story \u2013 capacity problem with data protection so let’s deploy an interim solution and solve it later. Later-later. Much later. Much later-later. Ad-infinitum<\/em>. (That’s why way too many companies just keep on kicking the can down the road when it comes to data lifecycle management: “this is too hard, we’ll just buy another 100 TB”.)<\/p>\nThere is, undoubtedly, a growing maturity in handling data protection storage management and capacity planning coming out of the pure disk<\/em> and disk\/cloud<\/em> storage formats. While this is driven by necessity, it’s also and important demonstration that IT processes need to mature as the business matures as well.<\/p>\nIf you’re new to pure disk based, or disk\/cloud based data protection storage, you might want to stop and think carefully about your data protection policies and procurement processes\/cycles so that you’re able to properly meet the requirements of the business. Here are a few tips I’ve learnt over the years…<\/p>\n
80% is the new 100%<\/h1>\n
This one is easy. Don’t think of 100% capacity as being 100% capacity.<\/strong> Think of 80% as 100%. Why? Because you need runway to either procure storage, migrate data or get formal approval for changes to retention and backup policies. If you wait until you’re at 90, 95 or even 100% capacity, you’ve left your run too late and you’re just asking for many late or sleepless nights managing a challenge that could have been proactively dealt with earlier.<\/p>\nNote<\/strong>: This isn’t to say that your data protection storage will stop working at 80%! I’ve seriously been in meetings where people have said that’s what I mean along that line. Maybe that might be true of other data protection storage, but it’s certainly not for Data Domain: it’ll keep happily writing away until you hit 100%. But it’s never going to let you write to 101%.<\/p>\nAt 80% you have to know what your plan is<\/strong>. Actually, I’ll go one better than that: you should know well in advance what your potential plans<\/em> are, and at 80% the only work<\/em> should be to decide which plan<\/em> you need to invoke. That’s it.<\/p>\nThe key to management is measurement<\/h1>\n
I firmly believe you can’t manage something that has operational capacity restraints (e.g., “if we hit 100% capacity we can’t do more backups”) if you’re not actively measuring it. That doesn’t mean periodically logging into a console or running a “df -h” or whatever the “at a glance” look is for your data protection storage, it means capturing measurement data and having it available in both reports and dashboards so it is instantly<\/em> visible.<\/p>\nThe key to measurement is trending<\/h1>\n
You can capture all the data in the world and make it available in a dashboard, but if you don’t perform appropriate localised trending against that data to analyse it, you’re making your own good self the bottleneck (and weakest link) in the capacity management equation. You need to have trends produced as part of your reporting processes to understand how capacity is changing over time. These trends should be reflective of your own seasonal data variations or sampled over multiple time periods. Why? Well, if you have disk based data protection storage in your environment and do a linear forecast on capacity utilisation from day one, you’ll likely get a smoothing based on lower figures from earlier in the system lifecycle that could actually obfuscate more recent results. So you want to capture and trend that information for comparison, but you equally want to capture and trend shorter timeframes to ensure you have an understanding of shorter term changes. Trends based on the last six and three months usage profiles can be very useful in identifying what sort of capacity management challenges you’ve got based on short term changes in data usage profiles \u2013 a few systems for instance might be considerably spiking in utilisation, and if you’re still comparing against a 3-year timeframe dataset or something along those lines, the more recent profile may not be accurately represented in forecasts.<\/p>\n
In short: measuring over multiple periods gives you the best accuracy.<\/p>\n
Maximum is the new minimum<\/h1>\n
Linear forecasts of trending information are good if you’re just slowly, continually increasing your storage requirements. But if you’re either staging data (disk as staging) or running garbage collection (e.g., deduplication), it’s quite possible to get increasing sawtooth cycles in capacity utilisation on your data protection storage. And guess what? It doesn’t matter if your capacity requirements for the average<\/em> utilisation are met if you’ll grow beyond the capacity requirements of the day before the oldest backups are deleted or garbage collection takes place. So make sure when you’re trending you’re looking at how you meet the changing maximum<\/em> peaks, not the average sizes.<\/p>\n10GB is not 10GB<\/h1>\n
Something I get asked from time to time goes like this: “Hey, I just want to backup 20TB. Can you give me a price for that?” Here’s the short answer: well, no I can’t. And that’s not because I’m in presales<\/em> rather than sales<\/em>. It’s because with that level of information, I literally can’t give you an answer<\/em>.<\/p>\nAs part of modern capacity management, it’s not good enough to know that you’re going to be adding 10GB, 100GB, 100TB, or any other amount of data to your backup environment: you need to understand what<\/em> the data is, as well. You also need to have a rough idea of what its daily change rate, and growth rate is as well. (Here’s a hint: if someone with a shiny new product tells you they don’t need that information, it’s probably because all they’re doing is compressing<\/em> rather than deduplicating<\/em> data. I can give you an average compression ratio in less time than it took me to type this sentence: deduplication \u2013 true<\/strong> deduplication \u2013 is another thing entirely though.)<\/p>\nIf you’re backing up to tape, you’ll assume an average of the hardware compression ratio (and hell, another box of tapes is just another box of tapes, right?); if you’re backing up to dumb disk that’s not doing any deduplication, then yeah, 10GB is 10GB. But in the world of deduplication, it’s really<\/em> important to understand: is that filesystem data, virtual machine image data, database data, uncompressable data, encrypted data, etc. And so, if you’re looking at understanding capacity and growth rules for a modern data protection environment, you’ll have some estimates of what those different types of data might contribute to the capacity \u2013 or know to double-check. Sometimes the scariest request I get is “We’re adding a new workload, can you quote an expansion tray?” My first answer is always<\/em>: “What’s this new workload?”<\/p>\nKnow your windows<\/h1>\n
There’s three types of windows I’m referring to here \u2013 change, change freeze, and procurement.<\/p>\n
You need to know them all intimately.<\/p>\n
You’re at 95% capacity but you anticipated this and additional data protection storage has just arrived in your datacentre’s receiving bay, so you should be right to install it \u2013 right? What happens if you then have to wait an extra week to have the change board consider your request for an outage \u2013 or datacentre access \u2013 to install the extra capacity? Will you be able to hold on that long? That’s knowing your change windows.<\/p>\n
You know you’re going to run out of capacity in two months time if nothing is done, so you order additional data protection storage and it arrives on December 20. The only problem is a mandatory company change blackout started on December 19 and you literally cannot<\/em> install anything, until January 20. Do you have enough capacity to survive? That’s knowing your freeze windows.<\/p>\nYou know you’re at 80% capacity today and based on the trends you’ll be at 90% capacity in 3 weeks and 95% capacity in 4 weeks. How long does it take to get a purchase order approved? How long does it take the additionally purchased systems to arrive on-site? If it takes you 4 weeks to get purchase approval and another 3 weeks for it to arrive after the purchase order is sent, maybe 70%, not 80%, is your new 100%. That’s knowing your procurement windows.<\/p>\n
Final thoughts<\/h1>\n
I want to stress \u2013 this isn’t a doom and gloom<\/em> article, even if it seems I’m painting a blunt picture. What I’ve described above is expert tips \u2013 not just from myself, but from my customers, and customers of colleagues and friends, whom I’ve seen manage data protection storage capacity well. If you follow at least<\/em> the above guidelines, you’re going to have a far more successful \u2013 and more relaxed \u2013 time of it all.<\/p>\nAnd maybe you’ll get to spend Thanksgiving, Christmas, Ramadan, Maha Shivaratri, Summer Solstice, Melbourne Cup Day, Labour Day or whatever your local holidays and festivals are with your friends and families, rather than manually managing an otherwise completely manageable situation.<\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction Note: I first wrote this in November 2016, but since this covers topics that comes up regularly with customers,…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":true,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[3,5,1133],"tags":[1330],"class_list":["post-6036","post","type-post","status-publish","format-standard","hentry","category-architecture","category-backup-theory","category-best-practice","tag-capacity-management"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1zm","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6036","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=6036"}],"version-history":[{"count":9,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6036\/revisions"}],"predecessor-version":[{"id":7403,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6036\/revisions\/7403"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=6036"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=6036"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=6036"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Glass\"](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2016\/11\/bigStock-Cup.jpg\")
<\/a><\/p>\n