Nos sites sont hébergés sur un serveur dédié chez Ikoula. C'est un PIV
avec 1 Go de ram et deux disques de 80 Go IDE. Le disque hda est en
train de lâcher, donc nous effectuons une sauvegarde totale sur hdc, en
vue d'un changement de disque dur, puis install d'une Fedora Plesk toute
neuve et à jour. la question que je me pose est la suivante: une fois
sauvegardés les sites, bases de données, mail etc... et la nouvelle
install effectuée, le simple fait de restaurer les sauvegardes ne va pas
configurer par magie les services. Donc, je me dis qu'il doit y avoir
une liste finie de fichiers de conf à sauvegarder, de manière à
retrouver *exactement* la config serveur d'avant sauvegarde.
par moi-même, et au vu du temps que j'ai pour effectuer le redressement
du système, et vu d'autre part que c'est ma première expérience
d'administration serveur depuis que j'utilise Linux et que je publie des
sites webs, j'aimerais faire les choses le plus proprement possible.
On Fri, 27 Jan 2006 13:35:59 +0100 Dominique Godon wrote:
par contre, le giga de RAM du serveur est toujours occupé à 98% la plupart du temps. ceci dit, cela ne l'empêche pas d'être rapide et de délivrer un service fluide, mais quand même, j'ai du mal à accepter cette utilisation excessive de la mémoire vive.
Jette un oeil dans les archives de fcolc (via Google). C'est une FAQ et ça n'a rien d'inquiétant.
-- Jérémy JUST
On Fri, 27 Jan 2006 13:35:59 +0100
Dominique Godon <dominique.godon@tiscali.fr> wrote:
par contre, le giga de RAM du serveur est toujours occupé à 98% la
plupart du temps. ceci dit, cela ne l'empêche pas d'être rapide et de
délivrer un service fluide, mais quand même, j'ai du mal à accepter
cette utilisation excessive de la mémoire vive.
Jette un oeil dans les archives de fcolc (via Google). C'est une FAQ et
ça n'a rien d'inquiétant.
On Fri, 27 Jan 2006 13:35:59 +0100 Dominique Godon wrote:
par contre, le giga de RAM du serveur est toujours occupé à 98% la plupart du temps. ceci dit, cela ne l'empêche pas d'être rapide et de délivrer un service fluide, mais quand même, j'ai du mal à accepter cette utilisation excessive de la mémoire vive.
Jette un oeil dans les archives de fcolc (via Google). C'est une FAQ et ça n'a rien d'inquiétant.
-- Jérémy JUST
Michel Tatoute
l'indien wrote:
On Wed, 25 Jan 2006 21:16:57 +0100, Emmanuel Florac wrote:
Le Wed, 25 Jan 2006 20:22:31 +0100, a écrit :
Ce qui m'étonne un peu, c'est que l'on puisse utiliser de l'IDE pour faire un serveur ! Scsi est de loin plus fiable me semble-t-il
J'ai en main un document du CERN sur la question : après avoir testé pendant 2 ans des centaines de To de disques SCSI, FC et IDE, ils en sont arrviés à la conclusion qu'il n'y a absolument aucune différence de fiabilité entre les uns et les autres. En fait, si tu n'as pas besoin de la très haute performance des disques 15000t/mn, le SCSI est devenu absolument superfétatoire.
Sauf pour utiliser de façon des file-system journalisés, aussi. Ca (peut) aider en cas de crash...
A voir, j'ai perdu pas mal de données avec un disque dur qui perdait des blocs sur un fs journalisé... comme aucun check global n'était jamais fait le jour ou je m'en suis apperçu c'était la berezina.
Mais c'est vrai que je ne le sauvegardait pas souvent. La sauvegarde m'aurait fait prendre conscience du pb.
Le mieux est toujours le raid 5,
Michel.
l'indien wrote:
On Wed, 25 Jan 2006 21:16:57 +0100, Emmanuel Florac wrote:
Le Wed, 25 Jan 2006 20:22:31 +0100, vincent.verdon@laposte.net a écrit :
Ce qui m'étonne un peu, c'est que l'on puisse utiliser de l'IDE pour
faire un serveur ! Scsi est de loin plus fiable me semble-t-il
J'ai en main un document du CERN sur la question : après avoir testé
pendant 2 ans des centaines de To de disques SCSI, FC et IDE, ils en sont
arrviés à la conclusion qu'il n'y a absolument aucune différence de
fiabilité entre les uns et les autres. En fait, si tu n'as pas besoin de
la très haute performance des disques 15000t/mn, le SCSI est devenu
absolument superfétatoire.
Sauf pour utiliser de façon des file-system journalisés, aussi.
Ca (peut) aider en cas de crash...
A voir, j'ai perdu pas mal de données avec un disque dur qui perdait des
blocs sur un fs journalisé... comme aucun check global n'était jamais fait
le jour ou je m'en suis apperçu c'était la berezina.
Mais c'est vrai que je ne le sauvegardait pas souvent. La sauvegarde
m'aurait fait prendre conscience du pb.
On Wed, 25 Jan 2006 21:16:57 +0100, Emmanuel Florac wrote:
Le Wed, 25 Jan 2006 20:22:31 +0100, a écrit :
Ce qui m'étonne un peu, c'est que l'on puisse utiliser de l'IDE pour faire un serveur ! Scsi est de loin plus fiable me semble-t-il
J'ai en main un document du CERN sur la question : après avoir testé pendant 2 ans des centaines de To de disques SCSI, FC et IDE, ils en sont arrviés à la conclusion qu'il n'y a absolument aucune différence de fiabilité entre les uns et les autres. En fait, si tu n'as pas besoin de la très haute performance des disques 15000t/mn, le SCSI est devenu absolument superfétatoire.
Sauf pour utiliser de façon des file-system journalisés, aussi. Ca (peut) aider en cas de crash...
A voir, j'ai perdu pas mal de données avec un disque dur qui perdait des blocs sur un fs journalisé... comme aucun check global n'était jamais fait le jour ou je m'en suis apperçu c'était la berezina.
Mais c'est vrai que je ne le sauvegardait pas souvent. La sauvegarde m'aurait fait prendre conscience du pb.
Le mieux est toujours le raid 5,
Michel.
l'indien
On Sat, 28 Jan 2006 12:24:53 +0100, Michel Tatoute wrote:
l'indien wrote:
On Wed, 25 Jan 2006 21:16:57 +0100, Emmanuel Florac wrote:
Le Wed, 25 Jan 2006 20:22:31 +0100, a écrit :
Ce qui m'étonne un peu, c'est que l'on puisse utiliser de l'IDE pour faire un serveur ! Scsi est de loin plus fiable me semble-t-il
J'ai en main un document du CERN sur la question : après avoir testé pendant 2 ans des centaines de To de disques SCSI, FC et IDE, ils en sont arrviés à la conclusion qu'il n'y a absolument aucune différence de fiabilité entre les uns et les autres. En fait, si tu n'as pas besoin de la très haute performance des disques 15000t/mn, le SCSI est devenu absolument superfétatoire.
Sauf pour utiliser de façon des file-system journalisés, aussi. Ca (peut) aider en cas de crash...
A voir, j'ai perdu pas mal de données avec un disque dur qui perdait des blocs sur un fs journalisé... comme aucun check global n'était jamais fait le jour ou je m'en suis apperçu c'était la berezina.
Ca n'a pas de rapport. En IDE, on peut perdre une partie du journal lors d'un arret brutal, même si le disque n'est pas abimé. En SCSI, le système de queueing permet de gérer des priorité entre les requêtes d'écritures. On peut donc mettre une grande priorité pour tout ce qui concerne la journalisation et une priorité plus faible pour les données elle mêmes. Ainsi, on est quasi certain que le journal est toujours à jour. La possibilité existe aussi dans la norme IDE, en fait, mais je n'ai jamais vu aucun disque qui l'implémente.
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage n'est pas lui même fiable, c'est une évidence.
[...]
On Sat, 28 Jan 2006 12:24:53 +0100, Michel Tatoute wrote:
l'indien wrote:
On Wed, 25 Jan 2006 21:16:57 +0100, Emmanuel Florac wrote:
Le Wed, 25 Jan 2006 20:22:31 +0100, vincent.verdon@laposte.net a
écrit :
Ce qui m'étonne un peu, c'est que l'on puisse utiliser de l'IDE pour
faire un serveur ! Scsi est de loin plus fiable me semble-t-il
J'ai en main un document du CERN sur la question : après avoir testé
pendant 2 ans des centaines de To de disques SCSI, FC et IDE, ils en
sont arrviés à la conclusion qu'il n'y a absolument aucune
différence de fiabilité entre les uns et les autres. En fait, si tu
n'as pas besoin de la très haute performance des disques 15000t/mn, le
SCSI est devenu absolument superfétatoire.
Sauf pour utiliser de façon des file-system journalisés, aussi. Ca
(peut) aider en cas de crash...
A voir, j'ai perdu pas mal de données avec un disque dur qui perdait des
blocs sur un fs journalisé... comme aucun check global n'était jamais
fait le jour ou je m'en suis apperçu c'était la berezina.
Ca n'a pas de rapport.
En IDE, on peut perdre une partie du journal lors d'un arret brutal, même
si le disque n'est pas abimé.
En SCSI, le système de queueing permet de gérer des priorité entre les
requêtes d'écritures. On peut donc mettre une grande priorité pour tout
ce qui concerne la journalisation et une priorité plus faible pour les
données elle mêmes. Ainsi, on est quasi certain que le journal est
toujours à jour.
La possibilité existe aussi dans la norme IDE, en fait, mais je n'ai
jamais vu aucun disque qui l'implémente.
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage
n'est pas lui même fiable, c'est une évidence.
On Sat, 28 Jan 2006 12:24:53 +0100, Michel Tatoute wrote:
l'indien wrote:
On Wed, 25 Jan 2006 21:16:57 +0100, Emmanuel Florac wrote:
Le Wed, 25 Jan 2006 20:22:31 +0100, a écrit :
Ce qui m'étonne un peu, c'est que l'on puisse utiliser de l'IDE pour faire un serveur ! Scsi est de loin plus fiable me semble-t-il
J'ai en main un document du CERN sur la question : après avoir testé pendant 2 ans des centaines de To de disques SCSI, FC et IDE, ils en sont arrviés à la conclusion qu'il n'y a absolument aucune différence de fiabilité entre les uns et les autres. En fait, si tu n'as pas besoin de la très haute performance des disques 15000t/mn, le SCSI est devenu absolument superfétatoire.
Sauf pour utiliser de façon des file-system journalisés, aussi. Ca (peut) aider en cas de crash...
A voir, j'ai perdu pas mal de données avec un disque dur qui perdait des blocs sur un fs journalisé... comme aucun check global n'était jamais fait le jour ou je m'en suis apperçu c'était la berezina.
Ca n'a pas de rapport. En IDE, on peut perdre une partie du journal lors d'un arret brutal, même si le disque n'est pas abimé. En SCSI, le système de queueing permet de gérer des priorité entre les requêtes d'écritures. On peut donc mettre une grande priorité pour tout ce qui concerne la journalisation et une priorité plus faible pour les données elle mêmes. Ainsi, on est quasi certain que le journal est toujours à jour. La possibilité existe aussi dans la norme IDE, en fait, mais je n'ai jamais vu aucun disque qui l'implémente.
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage n'est pas lui même fiable, c'est une évidence.
[...]
Michel Tatoute
l'indien wrote:
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage n'est pas lui même fiable, c'est une évidence.
Ben je ne donnes pas dans le troll mais c'est tout à fait possible. Si tu utilise un systeme de stockage non fiable mais volumineux tu peux utiliser les crc pour stocker de façon fiable l'information dessus.
Michel.
l'indien wrote:
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage
n'est pas lui même fiable, c'est une évidence.
Ben je ne donnes pas dans le troll mais c'est tout à fait possible. Si tu
utilise un systeme de stockage non fiable mais volumineux tu peux utiliser
les crc pour stocker de façon fiable l'information dessus.
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage n'est pas lui même fiable, c'est une évidence.
Ben je ne donnes pas dans le troll mais c'est tout à fait possible. Si tu utilise un systeme de stockage non fiable mais volumineux tu peux utiliser les crc pour stocker de façon fiable l'information dessus.
Michel.
l'indien
On Sat, 28 Jan 2006 19:32:11 +0100, Michel Tatoute wrote:
l'indien wrote:
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage n'est pas lui même fiable, c'est une évidence.
Ben je ne donnes pas dans le troll mais c'est tout à fait possible. Si tu
utilise un systeme de stockage non fiable mais volumineux tu peux utiliser les crc pour stocker de façon fiable l'information dessus.
OK, je reprends: il est possible d'avoir un système RAID (logique ou physique) pour palier à l'éventuelle déficience d'un ou plusieurs disques. Dans ce cas, le système de stockage vu par l'utilisateur est le système RAID et pas les disques directement. Le fait de rajouter des codes correcteurs d'erreurs sur un disque permet de rendre fiable un système de stockage qui ne l'est pas à l'origine: c'est le principe utilisé sur les flash de type nand. Ce genre de mécanisme existe d'ailleurs aussi en interne sur les disques durs.
Ce que je voulais dire c'est que à partir du moment ou le système de stockage, tel qu'il est vu par l'OS, n'est pas fiable, il est illusoire de garantir une quelconque fiabilité des données. Employer des mesures pour retarder l'apparition des erreurs vues par l'OS, quelle que soit la méthode ne change pas ce constat: dès que le système de stockage est mis en défaut, il n'y a plus de solution viable concernant les données actuellement stockées: il faut repartir d'une sauvegarde. Ensuite, il est effectivement parfois possible de réutiliser le médium de stockage en "l'enrobant" dans un système corrigeant les erreurs. Avec des disques modernes, ce n'est pas conseillé: les disques contiennent déjà des systèmes de correction d'erreur et des blocs de remappage. D'après les docs IBM/Hitachi, le premier bad-bloc est visible lorsque environ 1/3 de la surface physique du disque est deffectueuse...
On Sat, 28 Jan 2006 19:32:11 +0100, Michel Tatoute wrote:
l'indien wrote:
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage
n'est pas lui même fiable, c'est une évidence.
Ben je ne donnes pas dans le troll mais c'est tout à fait possible. Si tu
utilise un systeme de stockage non fiable mais volumineux tu peux utiliser
les crc pour stocker de façon fiable l'information dessus.
OK, je reprends:
il est possible d'avoir un système RAID (logique ou physique) pour palier
à l'éventuelle déficience d'un ou plusieurs disques.
Dans ce cas, le système de stockage vu par l'utilisateur est le système
RAID et pas les disques directement.
Le fait de rajouter des codes correcteurs d'erreurs sur un disque permet
de rendre fiable un système de stockage qui ne l'est pas à l'origine:
c'est le principe utilisé sur les flash de type nand. Ce genre de
mécanisme existe d'ailleurs aussi en interne sur les disques durs.
Ce que je voulais dire c'est que à partir du moment ou le système de
stockage, tel qu'il est vu par l'OS, n'est pas fiable, il est illusoire de
garantir une quelconque fiabilité des données.
Employer des mesures pour retarder l'apparition des erreurs vues par l'OS,
quelle que soit la méthode ne change pas ce constat: dès que le système
de stockage est mis en défaut, il n'y a plus de solution viable
concernant les données actuellement stockées: il faut repartir d'une
sauvegarde.
Ensuite, il est effectivement parfois possible de réutiliser le médium
de stockage en "l'enrobant" dans un système corrigeant les erreurs.
Avec des disques modernes, ce n'est pas conseillé: les disques
contiennent déjà des systèmes de correction d'erreur et des blocs de
remappage. D'après les docs IBM/Hitachi, le premier bad-bloc est visible
lorsque environ 1/3 de la surface physique du disque est deffectueuse...
On Sat, 28 Jan 2006 19:32:11 +0100, Michel Tatoute wrote:
l'indien wrote:
Par contre, il n'y a pas de solution fiable si le mécanisme de stockage n'est pas lui même fiable, c'est une évidence.
Ben je ne donnes pas dans le troll mais c'est tout à fait possible. Si tu
utilise un systeme de stockage non fiable mais volumineux tu peux utiliser les crc pour stocker de façon fiable l'information dessus.
OK, je reprends: il est possible d'avoir un système RAID (logique ou physique) pour palier à l'éventuelle déficience d'un ou plusieurs disques. Dans ce cas, le système de stockage vu par l'utilisateur est le système RAID et pas les disques directement. Le fait de rajouter des codes correcteurs d'erreurs sur un disque permet de rendre fiable un système de stockage qui ne l'est pas à l'origine: c'est le principe utilisé sur les flash de type nand. Ce genre de mécanisme existe d'ailleurs aussi en interne sur les disques durs.
Ce que je voulais dire c'est que à partir du moment ou le système de stockage, tel qu'il est vu par l'OS, n'est pas fiable, il est illusoire de garantir une quelconque fiabilité des données. Employer des mesures pour retarder l'apparition des erreurs vues par l'OS, quelle que soit la méthode ne change pas ce constat: dès que le système de stockage est mis en défaut, il n'y a plus de solution viable concernant les données actuellement stockées: il faut repartir d'une sauvegarde. Ensuite, il est effectivement parfois possible de réutiliser le médium de stockage en "l'enrobant" dans un système corrigeant les erreurs. Avec des disques modernes, ce n'est pas conseillé: les disques contiennent déjà des systèmes de correction d'erreur et des blocs de remappage. D'après les docs IBM/Hitachi, le premier bad-bloc est visible lorsque environ 1/3 de la surface physique du disque est deffectueuse...
