none
Restore de Bases SQl 2005 RRS feed

  • Pergunta

  • Buenas pessoal,

    Tenho o seguinte problema e acredito que alguem possa me ajudar.

    Aqui na empresa, a cada semana +- é preciso restaurar os ambientes de testes, cada ambiente tem entorno de 15 bases, cada vez que preciso restaurar, pego o ultimo backup (dia anterior) e restauro, isso me demanda quace todo o dia nessa função, teria alguma forma de fazer esses restores fazendo somente que seja restaurado o diferencial?

    Grato desde já

    Jonny

    segunda-feira, 27 de agosto de 2012 14:38

Respostas

  • Olá JM,

    As ferramentas de descaracterização de dados (ou embaralhamento dos dados) servem para situações onde o dado é necessário, mas sua identidade precisa ser preservada. Suponhamos que você tenha um precioso cadastro de clientes e que precise desenvolver nossas funcionalidades no seu cadastro. Isso vai requerer desenvolvimento e homologação para que essas funcionalidades sejam colocadas em produção. Seria prático pegar a base atual, colocar no ambiente de desenvolvimento e assim os desenvolvedores terem massa de testes para desenvolver e a homologação ter massa de testes para homologar... Fórmula simples mas...

    O cadastro é o negócio da sua empresa. Se você restaura a base em desenvolvimento ou entrega para uma empresa terceira, ela irá entregar as funcionalidades que você deseja, mas acabou de ganhar um grande patrimônio que são os seus dados. Agora basta ela ir na concorrência e vendê-los e aí você precisará de muito mais do que novas funcionalidades para recuperar o prejuízo. Mas o que fazer ? A empresa precisa de dados para poder trabalhar.

    Nessa situação, onde o dado é precioso é que entra a descaracterização de dados. Você poderia desenvolver uma série de procedures em TSQL ou classes em Java para mascarar os dados. Às vezes trocar CPFs válidos por CPFs gerados aleatoriamente (mas válidos), atualizar nomes de clientes ou criar endereços fictícios. O problema dessa abordagem é que se você o fizer estará criando uma ferramenta muito atrelada ao negócio. Quando novas tabelas aparecerem, será necessário refazer suas rotinas de descaracterização. Para cada banco de dados uma rotina nova e por aí vai, o que tornará muito caro senão impossível de manter.

    E aí que entram as ferramentas de descaracterização. Elas não conhecem nada de negócio, mas podem descaracterizar dados conforme regras preestabelecidas. Ela pode extrair um subset de dados da produção e mascará-los (dobrar o salário, multiplar a renda por um número aleatório, conectar em um base de nomes para regerar os nomes dos clientes, etc). Isso sem ater-se a complexidade da base, relacionamentos, PKs, etc.

    Não conheço muitas ferramentas de mascaramento de dados, mas estive fazendo uma POC recentemente com as ferramentas da Informatica (Data Mask) e da IBM (Optimum). Por motivos de NDA, não posso revelar preferências, features nem nada assim (ainda estamos em negociação). De qualquer forma, recomendo procurar, pois, existem outros players nesse mercado.

    Ferramentas de mascaramento de dados não são gratuitas, mas quanto mais você cresce, quanto mais importante o dado se torna, mais e mais elas são necessárias. Não representam apenas uma proteção para o dado, mas viabilizam inclusive a produção de massa de dados mais rapidamente. Ao invés de restaurar um backup de Teras e Teras, você pode gerar uma massa bem menor, porém com representatividade (mascarada ou não). Isso é mais rápido e econômico do que restaurar backups.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    • Marcado como Resposta JM_analista quarta-feira, 29 de agosto de 2012 07:46
    terça-feira, 28 de agosto de 2012 22:24

Todas as Respostas

  • O diferencial é baseado no seu último backup completo, se você tiver um full à meia noite, e diferenciais durante o dia, será necessário voltar esse completo e depois os Diferenciais em seguida.

    Agora se você quer voltar o diferencial sem o full? Esquece, impossível.

    [ ]'s

    segunda-feira, 27 de agosto de 2012 14:40
  • Sim, mas toda vez que você fizer um Backup Full é este que deverá ser restaurando no servidor de testes.

    Enquanto você estiver fazendo o backup Diferencial na base de produção você pode ir restaurando-o na base de homologação.

    Lembre-se que o backup Diferencial contém: tudo o que aconteceu na base desde o último backup Full realizado.

    Então basta restaurar o Diferencial mais recente que você tiver.

    Claro que não deve ser feito qualquer tipo de backup na base de testes, senão você terá conflito de LSN.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    segunda-feira, 27 de agosto de 2012 14:41
  • Faça o teste de restaurar o último Full que fez na base de produção e, a partir de agora, só ir restaurando os backups Diferenciais.

    Lebre-se do que eu disse: quando você fizer um backup Full na base de produção deverá restaurar este no servidor de homologação.

    Exemplo: base de produção.

    DOMINGO -> Backup Full
    SEGUNDA -> Backup Diferencial
    TERÇA   -> Backup Diferencial
    QUARTA  -> Backup Diferencial
    QUINTA  -> Backup Diferencial
    SEXTA   -> Backup Diferencial
    SÁBADO  -> Backup Diferencial

    Com este cenário você pode:

      Restaurar o Backup Full depois que for feito o backup Full de domingo e, no mais, restaurar somente os backups diferenciais que forem acontecendo.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    segunda-feira, 27 de agosto de 2012 14:46
  • Pessoal, obrigado pelo pronto retorno.

    O que acontece é que os backups são todos full, eu não tenho diferencial.

    Esses backups são  feitos diariamente as 20:00hs.

    Att

    Jonny

    segunda-feira, 27 de agosto de 2012 16:29
  • Se você não tem Backup Diferencial não terá como fazer Restore Diferencial.

    Ou você muda (caso possível) sua estratégia de backup, passando a fazer backups diferenciais, ou terá sempre que utilizar o Full para seus Restores.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    segunda-feira, 27 de agosto de 2012 16:48
  • JM_Analista,

    Porque você precisa voltar os backup? É somente um procedimento para verificar a integridade do backup? Se for isso, poderia utilizar a opção de verificação de integridade na instrução de backup.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    segunda-feira, 27 de agosto de 2012 17:49
    Moderador
  • Boa Noite,

    Se a idéia é restaurar o backup full no ambiente de testes para que os analistas testem, então não será possível trabalhar com o backup diferencial. A razão é muito simples. Se você restaurar uma base da produção no ambiente de teste e a base sofrer operações de escrita, ela ficará diferente do que aconteceu em produção e portanto não fará sentido tentar restaurar um backup diferencial (nem é possível fazer isso).

    Se a idéia é sempre restaurar um backup para que as pessoas possam trabalhar (péssima prática na minha opinião), você terá que sempre restaurar um backup full. Não haverá outra estratégia (By Design) nesse caso.

    Honestamente não acho que restaurar backups da produção em um ambiente de testes seja um boa idéia. Isso ao meu ver limita consideravelmente sua escalabilidade (entre outros problemas). Imagine quando sua base estiver muito grande, vai demorar cada vez mais para você conseguir efetuar esse restore (fora que os dados da produção tem seu sigilo colocado em risco).

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    terça-feira, 28 de agosto de 2012 00:08
  • Show Gustavo.

    Mas o que você recomenda quando as Softhouses precisam de base de homologação?


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    terça-feira, 28 de agosto de 2012 14:24
  • Oi Roberson,

    Recomendo que invistam em ferramentas de descaracterização de dados. Servem exatamente para esse propósito. Esse negócio de fazer backup da produção para efetuar testes é pensamento de empresa pequena ou de softwarehouse amadora, pois, por uma questão de sigilo e confidencialidade, nenhuma empresa séria iria propor ou ceder os dados da produção.

    Não consigo acreditar que os desenvolvedores do site do Banco do Brasil tenham que baixar um backup para desenvolverem o site e também não imagino o Pão de Açúcar restaurar um backup da produção para que alguém tenha de resolver um problema bem como recuso me a acreditar que a Receita Federal coloque a base da produção em um servidor de testes para que uma empresa terceira faça integração do cadastro com outros órgãos do governo.

    Como eles fizeram ? Não sei, mas certamente não foi voltando um backup da produção.

    Infelizmente, essa prática é um vício (até porque é muito prático), mas não é o mais "correto" a se fazer. Claro que tudo varia de organização para organização, mas não vejo isso com bons olhos. Ferramentas de descaracterização de dados são uma alternativa muito mais interessante (além de entregar o dado mais rápido).

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    terça-feira, 28 de agosto de 2012 14:45
  • Sim, Gustavo, você está certo. Concordo com você. Mas realmente tenho visto grandes empresas que ainda estão neste vício (Backup/Restore para homologação). Refiro-me tanto a Software houses quanto aos clientes delas.

    Na verdade acredito que ainda existem grandes empresas despreparadas, que ainda conseguem contar com a sorte de não terem tido um problema sério por causa dessas práticas ruins.

    A mudança de cultura em nosso país é a alteração mais difícil de acontecer, você sabe. De forma que somente aquelas empresas que já sofreram algum problema grave pensam em como mudar essas práticas.

    As produtoras de software então... Recentemente liguei para uma das maiores do país, pois eu precisava aplicar algumas boas práticas de configuração na base que o software deles utiliza, em meu cliente. Sabe o que me disseram: "Senhor, não temos ninguém com o perfil para discutir questões de banco de dados."

    É difícil! Mas vamos lá, rs. Aos poucos isso está mudando.

    Mas obrigado. Vou procurar mais sobre descaracterização de dados.

    Forte abraço.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    terça-feira, 28 de agosto de 2012 14:59
  • Gustavo, fale mais sobre essas ferramentas de descaracterização.

    Site alguns exemplos

    Grato

    Jonny

    terça-feira, 28 de agosto de 2012 16:15
  • Boa Noite Roberson,

    Normalmente os problemas em se restaurar o backup de produção no ambiente de homologação ou de desenvolvimento não são percebidos na hora e muitas vezes sequer se materializam. Agora o desenvolvedor ou o homologador ficar sem os dados implica em desenvolvimento mais lento ou homologações paradas.

    Entretanto, pouca gente pensa que a produção pode ter dados sigilosos, que alguém poderia pegar esses dados vender para a concorrência ou ainda que alguém pode de posse desses dados viabilizar uma fraude, ou outras iniciativas como de posse dos dados financeiros de alguém planejar um sequestro relâmpago ou algo do tipo. Embora não paremos para pensar, é por motivos como esse que é possivelmente comprar facilmente cadastros sigilosos na Santa Efigênia, é por motivos assim que recebemos emails com propaganda sem nem saber de quem ou ainda ofertas de cartão de crédito de instituições que sequer sabíamos que existiam. Em uma economia baseada em informação, o dado é valioso e precisa ser protegido, mas pouca gente lembra disso no momento de restaurar um backup da produção em ambiente de homologação.

    Mas enfim, temos de tentar fazer as coisas sempre da melhor forma possível (e não é restaurando um backup da produção).

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    terça-feira, 28 de agosto de 2012 22:13
  • Olá JM,

    As ferramentas de descaracterização de dados (ou embaralhamento dos dados) servem para situações onde o dado é necessário, mas sua identidade precisa ser preservada. Suponhamos que você tenha um precioso cadastro de clientes e que precise desenvolver nossas funcionalidades no seu cadastro. Isso vai requerer desenvolvimento e homologação para que essas funcionalidades sejam colocadas em produção. Seria prático pegar a base atual, colocar no ambiente de desenvolvimento e assim os desenvolvedores terem massa de testes para desenvolver e a homologação ter massa de testes para homologar... Fórmula simples mas...

    O cadastro é o negócio da sua empresa. Se você restaura a base em desenvolvimento ou entrega para uma empresa terceira, ela irá entregar as funcionalidades que você deseja, mas acabou de ganhar um grande patrimônio que são os seus dados. Agora basta ela ir na concorrência e vendê-los e aí você precisará de muito mais do que novas funcionalidades para recuperar o prejuízo. Mas o que fazer ? A empresa precisa de dados para poder trabalhar.

    Nessa situação, onde o dado é precioso é que entra a descaracterização de dados. Você poderia desenvolver uma série de procedures em TSQL ou classes em Java para mascarar os dados. Às vezes trocar CPFs válidos por CPFs gerados aleatoriamente (mas válidos), atualizar nomes de clientes ou criar endereços fictícios. O problema dessa abordagem é que se você o fizer estará criando uma ferramenta muito atrelada ao negócio. Quando novas tabelas aparecerem, será necessário refazer suas rotinas de descaracterização. Para cada banco de dados uma rotina nova e por aí vai, o que tornará muito caro senão impossível de manter.

    E aí que entram as ferramentas de descaracterização. Elas não conhecem nada de negócio, mas podem descaracterizar dados conforme regras preestabelecidas. Ela pode extrair um subset de dados da produção e mascará-los (dobrar o salário, multiplar a renda por um número aleatório, conectar em um base de nomes para regerar os nomes dos clientes, etc). Isso sem ater-se a complexidade da base, relacionamentos, PKs, etc.

    Não conheço muitas ferramentas de mascaramento de dados, mas estive fazendo uma POC recentemente com as ferramentas da Informatica (Data Mask) e da IBM (Optimum). Por motivos de NDA, não posso revelar preferências, features nem nada assim (ainda estamos em negociação). De qualquer forma, recomendo procurar, pois, existem outros players nesse mercado.

    Ferramentas de mascaramento de dados não são gratuitas, mas quanto mais você cresce, quanto mais importante o dado se torna, mais e mais elas são necessárias. Não representam apenas uma proteção para o dado, mas viabilizam inclusive a produção de massa de dados mais rapidamente. Ao invés de restaurar um backup de Teras e Teras, você pode gerar uma massa bem menor, porém com representatividade (mascarada ou não). Isso é mais rápido e econômico do que restaurar backups.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    • Marcado como Resposta JM_analista quarta-feira, 29 de agosto de 2012 07:46
    terça-feira, 28 de agosto de 2012 22:24