Dans ce cas, ce que je ferais :
- une machine physique (pourquoi pas une machine de récup ?) sur laquelle je mettrai mes deux disques de sauvegarde (voire un NAS dédié, mais c'est plus cher)
- une machine physique sur laquelle je mettrais 3 VMs (ou plus) :
* serveur de dev
* serveur de test (1 config VM par fonctionnalité que tu veux tester)
* multimedia.
En séparant la machine de sauvegarde de l'autre, tu te prémunis des erreurs de manpulation, ou de la perte de toute la machine. En effet, au pire des cas si tu perds ton serveur de sauvegarde, tu disposes encore de tes données sur les autres machines (tu perds par contre l'historique si tu fais des incrémentales). Et si tu perds la machine contenant les environnements de dev et de test, tu peux toujours récupérer tes sauvegardes.
Les serveurs de dev et de test n'ont pas forcément besoin d'une grosse config, ni d'interface graphique, si ce n'est que pour faire tourner Apache. Donc tu n'es pas obligé de mettre beaucoup de CPU ni de RAM. Et le(s) serveur(s) de test ne sont pas forcément obligés de tourner en mêm temps (c'est ce que je fais chez moi : 1 VM Host avec plusieurs configs e VM, que je ne fais pas tourner en même temps, je ne les lances que lorsque j'ai quelque chose à tester).
En y réfléchissant un peu, avec Docker ou un environnement de virtualisation, tu peux très bien garder le multimedia sur le système hôte, avec ton IDE pour développer ton code source (que tu envoies ensuite vers ton env de dev Apache par exemple), et lancer des VM, ou des containers Doker sur lesquels tourneraient tes environnements de test et de dev Apache
[^] # Re: Un servuer, compartimenté avec VM, docker ou autre : avantages et inconvénients.
Posté par totof2000 . En réponse au message Quel serveur? solution?. Évalué à 2.
Dans ce cas, ce que je ferais :
- une machine physique (pourquoi pas une machine de récup ?) sur laquelle je mettrai mes deux disques de sauvegarde (voire un NAS dédié, mais c'est plus cher)
- une machine physique sur laquelle je mettrais 3 VMs (ou plus) :
* serveur de dev
* serveur de test (1 config VM par fonctionnalité que tu veux tester)
* multimedia.
En séparant la machine de sauvegarde de l'autre, tu te prémunis des erreurs de manpulation, ou de la perte de toute la machine. En effet, au pire des cas si tu perds ton serveur de sauvegarde, tu disposes encore de tes données sur les autres machines (tu perds par contre l'historique si tu fais des incrémentales). Et si tu perds la machine contenant les environnements de dev et de test, tu peux toujours récupérer tes sauvegardes.
Les serveurs de dev et de test n'ont pas forcément besoin d'une grosse config, ni d'interface graphique, si ce n'est que pour faire tourner Apache. Donc tu n'es pas obligé de mettre beaucoup de CPU ni de RAM. Et le(s) serveur(s) de test ne sont pas forcément obligés de tourner en mêm temps (c'est ce que je fais chez moi : 1 VM Host avec plusieurs configs e VM, que je ne fais pas tourner en même temps, je ne les lances que lorsque j'ai quelque chose à tester).
En y réfléchissant un peu, avec Docker ou un environnement de virtualisation, tu peux très bien garder le multimedia sur le système hôte, avec ton IDE pour développer ton code source (que tu envoies ensuite vers ton env de dev Apache par exemple), et lancer des VM, ou des containers Doker sur lesquels tourneraient tes environnements de test et de dev Apache