Hosting Partners  |  About Us  |  Blog  |  Legal  |  Portal Login

The Planet Blog

 

Kevin HazardA few weeks ago, I received an interesting email. The sender claimed to be from CNN, and he wanted to chat about The Planet’s #showmemyserver experiment. Before I filtered the seemingly surreal opportunity into a folder typically reserved for emails that say, “Dear Sir, I will send you $1million dollars if you send me $25.93 for postage,” I did a little snooping around. To my very pleasant surprise, this John D. Sutter guy is not only a real person, he actually writes and produces for CNN!

We exchanged a few phone calls, and I learned that he spoke with Rich Miller at Data Center Knowledge for a CNN Tech article about “The Cloud.” As they discussed the mechanics of the cloud in terms of data centers and servers, Rich pointed out the juxtaposition of this hyped demand of virtualized products with an old-school desire to have the data in a visible, tangible location. Enter The Planet’s #showmemyserver project.

John was very interested in our take on the social media experiment’s success, so it was great to share a little of what we heard from our customers … and we were even able put him in touch with Nate Tallman at HealthTeacher.com to give him a direct customer perspective. Thanks for your help, Nate!

Long story short: John posts A trip into the secret, online ‘cloud’ to quite a bit of fanfare … which isn’t surprising, given its great introductory video:

From the heart of that article, he links to a “Behind the Scenes” blog about The world of ’server huggers’ and investigates his subconscious desire to find the “real” location of his digital data. As any customer who visits one of our data centers can attest, he’s not alone.

If you’re interested in “hugging” your server, stay tuned to The Planet Blog over the next few weeks, and keep your keyboard at the ready. We’ll offer another opportunity just in time for the holidays. :-)

-Kevin

Kevin HazardAt the 2009 Cloud Computing Conference in Santa Clara, Calif., The Planet Director of Product Management Rob Walters was one of five experts invited to participate in a panel discussion about enterprise-level cloud computing – whether it’s a far-off dream or a present-day reality. Conference Chair Jeremy Geelan covered everything from whether the term “cloud” was too broad to be useful to whether private clouds and public clouds can coexist.

I caught up with Rob in the expo hall to have him weigh in on each of the questions for our loyal blog readers (you!):

I love the analogy he uses to explain why “the cloud” is such a difficult concept to explain. It seems to be a paradigm shift unlike any we’ve seen in recent memory, so the transition from hype and confusion to understanding and adoption should prove to be an interesting adventure over the next few years.

One of the most interesting questions asked of the panel was whether or not we’d be talking about cloud computing in 10 years. The unanimous answer: No. Why? The resounding sentiment is that shift toward “the cloud” will be so pervasive that a given platform’s “cloudiness” will be implied. This opinion is shared by a group of experts at a “cloud computing conference,” so there may be a little bias here … What do you think? Will the cloud take over and become the de facto standard or will demand for traditional IT remain in the midst of the cloud’s surge?

-Kevin

Kevin HazardSince Halloween falls on a Saturday this year, The Planet’s annual Boo Bash is happening today. As you can see from our archives, there are a lot of creative people around here, and when a costume contest challenge is issued, you’re bound to get some interesting results. I’ve already seen a fully costumed Ghostbuster, a bumble bee, and about 45 people – including our CEO and CFO – dressed as Todd Mitchell. They say imitation is the sincerest form of flattery, so Todd must feel VERY flattered.

We will post our costumed competitors on The Planet Flickr for all to see, and you can post a comment here to vote for your favorites. Click the picture of “Todd” below to go directly to the Boo Bash 2009 album.

Todd Mitchell

To let you share in today’s costuming, we’ve got a present for you. As a part of our fundraising efforts to support the American Heart Association, we printed shirts for employees who donate. The shirt design has been so popular internally that I made it into a few wallpapers that you can use:

You Got Served

Versions Available:
Dual-Monitor Setup (2560 x 1024)
Single Monitor – Server Only (1280 x 1024)
Single Monitor – “You Got Served” Only (1280 x 1024)

After you get your desktop suited up in its new costume, remember to vote for your favorite Boo Bash 2009 entrant in the comment section below.

Trick or Treat!

-Kevin

Ben KeenerIn 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.

Example: Differential Incremental Backups

As in the previous example, I am using a schedule of backups that starts with a full backup on Sunday, with additional backups on the following days. This time, I’m using differentials. Let’s say that on Thursday I find some inconsistencies in the database when compared to the paper files I received from a vendor. After investigating, I find that my database is corrupted. I determine that I will not be able to recover the database as it is, so I review my backups.

Somehow, I cracked the DVD that my Tuesday backup was stored on, but all of the other discs are here. I start by restoring the Sunday backup and then the Wednesday backup, hoping the corruption occurred after the backup was made. Thankfully, the restoration works, and we are up and running again after losing minimal data. If I had been using simple incremental backups, I would have been able to restore only up to Monday because Tuesday’s backup disc was broken.

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.

Example: Multi-Level Incremental Backups

This time I am in charge of a Sendmail server that is always under heavy stress. Because this server is extremely important to my business, I need to ensure both its availability and responsiveness at all times. I also need to maintain archives of the e-mail on the server. To do this, I decide to implement a multi-level incremental backup scheme since I need more granular backup configuration that does not generate a great deal of load on the server. This scheme meets that need. It still retains the weakness of incremental backups, but I partially mitigate those weaknesses with scheduling.

At the first of every month, a full backup is scheduled. This is my Level 0 backup, and it is named level0.name of the month. The following day I run a Level 1 backup. This backup holds only the changes since the most recent Level 0 copy called level1.first.name of the month. The subsequent days of that week, I create a Level 2 backup called level2.first.day of the week.name of the month. This process continues until the Sunday after the first Level 2 backup.

On the next Sunday, I make another Level 1 backup called level1.second.name of the month. The subsequent days of that week, I make Level 2 backups called level2.second.day of the week.name of the month. I continue in this vein with every Sunday being a Level 1 backup and the rest of the week being Level 2 backups until the end of the month. On the first day of the next month, I start all over with another Level 0 copy.

I make certain to save multiple copies of the files after I test the archive. I also check to be certain it’s not corrupted, to minimize the risk of data loss through a faulty archive. This scheme allows me to restore to any point within the month in just three steps, as long as all of the archived backups work.

If I need to restore the data from April 17, 2009, I would need the archives for level0.april, level1.third.april, and level2.friday.third.april. I would restore them in sequence from Level 0 to Level 1 to Level 2.

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

Ben KeenerMore 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.

Example: Simple Incremental Backups

I am implementing incremental backups for a database that houses all of my users’ data. I decide I am going to start with a full backup each Sunday — the slowest day of the week for the database — and do an incremental backup on each subsequent day. This process starts over again every Sunday. On Friday, my server suffers a catastrophic hard drive failure. I am told by the technician who replaced the drive that the controller failed, and the heads were idly tapping the side of the drive cage. Everything on the drive is lost.

I gather my backups and begin to restore them on the new replacement drive. The backups from Sunday, Monday and Tuesday restore without a hitch, but Wednesday’s backup is corrupted and will not complete. This means I have lost all of the data from Wednesday and Thursday. Without Wednesday’s backup, the rest of my incremental backups are useless.

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

Todd MitchellIf 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:

Get the Flash Player to see the wordTube Media Player.

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

Kevin HazardAs an avid reader of The Planet Blog, you’ve probably noticed some consistency in the 164 articles published here since Doug’s inaugural “Welcome to The Planet’s blog… I think?” post on May 14, 2007. We focus on our company culture, support, data centers and network to help you step through the looking glass and get an inside perspective on our business. With a continuous stream of changes and improvements, it’s tough to feature even a fraction of the work our team is doing to improve our service, so we keep an eye out for opportunities to “show” what we’ve “told” you about in the past. This is one of those opportunities.

On September 2, 2008, we announced the results of our lights-out energy efficiency initiative. A few days ago, I was sorting through a batch of data center pictures, and I came across a few great examples of what this news looks like in practice:

The Planet Lights Out Program

This is Phase Two of our H1 data center. With all the posts you see from H2 and D6, you might be curious about what our other data centers look like, so hopefully the picture above doesn’t surprise you. We have extremely high standards for our data centers, and you should expect the same enterprise-level quality across the board.

If you took a guided tour through H1, you’d see it all lit up as it is above. If you walked in during a normal DC shift, you’d probably find it a little different:

The Planet Lights Out Program

When the data center is unoccupied, the lights are switched off to save energy. How much energy? Well, across the board, we estimate the program saves more than 1.4 million kilowatt hours in a given year – or about $140,000 in power bills. It’s no small change.

As you’ve seen in our other posts about data center innovation and operational efficiency, we take a common-sense approach to energy conservation. It’s incredible to see the significant impact such simple changes can make.

It’s also pretty cool to see servers glowing in the dark:

The Planet Lights Out Program

-Kevin

 
 
 
 

Dedicated Servers

Managed Hosting

Colocation

Business Solutions

Why The Planet?

Contact Us