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)?

Foi útil?

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.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top