Archive for the ‘Technique’ Category

Reboot “hard” de serveur linux, avec un shell

Saturday, March 14th, 2009

Il peut arriver que l’état d’instabilité d’un serveur dédié, rende impossible l’utilisation de la commande reboot. Par exemple des binaires corrompus, un système de fichier endommagé, ou tout simplement un état de charge qui ne permet pas un contrôle suffisant. Dans ce cas là, il est possible, lorsque l’on est devant le serveur d’utiliser les SysReq. Cependant, ces combinaisons de touche, peuvent poser problème à distance, lorsque l’on a comme unique moyen d’accès un shell ssh.

Heureusement il est tout de même possible d’obtenir le même résultat. Il s’agit d’un reboot “sauvage”, les services ne sont pas arrêtés, et la machine est rebootée, avec un résultat similaire à un reboot hard. Eventuellement, vous pouvez mettre en place un cron sur le serveur avec certaines conditionnelles qui effectue cette opération salvatrice (attention à bien contrôler tous les paramètres).

Bref venons en au fait :

Sur votre shell linux, lancer tout simplement les commandes suivantes :

echo 1 > /proc/sys/kernel/sysrq (pour activer les sysreq)
echo b > /proc/sysrq-trigger (pour lancer le reboot sauvage)

Contrairement à la commande reboot ou shutdown, le redémarrage est automatique, sans tenter d’arrêter des processus ou encore de démonter les systèmes de fichiers (ce qui évite également les reboot qui ne peuvent fonctionner à cause de ces problèmes). Petite astuce de Hacker à utiliser tout de même avec parcimonie !

Share/Save/Bookmark

4 conseils pour bien choisir, optimiser et exploiter son serveur dédié

Sunday, March 1st, 2009

10 ans, cela fait une décénnie que Digital Network fourni des serveurs dédiés à ses clients. 10 ans que nous inventons de nouveaux produits, 10 ans que nous façonnons chaque serveur pour l’utilisation qui en sera faite par le client. De cette décennie d’expérience, nous avons retiré quelques règles que je vous fais partager. Ces règles de base, bien qu’elles puissent paraître simplistes vous permettront de bien choisir votre serveur dédié, et d’avoir un uptime moyen de plus de 500 jours sans trop de difficultés.

1) Connaître son projet : trop d’achat de serveurs dédiés ont lieu avant que le projet qu’il doit hébergé ait été correctement dimensionné. Il est important de bien connaître son projet mais également les technologies qui seront utilisées (php, python, perl, c, cgi, mysql, postgresql, oracle, websphere, dbase, apache…), l’espace physique occupé qui utilisera ces technologies et comment il sera concrètement utilisé : aura t’on besoin de beaucoup d’espace ? Hébergera t’on des gros fichiers, ou plutôt des petits, en quel nombre et dans quelle arborescence ? Quelle sera la taille physique de la base de données utilisée… une fois remplie ? Va t’on faire beaucoup de calcul brut ou bien va t’on plutot lire et écrire des données ? Va t’on traiter beaucoup de tâches en parallèle ou au contraire de grosses tâches les unes derrière les autres ? Une architecture multi-coeurs est elle préférable ou au contraire devont nous bâtir notre serveur sur un processeur puissant mais monocore ?. Les réponses à toutes ces questions permettront dans un premier temps de dimensionner correctement le hardware de votre serveur dédié, et, dans un second temps : de l’installer et de l’optimiser de manière adéquate.

Une fois obtenues les réponses à toutes ces questions, on pourra facilement évaluer le hardware nécessaire (processeur, ram), le type de disque dur (Enterprise Server, Velociraptor, SAS ou encore SSD ?), le type de raid à utiliser (RAID 1, RAID5, RAID 1+0, RAID 0+1 ou RAID6 ?). Dans tous les cas de figure : il faudra choisir du matériel certifié serveur et ayant un MTBF (temps moyen de bon fonctionnement) le plus élevé possible.

D’autres étapes pour choisir, optimiser et exploiter correctement son serveur dédié sont nécessaires. Pour la suite, le plus simple est de consulter le lien suivant : Bien choisir son serveur dédié

Share/Save/Bookmark

L’éthique de pseudos bien pensant est un frein au progrès !

Sunday, March 1st, 2009

Le rythme semble s’accélérer dans les médias : clonage, génétique, cultures transgéniques, nanotechnologie ou intelligence artificielle, il ne se passe pas 1 mois sans que de “pseudos bien pensant” viennent manifester leur colère à l’encontre des avancées scientifiques, au nom d’une soi-disant “éthique”. Pourtant, bien souvent, c’est d’avantage une peur incontrôlable de l’inconnu qui motive ces actes et ces paroles, plus que l’éthique ou qu’un quelconque bon sens. Conserver un minimum de prudence dans le domaine scientifique est normal en soi, cependant, il ne faudrait pas que les mêmes individus qui réclamaient l’immolation des “sorciers” il y a quelques siècles, parviennent finalement à freiner l’évolution technologique et scientifique de l’espèce humaine.

En effet, contrairement à ce que prônent ces anti-progressistes, les technologies ne sont, non pas un moyen pour les puissants de dominer les faibles, bien au contraire : les avancées technologiques ont de tout temps été annonciatrices et suivies d’un vent de liberté.

Le progrès ne doit pas être arrêté sous de faux prétextes éthiques : en effet, même les technologies purement militaires trouvent dans le temps des utilisations civiles débouchant sur des progrès et un “mieux vivre” pour les gens de la terre entière. Il est trop tard pour faire marche arrière : seul un bond technologique peut nous permettre de lutter efficacement contre la pollution, la déforestation ou encore la maladie.

Au contraire, de certains courants de pensée pessimistes, je reste convaincu que les technologies modernes telles que l’ingénierie génétique, la technologie de l’information, la médecine pharmaceutique, l’anticipation des capacités futures dont la nanotechnologie, l’intelligence artificielle, le téléchargement des données du cerveau dans un ordinateur ou et vice-versa, ou encore la colonisation de l’espace sont annonciatrices d’un avenir extrêmement positif, et non de l’apocalypse que nombreux esprits, peut être encore trop fermés veulent voir.

Pour planifier l’avenir, il est impératif de tenir compte des progrès technologiques spectaculaires qui peuvent se produire. Il serait en effet catastrophique que ces avantages potentiels ne se matérialisent pas à cause de la technophobie ou de prohibitions inutiles. N’oublions pas que si, par le passé, l’homme s’était arrêté devant ce type de frayeurs, les inventions comme le langage, l’ecriture, l’imprimerie, l’électricité l’industrialisation, la médecine moderne ou encore internet, n’auraient jamais vu le jour, et l’espérance de vie plafonnerait toujours à une trentaine ou à une quarantaine d’années…

Le monde est ainsi fait que la voix de la contestation est souvent la seule qui se fait entendre, alors qu’elle reste rarement majoritaire. J’espère que ce post sera l’une des bases de lancement d’autres manifestations positives, et non l’encouragement à la manifestation d‘hostilités permanentes à laquelle le progrès doit aujourd’hui, une fois de plus faire face.

Share/Save/Bookmark

Faille DNS : beaucoup de bruit… pour pas grand chose.

Sunday, August 17th, 2008

Il y a quelques semaines, la presse s’emparait avec l’engouement médiatique habituel, de la récente “nouvelle” vulnérabilité dns, découverte par Dan Kaminsky. Cette faille, présentée comme la nouvelle épée de Damocles de ce monde numérique, pourrait mettre en danger le web tout entier. Oui mais…

Cette histoire me rappelle, l’autrement différente mais comparable attaque qui avait eu lieu contre les serveurs “racine” (Root Servers) sur lesquels repose en partie le fonctionnement de traduction d’adresses offert par le système DNS. Il y avait eu autant de bruit… pour pas grand chose encore : on pouvait “arrêter internet”. Oui et ? Et rien justement ; le fonctionnement d’Internet, dans son ensemble, repose sur une colonne vertébrale à la solidité plus proche du verre que du carbone. Ce n’est pas nouveau, et il existe des moyens beaucoup plus efficaces que de s’adresser aux serveurs racines pour en perturber le fonctionnement…

A la lecture des nombreux articles parlant de cette nouvelle vulnérabilité DNS, on y apprend qu’il s’agit simplement de l’application d’une technique de cache poisonning DNS. C’est une attaque en effet efficace… utilisée depuis plus de 10 ans, dans le cadre par exemple, de tests d’intrusion, ou expliquée dans le cadre de cours que j’ai eu l’occasion de dispenser pour un Opérateur Historique ou certains de nos ministères…

En effet, le protocole DNS a toujours été vulnérable aux attaques de type cache poisonning, ce n’est pas nouveau, même si son exploitation a, visiblement, été facilitée. C’est d’ailleurs l’une des raisons de la création du protocole DNSSEC, qui résoud en grande partie le problème sur le fond. Ce problème, comme de nombreuses autres vulnérabilités, est inhérent au fonctionnement et à la conception du réseau Internet et de la suite de protocoles TCP/IP, ni plus, ni moins. Cette “vulnérabilité”, représente surtout un risque pour l’utilisateur final mal renseigné, mais, dans la pratique, pas beaucoup plus qu’un virus ou un ver s’amusant à modifier les fichiers hosts des utilisateurs, avec un effet similaire.

Quoi de neuf là dedans ? A vrai dire, pas grand chose. Du réchauffé, de chez réchauffé, sans odeur et sans saveur, comme d’habitude dirons-nous : c’est ce qui se pratique depuis des lustres par les “médiatechnologues” de la sécurité. Alors que de nombreux routeurs composants le backbone internet utilisent encore des piles tcp/ip avec des numéros de séquence totalement prédictibles, qu’il est possible d’hijacker n’importe quelle connexion utilisant un protocole standard (ftp, email, web…), d’accéder de manière non autorisée au courrier électronique, le falsifier à la volée, ou encore récupérer en quelques clics dans un navigateur des banques de données complètes contenant des millions de logins et de passwords, et d’informations bancaires (numéro de CB, date d’expiration, nom du porteur…), cette faille DNS amène t’elle vraiment le chaos annoncé ?

La réponse est non, bien entendu. Pourquoi ? Tout simplement parce que 100% des systèmes d’information sont piratables, et ce depuis toujours, et le resteront probablement encore pendant quelques décennies. Les raisons en sont toutes simples : les ordinateurs sont “pensés” par des humains imparfaits, fabriqués par des machines conçues imparfaitement (d’ailleurs *tous* les processeurs sont buggués), sur lesquels on installe des système d’exploitation également imparfaits, tournant sur des langages eux mêmes imparfaits… La chaîne est encore longue, pour arriver jusqu’à l’applicatif utilisateur… et l’utilisateur lui même.

Le problème n’est donc pas de savoir si un système est piratable : il l’est par sa conception même *systématiquement*, il ne s’agit que d’une question de temps et de moyens, tout comme dans le cas d’un coffre fort par exemple. On ferait mieux de se préoccuper d’une vulnérabilité beaucoup plus importante et affectant aujourd’hui les systèmes les mieux protégés, sur lequels il reste possible d’agir, et, exploitable avec des moyens minimums : le facteur humain… Aujourd’hui encore, et pour longtemps je pense, la plus grande vulnérabilité reste située entre la chaise… et le clavier.

Share/Save/Bookmark

Ma nouvelle station : epona

Saturday, May 31st, 2008

Dernière station “maison” sortie de mes mains : elle s’appelle epona. Comme il y avait trop de matériel à l’intérieur, j’ai fixé l’alimentation à l’extérieur du boitier. Idem pour le radiateur du processeur : la bête butait contre le ventilateur d’extraction latéral : ce dernier est donc parti à l’extérieur du boitier.

Coté hardware, il est équipé d’un processeur AMD Phenom X4 Quad Core GP-9530, de 4 Go de RAM, et de 2 cartes Radeon dual core en crossifre HD3870X2, ce qui en fait, en sus d’une formidable “game machine”, une excellente station de travail linux avec ses 4 écrans 22 pouces au format wide screen, ce qui permet d’afficher simultanément 8 pages A4 à l’écran.

Le disque dur est un 750 Go à stockage perpendiculaire. A noter qu’Epona ne dépasse pas les 45 degrés dans un environnement à 27 degrés extérieur et en pleine charge.

Share/Save/Bookmark

L’eee PC : plus qu’un ultra-portable, un ultra communiquant.

Monday, March 3rd, 2008

Après avoir eu l’occasion de voir dans les mains d’un ami le nouveau eee-pc de chez asus, il ne m’aura fallu que peu de temps pour m’en procurer un. La lutte contre la rupture de stock fut acharnée, mais j’ai finalement pu trouver un petit magasin, qui en avait une dizaine d’avance.

Révolution serait un terme adapté, mais il serait insuffisant pour décrire l’eee-pc. Pour beaucoup moins cher que le dernier pda à la mode, cette merveille est non seulement la possibilité d’avoir une mini station bureautique complète dans sa poche, c’est également un formidable outil de communication.

EEE-PC Asus

Equipé de sa clef 3g, d’une webcam intégré, et en utilisant un logiciel comme skype, c’est la possibilité pour 2 personnes de travailler à plus de 1000 kms de distance tout en ayant l’impression d’être à coté. En effet, contrairement à un laptop standard, le “3E”, se déplace d’une seule main et peut vous suivre partout, et dans quasiement n’importe quelle circonstance.

Ce n’est cependant pas tout : cette petite merveille (qui tourne sous linux), peut être totalement personnalisée : cela devient alors un puissant outil de maintenance intégré. Avec son poid inférieur à 1 kg, il se fait vite oublier. Enfin, il dispose en standard d’une autonomie d’environ 3H30, qui peut être augmentée à 8H00 via une batterie complémentaire ayant une autonomie de 5H00.

L’eee-pc est probablement le premier d’une longue série, annonçant probablement une nouvelle façon de faire de l’informatique, du web, de communiquer, ou tout simplement… de travailler.

Share/Save/Bookmark

Sécurité dans les aéroports : réalité ou fiction ?

Tuesday, November 27th, 2007

Suite à quelques vacances programmées dans les caraïbes, j’en ai profité pour examiner d’un peu plus près les nouvelles normes de sécurité appliquées à l’embarquement aéroporté, et notamment celles concernant l’interdiction des liquides en cabine. Ma conclusion est sans appel : Si ces mesures auront probablement pour effet de rassurer l’inconscient collectif, elles ne sont d’aucune utilité pratique dans la lutte contre le terrorisme.

La suite ici : Sécurité dans les aéroports : Réalité ou Fiction ?

Share/Save/Bookmark

La haute disponibilité passe par la simplicité

Saturday, August 4th, 2007

Au cours des dix dernières années, nombreux sont les cas d’infrastructures dites sensibles, que ce soit pour des raisons de sécurité ou de disponibilité que j’ai du auditer, définir ou mettre en place. Le résultat de ces dix ans d’expérience est sans appel : la haute disponibilité passe par la simplicité.

Dans bien des cas, lorsqu’un projet nécessitant une haute disponibilité est nécessaire, c’est une infrastructure complexe (multiples load balancers en cascades, serveurs en chaine répliqués, structure pouvant basculer automatiquement sur ses secours en cas de panne, etc…) qui est généralement conseillée ou mise en place. Or avec l’amélioration technologique dont nous profitons, il n’est pas toujours nécessaire de déployer tout cela.

La principale erreur que font les responsables de telles architectures, c’est de ne pas se concentrer sur la réalité du but à atteindre dans son ensemble : concentrés sur la disponibilité et la performance, ils en oublient les probabilités de taux de panne, ainsi que les temps de rétablissement en accord avec la probabilité précédente.

Or ce dernier point est très important : en cas de problème grave (et non d’une coupure bête et méchante du service) s’ajoute un temps de diagnostic, temps qui croit de manière exponentielle avec la complexité de l’infrastructure. On se rend compte en étudiant les cas réels, que les problèmes (les vrais) sont rarement simples, ainsi, un fichier effacé sur un disque se réplique sur un RAID, une erreur ou corruption de base de données, peut se répliquer en temps réel sur des serveurs en réplications, etc… La redondance et le backup sont 2 points totalement différents à aborder, mais les paramètres entrant en ligne de compte sur la globalité de l’infrastructure sont très nombreux.

Avec le temps, je constate que dans 99% des cas, tous les points importants correspondant à la réalité pratique, et non à la théorie, ne sont quasiment jamais étudiés. C’est l’une des causes pour laquelle il y a encore aujourd’hui des pannes longues et lourdes sur les infrastructures les plus importantes, et disposant pourtant du plus de moyens.

Aller droit au but, et éviter ces pièges : la société au sein de laquelle j’occupe le poste de directeur technique s’en est fait une spécialité, notamment dans le domaine des infrastructures hébergées. Malgré cette spécificité, j’étudie la sortie à moyen terme d’un rapport basé sur toute cette expérience, avec une méthode de calcul permettant de réellement cibler le problème dans son ensemble. Ainsi 4H00 de panne 1 jour et 5 min par semaines, n’ont pas les mêmes conséquences, alors que le taux annuel reste le même, etc… Ce sont des centaines de paramètres qui doivent rentrer en compte dans une étude. La suite… peut être un de ces jours.

Share/Save/Bookmark

Petit point sur les stratégies de mot de passe

Tuesday, January 30th, 2007

Le mot de passe, quelque chose de si simple, si usuel qu’on en oublie très souvent l’importance. Boites emails, comptes shell, applications web, intranet, accès à votre compte bancaire : le mot de passe est partout.

L’importance du mot de passe est souvent sous estimée. On trouve ainsi de nombreux systèmes où des efforts considérables de sécurité ont été effectués, alors que les stratégies de mots de passe, définies le plus souvent sur le papier au sein de la politique de sécurité ou de la charte d’utilisation du système d’information, sont rarement vérifiées et appliquées.

Un cracker souhaitant devenir maître d’un système d’information, cherchera dans un premier temps à obtenir un compte au sein du système ou de l’application cible, puis cherchera à élever son niveau de privilèges jusqu’à obtenir ceux dont il a besoin pour accomplir sa tâche. Le premier compte obtenu, est souvent un compte utilisateur « mineur » ne disposant pas de privilèges particuliers, et où en conséquence, aucune stratégie de mot de passe particulière n’aura été appliquée.

Nom, prénom, mot usuel ou familier, le mot de passe d’un point considéré à tort comme non sensible (ex : mot de passe d’une secrétaire, d’un compte invité ou autre), constitue une faiblesse critique dans un système d’information.

Il existe pourtant quelques règles simples permettant d’obtenir un mot de passe d’une solidité tout à fait convenable. La première règle en matière de mots de passe est de ne jamais choisir un mot « réel », c’est à dire que l’on puisse trouver dans un dictionnaire (utilisés pour les attaques de type brute forcing sur un ou plusieurs comptes).

Tous les composés chimiques, noms propres, etc… sont bien entendu également à proscrire (les dictionnaires utilisés dans le brute forcing contiennent en effet également de type de de mot).Le brute forcing s’explique assez simplement : Sachant que l’on connaît l’algorithme de codage des mots de passe, il suffit alors de l’appliquer à des dictionnaires choisis astucieusement (on en trouve une multitude sur Internet et il est très facile d’en composer soi même), de crypter chaque mot du dictionnaire avec l’algorithme utilisé par le système de cryptage des mots de passe et de comparer le résultat avec l’existant.

Il est également possible d’utiliser du brute force dit « direct » en s’adressant directement au service d’authentification et en simulant un envoie via le protocole adapté du login et du mot de passe. En utilisant une technique de brute forcing sur un fichier, 20% des mots de passes sont cassés dans une moyenne d’une heure. Il est donc capital de choisir son mot de passe avec le plus grand sérieux.

Il convient de d’effectuer ce choix avec la plus grande attention, car il n’est jamais possible de connaître les informations dont le pirate dispose. Soyez donc vigilants et n’utilisez aucune information personnelle (numéro de sécurité sociale, immatriculation, prénom de votre petite amie, etc…).

Ne donner votre mot de passe à PERSONNE. Le mot de passe est un secret uniquement entre vous et le système, personne d’autres de doit être en mesure de l’utiliser et surtout pas votre voisin de bureau…Cette règle vaut dans toutes les situations, et le téléphone n’est pas une exception (de plus il est plus dur d’être certain de l’identité de son interlocuteur au téléphone qu’en l’ayant en face de soi.).

Il existe heureusement quelques techniques simples et efficaces permettant de générer un mot de passe solide. Un livre entier ne suffirait pas à toutes les énumérer, je vais donc rapidement expliquer les plus simples et les plus efficaces. Attention, la sécurité d’un mot de passe est également relative à l’algorithme de cryptage utilisé.

I] La phrase mnémonique

Cette méthode très simple permet de construire de bons mots de passe que vous pourrez retrouver facilement en cas d’oubli ou de perte.

Prenons l’exemple suivant : “Hier, ma femme est allée faire les courses.”

Maintenant gardons uniquement les initiales de cette phrase, nous obtenons alors : Hmfeaflc
C’est bien mais ce n’est pas suffisant. Un bon mot de passe contient non seulement les majuscules, des minuscules mais également des chiffres et caractères spéciaux.

Prenons le cas d’une autre phrase : “La Ciotat et Aubagne, sont deux villes !”

Effectuons la même opération mais gardons la ponctuation. Nous pouvons également remplacer le mot « deux » par le chiffre équivalent et le mot « et » par le signe correspondant ce qui donne :
La Ciotat et Aubagne, sont deux villes ! -> LC&A,s2v!

Voilà qui est mieux, ce mot de passe sera assez solide pour la plupart des utilisations et restera assez simple à retenir grâce à la phrase mnémonique.

Cette méthode est efficace mais il faut arriver à un mot de passe d’un minimum de 8 caractères.

II] La méthode par substitution

Cette méthode qui fait partie des plus simple, est pourtant l’une des plus efficace. Il suffit d’apprendre par coeur une chaîne de caratères comme par exemple « !*+._& ».

Ensuite d’appliquer sur un mot cette chaîne, soit en intercalant après chaque lettre un caractère de la chaîne soit en remplaçant par ex une lettre sur deux par la dite chaîne.

Par exemple le mot Digital4 peut devenir :

Digital4 –> !D*i+g.i_t&a!l*4 ou encore Digital4 –> D!g*t+l.

Libre à vous d’utiliser les variantes que vous souhaitez en ayant une préférence pour l’utilisation combinée des caractères spéciaux, chiffres, majuscules et minuscules au sein d’un même mot de passe.

III] Autres méthodes

On pourrait écrire des centaines de pages sur la fabrication de mots de passe surs, des techniques les plus simples aux plus sophistiquées. N’hésitez pas à inventer votre propre méthode : celle qui vous conviendra le mieux. Mais n’oubliez jamais les règles essentielles énoncées plus haut :

- Un mot de passe est TOP SECRET
- Il ne doit en aucun cas être un mot réel
- Il doit comporter un minimum de 8 caractères

Il doit être composé de lettres minuscules et majuscules, de chiffres et de caractères spéciaux.

IV] Optimiser la sécurité

Bien que le mot de passe représente un maillon parmi les plus importants de la chaîne « sécuritaire », un bon mot de passe n’est évidement pas suffisant pour protéger efficacement ses données. Afin qu’une stratégie de mot de passe soit efficace il faut :

- Ne jamais faire transiter le mot de passe en clair sur le réseau
- Etre sûr que l’on s’adresse bien au bon système d’information
- Etre attentif au moindre message d’alerte et/ou avertissement (ex ssh/ssl)
- Que la sécurité de la machine sur laquelle est tapé le mot de passe soit garantie
- Utiliser un système de cryptage sur les couches concernées afin d’éviter tout risque d’hijacking (vol de session sans besoin du mot de passe).

Certains prétendent également que le mot de passe est une technique révolue face aux divers autres types d’authentification existants (pki, biométrie, systèmes jetables, etc…). Je leur répondrai tout d’abord que la vocation de ces techniques est différente, et qu’il ne faut pas confondre identification et authentification. De plus les tests d’intrusion que j’effectue au quotidien montrent le contraire : si le remplacement de l’authentification classique par un système d’identification biométrique par ex peut dérouter un pirate, il n’est en rien plus sécurisé qu’un simple login/pass, notamment à cause du maillon faible que représentent souvent les systèmes d’authentification alternatifs et centralisés.

Share/Save/Bookmark

MySQL : quelques rappels et astuces en cas de problèmes.

Tuesday, December 26th, 2006

Comment faire un backup de toutes les bases MySQL d’un serveur ?

Pour effectuer une sauvegarder locale il vous suffit de taper : mysqldump -u utilisateur_autorisé –password=mot_de_passe –all-databases > backup.sql

Vous pouvez également compresser votre sauvegarde à la volée : mysqldump -u utilisateur_autorisé –password=mot_de_passe –all-databases > backup.sql | gzip>backup.sql.gz

Enfin si vous avez plusieurs machines, vous pouvez également sauvegarder votre base à distance :

Depuis le serveur de sauvegarde : mysqldump -u utilisateur_autorisé –password=mot_de_passe –all-databases –host=serveur_sql > backup.sql | gzip>backup.sql.gz
Depuis le serveur MySQL : mysqldump -u utlisateur_autorisé –password=mot_de_passe –all-databases | gzip | ssh root@serveur_backup “cat > /home/backup/backup.sql.gz”

Il est également possible d’effectuer un backup “binaire” de vos bases de données. Si ces dernières ont une taille très importante, ce type de backup peut représenter certains avantages, comme la rapidité de la sauvegarde :

1) il faut tout d’abord mettre les requêtes en cours en attente.
mysql -u root -p
>FLUSH TABLES WITH READ LOCK ;

Dans un autre term, vous pouvez alors faire une sauvegarde binaire de vos bases de données :
tar cvfz /home/backup/backup_sql.tar.gz /var/lib/mysql

Vous pouvez également comme dans les cas cités plus haut, l’envoyer directement sur un serveur distant :
tar cvfz /home/backup/backup_sql.tar.gz /var/lib/mysql | ssh root@serveur_backup “cat > /home/backup/backup_sql.tar.gz”

Revenez ensuite au premier term et libérez les requêtes :
>UNLOCK TABLES;

Vous pouvez également effectuer la même opération en arrêtant la base, puis en la redémarrant une fois l’opération effectuée :
/etc/rc.d/init.d/mysql stop
/etc/rc.d/init.d/mysql start

Comment vérifier et réparer une base MySQL ?

Il existe 2 grandes méthodes pour vérifier et réparer une base de données MySQL. La première consiste à utiliser la commande “mysqlcheck” :

mysqlcheck tbase -p : va vérifier la base “tbase”
mysqlcheck –all-databases -p : va vérifier toutes les bases installées
mysqlcheck –auto-repair –all-databases -p : va vérifier puis réparer automatiquement les erreurs détectées sur les différentes bases

Pour plus d’informations : mysqlcheck –help

La seconde methode est d’utiliser “myisamchk”. Contrairement à mysqlcheck, myisamchk n’a pas besoin que MySQL tourne pour fonctionner : il va directement analyser les tables depuis leur forme binaire dans le répertoire /var/lib/mysql/toto/bla.MYI. Exemple :

myisamchk -i -o /var/lib/mysql/toto/bla.MYI -> va vérifier et réparer la table “bla” de la base “toto”.

Pour plus d’informations : myisamchk –help

Comment réinjecter un dump MySQL en ligne de commande ?

Pour réinjecter un fichier .sql, il existe 2 méthodes possibles :

1) Utiliser phpMyAdmin
2) Utiliser la commande mysql

Si le fichier s’appelle sauvegarde.sql, vous pouvez la réinjecter directement en ligne de commande, sans passer par phpMyAdmin avec la commande suivante :

mysql -u utilisateur -p –database=nom_de_la_base

Share/Save/Bookmark