1. Backup and Restore Strategy
Simply backing up a server is not a viable strategy
in and of itself nor is redundancy a suitable substitution for a good
backup strategy. A good backup strategy considers uptime and restoration
Service Level Agreements (SLA) and the impact of an extended outage.
As
in previous versions, there are multiple facets to backing up Lync
Server. Obviously, the SQL databases must be backed up. Fortunately,
this process is fairly straightforward. There is nothing unique about
backing up a Lync Server database compared to another SQL database.
However, the Central Management Server (CMS) database must be backed up,
too. In contrast, the local SQL express instances on each server role
do not need to be backed up because they contain no unique information.
The next consideration is backing up the Lync Server
configuration. The familiar LCSCmd process is gone, but it is replaced
with the more powerful Lync Server cmdlets. Finally, one must consider a
traditional full backup of each of the individual servers. However, in
some environments, traditional backups may not be a requirement.
For most, environments in Table 1 outlines the best practices related to backup strategy.
Table 1. Best Practices for Backup Strategies
Type | Frequency |
---|
SQL database | Nightly |
CMS | Every time a change is made, or at least monthly |
Server backup | Weekly |
2. Backup Processes
This section includes the steps necessary to back up
your Lync Server environment. As mentioned previously, backing up the
environment is a multistep process. This section covers each step in
detail. Of course, these steps are adequate for most evenironments.
Environments with special requirements might require a more exotic
solution to back up and restore.
2.1 Backing Up Lync Server Databases
The good news is there is nothing unique about the
Lync Server databases stored in SQL Server. They can be backed up and
restored like any other database. Although this section does not cover
the SQL database process in depth, it summarizes the process for CS
administrators who might not be familiar with the process.
Note
Keep in mind that each pool has a unique database and must be backed up separately.
As
in previous versions, data is stored in the RTC database. Backups can
be done in the SQL Management Studio GUI, scripted using TSQL, or by
using a SQL-specific backup agent such as Microsoft Data Protection
Manager 2010. Because there are many different enterprise backup
products, this section reviews the first two options. Users with an
enterprise backup platform should follow the instrutions for SQL backup
from their platform vendors.
Backing Up the RTC Database
For a given front end pool, the only database that
needs to be backed up is the RTC database. If you choose to deploy
Monitoring or Archiving services, those databases need to be backed up
in the same manner. To back up the RTC database using the SQL Management
Studio GUI, first log in to your SQL server and follow the steps that
follow:
1. | Open the SQL Management Studio tool and connect to the appropriate SQL instance where the RTC database is stored.
|
2. | Expand Databases and find the RTC database.
|
3. | Right-click the RTC database and select Tasks, and then select Back Up.
|
4. | In
the window that displays, ensure the RTC database is selected and the
backup type is Full. Ensure the appropriate destination is selected,
too. A proper configuration of this screen is shown in Figure 1.
|
5. | In the left column, select the Options item. Most of the items can be left at their default settings; however, it is recommended you enable the Verify backup when finished box, as shown in Figure 2. Because the RTC database is not very large, this process does not require much additional time.
|
6. | Click OK to begin the backup.
|
7. | A pop-up should display with the message, “The backup of database “rtc’ completed successfully.” Click OK to continue.
|
Create TSQL Script to Back Up the RTC Database
There are two ways to create the TSQL script for
backing up the RTC database. If you are familiar with TSQL, it’s simple
to write the script and set it as a job.
Tip
If you are not familiar with TSQL, there is a way to
have the SQL Management studio write the script for you. Follow steps
1–5 in the preceding section. However, instead of clicking OK, click the Script button at the top of the window and choose Script Action to New Query Window as shown in Figure 3. Simply run the query to create the backup.
For the process outlined previously, the script is included in the following:
BACKUP DATABASE [rtc] TO DISK = N'C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Backup\rtc.bak' WITH NOFORMAT, NOINIT, NAME
= N'rtc-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where
database_name=N'rtc' and backup_set_id=(select max(backup_set_id) from
msdb..backupset where database_name=N'rtc' )
if @backupSetId is null begin raiserror(N'Verify failed. Backup information
for database ''rtc'' not found.', 16, 1) end
RESTORE VERIFYONLY FROM DISK = N'C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Backup\rtc.bak' WITH FILE = @backupSetId,
NOUNLOAD, NOREWIND
GO