Restorer un serveur physique sous Linux
Bonjour à tous, Il parait qu'il n'y a pas de question bête, donc je pose une question basique pour m'éviter de faire une vraie bêtise. Dans le cadre d'une mise en place de DRP (Disaster Recovery Plan), je voudrais savoir ce qu'il existe comme options pour backup/restore un serveur physique sous SLES 11 (SuSE Linux Enterprise Server). On peut toujours faire du CloneZilla s'il le faut, je sais que ça marche. Mais arrêter complètement un serveur de prod physique (forcément un peu central) pour un backup qui se voudrait régulier n'est pas très enchanteur. Je ne connais pas trop ce qui se fait en terme de backup "à chaud". Google m'a vite suggéré Rear ou MondoRescue (je vais les essayer). D'autres suggestions ? Des choses à faire/ne pas faire ? Des pièges de débutants à surveiller de près ? Merci à vous :) -- Magané DUREAU
Le 25/03/2016 11:52, Magané Dureau a écrit :
Bonjour à tous,
Il parait qu'il n'y a pas de question bête, donc je pose une question basique pour m'éviter de faire une vraie bêtise.
Dans le cadre d'une mise en place de DRP (Disaster Recovery Plan), je voudrais savoir ce qu'il existe comme options pour backup/restore un serveur physique sous SLES 11 (SuSE Linux Enterprise Server).
On peut toujours faire du CloneZilla s'il le faut, je sais que ça marche. Mais arrêter complètement un serveur de prod physique (forcément un peu central) pour un backup qui se voudrait régulier n'est pas très enchanteur. Je ne connais pas trop ce qui se fait en terme de backup "à chaud".
Google m'a vite suggéré Rear ou MondoRescue (je vais les essayer). D'autres suggestions ? Des choses à faire/ne pas faire ? Des pièges de débutants à surveiller de près ?
Merci à vous :)
--
Magané DUREAU
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Tout dépend du cadre exact du DRP (ou PRA en français :-) ): localisation physique et disponibilité du serveur de secours, temps accordé pour la remise en production, etc. Une solution peut être d'avoir un serveur "banalisé" à jour de tous les paquets "système" et d'utiliser un gestionnaire de configuration de type "ansible" ou "puppet" pour maintenir la cohérence de configuration. Toute modification de configuration du serveur étant, au choix porté instantanément sur le serveur de secours ou bien appliquée au moment du déclenchement du PRA. En cas de déclenchement du PRA, la reprise est quasi instantanée en basculant sur le réseau de secours. Si une solution dégradée est envisageable, pourquoi ne pas utiliser un serveur virtuel, qui prendrait le relais jusqu'à ce que le serveur principal soit rétabli? Au niveau des bon comportements et pièges à éviter: - Toujours, toujours TESTER le DRP/PRA en situation contrôlée, c'est indispensable et répéter l'exercice aussi souvent que possible et de manière aussi proche de la réalité que possible. Ça perturbe certes la production mais le jour où le DRP/PRA sera nécessaire, tu seras sûr de son fonctionnement et les équipes seront "rodées" à la "manœuvre". - Le Plan de Reprise doit être écrit, validé et connu de tous les intervenants, chaque étape décrite en détail et il doit exister des solutions de secours. D'expérience personnelle, j'ai connu un PRA (en test, heureusement) qui a mal fini... Parce que la personne qui devait apporter les bandes de sauvegardes/restauration n'avait pas les clefs des salles de secours... - Une vérification draconienne des sauvegardes doit absolument être faite très régulièrement, ainsi que de la cohésion des configurations entre le serveur et son secours. -- David
Le 25/03/2016 11:52, Magané Dureau a écrit :
Bonjour à tous,
Il parait qu'il n'y a pas de question bête, donc je pose une question basique pour m'éviter de faire une vraie bêtise.
Dans le cadre d'une mise en place de DRP (Disaster Recovery Plan), je voudrais savoir ce qu'il existe comme options pour backup/restore un serveur physique sous SLES 11 (SuSE Linux Enterprise Server).
On peut toujours faire du CloneZilla s'il le faut, je sais que ça marche. Mais arrêter complètement un serveur de prod physique (forcément un peu central) pour un backup qui se voudrait régulier n'est pas très enchanteur. Je ne connais pas trop ce qui se fait en terme de backup "à chaud".
Google m'a vite suggéré Rear ou MondoRescue (je vais les essayer). D'autres suggestions ? Des choses à faire/ne pas faire ? Des pièges de débutants à surveiller de près ?
Il est possible de restaurer un système linux uniquement à partir d'une sauvegarde de l'arborescence, je l'ai fait il y a quelques mois après avoir flingué un serveur CentOS physique. Pour faire une sauvegarde du système «à chaud», tu peux utiliser des outils très classiques et communs à toutes les distributions comme dump ou tar (fsarchiver à l'air bien mais n'est peut-être pas dispo dans toutes les distribs). Si tu veux avoir une sauvegarde cohérente (pas de fichiers qui bougent pendant la sauvegarde), il suffit de figer les systèmes de fichiers avec un snapshot LVM. Cependant, il faut mettre dans la balance le temps nécessaire et la facilité à restaurer le système à partir de la sauvegarde. Des fois il est plus rapide de faire une ré-installation + re-configuration automatisée de l'OS, plutôt que de restaurer depuis un dump. Si le serveur SuSe utilise uniquement des paquets classiques de la distribution et une configuration standard, il vaut peut-être mieux te focaliser sur la sauvegarde de la configuration et un moyen de faire une ré-installation automatique (et oublier la sauvegarde de l'OS). Si c'est un serveur qui utilise beaucoup de logiciels propriétaires, très longs à ré-installer et à re-configurer alors peut-être que la méthode dump/image du système complet sera plus simple. Moi j'ai pendant longtemps cumulé la sauvegarde de l'arborescence système et des données et je suis en train de faire machine arrière : il faut mieux se focaliser sur les données qui sont précieuses plutôt que les 50.000 fichiers installés de base dans le répertoire /usr/share. Nicolas
On 25/03/2016 16:27, Nicolas C. wrote:
Moi j'ai pendant longtemps cumulé la sauvegarde de l'arborescence système et des données et je suis en train de faire machine arrière : il faut mieux se focaliser sur les données qui sont précieuses plutôt que les 50.000 fichiers installés de base dans le répertoire /usr/share. Exactement Je fais pareil, configuration homogène, et conservation des configurations Il est tellement plus rapide d'installer une machine via des outils automatique, puis d'ensuite copier /home /root /etc, que de rsync tout le système ..
M'enfin, chez moi, c'est plus rapide :)
Nicolas _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Le 03/25/16 11:52, Magané Dureau a écrit :
Bonjour à tous,
Il parait qu'il n'y a pas de question bête, donc je pose une question basique pour m'éviter de faire une vraie bêtise.
Dans le cadre d'une mise en place de DRP (Disaster Recovery Plan), je voudrais savoir ce qu'il existe comme options pour backup/restore un serveur physique sous SLES 11 (SuSE Linux Enterprise Server).
On peut toujours faire du CloneZilla s'il le faut, je sais que ça marche. Mais arrêter complètement un serveur de prod physique (forcément un peu central) pour un backup qui se voudrait régulier n'est pas très enchanteur. Je ne connais pas trop ce qui se fait en terme de backup "à chaud".
Google m'a vite suggéré Rear ou MondoRescue (je vais les essayer). D'autres suggestions ? Des choses à faire/ne pas faire ? Des pièges de débutants à surveiller de près ?
Au début sur unix, il y avait (ufs)dump, cpio, tar. Restorer l'OS consiste au plus gros à restorer les fichiers ET les droits. Sauf qu'il y a quelques pièges comme: le boot loader, le partitionnement. Je te conseil fortement de t'exercer avec ces outils, même si tu ne les utilisent pas au final: c'est très formateur et à mon avis totalement indispensable à un administrateur unix. Exerce toi (indispensable) sur un serveur de test de restauration, écrit un script pour faire cela. (1 à 3j de travail en fonction de ton niveau) Dans la veine "produit payant qui fait des images", il y Acronis TrueImage qui fait des versions linux (je n'ai pratiqué que sur windows, avec complète satisfaction) C'est la solution facile et tentante, attention à la tentation :-) Cette solution à l'immense avantage de pouvoir être faite à chaud. Certains logiciels de sauvegarde chère (genre 100K€) te fournissent du "bare metal restore", j'ai eu des expériences contrasté avec ces produits. Pour le "à chaud", il y a les snapshots: lvm snapshot, btrfs snapshot, zfs snapshot qui te permettrons d'effectuer des photographies *atomique* de tes disques/filesysteme et donc de sauvegarder des base de donnée. Cela demande une préparation du serveur (éventuellement une re-installation) mais constitue pour moi un préalable totalement indispensable en milieux pro ( mis en oeuvre sur tout mes serveur pro ( et pas-pro)) Tu peux envisager des changement plus lourd: serveur NFS, SAN, duplication de disque au fils de l'eau, mirror iscsi, drdb... Cela demande des connaissance plus pointus ( mais comme j'y arrive, ca doit rester dans le humain normal ;-) ) Ce qui te permettra d'avoir 2 sites a jours/presque a jours Difficile de te conseiller plus sans connaître le contexte plus précisément. Ca c'est pour la partie purement backup & restore ( que tu DOIT tester, ne fait pas l'erreur classique :-) ) Pour la vue d'ensemble: * il faut se méfier des fameux "gestionnaire de configuration" puppet/chef & co (je ne met pas ansible dans le même sac), si ils sont utile, ils sont souvent mal compris et cela ne remplace absolument pas des restaurations ( y compris de l'OS, si si, on backup l'OS aussi, vous êtes pas à 8Go prêt) * avoir un processus d'installation automatisé des OS est un immense avantage dans les cas de PRA. Ne t'en prive pas, il te serons aussi fort utile lors de l'administration régulière. * penser aux éventuelle licence attaché au matériel précédent (qui peut être indisponible lors du PRA) * TESTER LA PROCÉDURE Cordialement. -- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
On 25 Mar 2016, at 18:06, Un <un+FRsAG@pontesprit.net> wrote:
Le 03/25/16 11:52, Magané Dureau a écrit :
Bonjour à tous,
Il parait qu'il n'y a pas de question bête, donc je pose une question basique pour m'éviter de faire une vraie bêtise.
Dans le cadre d'une mise en place de DRP (Disaster Recovery Plan), je voudrais savoir ce qu'il existe comme options pour backup/restore un serveur physique sous SLES 11 (SuSE Linux Enterprise Server).
On peut toujours faire du CloneZilla s'il le faut, je sais que ça marche. Mais arrêter complètement un serveur de prod physique (forcément un peu central) pour un backup qui se voudrait régulier n'est pas très enchanteur. Je ne connais pas trop ce qui se fait en terme de backup "à chaud".
Google m'a vite suggéré Rear ou MondoRescue (je vais les essayer). D'autres suggestions ? Des choses à faire/ne pas faire ? Des pièges de débutants à surveiller de près ?
Au début sur unix, il y avait (ufs)dump, cpio, tar. Restorer l'OS consiste au plus gros à restorer les fichiers ET les droits. Sauf qu'il y a quelques pièges comme: le boot loader, le partitionnement. Je te conseil fortement de t'exercer avec ces outils, même si tu ne les utilisent pas au final: c'est très formateur et à mon avis totalement indispensable à un administrateur unix. Exerce toi (indispensable) sur un serveur de test de restauration, écrit un script pour faire cela. (1 à 3j de travail en fonction de ton niveau)
Dans la veine "produit payant qui fait des images", il y Acronis TrueImage qui fait des versions linux (je n'ai pratiqué que sur windows, avec complète satisfaction) C'est la solution facile et tentante, attention à la tentation :-) Cette solution à l'immense avantage de pouvoir être faite à chaud.
Certains logiciels de sauvegarde chère (genre 100K€) te fournissent du "bare metal restore", j'ai eu des expériences contrasté avec ces produits.
Pour le "à chaud", il y a les snapshots: lvm snapshot, btrfs snapshot, zfs snapshot qui te permettrons d'effectuer des photographies *atomique* de tes disques/filesysteme et donc de sauvegarder des base de donnée. Cela demande une préparation du serveur (éventuellement une re-installation) mais constitue pour moi un préalable totalement indispensable en milieux pro ( mis en oeuvre sur tout mes serveur pro ( et pas-pro))
Tu peux envisager des changement plus lourd: serveur NFS, SAN, duplication de disque au fils de l'eau, mirror iscsi, drdb... Cela demande des connaissance plus pointus ( mais comme j'y arrive, ca doit rester dans le humain normal ;-) ) Ce qui te permettra d'avoir 2 sites a jours/presque a jours
Difficile de te conseiller plus sans connaître le contexte plus précisément.
Ca c'est pour la partie purement backup & restore ( que tu DOIT tester, ne fait pas l'erreur classique :-) )
Pour ma part, je préfère redéployer l’os via le système en place (foreman & Puppet) avec la configuration et restaurer les datas. Cet aspect à un avantage, c’est que la configuration doit être centralisée afin de garantir d’avoir une cohérence de l’ensemble.
Pour la vue d'ensemble: il faut se méfier des fameux "gestionnaire de configuration" puppet/chef & co (je ne met pas ansible dans le même sac), si ils sont utile, ils sont souvent mal compris et cela ne remplace absolument pas des restaurations ( y compris de l'OS, si si, on backup l'OS aussi, vous êtes pas à 8Go prêt)
Puppet et consorts non jamais eu pour vocation de faire des sauvegardes / restauration de système mais de déployer : - des fichiers configurations (templates ou spécifiques) - packages - utilisateur et groupes - gérer les services - gérer les dépendances entre tout ce petit monde Cela afin d’assurer que le tout soit : - centralisées - identiques sur certains point (dns, serveur de temps, users, sudo etc….) Mais aussi éviter les changements sauvages que certaines personnes font sans avertir les autres par le biais de mails ou de change (cf ITIL). Cependant utiliser ce genre d’outils vous oblige a une certaine rigueur pour tout mettre sous le contrôle de l’outil.
avoir un processus d'installation automatisé des OS est un immense avantage dans les cas de PRA. Ne t'en prive pas, il te serons aussi fort utile lors de l'administration régulière. penser aux éventuelle licence attaché au matériel précédent (qui peut être indisponible lors du PRA) TESTER LA PROCÉDURE
Cordialement.
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Liste de diffusion du FRsAG http://www.frsag.org/
Plusieurs question à te poser: - Combien de temps as-tu pour remonter le service en cas de déclenchement du PRA ( 10minutes, 1heure, 2 jours ) ? - Quelle est la tolérance de perte de données en terme de temps ( peux tu te permettre de 'perdre' une journée de prod, etc.. ) ? - Combien de serveurs as-tu à gérer ? - Quel type de service fait tu tourner sur ce(s) serveur(s) 'centra(l|aux)' ? - Quelle est la charge moyenne de ton/tes serveurs ? Et quelques pistes: - On ne backup pas un OS complet, on backup les data permettant de remonter le service ( qui as envie de (tar xzf|scp) une archive dont la taille est plus volumineuse que nécessaire, surtout avec des contraintes de temps ou de bande passante ? ). - On ne fait pas ses configurations OS/services à la main, même quand on est seul à gérer le parc ( qui as envie d'oublier une simple ligne dans un fichier de conf, ou de passer du temps à reconfigurer un serveur à l'identique ? ). - Zfs est stable et performant ( et les snapshosts send/receive un vrai bonheur ). - Refondre une archi pour intégrer la notion de haute disponibilité n'est pas forcément une mauvaise idée, un investissement temps/matériel certes, mais le jour ou tu en as besoin, tu es content de voir que ton backup as pris le relai automatiquement et que tu n'as juste qu'a faire du post mortem. - Certains 'services' intègrent des méchanismes de réplication et/ou backup à chaud, autant les utiliser ( DB par exemple ). - Un boot pxe qui installe un serveur en unattended pendant que tu fais autre chose, c'est carrément du bonheur aussi, surtout couplé à un outil d'autoconfiguration ( chef, ansible, puppet, ... ) qui va déployer les backups data et le code le plus récent. tu peux même ajouter de l'orchestration et regarder les outils faire pour toi. - Rsync est la pour transferer des fichiers en mode incrémental pour les besoins très simples, duplicity ou autres peuvent être interessants aussi. - Documente TOUT, afin que le jour ou tu en aie besoin, tu n'aie juste qu'à suivre une procédure validée et testée 'hors stress', tu peux même tout scripter. My 2 cents. On 03/25/2016 02:21 PM, Nicolas GORALSKI wrote:
On 25 Mar 2016, at 18:06, Un <un+FRsAG@pontesprit.net <mailto:un+FRsAG@pontesprit.net>> wrote:
Le 03/25/16 11:52, Magané Dureau a écrit :
Bonjour à tous,
Il parait qu'il n'y a pas de question bête, donc je pose une question basique pour m'éviter de faire une vraie bêtise.
Dans le cadre d'une mise en place de DRP (Disaster Recovery Plan), je voudrais savoir ce qu'il existe comme options pour backup/restore un serveur physique sous SLES 11 (SuSE Linux Enterprise Server).
On peut toujours faire du CloneZilla s'il le faut, je sais que ça marche. Mais arrêter complètement un serveur de prod physique (forcément un peu central) pour un backup qui se voudrait régulier n'est pas très enchanteur. Je ne connais pas trop ce qui se fait en terme de backup "à chaud".
Google m'a vite suggéré Rear ou MondoRescue (je vais les essayer). D'autres suggestions ? Des choses à faire/ne pas faire ? Des pièges de débutants à surveiller de près ?
Au début sur unix, il y avait (ufs)dump, cpio, tar. Restorer l'OS consiste au plus gros à restorer les fichiers ET les droits. Sauf qu'il y a quelques pièges comme: le boot loader, le partitionnement. Je te conseil fortement de t'exercer avec ces outils, même si tu ne les utilisent pas au final: c'est très formateur et à mon avis totalement indispensable à un administrateur unix. Exerce toi (indispensable) sur un serveur de test de restauration, écrit un script pour faire cela. (1 à 3j de travail en fonction de ton niveau)
Dans la veine "produit payant qui fait des images", il y Acronis TrueImage qui fait des versions linux (je n'ai pratiqué que sur windows, avec complète satisfaction) C'est la solution facile et tentante, attention à la tentation :-) Cette solution à l'immense avantage de pouvoir être faite à chaud.
Certains logiciels de sauvegarde chère (genre 100K€) te fournissent du "bare metal restore", j'ai eu des expériences contrasté avec ces produits.
Pour le "à chaud", il y a les snapshots: lvm snapshot, btrfs snapshot, zfs snapshot qui te permettrons d'effectuer des photographies *atomique* de tes disques/filesysteme et donc de sauvegarder des base de donnée. Cela demande une préparation du serveur (éventuellement une re-installation) mais constitue pour moi un préalable totalement indispensable en milieux pro ( mis en oeuvre sur tout mes serveur pro ( et pas-pro))
Tu peux envisager des changement plus lourd: serveur NFS, SAN, duplication de disque au fils de l'eau, mirror iscsi, drdb... Cela demande des connaissance plus pointus ( mais comme j'y arrive, ca doit rester dans le humain normal ;-) ) Ce qui te permettra d'avoir 2 sites a jours/presque a jours
Difficile de te conseiller plus sans connaître le contexte plus précisément.
Ca c'est pour la partie purement backup & restore ( que tu DOIT tester, ne fait pas l'erreur classique :-) )
Pour ma part, je préfère redéployer l’os via le système en place (foreman & Puppet) avec la configuration et restaurer les datas. Cet aspect à un avantage, c’est que la configuration doit être centralisée afin de garantir d’avoir une cohérence de l’ensemble.
+1
Pour la vue d'ensemble:
* il faut se méfier des fameux "gestionnaire de configuration" puppet/chef & co (je ne met pas ansible dans le même sac), si ils sont utile, ils sont souvent mal compris et cela ne remplace absolument pas des restaurations ( y compris de l'OS, si si, on backup l'OS aussi, vous êtes pas à 8Go prêt)
Puppet et consorts non jamais eu pour vocation de faire des sauvegardes / restauration de système mais de déployer : - des fichiers configurations (templates ou spécifiques) - packages - utilisateur et groupes - gérer les services - gérer les dépendances entre tout ce petit monde
Cela afin d’assurer que le tout soit : - centralisées - identiques sur certains point (dns, serveur de temps, users, sudo etc….)
Mais aussi éviter les changements sauvages que certaines personnes font sans avertir les autres par le biais de mails ou de change (cf ITIL).
Cependant utiliser ce genre d’outils vous oblige a une certaine rigueur pour tout mettre sous le contrôle de l’outil.
+1 idem sur le paragraphe.
* avoir un processus d'installation automatisé des OS est un immense avantage dans les cas de PRA. Ne t'en prive pas, il te serons aussi fort utile lors de l'administration régulière. * penser aux éventuelle licence attaché au matériel précédent (qui peut être indisponible lors du PRA) * TESTER LA PROCÉDURE
Cordialement.
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
Au début sur unix, il y avait (ufs)dump, cpio, tar. Restorer l'OS consiste au plus gros à restorer les fichiers ET les droits. Sauf qu'il y a quelques pièges comme: le boot loader, le partitionnement. Je te conseil fortement de t'exercer avec ces outils, même si tu ne les utilisent pas au final: c'est très formateur et à mon avis totalement indispensable à un administrateur unix. Exerce toi (indispensable) sur un serveur de test de restauration, écrit un script pour faire cela. (1 à 3j de travail en fonction de ton niveau)
Et en plus c'est très pratique pour faire du P2V quand les outils fournis par les dev de virtu ne marchent pas. (...)
Pour ma part, je préfère redéployer l’os via le système en place (foreman & Puppet) avec la configuration et restaurer les datas. Cet aspect à un avantage, c’est que la configuration doit être centralisée afin de garantir d’avoir une cohérence de l’ensemble.
Ceci n'est possible que pour des cas où les sysadmins maitrisent à 100% le déploiement de l'infra. Hors ceci n'est pas souvent le cas quand on prends du lagacy qu'on a du mal a butter / industrialiser, donc les commandes dump/restore te permettent donc de faire un vrai sauvegarde... Xavier
Hello à tous, Merci pour vos nombreuses réponses à ma question :-) Je précise le contexte (que je n'avais pas donné) : - peu de serveurs (seulement 2) - pas d'admin sys à la maison, ce sont des gars comme moi (profil power user qui sont habituellement chez d'autres clients) qui s'occupent de ce sujet Le quick & dirty est toujours réalisable, mais si on peut faire quick sans dirty, c'est mieux. Le choix pour l'instant s'est porté sur ces 2 choses là : * copie de fichiers : rsync ou tar du filesystem ailleurs + une note du partitionnement. Si un jour on doit reconstruire l'os, on fait une fresh install de l'OS en faisant attention de refaire le partitionnement à l'identique, puis recopie des fichiers qu'on avait mit de côté. * acronis : copie du disque/volume ailleurs. Si un jour on doit reconstruire l'os, on boot sur rescue CD d'Acronis qui reconstruit à partir de l'image faite précédemment. Les premiers tests sur VM ont étés concluants sur ces 2 méthodes. Je dois encore tester ça sur un vrai serveur physique qu'on me fourni cette semaine. Le 29 mars 2016 à 13:39, Xavier Beaudouin <kiwi@oav.net> a écrit :
Hello,
Au début sur unix, il y avait (ufs)dump, cpio, tar. Restorer l'OS consiste au plus gros à restorer les fichiers ET les droits. Sauf qu'il y a quelques pièges comme: le boot loader, le partitionnement. Je te conseil fortement de t'exercer avec ces outils, même si tu ne les utilisent pas au final: c'est très formateur et à mon avis totalement indispensable à un administrateur unix. Exerce toi (indispensable) sur un serveur de test de restauration, écrit un script pour faire cela. (1 à 3j de travail en fonction de ton niveau)
Et en plus c'est très pratique pour faire du P2V quand les outils fournis par les dev de virtu ne marchent pas.
(...)
Pour ma part, je préfère redéployer l’os via le système en place (foreman & Puppet) avec la configuration et restaurer les datas. Cet aspect à un avantage, c’est que la configuration doit être centralisée afin de garantir d’avoir une cohérence de l’ensemble.
Ceci n'est possible que pour des cas où les sysadmins maitrisent à 100% le déploiement de l'infra.
Hors ceci n'est pas souvent le cas quand on prends du lagacy qu'on a du mal a butter / industrialiser, donc les commandes dump/restore te permettent donc de faire un vrai sauvegarde...
Xavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Magané DUREAU
Le Fri, 25 Mar 2016 11:52:52 +0100, Magané Dureau <m.dureau@b-a-w.com> a écrit :
Dans le cadre d'une mise en place de DRP (Disaster Recovery Plan), je voudrais savoir ce qu'il existe comme options pour backup/restore un serveur physique sous SLES 11 (SuSE Linux Enterprise Server).
Comme répondu par avant : j'use et j'abuse du dump / restore. 1) avoir un NAS avec un partage NFS disponible depuis l'ip de ton serveur primaire, secondaire 2) se noter les partitions de ton système dans un répertoire du nas 3) dump toute les semaines vers le répertoire du NAS 4) en cas de besoin : je dégaine mon Sysresccd en clef USB ou CD-RW bootable sur le système de backup a) création des partitions, formatage, mkswap de la partition swap b) mount nfs du nas c) mount de la futur partition / c) restore dedans d) Création du boot grub-install --root-directory=/media/futur_slash /dev/sda (parfois, ça ne marche pas, alors je fais un: mount --bind /dev /mnt/dev mount --bind /dev/pts /mnt/dev/pts mount --bind /sys /mnt/sys mount -t proc /proc /mnt/proc chroot /media/futur_slash /bin/bash puis à nouveau "grub-install /dev/sda " voir grub-install --force /dev/sda puis update-grub Reboot et c'est OK ;)
participants (10)
-
David -
frsag＠jack.fr.eu.org -
L.M.J -
Magané Dureau -
Manu -
Nicolas C. -
Nicolas GORALSKI -
Tristan Mahé -
Un -
Xavier Beaudouin