Par contre, ça te protège contre une panne de disque dur, qui est un risque beaucoup plus élevé qu'un rm -rf, notamment à cause du fait qu'elle est indépendante des précautions que pourrait prendre l'utilisateur.
Des "utilisateurs", j'en connais plein qui ont perdu des données suite à des erreurs de manip. Certes, pas forcément à cause du "rm -fr" (qui est peu fréquent). Ca peut être le formattage d'un disque dur au lieu d'une clé USB ou d'un disque externe, restauration système fournie par le constructeur qui écrase tout, un virus, malware, ou plein d'atres raisons.
L'intérêt de faire une « copie de sauvegarde » est quand même en premier lieu de protéger contre une défaillance du médium concerné.
Non. La "copie de sauvegarde" te sert à récupérer tes données à un instant T, sans se poser de question sur la raison pour laquelle elle a disparu.
et pour cela, il n'y a rien de mieux que le RAID à mon avis.
Oui, si tu ne te veux te prémunir uniquement de la perte d'un disque. Celà dit comme tu le disais plus haut, tu n'es pas à l'abri de la perte de tous tes disques (incendie, orage, etc ….). Mais le seul moyen efficace de pouvoir récupérer ses données à un instant T, c'est la sauvegarde.
Sinon, l'intéret est de savoir pourquoi on garde ces données, et à quelle fréquence elles bougent.
Ça, c'est prendre le problème à l'envers. Ça peut avoir du sens dans certains cas, mais ce n'est pas ce qui nous occupe ici.
Bien sur que si ça a du sens … Comme justement. Toutes les données n'ont pas la même criticité. Comme on a de plus en plus de choses sur nos machines, c'est difficile de tout sauvegarder. Il faut faire des choix et un tri pour pouvoir s'en sorti sans que ça ne coute trop cher.
Par exemple, entre autres choses, j'ai 37 gigas de photographies de la naissance de mes nièces. Il est évident qu'elles sont immuables et que je ne veux pas les perdre non plus. Il n'empêche que je ne vais pas graver une dizaine de DVD pour celles-là en plus du reste. À partir du moment où j'ai une grosse quantité de données à conserver, il n'y a guère que les disques durs pour le faire efficacement.
Dans ce cas ce n'est pas de la sauvegarde que tu fais mais de l'archivage, et tu ne le gère pas du tout de la même façon.
Pour le feu et l'inondation, ça n'a de sens que si tu mets tes sauvegardes à l'abri. Et il est de fait qu'en général, ces sauvegardes se retrouvent bien rangés sur l'étagère à côté du PC, ce qui revient donc exactement au même
Dans ce cas, c'est que tu ne t'es pas posé la question de savoir pourquoi tu gardes ces données. Si tu sais pourquoi tu gardes tes données et combien de temps, tu décideras ensuite de l'endroit ou tu les rangeras.
On pourrait à la limite envisager un hypothétique bug du noyau qui irait corrompre directement toute ta partition mais, là encore, c'est quand même extrêmement peu probable.
Comme je l'ai dit plus haut, l'utilisateur est moins fiable que le hardware ou le noyau. Mais sinon il me semble qu'à une époque il y avait un méchant bug sur XFS qui te corrompait méchamment la table d'inodes. Le truc c'est que ton FS pouvait sembler continuer à bien fonctionner mais dans les faits, tu ne t'en rendais compte que lorsque tu redémarrais ta machine, ou lorsque tu essayais de relire tes données.
Il en reste que ces quatre risques sont très peu probables et en principe, ne doivent pas arriver. Un disque dur défaillant, en revanche, c'est arrivé à toute personne ayant utilisé un ordinateur suffisamment longtemps. Et quand le disque en question commence à présenter des signes de faiblesse, c'est en général trop tard pour faire une copie. Cependant, c'est une panne qui reste peu fréquente (heureusement), si bien que lorsqu'elle se produit, on a en général perdu l'habitude de faire ses sauvegardes régulières.
Si tu fais des sauvegardes rgulières, pas de problème. Tu n'auras qu'à copier que le delta ar rapport à ta dernière sauvegarde avant de changer le disque. Et un risque peu probable n'est pas un risque inexistant : le jour ou ça arrive, et que tu n'a pas pris de précautions, tu pleures.
Naturellement, je finis quand même par archiver mes données les plus critiques comme mon répertoire de documents administratifs et la boîte mail de mon client courrier (je n'utilise pas le webmail). Mais du coup, je le fais à intervalles beaucoup plus larges, par exemple quand je change de distribution et, surtout, ça me laisse le temps de faire un tri efficace dans ce que j'ai à sauvegarder ou à abandonner. J'ai 110 Go dans mon /home actuellement, c'est long à auditer.
Tu fais comme tu veux. Mais si tu perds ta machine en raison d'une surtension (orage ou mauvaise manip sur le réseau électrique), tu risque de perdre beaucoup.
Pour ma part je n'archive que ce que je ne pourrai pas retrouver : photos, documents administratifs et documents que j'ai produit, sur disque externe. Au final, ça ne représente pas tant de données que ça. Par contre je reconnais que si on fait de la vidéo, ça peut vite monter.
Je ne suis pas encore passé à ce stade, mais j'envisage de me procurer des disques durs externes et de les confier à une personne de confiance pour la sauvegarde/archivage, en établissant un roulement. A mon avis pour être efficace, il faudrait 3 disques au moins (mêm 4 si je garde un exemplaire chez moi) avec un truc de ce genre.Il faut que j'y réfléchisse sérieusement.
Il faut bien préciser ou tu veux mettre la haute dispo et la répartition de charge. De plus tu aurais du te poser cette question lors du choix du SGBD, car il y a des choses qui peuvent être faites à son niveau.
Niveau haute disponibilité, que voudrais-tu exactement ?
1/ veux-tu un cluster de serveurs de base de données qui accèderaient à tes LUNs simultanément ? A ma connaissance, seul Oracle RAC permet de le faire (il y en a peut-être d'autres mais je ne les connais pas - si qqn a des infos à ce sujet, je suis preneur).
2/ Ou alors voudrais-tu deux serveurs ou baies qui mettraient à dispo la volumétrie via iSCSI en permettant une écriture synchrone sur les deux serveurs (une sorte de raid1 entre les LUNs ?). Dans ce cas, c'est simple : deux machines exportant leur volumétrie : tu crées des LUNs identiques sur chaque machine, et ensuite tu fais un RAID1 LVM (ou autre) pour avoir la haute dispo au niveau des données. Par contre, pas de répartition de charge : les données sont écrites simultanément sur tes 2 UNS. Côté perfs, ça doit pas être génial …
3/ tu pourrais simuler un actif/actif avec répartition de charge "manuelle" en utilisant deux machines qui aurait chacune une partie des données en actif, et qui répliqueraient celles-ci sur l'autre en mode passif, avec un cluster style heartbeat pour gérer la haute dispo.
Sinon, si tu veux des idées, va Va voir ce slide. Je cherche la vidéo associée, mais je ne la trouve pas. Mais dans le slide tu trouveras quelques infos (qui pourront te servir de base de recherche) pour faire du mariadb distribué.
Je conseillerais quand même de tenter d'ajouter de la RAM : même si Linux tourne sur ce genre de machine avec un gestionnaire de bureau léger, il risque de manquer de mémoire pour faire tourner les applis. Avoir un OS qui tourne c'est bien, mais ce n'est pas une fin en soi :)
Oui, mais l'intérêt du RAID 5 chez un particulier, c'est quand même de limiter le besoin de sauvegarde à tout bout de champ.
JAMAIS, NON JAMAIS !!!!!
Le RAID quel qu'il soit n'est là QUE pour la disponibilité. Ceux qui s'en servent pour autre chose sont simplement fous ou inconscients.
Un RAID quelq qu'il soit ne te préservera jamais d'un rm au mauvais endroit, ou de l'écrasement d'un fichier par un autre par erreur.
Évidemment, ça ne protège pas du feu, ni du vol, ni surtout de la corruption de données. Il en reste que même en faisant du tri, j'ai encore 100 Go de données dans mon /home. Sur quoi je puis sauvegarder cela autrement que sur un autre disque dur, en combien de temps, et surtout à quelle fréquence ? Si c'est tous les six mois, je perds mes données récentes, qui peuvent être les plus importantes.
D'ou l'intérêt de faire de l'incrémental. Sinon, l'intéret est de savoir pourquoi on garde ces données, et à quelle fréquence elles bougent.
Pour info, Linux n'est pas magique (et Windows non plus). Si le périphérique n'est pas reconnu au BIOS, Linux n'y peut rien, et ne le reconnaîtra pasd plus.
C'est quoi cette manie de toujours dénigrer les outils qui font bien leur taf ?
Telnet est très pratique pour faire des tests rapides d'ouverture de ports. C'est comme si tu demandais à quoi peut servir une pelle en 2013 alors qu'il existe des pelleteuses.
On va se concentrer sur les périphériues IDE, et vérifier que es ralentissements lui sont bien liés:
Quels périphériques as-tu et combien ? Es-tu allé voir le lien que je t'ai mis plus haut pour les cavaliers ?
Pour s'assurer que les ralentissements sont bien liés aux périphériques IDE, peux-tu essayer, si ce n'est déjà fait, un redémarrage en débrnchant toutes les nappes IDE et dire si c'est toujours aussi lent ? Si c'est le cas, je crains pour la carte mère.
Sinon, à te lire, je suis presque convaincu qu'il s'agit d'un problèmede positionnement de cavaliers sur les disques durs ou lecteurs DVD.
Un peu de patience et de méthode, et , on va y arriver ;)
Si je met internal sata sur disabled la quatrieme ligne (raid option rom disparait de l'écran) et si , en laissant ce choix je retourne sur le main menu du bios, mes primary ide master esclaves et maitres et secondary ide master esclave et maitres sont toujours no detected…
Refais la manip, redémarre la machine, reviens sur le BIOS pour voir si les périphériques sont détectés.
Normal que tu ne retrouves pas ton disque dur (qui est SATA si j'ai bien suivi) parce que tu as désactivé les controleurs. Et à ce stade, vois-tu les périphériques ATA dans le BIOS ?
Si tu ne les vois toujours pas, ça sent mauvais pour le controleur IDE ….
Je te propose un nouveau test: essaie de le faire en désactivant les controleurs SATA pour éviter toute interférence. Le but : essayer chaque périphérique IDE de façon indépendante en mode "Master"
A :
A1/ Débrancher les deux périphériques IDE.
A2/ Prendre un des deux périphériques IDE, positionner le cavalier sur "MASTER"
A3/ Brancher ce périphérique en bout de naoppe.
A4/ Redémarrer la machine avec ce seul périphérique et voir si le BIOS le détecte
A5/ Débrancher le périphérique
B: Faire les manips A2 à A5 pour le second périphérique
B2/ Prendre le second périphériques IDE, positionner le cavalier sur "MASTER"
B3/ Brancher ce périphérique en bout de naoppe.
B4/ Redémarrer la machine avec ce seul périphérique et voir si le BIOS le détecte
B5/ Débrancher le périphérique
Si le BIOS détecte tes deux périphériques en mode Master de façopn indépendante, c'est bon signe. Essaie donc les manips suivantes :
C: Tenter un branchement en "Cable Select"
1/ Positionner les cavaliers des deux périphériques en mode "Cable Select" ou "CS"
2/ Brancher les périphériques sur la nappe (un au milieu, l'autre au bout).
3/ Redémarrer la machine sur le BIOS pour voir s'ils sont détectés.
Question : As-tu une autre machine sur laquelle tu pourrais tester tes périphériques IDE, ou d'autres périphériques IDE que tu pourrais tester sur cette machine ?
suggestion : pour s'assurer que tespériphériques IDE sont bien présents et pour t'assurer que le problème ne vient pas de là, essaie de désactiver le support SATA dans le bios, en t'assurant que le support IDE est bien actif. Ensuite regarde si le BIOS voit tes périphériques IDE. Tu sauras ainsi si c'est un problème de désactivation IDE lorsque le SATA est actif.
Donc Linux est adapté au très bas de gamme et aussi au très haut de gamme, mais comme par magie il n'est pas adapté au milieu de gamme, le truc entre les deux.
Tu parles de quoi ? Du noyau ou de la distribution ? comme je pense que tu parles de la distrib, tu devrais relire ce que j'ai écrit : les serveurs du top500 sont des serveurs qui tournent avec des versions adaptées spécifiquement des distributions d'OS, quel que soit l'OS sous-jacent. Tu n'installes pas une Debian ou une RedHat/centOS standard pour tirer profit du matos.
Mouais, donc en gros la cible de Linux, cool on parle de Linux.
Finalement ça va bien dans la cible!
Non, la cible Linux c'est aussi les trucs un peu plus costauds, sans entrer dans le top 500. Ca commençait à bien partir. On commençait à avoir des choses intéressantes. RedHAt Cluster est assez bien fichu, et tourne pas trop mal. Il lui manque quelques fonctionnalités pour remplacer un HACMP ou un HP Serviceguard (a moins que depuis elles soient arrivés). Et je dis du bien de RedHAt Cluster, alors mêe que son fichier de conf est en XML, alors qu'en général je n'aime pas trop ça (l'avantage de ce fichier est qu'il est plutôt bien écrit, par contre il est parfois difficile de s'y retrouver dedans).
(OK, le top500 est un mode particulier, pas généralisable, mais bon, tu as commencé à parler de "monde particulier"… Et puis, IBM en fait du Linux aussi)
Je me suis mal exprimé sur le monde particulier. Je parle du monde que je cotoie au quotidien, que l'on retrouve dans les banques, les télécoms, l'industrie, etc … : j'aurais du parler d'un monde différent du desktop et des serveurs "bas de gamme", le monde entre ça et le top 500 (note qu'en général, les OS tournant sur ces environnements sont des OS adaptés spécifiquement, que ce soit du Linux, Windows, AIX ou autre).
Aucun rapport : restons dans la technique STP. Je ne suis pas résistant au changement, mais je n'aime pas le changement pour le changement. Il y a des changements assez réussi (on peut par exemple parler des changements sur l'ordonnanceur du noyau par exemple), /proc et /sys sont de bonnes idées (je ne dis pas que c'est parfait, notamment je trouve que les arborescences sont parfois complexes à retenr dans /sys et une commande faisant la modif au bon endroit serait parfois utile). Quitte à changer le système d'init, j'aurais préféré que ce ne soit pas aussi brutal, et qu'on s'attaque aux vrais problèmes. Là je vois urtout un gars qui a envie de faire parler de lui (et ça marche) et qui est parti dans son délire en voulant tout réécrire les fondamentaiux de Linux. En soit ça ne me gène pas, mais qu'il annonce la couleur de suite plutôt que de mentir comme il l'a fait, et qu'il appelle son OS Systemd/Linux et le présente comme une alternative à GNU/Linux. Parce que c'est bien vers ça que l'on va.
Je trouve l'attitude de Google beaucoup plus clean sur ce point, et Androïd une alternative intéressante à un GNU/Linux
Donc en gros tu dis que tout ce que Linux a fait depuis des lustres c'est pas bien… Et bizarrement, c'est à ce moment-la que Linux a explosé en part de marché.
Enlève tes oeuillères : je ne parle pas de tout. Ou alors je me suis mal exprimé, ce qui est possible.
Et bizarrement, c'est à ce moment-la que Linux a explosé en part de marché.
Tout simplement parce que entre une station ultra5 + Solaris à 25000 F et un PC + Linux à 10000F le choix est vite fait. Ce n'est pas parce que Linux faisait mieux que les autres, au contraire dans certains cas, il faisait moins bien, mais les DSI s'en sont accomodés pour de petits serveurs qui autrefois étaient gérés par des machines Unix bas de gamme mais qui coutaient quand même très cher. Linux sur les grosses infras critiques, c'est relativement récent.
Et après, tu vas nous dire qu'à cause de systemd, Linux sur les serveurs va chuter? ha ha ha… Tu t'enfonces tout seul…
Il restera cantonné aux petits serveurs et aux petites VM, et perdra les parts qu'il est en train de gagner sur les trucs un peu plus musclés. Ou alors ce sera une distrib adaptée, comme on en voit sur certains clusters spécifiques, pour lesquels il faudra payer cher une prestation d'adaptation/maintenance. Et les systèmes que je cotoie tous les jours qui aujourd'hui tournent sous AIX/Solaris resteront sous AIX/Solaris parce que le cout d'adaptation/maintenance du Linux ne sera pas rentable.
Clair, chez Red Hat qui est à fond dessus, ils n'ont jamais eu à gérer des serveurs bizarres avec des demandes bizarres,
Redhat et Linux, dans la plupart des cas, c'est du PC X86, des VM sous VMWare. Les autres trucs plus costauds, c'est AIX, Solaris, HP-UX et zOS avec son monde particulier.
Tu peux rire tant que tu veux, Red!hart dans le monde des serveurs hauts de gamme, c'est rien du tout.
Red Hat, ce sont des petits joueurs face à Kaane et totof2000 qui sont des dieux des trucs compliqués…
Non, mais RedHat ce sont des petits joueurs face à IBM par exemple. Tu peux rire tant que tu veux et garder tes oeuillères, ça ne changera rien à la réalité.
PS : tu attaques perso faute d'arguments vraiment contre et en ayant de très grandes oeillères, je répond perso, c'est nul mais je joue.
Les arguments contre t'ont été donnés avec un exemple précis, je n'ai rien à y ajouter. Ce sont des arguments de personnes ayant des problématiques d'admn à régler au quotidien, pas des argments de marketteux comme chez RedHat. Et en général, chez RedHat, ils ne sont pas là pour faire de la gestion au quotidien.
Ah tiens, puisque tu me parle du Dieu Redhat : ils ont mis au point un système de déploiement qui s'appelle RedHat Sattellite: ce truc marche très bien pour faire du déploiement d'OS et de la gestion de configuration simple, mais c'est une plaie lorsque tu veux gérer des configurations complexes : ça n'empêche pas RedHat de le vendre pour ça, alors que des outils comme Puppet ou Chef sont beaucoup mieux fichu pour ça. Et je ne suis pas un dieu, je suis juste un utilisateur de ces outils au quotidien.
C'est justement ce que je reproche au monde Linux : vouloir toujours tout changer et tout révolutionner, puis se rendre compte que ce n'était pas la bonne solution ensuite puis rechanger pur un autre truc qui marche moins bien, et HAL est un exemple flagrant. Les scripts rc de NetBSD sont un exemple de propreté et de factorisation de code qui montre que des scripts, ce n'est pas si pourri que ça.
Je suis parfaitement au courant, c'est l'une des raisons pour lesquelles je ne fais plus de Solaris. Mais vu que Solaris est prévu pour tourner sur du matos spécifique, il est fort probable que les problématiques de desktop auxquelles tente de répondre SystemD n'ont pas été prises en compte. Sinon, il me semble que le système de démarrage de Solaris et de SystemD ne sont pas si proches que ça : le système de démarrage de Solaris - me semble-t-il - ne s'accapare pas la gestion des logs et tous les autres trucs que fait systemd. Il faudrait que je vérifie ça.
Admettons-le, les scripts shell pour lancer les différents services, ce n'est pas ce qu'on a vu de plus propre dans le monde Unix: les mêmes scripts à quelques détails près sans aucune factorisation de code!
Va voir les scripts rc de NetBSD et on en reparle. Sinon il y a de la factorisation de code dans les scripts des distribs Linux.
Le système d'init/boot, en temps que d'utilisateur et développeur, je n'ai que très rarement un contact direct avec.
Le système d'init et de boot, en tant qu'admin de serveurs, j'y suis confronté tous les jours. Et quand ça ne démarre pas, ce n'est pas toi, le développeur, qui se débrouille pour que la machine reparte. En tant que développeur, tu n'y vois que dalle. Par contre, quand il y a quelque chose qui ne part pas, c'est mon job de chercher à comprendre pourquoi, et je préfère dans ce cas un truc un peu moins "neuneu-friendly (sur un serveur - je précise) mais qui garde une certaine souplesse et une grande simplicité de design. Le système d'init a ses défauts qu' on aurait pu tenter de corriger plutôt que de vouloir tout réécrire from scratch.
Laisse tomber : tu parles à quelqu'un qui a des oeuillères et qui n'a jamais eu à gérer des serveurs qui paraissent être des cas "rares" dans leur monde du poste de travail ou du serveur de fichier, mais qui est beaucoup plus courant que l'on ne le croit ailleurs.
Systemd sur un poste de bureau, je n'ai rien contre, bien au contraire. Systemd, c'est sur les serveurs que je n'en veux pas, parce que les problématiques serveurs et poste de bureau ne sont absolument pas les mêmes. Et le genre de problème qui a été reonté par la personne à qui tu réponds, c'est ce que l'on rencontre couramment dans le monde des "gros" serveurs. Maintenant ce que je vois, c'est qu'à cause de ce genre de conneries, c'est une tentative de percer sur le bureau. ca ne marchera pas. Et surtout, Linux perdra le marché des serveurs au profit des OS proprios tels qu'AIX ou Solaris, voire Windows.
Ça ne change pas l'hostname, ça le change après le prochain redémarrage. Ce n'est pas très user friendly.
Faut être un peu couillon pour changer son hostname toutes les 5 minutes aussi.
Ça demande aussi un redémarrage pour être appliquer. Si ta vision de Linux, c'est un truc à la Windows où il faut redémarrer dès qu'on change un paramètre, c'est bien mais je préfèrerais un truc mieux foutu.
Sur un serveur on s'en fiche, et c'est même mieux qu'on ne puisse pas faire plein de changement à la volée : ça évite que n'importe qui fasse n'importe quoi sans prévenir personne. Quand tu fais des astreintes, c'est pas très agréable de se rendre compte qu'un truc ne marche plus parce que le hostname (ou autre) a été changé à la volée sans que personne ne soit prévenu. En cas de reboot, ça se voit plus facilement : faut demander un arrêt de service, ça risque pas de passer inapperçu.
Ça ne change pas l'hostname, ça le change après le prochain redémarrage. Ce n'est pas très user friendly.
hostname c'est pas mal non plus. Et pour être sur d'être cohérent avec ta config, un truc du genre hostname $(cat /etc/hostname) marche bien. Et surtout, ça n'a pas à être user friendly sur un serveur, mais admin friendly. Et les trucs user-friendly (qui bien souvent veut dire neuneu-friendly) , ça a tendance à ne pas trop plaire aux admins.
[^] # Re: Sauvegarde ?
Posté par totof2000 . En réponse au message RAID 5 sans spare => changement préventif de disque. Évalué à 2.
Des "utilisateurs", j'en connais plein qui ont perdu des données suite à des erreurs de manip. Certes, pas forcément à cause du "rm -fr" (qui est peu fréquent). Ca peut être le formattage d'un disque dur au lieu d'une clé USB ou d'un disque externe, restauration système fournie par le constructeur qui écrase tout, un virus, malware, ou plein d'atres raisons.
Non. La "copie de sauvegarde" te sert à récupérer tes données à un instant T, sans se poser de question sur la raison pour laquelle elle a disparu.
Oui, si tu ne te veux te prémunir uniquement de la perte d'un disque. Celà dit comme tu le disais plus haut, tu n'es pas à l'abri de la perte de tous tes disques (incendie, orage, etc ….). Mais le seul moyen efficace de pouvoir récupérer ses données à un instant T, c'est la sauvegarde.
Bien sur que si ça a du sens … Comme justement. Toutes les données n'ont pas la même criticité. Comme on a de plus en plus de choses sur nos machines, c'est difficile de tout sauvegarder. Il faut faire des choix et un tri pour pouvoir s'en sorti sans que ça ne coute trop cher.
Dans ce cas ce n'est pas de la sauvegarde que tu fais mais de l'archivage, et tu ne le gère pas du tout de la même façon.
Dans ce cas, c'est que tu ne t'es pas posé la question de savoir pourquoi tu gardes ces données. Si tu sais pourquoi tu gardes tes données et combien de temps, tu décideras ensuite de l'endroit ou tu les rangeras.
Comme je l'ai dit plus haut, l'utilisateur est moins fiable que le hardware ou le noyau. Mais sinon il me semble qu'à une époque il y avait un méchant bug sur XFS qui te corrompait méchamment la table d'inodes. Le truc c'est que ton FS pouvait sembler continuer à bien fonctionner mais dans les faits, tu ne t'en rendais compte que lorsque tu redémarrais ta machine, ou lorsque tu essayais de relire tes données.
Si tu fais des sauvegardes rgulières, pas de problème. Tu n'auras qu'à copier que le delta ar rapport à ta dernière sauvegarde avant de changer le disque. Et un risque peu probable n'est pas un risque inexistant : le jour ou ça arrive, et que tu n'a pas pris de précautions, tu pleures.
Tu fais comme tu veux. Mais si tu perds ta machine en raison d'une surtension (orage ou mauvaise manip sur le réseau électrique), tu risque de perdre beaucoup.
Pour ma part je n'archive que ce que je ne pourrai pas retrouver : photos, documents administratifs et documents que j'ai produit, sur disque externe. Au final, ça ne représente pas tant de données que ça. Par contre je reconnais que si on fait de la vidéo, ça peut vite monter.
Je ne suis pas encore passé à ce stade, mais j'envisage de me procurer des disques durs externes et de les confier à une personne de confiance pour la sauvegarde/archivage, en établissant un roulement. A mon avis pour être efficace, il faudrait 3 disques au moins (mêm 4 si je garde un exemplaire chez moi) avec un truc de ce genre.Il faut que j'y réfléchisse sérieusement.
# Si tu utilises Mysql/Mariadb ou autre SGBDR ....
Posté par totof2000 . En réponse au message Besoin de conseils pour la création d'un SAN. Évalué à 3.
Il faut bien préciser ou tu veux mettre la haute dispo et la répartition de charge. De plus tu aurais du te poser cette question lors du choix du SGBD, car il y a des choses qui peuvent être faites à son niveau.
Niveau haute disponibilité, que voudrais-tu exactement ?
1/ veux-tu un cluster de serveurs de base de données qui accèderaient à tes LUNs simultanément ? A ma connaissance, seul Oracle RAC permet de le faire (il y en a peut-être d'autres mais je ne les connais pas - si qqn a des infos à ce sujet, je suis preneur).
2/ Ou alors voudrais-tu deux serveurs ou baies qui mettraient à dispo la volumétrie via iSCSI en permettant une écriture synchrone sur les deux serveurs (une sorte de raid1 entre les LUNs ?). Dans ce cas, c'est simple : deux machines exportant leur volumétrie : tu crées des LUNs identiques sur chaque machine, et ensuite tu fais un RAID1 LVM (ou autre) pour avoir la haute dispo au niveau des données. Par contre, pas de répartition de charge : les données sont écrites simultanément sur tes 2 UNS. Côté perfs, ça doit pas être génial …
3/ tu pourrais simuler un actif/actif avec répartition de charge "manuelle" en utilisant deux machines qui aurait chacune une partie des données en actif, et qui répliqueraient celles-ci sur l'autre en mode passif, avec un cluster style heartbeat pour gérer la haute dispo.
Sinon, si tu veux des idées, va Va voir ce slide. Je cherche la vidéo associée, mais je ne la trouve pas. Mais dans le slide tu trouveras quelques infos (qui pourront te servir de base de recherche) pour faire du mariadb distribué.
[^] # Re: Emmabuntus!
Posté par totof2000 . En réponse au message quel linux sur vieux portable. Évalué à 2.
Je conseillerais quand même de tenter d'ajouter de la RAM : même si Linux tourne sur ce genre de machine avec un gestionnaire de bureau léger, il risque de manquer de mémoire pour faire tourner les applis. Avoir un OS qui tourne c'est bien, mais ce n'est pas une fin en soi :)
[^] # Re: Sauvegarde ?
Posté par totof2000 . En réponse au message RAID 5 sans spare => changement préventif de disque. Évalué à 3.
JAMAIS, NON JAMAIS !!!!!
Le RAID quel qu'il soit n'est là QUE pour la disponibilité. Ceux qui s'en servent pour autre chose sont simplement fous ou inconscients.
Un RAID quelq qu'il soit ne te préservera jamais d'un rm au mauvais endroit, ou de l'écrasement d'un fichier par un autre par erreur.
D'ou l'intérêt de faire de l'incrémental. Sinon, l'intéret est de savoir pourquoi on garde ces données, et à quelle fréquence elles bougent.
[^] # Re: Merci infiniment pour votre aide à tous,je vous communique les derniers essais avec photo
Posté par totof2000 . En réponse au message Problème de reconnaissance IDE. Évalué à 2.
Avec bios classique ou uefi ?
[^] # Re: Merci infiniment pour votre aide à tous,je vous communique les derniers essais avec photo
Posté par totof2000 . En réponse au message Problème de reconnaissance IDE. Évalué à 3.
Pour info, Linux n'est pas magique (et Windows non plus). Si le périphérique n'est pas reconnu au BIOS, Linux n'y peut rien, et ne le reconnaîtra pasd plus.
[^] # Re: ok..
Posté par totof2000 . En réponse au message Pourquoi certains sites ne répondent pas en http avec telnet ?. Évalué à 8.
C'est quoi cette manie de toujours dénigrer les outils qui font bien leur taf ?
Telnet est très pratique pour faire des tests rapides d'ouverture de ports. C'est comme si tu demandais à quoi peut servir une pelle en 2013 alors qu'il existe des pelleteuses.
[^] # Re: Merci infiniment pour votre aide à tous,je vous communique les derniers essais avec photo
Posté par totof2000 . En réponse au message Problème de reconnaissance IDE. Évalué à 2. Dernière modification le 11 décembre 2013 à 17:16.
Un problème à la fois …
On va se concentrer sur les périphériues IDE, et vérifier que es ralentissements lui sont bien liés:
Quels périphériques as-tu et combien ? Es-tu allé voir le lien que je t'ai mis plus haut pour les cavaliers ?
Pour s'assurer que les ralentissements sont bien liés aux périphériques IDE, peux-tu essayer, si ce n'est déjà fait, un redémarrage en débrnchant toutes les nappes IDE et dire si c'est toujours aussi lent ? Si c'est le cas, je crains pour la carte mère.
Sinon, à te lire, je suis presque convaincu qu'il s'agit d'un problèmede positionnement de cavaliers sur les disques durs ou lecteurs DVD.
Un peu de patience et de méthode, et , on va y arriver ;)
[^] # Re: Merci infiniment pour votre aide à tous,je vous communique les derniers essais avec photo
Posté par totof2000 . En réponse au message Problème de reconnaissance IDE. Évalué à 2.
Mettre un périphérique en "cs" ne se fait pas dans le bios mais sur le périphérique (voir par exemple http://forums.cnetfrance.fr/topic/112947-position-du-cavalier-jumper-sur-un-peripherique-ide-ou-sata/ ).
Il faut positionner le cavalier de façon telle que ton périphérique soit Master en bout de nappe.
La nappe du lecteur de disquette n'a rien à voir, oublie-là.
Cordialement.
[^] # Re: Merci infiniment pour votre aide à tous,je vous communique les derniers essais avec photo
Posté par totof2000 . En réponse au message Problème de reconnaissance IDE. Évalué à 2.
Refais la manip, redémarre la machine, reviens sur le BIOS pour voir si les périphériques sont détectés.
Si tu ne les vois toujours pas, ça sent mauvais pour le controleur IDE ….
Je te propose un nouveau test: essaie de le faire en désactivant les controleurs SATA pour éviter toute interférence. Le but : essayer chaque périphérique IDE de façon indépendante en mode "Master"
A :
A1/ Débrancher les deux périphériques IDE.
A2/ Prendre un des deux périphériques IDE, positionner le cavalier sur "MASTER"
A3/ Brancher ce périphérique en bout de naoppe.
A4/ Redémarrer la machine avec ce seul périphérique et voir si le BIOS le détecte
A5/ Débrancher le périphérique
B: Faire les manips A2 à A5 pour le second périphérique
B2/ Prendre le second périphériques IDE, positionner le cavalier sur "MASTER"
B3/ Brancher ce périphérique en bout de naoppe.
B4/ Redémarrer la machine avec ce seul périphérique et voir si le BIOS le détecte
B5/ Débrancher le périphérique
Si le BIOS détecte tes deux périphériques en mode Master de façopn indépendante, c'est bon signe. Essaie donc les manips suivantes :
C: Tenter un branchement en "Cable Select"
1/ Positionner les cavaliers des deux périphériques en mode "Cable Select" ou "CS"
2/ Brancher les périphériques sur la nappe (un au milieu, l'autre au bout).
3/ Redémarrer la machine sur le BIOS pour voir s'ils sont détectés.
Question : As-tu une autre machine sur laquelle tu pourrais tester tes périphériques IDE, ou d'autres périphériques IDE que tu pourrais tester sur cette machine ?
[^] # Re: ca fonctionne
Posté par totof2000 . En réponse au message Problème de reconnaissance IDE. Évalué à 2.
suggestion : pour s'assurer que tespériphériques IDE sont bien présents et pour t'assurer que le problème ne vient pas de là, essaie de désactiver le support SATA dans le bios, en t'assurant que le support IDE est bien actif. Ensuite regarde si le BIOS voit tes périphériques IDE. Tu sauras ainsi si c'est un problème de désactivation IDE lorsque le SATA est actif.
[^] # Re: ca fonctionne
Posté par totof2000 . En réponse au message Problème de reconnaissance IDE. Évalué à 2.
Il est possible sur certains modèles de paramétrer ce comportement dans le bios.
[^] # Re: LTSP avec ou sans le fat-client
Posté par totof2000 . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 3. Dernière modification le 09 décembre 2013 à 10:40.
Sans vouloir entrer dans le troll, est-ce que l'arrivée de Wayland remettra en cause les solutions que vous avez mis en place ?
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Tu parles de quoi ? Du noyau ou de la distribution ? comme je pense que tu parles de la distrib, tu devrais relire ce que j'ai écrit : les serveurs du top500 sont des serveurs qui tournent avec des versions adaptées spécifiquement des distributions d'OS, quel que soit l'OS sous-jacent. Tu n'installes pas une Debian ou une RedHat/centOS standard pour tirer profit du matos.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Non, la cible Linux c'est aussi les trucs un peu plus costauds, sans entrer dans le top 500. Ca commençait à bien partir. On commençait à avoir des choses intéressantes. RedHAt Cluster est assez bien fichu, et tourne pas trop mal. Il lui manque quelques fonctionnalités pour remplacer un HACMP ou un HP Serviceguard (a moins que depuis elles soient arrivés). Et je dis du bien de RedHAt Cluster, alors mêe que son fichier de conf est en XML, alors qu'en général je n'aime pas trop ça (l'avantage de ce fichier est qu'il est plutôt bien écrit, par contre il est parfois difficile de s'y retrouver dedans).
Je me suis mal exprimé sur le monde particulier. Je parle du monde que je cotoie au quotidien, que l'on retrouve dans les banques, les télécoms, l'industrie, etc … : j'aurais du parler d'un monde différent du desktop et des serveurs "bas de gamme", le monde entre ça et le top 500 (note qu'en général, les OS tournant sur ces environnements sont des OS adaptés spécifiquement, que ce soit du Linux, Windows, AIX ou autre).
[^] # Re: résistance au changement
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Aucun rapport : restons dans la technique STP. Je ne suis pas résistant au changement, mais je n'aime pas le changement pour le changement. Il y a des changements assez réussi (on peut par exemple parler des changements sur l'ordonnanceur du noyau par exemple), /proc et /sys sont de bonnes idées (je ne dis pas que c'est parfait, notamment je trouve que les arborescences sont parfois complexes à retenr dans /sys et une commande faisant la modif au bon endroit serait parfois utile). Quitte à changer le système d'init, j'aurais préféré que ce ne soit pas aussi brutal, et qu'on s'attaque aux vrais problèmes. Là je vois urtout un gars qui a envie de faire parler de lui (et ça marche) et qui est parti dans son délire en voulant tout réécrire les fondamentaiux de Linux. En soit ça ne me gène pas, mais qu'il annonce la couleur de suite plutôt que de mentir comme il l'a fait, et qu'il appelle son OS Systemd/Linux et le présente comme une alternative à GNU/Linux. Parce que c'est bien vers ça que l'on va.
Je trouve l'attitude de Google beaucoup plus clean sur ce point, et Androïd une alternative intéressante à un GNU/Linux
[^] # Re: résistance au changement
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
Enlève tes oeuillères : je ne parle pas de tout. Ou alors je me suis mal exprimé, ce qui est possible.
Tout simplement parce que entre une station ultra5 + Solaris à 25000 F et un PC + Linux à 10000F le choix est vite fait. Ce n'est pas parce que Linux faisait mieux que les autres, au contraire dans certains cas, il faisait moins bien, mais les DSI s'en sont accomodés pour de petits serveurs qui autrefois étaient gérés par des machines Unix bas de gamme mais qui coutaient quand même très cher. Linux sur les grosses infras critiques, c'est relativement récent.
Il restera cantonné aux petits serveurs et aux petites VM, et perdra les parts qu'il est en train de gagner sur les trucs un peu plus musclés. Ou alors ce sera une distrib adaptée, comme on en voit sur certains clusters spécifiques, pour lesquels il faudra payer cher une prestation d'adaptation/maintenance. Et les systèmes que je cotoie tous les jours qui aujourd'hui tournent sous AIX/Solaris resteront sous AIX/Solaris parce que le cout d'adaptation/maintenance du Linux ne sera pas rentable.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
Redhat et Linux, dans la plupart des cas, c'est du PC X86, des VM sous VMWare. Les autres trucs plus costauds, c'est AIX, Solaris, HP-UX et zOS avec son monde particulier.
Tu peux rire tant que tu veux, Red!hart dans le monde des serveurs hauts de gamme, c'est rien du tout.
Non, mais RedHat ce sont des petits joueurs face à IBM par exemple. Tu peux rire tant que tu veux et garder tes oeuillères, ça ne changera rien à la réalité.
PS : tu attaques perso faute d'arguments vraiment contre et en ayant de très grandes oeillères, je répond perso, c'est nul mais je joue.
Les arguments contre t'ont été donnés avec un exemple précis, je n'ai rien à y ajouter. Ce sont des arguments de personnes ayant des problématiques d'admn à régler au quotidien, pas des argments de marketteux comme chez RedHat. Et en général, chez RedHat, ils ne sont pas là pour faire de la gestion au quotidien.
Ah tiens, puisque tu me parle du Dieu Redhat : ils ont mis au point un système de déploiement qui s'appelle RedHat Sattellite: ce truc marche très bien pour faire du déploiement d'OS et de la gestion de configuration simple, mais c'est une plaie lorsque tu veux gérer des configurations complexes : ça n'empêche pas RedHat de le vendre pour ça, alors que des outils comme Puppet ou Chef sont beaucoup mieux fichu pour ça. Et je ne suis pas un dieu, je suis juste un utilisateur de ces outils au quotidien.
[^] # Re: résistance au changement
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
C'est justement ce que je reproche au monde Linux : vouloir toujours tout changer et tout révolutionner, puis se rendre compte que ce n'était pas la bonne solution ensuite puis rechanger pur un autre truc qui marche moins bien, et HAL est un exemple flagrant. Les scripts rc de NetBSD sont un exemple de propreté et de factorisation de code qui montre que des scripts, ce n'est pas si pourri que ça.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à -1.
Je suis parfaitement au courant, c'est l'une des raisons pour lesquelles je ne fais plus de Solaris. Mais vu que Solaris est prévu pour tourner sur du matos spécifique, il est fort probable que les problématiques de desktop auxquelles tente de répondre SystemD n'ont pas été prises en compte. Sinon, il me semble que le système de démarrage de Solaris et de SystemD ne sont pas si proches que ça : le système de démarrage de Solaris - me semble-t-il - ne s'accapare pas la gestion des logs et tous les autres trucs que fait systemd. Il faudrait que je vérifie ça.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
Va voir les scripts rc de NetBSD et on en reparle. Sinon il y a de la factorisation de code dans les scripts des distribs Linux.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Le système d'init et de boot, en tant qu'admin de serveurs, j'y suis confronté tous les jours. Et quand ça ne démarre pas, ce n'est pas toi, le développeur, qui se débrouille pour que la machine reparte. En tant que développeur, tu n'y vois que dalle. Par contre, quand il y a quelque chose qui ne part pas, c'est mon job de chercher à comprendre pourquoi, et je préfère dans ce cas un truc un peu moins "neuneu-friendly (sur un serveur - je précise) mais qui garde une certaine souplesse et une grande simplicité de design. Le système d'init a ses défauts qu' on aurait pu tenter de corriger plutôt que de vouloir tout réécrire from scratch.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à -4.
Laisse tomber : tu parles à quelqu'un qui a des oeuillères et qui n'a jamais eu à gérer des serveurs qui paraissent être des cas "rares" dans leur monde du poste de travail ou du serveur de fichier, mais qui est beaucoup plus courant que l'on ne le croit ailleurs.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 0.
Systemd sur un poste de bureau, je n'ai rien contre, bien au contraire. Systemd, c'est sur les serveurs que je n'en veux pas, parce que les problématiques serveurs et poste de bureau ne sont absolument pas les mêmes. Et le genre de problème qui a été reonté par la personne à qui tu réponds, c'est ce que l'on rencontre couramment dans le monde des "gros" serveurs. Maintenant ce que je vois, c'est qu'à cause de ce genre de conneries, c'est une tentative de percer sur le bureau. ca ne marchera pas. Et surtout, Linux perdra le marché des serveurs au profit des OS proprios tels qu'AIX ou Solaris, voire Windows.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Faut être un peu couillon pour changer son hostname toutes les 5 minutes aussi.
Sur un serveur on s'en fiche, et c'est même mieux qu'on ne puisse pas faire plein de changement à la volée : ça évite que n'importe qui fasse n'importe quoi sans prévenir personne. Quand tu fais des astreintes, c'est pas très agréable de se rendre compte qu'un truc ne marche plus parce que le hostname (ou autre) a été changé à la volée sans que personne ne soit prévenu. En cas de reboot, ça se voit plus facilement : faut demander un arrêt de service, ça risque pas de passer inapperçu.
hostname c'est pas mal non plus. Et pour être sur d'être cohérent avec ta config, un truc du genre hostname $(cat /etc/hostname) marche bien. Et surtout, ça n'a pas à être user friendly sur un serveur, mais admin friendly. Et les trucs user-friendly (qui bien souvent veut dire neuneu-friendly) , ça a tendance à ne pas trop plaire aux admins.