@jose as-tu eu des retours sur la seconde proposition ?
De mon côté, je travaille toujours sur mon propre serveur yunohost, je n'ai pas beaucoup avancé, mais j'espère pouvoir à terme remplacer mon raspberry pi (moins puissant) équipé de nextcloupdpi, par mon NAS avec yunoshost virtualisé. Du coup je peux également orienter ma réflexion sur l'infrastructure possible du serveur de Tricassinux.
Je me pose aussi la question de savoir si c'est mieux en virtualisé ou pas, d'un côté c'est plus pratique pour restaurer une image ou une sauvegarde si un imprévu s'est passé (juste un fichier à remettre en place, pour l'avoir expérimenté plusieurs fois, c'est pratique, rapide, et confortable), de l'autre c'est moins souple pour les sauvegardes (il faut sauvegarder l'image complète pour bien faire).
Et puis comme Yunohost permet de restaurer plutôt aisément une sauvegarde, est-ce bien nécessaire ? Il faut juste être prêt à pouvoir remonter rapidement un serveur yunohost au cas où...
Quelques pistes supplémentaires :
(EDIT) Je continue mes recherches au niveau de l'optimisation du serveur actuel. Et là je viens de découvrir avec horreur que yunohost repose sur l'utilisation de "composer", qui est une sorte de gestionnaire de dépendances php. Et le soucis, c'est que pour chaque module installé, cela créé une nouvelle instance de composer, avec toutes les dépendances dedans, et un cache énorme. En moyenne, c'est 300 ou 400 Mo de cache, et je comprends mieux pouquoi avec un site pas très gros, un forum pas très rempli et presque pas de données utilisateur, on se retrouve avec 2 Go de sauvegarde ! Tout passe dans composeur et son cache gargantuesque !
Pour trouver les plus gros fichiers, je tape la commande : du --all -h --max-depth=2|sort -n
et je trouve des merveilles dans ce genre :
309M /home/admin/.composer
356M /home/flarum/.composer
308M /root/.composer
Peut-être que le cache n'est pas obligatoirement toujours régénéré, je vais faire un peu de ménage...
