technique:adminsys:backup:troubleshooting

Différences

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

Lien vers cette vue comparative

technique:adminsys:backup:troubleshooting [2022/09/25 06:33] – créée rdelaagetechnique:adminsys:backup:troubleshooting [2022/09/25 06:34] (Version actuelle) rdelaage
Ligne 1: Ligne 1:
 # Troubleshooting # 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/troubleshooting.1664080405.txt.gz
  • de rdelaage