(Enquete encerrada) Onde guardam seus backups?

Ola galera,
Essa enquete ficou ativa entre os dias 01/10/2016 à 04/01/2017, o objetivo era saber como as empresas estão armazenando seus dados, diante o cenário atual de segurança de dados!

Podemos observar que existe sim a preocupação no que se diz respeito a backup, apesar de vermos diversos casos no Estado do Ceará e no Brasil, de empresas que perdem todas (ou quase todas) as informações quando precisaram recuperar de um desastre, mais ai vem a questão: Será que estão sendo feitos testes nesses backups?

Pontos positivos:
– 62% dos participantes usam estratégias bem seguras em relação a backup (Servidor de Backup, Nuvem, Fita, Rede, Espelho ou Replicado);
– A questão de backup em Nuvem (18%), esta crescendo muito e atualmente é uma das opções mais acessíveis e rápidas de serem utilizadas;

Pontos negativos:
– 23% dos participantes informaram se seus backups são guardados em HD externo, não digo um ponto negativo, mas creio que devam ter uma segunda opção de backup, por ser tratar de uma mídia que pode dar problemas físicos com facilidade. Atenção galera!!!
– 14% informaram que fazem backup no próprio computador, isso é extremamente crítico se não feito como deve ser feito. Backup no computador é uma boa prática no que se diz respeito a volta rápida ao estado anterior, quando o problema não é na máquina ou no disco, mas essa estratégia obrigatoriamente deve ser seguida por alguma outra como por exemplo um backup em nuvem! Atenção galera!!!

Agradeço a todos pela atenção e espero ter ajudado com essa pesquisa, que no meu ponto de vista, levou a questão:

Seus backups são testados periodicamente?
Deixem seus comentários!

 

Perda de dados custa às empresas brasileiras US$ 26 bilhões em 12 meses

L&A Soluções – Consultoria em Banco de Dados SQL Server ( Suas informações em boas mãos! )

Companhias tiveram 17 horas de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos

A perda de dados e tempo de inatividade custou aproximadamente US$ 26 bilhões às empresas brasileiras no último ano. Mundialmente, o montante foi de US$ 1,7 trilhão. É o que apontou um estudo encomendado pela EMC, que indica que 62% dos profissionais de TI do Brasil não confiam integralmente em sua capacidade de recuperar informações após um incidente.

Além disso, 61% das organizações não têm plano de recuperação de desastres para cargas de trabalho emergentes; e apenas 4% têm planos para big data, nuvem híbrida e dispositivos móveis. De acordo com o levantamento, “nenhuma das organizações do Brasil são ‘Líderes’ em proteção de dados; 9% são ‘Adotantes’; 91% estão desatualizadas”, informa a fabricante.

Apesar de o número de incidentes estar em queda, o volume de dados perdidos por incidente cresce exponencialmente. De acordo com o estudo, 59% das empresas pesquisadas passaram por perda de dados ou tempo de inatividade nos últimos 12 meses.

Na média, as empresas tiveram 17 horas (mais de dois dias de trabalho) de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos.

Segundo a pesquisa, empresas com três ou mais fornecedores perderam quase cinco vezes mais dados em comparação com as que têm estratégia de um só fornecedor.

“As empresas com três fornecedores também tenderam a gastar, em média, US$ 15 milhões a mais na infraestrutura de proteção de dados, em comparação com as que têm apenas um”, informa o relatório.

O EMC Global Data Protection Index, realizado pela Vanson Bourne, pesquisou 3,3 mil responsáveis por decisões de TI de médias a grandes empresas em 24 países entre agosto e setembro de 2014.

Fonte: Site Computerworld

Lendo Informações do Backup – SQL Server

OnlyWhatMatters

Neste artigo irei mostrar alguns comandos T-SQL, que estão disponíveis do SQL Server 2005, que retornam informações úteis dos backups realizado, tais como: arquivos de data e log que estão no backup, horário de inicio e término do backup, integridade do backup realizado, etc.

Os comandos T-SQL são:

RESTORE FILELISTONLY
RESTORE LABELONLY
RESTORE HEADERONLY
RESTORE VERIFYONLY

Obs.: estes comandos apenas extraem as informações que estão no backup, isso sem a necessidade de restaura-lós.

Para saber mais detalhes de cada informação retornada nestes comandos, clique no título do comando.

RESTORE FILELISTONLY

Este comando retorna informações sobre os arquivos de dados (mdf e ndf) e log (ldf) armazenados em um dispositivo.

Por exemplo, neste comando ele retorna algumas informações importantes como:
– LogicalName: nome lógico do arquivo no SQL Server;
– PhysicalName: caminho e nome do arquivo;
– Type: o tipo do arquivo, ex: se o Type for “D”, trata-se de um…

Ver o post original 201 mais palavras

Recoverying Model Database

Freccia's Blog

Recentemente tive algumas discussões a respeito de como proceder em caso a base de dados Model seja corrompida. A primeira coisa que escutei foi:

Nunca tivemos a base de dados model corrompida! É tão pequena que não teriamos problema

Bom, ai é que surge o problema! Se estamos pensando em um verdadeiro cenário de Disaster Recovery, nada pode passar despercebido por nós, nem mesmo aquela pequena base chamada de model. Se você quer saber um pouco mais sobre a mesma, indico a leitura do link abaixo.

https://msdn.microsoft.com/en-us/library/ms186388.aspx

Ver o post original 740 mais palavras

O Plano B

Fonte e direitos: RENATO CESAR MONTEIRO

Todos nós recordamos daquele trágico dia 11 de setembro de 2001 – o dia em que as torres gêmeas de Nova York vieram abaixo pelas mãos dos terroristas que jogaram nelas dois aviões Boeing 767 que haviam sido sequestrados. Sem dúvida uma das maiores tragédias da história moderna. A partir dali, tudo mudou nos Estados Unidos: as leis de imigração ficaram mais rígidas, o controle sobre o tráfego aéreo aumentou,foi deflagrada uma verdadeira guerra contra o terrorismo que, mui tas vezes, passou por cima dos direitos humanos. Foram ordenadas execuções sumárias, mui tas vezes sem provas criminais e contrariando as leis internacionais. Mas a partir daquele dia também mudou a história da Tecnologia da Informação.

Todos sabemos que o armazenamento de informações e documentos são fundamentais para a continuidade de qualquer negócio. Os meios de armazenamento atuais incluem, quase que na maioria das empresas, backup em fitas magnéticas, em servidores remotos ou sites de backup (existem os modelos co-location, que nada mais são do que data centers independentes que oferecem hospedagem compartilhada para mais de uma organização). As boas práticas sugeridas pela ITIL (Information Technology Infrastructure Library, modelo britânico utilizado em muitas empresas, cito, por exemplo, a Gerdau e a Stefanini IT Solutions) recomendam que as mídias de backup de cada empresa sejam armazenadas em local seguro e nunca no mesmo prédio-sede. Em caso de destruição total do patrimônio físico de uma empresa (o que pode ser recuperado através de seguro) , estes arquivos poderão ser restaurados.

Naturalmente, o monitoramento destes backups através do uso de software apropriado, bem como a análise de logs e testes de restore periódicos também são recomendáveis. Acontece que muitas empresas que operavam nas torres gêmeas de NY possuíam seus backups na torre vizinha. Isso mesmo: fitas de backup, servidores de backup e links de contingência ficavam no outro prédio. Ninguém imaginava que as duas torres desabariam. Ali, caro leitor, muitas empresas vieram à falência por não terem mais o histórico de seus clientes ou simplesmente por não poderem comprovar dívidas e créditos: todo o histórico digital estava perdido!

Desde então a grande maioria dos bons profissionais de Tecnologia da Informação vêm buscando especializar-se e implementar em suas empresas as práticas de continuidade de negócio mais modernas, atualizadas a partir daquela tragédia. Isso não se restringe ao armazenamento de dados, mas tem sido levado em conta, também, o capital intelectual. Não me surpreende o fato dos dois diretores de uma famosa empresa de consultoria e treinamento aqui de Porto Alegre viajarem periodicamente em voos diferentes. Eles sabem que detém grande conhecimento sobre a sua empresa e que o falecimento de ambos seria extremamente prejudicial para a continuidade do negócio. Logo, se acontecer a queda de um dos aviões, viria a falecer somente um dos diretores… Parece loucura, mas muitas empresas adotam esta prática. Apenas não admitem publicamente. Se refletirmos um pouco chegaremos a uma conclusão semelhante no que diz respeito ao conhecimento, à patente do software. O monopólio da informação, o não compartilhamento do código pode gerar a perda irreversível de grandes ideias. Quantos grandes softwares foram descontinuados simplesmente porque o código-fonte não foi aberto e, assim, não foi dada a continuidade por parte de outros desenvolvedores?

O “plano B”, caro leitor, resume-se a uma única palavra: continuidade. Isso pode ser implementado a partir de um simples nobreak até um si te em co-location.
Cabe aos profissionais de Tecnologia, ir além e nos anteciparmos aos imprevistos

Vejam também:
Missão Crítica: conceitos básicos

Migração de Dados e Estratégias de Backup para o SQL Azure

 

Leiam também:

Estudo aponta melhores maneiras de se fazer backup em ambientes virtualizados

{ Alex Souza }

Banco de dados corrompido (Análise)

Esta é uma área que gosto muito, apesar que não gostaria de passar por uma situação desta em produção… hehehe

Encontrei este Post no Blog do Erickson Ricci, segue abaixo conforme o autor escreveu (todo o mérito é do autor, que esta de parabéns pelo excelente material)…
Neste post farei a análise de um banco de dados corrompido. O banco de dados corrompido que irei utilizar foi disponibilizado num grupo de estudos para a certificação MCM no qual estou participando. O grupo foi iniciado pelo MVP Jason Strate ( blog | @StrateSQL ) e quem quiser mais informações pode acessar este post dele: http://www.jasonstrate.com/2011/12/sql-mcm-study-group/.

Vocês poderão baixar o banco de dados corrompido aqui.

Vamos começar a análise então. Antes de mais nada, precisamos deixar nosso banco de dados disponível em nossa instância. A maneira mais simples de fazer isto é anexar (attach) a base, seja pela interface gráfica ou via comando, desta forma:

CREATE DATABASE [CorruptDB1] ON
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1.mdf' ),
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1_log.ldf' )
FOR ATTACH;
GO

Substitua o caminho “C:\temp\CorruptDBs\…” para o local onde você escolher descompactar os arquivos.

Uma vez que o banco de dados estiver anexado, vamos rodar um DBCC CHECKDB para ver qual o estado do nosso banco.

DBCC CHECKDB(CorruptDB1)
WITH ALL_ERRORMSGS, NO_INFOMSGS

Foi utilizado as opções ALL_ERRORMSGS e NO_INFOMSGS para exibir como resultado somente mensagens de erro e ignorar mensagens informativas. Se desejar mais informações sobre o comando DBCC CHECKDB, clique aqui. O resultado que temos é o seguinte:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data),
page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -4.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Há algo errado com nosso banco de dados. E agora, que ação devemos tomar?

O comando CHECKDB possui duas opções chamadas REPAIR_ALLOW_DATA_LOSS e REPAIR_REBUILD. A primeira impressão é “…ótimo, o DBCC CHECKDB vai resolver meu problema de corrupção!”.

A primeira opção “tenta” reparar o problema de corrupção e pode ocasionar perda de dados. Já a segunda opção “tenta” executar reparos que não possibilitem perda de dados. Como não queremos perder nenhum dado da base, vamos executar a segunda opção primeiro. Vou alterar o acesso do banco de dados para SINGLE_USER e vou executar estas opções.

ALTER DATABASE CorruptDB1 SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB(CorruptDB1, REPAIR_REBUILD)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E temos o seguinte resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Hummm… Nada resolvido. Ainda tivemos o erro 8939. Vamos forçar a barra e tentar o reparo com possível perda de dados.

DBCC CHECKDB(CorruptDB1, REPAIR_ALLOW_DATA_LOSS)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E o resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

 

Novamente, nada feito. Pelo nível de corrupção do banco de dados, o comando DBCC CHECKDB não consegue reparar este problema. Vamos ter que fazer uma análise um pouco mais profunda e por a mão na massa para resolver o problema.

Nós vamos encontrar a explicação deste erro aqui. Em linhas gerais, ele nos informa que foi realizada uma validação numa determinada página, e esta validação falhou por uma corrupção no cabeçalho (Header) da página. Interessante não?!

Analisando a mensagem completa de erro que nos foi dada, podemos observar que ela nos informa qual é a página que está com problema: “…page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. …”. Fica a dica: LEIA TODA A MENSAGEM DE ERRO!!! Achei que isto deveria ficar em destaque pois é muito comum ver as pessoas sem saber o que fazer e a mensagem de erro te dá dicas valiosas sobre o que aconteceu. Nem sempre é assim, mas na maioria das vezes é válido. Vamos dar uma olhada nesta página:

DBCC TRACEON(3604)
GO
DBCC PAGE('CorruptDB1', 1, 7, 3)

Quer saber mais sobre o Trace Flag 3604 e sobre o comando DBCC PAGE, acesse aqui e aqui.
O resultado completo que temos é o seguinte:

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.PAGE: (1:7)BUFFER:BUF @0x000000008EFA8F40bpage = 0x000000008E17E000           bhash = 0×0000000000000000           bpageno = (1:7)
bdbid = 17                           breferences = 0                      bcputicks = 0
bsampleCount = 0                     bUse1 = 50557                        bstat = 0xc00809
blog = 0×21212159                    bnext = 0×0000000000000000PAGE HEADER:Page @0x000000008E17E000m_pageId = (1:7)                     m_headerVersion = 0                  m_type = 0
m_typeFlagBits = 0×0                 m_level = 0                          m_flagBits = 0×200
m_objId (AllocUnitId.idObj) = 99     m_indexId (AllocUnitId.idInd) = 0    Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0            Metadata: IndexId = 0                Metadata: ObjectId = 99
m_prevPage = (0:0)                   m_nextPage = (0:0)                   pminlen = 90
m_slotCnt = 2                        m_freeCnt = 6                        m_freeData = 8182
m_reservedCnt = 0                    m_lsn = (0:0:1)                      m_xactReserved = 0
m_xdesId = (0:0)                     m_ghostRecCnt = 0                    m_tornBits = 105713478Allocation StatusGAM (1:2) = ALLOCATED                SGAM (1:3) = NOT ALLOCATED           PFS (1:1) = 0×44 ALLOCATED 100_PCT_FULL
DIFF (1:6) = CHANGED                 ML (1:7) = NOT MIN_LOGGED
Msg 2514, Level 16, State 5, Line 1

A DBCC PAGE error has occurred: Invalid page type – dump style 3 not possible.

Obviamente houve erros no resultado. Mas o que chama a atenção são os pontos que destaquei em negrito. Se dermos uma olhada no Internals (um modo “carinhoso” de chamar o livro Microsoft SQL Server 2008 Internals), veremos no capítulo 3, página 147, parágrafo 2 ( :-O Não, eu não decorei isto, fui ver no livro… ^.^ ) as explicações sobre as páginas de alocação de dados, em resumo, assim:

• Page 0 – File Header
• Page 1 – PFS Page Free Space
• Page 2 – GAM Global Allocation Map
• Page 3 – SGAM Shared Global Allocation Map
• Page 4 e Page 5 – não são utilizadas
• Page 6 – DCM Differential Changed Map
• Page 7 – BCM Bulk Changed Map

Isto nos leva à conclusão de que a página que temos corrompida neste banco de dados é a página BCM, Bulk Changed Map. Não vou entrar neste momento no detalhe das páginas de controle, ficando apenas por dizer que é uma das páginas de controle de alocação de dados do SQL Server.

Ótimo! Agora sabemos o que fazer. Podemos então fazer o restore desta página e tudo resolvido. Será?!
Vamos tentar.

USE MASTER;
GO

RESTORE DATABASE CorruptDB1
   PAGE = '1:7'
FROM DISK = 'C:\temp\CorruptDBs\CorruptDB1\Bak\CorruptDB1.bak'
WITH RECOVERY

Vamos utilizar o comando RESTORE para restaurar somente a nossa página corompida. O resultado que temos é:

Msg 3111, Level 16, State 1, Line 2
Page (1:7) is a control page which cannot be restored in isolation. To repair this page, the entire file must be restored.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

 

Ops! O SQL Server não nos permite restaurar isoladamente páginas de controle… E nos informa que para resolução do problema temos de restaurar o arquivo completo.

Solução para o problema e evitar perda de dados. Faça um backup de log (Tail Log Backups) e aplica um restore do banco de dados e depois aplique os logs na sequência, se houver, e por último aplique o último backup de log gerado (tail log). Depois de seguir estes passos, execute novamente o comando DBCC CHECKDB para ter certeza de que seu problema foi resolvido.

Esta foi a solução que foi encontrada para este problema de corrupção.

---

Veja também:

Integridade do Banco de Dados

Possible Index Corruption. Diagnosticando o problema

Corruption demo databases and scripts

Corrigindo Erro de Suspect Database (novo)

Corrompendo um Banco SQL (novo)

Corrupção de Dados direto das trincheiras (novo)

Ver páginas corrompidas (SQL Server)

Verificação de Página e Restore de Bases no SQL Server

Recriando as databases de sistema

Automatizando a verificação de integridade de seus bancos de dados

Como Restaurar o Master, Model e MSDB

Entendendo e Melhorando seus backups (SQL Server)

Restaurando um Database Suspect – SQL Server

Databases em modo Suspect e Pendente Recovery

Creating, detaching, re-attaching, and fixing a SUSPECT database

O utilitário TABLEDIFF

O utilitário tablediff é usado para comparar dados em duas tabelas para não convergência, e é especialmente útil para solução de problemas de não convergência em uma topologia de replicação. Esse utilitário pode ser usado no prompt de comando ou em um arquivo em lotes para executar as seguintes tarefas:
– Uma comparação linha por linha entre uma tabela de origem em uma instância do MicrosoftSQL Server agindo como um Publicador de replicação e a tabela de destino em uma ou mais instâncias do SQL Server agindo como Assinantes de replicação.
– Executar uma comparação rápida comparando apenas contagens de linha e esquema.
– Executar comparações em nível de coluna.
– Gerar um script Transact-SQL para corrigir discrepâncias no servidor de destino a fim de que haja convergência entre as tabelas de origem e de destino.
– Registrar resultados em um arquivo de saída ou em uma tabela no banco de dados de destino.

Encontrei no Blog do Leka um material bastante interessante sobre o assunto (veja…).

Fontes:
http://msdn.microsoft.com/pt-br/library/ms162843.aspx

TableDiff

Backup no SQL Server

O que é Backup?
Backup é um termo inglês que tem o significado de cópia de segurança. É frequentemente utilizado em informática para indicar a existência de cópia de um ou mais arquivos guardados em diferentes dispositivos de armazenamento. Se, por qualquer motivo, houver perda dos arquivos originais, a cópia de segurança armazenada pode ser restaurada para repor os dados perdidos. Fonte: Significados (+)

————————————————————————–

Este artigo escrito pelo Vladimir Magalhães sobre Performance de Backup é bastante interessante e resolvi compartilhar com todos, vejam…

” Quando falamos de backup, muita gente se preocupa com o lugar onde estes serão armazenados, período de retenção dos backups, tipos de backup utilizados (full, differencial, log, etc..), mas e quanto a performance?

Sim, você pode (e deve!) configurar seus backups para que sejam feitos da forma mais performática possível, pois lembre-se, estes costumam consumir muitos recursos do seu servidor enquanto são executados.” (MAIS…)

————————————————————————–

Todos os direitos são reservado aos autores dos artigos e posts, abaixo segue uma lista de links, categorizada por assunto, que redireciona ao site ou blog do respectivo autor.

Vejam também:

Estratégia de Backup

Fazer backup na nuvem ou em uma ferramenta efetiva?

Dica sobre Backups

Simulando – Desastre e Recuperação de Bancos de Dados – Microsoft SQL Server 2008 R2 e 2012 ( Parte 1 | Parte 2 | Parte 3 | Parte 4 | Final )

SP_BACKUP – Gerencie suas rotinas de modo simples, fácil e objetivo.

Como Restaurar o Master, Model e MSDB

Obtendo informações sobre Modelo de Recuperação, Contadores de Desempenho, Nível de Compatibilidade de Banco de Dados por Instância no Microsoft SQL Server 2005, 2008 e 2008 R2.

Compactação de Backup com o SQL Server 2008

Lendo Informações do Backup – SQL Server

Criação e Restauração de Backup – SQL Server 2005 ( Parte 1 | Parte 2 | Parte 3 | Parte 3.1 )

Plano de Manutenção: Automatizando Backups no SQL Server

SQL SERVER – Database in RESTORING State for Long Time

Query último Backups – SQL Server

O ultimo backup full executado com sucesso

Como recuperar um banco de dados apagado acidentalmente sem ter o backup

Script – Gerando comando de restore dinamicamente

RESTORE VERIFYONLY (Transact-SQL) – Verificar Backup

Restore Parcial no SQL Server

Realizando Backups SSMS

Realizando Backups T-SQL

Tempo restante para finalizar execução do Backup no Microsoft SQL Server 2008 e R2.

Script – Pesquisando arquivos de backups em um diretório com T-SQL

Tipos de Backup no SQL Server (Vídeo Youtube).

Fazendo Backups no SQL Server 2008 R2 (Vídeo Youtube).

Simulando – Minimal Logging – Microsoft SQL Server 2008 R2 e 2012.

Life Consultant: Restore With StandBy

SQL Server 2012 – Database Recovery Advisor

Database Recovery Advisor–SQL Server 2012 (Quick Post)

AUTOMATE SQL SERVER EXPRESS BACKUPS WITH POWERSHELL

Histórico de Backups – Pivot

Obtendo Histórico de Execução de Backups de Bancos de Dados no Microsoft SQL Server 2008, R2 ou 2012

Listando informações sobre backups do DPM

Restoring SQL Server backups made with System Center Data Protection Manager using Powershell – New Version

{ Alex Souza }

Dica sobre Backups

Fica ai a dica, caso um dia precisem analisar quando um backup foi feito e outras informações relacionadas, existem algumas tabelas no banco msdb que gravam varias informações sobre os backups, uma delas é a msdb.dbo.backupset.
Exemplo: Select * From msdb.dbo.backupset

{ Alex Souza }         Fonte: Blog do Fabiano Neves