Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

What is the best way to back up SharePoint without the backup files using up all your enterprise storage?

I am currently backing up SQL weekly(content dbs, config db), and doing site collection backups twice a day, and saving them for 2 weeks. We also backup the 12 hive, the GAC, and the Inetpub folder at the same time, but we let these overwrite the previous one.

This seems ok for now, but as the content grows I don't know if I will be able to afford the space. Is this too much? We've had a few instances where it's really saved us, but I don't know how much longer we'll be able to store this many backups.

What is the best practice considered to be?

share|improve this question
add comment

2 Answers

up vote 16 down vote accepted

Backing up with SQL Server is a good scenario if you know what the limitations are. Essentially, this only works fine with normal content databases.

Backing up the configuration database is possible, but it's not supported to restore it. In case of a disaster, you'll have to build a new farm. This means that detailed documentation is essential. When you have your servers up and running, just create a new web application and attach the restored content databases to it. Make sure you have the exact same version of SharePoint installed too.

You already backup the 12 hive, the GAC and the wss directories in the inetpub folders, so that's a good thing. I usually restore them to another folder and then pick and choose what to actually restore. With proper change management, it should be possible to restore all customizations. Of course you only allow them as solution packages so that's an easy one :-) When you restore the wss directories, you can scan the web.config files to make sure you have all other dependencies installed again.

If you reschedule your SQL backups to run daily full backups, and some incremental log backups you should be covered. If your content databases have a reasonable size (=< 100 GB) it should be relatively easy to restore them when needed. When you use SQL 2008, you'll have the possibility to use backup compression which can make a dramatic difference in storage space used!

To further reduce space used by your backups, consider not backing up your search index and databases. If you have good documentation, you can have this rebuild. Of course this depends on the size of stuff you want to index.

share|improve this answer
add comment

There are some third party tools that I really like for both normal content recovery and for disaster recovery. They have the ability to grab all of the settings, configuration, and content which should make the recovery quicker and easier.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.