Ajout restic + déplacement borg
RatCornu
parent
7381166084
commit
84f5d6dd64
|
|
@ -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.
|
||||||
|
|
@ -0,0 +1,110 @@
|
||||||
|
# Borg
|
||||||
|
|
||||||
|
Page officiel de borg : <https://www.borgbackup.org/>.
|
||||||
|
|
||||||
|
Documentation de borg : <https://borgbackup.readthedocs.io/>.
|
||||||
|
|
||||||
|
Page officielle de borgmatic : <https://torsion.org/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.
|
||||||
|
|
@ -0,0 +1,138 @@
|
||||||
|
# Restic
|
||||||
|
|
||||||
|
Page officielle de restic : <https://restic.net/>.
|
||||||
|
|
||||||
|
Documentation de restic : <https://restic.readthedocs.io/>.
|
||||||
|
|
||||||
|
Dépôt officiel de restic rest-server : <https://github.com/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/<dépôt>`, 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 <username> [<password>]
|
||||||
|
```
|
||||||
|
|
||||||
|
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://<username>:<password>@thot.adm.crans.org/<username>/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.
|
||||||
164
services/borg.md
164
services/borg.md
|
|
@ -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.
|
|
||||||
Loading…
Reference in New Issue