Discuta este tópico no fórum

Se este conteúdo te ajudou, deixe um presente!

segunda-feira, 29 de janeiro de 2018

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 2

Mais um artigo da série sobre o OpenWrt/LEDE.

No artigo anterior, comentei o que uma solução de backup deveria ter. Passei pela solução que usava anteriormente (crashplan) e uma brevíssima introdução aos recursos do borg. Neste artigo, vamos configurar o repositório.

O esquema ficou desta forma:


O computador roda o borg e copia os arquivos (amarelo) para um repositório no roteador. Esse repositório é acessado por CIFS e aponta para um HD Externo conectado na USB. Em um segundo momento, um rsync sincroniza esse repositório com um destino remoto utilizando o rsync. O destino remoto também é um roteador com um HD Externo conectado, mas poderia ser qualquer destino com suporte a rsync. A comunicação do rsync é feita dentro de uma VPN, que interliga o roteador de origem e destino do repositório. Muito complicado? Nem tanto. Como diria Jack, "vamos por partes...".

Neste artigo vou abordar apenas a flecha vermelha. No próximo trato da verde.

Instalação


O primeiro passo para usar o borg é a instalação. A versão do repositório do ubuntu 17.10 é suficiente:

pc# apt install borgbackup

Ou baixe diretamente do projeto. Eu prefiro a segunda opção. Este é um arquivo "autosuficiente", só baixar, dar permissão de execução e usar.

Repositório


O destino do repositório será no roteador. Como não vou rodar o borg lá, terei que acessar o disco do roteador por um sistemas de arquivos em rede. Optei pelo CIFS (samba). No lado do cliente, eu gosto de usar o autofs:

pc# apt install autofs cifs-utils

Eu gosto de configurar o /cifs, que monta sob demanda compartilhamentos CIFS:

/etc/auto.master:
/cifs /etc/auto.smb --timeout=300

E dispare o serviço

pc# systemctl enable autofs
pc# systemctl start autofs

Seu roteador estará acessível em /cifs/router/<compartilhamento>/

Iniciando o repositório


Para criar um novo repositório, é só rodar:

pc# borg init /cifs/router/<compartilhamento>/borg

Os repositórios borg podem ser protegidos por uma chave. Para uso interativo, isso não é problema. Contudo, se o objetivo é fazer backup agendado, não será a melhor opção. O borg permite informar uma chave por variável ambiente. Crie um arquivo de senhas ou gere um aleatoriamente.

pc# mkdir -p /etc/borg
pc# openssl rand -base64 32 > /etc/borg/borg.key 
pc# chmod 400 /etc/borg/borg.key

Eu pessoalmente prefiro senhas boas mas que possam ser decoradas. Mas gosto é gosto.

Você agora pode passar essa senha chamando o borg desta maneira:

pc# BORG_PASSCOMMAND="$(cat /etc/borg/borg.key)" borg ...

Ou também pode usar diretamente o BORG_PASSPHRASE com o conteúdo da senha:

pc# BORG_PASSPHRASE="naoconteparaninguem" borg ...


Fazendo backups


O backup é feito com uma chamada simples do borg. Um exemplo já passando a senha seria:

pc# BORG_PASSPHRASE="naoconteparaninguem" borg create /cifs/router/<compartilhamento>/borg /meu/dir1 /meudir2 ...

Não vou me estender nas diversas opções disponíveis. Porém, é indicado colocar isso em um script para facilitar a chamada.

Os backups no borg são rápidos e econômicos. Ele só copia as diferenças e faz isso de forma bem eficiente. Normalmente uma chamada de backup sem alteração é executada em menos de 30 segundos. Ele tem um cache local dos índices e um novo backup sem muitas alterações gera pouca carga sobre o repositório. Já que é tão barato, resolvi fazer uma vez por hora. A chamada do "borg create" foi colocada em um script em /etc/cron.hourly/meubackup. Quem quiser, alternativamente, pode editar a cron diretamente com 'crontab -e'.

Pronto! Temos uma rotina de backup!

Limpando o repositório


OK, tudo lindo e maravilhoso... mas vai ficar fazendo backup toda hora (literalmente) e nunca apagar nada? Bem, um novo backup sem alteração é bem econômico e fazer muitos deles realmente não é algo significativo. Porém, as diversas versões de arquivos alterados e apagados, e mesmo os metadados, eventualmente encheriam o disco. E, em alguns casos, eliminar permanentemente alguns dados pode ser salutar, em especial quando iniciar um novo relacionamento. 

Para apagar, o borg pode executar o prune baseado em critérios como "mantenha todos os últimos backups desta semana, um backup por dia nos últimos 10 dias com backup, 6 backups semanais...". Eu, por exemplo, estou usando:

pc# BORG_PASSPHRASE="naoconteparaninguem" borg prune --keep-within 1d --keep-hourly 20 --keep-daily 30 --keep-weekly 53 --keep-yearly 20 /cifs/router/<compartilhamento>/borg

Pode parecer estranho pedir para manter todos os backups das últimas 24 horas, mas somente um backup por hora nas últimas 20 horas. Bem, como o computador nem sempre está ligado, os 20 backups horários podem ser mais antigos do que "todos os backups das últimas 24 horas". Tudo isso depende de cada caso.

Como esta operação pode demorar mais tempo do que um backup normal, eu rodo semanalmente. Contudo, fica a gosto do cliente.

No próximo artigo, a parte de sincronia remota do repositório. Se pintar uma dúvida, tem sempre o fórum deste blog.

Até a próxima!

sábado, 6 de janeiro de 2018

LEDE renomeado para OpenWRT: projetos "reunificados"

Mais um artigo da série sobre o OpenWrt/LEDE.

Faz quase um ano que postei sobre o lançamento do LEDE, um fork do projeto OpenWrt. Enfim, muita água rolou e agora temos novidades significativas. Mas o que aconteceu desde o lançamento do LEDE?

O surgimento do LEDE atraiu todos os desenvolvedores do OpenWrt. Ficou somente os desenvolvedores originas, "donos da marca" e da infraestrutura. Bem, como eles já não faziam grandes contribuições por algum tempo, o OpenWrt parou de ter um desenvolvimento significativo. Em suma, o OpenWrt mo-rré-u. O LEDE, em contrapartida, estava mais vibrante que o OpenWrt antes dele.

Então, o tempo passou, houveram conversas, e chegaram a um acordo. Os desenvolvedores do OpenWrt não tinham muito o que barganhar além do nome. Por uma série de votações, ficou decido que:

  1. Os desenvolvedores remanescentes do OpenWrt ganhariam acesso de escrita ao LEDE, se tornando efetivamente desenvolvedores do projeto (por meio de votação como para qualquer novo desenvolvedor);
  2. O código usado seria do LEDE, com eventuais melhorias exclusivas do OpenWrt sendo submetidas para avaliação, como qualquer outro patch (bem, sendo GPL, qualquer um já poderia ter feito isso sem pedir autorização);
  3. Mantém-se as regras do projeto LEDE;
  4. O OpenWrt CC está, na prática, abandonado, sendo recomendado o uso do LEDE 17.04.x;
  5. Todos os direitos do OpenWrt e do LEDE foram doados para uma entidade sem fins lucrativos isenta, para não ter mais um "dono da bola";
  6. O nome do projeto LEDE será alterado para OpenWrt.
Este último ponto, sobre o nome, foi polêmico. Não houve uma maioria absoluta mas uma votação equilibrada entre: voltar ao OpenWrt, manter o LEDE e posição neutra. Por poucos votos (acho que foi um), ganhou a volta ao nome OpenWrt.


E o que muda de agora em diante? O LEDE já usa o nome OpenWrt na sua versão em desenvolvimento. A infraestrutura do LEDE deve assumir o domínio do openwrt.org. Os servidores antigos do OpenWrt serão absorvidos. A próxima versão do LEDE será chamada OpenWrt e o nome LEDE deve desaparecer com o tempo.

Falta ainda decidir outros pontos até o lançamento da próxima versão estável (nos próximos meses) como a solução de controle de bugs, fórum e wiki.

Resumão: O OpenWrt de antes mo-rré-u. LEDE foi renomeado para OpenWrt. O LEDE ganhou uns servidores e três desenvolvedores.

O lado bom é que os usuários do OpenWrt CC nem irão notar que mudaram de projeto. Quando a nova versão do LEDE...,digo, OpenWrt for lançada, será que nem uma nova versão do OpenWrt.

Até a próxima!

quinta-feira, 4 de janeiro de 2018

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 1

Mais um artigo da série sobre o OpenWrt/LEDE.

Neste artigo vou mostrar a estrutura de backup que, com o auxílio de roteadores OpenWRT/LEDE, permite o backup de arquivos na rede e o envio desse backup de forma eficiente para pontos remotos sem a necessidade de deixar o computador ligado. Como vai ficar muito longo, primeiro vou levantar os requisitos e comentar a solução selecionada. Em um segundo artigo mostro as configurações efetuadas.

Costumo dizer "não adianta rezar, só backup salva". Todo mundo sabe que é preciso fazer as cópias de segurança, que são importantes, etc, mas poucos realmente o fazem. Mesmo os "entendidos" não fazem backup por uma simples razão: dá trabalho e é chato. 

Um bom backup é feito de forma automatizada. Na maioria dos casos, só vamos lembrar dele quando precisar recuperar algo. E surpresa? Não tinha o backup!

Um bom backup não é uma simples cópia. Um bom backup deve ter versões, pois você pode levar um tempo para ver em algum momento sumiram suas fotos. Se tiver só uma cópia e ela foi feito depois do problema, não tem o que recuperar.

Um bom backup deve ser geograficamente distribuído. Mas precisa? Pense que se alguém for roubar sua casa, ele pode querer levar aquele HD externo junto com o seu computador. Pode ocorrer um pico de tensão e queimar o HD e o computador enquanto o backup era feito. Pode pegar fogo na sala onde ambos estão. Preferencialmente, nunca deixe todas as suas cópias no mesmo local. Vai copiar em um HD externo? Use dois, de forma intercalada e não deixe as duas cópias e o seu computador juntos. E dizem que sou paranoico.

Como os backups podem estar afastados do seu controle (geograficamente distribuído), um bom backup é cifrado ("criptografado"). Não precisa ser algo para enfrentar a NSA, mas algo que o custo para quebrar seja maior que o valor de seus dados. Não precisa ser muito chato neste ponto: uma senha em texto plano pode cifrar os backups e este arquivo pode ficar aberto no seu computador. Afinal, se alguém roubar essa senha no seu computador, ele vai poder abrir os arquivos no backup, que ele já teve acesso para poder ler o arquivo de senhas.

Principalmente, um bom backup deve ser recuperável. De nada adianta fazer o backup e descobrir que você não pode recuperá-lo. Ele deve, no mínimo estar íntegro.

Como posso fazer tudo isso? Pague por um serviço de backup na nuvem. Ou tenha um pouco mais de trabalho e faça você mesmo. Neste artigo vou mostrar a infraestrutura que montei para fazer backups de forma a oferecer esses recursos com o mínimo de custo computacional e de forma mais automatizada possível.

Eu usei por anos o Code42 Crashplan. Porém, eles abandonaram a versão gratuita, que permitia o backup distribuído entre amigos. Ele funcionava surpreendentemente bem, fazendo o backup de forma oportuna tanto no meu roteador (montado por CIFS) como nos meus amigos remotos. O problema era ter que deixar o computador ligado por horas (ou dias) para enviar um novo lote de fotos. Era um desperdício de energia e vida-útil do computador. A parte mais triste era que o backup já estava disponível 24/7 em um disco conectado no roteador. Só não tinha como copiar para o local remoto. O Crashplan foi desenvolvido em Java e não tinha a menor condição de rodar em um roteador com 64 MBytes de RAM.

A sincronia dos repositórios de backup com o ponto remoto também poderia ser feita usando o rsync. Contudo, o formato do repositório de backup mudava tanto a cada novo backup que o volume de dados a ser copiado superava em muito os novos arquivos salvos. A solução, em tempos e tempos, era fisicamente  levar um dos repositórios ao encontro do outro e copiar localmente os arquivos (mesmo com rsync e USB 3.0, levava horas).

Então, além dos que se espera de um bom backup, uma solução ideal deveria enviar os arquivos de forma minimamente eficiente para o roteador (ex: CIFS, SFTP). Alternativamente, também poderia ser viável utilizar um agente da solução diretamente no roteador. Todavia, portar novos programas para o ambiente do roteador nem sempre é possível.

O envio dos dados ao repositório remoto também era um requisito importante. Eu realmente queria evitar o computador ligado para enviar dados que já estão no roteador. A solução de backup, então, deve facilitar a replicação. Isto pode ser obtido se o formato do repositório for eficientemente sincronizável por rsync. Outra solução seria com o agente rodando no roteador, que dificilmente teria sucesso pelas restrições do roteador.

Nas pesquisas por uma solução de backup, encontrei o borg. Ele está disponível em algumas distribuições e também em um arquivo autossuficiente. Tem uma arquitetura bem simples. Nem configuração existe no computador. Você apenas aponta para o repositório e manda uma série de caminhos. É um software livre, que vai evitar o mesmo problema de abandono do Crashplan. Até tem uma interface web, mas realmente, estou mais interessado na linha de comando. Uma parte importante do borg é a estrutura do repositório de backup. Os dados são salvos em blocos deduplicados no repositório e um "backup" referência uma série de blocos que formam a estrutura de diretório. Novos backups só enviam a diferença. E os backups não sobrescrevem dados antigos. Assim, ele é excelente para ser sincronizado usando rsync! A impressão que toda a estrutura do repositório foi pensado com esse propósito.

A única limitação é que você deve ter um repositório por máquina. O borg guarda um cache dos blocos já copiados para agilizar novos backups. Esse cache é validado antes de fazer o backup. Se os metadados do repositórios estiverem mais novos, o cache é invalidado. Com duas máquinas usando o mesmo repositório, toda vez que a outra fizer o backup, o próximo backup não utilizará o cache e será bem mais lento pois terá que baixar todos os metadados do repositório. Mas isso não foi um limitador para meu uso.

No próximo artigo, vamos direto para a configuração do borg utilizando o roteador como destino e sincronizador de backups. Até a próxima!

Se pintar uma dúvida, tem sempre o 
fórum deste blog.