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/