Conheça o Logical Backup Device

Logical Device

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);

Criando um LBD visualmente

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 :

Modo TSQL

– 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:

BKP E RST

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

3 pensamentos sobre “Conheça o Logical Backup Device

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s