# Installation et configuration de autorestic On a déjà des backups des images de machines virtuelles, qui sont [[technique:infrastructure:backup|faits par les hyperviseurs]] Pour faire des backups logiques de nos volumes Docker, on commence à utiliser autorestic. {{ :technique:adminsys:backup:restic.drawio.svg |}} Voilà comment installer et configurer autorestic sur une nouvelle machine : ## Installation des programmes 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](https://github.com/cupcakearmy/autorestic/releases/) et [là](https://github.com/restic/restic/releases/). Télécharge-les depuis votre navigateur, puis copie-les sur la MACHINE picasoft : ```bash rsync restic.bz2 autorestic.bz2 ppom@MACHINE.picasoft.net: ``` sur la MACHINE, décompresse les fichers et installe-les dans `/usr/local/bin` : ```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 ``` ## Installation de la configuration SSH du client 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 [[asso:tuto:vaultwarden|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 ``` ## Installation de la conf autorestic On clone le [repo git](https://gitlab.utc.fr/picasoft/projets/backups) 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](https://autorestic.vercel.app/backend/env)), 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 ```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 ``` ## Installation du service / timer systemd ```bash sudo cp -f /DATA/docker/backups/autorestic.service /etc/systemd/system/autorestic.service sudo cp -f /DATA/docker/backups/autorestic.timer /etc/systemd/system/autorestic.timer sudo systemctl daemon-reload sudo systemctl enable autorestic.timer sudo systemctl start autorestic.timer ``` ## Configuration de restic-server Auparavant, nous avions un user `backup` sur le serveur distant, dédié au stockage des backups. Cependant nous avions des problèmes d'efficacité et de robustesse avec le backend SSH de `restic`. Nous utilisons maintenant [`restic-server`](https://gitlab.utc.fr/picasoft/projets/services/restic-server), un petit serveur HTTP qui remplit ce même rôle. **TODO finir cette partie** - Authentification double HTTPS : certificats client & serveur générés côté traefik [ici](https://gitlab.utc.fr/picasoft/projets/services/traefik/#authentification-client). Certificat client à copier dans le dossier `certs/` du repo concerné - Authentification supplémentaire via le user restic-server 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`. ## Installation de fusermount Pour pouvoir monter les backups distants en local, pour les inspecter et tout il nous faut la commande `fusermount`: ```bash sudo apt install fuse ``` ## Alerte quand un backup se passe mal Dans l'esprit de [cet exemple](https://autorestic.vercel.app/examples#use-hooks-to-integrate-with-healthchecks), 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/ ``` Plus d'informations sur les hooks Mattermost sur [[technique:adminserv:mattermost:hooks_commands|la page dédiée]]. Un hook est déclenché par `autorestic` en cas d'erreur : ```yaml # Within a location hooks: failure: - /DATA/docker/backups/failed_backup.sh ${AUTORESTIC_LOCATION} ``` La variable d'environnement `AUTORESTIC_LOCATION` est fournie par `autorestic` pour tous les hooks : voir la [documentation](https://autorestic.vercel.app/location/hooks). Le script d'envoi de hook est très simple et peut ressembler à : `failed_backup.sh` ```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} ``` ## Utiliser autorestic Par convention, le dépôt de configuration des backups est commun à toutes les machines et est cloné dans le chemin `/DATA/BACKUP/backup` sur toutes les machines à sauvegarder. Le dépôt se trouve ici : https://gitlab.utc.fr/picasoft/projets/backups/ Lors d'un nouveau clone, suivre la procédure [[technique:docker:picasoft:dockerfiles#utiliser_les_depots_sur_les_machines|sur cette page]] 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 documentation complète est ici : https://autorestic.vercel.app/cli/general La base sera toujours la même, par exemple : ```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 ``` `pica03` étant à remplacer par le backup distant. Deux instances d'`autorestic` ne peuvent pas tourner simultanément. Or `autorestic` est souvent lancé par `cron`, donc attention.