Central Administration -> Operations -> Perform a Backup
Backup a site collection:
stsadm –o backup –url
Restore to a site collection:
stsadm –o restore –url
you can not backup or resore a single site using above command.
Backup a single site
stsadm –o export –url
Restore a single site
stsadm –o import –url
export/import may miss some functionality.. so double check.
This is probably the approach you will end up using most often. SharePoint stores all its data in SQL Server. Also, a site, or site collection, is nothing but data. Thus it is reasonable to assume that this data, can be easily backed up and restored using standard SQL Server mechanisms.
SharePoint stores its data in content databases. A single website can have a number of content databases, and a content database can contain one or more site collections. In other words, you cannot scope a content database to a single site or single list level.
You can view all the content databases associated with a given web application under central administration à Application Management à SharePoint Web Application Managementà Content Databases. This can be seen as below:
From this screen, you can add or remove content databases to a given web site. When you add a content database, you have the facility of specifying a database server and a content database name. If the database already exists on the server, it will be used as is. If in case the database does not exist on the server, it will be created for you by the farm account.
You can use this behavior to your advantage to backup restore web sites. In order to backup a web site, you simply backup all the content databases associated with the web application. In order to restore a website, you restore the content databases, and perform the extra step of specifying new site collection administrators in the new environment.
This is a fairly robust mechanism of backing up and restoring your SharePoint environment and I suspect that in any serious installation, this is what you will end up using the most anyway. This by far, however is not enough. Depending upon the specific needs of your SharePoint environment, also want to invest in the following:
Backup the entire 12 hive (c:\program files\common files\microsoft shared\web server extensions\12). This is because, frequently you will deploy code to your SharePoint farm, and you will need to restore the supporting physical files for the site to work properly.
You need to keep monitoring the size of your content databases. If you start hitting the 50GB mark, think of splitting them up, so the backups are done overnight before users start hitting the database in the morning.
Backup the entire INETPUB directory.
4. Always maintain a path to restore the current state of the production environment as various releases are pushed into production. This can be achieved by following the below recommendations:
a. Always use a scripted deployment process with clear instructions for deploying code to production. Give special attention to ensuring releases capable of taking your SharePoint installation from one version to another. With various releases, your scripts and instructions should be capable of taking a fresh SharePoint installation to the current production state.
b. Always deploy custom code as solutions, not fragile xcopy scripts.
c. Backup source control databases, and establish a strong version control policy for all code that goes into production.
d. Document all customizations and administration done under central administration for every release.
e. Follow standard disaster recovery best practices, such as regular and verified backups, off-site storage etc.
f. Backup Shared Service providers and Central Administration using stsadm after every significant configuration change or production release.
Backing up shared service providers
You can backup and restore an SSP in a mechanism similar to restoring any other SharePoint website. You must however perform the additional step of associating the SSP with the appropriate web applications after such a restore has been performed. This may be achieved using the following steps.
Under central administration, click on the “Shared Services Administration” on the left side of the page.
Once on the “Manage this farms shared services” page, click on “Restore SSP”.
Now assuming that you have already restored the SSP on a site, complete the required fields on the page shown. Just make sure that you specify the restored web application and database that the SSP site has already been restored to.
Backing up search
Search is probably the weirdest portion to backup on a SharePoint installation. First of all, given the additional complexity that backing up search requires, it might be a good idea to go with rebuilding the indexes for small or even medium sized farms. However, if your search database is huge, and your farm is quite big, and you need search to be online shortly after a disaster, you will need to look into an appropriate strategy for backing up search.
The reason backing up search is different than other portions of SharePoint, is because of how search works. Search data is stored in two locations, the search database, and the index files on the disk. You need both in order to be able to successfully serve search queries. Not only both, but you need both of them backed up concurrently for the restored versions to work together. In other words, if the search index was backed up 5 minutes after the search database, the index entries created in the additional 5 minutes will cause inconsistent results in the restored search.
In order to ensure this consistency, you should backup search using SharePoint 2007’s backup tool, or a third party product.