Deixe-me começar dizendo que, se eu perdi alguns documentos muito básicos, KBs ou qualquer coisa, sinta-se à vontade para me ligar na direção certa. Eu verifiquei alguns tópicos aqui e não encontrei a resposta para as perguntas que tenho.
Eu criei um script simples de acordo com o exemplo MS para backup completo (stsadmin com opção de backup completo para uma unidade de rede). Agora para a pergunta:
Cenário: Temos algum tipo de desastre destruindo este servidor. Como podemos levantá-lo novamente junto com o conteúdo? Eu juntei que o backup da ferramenta stsadmin tudo é importante em termos de conteúdo e tal, mas e as configurações e o próprio WSS? Gostaria apenas de instalar um novo servidor com o IIS, o WSS 3.0 com as mesmas configurações adicionadas durante a primeira instalação, etc., e depois executar a ferramenta stsadmin para restaurar os dados, ou estou faltando alguma coisa aqui?
Obrigado antecipadamente.
IMHO, seria muito mais fácil, rápido e seguro se você usasse um produto de backup de terceiros que pudesse fazer backup do servidor, do estado do sistema e do sharepoint usando um agente de backup do Windows e um agente de backup do SharePoint. BackupExec vem à mente.
Faça uma restauração de avaliação do método proposto (backup de STSADM para o novo servidor WSS) usando uma VM e veja se os sites retornam de forma aceitável. Seus backups são tão bons quanto sua última restauração.
Ao usar somente o STSADM, você perderá tudo na Administração Central e todas as personalizações feitas no Themes, no CSS ou em qualquer arquivo de configuração XML no sistema de arquivos. Se você estiver usando uma instalação WSS vanilla e se importar apenas com a recuperação de documentos de emergência, isso pode ser bom para sua organização.
MS tem documentação sobre o backup usando as ferramentas do SQL Server , que devem fazer o backup do site configuração e conteúdo, mas não qualquer coisa que tenha sido alterada no sistema de arquivos. Observação "Você não pode usar as ferramentas de backup e restauração do SQL Server 2005 para restaurar o banco de dados de configuração para um farm ou configuração de topologia diferente". Então, se você tem uma topologia simples, isso pode ser uma limitação aceitável.
Verifique também se você é capaz de colocar o servidor de recuperação na mesma versão exata que seu servidor de produção está executando no momento.
Mas sim, se sua empresa se preocupa com os dados, desembolsar a massa para um pacote de backup decente. Nós usamos o conector do Commvault.
Eu recomendaria o seguinte:
Os seguintes cenários de DR podem ser resolvidos por meio desses backups:
O método stsadm funciona bem, mas nunca me pareceu muito eficiente para mim. Os desastres acontecem muito raramente, mas você deve fazer backup do seu Sharepoint diariamente e não quer se sobrecarregar com backups de baixo desempenho o tempo todo.
Se você fizer backup de seus bancos de dados e de quaisquer arquivos de personalização, voltar a rodar é mais ou menos uma questão de construir um novo servidor Sharepoint e servidor SQL, instalando as personalizações e, em seguida, apontando Sharepoint no banco de dados de configuração. Ele deve então pegar todas as configurações e bancos de dados de conteúdo.
A maneira de cantar toda a dança que eu prefiro é ter servidores do SharePoint virtualizados, que você faz backup em sua totalidade, além de todos os seus bancos de dados do SharePoint. Você pode restaurar as VMs e os bancos de dados e começar a funcionar em um período muito curto de tempo com o mínimo de estresse. É muito fácil documentar em comparação com outros métodos também.
Existem soluções de terceiros para backup / restauração do SharePoint que podem fornecer opções mais granulares, especialmente quando se trata de restaurar itens individuais, mas eu ficaria surpreso se eles proporcionassem muito mais benefícios em um verdadeiro cenário de desastre. No lado do SQL, você pode encontrar algo como O Quest Litespeed faz o backup e restaura seus dados com mais eficiência, o que é de valor.