Openmediavault : Organisation des sauvegardes

Après voir mis en place mon serveur OMV, installé Plex, Nextcloud et qBittorrent-OpenVPN, il était temps de penser à la sauvegarde !

J’ai abandonné la baie Synology avec son RAID 1 (2 disques en miroir), et je n’ai plus qu’un seul disque sur mon magnifique Odroid-hc2 ! Et même si le RAID n’est une solution de sauvegarde, je ne sauvegardais que mes données avec la baie Synology.

Il s’agit maintenant de tout sauvegarder, alors voilà comment je me suis organisé :

  • pour les données, j’ai mis en place des jobs Rsync, ce que OMV permet de faire très facilement. La cible de sauvegarde se trouve sur le PC, sur lequel tourne un daemon Rsync.
  • pour le disque système d’OMV, après avoir essayé sans succès des scripts utilisant la commande dd, je me suis rabattu sur Clonezilla pour sauvegarder une image de la carte microSD qui sert de disque système au odroid-hc2.

Voyons tout cela en détail…

Le serveur Rsync sur le PC

On commence par installer un serveur Rsync sur le PC, où seront sauvegardées mes données d’OMV. J’ai déjà décrit en détail cette procédure dans un article au temps de la baie Synology, je me limite donc à l’essentiel ici :

Il faut d’abord autoriser le service rsync à se lancer en éditant le fichier /etc/default/rsync pour y modifier la ligne suivante comme suit : RSYNC_ENABLE=true.

Il faut ensuite créer un fichier de configuration /etc/rsyncd.conf pour y définir principalement le ou les différent(s) dossier(s) sur le PC qui seront utilisés pour chaque tâche de sauvegarde, qui est identifiée par un nom de module entre crochets :

pascal$ cat /etc/rsyncd.conf
uid = rsync
gid = rsync
max connections = 2
log file = /var/log/rsyncd.log
timeout = 300

[omv-films-rsync]
   path = /Disk1/OMV-FILMS
   comment = Sauvegarde fichiers Films de Plex sur le NAS OMV
   read only = false
   hosts allow = 192.168.1.30
   hosts deny = *

[omv-docus-rsync]
   path = /Disk2/OMV-DOCUS
   comment = Sauvegarde fichiers Docus de Plex sur le NAS OMV
   read only = false
   hosts allow = 192.168.1.30
   hosts deny = *

[omv-AppData-rsync]
   path = /Disk2/OMV-AppData
   comment = Sauvegarde fichiers AppData sur le NAS OMV
   read only = false
   hosts allow = 192.168.1.30
   hosts deny = *

On commence par définir l’utilisateur, puis pour chaque dossier un ‘module’ (par ex. [omv-rsync-films]) où l’on définit le chemin, l’adresse IP autorisée, etc…

Dans mon cas, c’est l’utilisateur rsync, et je place les films de mon serveur Plex dans un dossier sur Disk1, et vu la taille, je mets le reste sur Disk2, à savoir les documentaires de Plex, ainsi que toute la partie Docker d’OMV (docker + les fichiers de configuration des containers, voir l’article Déplacement de Docker).

Enfin, il faut créer l’utilisateur rsync, lui donner un mot de passe, puis les droits sur les dossiers utilisés :

sudo useradd rsync
sudo passwd rsync
sudo groupadd rsync
sudo gpasswd -a rsync rsync
sudo chown -R rsync:rsync /Disk1/Odroid-OMV
sudo chmod -R 775 /Disk1/Odroid-OMV

Voilà pour la partie côté PC (destination de la sauvegarde).

Les jobs Rsync côté OMV

Grâce à OMV, cette partie est vraiment très facile. On se place donc dans la section “Services-Rsync”, et l’on crée un ‘job’ pour chaque tâche que l’on souhaite définir :

Un job pour chaque dossier, avec la bonne syntaxe pour la destination.

Pour chaque job, on définit donc le mode “Push”, puis on sélectionne le ‘shared folder’ correspondant définit dans OMV. Pour la destination, la syntaxe est la suivante : nom_utilisateur@adresse_IP_distante::nom_module_rsync (donc l’adresse de mon PC et le nom du module définit dans le ficher /etc/rsyncd.conf). Enfin, on entre le mot de passe attribué au compte rsync sur le PC.

La syntaxe du ‘Destination Server’ est primordiale…

Dans les options, vous pouvez choisir d’envoyer un mail grâce au système de notifications d’OMV (si vous l’avez défini). Penser aussi à activer l’option “Recursive”. Enfin, pour tester le fonctionnement, on peut activer l’option “Trail run” pour simuler une sauvegarde (à désactiver ensuite bien entendu).

Docker

Toute la partie Docker est désormais sauvegardée, puisque Docker y compris les containers d’une part, et les fichiers de configuration d’autre part, se trouvent dans AppData, voir l’article Déplacement de Docker pour le détail.

En résumé, j’ai d’abord déplacé Docker dans /srv/dev-disk-by-label-DATA/AppData/Docker (et donc tous les containers), puis pour chaque container créé, je fais bien attention à définir le volume ‘config’ dans /srv/dev-disk-by-label-DATA/AppData/nom_container.

De cette façon, je pourrais reconstruire ma configuration Docker rapidement et facilement en restaurant AppData.

Le disque système

Sur l’odroid-hc2, le disque système est une carte microSD (comme sur les raspberry), et le disque contient raspbian ainsi qu’Openmediavault. Il est donc primordial d’avoir une sauvegarde de ce disque, la durée de vie d’un carte microSD n’étant pas éternelle, loin s’en faut.

C’est d’ailleurs pour cela que l’on évite d’écrire dessus, l’idée étant de travailler le plus possible en mémoire. C’est aussi pour cette raison que j’ai déplacé Docker sur le HD.

La commande dd

J’ai d’abord testé des scripts utilisant la commande linux dd (data dump), qui permet de copier des fichiers, des partitions, ou un disque entier, tout en contrôlant la taille des blocks. C’est l’outil idéal pour cloner rapidement un disque dans le monde Linux.

L’idée était d’utiliser le port USB de l’odroid-hc2 pour y insérer une carte microSD, puis de créer une tâche planifiée (cron) pour automatiser la copie du disque système, disons chaque semaine. Sur le papier, c’était top : une fois mis en place, rien de particulier à faire, et on a toujours une sauvegarde récente du disque système récente toute prête.

Sauf qu’en essayant d’utiliser la sauvegarde, j’avais des messages d’erreur du genre “Failed to connect to socket: Connection refused” ou “address already in use”.

Le problème est classique : on sauvegarde un système en cours de fonctionnement, certains fichiers sont ouverts, et comme avec Linux tout est fichier, et les sockets aussi ! 🙁

Clonezilla + KVM

J’ai cherché une solution à ce problème sur internet sans succès, et j’ai rapidement laissé tombé. Pour faire un backup propre, mieux vaut le faire système éteint. Je me suis donc tourné vers Clonezilla, la star des clones de disques dans l’open source.

J’ai donc fait un shutdown d’OMV, et extrait la carte microSD de l’odroid-hc2. Avec l’idée d’utiliser le PC pour faire cette copie de disque-système sur une deuxième carte microSD de la même taille.

Mais je n’avais pas envie de redémarrer le PC sur une clef USB où j’avais flashé Clonezilla. Je me suis donc dirigé vers l’utilisation d’une machine virtuelle KVM, puisque c’est ce type de VM que j’utilise sur le PC. Et cela s’est révélé hyper simple et efficace, même s’il ne faut pas se tromper dans ce que l’on fait.

On lance donc n’importe quelle console de VM, puisque l’on va démarrer sur un port USB, on passe en vue “Afficher les détails”, puis on clique sur ajouter un matériel. Il s’agit maintenant de sélectionner trois périphériques USB :

  • la clef où se trouve CLonezilla
  • la clef où se trouve la carte microSD d’OMV (via un adaptateur)
  • enfin, un disque USB qui servira à stocker l’image que l’on va faire (pour la sauvegarde).

Dans l’exemple ci-dessous, je vais sélectionner l’Alcor Micro (Clonezilla), Sandisk (OMV) et LaCie (sauvegarde).

On sélectionne les 3 périphériques USB dont nous avons besoin.

Puis on va dans “Options de démarrage”, et on sélectionne le périphérique USB où se trouve Clonezilla. Il ne reste plus qu’à démarrer la VM :

On choisit l’option par défaut, inutile de se compliquer la vie.

Inutile de s’embêter avec les réglages clavier, on n’utilisera que les touches tabulations, flèches haut/bas, et Entrée… Ensuite, au premier écran, on choisit “disque/partition vers/depuis image”.

Puis monter un périphérique local, où l’on choisira le disque USB que l’on a sélectionné précédemment :

Si le disque en question est partitionné comme c’est mon cas, on choisit une partition :

Je choisis une partition de 1GB où je pourrai sauvegarder l’image de mon disque OMV.

Il faudra ensuite choisir un dossier où sera effectuée la sauvegarde, et lui donner un nom (un nom par défaut est proposé, on peut le modifier). Laissez le défaut à priori. Reste à sélectionner le disque à sauvegarder :

Je choisis la carte SanDisk de 15 GB que je souhaite sauvegarder

Reste à choisir les dernières options : format de l’image, vérification de la sauvegarde, etc… Confirmez votre choix (deux fois), puis la sauvegarde démarre. Cela prend un certain temps (on sauvegarde 15 Go tout de même), surtout si vous avez demandé une vérification (recommandé). Quand tout est terminé, vous propose d’arrêter le système. Faire Entrée et choisir ‘poweroff’. La VM va alors s’éteindre.

Voilà, la carte microSD (le disque système d’OMV), est maintenant sauvegardé sur un disque du PC.

Pour la restauration vers une autre carte microSD, la procédure est très similaire, sauf que vous choisirez de l’image du disque dur comme source, et la carte microSD comme destination. Je m’épargne la série de capture d’écrans ! 😉

Pour ceux que l’interface de Clonezilla rebute, je viens de voir passer une information sur Rescuezilla, compatible avec Clonezilla (même s’il n’offre pas toutes les options du mode Expert de ce dernier), mais avec une interface beaucoup plus sympathique et facile d’accès.

Stratégie

Une fois cette sauvegarde terminée, j’ai utilisé cette nouvelle carte microSD pour redémarrer mon système OMV, afin de m’assurer que l’image était totalement fonctionnelle. Et je procède ainsi à chaque sauvegarde.

J’avais déjà fait une première sauvegarde de ce type avant de déplacer Docker et d’installer un container qBittorrent. J’ai donc procédé à une nouvelle sauvegarde de mon disque système, et j’ai redémarré avec ma nouvelle sauvegarde.

Et donc à chaque modification importante du système, je procéderai de la sorte. En faisant tourner les cartes microSD à chaque fois, non seulement je fais une sauvegarde, mais je valide la restauration.

Car comme on dit en informatique, le “Disaster” c’est toujours très facile à réussir, le “Recovery” beaucoup moins ! 😎

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *