Preciso fazer backup de 10 a 20 bancos de dados do SQL Server 2008 R2 com tamanhos entre 10 e 50 GB, enquanto eles estão 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 (posso pagar alguns segundos de dessincronização entre os bancos de dados). O objetivo é capturar dados de produção para ambientes QA/DEV.
Eu gostaria fortemente de não exigir que os bancos de dados sejam 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 principal de backup que não esteja sob meu controle.
Para meus clientes, levará de 1 a 2 horas para capturar 20 backups completos de aproximadamente 30 GB cada. Isso torna inaceitável fazer backups completos sequencialmente, pois os bancos de dados ficariam muito dessincronizados ao serem executados na recuperação simples.
Estou procurando uma ideia melhor do que estas:
IDEIA 1: Snapshot no nível SAN de discos 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 instantâneos praticamente simultaneamente.
Pesquisar no Google me convenceu de que essa é uma má ideia, pelo menos porque posso obter desync vs. master/msdb/etc.
IDEIA 2: Orquestre um backup complexo e uma restauração sincronizada em todos os bancos de dados
Isso exige que bancos de dados exigentes sejam executados em recuperação total, o que eu não quero. Inicie backups paralelos para todos os bancos de dados bem antes do prazo (T0). Quando T0 for atingido, faça backup de todos os logs (deve levar no máximo alguns minutos). Pegue a miríade resultante de backups e tente restaurá-los e rolar os logs para frente/para trás para obter um estado um tanto consistente nos bancos de dados, em relação a T0.
Isso requer muito planejamento e scripts para que seja usado de forma confiável, então eu faria de tudo para evitá-lo.
Estou perdendo alguma outra solução?
PS1: Eu adoraria poder usar snapshots db . A ideia era iniciar um instantâneo em cada banco de dados (que deve terminar em segundos) e, em seguida, 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 este cenário não é possível porque os instantâneos não podem ser copiados junto com o banco de dados. Eles só podem ser revertidos no local, no servidor onde foram criados. Além disso, eles exigem a Enterprise Edition, que não tenho para todos os clientes.
PS2: Se você souber de uma solução de terceiros capaz de produzir backups sincronizados entre bancos de dados, mencione-a.
O que você está procurando é um backup consistente em todos os seus bancos de dados de clientes, você deve usar backups COMPLETOS junto com
Marked Transactions(ênfase em negrito adicionada):Certifique-se de fazer backup de log de transação adhoc com
COPY_ONLY, caso contrário, sua recuperação será um problema, pois qualquer backup de log de transação adhoc semCOPY_ONLYinterromperá a cadeia de log. Como precaução, você pode restringir os usuários a usar apenasCOPY_ONLYbackups .As transações marcadas funcionarão para sua situação. A única coisa para fazer backups paralelos é para
STRIPEeles, mas depois você acaba se certificando de não perder suas listras de backup. Para torná-los mais rápidos, você pode brincar comBUFFERCOUNTeMAXTRANSFERSIZE.Você deve usar a compactação de backup e habilitar a inicialização instantânea de arquivo .
Referir-se
Se você estiver executando backups completos, bem como backups de log de transações (e você deve, se considerar esses dados importantes), basta copiar os backups e os backups de log de transações para o sistema de teste e executar uma restauração pontual para restaurar os bancos de dados para +- ao mesmo tempo.
Dependendo se todos os bancos de dados residem na mesma máquina do SQL Server ou quão bem os relógios dos servidores estão sincronizados, você deve ser capaz de corresponder ao destino de 'dessincronização de alguns segundos'.
Pode ser uma solução um pouco de band-aid, mas atenderia aos requisitos e seria bastante simples e barato.
Se você não tiver 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 de nível 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, você consultou os backups VSS por meio de um provedor VSS terceirizado ou baseado na Microsoft? Você pode executar um backup COPY_ONLY que não interromperá 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 lugar dentro de suas margens razoáveis. Lembre-se de que um backup VSS tem alguns dos mesmos mecanismos e quedas 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. Dê uma olhada nos recursos do TechNet sobre o serviço SQL Writer aqui e nos backups VSS do SQL Server aqui .
Para fazer isso por meio do Backup do Windows Server, você seguirá as etapas do assistente para um backup manual, certificando-se de selecionar backup de cópia VSS nas configurações personalizadas em Configurações VSS. Isso permitirá que o backup do Windows Server não interfira em nenhum outro backup feito no servidor. Consulte Referência de backup do Windows Server para obter detalhes.
Vou votar em @Kin como a resposta porque foi a primeira a corresponder ao que a pergunta perguntou. Acabei encontrando uma resposta adicional e vou descrevê-la abaixo.
Para clientes que usam o modelo de recuperação simples, exigirei uma cópia dos MDFs e LDFs extraídos de um instantâneo de disco temporário obtido em T0 no nível do hipervisor ou SAN. Posso usá-los para recuperar os dbs no estado de T0.
Para clientes que usam o modelo de recuperação total, exigirei:
Cópias de seu processo de backup PRINCIPAL do último backup completo concluído antes de T0 + cadeia mínima de backups de log de transações subsequentes cobrindo T0. Posso então executar uma recuperação pontual para T0.
COPY_ONLYAcesso para realizar meus próprios backups auxiliares . Vou iniciá-los todos em paralelo em T0, o que não deve levar mais do que alguns segundos e era minha principal preocupação número 1. Em seguida, na restauração, executarei uma recuperação pontual para o FirstLSN de cada backup. A beleza disso é que não exige que eu interaja com o processo de backup PRINCIPAL, que era minha outra preocupação, eles podem até truncar os logs enquanto meusCOPY_ONLYbackups estão sendo executados sem afetar sua coerência.Eu faço isso várias vezes ao ano para controle de qualidade e outros ambientes que são cópias de produção. Para restaurações, o modo de recuperação total é realmente necessário e a restauração para um ponto no tempo funciona bem. Também há muita replicação e é raro termos erros de 'linha não encontrada' após a restauração em um ponto no tempo. Também usamos o método SAN clone/snapshot para uma cópia de produção geograficamente distante e que também funciona bem para sincronizar os bancos de dados.