Installation et configuration de autorestic

On a déjà des backups des images de machines virtuelles, qui sont faits par les hyperviseurs Pour faire des backups logiques de nos volumes Docker, on commence à utiliser autorestic.

Voilà comment installer et configurer autorestic sur une nouvelle machine :

La version de restic sur Debian est assez vieille et autorestic n’est simplement pas présent. On a décidé d’installer les binaires depuis leur repositories github ici et là.

Télécharge-les depuis votre navigateur, puis copie-les sur la MACHINE picasoft :

snippet.bash

rsync restic.bz2 autorestic.bz2 ppom@MACHINE.picasoft.net:

sur la MACHINE, décompresse les fichers et installe-les dans /usr/local/bin :

snippet.bash

bunzip2 restic.bz2
bunzip2 autorestic.bz2 
sudo install -m 0755 -o root restic     /usr/local/bin/restic
sudo install -m 0755 -o root autorestic /usr/local/bin/autorestic

Restic effectue les backup par SFTP, il faut donc configurer le client pour se connecter au store via SSH. Pour cela on utilise le compte backup dont la clé SSH se trouve dans le vaultwarden.

Les backups se font par l’utilisateur root, il faut donc placer la clé dans /root/.ssh/id_ed25519_backup (elle ne soit ni être lisible ni être modifiable par les autres utilisateurs), nous pouvons ensuite modifier sa configuration du client SSH en ajoutant dans /root/.ssh/config (remplacer pica03 par la machine où se trouve le store) :

Host pica03-backup
  HostName pica03.picasoft.net
  Port 22
  User backup
  IdentityFile ~/.ssh/id_ed25519_backup

On clone le repo git ici : /DATA/docker/backups/ Chaque machine a son propre dossier, qui contient le fichier de configuration, versionné avec git. Par défaut, le secret est ajouté par restic dans le YAML. On l’exporte dans un .autorestic.env (doc ici), ignoré par git, pour ne pas versionner ce secret qui permet de chiffrer et déchiffrer les backups. Il faut ajouter ce secret dans le pass (par exemple Tech/Backup/pica03-store/pica02 pour les backups stockés sur pica03 par pica02). Car si on perd la machine, on a intérêt à avoir la clé de déchiffrement des backups quelque part !

/!\TODO expliquer les hooks des BDD et préciser qu’il faut créer les dossiers

snippet.bash

#on commence par initialiser le dépôt restic de la machine
sudo autorestic check
#on lance un backup pour vérifier que tout va bien
sudo autorestic backup -a

/etc/systemd/system/autorestic.service

snippet.systemd

[Unit]
Description=Backups yay
 
[Service]
Type=oneshot
ExecStart=/usr/local/bin/autorestic -vvv -c /DATA/docker/backups/MACHINE/.autorestic.yaml --ci cron

/etc/systemd/system/autorestic.timer

snippet.systemd

[Unit]
Description=Backups yay
 
[Timer]
# Trigger every 10 minutes
OnCalendar=*:0/10:0
 
[Install]
WantedBy=timers.target

snippet.bash

sudo systemctl daemon-reload
sudo systemctl enable autorestic.timer
sudo systemctl start autorestic.timer

Nous décidons de créer un utilisateur dédié afin d’effectuer les backups. Cet utilisateur permet de s’authentifier sur la machine distante mais nous ne lui permettrons pas d’ouvrir un shell distant.

Pour créer cet utilisateur nous utilisons le LDAP et créons un utilisateur de le dossier Services, ce compte doit être autorisés uniquement sur les machines sur lesquelles seront stockés les backups (pas les hyperviseurs).

Nous créons une paire de clés SSH pour cet utilisateur dont nous plaçons la clé privée sur le pass et dans le dossier /root/.ssh afin qu’elle soit accessible sur la machine que nous souhaitons backuper. Il faut ensuite placer la clé publique dans le LDAP.

Il faut ensuite configurer le serveur ssh de la machine de stockage pour chrooter l’utilisateur et ne lui autoriser que le sftp. On ajoute dans /etc/ssh/sshd_config :

Match User backup
	ChrootDirectory /DATA/BACKUP
	ForceCommand internal-sftp
	AllowTCPForwarding no
	X11Forwarding no

On redémarre le serveur SSH pour que la nouvelle configuration prenne effet sudo systemctl restart sshd.

Enfin nous définissons root et son groupe comme propriétaire de /DATA/BACKUP avec chown root:root /DATA/BACKUP. Il faudra aussi donner les droits à l’utilisateur backup sur son dossier chown -R backup:backup /DATA/BACKUP/backup.

Pour pouvoir monter les backups distants en local, pour les inspecter et tout il nous faut la commande fusermount:

snippet.bash

sudo apt install fuse

Dans l’esprit de cet exemple, il serait sympa d’avoir un message d’alerte quand un backup ne réussit pas.

On peut le faire simplement via un hook sur le canal Alertes Techniques. L’URL ne doit pas être versionnée; on la met dans un .env à la racine du dossier. Exemple :

.env

HOOK_URL=https://team.picasoft.net/hooks/<secret_token>

Un hook est déclenché par autorestic en cas d’erreur :

snippet.yaml

# Within a location
hooks:
  failure:
    - /DATA/docker/backups/failed_backup.sh ${AUTORESTIC_LOCATION}

Le script d’envoi de hook est très simple et peut ressembler à :

failed_backup.sh

snippet.bash

#!/bin/sh
 
# Get webhook URL
source .env
 
# Send a message to the alert channel of Picasoft's Mattermost team
curl -i -X POST -H "Content-Type: application/json" -d "{\"text\": \"${hostname}: backup failed for location ${1}\"}" ${HOOK_URL}

Chaque sous-dossier correspond à une machine et contient un fichier autorestic.yml. Ce fichier explicite les dossiers à sauvegarder, leur fréquence et le dépôt distant. Si autorestic est déclenché par un cron, il est parfois nécessaire de lancer des commandes manuelles.

La base sera toujours la même, par exemple :

snippet.bash

# On est sur pica02
$ cd /DATA/BACKUP/backup/pica02
$ head ./autorestic.yml
[...]
backends:
  pica03:
    type: sftp
    path: pica03-backup:/backup/pica02/
[...]
$ sudo autorestic -b pica03 <command>

pica03 étant à remplacer par le backup distant.