Olá,
O assunto de hoje é Logical Backup Device. Para maiores informações sobre o termo “Device” (Dispositivo) de backup no SQL Server ou sobre o termo que intitula o post, dê uma olhada nas referências.
Logical Backup Device (Dispositivo Lógico de Backup), que ao longo do post vou chamar de LBD, nada mais é do que um alias (ou abstração, para os mais teóricos) de um dispositivo físico (pode ser uma fita ou disco, geralmente este último). Significa que podemos referenciar um local físico passando apenas o nome do dispositivo lógico como destino.
Como seria um backup referenciando um LBD?
BACKUP DATABASE [AdventureWorks2008R2] TO BackupCactuar
Observações:
– O nome do seu Logical Backup Device deve ser único (óbvio, lol)
– View de sistema: sys.backup_devices (consulte aqui todos os LBD’s criados)
– Pra criar um logical device, é necessário pertencer à role diskadmin (ou sysadmin).
Como criar
Aquela beleza de poder escolher N formas para cumprir determinado objetivo.
Duas formas de criar o LBD (o modo hardcore, aka Powershell, não será abordado aqui);
a – Usando a GUI do Management Studio (Modo fácil);
Vale lembrar que o arquivo informado em File não é criado em tempo de execução. Você precisa criá-lo (lembre-se: é um arquivo binário).
b – Usando T-SQL (Modo normal)
Com as permissões necessárias, basta utilizar a procedure sp_addumpdevice.
O nome não é intuitivo e pode causar um certo estranhamento, pois antigamente, o termo dump era bastante utilizado em alguns cenários de tecnologias (e ainda é, no MySQL) por ser sinônimo de backup e agora nem tanto (sp_addbackupdevice seria muito mais amigável não só de nome como também combinaria com a view e tal…)
Confira as sintaxes úteis, que são a criação, a deleção e a consulta de informações em view de sistema relacionadas aos LBDs :
– name: Nome do seu dispositivo. É o nome que vai ser apontado no destino de backup;
– type: Tape = 1 e Disk = 2
– type_desc = descrição dos tipos acima
– physical_name = O caminho FÍSICO do dispositivo
Vale lembrar (de novo) que o arquivo informado em File não é criado em tempo de execução. Você precisa criá-lo (lembre-se: é um arquivo binário).
Mas qual a utilidade disto?
O fato de se ter uma abstração física te dá a vantagem de alterar o caminho de um dispositivo em determinado ponto (na configuração do próprio lbd), e não em scripts que o referenciem. Vamos supor que você tenha um job de backup, de uma base em específica. Se o script contiver apenas o nome do LBD e não um caminho de disco local ou SAN, se você precisar alterar o caminho físico, basta alterar o LBD.
E como usar um LBD? Mais fácil enxergar na prática:
Apenas um exemplo (tirado da vida real)
Uma aplicação X frequentemente fazia backup e restore da sua base e utilizava esse recurso do LBD. O fornecedor optou por utilizar apenas um arquivo pra fazer esse processo todo de backup e restore continuamente, sempre sobrescrevendo o mesmo em cada execução. A definição do (mais adequado possível) caminho físico fica por responsabilidade do DBA.
Também é interessante utilizar esse método onde você desenvolva algum script que precise de uma localização física para realização de backup e restore e você não pode garantir um caminho definitivo (seja de rede ou local). Adivinha qual a solução? LBD é uma boa. Já vi também implementações de LBD para estratégias de backup bem excepcionais (Backup dividido). Ou seja, é uma solução que não atende um cenário apenas, embora não sejam cenários comuns.
Qual a vantagem disto?
O comando de Backup e Restore recebem um alias, uma abstração de um caminho físico. Logo, por exemplo, se meu caminho real tiver no disco D, e eu precisar retirar esse disco, posso mapear o LBD para algum outro local, por exemplo disco E, sem prejuízo para a aplicação. Também é útil em manobras emergenciais.
Por exemplo, manobras que envolvam diferentes discos (o que inclui troca de caminhos físicos com frequência) e/ou que sofram de falta de espaço podem fazer bom uso dessa abstração.
É útil para rotinas de backup convencionais? Não considero e não recomendo de jeito nenhum. O nível de organização que se tem em realizar um backup de banco por arquivo, o que inclui também convenção de nome bem definida (20140226_AdventureWorks_Full.bak por exemplo) é muito mais interessante para uma rotina diária do que manter mais de um backup por arquivo (e isso pode pesar MUITO quando você precisar usar um device que tenha mais de uma base, e pior, bases diferentes).
Observação importante
Uma recomendação da própria MS e que atualmente é uma boa prática (por razões óbvias): não deixe seus backups no mesmo array de disco que seus arquivos de dados e de log (note que eu disse array de disco e não discos e isso vale também para LBDs, pois, você pode ter duas letras/discos diferentes (D: e E: por exemplo) porém são partições/discos do mesmo disco/array. Quando se pensa em desastres, pense na pior hipótese sempre, algo como: o array todo pode falhar, e se seus arquivos de backup estiverem lá, você aprenderá da pior forma possível que backup no mesmo local físico onde seus dados estão não é backup. Isso é um ponto que irei sempre voltar ao longo das postagens.
Qualquer dúvida ou comentário adicional, fique à vontade para comentar.
Referências
Backup Devices: http://technet.microsoft.com/en-us/library/ms179313.aspx
Logical Backup Device : http://technet.microsoft.com/en-us/library/ms189109.aspx
As imagens não estão carregando!
Pedro,
Hoje de noite (pois agora não é possível) vou re-upar as imagens. Muito, mas muito obrigado por me avisar!
[]’s
Pedro, obrigado por ter comentado. Atualizei as imagens e acrescentei algumas informações no post. Muitíssimo obrigado por ter me avisado. Abraço!