Como posso fazer backup de um banco de dados do servidor SQL (2000 e 2005)?

6

Atualmente, fazemos backup de nossos bancos de dados MSSQL 2000 e 2005 usando o software para copiar arquivos para a fita todas as noites. Tamanhos de banco de dados são 14-16Gb e 500Mb.

Como o SQL Server pode fazer backup de um banco de dados em um arquivo, seria melhor agendar o SQL Server para criar um arquivo de backup e, em seguida, fazer o backup desses arquivos em fita? Além disso, se usarmos esse método, é possível de alguma forma criar um log de transações que foram concluídas desde o último backup, para que possamos recriar o banco de dados e aplicar as transações adicionais?

    
por Swinders 30.04.2009 / 16:15

6 respostas

2

Não há realmente nenhuma razão para NÃO usar a funcionalidade de backup nativa do SQL Server. É ótimo, compreende logs de transações e oferece a maior parte da funcionalidade de que você precisa. (Soluções terceirizadas do SQL Server Backup são ótimas porque funcionam com as APIs expostas pela Microsoft e geralmente fornecem suporte a criptografia e compactação - e a compactação não apenas economiza espaço em disco, mas geralmente reduz os tempos de backup e restauração.)

Então, sim ... eu recomendo fazer backups com o SQL Server.

E certifique-se de fazer backups de log de transação REGULAR. (Eu recomendo fazê-los a cada 15 minutos ou menos - backups regulares de arquivos de log ajudam a manter seu arquivo de log enxuto / médio 1 e, por alguma razão, os usuários finais ficam sempre mal-humorados quando o servidor trava e eles precisam refazer todo o seu trabalho nas últimas x horas desde o último arquivo de log ou backup completo / diferencial.) Então, para fins de redundância, use robocopy, syncback, replicação do sistema de arquivos ou algo para mover cópias desses backups para outro local para proteger contra falhas de hardware / disco ou acionamentos no data center e assim por diante.

Sinta-se à vontade para conferir esses dois vídeos gratuitos para mais informações e ideias:

link

link

[ 1 ] [Revista do SQL Server: maximizando o desempenho do armazenamento] 3

    
por 30.04.2009 / 18:35
2

Observação: meu maior problema é que o SQL Server (todas as edições) é um backup de log de transações.

Executamos um backup completo do nosso banco de dados SQL e logs de transações a cada 30 minutos, no disco (em outro servidor, SAN diferente) para data de arquivos estampados (script SQL e SSIS bastante simples).

Nosso script também cria o script "restore.sql" para restaurar o último backup completo e todos os logs de transação até essa data.

Em seguida, compactamos os arquivos com mais de dois dias, excluímos mais de 30 dias (mas mantemos backups de final de mês em um arquivo). Nós replicamos essa unidade para fora do local (temos sorte em termos de 200 milhas entre grandes sites e uma grande conexão WAN entre eles).

Em seguida, fazemos backup disso em fita. (Cinto, chaves e mais chaves! Principalmente por razões políticas)

Nós executamos muitos bancos de dados do SQL Server e as ferramentas comerciais são muito caras ou simplesmente não nos dão o retorno do investimento. Mas eu recomendaria o RedGate SQLBackup para instalações menores

    
por 30.04.2009 / 16:24
1

Você quer dizer que atualmente faz backup dos arquivos MDF e LDF do banco de dados em fita? Eu acho que isso pode ser OK, contanto que o banco de dados esteja offline enquanto você o faz (ou seja, banco de dados desconectado ou SQL Service desligado), mas se você tentar fazer isso enquanto o banco de dados estiver em uso, você provavelmente terminará com backups não funciona porque os arquivos serão alterados durante a cópia.

Criar um backup completo do SQL e colocá-lo em fita é muito mais comum na minha experiência.

Além disso, para responder à sua segunda pergunta, o SQL Server oferece suporte a backups do log de transações. A documentação da MSDN no Modelo de Recuperação Completa seria um bom local para começar a ler.

    
por 01.05.2009 / 15:01
1

Como você viu pelas respostas, a maioria das pessoas faz o backup no disco primeiro e depois na fita. O que eu frequentemente vi (e recomendado) é fazer o backup imediatamente para o disco que está no próprio servidor (isso pode ser o armazenamento conectado à SAN, a chave é que o backup não está gravado na rede). Depois que esse backup imediato é feito, ele é copiado para um servidor de backup central. Você mantém uma cópia imediata do que precisa restaurar localmente. Nesse servidor de backup, você mantém vários dias de backups. Dessa forma, se você precisar reverter para um ou dois dias anteriores, não estará solicitando uma fita. E, claro, você faz backup desse servidor de backup central em fita. Então, isso cobre sua capacidade de recuperação.

Com relação aos tipos de backup que você deve fazer, se quiser recuperar todas as transações e conseguir fazer o que chamamos de recuperação pontual, verifique se os bancos de dados têm seu modelo de recuperação definido como recuperação completa. e você vai querer fazer backups completos junto com backups de log de transações. Você pode querer intercalar backups diferenciais para reduzir a quantidade de arquivos que você está restaurando. Tudo isso é abordado em livros on-line e fornecerá uma descrição melhor do que qualquer um de nós em uma postagem no fórum.

No que diz respeito a produtos de terceiros, como o LiteSpeed e o SQL Backup do Red Gate, eles costumavam ser mais rápidos do que o backup nativo. Isso porque eles usam uma API que o SQL Server não usava. Isso era verdade no SQL Server 2000, mas não tenho certeza se ainda é o caso. No entanto, eles fazem criptografia e compactação e, portanto, podem valer a pena considerar o tamanho de seus bancos de dados.

    
por 01.05.2009 / 15:53
1

O backup com script para disco é fácil e opera muito rapidamente:

osql -S [ip_of_server] -Q "BACKUP DATABASE [database_name] PARA DISK = 'C: \ Backups \ Backup.bak'"

Não funciona para fazer backup em local diferente na rede (não que isso seja uma boa ideia, de qualquer maneira) com um caminho UNC. É mais fácil de qualquer maneira fazer backups localmente e armazená-los criptografados.

O disco rígido é barato e cada vez mais confiável. Nós nos livramos de nossas fitas há algum tempo e nunca mais voltamos atrás.

    
por 11.05.2009 / 09:27
1

Eu gosto mais dessas instruções: link

    
por 11.06.2009 / 22:03