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.