The Planet Blog

In Know Thy Backups – Part I, we started discussing the most common strategies of backing up your data, and before we continue that discussion, I should clarify that we’re not talking about hardware configurations like RAID or backup products like Evault and Data Protection Servers. These backup schemes can be executed without spending a dime on additional equipment or resources. While there are best practices and recommendations for making backups and keeping them safe, if your budget is limited, you can protect and preserve your data using one of these schemes on your local workstation or on a secondary drive in your server.

When we looked at the full server and simple incremental backups in our previous post, we noticed a significant limitation: losing a single backup can be catastrophic to restoring data. In the next two schemes, we’ll evaluate solutions that protect us from this vulnerability.

Differential Incremental Backups

A differential scheme requires a full backup reference point and then makes a backup of all changes to the server from that reference point on each subsequent backup. This method requires more storage space than incremental backups but generally doesn’t need as much space as a full backup.

Based on the volume of changes made between the first backup, the reference point and the current backup, differential incremental backups may require additional server resources than an incremental backup. Simple and multi-level incremental backups constantly update the reference point with minimal load, while differential backups update the reference point with a new full backup.

Multi-level Incremental Backups

There’s a more granular and robust backup scheme that is less vulnerable than simple incremental backups and less server-intensive than differential backups: The multi-level incremental backup. Multi-level increments assign a level to each backup and then make a comparison against the last lower-level backup made. Only the changes between the reference point and the current data are saved.

This arrangement allows you to design a backup scheme around your needs and the capabilities of your server, and you can decide how many backups you will need for a full restoration to the latest restore point. You will control the number of backups required for a given restore by determining the number of levels in the system. In the event of a disaster, you need a single backup of each level, and each higher level backup must use the lower level as its reference point.

Choosing Your Backup Scheme

As I said in the beginning of this post, these backup schemes are available to you without the use of an additional server or any expensive backup management software. All of the above are viable options for making your backups; however, not every scheme is perfect for every situation. You should review your requirements and the available resources to determine which scheme best fits your needs.

-Ben

More often than not, server backups are misunderstood. With dozens of hardware options and hundreds of software options, finding the right backup can be intimidating. To assuage some of those fears and clear up a bit of that confusion, let’s go over a few of the most common backup schemes. This list isn’t all-inclusive, and the options presented shouldn’t be mistaken for backup plans. A backup scheme is simply a method of creating backups. A backup plan (or disaster recovery plan) is a scheduled implementation of a backup scheme. As we evaluate each scheme, we’ll look at the requirements, costs and benefits, and by the end of our tour, you can decide which best fits your business.

Before we get too far into the specifics of the different schemes, we should define some fundamental terms that we’ll use throughout the comparison:

• An archive is a set of data that is being preserved
• A reference point is a single archive against which comparisons are made
• A restore point is the most recent working backup

The key question a backup scheme answers is this: “If a server suffers a catastrophic failure, what is needed to resume operations with minimal downtime and data loss?” Again, the backup scheme is not a complete disaster recovery plan — its focus is the restoration of data.

The four basic backup schemes we’ll compare are full-server backups, simple incremental backups, multi-level incremental backups and differential incremental backups. The primary considerations about the method that should be used are the server load generated by the backup process, the backup file size, and the speed with which a backup can be restored.

Full Server Backups

A full server backup is one of the simplest methods for a backup scheme. It takes only a single backup archive to create a restore point, which makes data restoration simple and fast. The drawbacks are the amount of time it takes to make the backup, the load it generates, and the total size of the backup. Each backup scheme we’re comparing uses a full backup of the server.

As we evaluate the other schemes, you’ll note they all start with a full backup as a reference point, and create their own restore points as they move forward.

Simple Incremental Backups

A simple incremental backup attempts to resolve some of the issues with full backups, and it does a good job. With an incremental backup, a single full backup is made that serves as both a restore point and the initial reference point. On subsequent backups, it becomes a little more complex. Instead of making a new full backup when it is updated, this scheme compares the current state of the server against the state of the server as it was in the reference point (the first full backup). If it locates any changes, it backs up those changes and generates a new snapshot of the drive as another reference point. This new reference point is then used for the next incremental backup.

This backup structure means the restore point on a server with this backup will consist of the initial reference point and all subsequent incremental backups that use this reference point. This dependency is the primary weakness in simple incremental backups: All of the backups — from the original reference point to the incremental additions recording changes from the reference point — must be uncorrupted and complete for the backup to fully restore the data. If any backup is missing, corrupt or incomplete, the restoration can’t be completed.

The server load created and storage space required for this type of backup is generally less than what you’ll see in a full backup scheme, especially when there aren’t many differences between the backup point and the reference point. On the other side of the spectrum, if the entire data set changes between backups, the storage requirements and server load will be the same as they were when full backups were being performed.

There are two incremental backup schemes that attempt to address this issue: the differential and the multi-level incremental backup schemes. In Part II of “Know Thy Backups,” we’ll explain the pros and cons of these methods, and you’ll be ready to plan your backup strategy.

-Ben

If you weren’t able to attend the cPanel Conference 2009 last week in Houston, you missed out on a great show. With all the networking events, educational sessions and vendor booths to visit, it was pretty tough to keep up as a participant, so the cPanel team deserves a high-five or two —physical or virtual — for having everything so well prepared.

As you may have heard, I led a session about “Disruptive Technologies: The Road from Disruptive to Sustaining.” Instead of copying the bullet points from my presentation into this blog post, we recorded the whole session on a Flip MinoHD. If you’ve got a little time and you’re interested to hear my take on the effects of the Cloud and Virtualization on hosting, go grab a bag of popcorn, turn up your computer speakers, sit back and enjoy:

I opened the floor for Q&A in the session and for additional follow-up after the session after we ran out of time, so I want to do the same for you: When you watch the video, if you’ve got any questions, please post them in a comment below and I’ll be happy to respond.

-Todd

If you’ve ever been on a tour of The Planet’s data centers, you’ve probably noticed a server segregation of sorts. In one aisle, you see big breadracks of tower servers that resemble desktop computers, and in the next, you find rack-mount servers stacked on top of each other in cabinets. Both form factors can connect to the same Internet with the same speed and performance … and they can even share identical hardware specifications. It may be confusing to see both up and running right next to each other. In fact, as a DC manager, I’m often asked about why we elect to use one over the other. Because the explanation is pretty straightforward, I thought it would be a great topic to cover in my blog debut.

Quite a bit has changed in the way we’ve built data centers over the last four years. When we opened our H2 data center, we only deployed racks of tower servers, and in our newest data center phase, D6 Phase 3, we only provision rack-mount servers. You might assume this shift to imply the complete dominance of rack-mount servers over its tower-chassis relative. Let me suggest that you’d be making an incorrect assumption.

To understand when one form factor may be better than the other, let’s look at the hardware, flexibility, space requirements and costs for each. There are no umbrella claims about rack-mounted and tower servers because each comes in different sizes/variations. Tower servers will generally share the same width, but their heights and depths can vary. Concurrently, rack-mount servers are measured by their heights in “rack units.” The rack-mount server we’ll compare is a 1U – a server that takes up one rack unit of height.

Tower Servers

Hardware/Flexibility: Given the tower server size and layout, it can accommodate a greater number of large components like hard drives, RAID and network cards.
Space Requirements: The benefits of having more space for drives and components come at the cost of taking up more data center space. A breadrack of towers can hold 20 servers, while 30 1U rack-mount servers fill a cabinet less than half the width of the tower racks. There are fewer tower servers in a given square-foot area, so we say that the data center space is less dense. When a data center is dense, it requires more power and more cooling, so a data center with only tower servers will generally require less power and cooling.
Cost: In the early 2000’s, rack-mount servers were nearly twice the price of tower servers, so the use of towers could have been a purely economical decision. Now that the rack-mount equivalent of a tower is available only a few hundred dollars more, a data center’s use of the tower form factor will likely be based on one of the other differentiators.

Rack-Mount Servers

Space Requirements: As we noted, rack-mount servers can be installed more densely in a data center than their tower counterparts. To fit more servers in the same amount of space, the rack-mount servers offer less available interior real estate. Because the server uses less space, it tends to run hotter – the heat emitted from the processor and components is contained in a smaller area – so cooling and air-flow are critically important.
Hardware/Flexibility: A 1U rack-mount server’s decreased real estate often limits the types of components that fit in a given layout and the number of drives that can be installed … it’s not likely that the server above will be employed as a huge network storage repository.
Cost: While the difference in cost between form factors isn’t egregious, the cost of running a data center filled with one or the other is significant. That’s one of the main reasons why you see the focus on efficiency in D6 Phase 3. With more rack-mount servers in a given space, inefficient use of power and cooling means thousands of additional dollars in utility bills.

When it’s all said and done, the form factor of the server you have with The Planet shouldn’t matter to you. You’re connected to the same network, in the same enterprise-class data centers, and you’re getting the same level of service and support regardless of what your server looks like. If you are interested in more the nitty-gritty details from the data center operations side of our business, leave a comment and let me know what you want to see or learn more about, and I’ll do my best to cover it.

-Jon

A month ago, Urvish posted that Orbit 2.0 was live and available for all customers. As we reach the halfway point in the roll-out and transition process, it’s rewarding to look back at all the great feedback we’ve gotten from customers and the improvements we’ve been able to incorporate as a result.

With recommendations touching on everything from design and layout changes to functionality and feature requests, the portal’s social web “2.0″ suffix is well deserved. Comparing the portal release from 30 days ago with the current release is like night and day … or maybe more like dawn and noon. With the hard work of our development team, we’ve been squashing bugs and tweaking the system to be the extremely fast and easily usable resource our customers expect it to be.

That being said, we still want your feedback as we head down the home stretch of this transition. On August 17, we’ll be closing our legacy Orbit 1 and ServerCommand portals, and we want to make sure every one of our customers is comfortable with Orbit 2.0 before we get there.

If you’re a customer and you haven’t had an opportunity to visit https://orbit2.theplanet.com, take a few minutes and click around to get familiar with the new system. Imagine you’ve got to create a new ticket on one of your hardware objects … Is it clear to you how to get to the screen below?

What about if you need to change your credit card? How do you add a new user to your account? Can you check the bandwidth usage on one of your servers?

By clicking through the portal to execute these common tasks, you’re bringing a new set of eyes and a different perspective … and you’ll have great feedback that we want to hear. Are the sections logically laid out? Are additional descriptions or explanations required to make the portal more usable? Do our legacy portals offer better handling of a given task?

If you’ve got any ideas for improvements or you note any inconsistent performance, don’t be bashful in using the “Report Portal Issue” link at the top-right of the header. We want to hear from you so we can make Orbit 2.0 feel like home for you.

-Nadja

Often, developers and administrators come across situations in which the only apparent solutions are overly complex and require significant effort to implement. Most of the time this happens because they don’t know something else – and usually something easier – exists.

This practice was evident in a recent case where a customer didn’t know it was possible to do table joins inside an UPDATE statement.

Here’s an example of a task he was faced with: You have a user table and a user_subscription table; the former contains information about each user, while the latter contains start and end dates for particular subscription products for each user. You want to extend the access period for each user that lives in the UK using product #5.

A common way of tackling this is to create a temporary table and populate it with all of the userIds from the user table that has the country = 'UK' property, then update the subscription table specifying only those userIds in the temporary table:

CREATE TEMPORARY TABLE ukUsers (userId INT(11));
INSERT INTO ukUsers SELECT userId FROM user WHERE country = 'UK';
UPDATE user_subscription 
  SET expireDate = DATE_ADD(expireDate, INTERVAL 3 DAY)
  WHERE userId IN (SELECT * FROM ukUsers) AND productId = 5;

While the code outlined above gets the job done, it could be better written. Let’s see how the SELECT statement could be used to retrieve the user information (i.e. get all UK users with subscription to product #5):

SELECT u.firstName, u.lastName
FROM user u LEFT JOIN user_subscription s USING(userId)
WHERE u.region = 'UK' AND s.productId = 5;

Now, let’s translate the above get into an UPDATE statement:

UPDATE user u LEFT JOIN user_subscription s USING(userId)
SET s.expireDate = DATE_ADD(s.expireDate, INTERVAL 3 DAY)
WHERE u.region = 'UK' AND s.productId = 5;

It’s as simple as that! We no longer need the temporary table, and it saves us a couple of extra SQL commands.

For more information on MySQL UPDATE syntax, visit: http://dev.mysql.com/doc/refman/5.1/en/update.html

-Matthew

After reading our last few posts, you know all about “the cloud” now, right? Well, yes and no. You know about the cloud in a general sense, but when it comes to current applications of the cloud, we need to drill down a little deeper.

The hosting industry is abuzz about cloud computing and cloud storage. Based on some completely fictional research*, 7 out of 10 hosting customers do not differentiate between the two. *The numbers may be fictional, but based on my experience working with customers, the sentiment is entirely true.

Virtualization and Abstraction

Before we get ahead of ourselves, let’s take a quick trip down memory lane … back to the days of virtualization. Why? Because the work put into developing virtualization has been a springboard for cloud technologies – specifically with regard to abstraction, the ability to present computational power and/or storage space without theoretical limits. Through abstraction, a single physical server can be divided into several distinct virtual servers, which function as independent physical servers that have their own dedicated resources.

Cloud computing and cloud storage take the principle of abstraction and tweak it. Instead of taking one physical server and creating several independent virtual servers, the development of the cloud takes multiple physical servers and creates virtual servers that freely move between physical machines as though they were all a single server. Naturally, that’s attractive to a hosting customer.

Cloud Computing

Cloud computing allows access to theoretically limitless computational resources. A user can scale from one Web server and one database server, to five Web servers and three database servers on the fly, with no upfront capital expenditure. Cloud computing essentially makes one large virtualized server that spans the entire available hardware infrastructure. Instead of having 20 servers with 4GHz of processor power each, the cloud shows 80GHz of processor power.

Cloud computing customers purchase a part of that cloud computing platform, and if no other customers are using resources on a given installation, that customer has the can use all 80GHz of process power one minute and scale back to almost nothing the next minute. The technology is in its infancy, but it’s helping to redefine the concept of a server: It’s not a black-and-white matter of physical resources anymore.

While the hardware abstraction is impressive, the greatest potential benefit of cloud computing is its use in Software as a Service (SaaS). It’s revolutionary to have an office application that scales from 10 users to 10,000 users and also available to anyone or any device with a network connection.

Cloud Storage

Cloud storage can be an amalgam of SaaS and HaaS (Hardware as a Service): Straightforward user interfaces combined with a solid hardware storage infrastructure. Because a cloud storage installation is dedicated to access, protection and serving data, the key component is hard disk space. Being able to pay for the space that meets your specific needs at a given time has significant advantages over a traditional solution like building out a storage area network in your local office. Your storage can be available to all of your satellite offices in London, Asmara and Santiago. Moreover, your company isn’t responsible for repairing file systems, replacing drives, or dealing with Nick Burns (your company’s computer guy). Brilliant!

We’ve launched a very successful cloud storage solution, and if you’re interested in seeing what the cloud can do for you, you can sign up for our Storage Cloud Test. On the cloud computing side, our team has been evaluating the most powerful, reliable and cost-efficient cloud computing solutions, and we plan on launching a computing platform as dominant as the storage platform in the near future.

Cloud computing and cloud storage have come a long way in the past year or two, and with the hosting industry’s focus on the development and enhancement of the platforms, the sky is the limit for the clouds.

Pun intended.

- Chris