Are snapshots backup? I think that the usual IT answer is appropriate: It depends.
Although I greatly dislike considering snapshots as backup, I think that it depends upon what events you are trying to protect from. While I don't think that snapshots are adequate in and of themselves, they certainly have their role. The problem lies in the definition of backup: a copy of data maintained for the purpose of recovering data following a data loss event. The key is the word 'copy'. Snapshots aren't copies of data, they are deltas of data from a given point in time to the current state. Thus, they are full images, of data at a given point in time, but they are not full copies. This means that the same events that could cause data loss events will invalidate the snapshots at the same time.
If the sole intent of data protection is to protect from data corruption, accidental deletion, or some other partial, logical data loss, then snapshots may be adequate, but not necessarily sufficient. A snapshot by itself is not an efficient mechanism for locating and recovering an individual misplaced file from last week. In general, snapshots need to be combined with other tools such as replication to really be useful. And then, the lack of a catalog makes it a challenge to locate appropriate recovery versions of lost files.
The bottom line is that snapshots are a part of a data protection plan, but they don't stand on their own. Their primary weakness is a lack of complete copy onto a separate medium. Their primary benefit is that they are small and fast. So, it depends.
Sunday, March 27, 2011
Sunday, March 20, 2011
The Value of Cake
To start off today, I'd like to say thanks to everyone that made Varrow Madness such a huge success. This includes speakers, attendees, sponsors, and all the people behind the scenes. It was everything that I had hoped it would be. I am so excited, I'm ready to start planning for next year. If you didn't make it this year, make sure you plan to attend next year.
As for what cake has to do with anything, it comes down to a conversation with Chad Sakac following a break out session at Varrow madness. Basically, the value of a VBlock is something that many people seem to be having trouble wrapping their heads around. I believe that this is due to their over thinking it or over simplifying it. Chad used the analogy of a cake. If I may extrapolate from that idea for a moment, I would ask if you worry about whether the eggs that were used to bake the cake were free range, fertile, brown, white, large, or extra large. Do you worry about whether the sugar in the cake was brown sugar, cane sugar, or corn syrup? You may or you may not. It really depends on what you intend to get out of the cake. I will return to this idea later.
For now, I'd like to move on to another analogy. This analogy occurred to me while sitting in a training class a couple of months ago. One part of the training went through a white board of the history of the data center from mainframe to open systems to virtualization to cloud. Another part of the training discussed the value of a VBlock. In epiphany, I put the two together.
If you are like me, you very likely have built a PC or server at some time or another. (And likely many more than one.) At any rate, in the late nineties, I felt like the only way to have a PC worth having was to build it myself and hand select all of the components. This meant that I had to choose a case that would support the components that I would be placing in it. I had to find a mother board that was an adequate form factor to fit in the case. It also had to have the appropriate chipset to support the CPU that I wanted to use. Additionally, it had to support the number and type of expansion slots and memory slots that I needed. I then had to find CPUs, RAM, sound cards, video cards, power supplies, NICs, storage controllers, and hard drives. Above that, I also had to select an operating system that would support all of the components. Once all the pieces and parts had been selected, I had to find the appropriate drivers and firmware versions that I wanted to use. Finally, I can build my system.
However, that was where things became painful. All of those components with their varying firmware versions and driver sets might not be quite as compatible as one would desire requiring significant additional work to fine tune the configs and update versions of firmware and drives--often by trial and error--until the entire system would appear to function as desired.
Great. My system is up and running. Now I can go out and get that first application to run. Oh, no. Its not quite compatible with something in the mix. Now I've got to go through the process again. But what happens when I add another application with different requirements or a new driver version comes out and needs to be update? Worse, what happens when something misbehaves and needs troubleshooting? Though I may have support from the individual vendors, they don't necessarily play with each other and are actually most likely to point the finger at each other.
Bottom line....I don't build PC's much anymore. I buy fully supported systems from Acer, Apple, Asus, Dell, HP, Lenovo, etc. They go through the headache of dealing with those issues on a larger scale than I alone could ever do. They see issues repeatedly and can gain from that information. They can customize drivers and configurations to work best for that particular system. They can provide management tools above and beyond any that the individual component manufacturers can provide.
This leaves me with another question for you. Do you build all of your own servers? Most likely not. However, there may be times when you do.
Why? I have the utmost faith that any of you could successfully build a system yourselves. Why do you sometimes build a system and sometimes buy a complete system? Why do you sometimes use off-the-shelf software and sometimes open source? (Although this last question was once one of theology, most businesses today use some degree of both COTS and open source code within their environment.) The answer is really very simple. Sometimes, you don't want to be troubled with assembling it yourself, and sometimes you find that the off-the-shelf product doesn't meet your needs.
This gets back to the cake. If you're buying a cake for a birthday party, you probably don't really care a whole lot about what goes into the cake. You care primarily about the fact that it is a cake. On the other hand, if you are buying this cake for a birthday party where a guest may have some sort of food allergy, the pre-made cake may not be adequate. You may be required to bake the cake yourself in order to avoid the gluten or peanuts or dairy that could potentially make someone ill.
It is really the same way with cloud infrastructure. Yes, you could most likely go out and buy all of the components that you need, assemble them, put them into production, and support the infrastructure yourself. That doesn't necessarily mean that you should. If your goal is to build a simple, well documented, well tested, well supported, easy to manage, high performing cloud infrastructure, then you probably want a VBlock.
In that case, "Don't ask what's in the cake." Instead ask if the cake is the right size, color, and taste. Ask if the cake has the right decorations. Leave the details of what's in the cake up to the baker. That's his job. On the other hand, if the baker can't meet your needs, then go ahead and pre-heat the oven.
As for what cake has to do with anything, it comes down to a conversation with Chad Sakac following a break out session at Varrow madness. Basically, the value of a VBlock is something that many people seem to be having trouble wrapping their heads around. I believe that this is due to their over thinking it or over simplifying it. Chad used the analogy of a cake. If I may extrapolate from that idea for a moment, I would ask if you worry about whether the eggs that were used to bake the cake were free range, fertile, brown, white, large, or extra large. Do you worry about whether the sugar in the cake was brown sugar, cane sugar, or corn syrup? You may or you may not. It really depends on what you intend to get out of the cake. I will return to this idea later.
For now, I'd like to move on to another analogy. This analogy occurred to me while sitting in a training class a couple of months ago. One part of the training went through a white board of the history of the data center from mainframe to open systems to virtualization to cloud. Another part of the training discussed the value of a VBlock. In epiphany, I put the two together.
If you are like me, you very likely have built a PC or server at some time or another. (And likely many more than one.) At any rate, in the late nineties, I felt like the only way to have a PC worth having was to build it myself and hand select all of the components. This meant that I had to choose a case that would support the components that I would be placing in it. I had to find a mother board that was an adequate form factor to fit in the case. It also had to have the appropriate chipset to support the CPU that I wanted to use. Additionally, it had to support the number and type of expansion slots and memory slots that I needed. I then had to find CPUs, RAM, sound cards, video cards, power supplies, NICs, storage controllers, and hard drives. Above that, I also had to select an operating system that would support all of the components. Once all the pieces and parts had been selected, I had to find the appropriate drivers and firmware versions that I wanted to use. Finally, I can build my system.
However, that was where things became painful. All of those components with their varying firmware versions and driver sets might not be quite as compatible as one would desire requiring significant additional work to fine tune the configs and update versions of firmware and drives--often by trial and error--until the entire system would appear to function as desired.
Great. My system is up and running. Now I can go out and get that first application to run. Oh, no. Its not quite compatible with something in the mix. Now I've got to go through the process again. But what happens when I add another application with different requirements or a new driver version comes out and needs to be update? Worse, what happens when something misbehaves and needs troubleshooting? Though I may have support from the individual vendors, they don't necessarily play with each other and are actually most likely to point the finger at each other.
Bottom line....I don't build PC's much anymore. I buy fully supported systems from Acer, Apple, Asus, Dell, HP, Lenovo, etc. They go through the headache of dealing with those issues on a larger scale than I alone could ever do. They see issues repeatedly and can gain from that information. They can customize drivers and configurations to work best for that particular system. They can provide management tools above and beyond any that the individual component manufacturers can provide.
This leaves me with another question for you. Do you build all of your own servers? Most likely not. However, there may be times when you do.
Why? I have the utmost faith that any of you could successfully build a system yourselves. Why do you sometimes build a system and sometimes buy a complete system? Why do you sometimes use off-the-shelf software and sometimes open source? (Although this last question was once one of theology, most businesses today use some degree of both COTS and open source code within their environment.) The answer is really very simple. Sometimes, you don't want to be troubled with assembling it yourself, and sometimes you find that the off-the-shelf product doesn't meet your needs.
This gets back to the cake. If you're buying a cake for a birthday party, you probably don't really care a whole lot about what goes into the cake. You care primarily about the fact that it is a cake. On the other hand, if you are buying this cake for a birthday party where a guest may have some sort of food allergy, the pre-made cake may not be adequate. You may be required to bake the cake yourself in order to avoid the gluten or peanuts or dairy that could potentially make someone ill.
It is really the same way with cloud infrastructure. Yes, you could most likely go out and buy all of the components that you need, assemble them, put them into production, and support the infrastructure yourself. That doesn't necessarily mean that you should. If your goal is to build a simple, well documented, well tested, well supported, easy to manage, high performing cloud infrastructure, then you probably want a VBlock.
In that case, "Don't ask what's in the cake." Instead ask if the cake is the right size, color, and taste. Ask if the cake has the right decorations. Leave the details of what's in the cake up to the baker. That's his job. On the other hand, if the baker can't meet your needs, then go ahead and pre-heat the oven.
Subscribe to:
Posts (Atom)