You may not be familiar with the name Crispin Porter + Bogusky, but you’re probably familiar with their work. The firm, which was named U.S. Agency of the Year by Adweek last year, created “The King” and “Whopper Freakout” campaigns for Burger King; the Windows Mojave, Jerry Seinfeld/Bill Gates and I’m a PC campaigns for Microsoft; as well as ads for Guitar Hero, Old Navy, Best Buy, Coke Zero, and others.

For the previous four years they have also been the official U.S. agency for Volkswagen and have created a lot of media during that time. So, when it came time to archive all of that media somewhere…they decided to build their own Backblaze Storage Pod.

Ryan Banham, Windows Evangelist at Crispin Porter + Bogusky took on the task:

Just as everyone is settling down for a big turkey dinner our first
Backblaze storage pod will be preparing to feast on terabytes of data.

He customized the Backblaze storage pod reference design with a different motherboard, more memory, Samsung instead of Seagate drives, a single power supply, and used Windows Server 2008 as the operating system. It’s great to see people making the design suit their particular purpose. Once he hones in on the final design for their purpose, he plans to deploy several racks of mirrored archive servers to support their storage needs.

Some of the feedback Ryan provided to us on his customized version included:
* The pod is uber-cool: Even under full load the drives stay under 72 F, so he also swapped our fans for quieter and lower power intake fans.
* No trampolines for the pod: Moving the pod around requires the RAID cards to be reseated (possibly because the bottoms of the RAID cards stick out of the case.)
* $20 gets you far. A pod running 50% - 75% of the month costs just $20 in electricity.

Ryan says:

Thanks for sharing the build and giving me something fun and
interesting to do over the last few weeks! I learned a lot.

Glad it was interesting and useful and thank you for sharing your learnings!

Photos Ryan sent us of his pod:

What do Google providing search, Coca-Cola operating its systems to track inventory, and Backblaze backing up your data have in common? The computers that handle all of this live in data centers. And those data centers use power - lots of it.

In the U.S. alone there are over 20,000 data centers - each of which houses thousands or tens of thousands of servers. Combined, these data centers make up 3% of all U.S. energy consumption (not just electricity) - more than the entire domestic air fleet.

So when I went to an event on Wednesday called:
THE TRUTH ABOUT THE FUTURE OF THE DATA CENTER:
CLOUD, COLOCATION, & DATA CENTER REAL ESTATE
it should be no surprise that the focus was on power, power, power.

And lest you think this is people getting wrapped up in the green movement or just jumping on a marketing trend - let me dissuade you. Datacenters in the U.S. spend $23 billion a year on electricity according to KC Mares of MegaWatt Consulting. In fact, electricity can often cost over 50% of the purchase price of a server over it’s lifetime. Minor improvements can have massive implications not only on global warming but also company bottom lines.

KC provided a fascinating overview of innovations and experiments that operators of data centers and the companies building out large server deployments are pursuing. Some examples:

* VFDs - variable frequency drives to adjust the speed of blower fans that adjust to need rather than spinning at a constant rate.
* Natural cooling - using outside air and fans rather than air-conditioning to keep data centers cool; it turns out most servers are perfectly happy running at temperatures much higher than what data centers attempt to keep them at.
* Shorter cooling regions - having air flow almost directly around a server in the process of cooling it rather than through the entire building; shorter distances mean less air friction and less energy spent moving it around.
* Eliminating UPS systems - getting rid of the backup power systems and assuming servers will go down…and having backup servers or data centers instead.
* Using 480 volts - higher voltage means lower amperage and thus less heat loss and higher efficiency. More of today’s server systems are capable of handling this voltage.
* Higher efficiency power supplies - switching to 90% efficient power supplies on servers rather than using 70% or 80% ones; these are more expensive upfront but can still pay off fairly quickly.

A number of these items pay for themselves in a couple months and then generate savings ongoing from then on. KC has a variety of information on his site and blog.

Don Honabach has the honor of being the first person to successfully build his own Backblaze storage pod. (At least the first we know about.)

With four servers running at home for media storage, Don, was using a fair bit of power (and probably generating a lot of heat and noise and taking up space.) For five years he was working to come up with an “Extreme Media Server” and after reading about the Backblaze storage pod, he decided this may be the way to go.

Having expertise in the space, Don customized a variety of items in the pod including:
* The operating system (switching to Microsoft Windows Server 2008 R2)
* Power supplies
* Motherboard
* and more…

In just a couple weeks Don had completed his “Extreme Media Server”. Combining all four servers into one, Don is saving 500 watts of power, and can run 16 independent movie streams across two monitors from a single storage pod.

Don created a blog that describes his experiences building his Extreme Media Server.

Congratulations Don and good luck watching all those movies at the same time!

Last month’s blog post about building our Backblaze storage pods generated a ton of interest and many people are building their own pods! Our post also generated a ton of questions so below we answer the common ones and provides more detail about where to get components.
Continue reading…

Three weeks ago we published how to build a Backblaze Storage Pod, the cloud storage hardware we use for our unlimited online backup service, and gave away the design to anyone who wished to build their own. We thought a few people might find it interesting. Perhaps some might even want to try to build one. We never expected would happen next.

Om Malik wrote about it at GigaOm, as did Robin Harris at StorageMojo, and Cory Doctorow on Boing Boing. Soon after, CrunchGear, VentureBeat, ZDNet, Mashable, TUAW, Electronista, MacWorld, Vator.tv, NetworkComputing, On-Storage, PSFK, Enterprise Storage Forum, eWeek and dozens of others picked it up. After digging in, SmallNetBuilder did a thorough breakdown for its DIY audience.
Continue reading…

At Backblaze, we provide unlimited storage to our customers for only $5 per month, so we had to figure out how to store hundreds of petabytes of customer data in a reliable, scalable way—and keep our costs low. After looking at several overpriced commercial solutions, we decided to build our own custom Backblaze Storage Pods: 67 terabyte 4U servers for $7,867.

In this post, we’ll share how to make one of these storage pods, and you’re welcome to use this design. Our hope is that by sharing, others can benefit and, ultimately, refine this concept and send improvements back to us. Evolving and lowering costs is critical to our continuing success at Backblaze.

Below is a video that shows a 3-D model of the Backblaze Storage Pod. Continue reading to learn the exact details of the design.

You can download the full 3-D model of the Backblaze Storage Pod here.

Continue reading…

Introduction
I’ve had a lot of success in my 20 year software engineering career with developing cross platform ‘C’ and ‘C++’ code.  At Backblaze, we just released the Mac beta version of our online backup service, so I thought it an apt time to discuss my 10 rules for writing cross-platform code. We develop an online backup product where a small desktop component (running on either Windows or Macintosh) encrypts and then transmits users’ files across the internet to our datacenters (running Linux.)   We use the same ‘C’ and ‘C++’ libraries on Windows, Mac, and Linux interchangeably.  I estimate it slows down software development by about 5 percent overall to support all three platforms.   However, I run into other developers or software managers who mistakenly think cross platform code is difficult, or might double or triple the development schedules.  This misconception is based on their bad experiences with badly run porting efforts.   So this article is to quickly outline the 10 simple rules I live by to achieve efficient cross platform code development. 

Continue reading…

Goal: Security done right
Protecting the privacy of our users’ data is a top priority for us here at Backblaze and that means encryption. But providing a service that is extremely easy to use is also a key part of our vision and far too often encryption makes a product hard to use. This trade-off was unacceptable to us so we set out to build a system that delivers military grade encryption without compromise! Here is the full list of our requirements:

1) Protect data with military grade encryption
2) Implement encryption transparently so users don’t have to deal with it
3) Allow users to change their password without re-encrypting their data
4) In business environments, allow IT access to data without the user’s password

The solution: Military grade encryption made easy
To accomplish the ambitious goals above we used a mix of public/private and symmetric key algorithms. The math behind this cryptography is hard but the idea is simple…. Public/private keys allow you to encrypt data with one key and decrypt it with another one. Typically data is encrypted with the public key and decrypted with a private key that is kept secret but the reverse also works. This is very useful because it allows us to encrypt data in the background without requiring the user to type in their password.

Unfortunately, public/private key algorithms are slow and can’t be used to encrypt a large amount of data. Symmetric key algorithms use the same key to encrypt and decrypt data and are very fast on large amounts of data. But since the same key is used to decrypt the data, the data is only secure if the symmetric key is secure.

Combining these algorithms, here’s how our system works.


We generate a new 2048-bit RSA public/private key pair when our client is installed, store the public key on the local disk and transmit the private key to our datacenter via https. Then, for each backup session, we generate a new random 128-bit AES symmetric key which we use to encrypt the user’s data. We secure the 128-bit AES key by encrypting it with the user’s public key and transmit the encrypted file along with the encrypted key to our datacenter over https. We destroy the unencrypted 128-bit AES key at the end of each backup session and never write it to disk. To decrypt a file, the user’s private key is used to decrypt the 128-bit AES which is then used to decrypt the file.

The user’s private key which is stored safely in our datacenter is protected by a password that is highly guarded. But for some users this is not good enough and we allow the user to secure this file with their own password. When this is done it is impossible to access the data without the user’s password. Unfortunately, this also means we can’t help the user if they ever forget this password so we don’t recommend it for most users.

The real beauty of this scheme becomes clear when you look back at our goals above. AES is the encryption standard adopted by the US government to protect classified information. #1 solved. Using the user’s public key we can safely run transparently in the background without compromising security. #2 check. Since a password is used to secure the private key rather than to encrypt the data directly, the password can be changed by re-encrypting only the private key with the new password. #3 accomplished. And last but not least, you can make several copies of the user’s private key and encrypt each copy with a different password to provide IT access to data without the need to share passwords. #4 done!

This seems like a mathematical question, but is actually one of philosophy or perspective, and continues to cause confusion in its ambiguity.

A Bit of History
Originally megabyte was used to describe a byte multiple (2²⁰ = 1024 x 1024 = 1,048,576) in computer programming. However, several international organizations and most storage media (including hard drives and DVDs) use the Latin approach to the measurement whereby a megabyte is 10³ bytes (1000 x 1000 = 1,000,000.) Operating systems still refer to a megabyte as 1024 x 1024 bytes.

So why does that 500 GB external USB drive already feel a bit small? Well, a small part of it may be that you have actually “lost” 34 GB before taking it out of the package as it actually only stores 466 GB according to your file system.

Where Are We Now?

Apple sticks with the byte multiple approach (1024x) typical for file managers.

Microsoft Windows, for better and for worse, actually provides both numbers, explaining them as “Size” and “Size on disk.” This differentiation does not make sense – there is only one “size” – just different ways to measure it. The distance from San Francisco to Los Angeles does not change whether you measure it in miles or kilometers. Providing both numbers can be useful for troubleshooting or to explain to someone why the hard drive they just purchased has shrunk according to the operating system, but it does continue to perpetuate confusion.

A Solution?
The major measurement organizations tried to propose a solution, creating the terms “kibibyte”, “mebibyte”, “gigibyte”, etc. which would specifically refer to the 1024x approach, and going forward “kilobyte”, “megabyte”, and “gigabyte” would refer to the 1000x interpretation. Unfortunately, the world has already wed itself to the old lingo.

Search for “mebibyte” on the websites of Microsoft, IBM, Adobe, Symantec, Dell, EMC, and NetApp.
Number of results: 0

Even Microsoft Word tells me I have a spelling error when I write “mebibyte.”

We Chose the Operating System Interpretation
In other words, whenever you see a measurement presented, it is always based on 1024x. Why? Because more advanced users often compare the size a folder selected for backup according to our system and the size their file manager claims. Standardizing on the size presented to them makes it easiest for the user and to answer any support questions. It would be great if there was one system, but in the meantime, I’m not counting on the mebibyte to save us.

When we were thinking about a logo for Backblaze, we knew we wanted an iconic image that could be connected easily to the software. That meant creating something simple enough that could scale to 16×16 pixels for an icon placed in the system tray. Logos are probably the most difficult for me as a designer to do. There is a feeling that a company will live with this identity for the rest of it’s life, so it better be perfect. And everyone has a different opinion: “That looks too techy. Can we make it more catchy? It looks like a squished squid.”
Well squished squid or running starfish, it’s good to get the stakeholders opinion. As a designer, such criticism makes me articulate what I am trying to accomplish, rather then just feeling intuitively through the design process.

So what do I think of the Backblaze logo? It’s all flamey and stuff.