REVIEW: Carbonite Online Backup

One of the challenges of constantly traveling is ensuring that all of my data is continuously backed up.  Having lost data as a result of either a hardware or software failure, I know I need a backup, but I could never find a good solution. Enter Carbonite.

I happened upon Carbonite about four months ago.  Essentially, they offer an online backup of your machine (Windows only).  For $49/year, they will allow you to backup an unlimited amount of data.  When you sign-up for the service, they require a small agent download and install.  The agent constantly monitors various folders/files on your machine to determine whether they've changed; if they have, it starts copying the file to your online backup.  By default, Carbonite will backup all of your personal files -- on XP, this means anything in your Documents and Settings directory.  In Vista, this would include anything in your Users directory.  If you want to add other directories/files, just right click on the file or directory and pick Carbonite from the context menu and then "Back this up."  With virtually the same operation, you can also exclude certain files.

In addition, Carbonite surfaces in your "My Computer" as another drive.  Double clicking on the icon will show you what's been backed up.  It's presented as an Explorer-like interface, making finding a file pretty easy.

In my own experience, I ended up backing up about 32 Gb of data.  The complete backup took a number of days to complete.  However, Carbonite indicates a particular file's backup status by placing a small "button" on each file -- if the button is yellow, the file is in need of backing up.  If the button is green, the current version of that file is backed up.  You can also look at the Carbonite agent status in your system tray -- green indicates all files are backed up and yellow indicates that certain files require backup.

While backup is one thing, the restoration is entirely a different matter.  I also recently had the opportunity to test the service.  Not being completely trusting, I backed my files to a USB drive prior to wiping out my machine.  I then reloaded by then XP laptop with Vista, reloaded the Carbonite agent and told the agent to start a restore. 

Within a day I had most of my important files back.  That said, it's been about a week since I started the restoration and Carbonite still reports that I have quite a few files left to restore.  In truth, I'm not precisely sure what is missing, but I suspect it's my extensive (legal) music collection, since all of my documents have been restored.  Looking at the restore status in Carbonite has largely confirmed my theory.

My Observations:

• While backups certainly can happen over a longer period of time, waiting a week (or more) to get all of your files restored is unreasonable.  Granted, I've not been connected to a high-speed connection the entire time.  However, I have had 1 Mb or better connectivity for the better part of four days during week.  I'm not sure if the slowness is simply a function of available bandwidth or how Carbonite prioritizes its use of your bandwidth; throttling bandwidth usage for normal backups is expected, but I would think it would want to consume as much bandwidth as possible for the restoration.
• I've recently started using the service on a server.  I'm not backing up a ton of data, but the fact that the files are "instantly" offsite is somewhat comforting.  Because there isn't a lot of data AND the server will have a dedicated connection with loads of bandwidth, my guess is that any restore should be pretty snappy.
• I have tried contacting support regarding my restore speed.  It's been two days and so far I've not heard back.  Their web site did state that they were dealing with "higher-than-normal" volume.  Not sure what that means for them, but I'm growing a bit impatient.

My Verdict:

• For basic backups of your files, I've been pretty happy with the service.  For $49/year, you can't beat the price, especially since you're allowed unlimited space.
• Now knowing restores take so long, you may consider just using Carbonite for selected files.  If you have  high-speed connection, the restore should be O.K.  My bread and butter files were restored pretty quick (desktop and documents).

If this service sounds interesting to you, check out Carbonite's web site.  (NOTE: the link is a "refer a friend link")

Simple SharePoint Backup Routine

Like many of our clients, Consejo uses SharePoint to collaborate -- both with our clients and amongst our employees.  As a result, it has become a critical service to maintain -- thereby making it critical from a business continuity planning perspective as well. 

Recently a number of clients have all asked the same question:  how can we easily create backups of our SharePoint sites so that we can restore them in the event of a disaster?  While there are some good backup options built into SharePoint and some commercial vendors like AvePoint that provide backup and restore solutions, there are some relatively simply approaches that will provide baseline protection in the event of a disaster.

To begin, you should really read this post from Microsoft's SharePoint Developer Documentation Team blog on the various backup mechanisms and elements that need to be protected.  The blog entry does a great job of highlighting all of the moving parts, but doesn't provide a straightforward approach to getting the basics.  What we've tried to do, below, is provide you with an easy mechanism to automate and schedule backing up SharePoint site collections.  These backups can easily be restored in the event of a disaster.   To be clear, this approach is kind of the sledge hammer approach for site collections only and may not be right for the needs of individual sites.  However, this represents the very least you should have in place for your SharePoint environment.

NOTE:  The backup process described will backup only the site collections specified in the backup routine.  As the Microsoft article suggests, there are a lot of other parts to a SharePoint environment.   When designing your complete disaster recovery/business continuity plan, please ensure you have all of your bases covered.

Identifying the Site Collections

Depending on the type of SharePoint environment you have, your complete SharePoint environment will have one or more site collections.  When using the approach illustrated in this post, you must backup each site collection separately (or include them in a single job).  In any event, you should inventory the various site collections you want included in the backup routine.  If you're unsure what collections exist, you can look them up in the Central Administration tool by going to the Applications tab and clicking on the Site Collection List option under the SharePoint Site Management category (show in figure 1-1).

Figure 1-1 The site collection list for a given SharePoint application

If the site collections that appear aren't what you expect, make sure that you've selected the right web application, using the drop down list just above and to the right of the site collection list.

If you have found the right set of collections, take note of all the ones that are important to include in your backup routine.  You'll need the URLs to each of the collections.  Because you can have multiple collections off of the same web application, SharePoint may only show a relatively URLs; make sure that you know the full-qualified URL for this backup process.

Creating and Automating the Process

To create some basic automation and logging, we're going to create a CMD file that contains all of the commands necessary to use the STSADM command-line utility to backup one or more site collections and add some basic logging to a text file.

CMD code

The code in the CMD file should contain at least the following:

@echo off
echo --------------------------------------------------------------------- >> SharePoint_backup.log
echo SharePoint Backup Began >> SharePoint_backup.log
date /t  >> sharepoint_backup.log
time /t >> sharepoint_backup.log
"c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm" -o backup -url [URL TO YOUR SITE COLLECTION] -filename [PATH TO BACKUP FILE] -overwrite >> sharepoint_backup.log
if errorlevel 0 goto finish_backup
:error
echo An error has occured and the backup did not complete properly >> sharepoint_backup.log
goto end
:finish_backup
echo The backup completed successfully >> sharepoint_backup.log
:end
echo SharePoint Backup Finished >> sharepoint_backup.log
date /t >> sharepoint_backup.log
time /t >> sharepoint_backup.log

Keep in mind that the code contains bracketed text (like [URL]).  This bracket text should be replaced with settings specific to your environment, like the URL to your site collection or the path to your backup file.

Once you've made the modifications to your specific site, save the file to a directory on your SharePoint server; keep in mind that the log file will be written to the same directory and will collect entries over time.

Before proceeding, I would recommend testing your finalized CMD file to ensure it operates as you expect.  Once it does, proceed to the next step.

Scheduling the CMD File

There are a number of ways to schedule a process to run on a server, but Windows has a built-in scheduling system that you can use for this purpose.  The service is the Windows Scheduled Tasks.  A scheduled task can be created and run on a specific period and within the context of a given user.  To create the backup scheduled task, using the following instructions:

1. Open up the Windows Control Panel
2. Click on Scheduled Tasks
3. Click on Add New Task
4. The Scheduled Task Wizard appears
   
   
   
5. Click Next
   
   
   
6. Click on the browse button and locate the CMD file you created earlier
7. Now name the task and choose the schedule as shown below
   
   
   
   
8. Click Next
9. Enter the credentials for the user that the system will use to run the task.  In this example, we're using the Administrator account, but you should choose a user with the minimum privileges necessary to complete the backup.   Keep in mind that the user must have access to both the SharePoint site collections and the file system.
   
   
10. Once you click next, the final confirmation dialog will appear; simply click Finish to schedule the job.

To confirm that the job runs as expected, you can reopen the Scheduled Tasks option in the control panel and right click on the new job.  From the context menu, pick RUN.

After you have your job scheduled, your SharePoint site collection(s) will be backed up every time the job runs.  I would recommend at least once every 24 hours.

NOTES:

1. When I developed this routine, I made the assumption that you will get a full backup on the specified site collections every time the job runs.
   
2. The backup files are overwritten every time the job runs, so if you want historical backups, you'll need to develop some process for making a copy of the resulting backup file elsewhere.  Ideally, you could move the backup file to tape or another file system once the SharePoint backup is complete.
   
3. This backup process will backup all of the data and the security settings.  In the event of a disaster, the security context may not be the same when the site is restored.  For example, the domain used by SharePoint may change in the new environment.  As a result, you'll have to set the owner of the site through Central Administration to the new user ID who will control the site.  Then, you must grant the appropriate users in the new domain access to the SharePoint site collection.  This can get complicated if you use a lot of item or container-level security (e.g. sites within a collection or lists/libraries within a site don't use inherited permissions).
   
4. The text file that holds the log entries can fill up quickly over time.  Make sure someone is reviewing that file periodically to ensure it does get too big AND that the backups are completing successfully.

I'd love to hear your feedback on this approach and/or whether this was helpful to you.