Je gère bénévolement un site sur serveur Linux privé Amen à 19?ht pour 300Mo
(dédié virtuel)
Ce site est à la limite de ses possibilités : la mémoire allouée de 50Mo
pour les pics est utilisée à 95%,
mais avec seulement 150Mo utilisé en espace disque.
Il va donc falloir upgrader le pack pour obtenir 600Mo d'espace mais surtout
100Mo de mémoire allouée.
Coût : tout simplement du simple au double > 2 fois 19?ht soit 38ht mais
avec un trafic illimité.
Le trafic actuel est modeste : 10Go par mois
J'ai peut-être la possibilité d'obtenir du propriétaire un budget pour un
serveur dédié à 49?ht avec :
80Go d'espace disque et 256Mo de mémoire et 700Go de trafic par mois.
Pour vous les initiés, est-ce réellement valable ?
Y-a-t-il des spécificités particulière à gérer en plus sur un dédié par
rapport à un dédié virtuel ?
Sauvegarde ? Installation de plugin ? etc....
Amen ne précise rien au niveau de la bande passante....y-a-t-il anguille
sous roche ?
La description d'Amen précise que la gestion du spam avec Spam Assassin est
en option.
Est-ce normal ? Ne peut on pas installer cette application Freeware soi-même
sur un dédié puisqu'il est par définition dédié ?
La gestion d'un dédié réel nécessite-elle beaucoup plus de connaissances que
pour un dédié virtuel ?
Je suppose que la migration vers le dédié réel va nécessiter un changement
d'IP donc une indisponibilité de quelques jours ? (DNS)
etc...
Je suis preneur de tous les conseils que vous pourrez m'apporter !
Désolé pour toutes ces questions dans le désordre .... je ne suis pas
expert.
Merci.
"Rakotomandimby Mihamina" a écrit dans le message de news:c91r88$vmd$
Spyou wrote:
Recette pour une migration impeccable en 5 minute sans pertes : ^^^^^^^^
-> quelques jours avant la migration, baisser le TTL des zones DNS a 1 ^^^^^^^^^^^^^^^^^^^^
Ca fait largemenr plud de 5mn ça .
??
Baisser le TTL n'a jamais rendu un site indisponible :)
Spyou
"Patrick" <patrick+ a écrit dans le message de news:
Recette pour une migration impeccable en 5 minute sans pertes :
-> quelques jours avant la migration, baisser le TTL des zones DNS a 1 minute. Les sites seront un peu ralenti mais pas méchant (eventuellement baisser le TTL a 2h, puis 8h avant la migration le baisser a 1h, puis 2h avant la migration le baisser a 1 minute si il y'a beaucoup de requettes DNS en fonctionnement normal)
Ca ne suffit pas, il faut baisser le Refresh (ou controler complétement les secondaires)
Possible .. J'ai jamais <pas eu> le controle sur mes secondaires :))
Mieux vaut copier avant le maximum, et ne faire qu'un dernier rsync pour récupérer les dernières modifications.
Right
Plus simple: faire router les mails arrivés sur le secondaire directement (en dur) vers le nouveau primaire.
sendmail -q ... Et basta
"Patrick" <patrick+news@deepcore.org> a écrit dans le message de
news:pan.2004.05.26.14.33.05.856137.19603@deepcore.org...
Recette pour une migration impeccable en 5 minute sans pertes :
-> quelques jours avant la migration, baisser le TTL des zones DNS a 1
minute. Les sites seront un peu ralenti mais pas méchant (eventuellement
baisser le TTL a 2h, puis 8h avant la migration le baisser a 1h, puis 2h
avant la migration le baisser a 1 minute si il y'a beaucoup de requettes
DNS en fonctionnement normal)
Ca ne suffit pas, il faut baisser le Refresh (ou controler complétement
les secondaires)
Possible .. J'ai jamais <pas eu> le controle sur mes secondaires :))
Mieux vaut copier avant le maximum, et ne faire qu'un dernier rsync pour
récupérer les dernières modifications.
Right
Plus simple: faire router les mails arrivés sur le secondaire directement
(en dur) vers le nouveau primaire.
"Patrick" <patrick+ a écrit dans le message de news:
Recette pour une migration impeccable en 5 minute sans pertes :
-> quelques jours avant la migration, baisser le TTL des zones DNS a 1 minute. Les sites seront un peu ralenti mais pas méchant (eventuellement baisser le TTL a 2h, puis 8h avant la migration le baisser a 1h, puis 2h avant la migration le baisser a 1 minute si il y'a beaucoup de requettes DNS en fonctionnement normal)
Ca ne suffit pas, il faut baisser le Refresh (ou controler complétement les secondaires)
Possible .. J'ai jamais <pas eu> le controle sur mes secondaires :))
Mieux vaut copier avant le maximum, et ne faire qu'un dernier rsync pour récupérer les dernières modifications.
Right
Plus simple: faire router les mails arrivés sur le secondaire directement (en dur) vers le nouveau primaire.
sendmail -q ... Et basta
Davel_x
Spyou ecrivait :
"Rakotomandimby Mihamina" a écrit dans le message de news:c91r88$vmd$
Spyou wrote:
Recette pour une migration impeccable en 5 minute sans pertes :
^^^^^^^^
-> quelques jours avant la migration, baisser le TTL des zones DNS a 1
^^^^^^^^^^^^^^^^^^^^
Ca fait largemenr plud de 5mn ça .
??
Baisser le TTL n'a jamais rendu un site indisponible :)
Non mais s'il faut s'y prendre déjà 24h heures à l'avance c'est que ça ne dure pas que 5 minutes ^_^ C'est en fait le risque de temps déconnexion du site qui dure 5 minutes non ? et encore...
-- **davel** http://www.lerpg.com
Spyou ecrivait :
"Rakotomandimby Mihamina" <rktmb.tontolo@wanadoo.fr> a écrit dans le message
de news:c91r88$vmd$1@news-reader2.wanadoo.fr...
Spyou wrote:
Recette pour une migration impeccable en 5 minute sans pertes :
^^^^^^^^
-> quelques jours avant la migration, baisser le TTL des zones DNS a 1
^^^^^^^^^^^^^^^^^^^^
Ca fait largemenr plud de 5mn ça .
??
Baisser le TTL n'a jamais rendu un site indisponible :)
Non mais s'il faut s'y prendre déjà 24h heures à l'avance c'est que ça
ne dure pas que 5 minutes ^_^ C'est en fait le risque de temps
déconnexion du site qui dure 5 minutes non ? et encore...
"Rakotomandimby Mihamina" a écrit dans le message de news:c91r88$vmd$
Spyou wrote:
Recette pour une migration impeccable en 5 minute sans pertes :
^^^^^^^^
-> quelques jours avant la migration, baisser le TTL des zones DNS a 1
^^^^^^^^^^^^^^^^^^^^
Ca fait largemenr plud de 5mn ça .
??
Baisser le TTL n'a jamais rendu un site indisponible :)
Non mais s'il faut s'y prendre déjà 24h heures à l'avance c'est que ça ne dure pas que 5 minutes ^_^ C'est en fait le risque de temps déconnexion du site qui dure 5 minutes non ? et encore...
-- **davel** http://www.lerpg.com
Tropicaloo
Si il prend une Debian/Linux, sur un dedié, je veux bien m'y coller (serieusement).
Idem. Je veux bien filer un coup de pouce pour l'administration.
Vous êtes super !!! Je vous donnerai du nouveau d'ici quelques jours dès que le nouveau budget sera décidé.
Si il prend une Debian/Linux, sur un dedié, je veux bien m'y coller
(serieusement).
Idem. Je veux bien filer un coup de pouce pour l'administration.
Vous êtes super !!! Je vous donnerai du nouveau d'ici quelques jours dès que
le nouveau budget sera décidé.
Si il prend une Debian/Linux, sur un dedié, je veux bien m'y coller (serieusement).
Idem. Je veux bien filer un coup de pouce pour l'administration.
Vous êtes super !!! Je vous donnerai du nouveau d'ici quelques jours dès que le nouveau budget sera décidé.
Patrick
Ca ne suffit pas, il faut baisser le Refresh (ou controler complétement les secondaires)
Possible .. J'ai jamais <pas eu> le controle sur mes secondaires :))
Raison de plus donc pour baisser le refresh (avant de baisser le TTL) afin que les secondaires récupérent plus rapidement les mises à jour (le DNS UPDATE devrait aider aussi, mais c'est optionnel comme support).
Plus simple: faire router les mails arrivés sur le secondaire directement (en dur) vers le nouveau primaire.
sendmail -q ... Et basta
Pour la migration d'un MX, je préfére avoir un secondaire que je configure pour router directement vers le primaire. Ca accélére les choses car le secondaire n'est ainsi plus tributaire des changements DNS. Le nouveau MX peut ainsi déjà fonctionner en parallèle de l'ancien, et donc il n'y a même plus d'interruption du tout pour les utilisateurs.
Patrick.
Ca ne suffit pas, il faut baisser le Refresh (ou controler complétement
les secondaires)
Possible .. J'ai jamais <pas eu> le controle sur mes secondaires :))
Raison de plus donc pour baisser le refresh (avant de baisser le TTL)
afin que les secondaires récupérent plus rapidement les mises à jour (le
DNS UPDATE devrait aider aussi, mais c'est optionnel comme support).
Plus simple: faire router les mails arrivés sur le secondaire
directement (en dur) vers le nouveau primaire.
sendmail -q ... Et basta
Pour la migration d'un MX, je préfére avoir un secondaire que je
configure pour router directement vers le primaire. Ca accélére les
choses car le secondaire n'est ainsi plus tributaire des changements DNS.
Le nouveau MX peut ainsi déjà fonctionner en parallèle de l'ancien, et
donc il n'y a même plus d'interruption du tout pour les utilisateurs.
Ca ne suffit pas, il faut baisser le Refresh (ou controler complétement les secondaires)
Possible .. J'ai jamais <pas eu> le controle sur mes secondaires :))
Raison de plus donc pour baisser le refresh (avant de baisser le TTL) afin que les secondaires récupérent plus rapidement les mises à jour (le DNS UPDATE devrait aider aussi, mais c'est optionnel comme support).
Plus simple: faire router les mails arrivés sur le secondaire directement (en dur) vers le nouveau primaire.
sendmail -q ... Et basta
Pour la migration d'un MX, je préfére avoir un secondaire que je configure pour router directement vers le primaire. Ca accélére les choses car le secondaire n'est ainsi plus tributaire des changements DNS. Le nouveau MX peut ainsi déjà fonctionner en parallèle de l'ancien, et donc il n'y a même plus d'interruption du tout pour les utilisateurs.
Patrick.
Tropicaloo
Merci à tous pour votre aide Je suis en attente pour le moment, on attend les sous !
Merci à tous pour votre aide
Je suis en attente pour le moment, on attend les sous !
Merci à tous pour votre aide Je suis en attente pour le moment, on attend les sous !
Spyou
"Davel_x" a écrit dans le message de news:40b52039$0$15218$
Non mais s'il faut s'y prendre déjà 24h heures à l'avance c'est que ça ne dure pas que 5 minutes ^_^ C'est en fait le risque de temps déconnexion du site qui dure 5 minutes non ? et encore...
Il faut s'y prendre a l'avance .. mais le temps de travail effectif ne depasse pas les 5mn et l'interuption non plus (sauf si le site est tres gros)
"Davel_x" <davel@noospam.fr> a écrit dans le message de
news:40b52039$0$15218$626a14ce@news.free.fr...
Non mais s'il faut s'y prendre déjà 24h heures à l'avance c'est que ça
ne dure pas que 5 minutes ^_^ C'est en fait le risque de temps
déconnexion du site qui dure 5 minutes non ? et encore...
Il faut s'y prendre a l'avance .. mais le temps de travail effectif ne
depasse pas les 5mn et l'interuption non plus (sauf si le site est tres
gros)
"Davel_x" a écrit dans le message de news:40b52039$0$15218$
Non mais s'il faut s'y prendre déjà 24h heures à l'avance c'est que ça ne dure pas que 5 minutes ^_^ C'est en fait le risque de temps déconnexion du site qui dure 5 minutes non ? et encore...
Il faut s'y prendre a l'avance .. mais le temps de travail effectif ne depasse pas les 5mn et l'interuption non plus (sauf si le site est tres gros)
