Un plan de reprise d'activités est la marche à suivre après une perturbation pour retrouver le niveau de services de départ.

Dans le cadre du serveur, il s'agit de remettre en production les sauvegardes afin que les services de TCHACK continuent à être disponibles, suite à la destruction du Raspberry Pi ou à la coupure de l'accès Internet.

Sur une infrastructure où Yunohost est disponible (cf. les prérequis et versions disponibles sur https://yunohost.org/#/hardware_fr, à ce jour uniquement les architectures x86 ou armhf), on crée un serveur debian 8 (jessie) avec un administrateur root doté d'un mot de passe. Il peut s'agit d'un VPS chez un hébergeur (OVH, Scaleway, un CHATONS local), ou bien d'une machine physique hébergée derrière une bonne connexion internet (Fibre idéalement).

Noter l'adresse IP (v4 et v6) du serveur pour l'étape suivante. Le service web https://api.ident.me peut être utile à requérir facilement via curl.

Chez le fournisseur de nom de domaine, ou “registrar” (aujourd'hui OVH pour le domaine tchack.xyz), on modifie les champs A et AAAA de la Zone DNS pour correspondre aux nouvelles adresses IP du serveur.

Conformément au protocole DNS, la modification ne sera complètement diffusée sur Internet (et donc chez votre fournisseur d'accès Internet) qu'à l'expiration de la durée “TTL” (time to live) du champ (réglée normalement à 24h). Dans l'intervalle, vous obtiendrez probablement une erreur d'adressage. On peut contourner cela en modifiant le fichier local des hôtes connus.

On installe sur Debian 8 la “surcouche” Yunohost, en suivant le mode d'emploi à l'adresse : https://yunohost.org/#/install_on_debian_fr

Principalement, on récupère le script d'installation par git clone https://github.com/YunoHost/install_script /tmp/install_script.

Il ne faut pas réaliser la post-installation (qui correspond à la création d'un nouveau serveur), car les paramètres demandés sont déjà fixés dans la sauvegarde à restaurer.

- En Théorie :

On récupère, sur le serveur de sauvegarde, les fichiers .tar.gz et .json de la dernière sauvegarde effectuée, pour les placer dans le dossier /home/yunohost.backup/archives.

Puis on appelle la restauration de sauvegarde soit par l'interface web, soit par la commande yunohost backup restore NomDeLaSauvegarde (sans le '.tar.gz'), conformément à la procédure décrite dans la documentation https://yunohost.org/#/backup_fr

- En pratique le 13/12/2017 :

En raison de différents bugs non-corrigés, il faut se renseigner sur le forum (https://forums.yunohost.org) avant de lancer la procédure de restauration. Parmi les points relevés, il faut définir la commande “archivemount” en y copiant ainsi : cp /bin/false /usr/bin/archivemount.

Par ailleurs, les restaurations par l'interface web sont souvent refusées, notamment pour les applications qui restent introuvables. Il faut passer par la CLI en précisant l'option - -apps NomDeLapp, et - -force lorsqu'une première restauration ou post-install a déjà eu lieu.

Encore une étape avant la restauration : sur les conseils de https://weakdh.org/sysadmin.html, la configuration du serveur web Nginx avec SSL s'appuie sur un paramètre Diffie-Hellmann généré localement, à 2048 bits. Le fichier /etc/ssl/private/dh2048.pem doit donc être récupéré du serveur de sauvegarde, ou re-généré, faute de quoi Nginx ne se lance pas et met en échec le reste de la restauration.

- En pratique le 05/06/2020 : Le transfert des backups multi-applis sur un nouveau VPS s'est très bien passé. Seul point en erreur : les certificats SSL LetsEncrypt (voir ce fil du forum). Il faut non pas les renouveler mais les installer (cert-install) car la clé privée n'est pas encore créée.

Un reporting de ces erreurs et difficultés doit être fait auprès du projet Yunohost.

Une fois les utilisateurs, les domaines et les applications (natives) restaurées, il faut réparer ce qui n'est pas inclus dans Yunohost, à savoir l'application RPi-Monitor, que l'on peut installer ici : https://github.com/XavierBerger/RPi-Monitor/. Elle se lance sur le port 8888 local, où redirige l'application yunohost redirect__6 avec l'adresse https://tchack.xyz/moniYH.

Une régénération des certificats SSL est aussi une bonne pratique, pour éviter des erreurs/alertes dans les navigateurs, dues à la réutilisation d'un certificat depuis une autre adresse IP ou machine.

Par ailleurs, certaines applications ne sauvegardent pas leurs bases SQL ou ne les restaurent pas. Une veille est à faire sur ce point, pour identifier les actions complémentaires à effectuer.