Hello,
J’installe un service avec Yunohost pour une association GUL(groupement d’utilisateurs linux) avec le but de devenir un CHATON.
J’ai commencé à installer un serveur sur un Public Cloud, une offre S1-4 (1v core, 4Go de ram) et déplacé des partitions sur des Volumes Disques.
Ma question est, si je voulais déplacer le serveur sur un VPS, qui me semble plus abordable pour plus de capacités, comment procéder ? Pensez-vous que c’est réalisable ?
J’ai une instance Public Cloud S-1-4 avec des 4 Volumes disques externes attachés qui me permettent d’alloués de l’espace disque à certaines partitions du serveur Yunohost en place. /var/mail pour les mails, /home pour les données (entre autre celle de certaines apps), /var/www/cryptpad pour une application Cryptpad et /var/www/opensondage pour une application opensondage.
Je voulais savoir si techniquement il m’est possible de basculer à une offre VPS Essential et d’y attacher de la même façon les volumes externes.
Quelle serait la procédure ?
Est-ce que je peux simplement arrêter le serveur en coupant nginx,
faire un snapshot du Public Cloud,
restaurer le snapshot sur le VPS (je ne suis pas sûr que ce soit possible),
détacher les Volumes disques de l’instance Public Cloud et les attacher au VPS ?
configurer bien les montages des disques et le fstab,
éditer le reverse DNS du nom de domaine (pour ipv4 et ipv6)
Cela fonctionnerait-il ?
ou dois-je:
Installer mon serveur Yunohost sur le vps (quitte à l’installer avec provisoirement un autre nom de domaine) le configurer, rapatrier les données avec un backup de Yunohost ou un rsync, démonter et remonter les Volumes externes ???
Je ne sais pas si ce qui est réalisable ou pas, je pose la question sur les forums d’ovh aussi…
Sinon, je reste dans les Public Cloud, mais c’est un peu plus cher économiquement…
Une autre possibilité est de rester dans le Public Cloud et de passer à une offre S-2-8 (2v core 8Go de ram). J’ai un doute sur le fait que ces offres sont des sandbox, plutôt adaptées à des environnements de tests, développement, peut-être est-ce plus judicieux d’être sur un vps ??
Je ne sais pas si les disques peuvent changer complètement d’offres chez OVH, pour les snapshot, j’ai peine à croire que tu puisses le faire.
T’as combien de Go à migrer ? Quelle est la capacité du serveur de destination ?
De ce que tu décris la méthode de clonage de serveur avec rsync peut-être bien (en faisant attention de le faire à froid (services voir serveurs éteint).
Sinon utiliser l’outil de restauration de yunohost avec les.tar à restaurer, app par app si tu as beaucoup de données et potentiellement avec l’option BACKUP_CORE_ONLY. Tu peux d’ailleurs avoir une stratégioe mixte (utilisant rsync et l’outil de restauration de yunohost).
Bon finalement après tergiversation je suis rester sur le Public Cloud, surtout en comprenant qu’il y a moins de souplesse sur les VPS pour ajouter des volumes. Et les snapshots ne sont pas transposables.
Bonjour, comme le post est toujours ouvert, je me permet de rajouter où j’en suis. J’ai finalement migrer mon serveur vers un serveur dédié Kimsufi il y a un petit moment, c’était moins onéreux comme solution.
Par contre la difficulté que j’ai rencontré et anticipé, c’est de remettre les dossiers déplacés sur des partitions sans lien symbolique, mais avec des liens dans le /etc/fstab risquent de ne pas fonctionner avec une restauration.
J’ai eu récemment un soucis de ce genre avec une restauration de Nextcloud où j’avais déplacé les données sur un volume externe et spécifié l’URL de ce dossier dans le fichier /var/www/nextcloud/config/config.php. Finalement, il me semble plus judicieux de faire un lien symbolique du dossier /home/yunohost.app/nextcloud/data vers un dossier sur un autre volume.
Je me soucie de comment ne plus avoir ce genre de soucis. Par exemple, j’ai déplacé une application Cryptpad en éditant le fichier /etc/fstab avec un volume monté sur /var/www/cryptpad, mais en cas de suppression et restauration, ça va casser. Il vaudrait mieux que ce soit un lien symbolique, il me semble. Est-ce que vous confirmez ?
Pareil pour les mails, déplacés sur un volume en passant aussi par le fichier /etc/fstab monté sur /var/mail, un lien symbolique serait plus adapté en cas de besoin de restauration, non ??
J’aimerais en être sûr, pour anticiper et garder un service un peu plus pérenne…