DEV Community

Cover image for Proteção de Dados
Mariana Carvalho for Sysadminas

Posted on

Proteção de Dados

Como mencionamos no capítulo anterior, proteger fisicamente os equipamentos é muito importante para que não haja nenhum tempo perdido na execução e funcionamento das atividades. Além disso, proteger os dados que estão contidos nesses equipamentos é igualmente importante.

Na indústria, vemos que as empresas usam estratégias de proteção de dados para prevenir que arquivos sejam deletados erroneamente, que dados sejam corrompidos, que aplicações sejam afetadas e caso haja algum tipo de desastre natural (como enchentes, furacão, terremoto, entre outros).

Há duas estratégias que as empresas podem utilizar para proteger esses dados: 1) através da estratégia de backup e 2) estabelecendo um centro de dados que será acionado caso haja falhas no centro de dados principal, também chamado de centro de dados de recuperação de desastres (ou Disaster Recovery, DR, em inglês).

Atualmente, as empresas se utilizam mais dos backups do que da implementação de um centro de dados secundário, já que estabelecer um centro de dados secundário significa duplicar toda a infraestrutura. O que se tem visto são empresas usando provedores de nuvens públicas como solução para DR.

Backup

O backup é uma cópia dos dados principais, que pode ser armazenada em fitas (mais baratos, mas menos performáticos), discos (permitindo o acesso mais rápido e confiável), ou nuvem pública (mais seguro, porém mais caro do que os métodos tradicionais de fita e disco). O objetivo do backup é a recuperação dos dados caso eles sejam perdidos ou corrompidos.

Ao desenhar uma estratégia de backup, o ideal é que a empresa tenha definido:

  • Janela de backup
  • Tempo de retenção
  • Arquivamento
  • Tempo para restauração (também conhecido como RTO - Recovery Time Objective, em inglês)

    Para definir o RTO, a empresa precisa se perguntar: quanto tempo estou disposto a deixar minha aplicação indisponível sem causar impacto nos negócios?

  • Tolerância à perda de dados (também conhecido como RPO - Recovery Point Objective, em inglês)

    Para definir o RPO, a empresa precisa se perguntar: qual quantidade de dados pode ser perdida sem causar impacto negativo no negócio? O RPO também é medido em tempo, desde a falha ocorrida no sistema, até a restauração do último backup feito.

    Alt Text
    Referência da imagem aqui. Adaptação: Mariana Carvalho.

    Estratégia de Recuperação de Desastres

    Implementar um plano de Recuperação de Desastres está muitas vezes dentro da Estratégia de Continuidade de Negócios de uma organização. Por Estratégia de Continuidade de Negócios entende-se, segundo a Norma BS 25999-2, que esta é a “abordagem de uma organização que garanta a sua recuperação e continuidade ao se defrontar com um desastre, ou outro incidente maior ou interrupção de negócios”.

    A Estratégia de Recuperação de Desastres visa, portanto, a garantir que o negócio não seja interrompido no que diz respeito à área de Tecnologia da Informação (TI), cuidando do centro de dados, servidores, laptops, banco de dados, aplicações, entre outros.

    Os principais objetivos de uma Estratégia de Recuperação de Desastres são:

  • Reduzir riscos caso algum desastre aconteça
  • Diminuir impacto nas operações, que, por sua vez, impacta no negócio e faturamento
  • Prosseguir com as operações em caso de desastre
  • Estar em conformidade com leis de diferentes setores
  • Uma estratégia de Recuperação de Desastres deve ser atualizada de tempo em tempo para que todos os componentes estejam funcionando propriamente, estejam em conformidade com diversas leis e normas e continuem alinhados com os objetivos de negócios da empresa como um todo.

    Caso conheça indicações de livros, certificações ou cursos, fique à vontade para deixar nos comentários. Ficarei feliz em adicionar a esse post!

    Esse texto faz parte do Guia de Infraestrutura de Tecnologia de Informação publicado no medium, no dev.to, e na Open Library. Para checar todos os capítulos, clique aqui e acesse a Introdução.

    Próximo capítulo: Software Livre e Software Proprietário

    Top comments (0)