recuperação de desastres Sharepoint
-
06-07-2019 - |
Pergunta
Quais são os seus planos de recuperação de desastres para o Windows SharePoint Services 3.0?
Atualmente estamos fazer cópia de backup todos os bancos de dados (1 conteúdo, admin, pesquisar e config) usando ferramentas de backup do SQL, e fazer cópia de backup do servidor de front-end via DataProtector.
Para testar nossos backups, usamos um outro farm de servidores, restaurar o banco de dados de conteúdo (seguindo o procedimento na TechNet ) e criar um novo aplicativo que usa esse banco de dados. Nós apenas temos que soluções reimplantar sobre a aplicação sharepoint recém-criado.
No entanto, temos de credenciais de acesso de banco de dados mudanças (no servidor SQL): o usuário contas utilizadas na produção não são os mesmos que os utilizados em nossa fazenda "teste"
.No final, podemos restaurar nosso banco de dados de conteúdo e acesso a todos os nossos sites. Searching não funciona, mas estamos investigando.
É este o cenário de restauro confiável (como no suportado pela Microsoft)?
Solução
Você não pode realmente backup / restauração tanto da base de dados de configuração e pesquisa de banco de dados:
- restauração de banco de dados de configuração só funcionam se o seu novo farm têm exatamente os mesmos nomes de servidor
- quando você restaurar o banco de dados de pesquisa, o índice de texto completo não é sincronizar. no entanto, este não é um problema, como você pode apenas reindexar.
Como resultado, eu diria que sim, este um confiável para conteúdo. Mas cuidar de:
- Você pode ter que refazer algumas configurações (AAM, caminho gerenciado ...).
- Isto não inclui personalização, você quer manter um backup de sua solução
Outras dicas
A confiabilidade está no olho de quem vê. Neste caso, se os testes do processo de restauração for bem sucedida, então sim, é confiável.
Um número de meus clientes executar SharePoint (ambos MOSS e WSS) em ambientes virtuais, o SQL Server também é virtualizado e apoiada tanto com ferramentas SQL e com cópia sombra do volume.
A vantagem de um ambiente virtual é o tempo de inatividade é apenas o tempo que leva o seu host do Virtual Server para arrancar as imagens.
Se você não estiver usando virtualização, então lembre-se de logs de transação de backup regularmente, pois isso fará com que seja mais fácil para restaurar a um determinado momento do dia - isso também significa que seus logs de transação não faça crescer demais
Eu prefiro usar o comando stsadm -o backup 'para backup catastrófico', como se diz na ajuda. Isto pode ser agendada, mas requer alguma manutenção do arquivo XML de metadados de backup quando você começar a correr para fora do espaço em disco e necessidade de arquivar os backups mais antigos. Tem a vantagem de transferir mais trabalhos de timer (geralmente) e outra configuração porque como Nico diz, restaurando o banco de dados de configuração não irá funcionar para a maioria das situações.
Para restaurar, você pode usar a interface do usuário que é bom e não tem que mexer com muito mais. Eu acho que restaura suas soluções tão bem, mas não testei que extensivamente.