Migrer Nextcloud vers maria-db remote

Voici le scénario:

Vous décidez de reprendre contrôle de vos données. Vous installez nextcloud, peut-être par une image docker avec une base de données déjà configurée. Tout fonctionne à merveille pendant quelques mois et vous commencez à regarder les utilisateurs de cloud gratuits comme des ennemis publiques. Après une synchronisation de plusieurs centaines de photos de vacances et des milliers de documents, votre instance de Nextcloud ralentit sauvagement. Vous vous demandez si finalement le cloud financé par de la pub ne serait pas un compromis acceptable.

Et b’en non! Parce que vous avez installer PiHole/Adguard pardi! Il est donc temps de regarder comment optimiser Nextcloud ou toute autre application nécessitant une base de donnée configurable. Il est bien compris que les applis comme Sonarr ou Plex qui incluent SQLite mais qui ne vous permettent pas de l’externaliser ne seront pas pris en compte dans ce tuto. Nous avons aussi comme axiome que le disque système de votre machine est déjà installé sur quelque chose de rapide (ex. VM sur SSD avec plein de RAM et un nombre de coeurs CPU adéquat).

Nous allons donc externaliser la BDD (Base de Données) vers sa propre VM. L’intérêt est de centraliser les DB et ainsi d’en faciliter la sauvegarde et la restauration. Donc pour les grandes lignes :

• Installer Debian avec maria-db sur une VM,
• Configurer maria-db pour accepter les connexions extérieurs,
• Créer un DB et utilisateur avec les propriétés inclus dans la configuration Nextcloud,
• Mettre Nextcloud en « maintenance » et exporter ses données SQL,
• Importer ces données dans notre nouvelle BD,
• Finito!

Procédons par étapes:

1. Installer Debian avec maria-db sur une VM

Il est compris ici que vous pouvez installer maria-db sur Ubuntu ou autre distrib de votre choix. A titre d’exemple, je vais choisir Debian. Les principaux points à retenir :

• 1 CPU pour le moment,
• 32 Go de disque si vous n’avez que des petites BD,
• 2 Go de RAM pour démarrer,
• Figez l’adresses IP de la VM dans votre box/routeur après son démarrage,
• Installez qemu-guest-tools, pour avoir des shutdown propres et infos comme les addresses IPV4 et 6,
• Rajoutez votre clé SSH dans /root/.ssh/authorized_keys pour vous connecter facilement.

2. Installation maria-db et adminer

Donc je me connecte à la VM par SSH.

• Installation de maria-db serveur et client :

sudo apt -y install mariadb-server mariadb-client

• Sécurisation de maria-db. Un guide détaillé est disponible ici: https://www.digitalocean.com/community/tutorials/how-to-install-mariadb-on-debian-10

sudo mysql_secure_installation 

• (optionnel) Installation et sécurisation de ad-miner – Ad-miner est une application permettant de gérer maria-db en interface web. Si vous préférez la ligne de commande, vous pouvez sauter cette étape.

wget "http://www.adminer.org/latest.php" -O /var/www/html/adminer.php

chown -R www-data:www-data /var/www/html/adminer.php
chmod 755 /var/www/html/adminer.php

3. Paramétrage maria-db

Par défaut seuls les machines en local sur la VM de maria-db peuvent accéder à la base de donnée. Afin de permettre toutes les machines du réseau d’y accéder, telles que Nextcloud ou Home Assistant, on va ici :

nano /etc/mysql/my.cf

Et on rajoute cela à la fin du fichier :

[mysqld]
skip-networking=0
skip-bind-address

Et on redémarre maria-db :

service mysqld restart

Pour vérifier que ça marche bien on peut visualiser le statut du serveur mysql :

Parce qu’un petit test de connexion n’est pas de trop, on se dirige vers AdMiner et on se loggue en root sur notre nouvelle instance de maria-db :

http://<votre IP adminer>:8090

Donc, maria-db fonctionne et je peux m’y connecter, créer des tables et des utilisateurs via adminer.

Pour tester si maria-db peut se connecter d’une autre machine du réseau, on part en SSH sur la machine en question et on essaye de se connecter à maria-db (en ayant ou en installant mysql-client, bien-sur) :

mysql -u <mon nom d'utilisateur root sur maria-db> -p --host=<mon IP maria-db>

4. Exporter la base Nextcloud

On est fin prêt à importer la base Nextcloud dans notre nouvelle instance maria-db. Pour rappel, seule la base va être migrée et non pas vos données (photos, documents, etc.)

Pour cela, voici les grandes étapes :

• Mettre Nextcloud en mode « maintenance » pour éviter les modifications de base de donnée pendant la migration. On ne peut pas simplement arrêter la machine car on a encore besoin d’exporter la base de donnée.
• Exporter la base actuelle nextcloud en suivant votre architecture (ex. Nextcloud sur docker dans un VM Proxmox, ou directement sur une VM ou en bare-metal sur un raspberry pi, etc.).
• Copier le fichier .sql exporté, et l’importer dans notre nouvelle maria-db.

Donc, on procède en mettant Nextcloud en mode maintenance. Mon NC est sur docker et donc je vais en SSH sur la VM docker et j’entre dans le container nextcloud :

root@docker:~# docker exec -ti -u www-data <container nextcloud> /bin/bash

On remarque que j’utilise « -u www-data » afin de me logguer sur NC en tant qu’utilisateur web. Sinon je ne pourrais pas executer l’utilitaire « occ » de nextcloud pour le mettre en mode maintenance.

Ensuite j’éxecute occ pour mettre NC en maintenance :

www-data@27e2056ad0ed:~/html$ ./occ maintenance:mode --on

Si la commande de marche pas, vérifiez que vous avez bien « occ » sous /var/www/html

Ensuite, on va exporter la bdd NC. Pour ce faire, il faudra se logguer sur le containeur de l’ancienne BDD NC. Dans mon cas, nextcloud a été installé avec une BD sous docker. Je vais donc me logguer sur le vieux container maria-db :

root@docker:~# docker exec -ti maria-db /bin/bash

Et ensuite, je dump (exportation de la base nextcloud) :

mysqldump -u root -p --databases <nom de bd nextcloud> > /etc/mysql/mydump.sql

Pour vérifier que le dump a bien été fait, je regarde le fichier mydump.sql :

cat mydump.sql | more

Et maintenant, la partie facile. Je place mon fichier mydump.sql dans ma nouvelle VM maria-db (par filezilla, ou autre). Avant d’importer le lot, je crée un BD nextcloud sur maria-db avec un utilisateur « nextcloud ». Et tout cela en passant par ligne de commande ou Adminer.

Notez le « % » qui permet a n’importe quel IP de se connecter avec l’utilisateur « nextcloud ». On peut aussi faire « 192.168.%.% » pour vérouiller l’utilisateur « nextcloud » aux IP locaux du réseau. Il faudra faire bien attention de sélectionner la BD « nextcloud » avant de créer l’utilisateur. Retenez bien le nom de la BD crée, ici « nextcloud » ainsi que les « username » et « password » car nous allons les utiliser dans la prochaine étape.

Ensuite, j’importe simplement mon fichier « mydump.sql » pour populer la nouvelle bd nextcloud.

Si tout a bien fonctionné, ce qui devrait être le cas, car on importe d’une ancienne base maria-db vers une nouvelle base du même type, on voit ceci en cliquant sur « nextcloud » :

5. Reconfigurer nextcloud avec la nouvelle BD maria-db.

Il faudra maintenant dire à NC qu’il utilise une nouvelle BD. Pour cela on se loggue en SSH sur la VM/container NC et on va dans sa « config.php » pour NC. Sur l’image docker de NC que j’utilise, cela se trouve dans :

~/html/config/config.php

On va modifier ce fichier et mettre à jour les champs suivants, surlignés en jaune :

'dbname' => 'nom de ma base nextcloud',
'dbhost' => 'addresse IP de mon maria-db',
'dbuser' => 'utilisateur nextcloud',
'dbpassword' => 'mot de passe de l'utilisateur',

Je vais en profiter pour re-basculer mon NC en mode normal :

 ./occ maintenance:mode --off

Conclusion :

Je me loggue sur mon NC avec la BD migrée pour confirmer que tout va bien. En allant faire un petit tour ici, je peux aussi vérifier que mon instance est sécurisé :

https://scan.nextcloud.com/