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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
