Born to be wired

 Du matos qui traîne ? Recyclez-le en serveur de sauvegardes !

Je ne l’ai jamais caché à personne : je suis un grand parano rongé par une obsession inaltérable au sujet de la sauvegarde de données. Mon esprit ne connait le repos qu’après avoir obtenu la certitude que mes données informatiques les plus sensibles, résultat d’années de travail acharné, ne risquent pas d’être perdues.

Mon pire cauchemar ? Passer le reste de ma vie dans une prison turque. Mon pire cauchemar en seconde position ? Perdre mes données informatiques à cause d’un crash disque dur ou SSD.

J’ai donc décidé d’œuvrer à la prévention de mon pire cauchemar n°2. Jusqu’alors, je procédais déjà à la sauvegarde de données locale, c’est à dire sur le même disque. Cela permet de revenir quelques jours en arrière si des fichiers sont supprimés ou si une modification sur ceux-ci rendent mon système instable, mais cela ne sauvera pas mes précieuses données si le disque dur termine sa vie prématurément. La dernière fois, mon disque dur m’avait clairement montré des signes de fatigue avant-coureurs et j’avais pu transférer mes données sur un autre support in extremis, mais cette chance ne se présentera peut-être pas à chaque fois.

Pour lutter contre la perte de données massive, plusieurs solutions sont offertes. J’en liste ici quelques unes sans entrer dans le détail de leurs différences. Je me concentre uniquement sur une analyse succincte orientée selon mes propres critères (sécurité forte, coût faible) :

  • RAID matériel : comme son nom l’indique, fait appel à une carte contrôleur RAID dédiée. Financièrement pas donné. La récupération de l’array en cas de perte du contrôleur demande l’utilisation d’un contrôleur du même type. En ce qui me concerne, cette solution est rédhibitoire car trop onéreuse et pas adaptée à mon mini-boitier.
  • RAID semi-matériel : aussi appelé fake-RAID, fait appel à un chipset intégré sur la carte-même. Abordable financièrement. La récupération de l’array en cas de perte de la carte-mère demande l’utilisation d’une carte mère avec un chipset identique, en croisant les doigts. En ce qui me concerne, c’est estampillé FBI (Fausse Bonne Idée) : je n’aime pas jouer la récupération de mes données sensibles à la loterie.
  • RAID logiciel : géré par l’OS. Sans impact financier, sauf si vous aimez payer pour utiliser des solutions libres (c’est votre droit). La récupération de l’array est transparente en cas de perte de la carte mère.
  • Synchro de données à distance : géré logiciellement, consiste à transférer les données à sauvegarder sur une autre machine. Impact financier léger, peut être mis en place avec du matériel de récup’. La récupération de données en cas de crash disque se fait par une synchro ou une copie dans l’autre sens.

On le comprendra aisément, les 2 dernières solutions sont celles qui m’intéressent le plus. Le RAID logiciel peut être mis en place très facilement sous Linux avec les noyaux actuels, mais il s’agit d’une solution que je vais laisser de côté pour le moment. Je vais dans cet article me concentrer uniquement sur la dernière solution : elle permet d’établir la sauvegarde sur une machine différente, ce qui peut s’avérer utile en termes de sécurisation si l’intégralité de la machine d’origine est frappée par un coup du sort (par exemple : surtension, surchauffe). De plus la synchronisation de données permet d’introduire une notion d’intervalle temporel entre 2 sauvegardes, ce qui peut permettre si on le souhaite de revenir en arrière suite à une fausse manipulation. Cet intervalle temporel est toujours à double tranchant, car si une sauvegarde est restaurée à partir des données distantes, on prend le risque de restaurer des données légèrement obsolètes, et de perdre quelques jours de travail par ce biais. Rien n’empêchera de « blinder » cette solution en ajoutant un RAID-1 logiciel par la suite.

Au final, le but de l’opération décrite dans cet article est le suivant : sauvegarder le contenu important de la mémoire de stockage de mon  serveur, en l’expédiant de manière asynchrone à travers le réseau. Un peu comme Conrad dans Flashback, en somme.

flashback-memory-backup-to-ian

 (Ouais, j’avoue, j’avais envie de sortir une référence geek et vintage)

Rassemblement du matériel

J’ai toujours un peu de vieux matériel à proximité, cela constitue des éléments de choix pour mon serveur de sauvegarde. Pas besoin d’un foudre de guerre, j’ai commencé par assembler ce que j’avais de fonctionnel sous la main, avec pour objectif de monter un PC de faible largeur afin qu’il puisse être positionné au fond d’un placard à côté de mon installation VDI. En massacrant un vieux boitier cabossé pour n’en retenir que la plaque de support carte-mère et quelques morceaux de métal alentours, je suis arrivé à ça :

Assemblage déstructuré et compacté des composants informatiques vieillots (Pentium de première génération)

Assemblage déstructuré et compacté des composants informatiques vieillots (Pentium de première génération)

Avec un Debian installé, sans écran, le PC consomme 31W. Évidemment, hors de question de le laisser tourner 24h/24. Le scénario de sauvegarde est le suivant :

  • Éveil du serveur de sauvegarde grâce au réseau (Wake-on-LAN)
  • Sauvegarde de données différentielle par rsync over SSH
  • Extinction du serveur de sauvegarde

Toutes ces opérations sont gérées par le serveur principal qui garde pleinement la main sur le serveur de sauvegarde.

Malheureusement, j’ai eu toutes les peines du monde à faire fonctionner le Wake-on-LAN (WoL) sur ce vieux matériel : déjà, pas de carte réseau intégrée à la carte mère. Qu’à cela ne tienne, j’en ai plein mes tiroirs. Oui mais, dans les quelques unes qui sont effectivement WoL, toutes géraient par défaut cette fonction par le port PCI, ce qui n’était pas le cas de ma carte-mère, bien trop ancienne pour cela. J’ai dû me résoudre à utiliser une carte avec gestion du WoL par cordon externe à 3 broches, dont je ne disposais pas. Quelques emplettes plus tard, je découvrais amèrement que, même avec le cordon idoine et la paramétrage adéquat dans le BIOS, il était impossible de faire fonctionner le WoL sur cette carte-mère.

Qu’à cela ne tienne, j’ai retenté l’opération sur du matériel plus récent : Athlon XP 2200+, 512 Mo de RAM, disque dur de 120 Go. Je remercie d’ailleurs Doudou et Flo pour leurs dons, car grâce à eux le matériel informatique suit la loi de Lavoisier : rien ne se perd, rien ne se crée, tout se transforme.

Seconde tentative de récupération de matériel divers (Athlon XP)

Seconde tentative de récupération de matériel divers (Athlon XP)

Au passage, mon projet gagnant en maturité avec le temps, j’ai préféré investir dans un boitier slim afin de préserver la faible largeur initialement désirée, en assurant une protection aux composants informatiques.

Préparation au montage du matériel de récup' dans un beau et mince boîtier neuf

Préparation au montage du matériel de récup’ dans un beau et mince boîtier neuf

Les composants informatiques de récup’ sont positionnés dans le boitier. On remarque la position inhabituelle du bloc d’alimentation, contribuant pleinement à la faible épaisseur du boîtier.

Composants assemblés, prêts à servir

Composants assemblés, prêts à servir

Le PC, une fois entièrement monté ressemble à ça :

Serveur de sauvegarde assemblé

Serveur de sauvegarde assemblé

Comment la magie opère

Afin d’expliquer grossièrement l’assemblage des différentes étapes de ma sauvegarde, je vais focaliser le discours sur le système de stockage du serveur de sauvegardes, puis élargir peu à peu en parlant des couches additionnelles qui donnent au final les scripts utilisés sur le serveur principal, qui contient les données à sauvegarder.

Je préfère prévenir, on va parler technique. Encore plus qu’avant.

Le serveur de sauvegardes est donc architecturé de la manière suivante : une partition est réservée à l’OS (Debian), et une seconde partition, chiffrée avec LUKS (cryptsetup) afin de préserver un minimum de sécurité, est réservée pour mes données sauvegardées.

L’accès à la partition de sauvegarde chiffrée est effectué comme suit : la clé de déchiffrement est poussée par le serveur principal dans la mémoire du serveur de sauvegarde (copie par SSH d’un fichier dans /run, qui est un filesystem monté en mémoire). Le déchiffrement/montage est demandé en utilisant ce fichier, puis celui-ci est immédiatement supprimé du serveur de sauvegarde. L’accès à la partition déchiffrée est alors possible pour la sauvegarde. Une fois celle-ci effectuée, la partition est démontée. Il y a probablement plus sécurisé (et plus tordu), mais c’est déjà pas mal. Je ne détaille volontairement pas la création d’un container LUKS, des centaines d’exemples fourmillent déjà sur le net. Simplement, si je peux me permettre un conseil supplémentaire : comme tout bon parano de la sauvegarde, détenir une copie de la clé du container chiffré sur un support externe, bien caché, ne sera pas du luxe. Il est idiot et ironique de s’évertuer à chiffrer des données de sauvegarde si le seul support de stockage de la clé est justement le système que l’on souhaitera restaurer le jour où celui-ci sera corrompu au point d’être incapable de relire correctement cette seule copie de la clé qui pourrait le sauver de la destruction ! Ça rendrait les choses légèrement foutraques au moment de la restauration. Un peu comme Doug Quaid dans Total Recall, en somme.

rekall

Je m’égare un peu. On va donc passer à la sauvegarde en elle-même. Très simplement, elle est effectuée par une copie différentielle des fichiers, de manière incrémentale, grâce à rsync. Ne sont donc transférées sur le réseau que le fichiers qui ont été modifiés depuis la dernière sauvegarde. Et c’est diablement efficace.

Toutes les commandes destinées au serveur de sauvegarde (comme par exemple le montage de la partition chiffrée), ainsi que le transfert des données, sont effectuées via SSH avec authentification par certificat. Ni les commandes ni les données ne circulent en clair sur le réseau. La création d’un couple de clés publique/privée et sa distribution fait partie des étapes préparatoires nécessaires. Je ne détaille pas non plus la création de ces clés asymétriques, le net regorge encore une fois de milliers d’exemples.

Pour démarrer mon serveur de sauvegarde à distance par le réseau, j’utilise l’outil wakeonlan, inclus dans le package Debian du même nom. Ayant un serveur DHCP à disposition avec adressage IP statique basé sur l’adresse MAC, mes scripts récupèrent l’adresse MAC à utiliser pour wakeonlan par extraction du fichier de configuration du serveur DHCP. Mais on pourrait faire plus simple en renseignant l’adresse MAC en dur dans le script ou dans son fichier de configuration. Afin que le serveur de sauvegarde accepte les demandes WoL, ce qui n’est pas automatique avec Linux même si cela est configuré dans le BIOS, l’outil ethtool demande l’activation du WoL sur l’interface réseau dès que le module est chargé, et dès que l’interface passe en up ou down.

Enfin, un ensemble de scripts sur le serveur principal se charge d’automatiser l’ensemble de ces actions dans le bon ordre. La sauvegarde différentielle peut donc être planifiée à loisirs. Ces scripts sont laissés à libre disposition sous le nom backup-rsync-remote dans la section téléchargements. Notez que j’ai volontairement modifié les noms de machines, chemins de fichiers, mots de passe, et clés de sécurité. Notez également que ces scripts sont fournis tels quels et sont avant tout à utiliser comme base de travail, ils ne peuvent pas être utilisés ni considérés fonctionnels tels quels sans un minimum de préparation, voire de customisation, sur les machines ciblées (notamment : dépendances de packages, mise en place de la partition chiffrée, des certificats SSH, du serveur DHCP…). À titre indicatif, mes deux machines sont en Debian 7.8.

Conclusion

Le principe exposé ici constitue selon moi une méthode peu habituelle mais non dénuée d’intérêt pour sauvegarder ses données, qui est applicable pour tout lapin de Pâques soucieux de ne pas conserver tous ses œufs dans le même panier (j’espère que vous apprécierez la métaphore et la presque-synchro avec le calendrier). Cette méthode a ses limites, et bien qu’elle n’aidera en rien à récupérer mes données en cas d’incendie à mon domicile, elle présente les avantages de la conservation de données délocalisée et plutôt correcte en termes de sécurité. Pour la prévention contre l’incendie, je privilégie la sauvegarde annuelle sur support externe et le stockage de ce support dans un petit coffre ignifugé brocanté, lui-même entreposé chez une personne de confiance 🙂

Du coup, c’est tout pour aujourd’hui. Dans mon prochain article, on aménagera un espace de choix, adapté et discret, pour ce serveur de sauvegarde qui remplit déjà parfaitement son rôle.

 Un commentaire pour “Du matos qui traîne ? Recyclez-le en serveur de sauvegardes !”

  1.  Fabrication d’un capot pour installation VDI :: www. AlphaK .net

    […] www. AlphaK .net – News Born to be wired « Du matos qui traîne ? Recyclez-le en serveur de sauvegardes ! […]

 Laisser un commentaire