-
Na eventualidade de ocorrência de incidente, os dados devem ser
repostos, recorrendo então à informação armazenada na cópia de
segurança. A recuperação dos dados deverá ser efetuada rapidamente e de
forma eficiente, para que os serviços não se encontrem inativos por
muito tempo. A prioridade da reposição dos dados deve ser estabelecida,
conforme as necessidades da organização.
Num modelo não estruturado, o repositório pode ser armazenado
em medias de armazenamento com informações mínimas sobre o que e quando
foi armazenado. Apesar da simplicidade de implementação, torna-se
difícil recuperar as informações caso necessário. No outro extremo temos
a cópia de segurança completa que tem como principal desvantagem
altos requisitos de armazenamento, maior tempo de processamento tanto
na criação como na recuperação do repositório.
Em um repositório global e incremental (backup incremental), originalmente, é feita uma cópia de segurança completa de todos os arquivos. Depois, cópias incrementais são feitas apenas dos arquivos que foram modificados desde a última iteração de cópia incremental ou completa. Restaurar o sistema a um certo momento requer localizar a cópia completa obtida antes do momento dado e todas as cópias incrementais realizadas entre a cópia completa
e o momento. Esse modelo oferece um alto nível de segurança de
recuperação e rapidez, e pode ser usado com diferentes tipos de
dispositivos de armazenamento. Por outro lado, desvantagens incluem
lidar com diferentes cópias incrementais e o tempo de recuperação.
Num repositório global e diferencial (backup diferencial), após a cópia de segurança completa ser feita, cada cópia diferencial captura todos os arquivos criados ou modificados desde a cópia completa, apesar de alguns já poderem ter sido incluídos numa cópia diferencial anterior. Sua vantagem é que a restauração envolve recuperar somente a última cópia de segurança completa e a última cópia diferencial.
Um repositório mirror (espelho) e rsync (reversamente incremental) é similar ao global e incremental,
mas difere na medida em que oferece uma cópia que reflete o estado dos
dados da última cópia de segurança e a história reversa das cópias
incrementais. Um benefício é requerer somente uma cópia completa. Cada
cópia incremental é imediatamente aplicada à cópia espelho e os arquivos
que ela modifica são movidos para a cópia reversamente incremental.
Esse modelo não é adequado para dispositivos de armazenamento removíveis
pois cada cópia de segurança deve ser feita comparando-se com a cópia
espelho.
Já num modelo de proteção contínua dos dados, o sistema registra
imediatamente cada mudança nos dados, o que é geralmente feito
diferenças de bytes ou blocos de bytes e não de arquivos.
-
Ficou confuso o termo utilizado "aplicando logs do banco de dados". Por acaso isso se refere a backup incremental ou diferencial? O que entendo por log é um arquivo texto que contém informações sobre o que aconteceu com o banco. E no caso, eu não aplico logs e sim analiso os logs.
Mais alguém ficou confuso nesta questão?
-
Oi Maria, o que isso quer dizer (pelo que entendi) é que, para dizer que houve uma restauração "completa" você deve também restaurar os logs do banco, se você só sobe os dados (.mdf) você perde os logs de transações daquele banco, então se você quiser recuperar completamente um banco tem que subir tudo, dados e logs.
Veja se isso te ajuda, me ajudou pelo menos:
http://msdn.microsoft.com/pt-br/library/ms187495.aspx
-
Prezados, vamos analisar alternativa por alternativa :
a) se for executada a recuperação simples de
dados com base no último backup completo de dados com o banco de dados offline,
isso garantirá a recuperação dos dados no momento mais próximo ao colapso.
Alternativa errada, ao utilizarmos a recuperação do último
backup completo garantiremos a recuperação de dados até o momento em que o
backup foi realizado, com a perda dos dados salvos entre o momento do backup e
o momento do colapso
b) devem ser aplicados os logs correspondentes
às modificações de bancos de dados que ocorreram após a confirmação da queda de
energia que corrompeu o banco de dados.
Alternativa errada, aplicar os logs das operações realizadas
após a queda não irá recuperar os dados inseridos no banco entre a realização
do backup e o momento do colapso.
c) deve ser feita a recuperação do último
backup offline completo realizando join das tabelas de dados restauradas do
backup com as tabelas do banco de dados presentes no ambiente corrompido.
Alternativa errada, iniciar o procedimento de recuperação
restaurando o último backup é correto, mas dai a fazer join das tabelas de
dados restauradas do backup com as tabelas de dados presentes no ambiente
corrompido não tem lógica.
d) será necessária a recuperação completa
aplicando logs do banco de dados após a recuperação do último backup completo
do banco.
Alternativa correta. Para nos recuperarmos desse colapso,
devemos primeiramente recuperar o último backup completo. Depois disso,
poderíamos recuperar algum backup diferencial ou incremental, mas a alternativa
não trata disso, o que não a deixa errada . De qualquer sorte, recuperando o
último backup completo, ou o último backup completo + o último diferencial ou
os últimos incrementais, ou mesmo acreditando que um backup completo foi
realizado na noite anterior ao do colapso, apenas restaurando o backup iriamos
ter a perda dos dados inseridos no banco após a realização do backup até o
momento do colapso, e isso frustra a expectativa dos usuários, para garantirmos
que a perda de dados seja a mínima possível, devemos aplicar os logs do banco
de dados após a recuperação do backup , dessa forma , todas as operações
realizadas no banco de dados após o momento do backup seriam refeitas no banco
restaurado através do log das operações, dessa forma o banco ficaria em um
estado muito próximo ao de antes do colapso.
e) devem ser recuperados os backups
diferenciais, sem necessidade de recuperação de qualquer backup completo.
Alternativa errada, o backup diferencial realiza o backup de
todos os arquivos modificados ou alterados desde o último backup completo.
Restaurar um backup diferencial sem restaurar o backup completo acarreta em
perda de dados.
A alternativa correta é : D.
-
Maria, se eu não fosse da área de Banco de Dados ficaria com a mesma dúvida.
O Postgres, por exemplo, funciona da seguinte maneira: além de armazenar o log de todos os eventos (conforme configurado) ele armazena TODAS as transações feitas em um log (chamado pg_xlog) antes de 'salvá-las' em disco.
Com isso é possível fazer uma restauração de um backup full e depois aplicar os arquivos de log.
-
O enunciado da questão está bem genérico, restringindo apenas que o único mecanismo de proteção contra perda de dados da instituição era o de backup em dispositivo e mídia externo.
Neste cenário "padrão", o mais indicado é restaurar os dados do último backup completo. Provavelmente estes dados estarão desatualizados (sabemos que um backup full é realizado com menos frequência). Em se tratando de um sistema transacional, o ideal é realizar a restauração o mais próximo do incidente. Daí a necessidade de utilizar os logs REDO, por exemplo, para chegar a um momento mais próximo do incidente (corrupção da base), mas que mantenha o banco de dados em um estado consistente.
Resumindo: backup completo + aplicação dos logs correspondentes às modificações de bancos de dados.