Práticas recomendadas de backup e recuperação (SharePoint Server 2010)

Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo descreve as práticas recomendadas que podem ser usadas para ajudar a garantir o êxito das operações de backup e recuperação do Microsoft SharePoint Server 2010 e assegurar a proteção do ambiente contra perda de dados e falhas de continuidade. O artigo inclui as práticas recomendadas para desempenho, controle de qualidade, segurança e excelência operacional.

Neste artigo:

• Práticas recomendadas de desempenho

• Práticas recomendadas de controle de qualidade

• Práticas recomendadas de procedimentos

Práticas recomendadas de desempenho

As operações de backup e restauração podem consumir recursos de servidor e limitar o desempenho do servidor durante sua execução. Ao realizar as práticas recomendadas, você pode reduzir o uso de recursos e aumentar o desempenho de servidores e da operação de backup ou de restauração.

Minimizar a latência entre o SQL Server e o local de backup

Em geral, é melhor usar um disco local no servidor de banco de dados, e não uma unidade de rede, para fazer backups e, depois, copiar os dados em uma pasta compartilhada na rede. As unidades de rede com latência de 1 milissegundo ou menor entre elas e o servidor de banco de dados funcionam bem.

Para evitar afunilamentos de E/S, execute o backup principal em um disco separado do disco que executa o Microsoft SQL Server 2008 com Service Pack 1 (SP1) e Atualização Cumulativa 2.

Por design, a maioria dos trabalhos de backup consome todos os recursos disponíveis de E/S para concluir o trabalho. Portanto, pode ocorrer enfileiramento de discos, o que pode resultar em uma latência de solicitação de E/S maior do que a usual. Isso é normal e não deve ser considerado um problema.

Evitar conflitos de processamento

Não execute trabalhos de backup nos momentos em que os usuários precisam acessar o sistema. Considere intercalar os backups para que não ocorra o backup de todos os bancos de dados simultaneamente.

Manter os bancos de dados pequenos para obter tempos mais rápidos de recuperação

Mantenha os bancos de dados pequenos para acelerar o backup e a recuperação. Você pode fazer isso usando vários bancos de dados de conteúdo para um aplicativo Web, em vez de um banco de dados grande de conteúdo.

Usar backups incrementais para bancos de dados grandes

Use backups incrementais para bancos de dados grandes, como aqueles disponíveis no DPM 2010. Os backups incrementais podem ser restaurados mais rapidamente e com mais eficiência do que os backups completos de bancos de dados grandes. Para obter mais informações sobre os tipos de backup, consulte Visão geral de backup (SQL Server) (https://go.microsoft.com/fwlink/?linkid=203863&clcid=0x416).

Usar compactação durante o backup

Em algumas circunstâncias, é possível usar a compactação para melhorar o tamanho do backup (redução de 30%) e os tempos (redução de 25%). A compactação de backup foi introduzida no SQL Server 2008 Enterprise. Para obter mais informações sobre como a compactação de backup afeta o desempenho do SQL Server, consulte Compactação de backup (SQL Server) (https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x416).

Seguir as recomendações de otimização de backup e restauração do SQL Server

Se estiver usando backups do SQL Server, use uma combinação de backups completos, diferenciais e de log de transações (do modelo de recuperação completa ou bulk-logged) para minimizar o tempo da recuperação. Os backups diferenciais de banco de dados geralmente são mais rápidos de criar do que os backups completos de banco de dados e reduzem a quantidade de logs de transações necessária à recuperação do banco de dados.

Se estiver usando o modelo de recuperação completa, é recomendável truncar periodicamente os arquivos de log de transações para evitar problemas de manutenção.

Para obter recomendações detalhadas sobre como otimizar o desempenho de backup e restauração do SQL Server, consulte Otimizando o desempenho de backup e restauração em um SQL Server (https://go.microsoft.com/fwlink/?linkid=126630&clcid=0x416).

Usar RAID 10 se pretender usar RAID

Considere cuidadosamente o uso de RAID (redundant array of independent disks) no dispositivo de backup de disco. Por exemplo, o RAID 5 apresenta baixo desempenho de gravação, aproximadamente a mesma velocidade de um único disco. (Isso porque o RAID 5 precisa manter as informações de paridade.) O uso do RAID 10 para um dispositivo de backup pode proporcionar backups mais rápidos. Para obter mais informações sobre como usar RAID com backups, consulte o artigo sobre como configurar o RAID para obter a máxima taxa de transferência de E/S do SQL Server (https://go.microsoft.com/fwlink/?linkid=126632&clcid=0x416).

Configurar as definições do SharePoint para obter o melhor desempenho de backup e restauração

Você pode configurar as definições na Administração Central e no Windows PowerShell para aumentar a eficiência e o desempenho de backup ou restauração.

Se usar o cmdlet Export-SPWeb do Windows PowerShell, use o parâmetro NoFileCompression. Por padrão, o SharePoint Server 2010 usa a compactação de arquivos ao exportar aplicativos Web, conjuntos de sites, listas ou bibliotecas de documentos. Você pode usar esse parâmetro para suprimir a compactação de arquivos durante a exportação ou a importação. A compactação de arquivos pode usar até 30% mais recursos, mas o arquivo exportado ocupará aproximadamente 25% menos espaço em disco. Se usar o parâmetro NoFileCompression ao exportar, use-o também para importar o mesmo conteúdo.

Também é possível usar o parâmetro NoLogFile. Por padrão, o SharePoint Server 2010 sempre cria um arquivo de log quando você exporta conteúdo. Você pode usar esse parâmetro para suprimir a criação do arquivo de log, economizando assim recursos. Entretanto, é recomendável sempre criar logs. Isso porque os logs podem ser usados na solução de problemas. Além disso, a criação de logs não usa muitos recursos.

Se usar o cmdlet Backup-SPFarm, use o parâmetro BackupThreads para especificar a quantidade de threads que o SharePoint Server 2010 utilizará durante o processo de backup. Quanto mais threads você especificar, mais recursos serão usados pela operação de backup, porém, se houver recursos suficientes, a operação será concluída mais rapidamente. Entretanto, cada thread é relatado individualmente nos arquivos de log e, assim, o uso de menos threads facilita a interpretação dos arquivos de log. Por padrão, são usados três threads. O número máximo de threads disponível é 10.

Considerar o tamanho do conjunto de sites ao determinar as ferramentas a serem usadas

Se a empresa exigir backups de conjunto de sites, além dos backups no nível do farm ou no nível do banco de dados, selecione as ferramentas a serem usadas com base no tamanho do conjunto de sites.

• Menor que 15 GB (gigabytes): use comando Backup-SPSite do Windows PowerShell. Para obter mais informações, consulte Fazer backup de um conjunto de sites (SharePoint Server 2010).

• De 15 a 100 GB: use uma ferramenta dos Produtos e Tecnologias do SharePoint, uma ferramenta do SQL Server ou outra ferramenta de backup de banco de dados para proteger o banco de dados de conteúdo que tem o conjunto de sites. Para obter mais informações, consulte Fazer backup de um conjunto de sites (SharePoint Server 2010).

• Maior que 100 GB: use uma solução de backup diferencial, como Microsoft SQL Server 2005 ou DPM 2010, em vez das ferramentas internas de backup e recuperação.

Práticas recomendadas de controle de qualidade

Você pode seguir estas práticas recomendadas para garantir a qualidade dos backups do ambiente de farm e reduzir a possibilidade de perda de dados.

Verificar se o espaço de armazenamento é adequado

Verifique se o sistema tem o espaço em disco adequado para acomodar o backup.

Testar rotineiramente a qualidade do backup

Teste rotineiramente os backups e valide sua consistência. Execute operações de recuperação práticas para validar o conteúdo do backup e garantir que é possível restaurar todo o ambiente. Para ambientes dispersos geograficamente, prepare a recuperação de desastre configurando um farm remoto. Dessa forma, você poderá restaurar o ambiente usando o comando de anexação de banco de dados para carregar uma cópia do banco de dados no farm remoto e redirecionar os usuários. Execute periodicamente um teste da operação de recuperação de dados para verificar se os arquivos foram incluídos corretamente no backup. Uma restauração de teste pode expor problemas de hardware que não são detectados pelas verificações de software.

Backup de logs de rastreamento ULS

As ferramentas do SharePoint Server 2010 não fazem backup dos logs de rastreamento ULS. Os dados em logs de rastreamento ULS podem ser úteis para análise de desempenho, solução de problemas, monitoramento de conformidade com os contratos de nível de serviço e por motivos de ordem legal, normativa ou comercial. Portanto, proteja esses dados como parte da manutenção de rotina. Para obter mais informações sobre backup de logs ULS, consulte Back up or archive logs in SharePoint Server 2010.

Armazenar uma cópia externa dos arquivos de backup

Para se proteger contra perda de dados em um evento catastrófico, como incêndio ou terremoto, mantenha cópias duplicadas de backups em um local separado dos servidores. Isso ajuda a proteger você contra a perda de dados críticos. Como prática recomendada, mantenha três cópias da mídia de backup e mantenha pelo menos uma cópia externa, em um ambiente controlado, o que deve incluir todos os materiais de backup e recuperação, documentos, backups de bancos de dados e de logs de transações, e backups de log de utilização e rastreamento.

Práticas recomendadas de procedimentos

Você pode usar estas práticas recomendadas de procedimentos para planejar e executar operações de backup e restauração com documentação melhor, mais facilidade e maior segurança.

Usar nomes de servidor FQDN

Ao consultar servidores em um domínio diferente, use sempre os nomes FQDN (nomes de domínio totalmente qualificados).

Manter registros exatos

Ao implantar o SharePoint Server 2010, registre as contas que criar e os nomes de computadores, senhas e opções de instalação que escolher. Guarde essas informações em um lugar seguro.

Ter pronto um ambiente de recuperação

Prepare-se para testes de restauração e recuperação de desastre configurando um farm remoto. Dessa forma, você pode restaurar o ambiente usando o comando de anexação de banco de dados para carregar uma cópia do banco de dados no farm remoto e redirecionar os usuários. De modo semelhante, é possível configurar um ambiente em espera e que execute a mesma versão de software do ambiente de produção, para que você possa restaurar rapidamente os bancos de dados e recuperar documentos.

Agendar operações de backup

Se quiser agendar backups, use o Agendador de Tarefas do Windows para executá-los com o arquivo de script do Windows PowerShell (*.ps1).

Usar o provedor SQL FILESTREAM com o repositório BLOB

Se usar o repositório BLOB com o provedor SQL FILESTREAM e fizer backup do banco de dados de conteúdo com esse RBS (Remote BLOB Store) definido, o RBS e o banco de dados de conteúdo serão incluídos no backup e restaurados quando você usar as ferramentas do SharePoint ou do SQL Server. Não é recomendável usar o RBS com outros métodos de restauração.