Preciso fazer backup de 10 a 20 bancos de dados do SQL Server 2008 R2 com tamanhos entre 10 e 50 GB, enquanto estiverem online e usados ​​simultaneamente por um único aplicativo corporativo. Também preciso restaurá-los para um estado que seja amplamente sincronizado em todos os bancos de dados (eu posso permitir alguns segundos de dessincronização entre os bancos de dados). O objetivo é capturar dados de produção para ambientes QA / DEV.

Eu gostaria muito de não exigir bancos de dados executados em recuperação total e criar um método de backup dedicado à captura de dados para ambientes de controle de qualidade e que permaneça independente de um processo de backup principal que não esteja sob meu controle.

Para meus clientes, levará de 1 a 2 horas para capturar 20 backups completos com ~ 30 GB cada. Isso faz com que os backups completos sequencialmente sejam inaceitáveis, pois os bancos de dados seriam dessincronizados demais ao serem executados em recuperação simples.

Estou procurando uma ideia melhor do que estas:

IDÉIA 1: Instantâneo no nível da SAN dos discos da VM. xcopy MDFs / LDFs do instantâneo.

Depois que os arquivos copiados são anexados a uma instância de servidor diferente, seu processo de recuperação deve produzir bancos de dados consistentes que são capturados instantaneamente praticamente ao mesmo tempo.
Pesquisando ao redor me convenceu de que é uma má idéia, pelo menos porque posso ter dessincronização versus master / msdb / etc.

IDEA 2: orquestrar um backup complexo e restaurar a sincronização em todos os bancos de dados

Isso exige que os bancos de dados exigentes sejam executados em recuperação completa, o que não desejo. Inicie backups paralelos para todos os bancos de dados bem antes do prazo final (T0). Quando T0 for alcançado, faça backup de todos os logs (deve levar no máximo alguns minutos). Faça a miríade de backups resultante e tente restaurá-los e rolar os logs para frente / trás para obter um estado um tanto consistente nos bancos de dados, em relação ao T0.
Isso requer muito planejamento e script para usá-lo de maneira confiável, para que eu me esforce ao máximo para evitá-lo.

Estou perdendo alguma outra solução?

PS1: Eu adoraria poder usar instantâneos de banco de dados . A idéia era iniciar um instantâneo em cada banco de dados (que deveria terminar em segundos) e fazer backup completo de cada um sequencialmente nos minutos / horas seguintes. Em seguida, restaure todos eles em um servidor diferente e reverta cada um para o instantâneo. AFAIK neste cenário não é possível porque não é possível fazer backup dos instantâneos junto com o banco de dados. Eles só podem ser revertidos no local, no servidor em que foram criados. Além disso, eles exigem o Enterprise Edition, que não tenho para todos os clientes.

PS2: Se você conhece uma solução de terceiros capaz de produzir backups sincronizados entre db, mencione-a.

Preciso fazer backup de 10 a 20 dbs do SQL Server usados ​​simultaneamente por um único aplicativo corporativo, enquanto estiverem online, de maneira a restaurá-los para um estado amplamente sincronizado em todos os dbs

O que você procura é um backup consistente em todos os bancos de dados de seus clientes; você deve usar backups COMPLETOS juntamente com Marked Transactions(ênfase em negrito adicionado):

Ao fazer atualizações relacionadas a dois ou mais bancos de dados, bancos de dados relacionados , você pode usar marcas de transação para recuperá-las para um ponto logicamente consistente . No entanto, essa recuperação perde qualquer transação confirmada após a marca usada como ponto de recuperação. Marcar transações é adequado somente quando você está testando bancos de dados relacionados ou quando está disposto a perder transações confirmadas recentemente.

Certifique-se de que você faça o backup ad-hoc do log de transações COPY_ONLY; caso contrário, sua recuperação será dolorosa, pois qualquer backup ad-hoc do log de transações sem COPY_ONLYinterromperá a cadeia de log. Como precaução, você pode restringir os usuários a usar apenas COPY_ONLY backups .

Preciso de uma solução para o SQL Server versões 2008 R2 e posterior. Os tamanhos de banco de dados são de até 50 GB por db e o tempo para fazer backup de todos eles é provável em mais de uma a duas horas.

As transações marcadas funcionarão para sua situação. A única coisa a fazer backups paralelos é para STRIPEeles, mas você acaba se certificando de não perder suas faixas de backup. Para torná-los mais rápidos, você pode jogar com BUFFERCOUNTe MAXTRANSFERSIZE.

Você deve usar a compactação de backup e ativar a inicialização instantânea de arquivos .

Referir-se

• Usando transações marcadas (modelo de recuperação completa)
• Como aumentar a velocidade de backup completo do banco de dados SQL usando compactação e discos de estado sólido?

Se você estiver executando backups completos, bem como backups de log de transações (e se considerar esses dados importantes), poderá copiar os backups e backups de log de transações para o sistema de teste e executar uma restauração pontual para restaurar os bancos de dados. + - ao mesmo tempo.

Dependendo de todos os bancos de dados residirem na mesma máquina do SQL Server ou de quão bem os relógios dos servidores estão sincronizados, você poderá corresponder ao destino 'dessincronização de alguns segundos'.

Pode ser um pouco de solução de band-aid, mas atenderia aos requisitos e seria bastante simples e barato.

Se você não possui backups completos e backups de log de transações de seus bancos de dados importantes (que estão em recuperação total), você realmente precisa revisar sua estratégia de backup. Os instantâneos no nível da SAN realmente discutem o ponto de ter um banco de dados no modo de recuperação total, pois você não poderá fazer uma restauração pontual de qualquer maneira.

Por favor, leia o que MrDenny tem a dizer sobre isso

Nas circunstâncias que você indicou, examinou os backups do VSS por meio de um provedor VSS de terceiros ou baseado na Microsoft? Você pode executar um backup COPY_ONLY que não interrompa sua cadeia de recuperação de produção e deve terminar com um backup de todos os bancos de dados que você pode recuperar em outro local, dentro das margens razoáveis. Lembre-se de que um backup do VSS possui alguns dos mesmos mecanismos e falhas que os instantâneos do banco de dados, pois um banco de dados muito ativo pode causar um problema de espaço em disco devido aos arquivos esparsos usados. Veja os recursos do TechNet no serviço SQL Writer aqui e os backups VSS do SQL Server aqui .

Para fazer isso através do Backup do Windows Server, você seguirá as etapas do assistente para um backup manual, garantindo a seleção do backup de cópia do VSS nas configurações personalizadas em Configurações do VSS. Isso permitirá que o backup do Windows Server não interfira em outros backups executados no servidor. Consulte a referência do Backup do Windows Server para obter detalhes.

Vou votar no @ Kin como a resposta, porque foi o primeiro a corresponder ao que a pergunta foi feita. Acabei encontrando uma resposta adicional e a descreverei abaixo.

Para os clientes que usam o modelo de recuperação simples, solicitarei uma cópia dos MDFs e LDFs extraídos de uma captura instantânea de disco temporária tirada em T0 no nível do hipervisor ou SAN. Eu posso usá-los para recuperar os dbs no estado de T0.

Para clientes que usam o modelo de recuperação completa, exigirei:

• Cópias do processo de backup PRINCIPAL do último backup completo concluído antes da cadeia mínima de T0 + dos backups subsequentes do log de transações que cobrem T0. Posso então executar uma recuperação pontual para T0.

• Acesso para executar meus próprios COPY_ONLYbackups auxiliares . Vou iniciá-los todos em paralelo em T0, o que não deve demorar mais que alguns segundos e foi minha principal preocupação. Em seguida, na restauração, executarei uma recuperação pontual no FirstLSN de cada backup. A vantagem disso é que não é necessário que eu interaja com o processo de backup PRINCIPAL, que era minha outra preocupação, eles podem até truncar os logs enquanto meus COPY_ONLYbackups estão em execução sem afetar sua coerência.

Faço isso várias vezes ao ano para controle de qualidade e outros ambientes que são cópias da produção. Para restaurações, o modo de recuperação total é realmente necessário e a restauração em um determinado momento funciona bem. Também há muita replicação e é raro que tenhamos erros de 'linha não encontrada' após a restauração em um determinado momento. Também usamos o método de clone / captura instantânea da SAN para uma cópia geograficamente distante da produção e que também funciona bem para sincronizar os bancos de dados.