Resultados 1 a 2 de 2
  1. #1
    Membro
    Data de Ingresso
    Nov 2014
    Posts
    10

    Backups: dicas e técnicas para salvar os seus dados com segurança

    Nesse tópico vamos dividir algumas dicas de backup para o seu servidor ou seus arquivos. A intenção aqui não é abranger todas as ideias possíveis em um único post, mas levantar uma discussão para que todos compartilhem dicas.

    [[ Dicas para backups ]]

    - RAID1.
    Nem todo mundo pode investir em HA (alta disponibilidade) permitindo-se perder até um servidor (físico ou virtual) e tudo continuar funcionando. Mas contratar RAID1 hoje é fácil e barato em qualquer datacenter. No RAID1 permite-se que 1 ou mais discos falhem e que o sistema continue funcionando normalmente. Imagine que você tem dois discos de 1TB em RAID1. Vocẽ terá para uso apenas 1TB de dados, mas toda modificação/adição de dados será replicado para ambos os discos, de tal maneira que os dois sempre estarão iguais. O Kernel Linux (no caso de RAID1 via software) ou a controladora RAID (no caso de RAID1 via hardware) controlam essa replicação automaticamente e, no caso de falhas, quase sempre conseguem recuperar algum disco de uma falha (desde que o disco não esteja com falha de hardware). Se um disco falhar e não puder ser recuperado ao RAID1, ele será removido do RAID1, mas o sistema continuará funcionando sem qualquer problema. Teoricamente você pode fazer RAID1 de um disco, mas ele só faz sentido a partir de dois discos (afinal o RAID1 daz espelhamento/replicação dos dados). Quando você trocar o disco com problema e adicioná-lo ao RAID1, a controladora ou o Kernel Linux automaticamente fará a sincronia de ambos e você voltará a ter os dois (ou mais) discos exatamente iguais. Os discos precisam ter o mesmo tamanho (se forem diferentes, por exemplo 320GB e 500GB, você poderá usar apenas 320GB).

    - Backup local.
    Nem só de RAID1 vive o homem. Manter alguns backups locais é bom. Se você precisar deles, eles estarão a fácil e rápido acesso para recuperação.

    - Backup remoto.
    RAID1 é bom e funciona bem, mas e se a sua máquina explodir? Ok, exagero... Talvez não sofrer uma combustão, mas já vimos incêndio em data center, inundação de salas de rack, falha de energia que provocou a corrupção dos superblocos (e seus backups) em todos os discos do RAID1 quebrando a estrutura do sistemas de arquivos, invasão seguida de formatação do servidor e tantos outros incidentes possíveis que podem fazer com que todos os dados contidos na mesma máquina corrompam ou desapareçam. E é aqui que entra o backup remoto. O backup remoto não precisa ser instantâneo como é o RAID1 (replicação imediata), mas pode ser feito uma vez ao dia em uma infraestrutura independente do servidor em produção (aquele que está executando os seus serviços). E se algo muito ruim acontecer, você pode comprar outra máquina e recuperar o seu sistema a partir do backup remoto.

    - Vários backups.
    É até óbvio, mas manter um histórico de vários dias de backup é essencial. Muitas vezes você não perdeu todos os seus arquivos, mas pode ocorrer de alguns deles terem desaparecido (remoção acidental, usuário mal intencionado etc). Do ponto de vista do sistema operacional, tudo está normal, mas para você, não. E você pode demorar para percerber o desaparecimento dos arquivos! Mas não se você mantiver um histórico!
    Como sugestão, você pode manter o backup dos seus 7 últimos dias, 2 das últimas duas semanas (escolha um dia da semana que você considere melhor) e 2 do último mês (dia 1 e dia 15, por exemplo).

    - Muitos backups mesmo!
    Nunca backup é demais, mas fazer backup tem um custo: mais discos, mais máquinas, mais custo de infraestrutura, aluguel de servidor externo etc. A dica aqui é olhar o mercado de NAS (storage) e Nuvem (Cloud) em busca de custos menores. Por cerca de 100 dólares você consegue uma NAS, no exterior, de pelo menos 1TB. Ou você pode recorrer aos serviços de Nuvem. Por exemplo, o Dropbox. Na sua versão Personal, por 9,90 dólares mensais, você tem 1TB de espaço e até 30 dias de revisões (se algo for apagado ou substituído, você pode recuperar até 30 dias para trás). Na versão Enterprise o bolso é o limite, podendo ter até 365 dias de revisões. Há muitas opções a serem avaliadas. O importante é escolher uma empresa conceituada e que criptografe os seus dados (O Dropbox, nesse exemplo, usa AES 256bits).

    - Backups protegidos.
    Todos os seus backups devem ser criptografados. Só você pode recuperá-los. E mais: Jamais faça um script que envie os backups do seu servidor de produção para o seu servidor de backup. Se alguém invadir o seu servidor principal, automaticamente ele obterá acesso ao servidor remoto de backup. Use um rsync daemon no servidor em produção que permita apenas que o servidor de backup remoto copie determinados diretórios. Ninguém mais pode ter direito de escrita, além do administrador, no servidor de produção. No máximo leitura de diretórios específicos para o seu servidor de backup remoto.
    - Alertas para todos os lados!
    Vocẽ deve ser alertado sempre que: um script de backup falhar, a partição estiver quase cheia, um backup remoto falhar, o serviço crontab estiver inativo, alguma falha de disco que prejudicou ou está prejudicando o seu raid e todos os eventos relacionados aos seus arquivos. Não deixe os problemas acontecerem, evite-os. Sistemas de monitoramento estão disponíveis, em sua maioria gratuitamente, para lhe salvar tempo, trabalho e dinheiro.

    - Faça o seu backup corretamente!
    Utilize sempre rsync para copiar os seus dados. O rsync é uma ferramente que pode garantir que a cópia resultou em um arquivo idẽntico ao original. O rsync utiliza por padrão o MD5, mas pode utilizar SHA1, fornecendo uma garantia extra de integridade (desculpe o pleonasmo, mas como toda hash, o MD5 pode ter colisão, só que até hoje não se conhece ou não foi provado que existam colisões para o MD5). Explicarei mais abaixo como utilizar o rsync (ver post abaixo)..

    Nota: Nós vimos apenas uma vez a cópia de arquivos falhar e o rsync não nos informar. Isso aconteceu em uma máquina desktop sem memórias ECC. Um pente de 1GB estava com problemas e a faixa de memória corrompida era exatamente onde a biblioteca do rsync estava alocada. Isso é muito, mas muito difícil acontecer (só temos registro de um evento desse em 19 anos de trabalho com suporte na Mandriva Linux) e não foi falha do rsync, mas de um pente de memória que afetou a coerência do rsync exatamente na parte que checa o MD5.

    - Crie arquivos de paridade do backup principal
    Arquivos de paridade são arquivos que permitem que você corrompa e até perca pedaços dos arquivos e recupere-os "magicamente". Vocẽ pode controlar o tamanho dos arquivos de paridade. Quanto maiores eles forem, mais partes do arquivo serão recuperáveis. Quanto menores, obviamente mais difícil fica corrigir partes corrompidas. Abaixo explicarei como isso funciona (ver post abaixo).
    [[ continuação no segundo post, pois acabou o espaço do primeiro post ]]
    http://www.mandriva.com/br/suporte/
    Suporte técnico, consultoria e treinamento Linux da Mandriva Brasil.
    Experiência de longa data com sistemas Linux e Unix.

  2. #2
    Membro
    Data de Ingresso
    Nov 2014
    Posts
    10
    [[ continuação do primeiro post, pois faltou espaço ]]

    [[ Dicas para cópias de arquivos/backups ]]
    - Sempre faça suas cópias utilizando o comando rsync.
    O comando rsync, por padrão, faz uma checagem MD5 do arquivo copiado e compara com o md5 do original. Se houver um erro na cópia, ele avisará. Ainda não se conhece uma falha (colisão) na hash MD5, o que na prática significa que para cada arquivo existe um único hash MD5 e que arquivos que possuem a mesma hash MD5 são idênticos.

    Como gerar a hash md5 de um arquivo?
    Código:
    bash-4.2$ md5sum amd.png 
    44ee4f76d55bb2ba3e53db8dab5bca50  amd.png
    Como fazer uma cópia utilizando rsync para locais remotos?

    Código:
    rsync -az --progress -e "ssh -p portassh" arquivo1 arquivo2 arquivo3 dir1/ usuario@servidor:/path/de/destino/
    Explicando:
    -a: Conjunto de parâmetros recomendados para rsync (requerido para copiar diretórios)
    -z Utiliza compressão gzip para enviar os arquivos
    -e: Diz ao rsync que ele utilizará um shell remotp
    portassh: Porta ssh do destino dos arquivos (seu rsync será feito dentro de um túnel seguro do ssh)
    usuario: Usuário do servidor de destino que receberá os arquivos
    servidor: IP do servidor
    /path/de/destino/: Local onde os arquivos serão copiados

    Exemplo:

    Código:
    rsync -az --progress -e "ssh -p 22" meuarquivo.tar.gz meudir/ root@210.12.17.198:/backups/
    Como fazer uma cópia utilizando o rsync para um diretório local?

    Código:
    rsync -a --progress arquivo1 arquivo2 arquivo3 /path/de/destino/
    Exemplo:

    Código:
    rsync -a --progress arquivo1 arquivo2 arquivo3 /backup
    Como verificar se houve erro?
    O retorno do rsync para a saída padrão (stdout) mostrará o erro. Para vocẽ descobrir via shell script, basta após o comando do rsync recuperar o retorno do rsync:
    Código:
    retornorsync="$?"

    - Crie arquivos de paridade utilizando o par2 e faça backup deles.
    O par2 permite que você recupere partes corrompidas de um arquivo utilizando bits de paridade. Imagine que você fez um backup de um sistema inteiro em um arquivo chamado backup.tar.gz e que você enviou por rsync para seu storage de backup sem nenhum problema. Por azar, você teve seu servidor destruído e o seu servidor de backup teve o sistema de arquivos corrompido. Trágico! Você teve de enviar todos os seus discos para uma empresa de recuperação. Quem já passou por uma situação parecida já sabe que o que for recuperado, dependendo do problema que ocorreu, em sua maioria serão dados corrompidos. Como recuperar? Existem ferramentas que tentam recuperar arquivos corrompidos, mas com uma baixíssima porcentagem de sucesso. Se você tiver arquivos de paridade, os seus riscos de perda de dados diminuem mais ainda!

    Agora imagine outra situação: Você tem um arquivo de backup muito grande que foi dividido em 10 partes para ser gravado em uma determina mídia (imagine que cada arquivo tem 4GB e você gravou em um DVD). Vamos supor que você perdeu a 8a mídia e que você precisa recuperar o seu sistema ainda hoje (o que quer dizer que você precisa das 10 partes para remontar o arquivo de backup). Você até tem uma cópia da 8a mídia em algum lugar distante e haverá um tempo grande para ela chegar até você (download, correio ou o que for; nessas horas, tudo acontece!). Se você tiver criado os arquivos de paridade com redundância suficiente para cada parte perdida (4GB), você pode simplesmente recriar a parte faltante com os arquivos de paridade (que ocupam poucos MB).

    Como funciona a ferramenta par2?

    Em qualquer distribuição linux você pode instalar o aplicativo par2.

    O aplicativo par2 possui basicamente três funções:
    create: Criar arquivos de paridade
    verify: Verificar os arquivos
    repair: Reparar os arquivos

    Como faço para criar os arquivos de paridade?

    Vou utilizar como exemplo a criação de arquivos de paridade da ISO do Mandriva Business Server gratuita.

    Código:
    par2 c -r20 MBS_1.0-soho.x86_64.iso
    Explicando:
    c: criar arquivos de paridade
    -r20: 20% de redundância na paridade
    MBS_1.0-soho.x86_64.iso: ISO do Mandriva Business Server


    Output do comando:
    Código:
    Block size: 260636
    Source file count: 1
    Source block count: 2000
    Redundancy: 20%
    Recovery block count: 400
    Recovery file count: 9
    Veja os arquivos criados:
    Código:
    497M Jun 26 18:50 MBS_1.0-soho.x86_64.iso
    
    9.5M Dec  2 18:45 MBS_1.0-soho.x86_64.iso.par.vol063+37.par2
    8.2M Dec  2 18:45 MBS_1.0-soho.x86_64.iso.par.vol031+32.par2
    4.2M Dec  2 18:45 MBS_1.0-soho.x86_64.iso.par.vol015+16.par2
    2.2M Dec  2 18:45 MBS_1.0-soho.x86_64.iso.par.vol007+08.par2
    1.2M Dec  2 18:45 MBS_1.0-soho.x86_64.iso.par.vol003+04.par2
    589K Dec  2 18:45 MBS_1.0-soho.x86_64.iso.par.vol001+02.par2
    295K Dec  2 18:45 MBS_1.0-soho.x86_64.iso.par.vol000+01.par2
    37M Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol255+145.par2
    33M Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol127+128.par2
    17M Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol063+064.par2
    8.2M Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol031+032.par2
    4.2M Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol015+016.par2
    2.2M Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol007+008.par2
    1.2M Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol003+004.par2
    589K Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol001+002.par2
    295K Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.vol000+001.par2
    40K Dec  2 18:47 MBS_1.0-soho.x86_64.iso.par.par2
    Com menos de 120MB de arquivos de paridade nós somos capazes de recuperar até 400 blocos da ISO do exemplo.

    Como verificar o meu arquivo de backup com o arquivo de paridade?

    Muito simples! Basta executar:
    Código:
    par2 v MBS_1.0-soho.x86_64.iso.par.par2 MBS_1.0-soho.x86_64.iso
    Exemplo de output com erro encontrado:
    Código:
    There are 1 recoverable files and 0 other files.
    The block size used was 260636 bytes.
    There are a total of 2000 data blocks.
    The total size of the data files is 521142272 bytes.
    
    Verifying source files:
    
    Target: "MBS_1.0-soho.x86_64.iso" - damaged. Found 1999 of 2000 data blocks.
    
    Scanning extra files:
    
    Repair is required.
    1 file(s) exist but are damaged.
    You have 1999 out of 2000 data blocks available.
    You have 400 recovery blocks available.
    Repair is possible.
    You have an excess of 399 recovery blocks.
    1 recovery blocks will be used to repair.
    E para recuperar?

    No comando acima, o par2 mostrará os blocos com os erros e dirá quais .par.volXXXXXX.par2 ele precisará. Então, no diretório onde você executará a recuperação, armazene os .par.volXXXXXX.par2 requisitados. Como eu tinha todos os .par, eu coloquei como parãmetro todos eles.

    Código:
    par2 r MBS_1.0-soho.x86_64.iso.par* MBS_1.0-soho.x86_64.iso
    output do comando:
    Código:
    Repair is required.
    1 file(s) exist but are damaged.
    You have 1999 out of 2000 data blocks available.
    You have 400 recovery blocks available.
    Repair is possible.
    You have an excess of 399 recovery blocks.
    1 recovery blocks will be used to repair.
    
    Computing Reed Solomon matrix.
    Constructing: done.
    Solving: done.
    
    Wrote 521142272 bytes to disk
    
    Verifying repaired files:
    
    Target: "MBS_1.0-soho.x86_64.iso" - found.
    
    Repair complete.
    Será que funcionou mesmo?

    Código:
    bash-4.2$ md5sum MBS_1.0-soho.x86_64.iso
    25d7a77c6280de6a0eebd431e7a94757  MBS_1.0-soho.x86_64.iso
    bash-4.2$ md5sum MBS_1.0-soho.x86_64.iso.bkp 
    25d7a77c6280de6a0eebd431e7a94757  MBS_1.0-soho.x86_64.iso.bkp
    Sim! Arquivo recuperado! Eu trabalhei nesse exemplo com uma redundância alta, pode recuperar até 400 blocos da ISO do exemplo. Você pode diminuir ou aumentar, de acordo com a sua necessidade. Lembre-se que os arquivos de paridade são uma segurança extra para o seu backup e não um segundo backup. Você pode utilizar esse recurso sem que ele onere muito o seu sistema (afinal o backup por si só ja utiliza muitos recursos, principalmente de I/O).


    - Criptografe os seus dados!
    Não basta fazer backup. Vocẽ deve mantê-los livre criptografados. No caso de invasão e roubo, você deve garantir que ninguém possa recuperar os dados originais.
    Vou aqui usar o softwarelivre openssl para criptografar dados em AES 256bits.

    Gerando a chave de criptografia com senha:

    Código:
    openssl genrsa -out minhachavepriv.pem -aes256 4096
    (será solicitado uma senha)

    Obtendo a chave pública de sua chave privada:

    Código:
    openssl rsa -in minhachavepriv.pem -pubout
    Para salvar a chave pública:

    Código:
    openssl rsa -in key.pem -out minhachavepub.pem -outform PEM -pubout
    Agora vamos criptografar o seu arquivo/backup (para isso será necessário possuir a chave pública, que, obviamente, qualquer um pode ter acesso sem problemas):

    Código:
    openssl rsautl -encrypt -inkey minhachavepub.pem -pubin -in meubackup.txt -out meubackup.ssl
    E para remover a criptografia use o comando abaixo (agora sim você precisará de sua chave privada):

    Código:
    openssl rsautl -decrypt -inkey minhachavepriv.pem -in meubackup.ssl -out meubackup_semcriptografia.ssl
    http://www.mandriva.com/br/suporte/
    Suporte técnico, consultoria e treinamento Linux da Mandriva Brasil.
    Experiência de longa data com sistemas Linux e Unix.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens
  •