diff --git a/outils/logiciels/backups/README.md b/outils/logiciels/backups/README.md new file mode 100644 index 0000000..2b5f9b7 --- /dev/null +++ b/outils/logiciels/backups/README.md @@ -0,0 +1,92 @@ +# Outils de backups + +## Présentation + +Ce dossier contient une présentation des logiciels utilisés par le Crans pour +faire ses sauvegardes, ou backups en anglais. On entend ici par backup une +opération qui consiste à dupliquer de manière sécurisée (chiffrée en +l'occurrence) sur d'autres serveurs les données des utilisateurices et des +machines du Crans. + +Comme dans tout le dossier [logiciels](../../../), le but n'est pas de +réexpliquer l'entièreté des fonctionnalités mais simplement d'a voir les bases +de compréhension. + +## Organisation + +Vous trouverez ici deux fichiers correspondant aux deux logiciels utilisés pour +les backups au Crans : + +- [borg](./borg.md) pour les logiciels borg et borgmatic ; +- [restic](./restic.md) pour le logiciel du même nom. + +Il est cependant fortement conseillé de lire la fin de ce fichier présentant +certaines informations concernant les backups qu'il est important de connaître +avant de lire plus en détails les autres fichiers détaillant plus +spécifiquement les logiciels. + +## Contexte + +### Historique + +Pour prevenir certains incidents dus à des erreurs de manipulation, le collège +technique a mis en place en système de backups. Le but de celui-ci est de +pouvoir, si le besoin s'en fait ressentir, aller rechercher un fichier supprimé +ou écrasé. Bien qu'il serait possible de simplement faire une copie périodique +des données sur un serveur distant, on lui préfère des solutions un peu plus +développées qui permettent de faire des sauvegardes incrémentales. Fut un temps, +la solution technique en place était le logiciel +[BackupPC](https://backuppc.github.io/backuppc/), cependant celui-ci commençant +à dater et ayant une faible ergonomie, nous utilisons aujourd'hui le logiciel +[borg](https://borgbackup.readthedocs.io/) et son frontend +[borgmatic](https://torsion.org/borgmatic/). De plus, le logiciel +[restic](https://restic.readthedocs.io/) a été installé en parallèle pour sa +simplicité d'utilisation : borg/borgmatic et restic cohabitent donc pour le +moment pour que les jeunes membres actif⋅ves puissent comparer afin de faire un +choix à long terme. + +### Backups incrémentales + +Avant de présenter ces logiciels, attardons nous un peu sur ce qu'on entend par +faire des backups incrémentales. Pour cela revenons à notre piètre solution +initiale qui consiste à copier (à grands coups de rsync, unison, scp...) toutes +les données que l'on souhaiterait sauvegarder. Pour que ces sauvegardes soient +utiles, il faut les réaliser assez fréquemment (quelque part entre un jour et +une semaine disons). Cependant, à chaque nouvelle backup réalisée, celle-ci va +venir écraser le contenu de la précédente et ainsi, on ne dispose jamais plus +que d'une copie des données de la veille. Ainsi, des dysfonctionnements +automatiques ou simplement de la négligence peuvent faire que l'on ne se rendra +compte que l'on avait besoin de récupérer notre fichier il y a déjà quelques +jours et qu'il a maintenant déjà été supprimé de la copie de sauvegarde. + +On préfererait donc pouvoir disposer d'une collection de sauvegardes qui +remonte sur quelques jours voir moi en fonction de la politique de rétention de +sauvegarde qu'on mettrait en place. Par exemple, une sauvegarde pour chacun des +septs derniers jours puis quelques unes espacée d'une semaine. Si l'on reprend +notre solution naïve, on peut facilement en étendre l'usage pour ce nouvel +office : on réalise une copie complète des données par jour que l'on souhaite +sauvegarder. Suivant la politique de rétention que l'on a donné plus tôt cela +consisterais en une quinzaine de copies distinctes des données à sauvegarder et +donc une multiplication par quinze de la taille de celle-ci. + +Si je jette un œil rapide à la taille que prends aujourd'hui les données +utilisateurices, je vois qu'on utilise un peu plus de 2.5T de stockage, donc si +l'on suit la logique, on devrait disposer d'une ou plusieurs machines +totalisant un stockage d'environ 40T. Inutile de le dire je pense, mais cela +fait (beaucoup) trop. Heureusement pour nous, d'un jour sur l'autre +l'intégralité de nos données stockées ne varie pas et seule une petite partie +change sur le cours d'une journée. Ainsi, si l'on ne stocke que les différences +accumulé sur une journée par rapport à la veille, on se retrouvera avec une +taille beaucoup plus raisonnable de sauvegarde. C'est ~la déduplication. + +### Qu'est-ce que l'on sauvegarde ? + +Au Crans, on sauvegarde deux types de données : + +- D'un côté, on a les données d'administration, c'est une partie des disques + de tous les serveurs (généralement le /etc et le /var sauf cas particulier), + le home des nounous, les bases de données... + +- De l'autre côté; on a les données des adhérents, c'est à dire : le contenu + de leur répertoire personnel et de leur dossier mail qui au jour où j'écris + ses lignes peut contenir au maximum 30G et 10G de données respectivement. diff --git a/outils/logiciels/backups/borg.md b/outils/logiciels/backups/borg.md new file mode 100644 index 0000000..36d345f --- /dev/null +++ b/outils/logiciels/backups/borg.md @@ -0,0 +1,110 @@ +# Borg + +Page officiel de borg : . + +Documentation de borg : . + +Page officielle de borgmatic : (contient la +documentation). + +## Borg et borgmatic + +Borg est un logiciel client/serveur permettant d'effectuer des sauvegardes +incrémentales, dédupliquées et chiffrées par le client. Le serveur est simple à +installer et utilise ssh comme protocole de transport entre lui et le client. +Ainsi, il suffit de donner un accès ssh au client via une paire de clés pour lui +autoriser à discuter avec le serveur. Quelque chose ressemblant à ça dans le +`.ssh/authorized_keys` de l'utilisateur sur le serveur qui fera les backups : + +```txt +command="borg serve --restrict-to-path {{ chemin vers les sauvegardes }}",restrict {{ clé publique ssh }} +``` + +Avec l'installation du paquet `borg` c'est la seule chose à faire sur le serveur +et le reste du travail sera réalisé par le client. Après avoir aussi installé +`borg` sur le client, on peut déjà commencer à faire quelques sauvegardes. +Cependant, si l'on utilise que borg pour les faire (ce qui est possible), on se +retrouvera avec des commandes bien trop longues dans lesquels on passe notre +temps à spécifier des arguments plusieurs fois : comment contacter le serveur ? +où stocker les sauvegardes ? quel politique de rétentions garder ? que faut-il +sauvegarder ? Borgmatic est un frontend de borg qui définir une bonne fois pour +toutes ses options dans un fichier de configuration pour ensuite n'avoir plus +qu'à faire des appels simples à borgmatic qui pasera à borg tous les paramètres +dont il a besoin. Le but n'est pas ici d'être exhaustif sur ce que peut/doit +contenir ce fichier de configuration. Je vous redirige pour ça vers la +[documentation +officielle](https://torsion.org/borgmatic/docs/reference/configuration/). Ici, +je vais plus chercher à vous donner quelques options minimales et des exemples +d'utilisations de borgmatic. Commençons par donner le contenu d'un fichier de +configuration partiel : + +```txt +location: + source_directories: + - /etc + - /var + repositories: + - borg@backup-server:/folder/to/bacup/to + +storage: + encryption_passphrase: PASSPHRASE + ssh_command: ssh -i /etc/borgmatic/id_ed25519_borg + +retention: + keep_daily: 4 + keep_monthly: 6 +``` + +Dans la section `location`, on définit deux choses : ce que l'on souhaite +sauvegarder et où on souhaite le sauvegarder. Ici on va backupé le `/etc` et +`/var` de notre client sur un serveur distant qu'on contactera via ssh. Dans la +section suivante, `storage`, on définit quelques options relatives au stockage +et à comment y accéder. Premièrement, on donne la passphrase de chiffrement des +sauvegardes (attention, si elle est perdue, les sauvegardes ne seront plus +accessibles). Ensuite, on précise comment accéder au serveur (ici, l'information +importante est où se trouve la clé privée pour pouvoir se connecter). Enfin, +dans la section retention, on définit notre politique de retention : le serveur +ne doit stocker qu'une backup quotidienne sur les 4 derniers jours, et une +backup mensuelle sur les 6 derniers mois. + +En supposant les autres options de fonctionnement renseignées dans le fichier, +que je ne détaillerais pas ici, il est maintenant possible de commencer à +utiliser le logiciel et faire nos premières sauvegardes. + +## Créer l'archive de stockage + +La commande suivante permet de créer l'archive où seront stockées les +sauvegardes sur le serveur. + +```bash +borgmatic init -e repokey +``` + +## Faire une première sauvegarde + +Pour faire une sauvegarde, rien de plus simple, on appelle simplement le +programme borgmatic sans option. Il est néanmoins possible de demander un +affichage plus verbeux pour le débogage. + +```bash +borgmatic +borgmatic -v 2 +``` + +## Lister les différentes sauvegardes dans l'archive + +```bash +borgmatic list +``` + +## Monter une sauvegarde précise sur un point de montage + +```bash +borgmatic mount --archive {{ nom de l'archive ou latest pour la dernière }} --mount-point /mnt --path {{ chemin à monter de l'archive }} +borgmatic mount --archive latest --mount-point /mnt --path etc/nginx/nginx.conf +``` + +## Automatiser les backups + +Pour réaliser des backups périodique, on peut en laisser la charge à un cron ou +à systemd à l'aide d'un timer. diff --git a/outils/logiciels/backups/restic.md b/outils/logiciels/backups/restic.md new file mode 100644 index 0000000..9c6207e --- /dev/null +++ b/outils/logiciels/backups/restic.md @@ -0,0 +1,138 @@ +# Restic + +Page officielle de restic : . + +Documentation de restic : . + +Dépôt officiel de restic rest-server : . + +## Présentation + +Restic est un logiciel client/serveur permettant d'effectuer des sauvegardes +incrémentales, dédupliquées et chiffrées par le client. Différents serveurs +sont utilisables par le client, nous présenterons ici le serveur REST de restic +utilisant le protocole HTTP, qui est installé actuellement au Crans sur +[thot](../../../infrastructure/machines/physiques/thot.md). + +Pour la configuration d'un client, vous aurez besoin d'installer le paquet +`restic` sur les machines sous debian, restic étant déjà packagé dans nixpkgs +pour les machines sous NixOS. + +## Configuration du serveur + +Le choix le plus simple à mettre en place pour la partie serveur de restic est +restic rest-server, très simple à mettre en place. Vous pouvez trouver la +configuration actuelle dans le module restic du +[dépôt NixOS](https://gitlab.crans.org/nounous/nixos). + +Le fonctionnement de ce serveur REST est le suivant : le client compresse et +chiffre ses données avec un mot de passe, vient s'authentifier en +[basic auth](https://en.wikipedia.org/wiki/Basic_access_authentication) auprès +du serveur, puis dépose la backup au fur et à mesure de son avancée sur le +serveur. Chaque client dispose donc de deux mots de passe : une clef de +chiffrement pour les données, ainsi qu'un mot de passe pour s'authentifier +auprès du serveur REST. + +Deux notions sont importantes à comprendre ici dans la configuration du serveur +REST. + +- L'option `privateRepos`/`--private-repos` : permet de faire en sorte qu'un⋅e + utilisateurice (dans notre cas une machine) ne puisse accéder qu'à ses + propres backups et puisse créer tous les dépôts souhaités dans un sous + dossier à son nom. Ainsi, une fois authentifiée, la VM flirt aura accès à + tous dépôt de la forme `restic:http://thot.adm.crans.org/flirt/`, ce + qui est particulièrement pratique pour ne pas avoir à gérer les accès à la + main pour chaque machine. +- Les clients sont authentifiées par le serveur grâce à un fichier `.htpasswd` + situé à la racine du dossier de données. Ainsi, si le dossier de données est + `/backups`, le fichier d'authentification sera `/backups/.htpasswd`. Ce + fichier est un fichier d'authentification standard : vous pouvez consulter la + [page Wikipédia](https://en.wikipedia.org/wiki/.htpasswd) dédiée pour plus + d'informations. Vous pouvez alors ajouter une machine à ce fichier avec la + commande : + + ```bash + sudo htpasswd -B /backups/.htpasswd [] + ``` + + Si le mot de passe n'est pas spécifié, il sera alors demandé sur l'entrée + standard. + +## Configuration du client + +Théoriquement, restic est uniquement un logiciel qui s'utilise directement. +Cependant, nous souhaitons faire des sauvegardes automatiquement en utilisant +des systemd timer, on va donc créer plusieurs fichiers pour ne pas à avoir tout +à spécifier directement dans les lignes de commande. + +Actuellement, la configuration des clients restic se situe dans le dossier +`/etc/restic` sous debian, et dans le +[dépôt NixOS](https://gitlab.crans.org/nounous/nixos) pour les machines sous +NixOS. Dans les deux cas, on retrouve les mêmes éléments (on donne les noms +pour la configuration par défault des machines sous debian) : + +- un fichier d'environnement `base.env`, contenant plusieurs variables d'environnement + dont l'utilité précise peut être trouvée dans + [la documentation de restic](https://restic.readthedocs.io/en/stable/040_backup.html#environment-variables). +- un fichier `base-repo` contenant la position du dépôt (serveur REST), avec + les identifiants de connexion, qui se présente sous la forme + `restic:http://:@thot.adm.crans.org//base`. +- un fichier `base-password` contenant le mot de passe de chiffrement des + sauvegardes. +- deux fichiers `base-includes` et `base-excludes` indiquant respectivement les + dossiers inclus et exclus pour les sauvegardes. + +En plus de cela, on trouve un service systemd `restic-base` ainsi qu'un timer +associé dans le dossier `/etc/systemd/system/`. Ce service lancera deux +commandes : une commande pour lancer une sauvegarde, et une commande pour +supprimer les anciennes sauvegardes qui ne seront pas gardées en tant que +sauvegarde journalière/hebdomadaire/mensuelle/annuelle (définies par la +configuration). + +## Initialiser un dépôt + +En supposant que vous avez la configuration décrite ci-dessus, vous pouvez +initialiser un dépôt grâce à la commande suivante : + +```bash +restic init --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password +``` + +## Faire une sauvegarde à la main + +Pour faire une sauvegarde à la main, rien de compliqué, il suffit de lancer le +service systemd normalement de la manière suivante : + +```bash +sudo systemctl start restic-base.service +``` + +(Même si c'est surprenant, vous pouvez faire CTRL+C à ce moment dans votre +terminal, la tâche continuera en fond.) + +De plus, si la variable `RESTIC_PROGRESS_FPS` a été affectée à une valeur +strictement positive, vous pourrez voir la progression de la sauvegarde dans +le journal. Vous pouvez donc y accéder par la commande : + +```bash +sudo journalctl -xefu restic-base +``` + +## Consulter l'état des sauvegardes + +Pour consulter la liste actuelle des sauvegardes, vous pouvez simplement +utiliser la commande : + +```bash +restic snapshots --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password +``` + +De plus, vous pouvez facilement monter une sauvegarde sur un point de montage +avec la commande suivante : + +```bash +restic mount /mnt --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password +``` + +Cela bloquera alors votre terminal, et la sauvegarde sera démontée dès que vous +quitterez votre terminal, évitant d'avoir une sauvegarde montée et oubliée. diff --git a/services/borg.md b/services/borg.md deleted file mode 100644 index 6b0c7b1..0000000 --- a/services/borg.md +++ /dev/null @@ -1,164 +0,0 @@ -# Borg - -Pour prevenir certains incidents dus à des erreurs de manipulation, le collège -technique a mis en place en système de backups. Le but de celui-ci est de -pouvoir, si le besoin s'en fait ressentir, aller rechercher un fichier supprimé -ou écrasé. Bien qu'il serait possible de simplement faire une copie périodique -des données sur un serveur distant, on lui préfère des solutions un peu plus -développées qui permettent de faire des sauvegardes incrémentales. Fut un temps, -la solution technique en place était le logiciel -[BackupPC](https://backuppc.github.io/backuppc/), cependant celui-ci commençant -à dater et ayant une faible ergonomie, nous utilisons aujourd'hui le logiciel -[borg](https://borgbackup.readthedocs.io/en/stable/) et son frontend -[borgmatic](https://torsion.org/borgmatic/). - -Avant de présenter ce logiciel, attardons nous un peu sur ce qu'on entend par -faire des backups incrémentales. Pour cela revenons à notre piètre solution -initiale qui consiste à copier (à grands coups de rsync, unison, scp…) toutes -les données que l'on souhaiterait sauvegarder. Pour que ces sauvegardes soient -utiles, il faut les réaliser assez fréquemment (quelque part entre un jour et -une semaine disons). Cependant, à chaque nouvelle backup réalisée, celle-ci va -venir écraser le contenu de la précédente et ainsi, on ne dispose jamais plus -que d'une copie des données de la veille. Ainsi, des dysfonctionnements -automatiques ou simplement de la négligence peuvent faire que l'on ne se rendra -compte que l'on avait besoin de récupérer notre fichier il y a déjà quelques -jours et qu'il a maintenant déjà été supprimé de la copie de sauvegarde. On -préfererait donc pouvoir disposer d'une collection de sauvegardes qui remonte -sur quelques jours voir moi en fonction de la politique de rétention de -sauvegarde qu'on mettrait en place. Par exemple, une sauvegarde pour chacun des -septs derniers jours puis quelques unes espacée d'une semaine. Si l'on reprend -notre solution naïve, on peut facilement en étendre l'usage pour ce nouvel -office : on réalise une copie complète des données par jour que l'on souhaite -sauvegarder. Suivant la politique de rétention que l'on a donné plus tôt cela -consisterais en une quinzaine de copies distinctes des données à sauvegarder et -donc une multiplication par quinze de la taille de celle-ci. Si je jette un œil -rapide à la taille que prends aujourd'hui les données utilisateur⋅ices, je vois -qu'on utilise un peu plus de 2.5T de stockage, donc si l'on suit la logique, on -devrait disposer d'une ou plusieurs machines totalisant un stockage d'environ -40T. Inutile de le dire je pense, mais cela fait (beaucoup) trop. Heureusement -pour nous, d'un jour sur l'autre l'intégralité de nos données stockées ne varie -pas et seule une petite partie change sur le cours d'une journée. Ainsi, si l'on -ne stocke que les différences accumulé sur une journée par rapport à la veille, -on se retrouvera avec une taille beaucoup plus raisonnable de sauvegarde. C'est -~la déduplication. - -## Qu'est ce que l'on sauvegarde ? - -Au crans, on sauvegarde deux types de données : - -* D'un côté, on a les données d'administration, c'est une partie des disques - de tous les serveurs (généralement le /etc et le /var sauf cas particulier), - le home des nounous, les bases de données… - -* De l'autre côté; on a les données des adhérents, c'est à dire : le contenu - de leur répertoire personnel et de leur dossier mail qui au jour où j'écris - ses lignes peut contenir au maximum 30G et 10G de données respectivement. - -Même si les deux types de sauvegardes sont fait avec borg/borgmatic, la manière -dont les sauvegardes sont effectivement lancé varie entre les deux. Je -m'attarderais ici plus sur le fonctionnement générale de borg/borgmatic et donc -je présenterais le cas de la sauvegarde de données administratives qui est une -utilisation assez normale du logiciel. L'explication de comment se passe les -sauvegardes pour les données adhérents est disponible [ici](services/borg.md). - -## Borg et borgmatic - -Borg est un logiciel client/serveur permettant d'effectuer des sauvegardes -incrémentales, dédupliquées et chiffrées par le client. Le serveur est simple à -installer et utilise ssh comme protocole de transport entre lui et le client. -Ainsi, il suffit de donner un accès ssh au client via une paire de clés pour lui -autoriser à discuter avec le serveur. Quelque chose ressemblant à ça dans le -`.ssh/authorized_keys` de l'utilisateur sur le serveur qui fera les backups : - -```txt -command="borg serve --restrict-to-path {{ chemin vers les sauvegardes }}",restrict {{ clé publique ssh }} -``` - -Avec l'installation du paquet `borg` c'est la seule chose à faire sur le serveur -et le reste du travail sera réalisé par le client. Après avoir aussi installé -`borg` sur le client, on peut déjà commencer à faire quelques sauvegardes. -Cependant, si l'on utilise que borg pour les faire (ce qui est possible), on se -retrouvera avec des commandes bien trop longues dans lesquels on passe notre -temps à spécifier des arguments plusieurs fois : comment contacter le serveur ? -où stocker les sauvegardes ? quel politique de rétentions garder ? que faut-il -sauvegarder ? Borgmatic est un frontend de borg qui définir une bonne fois pour -toutes ses options dans un fichier de configuration pour ensuite n'avoir plus -qu'à faire des appels simples à borgmatic qui pasera à borg tous les paramètres -dont il a besoin. Le but n'est pas ici d'être exhaustif sur ce que peut/doit -contenir ce fichier de configuration. Je vous redirige pour ça vers la -[documentation -officielle](https://torsion.org/borgmatic/docs/reference/configuration/). Ici, -je vais plus chercher à vous donner quelques options minimales et des exemples -d'utilisations de borgmatic. Commençons par donner le contenu d'un fichier de -configuration partiel : - -```txt -location: - source_directories: - - /etc - - /var - repositories: - - borg@backup-server:/folder/to/bacup/to - -storage: - encryption_passphrase: PASSPHRASE - ssh_command: ssh -i /etc/borgmatic/id_ed25519_borg - -retention: - keep_daily: 4 - keep_monthly: 6 -``` - -Dans la section `location`, on définit deux choses : ce que l'on souhaite -sauvegarder et où on souhaite le sauvegarder. Ici on va backupé le `/etc` et -`/var` de notre client sur un serveur distant qu'on contactera via ssh. Dans la -section suivante, `storage`, on définit quelques options relatives au stockage -et à comment y accéder. Premièrement, on donne la passphrase de chiffrement des -sauvegardes (attention, si elle est perdue, les sauvegardes ne seront plus -accessibles). Ensuite, on précise comment accéder au serveur (ici, l'information -importante est où se trouve la clé privée pour pouvoir se connecter). Enfin, -dans la section retention, on définit notre politique de retention : le serveur -ne doit stocker qu'une backup quotidienne sur les 4 derniers jours, et une -backup mensuelle sur les 6 derniers mois. - -En supposant les autres options de fonctionnement renseignées dans le fichier, -que je ne détaillerais pas ici, il est maintenant possible de commencer à -utiliser le logiciel et faire nos premières sauvegardes. - -### Créer l'archive de stockage - -La commande suivante permet de créer l'archive où seront stockées les -sauvegardes sur le serveur. - -```bash -borgmatic init -e repokey -``` - -### Faire une première sauvegarde - -Pour faire une sauvegarde, rien de plus simple, on appelle simplement le -programme borgmatic sans option. Il est néanmoins possible de demander un -affichage plus verbeux pour le débogage. - -```bash -borgmatic -borgmatic -v 2 -``` - -### Lister les différentes sauvegardes dans l'archive - -```bash -borgmatic list -``` - -### Monter une sauvegarde précise sur un point de montage - -```bash -borgmatic mount --archive {{ nom de l'archive ou latest pour la dernière }} --mount-point /mnt --path {{ chemin à monter de l'archive }} -borgmatic mount --archive latest --mount-point /mnt --path etc/nginx/nginx.conf -``` - -### Automatiser les backups - -Pour réaliser des backups périodique, on peut en laisser la charge à un cron ou -à systemd à l'aide d'un timer.