A Small SharePoint Backup Beats Big SharePoint Backup: Boot Camp Week 5

A Small SharePoint Backup Beats Big SharePoint Backup: Boot Camp Week 5

A Small SharePoint Backup Beats Big SharePoint Backup: Boot Camp Week 5

By Paul LaPorte | September 25, 2015

A David and Goliath Backup Story: Why You Want Small SharePoint Backups

Sometimes it’s good to be the big guy. People look up to you, amazed at how big you are. You always get picked first for sports teams. The view is much better. However, if you happen to be a backup file, bigger is definitely not better. You get little love. Administrators tolerate you at best and avoid you at worst. And when you are called to recover against a small backup, you lose every time.

No one wants to be the Goliath of the backup world. Large backups take too long to capture, mount, and depending on storage location, retrieve prior to mounting. With content growing at 50-75% annually, it is unrealistic to look toward eliminating content as a way to shrink backups. That means backup times grow 50-75% per year. Backups typically encompass all content. The only way to perform well in this game is to go on a diet. So, how do you go on a backup diet? Glad you asked.

There is a way to move large portions of content out of the traditional backup flow and into a real-time backup environment. Using Remote BLOB Storage, you can move up to 95% of your SharePoint content out of SQL Server using a process known as externalization. This approach results in a backup footprint that is an order of magnitude smaller leading to very fast backups with more frequent backup opportunities. For more information on BLOB externalization, download my recent eBook: Shattering SharePoint Storage Limitations

How do backups get so big and why is this bad? Backups are designed to protect you. The longer a backup takes, the less frequently you take them. The frequency of backups, whether full or partial, directly correlates to potential data loss. Less frequent backups mean greater potential data loss. Often, data loss tolerance is expressed in terms of a Recovery Point Objective (RPO), the maximum tolerable amount of data loss expressed as a period of time. As backups get bigger and take longer, you can no longer meet your company’s RPO. Smaller backups frequently make the difference between RPO success and failure. For more on RPOs, read my Week 3 Boot Camp blog.

Once you take a backup, it gets stored for potential future use. In the event you need the backup file or files, you will eventually need to mount those files. Typical activities range from an operational recovery activity, such as performing a granular item restore, to far more dire Disaster Recovery scenarios where you are recovering an entire farm. Traditional file mounting takes time. The larger the file, the longer the time for the mount process to complete. The time to recover, including the mount, is referred to as the recovery time. This is frequently measured against another key performance metric, the Recovery Time Objective (RTO). Smaller backups mount faster, allowing you to meet or exceed your RTO.

Backup options are growing as we start to leverage the cloud. Cheaper offsite storage becomes a new option. Depending on your goals, this can be an attractive option. It provides geo-diversity for improved Disaster Recovery capabilities. It also allows you to store years’ worth of backup files to adhere to regulatory or compliance needs. However, cloud storage is not a panacea. It takes substantial time to move large files around to and from the web. There are many frequent bottlenecks in speed to address. This becomes most acute when it is time for a recovery. You must factor in the time it takes to move all the required files from a cloud storage provider to your recovery location. Something that took hours can now take days. Do your homework before taking the cloud backup plunge to ensure recovery needs are factored in as much as cost savings.

If shrinking the size of your backup is important to improve performance and recovery times, then put your Goliath backup on a diet by moving BLOBs out of your SQL Server to create a lean, high performing backup.

Leave a Comment

Add new comment

Paul LaPorte

To find out more about Paul, please check his linkedin page.

Written By: Paul LaPorte