Backup d’une instance Mastodon (fonctionnant sous Docker)

Dans l’article précédent, je vous ai parlé de ma découverte de Mastodon et de mon enthousiasme à propos de ce nouveau réseau social.

J’ai donc rapidement mis en place une instance Mastodon. Cette instance me permet de participer à ma façon au réseau Mastodon. Mais surtout, elle me permet de rendre concret ma vision du réseau social idéal, où tout le monde est libre de choisir où il s’héberge: chez lui ou chez quelqu’un d’autre.

Personnellement, j’ai décider d’appliquer l’adage “On est jamais bien servit que par soi-même”. Il s’agit d’une solution qui apporte beaucoup d’avantages, dont le contrôle total sur les données. Mais ce contrôle a un prix : je suis responsable de mes données.

Que se passera-t-il le jours où un problème majeur se produit sur mon serveur? En cas de petite erreur de frappe lors d’une manipulation en console root? Et bien mes données disparaîtront, purement et simplement! Je perdrai mon compte, mes toots, mes followers, je n’existerai plus sur le réseau.

Cela serait bien dommage! Il faut donc mettre au point une stratégie de backup permettant de sauvegarder régulièrement les données du serveur, et de les restaurer en cas de soucis, sur le même serveur, et même sur un autre serveur chez un autre hébergeur.

Backup

Je dispose déjà d’un VPS de stockage sur lequel je backup déjà d’autres données, dont un backup journalier de ce blog. Je vais donc l’utiliser comme destination du backup de l’instance Mastodon.

Ce backup est effectué grâce à l’outil Rsnapshot. Il s’agit d’un petit utilitaire très pratique permettant d’effectuer des backups simplement, en se basant sur Rsync et SSH.

La difficulté réside ici dans le fait que mon instance Mastodon fonctionne sous Docker, et utilise un serveur de base de données Postgresql, et je ne connais aucun des deux.

Voici donc comment se passe le backup du côté du serveur de sauvegarde (c’est bien sur ce serveur qu’est exécuté rsnapshot):

  • Exécution d’une commande qui va générer un fichier ‘dump‘ de la base de données postgresql dans le répertoire ‘dumps‘ créé pour l’occasion dans le répertoire principal de l’instance.
  • Copie du répertoire ‘root’ de l’instance (c’est-à-dire le répertoire dans lequel on a fait le ‘git clone‘, le ‘docker-compose‘ et dans lequel se trouve le répertoire ‘public‘, ainsi que le répertoire ‘dumps‘ que nous avons créé dans le point précédent.

Voici ce que ça donne concrètement dans le fichier rsnapshot.conf:

# Mastodon
backup_script   /usr/bin/ssh user_de_backup@url.de.l-instance.com "docker exec -t mastodon_db_1 pg_dumpall -c -U postgres > /opt/mastodon/dumps/dump.sql" unused
backup  user_de_backup@url.de.l-instance.com:/opt/mastodon/       mastodon-backup/

La première ligne va permettre à rsnapshot de se connecter en SSH à l’instance, et d’exécuter la commande nécessaire pour générer fichier dump de la base de données. Notez que dans ce cas, le répertoire principal (root) de l’instance est dans /opt/mastodon).

La seconde ligne va demander à rsnapshot d’effectuer le backup complet du répertoire /opt/mastodon du serveur de l’instance, dans le répertoire mastodon-backup du serveur de backup.

Il suffit ensuite de lancer la commande

rsnapshot daily

pour effectuer un backup. Dans mon cas, c’est une tâche Cron qui est lancée 1x par jours.

Restauration

Le plus délicat quand on effectue un backup, c’est de s’assurer que celui-ci est suffisamment complet que pour pouvoir le restaurer facilement.

Voici la procédure que j’applique dans mon cas sur un autre serveur sur lequel je voudrais restaurer mon instance à partir du backup:

  • Re-télécharger les source de Mastodon. Il est sans doute préférable d’effectuer le ‘git checkout’ du tag sur lequel fonctionnait l’instance lors du backup:
$ git clone https://github.com/tootsuite/mastodon.git
$ git checkout tags/1.2.2
  • Effectuer l’installation de Mastodon:
$ docker-compose build
$ docker-compose run --rm web rails db:migrate
$ docker-compose up -d
  • Là, l’instance devrait fonctionner, mais avec une base de données vide. Avant d’aller plus loin, on va devoir réinstaller nginx et son certificat Let’s Encrypt (sans le cas où on effectue la restauration sur un serveur vide).
  • Restauration de la base de données:
$ cat your_dump.sql | docker exec -i mastodon_db_1  psql -U postgres
  • Redémarrage:
$ docker-compose restart

Et voilà! Après quelques secondes, l’instance doit redémarrer comme si de rien n’était, dans le même état que lors du backup!

Le mot de la fin

Cette procédure de backup est assez simpliste, mais fonctionne dans mon cas. Attention cependant que le backup n’est effectué qu’une fois par jours, et que donc, toute l’activité de l’instance entre le moment du backup et le crash sera perdu.

Notez aussi que le plus important lorsque l’on met en place une procédure de backup, c’est de la tester!!! Chaque installation est différente, et Mastodon est en évolution très rapide! Il est donc primordial de tester fréquemment ses backups afin de s’assurer que la procédure est toujours applicable.

.

Leave a Reply

Your email address will not be published. Required fields are marked *