Retour d'expérience migration de serveur

Salut à tous,

Juste un petit message qui servira peut-être à ceux qui souhaiteraient migrer leur serveur vers une nouvelle machine (qu’elle soit physique ou virtuelle).
Pour ma part, je suis passé d’un raspberry pi 3B vers une VM sous proxmox, mais les étapes de migration que j’ai suivi seront les mêmes pour une migration vers une machine physique.

Voici tout simplement comment j’ai procédé:

sur le raspberry pi, j’ai lancé une sauvegarde yunohost complète depuis l’interface web (systèmes + applications (je n’avais que nextcloud) et les données associées (320 Go).

sur le nouveau serveur, j’ai installé debian, puis yunohost, mais au lieu de faire la postinstall, j’ai tout simplement importé ma sauvegarde yunohost et l’ai restauré (comme expliqué dans la documentation).

resultat des courses: tout s’est parfaitement déroulé sans que j’ai eu quoi que ce soit à retoucher. Ce qui démontre que malgré ses quelques limitations, le système de sauvegarde/restauration intégré de yunohost est quand même vachement puissant.

La méthode utilisée n’est peut-être pas la plus rapide: 40 heures au total pour la migration (30 heures pour générer la sauvegarde et 10 heures pour la restaurer) mais elle a le mérite d’être simple, et surtout diablement efficace!

Si vous souhaitez que je détaille + la méthode et les étapes de réalisation, n’hésitez pas à me demander.

Merci encore à toute l’équipe pour ce superbe travail.
A ce propos, je souhaiterai, si vous êtes intéressés, vous expédier mon rpi si vous voulez vous en servir pour des tests/intégrations.

5 Likes

Bonjour,

J’ai fais la même migration que toi, c’est à dire passé d’un RPI3B+ à une VM proxmox. Tout c’est bien passé mais j’ai eu quelques soucis avec les certificats au renouvellement de ceux-ci. Rien de bien méchant, cependant c’est éventuellement à surveiller et voir si ta restauration passe cette étape. Le script de renouvellement automatique des certificats LE n’était plus présent non plus.
Est-ce une adresse yunohost en noho.st ou similaire que tu utilises? Et as-tu été obligé de la réinitialiser?

J’apporterais comme conseil de faire une sauvegarde de /etc en plus, ça permet de réparer ces petits désagréments lors de la migration en récupérant ce qu’il faut. Après je suis passé d’une 3.8 sur le raspberry directement à Yunohost 4 sur la VM et la sauvegarde était issu d’une sauvegarde Borg.

salut @metyun
je n’ai eu aucun problème avec les certificats (ni avec quoi que ce soit d’autre d’ailleurs… je n’ai même pas eu à effectuer un petit chmod ou chown par ci par là… ). Par contre, je n’étais pas en domaine noho.st ou similaire, mais sur un “vrai” domaine.
Je n’ai pas eu besoin de faire de sauvegarde supplémentaire de /etc ou autre. Mais contrairement à toi, je n’ai pas utilisé borg pour la sauvegarde et j’étais déjà en yunohost V4.0.8 sur le rpi avant la migration.

En tout cas c’est clair que pour dkim il manque quelques choses dans les sauvegardes.

Ce n’est pas un soucis avec borg, là c’est la sauvegarde ynh qui pose soucis.

J’ai commencé une PR pour corriger ça: [fix] Backup/restore dkim keys by zamentur · Pull Request #1098 · YunoHost/yunohost · GitHub

1 Like

Merci pour l’info.
J’ai regardé le contenu de /etc/dkim et j’ai bien le fichier .txt et .key correspondant au domaine, pourtant je ne crois pas avoir copié quoi que ce soit concernant ce dossier. est-ce normal vu ta remarque?
Sur mail-tester, j’ai ceci:

-0.01		T_DKIM_INVALID		Your DKIM signature is not valid
Jetez un oeil à nos contrôles DKIM ci-dessous pour savoir pourquoi, ce résultat peut-être un faux positif

Est-ce en rapport?

Les clé dkim sont régénérées, mais du coup il faut changer la config DNS, sinon le diagnostique rale. Ma PR sert à éviter de devoir changer les entrées dkim du dns lorsque l’on restore.

Après ça dépend aussi si on restaure sur le même serveur ou sur un tout neuf (le problème arrive dans le second cas).

Potentiellement, oui. Après dans mail tester, il peux mettre un message qui ressemble à ça aussi à cause du reverse DNS…, tout dépend dans quel catégorie tu es.

Sinon tu peux utiliser le module “DKIM verifier” de Thunderbird (et en plus tu pourras voir qui utilises dkim ou pas).

1 Like

Et concrètement il faut faire quoi? J’ai toujours la sauvegarde de /etc/dkim de mon ancien serveur. La copier à la place de l’actuelle? Ou sinon comment changer les entrées dkim du dns avec une adresse fournie par Yunohost?

Sinon je ne me suis aperçu de rien, je n’ai pas de soucis de mails ni pour l’envoi ni pour la réception mais mieux vaut corriger ce qui peut l’être avant d’avoir un rejet éventuel.
Pour le reverse, effectivement je n’en ai pas ou plutôt ça ne renvoie pas le bon domaine. Et oui, il s’agit d’une réinstallation sur un serveur différent.

@ljf: Bon, je viens d’essayer yunohost dyndns update --force mais ça n’a rien changé au résultat de mail-tester.

c’est ça et configurer les droits comme ça:
-r-------- 1 _rspamd root 887 Nov 17 02:27 DOMAIN.mail.key
-rw------- 1 root root 321 Nov 17 02:27 DOMAIN.mail.txt

Tu peux voir les opérations décrites ici:

C’est bien que t’ai posé la question, car j’ai failli oublier de reconfigurer les droits dans la PR…

La mise à jour des DNS aurait dû fonctionner aussi en mettant la configuration dkim à jour si je comprends bien tes explications.
Je verrai ça demain. Merci pour les infos et de m’avoir fait découvrir DKIM verifier.

Tout à fait, c’est soit l’un soit l’autre. Et d’ailleurs, si tu as un nom de domaine en noho.st, nost.me ou ynh.fr il est possible qu’elle ai été faite automatiquement. Ce qui me fait me rappeler qu’il y a là aussi un soucis, car les clés de signature pour la mise à jour des noms de domaines ne sont pas sauvegardées !

Du coup j’ai fait une PR pour ça aussi: [fix] Add Dyndns domains keys to backup by zamentur · Pull Request #1101 · YunoHost/yunohost · GitHub

1 Like

C’est vrai. J’ai du en effet mettre à jour mes enregistrements dans concernant dkim avec les nouvelles infos fournies par l’outil de diagnostic de yunohost

C’est exactement ça, j’ai une adresse Yunohost, je n’ai pas eu besoin de demander de réinitialiser le domaine en restaurant /etc/yunohost/dyndns.