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> 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/