Introducción

Aínda que ao longo dos anos tiven bastante sorte ca miña información, o certo é que ata o de agora foi unha lotería. Se ben podía pasar, xa que non tiña moita información importante que perder.
Pero hoxe en día a cousa é distinta. Co proxecto de auto aloxamento que quero ter, a cantidade de información que vou manter no meu sistema será maior. Xa non serán ficheiros multimedia e pouco máis, senón que tamén haberá datos de saúde, contas, calendarios, etc. Unha vez o sistema estea estabilizado, pode que tamén teña datos da miña familia. Para que así tamén poidan deixar de depender das grandes compañías para almacenalos.

Así que isto presenta unha necesidade. A necesidade de ter un sistema que almacene esta información de xeito seguro e sobre todo que permita recuperala en caso de desastre, tamén de forma sinxela.
Buscando por internet lín sobre algúns sistemas, pero parece que o que ten mellores perspectivas é Borgbackup.

Neste artigo veremos como instalar a ferramenta, como crear un repositorio para almacenar as copias e como restaurar unha copia de seguridade.

NOTA: Sobre o último punto, o de restaurar as copias de seguridade, compre dicir que é algo que deberemos testar periódicamente. De xeito que o día que precisemos facer uso dos backups, non nos atopemos con que hai algún erro que impida recuperalas.

NOTA 2: Idealmente tamén montaremos un sistema de notificación para saber, tanto que a copia se fixo correctamente, como que fallou.

Borgbackup

Borgbackup, como se define na web do proxecto, é un programa de backup sen duplicados, que soporta compresión e autenticación cifrada.

O obxectivo principal de Borgbackup é prover unha forma eficiente e segura de protexer información. Cando dín que é son backups sen duplicados, refírense a que en base a unha copia só se almacenarán os cambios nas seguintes. O que permite aforrar espazo. Mentres que a autenticación cifrada, permite gardar a información en destinos nos que non temos toda a confianza.

Características principais

  • Almacenamento eficiente: como dixemos unha primeira copia será almacenada e en base a esta as seguintes so gardarán as diferenzas. Isto faise en base a fragmentos. Cada copia será dividida en varias partes e tan só aqueles pedazos que nunca se viran serán almacenados. Esta diferenciación será feita en base a un hash. Para isto non importa a orixe dos datos, se temos a mesma información de distintas fontes, so almacenaremos unha copia.
  • Velocidade: o código está implementado en C/Cython. Cachease a información dos fragmentos locais. Borrado rápido de arquivos non modificados.
  • Cifrado da información: a información pode ser cifrada utilizando cifrado AES de 256-bits. O cifrado será autenticado e comprobada a súa integridade. Cabe sinalar que o cifrado será feito do lado do cliente, así que o destino non verá a información plana.
  • Ofuscación: borgbackup pode ofuscar os tamaños dos ficheiros e fragmentos, para dificultar ataques de pegada.
  • Compresión: os datos poden ser comprimidos coma lz4, zstd, zlib, lzma. Indo de menos compresión e maior velocidade a maior compresión e menor velocidade.
  • Backups remotos: borgbackup pode restaurar copias de forma remota, pero se está instalado no host remoto conseguiremos grandes melloras.
  • Backups montables como unidades: podemos acceder aos contidos dos backups, coma se estivésemos a montar unha unidade extraíble. Co que poderemos movernos polos contidos para examinar ou recuperar información, co noso navegador de arquivos habitual.
  • Compatible cos principais sistemas operativos, aínda que en Windows será a través de WSL.
  • Libre e de código aberto

Borgbackup: Instalación outra vez docker

Cómo é costume outra vez vou usar á aplicación a través dun contenedor docker. Isto permitirame levar a funcionalidade a calquer outra máquina que queira, sen ter que andar instalando dependencias e configurando cousas. O único que precisarei será engadir as rutas que quero salvar, e o destino, e erguer o contenedor.

Neste punto o Dockerfile é o seguinte:

FROM alpine:latest

# Installing packages
RUN apk update \
  && apk add borgbackup openssh jq

ARG LOCAL_GID=$LOCAL_GID
ARG LOCAL_UID=$LOCAL_UID
ENV REPO_1_KEY=$REPO_1_KEY

# Creating borg user to avoid working with root
RUN addgroup -g ${LOCAL_GID} borg \
  && adduser -h /home/borg -s /bin/ash -u ${LOCAL_UID}\
  -g Borgbackup -G borg -D borg \
  && mkdir /home/borg/.ssh && mkdir /home/borg/mnt && chown -R borg:borg /home/borg;

# Copying ssh key to connect remotely
COPY secrets/.id_rsa /home/borg/.ssh/id_rsa
COPY scripts/cron_backup.sh /home/borg/cron_backup.sh

RUN chmod 600 /home/borg/.ssh/id_rsa \
  && chown borg:borg /home/borg/.ssh/id_rsa \
  && chmod +x /home/borg/cron_backup.sh

# Copy cronjob to keep container up
COPY scripts/cron_file /etc/crontabs/borg

# Change to user borg
USER borg
WORKDIR /home/borg

# Entry command to run cron and keep container running
CMD ["/bin/ash", "-c", "crond -f & tail -f /dev/null"]

Partindo dunha imaxe de Alpine Linux, para que sexa o máis lixeira posible, instalo as dependencias necesarias. A propia aplicación de borgbackup ca que xestionaremos as copias de seguridade. Openssh que me permitirá conectarme por SFTP ao servidor remoto. E jq que me permitirá traballar dende a shell con arquivos de formato JSON, que será como defina as configuracións de carpetas de orixe, destinos, etc.

A continuación creamos unas variables a utilizar. As de tipo ARG estarán dispoñibles durante a creación do contenedor. Neste caso serán os uid e gid do usuario e grupo do host. Para que no contenedor teña os mesmos id e por tanto poidan traballar cos arquivos sen problemas de permisos.

Despois creamos o grupo e o usuario con eses IDs. Creando tamén o directorio home do usuario e algunha outra carpeta necesaria.

Para poder conectar por SFTP, preciso a parella da clave pública que está no destino. Así que a copio no contenedor dende unha ruta na carpeta secrets. E aproveito tamén para copiar o script que se encargará de facer as copias. Este verémolo máis adiante.

Con chmod e chown ajusto os permisos e propietarios dos directorios e arquivos. Por exemplo, a clave id_rsa non funcionará se non se establece os permisos a 600. É dicir so o propietario pode leer e escribir nela.

O script cron_file será o encargado de programar cando se executarán as copias. No meu caso o contido é o seguinte:

# Cronjob to uun backup script every day at 0:00 AM
0 0 * * * /home/borg/cron_backup.sh

Xa por último indicámoslle ao contenedor que o usuario a utilizar será borg e que o directorio de traballo será a home do mesmo.

Na última liña engadimos un pequeno comando para que o contenedor se manteña en execución.

O ficheiro .env sería algo así, aínda que este só é un exemplo:

NEXTCLOUD_DATA_PATH=
PIHOLE_PATH=
LOCAL_GID=1000
LOCAL_UID=1000
REPO_1=./data
REPO_1_KEY=repokey

A idea é que esas claves REPO_1 sexan algo máis xenéricas e dinámicas. Pero veremos a que me refiro cando amose a configuración final do contenedor, cun exemplo real.

O docker-compose.yml é o seguinte:

services:
  borg:
    build:
      context: docker
      dockerfile: Dockerfile
      args:
        LOCAL_GID: ${LOCAL_GID}
        LOCAL_UID: ${LOCAL_UID}
        REPO_1_KEY: ${REPO_1_KEY}
    container_name: borgbackup
    init: true
    restart: unless-stopped
    volumes:
      - ${REPO_1}:/repo_1

Esta será a configuración xenérica do servizo, pero a parte referente aos volumes só está como exemplo. Esta será sobre escrita en cada equipo.

O ficheiro docker-compose.override.yml será o que teña a configuración dos volumes en cada despregue:

services:
  borg:
    volumes:
      - /home/user:/home_backup
    environment:
      - BACKUP_CONFIG_PATH=/config/backup_config_laptop.json

Aquí podemos ver como nun despregue indicaríamos que o volume será a home do usuario. Na variable BACKUP_CONFIG_PATH, pode ser indicado o ficheiro de configuración que conterá a información necesaria para facer as copias. Neste momento é algo así:

{
  "backup_directories": [
    "/home/user"
  ],
  "remote_backup_path": "/mnt/backup"
}

Apuntaremos os directorios a salvar e onde salvalos. Aínda que isto é algo temporal e é probable que remate por incluír máis información, como o nome do arquivo de cada copia, para que non se pisen.

Repositorios de Borgbackup

Cando falamos de repositorio en Borgbackup, non só nos estamos a referir a un almacén de datos. Senón que tamén inclúe a información e a estructura para xestionar esas copias de seguridade. Por exemplo, coma dixemos antes para evitar duplicados, xestionar os arquivos, verificar a integridade, etc.

A continuación veremos como crear un destes repositorios.

Iniciar repositorio por SSH

Como Borgbackup vai executar comandos no servidor remoto, tamén o precisaremos instalado nel. Co cal o primeiro será instalalo. No caso de Raspberry Pi OS:

sudo apt install borgbackup

Agora cando executamos Borgbackup en local, este conectará por SSH ao equipo remoto. Xa neste servidor remoto Borgbackup comezará a executar os comandos precisos.

Antes de comezar, quero sinalar que se imos facer probas creando ou borrando arquivos, temos ao noso dispor do parámetro –dry-run que executará de forma simulada á instrucción sen realizar cambios. Así mentres probamos, podemos ver cal sería o resultado sen ternos que lamentar por perder información.

Unha vez teñamos isto, podemos iniciar o repositorio co seguinte comando, dende o cliente:

borg init -e repokey ssh://usuario@SERVER_IP:/ruta/backup

No caso de utilizar un porto diferente ao 22, engadiríamos _:PORTO despois da ip.

Se non quixésemos cifrar o repo, en troques de repokey usaríamos none. Con isto cando fagamos un backup non nos pedirá a clave de cifrado, pero calquera con acceso poderá montar os backups e ver o contido.

borg init -e none ssh://usuario@SERVER_IP:/ruta/backup

Recuperar un backup

Para recuperar un backup, nunha ruta concreta teremos que dirixirnos a esa ruta e executar o comando apuntando ao arquivo que queremos recuperar:

borg extract ssh://usuario@SERVER_IP:/ruta/backup::backup-file

Se queremos ver un listado dos ficheiros que vai extraíndo, podemos engadir o parámetro –list.

Eliminar backups

Cunha tarefa programada ou seguindo estes pasos tal cal están, remataríamos por ter unha morea de copias. Para evitar isto é interesante aprender a eliminar algunhas destas copias.
Para facelo temos dous xeitos, un é utilizar borg delete que permite borrar un arquivo ou un repositorio. Se por exemplo quixésemos borrar o arquivo test1234 do repo remoto executaríamos:

borg delete ssh://usuario@SERVER_IP:/ruta/backup::test1234

Para elminar un repo, pois fríamolo sen a parte que sinala o arquivo.
Pero e se non queremos borrar un ficheiro concreto, se non un rango de copias. Por exemplo aquelas anteriores a unha semana. Para isto usaremos borg prune do seguinte xeito:

borg prune ssh://usuario@SERVER_IP:/ruta/backup --keep-daily 7

Con isto estámoslle a indicar que queremos manter os backups dos últimos sete días. E aínda poderíamos afinar máis indicando tamén backups semanais ou mensuais. Todo-los parámetros están na súa documentación.

NOTA: para estes dous últimos comandos recorda que se poden lanzar con –dry-run para ver o que fará, sen cambios no repositorio.

Como exemplo, no meu caso podería correr a seguinte orde e tería esta saída, hai que ter en conta que non levo demasiado tempo cas copias todavía:

borg prune --dry-run usuario@SERVER_IP:/ruta/backup --keep-daily 7 --keep-weekly 2 --keep-monthly 2 --keep-yearly 2 --list
Keeping archive (rule: daily #1):        self-hosted-2024-09-11               Wed, 2024-09-11 00:00:04 [bdda5b3888a67393f2516550f064c3eac08224ee13f8be1f20888b6907dae2bd]
Keeping archive (rule: daily #2):        self-hosted-2024-09-10               Tue, 2024-09-10 00:00:04 [d8c8d65d86343df53ba2e899819dbf6bafc28a4c2d6c8f1b0635b944f6eac80c]
Keeping archive (rule: daily #3):        self-hosted-2024-09-09               Mon, 2024-09-09 00:00:04 [9c4fceae38a2a5bedef7ac20a893ae26029228debfdf5f9ea333dedfd60370e8]
Keeping archive (rule: daily #4):        self-hosted-2024-09-08               Sun, 2024-09-08 00:00:04 [325fd12fc1f952b0ed88cc1caf7f0b145c4043664f31365b921ffae9639a9547]
Keeping archive (rule: daily #5):        self-hosted-2024-09-07               Sat, 2024-09-07 11:28:51 [18a96f26f1b7d1f81966cefbbb5cf875651673aa9fd64f9cd12be84bc5c5bcb3]
Keeping archive (rule: daily #6):        self-hosted-2024-09-06               Fri, 2024-09-06 06:09:59 [3e4b8081eb5b763293b096f5095c8c83e5d27b23e5513cf606157727cfd15154]
Keeping archive (rule: daily #7):        self-hosted-2024-09-05               Thu, 2024-09-05 06:15:19 [cb4982b6471508f70704f7226b61e9be02088ff03403d5eba0033aa53d6074d2]
Keeping archive (rule: weekly #1):       self-hosted-2024-09-01               Sun, 2024-09-01 11:11:12 [d8a8628c9bd970b6fa0b0e0adc1b02272f0f24e37e7a980ebdd235c9d1204150]
Keeping archive (rule: weekly[oldest] #2): self-hosted-2024-08-31               Sat, 2024-08-31 11:30:35 [a8dfe9cc0a57015bdeee6083d852c432b8800ec9be5aa8230639b8de9e6a9ed7]

Aquí non borraría arquivos, porque mantén o do día 31 como o segundo arquivo semanal por ser o máis antigo. Pero se por exemplo editamos e lle digo que manteña tan só os tres últimos días, veremos isto:

borg prune --dry-run usuario@SERVER_IP:/ruta/backup --keep-daily 3 --list
Keeping archive (rule: daily #1):        self-hosted-2024-09-11               Wed, 2024-09-11 00:00:04 [bdda5b3888a67393f2516550f064c3eac08224ee13f8be1f20888b6907dae2bd]
Keeping archive (rule: daily #2):        self-hosted-2024-09-10               Tue, 2024-09-10 00:00:04 [d8c8d65d86343df53ba2e899819dbf6bafc28a4c2d6c8f1b0635b944f6eac80c]
Keeping archive (rule: daily #3):        self-hosted-2024-09-09               Mon, 2024-09-09 00:00:04 [9c4fceae38a2a5bedef7ac20a893ae26029228debfdf5f9ea333dedfd60370e8]
Would prune:                             self-hosted-2024-09-08               Sun, 2024-09-08 00:00:04 [325fd12fc1f952b0ed88cc1caf7f0b145c4043664f31365b921ffae9639a9547]
Would prune:                             self-hosted-2024-09-07               Sat, 2024-09-07 11:28:51 [18a96f26f1b7d1f81966cefbbb5cf875651673aa9fd64f9cd12be84bc5c5bcb3]
Would prune:                             self-hosted-2024-09-06               Fri, 2024-09-06 06:09:59 [3e4b8081eb5b763293b096f5095c8c83e5d27b23e5513cf606157727cfd15154]
Would prune:                             self-hosted-2024-09-05               Thu, 2024-09-05 06:15:19 [cb4982b6471508f70704f7226b61e9be02088ff03403d5eba0033aa53d6074d2]
Would prune:                             self-hosted-2024-09-01               Sun, 2024-09-01 11:11:12 [d8a8628c9bd970b6fa0b0e0adc1b02272f0f24e37e7a980ebdd235c9d1204150]
Would prune:                             self-hosted-2024-08-31               Sat, 2024-08-31 11:30:35 [a8dfe9cc0a57015bdeee6083d852c432b8800ec9be5aa8230639b8de9e6a9ed7]

NOTA: No meu caso non me fixei cando fixen as probas xa con outro repo. No que tiña distintos ficheiros de backup, con distintos quero dicir de diferentes orixes. Por exemplo tiña ficheiros co ssh, proxectos, etc. Neste caso ao facer prune con esas regras, toma os ficheiros coma un todo. Polo que o resultado foi que quedou cun ficheiro de ssh e sete de configuracións, pero borrou tódolos demais. Para repositorios deste tipo, o que temos que facer é executar o comando prune por cada tipo de ficheiro, indicando un patrón polo que filtar. Para isto usaremos o argumento –glob-archives. Así pois teríamos un comando similar ao anterior, pero co filtro:

borg prune --dry-run usuario@SERVER_IP:/ruta/backup --keep-daily 3 --list --glob-archives 'ssh*'

Neste exemplo tan só aplicaría a operación aos arquivos que comecen por ssh. Podemos ver máis patróns na axuda do proxecto.

Montar un repositorio

Ben, agora que xa sabemos recuperar un backup, eliminar un, ou varios en base a regras. Compre saber cómo podemos recuperar un só ficheiro. Que ocorre se simplemente borrei unha foto, un ficheiro de configuración, etc. Ter que recuperar un backup enteiro para só coller o ficheiro que preciso non parece o máis óptimo.
Para estas situacións, Borgbackup permite montar un backup como se fose unha unidade do noso equipo e navegar polos seus ficheiros. Deste xeito poderemos coller tan só o que nos interesa e pegalo onde queiramos. Para estas operacións temos os comandos borg mount e borg umount, que xa vemos que pegan moito co que estamos acostumados en GNU/Linux.

Supoñamos para o seguinte exemplo que quero recupear unha clave id_rsa do backup. Teño no repositorio un ficheiro ca última data ssh-2024-09-15.

borg mount ssh://usuario@SERVER_IP:/ruta/backup::ssh-2024-09-15 /punto/montaxe

E para desmontalo:

borg umount /punto/montaxe

Conclusión

Ao final non puiden crear o repositorio para traballar con SFTP como quería en artigos anteriores. Parece que o equipo de Borgbackup desbotou a idea xa que requería engadir moitas dependenzas. Pero podemos facelo por SSH, co único requisito de ter que instalar Borgbackup en ambos equipos. Por suposto, aínda que agora o instalei directamente, tamén se podería facer cun contenedor ao cal lle daríamos acceso só a un volume. Seguramente remate por facelo así, para illar aínda máis posibles problemas. Xa que se alguén accedese só tería permiso para o contenedor e o volume.

A partir de agora traballarei con esta ferramenta, o que me permitirá máis seguridade á hora de facer cambios ou probas. Tamén que en caso de desastre, por avaría ou o que sexa, poida recuperar unha copia e continuar co traballo.

Todo o mundo debe ter copias das cousas que son importantes, non fai falla que sexa con esta ferramenta. Pero si que compre ter as nosas cousas duplicadas nalgún sitio. Sería unha mágoa que esas fotos ou vídeos de familia se perdan porque un disco duro deixe de funcionar. Ou que un traballo importante non poida ser entregado, porque caímos nun ransomware.

Fontes

A web do proxecto: BorgBackup
Init: borg init
Create: borg create
Delete: borg delete
Prune: borg prune
Help: borg help patterns