Anexar / desanexar vs. backup / restauração

Preciso transferir o banco de dados (como um todo) para outro servidor, para criar um banco de dados duplicado para configurar outro ambiente de teste.

Eu tenho duas escolhas:

1. Faça um backup completo no servidor de origem / restaure no servidor de destino;
2. Desconecte no servidor de origem / anexe no servidor de destino.

Quais são os prós e os contras das duas soluções de acordo com meus requisitos?

Estou usando o SQL Server 2008 Enterprise.

O backup / restauração normalmente deve ser o seu método de escolha. Será mais rápido na maioria das situações.

Você pode usá-lo de forma consistente, também para testar a produção.

Consulte também esta questão relacionada, onde é mencionado o backup / restauração vs desanexação / anexação:

Migração do SQL Server restaurar backup vs copiar dados e arquivos de log

Certifique-se de adicionar a WITH COPY_ONLYopção ao backup, para que não quebre a cadeia de backup do plano de manutenção existente.

1. Desanexar o banco de dados o deixará offline. Faça um backup se precisar que o banco de dados permaneça online enquanto o copia para outro servidor.
2. Mover e restaurar um arquivo de backup (.bak) pode ser mais simples / fácil do que mover e anexar vários arquivos mdf / ldf (como faria se você desconectasse o banco de dados).
3. No papel, uma desanexação / conexão de banco de dados pode ser tecnicamente mais rápida, mas, na prática, um backup / restauração provavelmente será mais rápido e fácil. Ao desanexar um banco de dados, você primeiro deve colocar o banco de dados original offline (desconectar todos e tudo) e, em seguida, o banco de dados fica indisponível até você se reconectar. Você também deve acompanhar todos os arquivos, enquanto que com um backup todos os arquivos são agrupados.

Se você decidir fazer backup / restauração, use a opção WITH COPY_ONLY durante o backup para garantir que a cadeia de backup de qualquer plano de manutenção existente não seja interrompida.

Um arquivo .bak é compactado bem; portanto, se você decidir fazer um backup, compactá-lo antes de movê-lo pode economizar tempo de transferência.

Eu iria para backup / restauração, pois deixa o banco de dados original em um estado operacional.

Especialmente se você estiver fazendo uma conversão de 'produção para testar', é importante que o banco de dados de produção permaneça online.

O backup / restauração também é uma opção mais segura : o que acontece se o arquivo for corrompido em algum lugar entre o início da desanexação, a cópia, a anexação etc.? Pelo menos, se você executar um backup e o arquivo ficar corrompido, poderá começar de novo. Se isso acontecer com uma desanexação, seu banco de dados desaparecerá.

Além disso, para mim (embora seja mais uma sensação do que qualquer outra coisa), o backup / restauração é "trabalho diário", enquanto que desanexar / anexar é algo que você faz em circunstâncias excepcionais. Não me pergunte onde eu tirei essa ideia ;-)

Eu sempre tive problemas com a parte "restauração" do backup / restauração. Não posso citar detalhes, pois acabei desistindo e, desde então, tenho destacado / copiado / anexado.

A única coisa sobre a desanexação é que você PRECISA ter certeza de que o DBMS também não excluirá o banco de dados também. Isso já aconteceu, e não é uma visão bonita.

Eu recomendo um copy_onlybackup usando este método a partir de um shell do DOS (para que você não interrompa os logs de transações) :

Execute a partir do C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupdiretório:

backup.bat SQLDBNAME

Onde backup.batcontém (quebra de linha adicionada para facilitar a leitura) :

sqlcmd.exe -U username -P xxxxxxx -S SQL-SERVERNAME 
    -Q "BACKUP DATABASE %1 TO DISK = '%1_COPYONLY.BAK' WITH COPY_ONLY,INIT;"