technique:adminsys:backup:install_and_config

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:adminsys:backup:autorestic [2022/09/23 10:21] – modification externe 127.0.0.1technique:adminsys:backup:install_and_config [2023/06/26 16:15] (Version actuelle) – [Configuration de restic-server] ppom
Ligne 1: Ligne 1:
-Configuration de autorestic+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]] On a déjà des backups des images de machines virtuelles, qui sont [[technique:infrastructure:backup|faits par les hyperviseurs]]
Ligne 56: Ligne 56:
 ``` ```
 ## Installation du service / timer systemd ## Installation du service / timer systemd
- 
-`/etc/systemd/system/autorestic.service` 
-```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` 
-```systemd 
-[Unit] 
-Description=Backups yay 
- 
-[Timer] 
-# Trigger every 10 minutes 
-OnCalendar=*:0/10:0 
- 
-[Install] 
-WantedBy=timers.target 
-``` 
  
 ```bash ```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 daemon-reload
 sudo systemctl enable autorestic.timer sudo systemctl enable autorestic.timer
 sudo systemctl start autorestic.timer sudo systemctl start autorestic.timer
 ``` ```
 +## Configuration de restic-server
  
-## Configuration du user backup+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.
  
-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. +**TODO finir cette partie**
- +
-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`.+- 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`. 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`.
Ligne 181: Ligne 149:
 <bootnote warning>Deux instances d'`autorestic` ne peuvent pas tourner simultanément. Or `autorestic` est souvent lancé par `cron`, donc attention.</bootnote> <bootnote warning>Deux instances d'`autorestic` ne peuvent pas tourner simultanément. Or `autorestic` est souvent lancé par `cron`, donc attention.</bootnote>
  
-## Troubleshooting 
- 
-### Trop de place prise 
- 
-Exemple : le disque de backup explose. 
- 
-Étrange : on regarde sur `pica01` au hasard la taille prise par les backups sur le dépôt distant Restic. Pour les données de `pica01`, il se trouve sur `pica03`. 
- 
-```bash 
-$ sudo autorestic -vvv -b pica03 exec stats 
-enter password for repository:  
-repository b0ca7112 opened successfully, password is correct 
-scanning... 
-Stats in restore-size mode: 
-Snapshots processed:   4176 
-   Total File Count:   25892853 
-         Total Size:   10.881 GiB 
-``` 
- 
-Note : `autorestic` tagge chaque snapshot avec la syntaxe `ar:location:<location>`, `<location>` étant une clé de la section `location` du fichier de configuration qui indique quels chemins sauvegarder. Pour ne vérifier la taille que d'un service, exemple : 
- 
-```bash 
-$ sudo autorestic -b pica03 exec stats -- --tag ar:location:etherpad-yearly 
-``` 
- 
-Pour revenir à notre exemple précédents, 4176 snapshots, c'est beaucoup, c'est anormal. On essaye de lancer un `forget` manuel pour supprimer les vieux backups. 
- 
-<bootnote>Normalement, on a pas à le faire à la main, car l'option `forget: prune` est spécifiée pour tous les dossiers sauvegardés. Voir la [documentation](https://autorestic.vercel.app/location/forget#automatically-forget-after-backup) et les [fichiers du dépôt Git](https://gitlab.utc.fr/picasoft/projets/backups/-/blob/master/pica01/autorestic.yml).</bootnote> 
- 
-<bootnote web>Documentation de `autorestic forget` : https://autorestic.vercel.app/cli/forget</bootnote> 
- 
- 
-<bootnote critical>Cette commande supprime définitivement les snapshots qui ne sont plus considérés comme valides selon la politique de sauvegarde.</bootnote> 
- 
-```bash 
-$ sudo autorestic -vvv forget --prune -a 
-repository b0ca7112 opened successfully, password is correct 
-unable to create lock in backend: repository is already locked by PID 886695 on pica01 by root (UID 0, GID 0) 
-lock was created at 2022-06-10 08:19:04 (654h30m9.367618574s ago) 
-storage ID 48ba5a2f 
-the `unlock` command can be used to remove stale locks 
-``` 
- 
-On voit qu'un fichier de lock existe depuis le 10 juin (à la date du 07 juillet). Ce fichier de lock est obsolète mais empêche la suppression de fichier du dépôt. Comme le suggère la commande, on peut forcer à supprimer le verrou avec la commande `unlock` de restic. 
- 
-<bootnote>À ne bien évidemment jamais faire lorsque restic est en train de faire un backup, cf `ps aux | grep restic`.</bootnote> 
- 
-Exemple : 
- 
-```bash 
-$ sudo autorestic -vvv -b pica03 exec unlock 
-repository b0ca7112 opened successfully, password is correct 
-successfully removed locks 
-``` 
- 
-On peut à présent exécuter la commande. 
  • technique/adminsys/backup/install_and_config.txt
  • de ppom