Recentemente reformulei o meu sistema de backup com o objectivo de ficar o mais próximo possível de algo sério gastando perto de nada. Achei por bem documentar aqui o processo para a eventualidade de interessar a alguém.

Hardware

Evidentemente necessita-se de um computador; nada particularmente poderoso mas sim eficiente e idealmente compacto. Um SBC como um Raspberry Pi serve, mas a performance dos mesmos é limitante em tópicos como compressão. Firmei-me num portátil antigo.

Adquire-se um a três discos mecanicos, consoante a necessidade de espaço e redundância.
É indesejavel usar muitos, particularmente se tiverem pouco espaço (<=1TB) uma vez que se sentem na conta da eletricidade.

Discos vindos de classificados são um tiro no escuro. Muitas dezenas de milhar de horas de uso ou bad sectors são avisos claros de discos inadequados para manter operacionais. Estas caraterísticas são visualizáveis no SMART dos discos.

Tipicamente os portáteis só tem uma ou duas portas SATA, uma das quais frequentemente “Micro SATA”; alem disso as portas em portateis tem potênciais de 5 volts e os discos de 3.5” requerem 12 volts para operar. Já a maioria dos SBCs não tem SATA nem PCIe, e muito menos uma alimentação adequada. Requere-se como tal uma combinação de:

  • Extensões de SATA para SATA (só dados)
  • Adaptador de Micro SATA para SATA (só dados)
  • Controlador Mini PCIe para SATA
  • Adaptadores USB para SATA
  • Transformadores eletricos SATA.

É importante considerar que a velocidade de transferência máxima será o mínimo entre o canal e as especificações dos discos no mesmo. USB 2.0 é potêncialmente limitante; SATA nativo, PCIe ou USB 3.0 não serão. Caso tenha de ser utilizado USB 2.0 que se usem canais distintos para cada disco.
É possível ver que porta USB é que pertence a cada canal com o comando lsusb (ligando algo e vendo em que bus acabou).

Excetuando alguns adaptadores USB que contemplam uma entrada externa para alimentação do disco (como caixas externas), os restantes métodos requerem criatividade. Na minha configuração em particular, utilizei dois discos com dois adaptadores USB para SATA e uma fonte de alimentação como alimentação dos discos.

Nota: As fontes de alimentação de computador podem ser arrancadas ligando o fio verde do conector ATX a qualquer fio terra (pretos), no entanto é importante não fazer isto antes de meter alguma carga na fonte; as mesmas não foram feitas para operar sem carga.

Considerações adicionais

Pode ser proveitoso colocar arrefecimento adicional, particularmente nos discos. Caso se use um portátil e o mesmo se encontre fora do respetivo chassis é pertinente considerar as temperaturas na motherboard, especialmente em locais que o chassis atuava como dissipador. Usar a mão como termometro não faz mal supondo que está seca.

Nota: Computadores mortos tendem a ser uma boa fonte de ventoinhas e dissipadores gratuitos.

Portáteis costumam ter baterias. Por pior que seja o estado das mesmas, 3 minutos de energia é a diferença entre desligar em segurança e ter dados corrompidos.

Localização

Pessoas cujo emprego dependa de segurança de dados defendem a estratégia “3-2-1”:

3 cópias dos dados, 2 backups em meios diferentes, 1 deles noutra região geográfica.

Na localização ideal, nenhuma catástrofe pode derrubar todas as cópias de uma só vez, seja com um pico de tensão, incêndio, cheia, terramoto, etc …
A casa daquele familiar que vive em Trás-os-Montes, é um bom local, mas a maioria das pessoas não tem tal familiar. Colocar na outra ponta da casa pode ser razoável, tudo depende do risco que se quer tomar, cabe à consciência de cada um.

Em backups locais e dependendo do volume de dados, pode ser conveniente utilizar-se Wi-Fi. Nunca será mais estável, rápido ou seguro do que cabo ethernet, mas pode ser rápido o suficiente e funciona em locais inviáveis a cabo. Nesse caso é pertinente utilizarem-se antenas direcionais (como Yagi’s) em vez das omnidirecionais, e se possível estabelecer uma intranet, desconectada da Internet. Se possível é preferível a utilização de powerline a Wi-Fi.

Backups remotos deverão de evitar exposição à Internet com o uso de global area networks como o ZeroTier ou de VPNs pessoais (como o Wireguard ou OpenVPN).

Software

Um servidor, seja qual seja, quer-se quietinho. Software explosivo (como Windows ou sistemas operativos em rolling-release) é o oposto do que se quer. Debian, CentOS ou FreeBSD são sistemas operativos solidos que se podem “meter e esquecer”, podendo ser atualizados sem expectativa que surja drama.

O particionamento é relativamente indiferente, no entanto deixo algumas sugestões:

  • Em caso de dúvida uma partição para o sistema mais 1GB de swap chega.
  • RAID deve de ser feito com recurso a software e aplicado em primeiro lugar.
  • LVM pode ser útil, especialmente caso não seja utilizado RAID.
    É trivial mudar hardware ao vivo com LVM.
  • Caso se vá guardar algo mais é recomendado encriptar pelo menos a partição dos dados.
  • Devem de ser utilizar os sistemas de ficheiros EXT4, BTRFS ou ZFS.
    Em caso de dúvida EXT4 é o caminho a seguir.
    BTRFS oferece mais que EXT4 mas é considerado algo instavel (particularmente em RAID 5/6).
    ZFS não está upstreamed e pode ter um consumo avultado de RAM.

A wiki do Arch Linux é um excelente manual de instruções para estes processos, mesmo noutros sistemas operativos.

Requisitos

Um servidor de backup quer-se de leitura apenas. Se o alvo do backup se apagar por acidente, for atacado ou tenha falha de hardware, não é suposto o backup perder os dados. Quer-se uma sucessão de mementos regulares e resistentes a serem apagados.

A cadência desejada dos mementos pode ser por exemplo:

Uma cópia por hora nas últimas 24 horas, uma cópia por dia na última semana, e uma copia semanal no último mês é uma cadência

Manter copias completas gasta imenso espaço e largura de banda, pelo que é desejável recorrer a diferenciais, transferindo e armazenando apenas as mudanças.

Borg

O Borg é uma de diversas soluções de backup que existem, e permite permite alcançar o desejado. O seu uso passa pela manutenção de um repositório que mantém registo dos conteúdos, os deduplica, comprime, encripta e apaga quando deixam de ser relevantes.

O primeiro passo é portanto criar o repositório:

borg init --encryption=xxxx ~/repositorio/

Pode ser desejável não encriptar o repositório se a própria partição estiver encriptada. As opções de encriptação estão aqui.

Os dados a armazenar podem tornar-se acessiveis por SSH (ou NFS, SMB, …). Em dados sensiveis é particularmente importante que se utilizem keyfiles em vez de passwords (consulta-me).

sshfs [email protected]:/informação ~/remoto/ -o IdentityFile=~/.ssh/ssh_key

Por fim instancia-se o atual memento dos dados com:

borg create \
    --filter AME \
    --list \
    --stats \
    --progress \
    --compression zstd,22 \ # 22 é o máximo
    --files-cache ctime,size \
    ~/repositorio::'{now}' \
    ~/remoto/pasta1/ ~/remoto/pasta2/ ...

A parametrização deste comando varia com o desejado. Neste caso são conservadas duas pastas, com compressão, o criterio de modificação é a data de modificação e o tamanho e o Borg descreve o que vai acontecendo. As opções de encriptação deste comando estão aqui.

Por fim, é ocasionalmente feita a limpeza dos backups indesejados com um comando similar a:

borg prune \
    --list \
    --keep-daily    x \
    --keep-weekly   y \
    --keep-monthly  z \

Depois de testado este procedimento deve de ser colocado num script que será executado periodicamente (por exemplo pelo systemd).

Recuperação

Aconteceu uma tragédia. Recuperar os dados é tão simples como aparecer com um disco novo e retira-los do repositório:

borg extract ~/repositorio::versão

O bom funcionamento deste procedimento deve de se testado ocasionalmente ANTES de acontecer uma tragédia.

E é só isto. Bons backups :)