More statistics on the backup process. More information is provided about overall disk space usage, status, and errors.
How to use Microsoft SharePoint Server 2007 backup tool
One
of the splendid facial appearance of the SharePoint Backup tool is the
ability to better control what you are backing up. Next image shows the
interface for selecting which SharePoint components you wish to back up.
Each component is associated with a SharePoint database (and ultimately
specific SharePoint content) or data collection. It is possible to select an entire farm or party components for backup.
NOTE: To
perform a backup, you need to be an administrator on the farm. To run
restore, you need to be a Farm Admin and a box admin on the front-end
machines.
Another
fascinating feature of SharePoint backups is the collection of backup
history. SharePoint really differentiates between full and incremental
backups. This is done by examining the backup files on the file system
(discussed later in this chapter) and identifying new content.
A full backup backs up the elected content with all the history. Specifically, a full backup
backs up the entire database, including all file groups and data files,
providing a high degree of data integrity. The downside is that full
backups can take a long time for large
data stores. We recommend keeping your content databases to a
reasonable size (under 100GB) so that backups take a reasonable time.
A
differential backup backs up all changes to the elected content since
the last backup (either full or differential). This option allows IT
administrators to better manage disk space associated with SharePoint
backup files. In addendum, the backups are quicker. The key issue with
differential backups is that a restore requires the administrator to
restore the last full backup in addendum to the differential backups that have taken house.
Given the choice, which should you use? The thought is to use a combination of the two as follows: Start with a full backup of your data. Then perform a daily differential backup of all databases all through offline hours. Next, perform a full backup
of all databases on a weekly basis. Finally, perform a full restore (to
an offline data source such as a mirror server or disk) of your backup
set roughly once per month. This lets you validate that your backup
procedures are working correctly.
Next
image shows the Start Backup page. You must state a location for the
SharePoint backup files. The Backup utility accepts only UNC file paths,
and permissions on the folder must be sufficient to allow SharePoint
Backup (running under the credentials of the logged-in user) to write
files to that folder.
Once completed, the Backup
tool provides diagnostic details on the backup files made and any errors
that may have occurred. As expected, the elapsed time associated with
the backup process is proportional to the amount of data being backed
up. A standard portal should doubtless take a few minutes to make all
associated files. Next screenshot shows a completed backup process.
Diagnostic data includes status, elapsed time, file directory path, and
associated error messages.
NOTE: It’s recommended that you use a remote file share to store your SharePoint backups. Do the following:
Timer
Service account. If sptimerv3 is running as a “network service
account,” add the WSS front-end machine, such as DomainWSSserver$ (UI).
How to Manage Microsoft SharePoint Server 2007 backup files
When the SharePoint backup
completes, the corresponding backup files are placed on the file system
in the designated path. If you’re traditional with SharePoint Portal
Data Backup and Restore, you’ll notice that the collection of files is
very different. Next image shows an example backup file collection.
There are two main pieces. One is the spbrtoc.xml (SharePoint Backup
Restore Table of Contents) file. The other is the folder that contains
all the backup data for that particular backup.
Let’s take a closer look at
how SharePoint manages the backup data. First, image shows the contents
of the spbrtoc.xml file. You’ll notice that the information maps very
closely to the diagnostics shown at the conclusion of the backup
process.
More fascinating are the
real contents of the backup folder. Next image shows the files
associated with a full farm backup. Again, for SharePoint Portal Server
2003 users, notice that the backup files no longer map to the specific
SQL Server databases. The backup files (file additional room .bak) are
segmented across a collection of files. A log file, spbackup.log, gives
details on the executed backup process. All of this is managed by
another xml file, spbackup.xml.
The spbackup.xml file
contains all the parameters and attributes needed to perform SharePoint
backup and restore actions. Next image shows a sample xml file. The top
section, SPGlobalInformation, contains data on the executed backup. It
maps very closely to the data stored in the top-level xml file. The
subsequent nodes under SPBackupNode map to specific components elected
using the Backup interface. This file provides a road map for the the
makings restore of SharePoint data. Notice that unlike the manifest file
used in the previous version of SharePoint Portal Server, this xml file
contains no specific references to portal URLs or database servers.
This makes it simpler to use these files, unaltered, to restore
SharePoint on different servers.
WARNING: Do not
modify the spbackup.xml file. Doing so can corrupt your backup and/or
your restored farm in an unrecoverable manner.
How to use Microsoft SharePoint Server 2007 restore utility
Before delving into the
restoration process, it is vital to note that one underlying assumption
is involved with SharePoint restores: the authentication mode (that is,
Active Directory or another LDAP source) is the same. This is less
critical for restorations in an existing SharePoint environment but may
impact the recreation on new servers.
WARNING: SharePoint
maintains its security model (users, roles, access) in its databases.
Therefore, this security model is maintained in the restoration. But, if
you restore the portal to a machine that does not have access to the
same authentication engine (a specific Active Directory domain, for
example) the security rules previously defined are no longer valid. This
scenario is most commonly seen in the restoration of a SharePoint
environment onto a development server. It is vital to ensure that the
restoration environment has
access to the same authentication engine as
the backup environment.
As previously mentioned,
SharePoint maintains version history associated with backup activity.
This offers two immediate benefits: more flexibility for the IT staff in
terms of controlling what components of SharePoint to restore, and
better management of disk storage space in terms of the amount of space
used. Next screenshot shows a sample Backup and Restore History screen.
NOTE: The
information contained in the xml files previously discussed is shown on
the interface to clearly identify the type of backups registered and
the associated attributes. SharePoint manages a perfect collection of
historical files associated with backups. This feature allows on-demand
restoration of potentially corrupt or disabled components (a requirement
for any plot for high availability).
As
mentioned previously, to successfully do a SharePoint restore, the user
must have Administrator privileges surrounded by SharePoint and have
access to the files on the file system.
The
SharePoint restoration process is very straightforward and consists of
two steps. The first, shown in first image, is to select the location of
the SharePoint backup files. The second, shown in screenshot, is the
selection of a specific SharePoint backup from the collection in
history. In Step 3, you are questioned which components you wish to
restore (see third map from below). You can change some of the
configuration details in Step 4 (see last image). Once a backup
collection has been elected, the restoration starts the moment Start
Restore Process is clicked. The timing of the restoration is directly
related to the elapsed time all through the backup process. Expect a
typical full farm restore to take several minutes. Once perfect, the
restoration will have updated the appropriate SharePoint components with
the specific content elected.
NOTE: What’s
the difference between “New” and “Overwrite” on the Restore Page? Use
“new” when migrating to a different farm or restoring such that you want
to refer to a new machine or new database. Use “overwrite” when you are
restoring on the machines and databases that the original farm backup
refers to. “Overwrite” is used for the catastrophic restore scenario and
does not give you the option to use a different machine or database
name.
NOTE: If a
backup or restore fails, you can get details on why the operation
failed in spbackup.log (for backups) or sprestore.log (for a restore) in
the backup location. If errors occur all through the backup/restore
process, you have to delete the failed Backup/Restore Timer Job before
you can run the next backup/restore process. You can delete the job from
http:/// _admin/ServiceJobDefinitions.aspx.
How to Schedule a Microsoft SharePoint Server 2007 backup
One of the things you’ll
notice on the Backup and Restore pages is that there is no tool for
scheduling backups. Much like SharePoint Portal Server 2003, there is no
scheduling component in Office SharePoint Server 2007. This presents a
problem for IT staff interested in ensuring that SharePoint backups are
regularly obtained. As in the previous version, the best alternative is
to use a simple batch file that executes the SharePoint backup from the
command line. This batch file can then be scheduled using the native
Windows Task Scheduler. We’ll chat about the command-line backup options
in the next section.
Command-Line Backup Tools
The
stsadm.exe utility is doubtless traditional to users of WSS 2.0. It
enables SharePoint administrators to back up site collections using the
command line. This makes it simple to restore a site collection (or a
single site) if necessary.
stsadm.exe
still exists in WSS 3.0 and has been enhanced for Office SharePoint
Server 2007. You can still use stsadm to back up a site collection as
follows:
stsadm.exe -o backup
-url <url>
-filename <filename>
[-overwrite]
For example, if I want to back up my site collection that exists at http://myserver/sites/, I would issue the following command:
stsadm –o backup –url http://myserver/sites -filename c:mybackups
In
addendum, the stsadm.exe utility now lets you do a full SharePoint back
up as you would with the Central Administration page (the command-line
help text calls this the “catastrophic backup”). To issue a full or
differential backup using the command line rather than the Web UI,
simply use the following format:
stsadm.exe -o backup
-directory <UNC path>
-backupmethod <full | differential>
[-item <made path from tree>]
[-percentage <integer between 1 and 100>]
[-backupthreads <integer between 1 and 10>]
[-showtree]
[-silent]
For example, to back up my entire SharePoint farm, I could issue the following command:
stsadm -o backup -directory backupssharepoint
-backupmethod full
This
would perform a full backup on my SharePoint farm and write to the
Backup and Restore History on the Central Administration page. Then I
could use either the command line or the Central Administration UI to
restore from this backup. Backups done via the Web UI or the command
line are indistinguishable.
Using
the stsadm utility is very helpful for regular backups because you can
use the Windows Task Scheduler to make a recurring backup job.
Two-Stage Recycle Bin
Needing to recover a single
item is a more commonplace situation than having to recover from a
full-fledged disaster. SharePoint now provides an “undelete” feature to
allow end users to recover fortuitously deleted files, documents, list
items, lists, and document libraries without running a
content-database-level backup and restore. This saves the SharePoint
Administrator(s) time and hassle because they can easily recover files
for end users without having to initiate a full-fledged backup and
restore process. In fact, in most
cases, users simply recover things themselves.
When
a user empties the Recycle Bin, the deleted items go to a second-level
Recycle Bin, which can easily be recovered by the administrator,
provided the items have not been purged.
The
global settings for the Recycle Bin are part of the Web Application
General Settings. These settings are accessed through the Central
Administration Application Management (see first image). The Recycle Bin
settings are at the bottom of the general settings page (see second
image).
The
Recycle Bin is a Web application setting, which means that it can only
be enabled or disabled for all of the site collections served by the Web
application. If you turn it on, it’s available on all sites in all site
collections for that Web application.
We
recommend that you configure the Recycle Bin to a size that is a
percentage of the overall site quota and set an “auto-clean” schedule
(the default is 30 days) for permanent file removal that fits your
business needs.
The
first level of the Recycle Bin is the user-level Recycle Bin, which is
accessible by site users. It provides a site-level view of deleted
content and contains all items deleted from a particular site.
NOTE: The
Recycle Bin works by capturing delete actions. If items go missing due
to errors, data corruption, or other problems, they will not be
recoverable via the Recycle Bin. This is why a full backup process must
exist. They Recycle Bin is a convenience item for users who fortuitously
delete a file or other item.
NOTE: The first-level Recycle Bin counts toward the site’s maximum quota.
The
second level of the Recycle Bin is the administrative Recycle Bin (see
Map 7.17), which is accessible by site collection administrators. It
provides a site collection-level view of deleted content and contains
all items deleted from a particular site collection. In effect,
SharePoint administrators are no longer responsible for maintaining
replica environments for item-level restores. In addendum, inadvertent
site deletions can be managed through the use of custom event handlers
that automatically back up a site prior to deletion. Both place forward
significant support time reductions.
