Doit on rappeler l’importance de sauvegarder les données de son serveur ? Et plus vital encore, de tester régulièrement la restauration de ses sauvegardes. Un adminsys averti le sait, mais qu’en est-il des personnes dont l’informatique n’est pas leur cœur de métier et qui se sont lancées dans l’autohébergement grâce à des solutions comme l’excellentissime distribution Yunohost.

Et comme trop souvent, c’est le jour où ton serveur crashe que tu te dis que tu n’aurais jamais dû procrastiner l’étape des backup.
Il existe plusieurs méthodes pour sauvegarder son serveur yunohost . L’idée de ce billet étant de proposer une solution pour sauvegarder/restaurer le système et les applications sans se prendre la tête et de limiter la perte de ses données.

Stratégie de backup ?

Mais avant de passer à l’action , il est nécessaire que tu prennes le temps de répondre à ces quelques questions qui te permettront de définir ta stratégie de sauvegarde :
– Quoi sauvegarder? Quelles données? Système? Applicatives? Les deux ?…
– Où le faire? sur un disque dur externe, vers une machine du même réseau , vers une machine extérieure?
– Comment sauvegarder? A quelle fréquence? Sauvegarde incrémentale, différentielle? Chiffrement?

L’objet de ce billet n’est pas de s’attarder sur ces enjeux mais de te donner une recette simple pour minimiser la perte de tes données en cas d’incident. Pour t’aider à appréhender les notions de sauvegarde, tu peux t’inspirer de la doc officielle yunohost ici et aussi de ce diaporama à destination des néophytes dont j’avais fait la présentation au festival Libre en fête.

Quelle solution pratique pour sauvegarder sur Yunohost ?

En général pour sauvegarder tu peux :

• utiliser tes propres scripts à base de rsync. Ça fonctionne très bien mais lourd à gérer pour quelqu’un qui ne connaît pas bien le bash et ses subtilités systèmes.
  
• utiliser une application dédiée comme Borgbackup. Un très bon choix , notamment pour ses options de déduplication et de chiffrement qui permettent d’avoir des sauvegardes sécurisées et rationalisées. Mais pas forcément évident à mettre en place pour un néophyte.
  
• autre solution , propre à Yunohost, utiliser son interface web et ses commandes internes. La meilleure solution selon moi pour qui débuterait.
  
  Encore une fois, le but de ce billet est de rester le plus simple possible , pardon d’avance pour les puristes de la sauvegarde. Nous allons donc voir comment faire une sauvegarde complète puis comment faire pour l’automatiser.

Sauvegarder en mode manuel

Pour créer une sauvegarde complète manuelle, tu as le choix :

1. le faire à partir de l’interface d’administration de Yunohost
2. le faire à partir d’un terminal en ligne de commande

Dans notre exemple , nous allons nous concentrer pour faire une sauvegarde système. Elle contiendra donc les fichiers concernant :

• Les données utilisateurs situées dans /home/USER
• L’annuaire des utilisateurs (ldap)
• La configurations de YunoHost,
• Les certificats SSL,
• Les fichiers de configuration modifiés manuellement

Voyons voir comment faire tout ça en 1 clic…

1 – Sauvegarder via l’interface:

Menu ‘sauvegardes’ – ‘créer une sauvegarde’.

On coche les données systèmes à sauvegarder. Je te conseille surtout :
– « Configurations systèmes »
– « Données des utilisateurs »

Pour les applications, coche celles qui te semblent les plus indispensables, comme par exemple Nextcloud. Mais avant assure toi aussi d’avoir assez de place sur ton disque de sauvegarde pour pouvoir les stocker.

Selon le poids de tes données , la sauvegarde peut prendre un certain temps. Sur ma raspberry3 , ça m’a coûté 28 minutes pour une archive .tar de 7gb.

Tu possèdes donc maintenant une sauvegarde complète de tes fichiers systèmes ce qui te permettra en cas d’incident de restaurer les profils utilisateurs entre autre (on voit ça à la fin du billet).

Voyons voir maintenant une alternative qui te permettra de faire la même chose mais depuis la ligne de commande.

2 – via le terminal

La commande à taper pour tout sauvegarder (système et applis):

sudo yunohost backup create

– pour sauvegarder uniquement les fichiers de conf système:

sudo yunohost backup create --system

– pour sauvegarder uniquement les applis:

sudo yunohost backup create --apps

– pour sauvegarder que certaines applis:

yunohost backup create --apps nextcloud calibre

Dans mon cas , je choisis de sauvegarder la conf système:

Voilà on a notre fichier de sauvegarde sous forme d’une archive tar.

Pour vérifier les fichiers qu’elle contient, tu peux les lister comme ça:

tar -tvf /home/yunohost.backup/archives/20230301-091951.tar | less

Sauvegarde automatisée

Malheureusement l’interface de Yunohost ne prévoit pas la possibilité de réaliser une sauvegarde automatisée. Il va donc falloir scripter un peu en bash mais rien de compliqué tu vas voir.

on crée le fichier script appelé ‘backup_syst.sh’ qui fera:
– la purge des archives âgées de plus de 1 mois
– la sauvegarde complète des fichiers systèmes de Yunohost

#!/bin/bash
# sauvegarde systeme complete de yunohost

rep="/home/yunohost.backup/archives"
log="/tmp/backup_syst.log
>$log # raz du log

# on supprime les backup vieux de plus de 30 jours
$(find $rep -type f -iname "*.tar" -mtime +30 -delete > $log)

# on crée une nouvelle sauvegarde systeme
$(yunohost backup create --system 2>/dev/null >> $log )

Rendre exécutable le script:

chmod u+x backup_syst.sh

Planifier la sauvegarde:

Pour notre exemple, nous planifierons un backup hebdomadaire :

sous linux , ça se passe dans la crontab:

vi /etc/crontab

Ajouter cette ligne pour sauvegarder par exemple tous les mercredi à 03h du matin:

0 3 * * 3 /root/SCRIPTS/backup_syst.sh 

Restaurer une sauvegarde Yunohost ?

A partir du menu – Sauvegardes – Local, sélectionner l’archive à restaurer puis cliquer sur le bouton restaurer en bas à droite.

Tu vois ce n’est pas plus compliqué que ça.

Dans un prochain article nous verrons comment ajouter un disque dédié et monter le répertoire de sauvegarde dessus.

Cet article Sauvegarder son serveur Yunohost pour les nuls (1/2) est apparu en premier sur tutox.fr.

Parfois il m’arrive pour me connecter à un serveur en ssh de ne plus me souvenir exactement de ma passphrase.Peu importe me direz-vous , je n’ai qu’à utiliser mon gestionnaire de mot de passe. Mais j’ai aussi quelques vieux comptes qui trainent que je n’ai pas nettoyés (mybad) et qui du coup m’induisent en erreur en me proposant une phrase de passe obsolète.

Et bien sûr comme un bourrin je l’essaye plusieurs fois d’affilée sans succès jusqu’à me faire bloquer par les règles de sécurité un peu strictes de mon propre serveur. 3 tentatives infructueuses et c’est le ban pour quelques minutes !
Dès lors comment faire pour retrouver sa passphrase sans se faire bannir ? Yaurait pas un moyen de tester en local la passphrase de sa clé privée avant de la taper pour de vrai sur le serveur ?

La commande de test

ssh-keygen -y -f private_key

si c’est ok, il t’affiche le hash correspondant.

si c’est pas bon tu obtiendras le message  » incorrect passphrase supplied to decrypt private key« 

Évidement le mieux c’est d’utiliser et renseigner correctement son gestionnaire de mots de passe pour ne pas galérer la prochaine fois

Cet article Oups j’ai oublié ma passphrase ssh… est apparu en premier sur tutox.fr.

L’autre jour, Monsieur WordPress m’a rappelé que la version de php que j’utilise pour mon blog était obsolète. En effet, je suis en 7.4 et il est vivement conseillé de passer à php8. La montée de version de php n’est pas une opération anodine : des plugins peuvent péter, des templates s’abîmés. Alors comme toute migration de cette importance, Il est vivement conseillé d’anticiper ses éventuels effets de bord  sur un environnement de tests, où l’on pourra tout casser à volonté. D’habitude, je travaille sur une VM avec apache ou j’héberge une copie de mon blog . Mais là je me dis, que dans une démarche de sobriété (noooooon sudo systemctl stop bulshit) ce serait l’occasion parfaite pour remettre le nez dans docker et monter ma stack wordpress de dev.

Donc le but de ce billet avoir un environnement de tests pour wordpress qui soit identique avec celui qui fait tourner mon blog en prod. Je pars du principe que tu as déjà installé docker-compose sur ton host.

On va y aller par étapes:
1 – sauvegarder données du blog wordpress en prod
2 – monter la stack avec docker-compose
3 – réintégrer les données (base sql + fichiers)

Donc j’aurais besoin:
– 1 conteneur apache
– 1 conteneur phpmyadmin
– 1 conteneur mariadb

Afin de simplifier , j’ai volontairement zapper la partie reverse proxy et https. ce sera l’objet d’un prochain billet.

1 – Sauvegarde du blog actuel

Toujours l’occasion de revérifier qu’elles sont fonctionnelles
– le fichier sql du dump de la bdd
– les fichiers data wordpress (dans /var/www/wordpress/wp-content) et le fichier wp-config.php

2 – Créer le docker-compose

• être iso avec la prod (versions php ,mariadb,wordpress)
• avoir un fichier .env qui centralise variables d’environnement

Pour le docker-compose:

version: '3.3'

services:
   db:
     container_name: mariadb-wp
     image: mariadb:10.3.34
     env_file: .env
     volumes:
       - wp_db:/var/lib/mysql/
     restart: always
     networks:
     - wp

   wordpress:
     depends_on:
       - db
     container_name: wordpress
     image: wordpress:6.0-php8.1-apache
     volumes:
       - wp_statics:/var/www/html/
     ports:
       - 8087:80
     restart: always
     networks:
     - wp

   phpmyadmin:
     depends_on:
       - db
     image: phpmyadmin/phpmyadmin
     restart: always
     ports:
       - 8088:80
     environment:
       PMA_HOST: db
     networks:
     - wp

networks:
  wp:
    driver: bridge

volumes:
  wp_db:
    driver: local
    driver_opts:
      o: bind
      type: none
      device: /srv/wordpress/db
  wp_html:
    driver: local
    driver_opts:
      o: bind
      type: none
      device: /srv/wordpress/html

3 – Créer un fichier .env

copier/coller les lignes et adapter avec les valeurs qui vont bien:

MARIADB_ROOT_PASSWORD: mdpcomplexce
MARIADB_DATABASE: wordpress
MARIADB_USER: userbase
MARIADB_PASSWORD: xxxxxx

pour le conteneur wordpress:

WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: userbase
WORDPRESS_DB_PASSWORD: xxxxxx

Créer les volumes:
mkdir /srv/wordpress/{db,html}

Lancer la stack:
docker-compose up -d

on vérifie que nos conteneurs s’exécutent bien :
docker ps

Si jamais le status est en « exited » , on vérifie les logs pour débuguer:
docker logs mariadb-wp

Si besoin , se connecter au conteneur mariadb par ex et tester la connexion au sgbd:
docker exec -it mariadb-wp /bin/bash

Créer l’utilisateur de la base de données:
mysql> CREATE USER ‘user’@’localhost’ IDENTIFIED BY ‘password’;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON * . * TO ‘user’@’localhost’;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

4 – Éditer le wp-config:

Réintégrer et copier le fichier wp-config.php du blog de prod: 
sudo cp backup/wordpress/wp-config.php /srv/wordpress/html/

Vérifizer les lignes suivantes et au besoin adapter avec les bonnes valeurs, mais normalement ya rien à toucher:

/** Nom de la base de donnée */
define( ‘DB_NAME’, ‘wp’ );

/** Utilisateur de la base de données MySQL. */
define( ‘DB_USER’, ‘tutox’ );

define( ‘DB_PASSWORD’, ‘ pasworddedingue’ );

/** Adresse de l’hébergement MySQL. */
define( ‘DB_HOST’, ‘localhost’ );

Parfois, pour le DB_HOST il faut mettre le nom du service docker , ici appelé ‘db’ dans le docker-compose.
C’est ici aussi qu’il faut préciser le port sur lequel écoute mariadb. Parfois on le change car on a déja un service sql qui tourne sur le 3306. Donc là on pourrait mettre par ex: localhost:3307 ou db:3307.

5 – Importer la base sql

docker exec -i conteneur mysql -uroot -pmotdepassecomplexe < backups/blog.sql

6 – Synchroniser les fichiers:

sudo rsync -azv backups/blog/wp-content/ /srv/wordpress/html/wp-content/

Vérifier les droits, si pas bons alors:

chown $user -R /srv/wordpress/statics/wp-content/

7 – Modifier les URL du site:

Ouvrir phpmyadmin éditer les liens dans wp_options:

Test url en local:
http://@ip_locale:8087

Et voilà une instance de wordpress toute pareille que celle de prod. On va pouvoir tester, casser et tout reconstruire

Dans un prochain billet on peaufinera avec notamment l’utilisation d’un reverse proxy et l’utilisation du https.

liens utiles:
https://xavki.blog/docker-compose-tutoriaux-francais/
https://www.alsacreations.com/tuto/lire/1838-Docker-compose.html
https://www.armandphilippot.com/article/docker-compose-traefik-wordpress
https://blog.ouvrard.it/2016/02/22/migrer-mon-wordpress-vers-docker/
https://www.digitalocean.com/community/tutorials/how-to-install-wordpress-with-docker-compose