Bacula : sauvegarde immuable anti-ransomware sans facturation

Votre sauvegarde n'est plus la dernière ligne de défense. Elle est la première victime.

Fin mars, Bacula Systems a publié deux articles qui résument bien où en est la discussion aujourd'hui. Le premier explique pourquoi l'infrastructure de sauvegarde est une cible plus précieuse pour un attaquant qu'un compte d'administrateur de domaine, et le second pourquoi le Zero Trust s'effondre au niveau de la couche de sauvegarde. Rien de tout cela n'est une nouveauté pour les équipes de réponse aux incidents — elles le répètent depuis deux ans. Mais le fait de le voir noir sur blanc change des conversations de comité de direction qui étaient auparavant impossibles à tenir.

Quand un client nous appelle pour gérer un incident, le schéma qu'il nous décrit est presque toujours le même, à quelques variations près :

Regardez cette frise un instant. L'attaquant passe plus de jours à neutraliser la sauvegarde qu'à lancer le chiffrement lui-même. Ce n'est pas une erreur de sa part. Il sait très bien que si la sauvegarde survit, la victime ne paie pas, et toute l'opération perd son intérêt économique. C'est de la comptabilité criminelle froide.

C'est pour cela que la question "est-ce qu'on a des sauvegardes ?" ne vaut plus comme réponse à quoi que ce soit. La question vraiment utile est inconfortable : ces sauvegardes seraient-elles impossibles à détruire, même pour quelqu'un qui aurait déjà des identifiants d'administrateur sur votre réseau ? Si vous devez y réfléchir, la réponse honnête est sans doute non.

Ce que "sauvegarde immuable" veut vraiment dire

Avertissement : "sauvegarde immuable" est devenu un slogan marketing. À peu près tous les éditeurs prétendent en proposer une, et la plupart désignent des choses radicalement différentes. Soyons donc précis sur ce dont on parle ici.

Une sauvegarde est véritablement immuable quand, une fois qu'elle a été écrite, personne ne peut la modifier ni la supprimer avant l'expiration de sa rétention. Personne. Ni l'utilisateur qui l'a créée, ni votre DBA avec des identifiants valides, ni vous-même avec le compte root, ni un attaquant qui aurait déjà compromis le serveur de sauvegarde. Si l'une de ces personnes peut détruire la copie, la copie n'est pas immuable. C'est juste une sauvegarde ordinaire avec une belle étiquette dessus.

Pour obtenir cette garantie en pratique, il existe trois approches sérieuses, et Bacula les supporte toutes les trois :

La règle que de nombreux RSSI adoptent discrètement en ce moment s'appelle 3-2-1-1-0. Vous l'avez peut-être déjà croisée : trois copies, sur deux supports différents, une hors-site, une immuable, et zéro erreur lors de la vérification. Ce "1-0" est exactement ce qui a changé par rapport au classique 3-2-1 que nous avons tous connu. Avoir des copies ne suffit plus — elles doivent être inaltérables, et elles doivent être vérifiées automatiquement sans que personne n'ait à y penser. Et voici le point important : Bacula fait ces deux choses dans son cycle de fonctionnement normal. Ce n'est pas un module premium vendu à part.

Pourquoi Bacula colle si bien à ce scénario

Bacula protège des données depuis plus de vingt ans dans des banques, administrations publiques, hôpitaux, opérateurs télécom et centres de données scientifiques à l'échelle du pétaoctet. C'est probablement le logiciel de sauvegarde d'entreprise open source le plus mature qui existe, et ce n'est pas nous qui le disons — ce sont les installations qui tournent depuis les années deux mille, et ce sont les clients de l'éditeur qui lui confient leur donnée critique depuis vingt ans. La version commerciale actuelle est Bacula Enterprise 18.0.8, qui apporte des choses qui auraient semblé de la science-fiction il y a cinq ans : BGuardian pour détecter l'empoisonnement du catalogue, un tableau de bord de sécurité dans BWeb, le support natif de Microsoft 365 et Azure, un plugin Nutanix AHV, les snapshots CSI de Kubernetes.

Mais la vraie raison pour laquelle Bacula tient aussi bien face aux ransomwares modernes, ce ne sont pas les nouveaux plugins. Ce sont des choix de conception que le projet a faits il y a vingt ans et qui, avec le recul, ont très bien vieilli :

• Architecture distribuée par conception. Director, catalogue, storage daemons et clients sont tous des processus distincts. Ils peuvent vivre sur des hôtes différents, avec des identifiants différents, sur des segments réseau différents. Compromettre l'un ne donne pas accès aux autres — loin de là.
• Catalogue dans une vraie base de données. PostgreSQL ou MySQL avec leurs propres sauvegardes, leurs propres contrôles d'accès, leurs propres journaux d'audit. Vous pouvez le répliquer, le mettre derrière son propre pare-feu, le traiter comme l'actif critique qu'il est réellement. Ce n'est pas un fichier binaire perdu dans /var.
• Vérification automatique du contenu. Bacula relit périodiquement les volumes et compare les checksums. Si quelque chose a été altéré — par une main humaine, par un secteur disque défectueux, par un bug matériel bizarre — vous le savez bien avant d'avoir besoin du restore d'urgence. Ça paraît ennuyeux sur le papier, mais c'est la différence entre une frayeur et une catastrophe.
• Open source authentique, sans petits caractères. Le format des volumes est documenté. Si SIXE disparaît demain, ou si Bacula Systems disparaît, vos sauvegardes restent récupérables avec les outils open source de la communauté. Ce n'est pas quelque chose qu'on peut dire de beaucoup d'autres éditeurs.
• LTO, Object Lock et air-gap, intégrés depuis toujours. Ces mécanismes ne sont pas un ajout récent parce que les ransomwares sont devenus à la mode. Ils sont la façon naturelle d'exploiter Bacula depuis des décennies. Quand le reste du marché a redécouvert que la bande comptait à nouveau, Bacula en était déjà là depuis longtemps.

Pourquoi Bacula devient moins cher chaque année (et pas les autres)

L'écart de prix entre Bacula et les gros éditeurs propriétaires n'est pas une histoire de remise de couloir. Il tient au modèle de licensing lui-même. Veeam, Veritas NetBackup et Commvault facturent tous en fonction de la quantité de données protégées, du nombre d'hôtes, ou d'une combinaison créative des deux. Le résultat est toujours le même : quand votre entreprise grandit, votre facture de sauvegarde grandit au même rythme. Et les entreprises grandissent chaque année.

Bacula Systems, de son côté, licencie par nombre de clients et par plugins activés. Le prix reste stable même si le volume de données double. La première fois qu'un DAF prend conscience de ça dans une réunion avec nous, le silence autour de la table est assez parlant.

Et la situation se durcit de l'autre côté. Veeam a annoncé des hausses de prix de 4 à 8 % pour janvier 2025 et janvier 2026, et ce n'est que le chiffre officiel — sur les forums Veeam, certains clients rapportent des augmentations cumulées de 25 % ou plus entre 2021 et 2024, avec des renouvellements individuels à +49 %. On commence à voir dans la presse tech des comparaisons avec ce que Broadcom a fait à VMware après l'acquisition. Elles ne sont pas infondées.

Dans les migrations que nous avons menées depuis Veeam ou Veritas, l'économie annuelle de la première année se situe typiquement entre 60 % et 85 %. Le point idéal se trouve dans les environnements de taille moyenne, entre 20 et 200 To protégés — c'est là que la tarification à la capacité fait le plus mal et que Bacula brille le plus clairement. Et l'écart se creuse d'année en année, parce que votre donnée continue de grandir et que Bacula ne vous pénalise pas pour ça.

Comment concevoir un Bacula qui résiste à une attaque

Installer Bacula n'est pas la partie difficile. Concevoir un Bacula qui survit à quelqu'un qui a déjà root à l'intérieur de votre réseau — c'est là que commence la vraie ingénierie. Voici les cinq décisions d'architecture qui font la différence entre une sauvegarde qui sauve l'entreprise et une qui tombe avec elle :

1. Séparer le plan de contrôle du plan de données

Le director Bacula et son catalogue PostgreSQL ne devraient pas vivre sur le même réseau que les clients qu'ils protègent. Il faut un réseau d'administration séparé, avec ses propres règles, son propre MFA, et idéalement une architecture zero-trust appliquée aux serveurs de sauvegarde eux-mêmes. Ça paraît évident — et pourtant nous le voyons mal fait la plupart des fois que nous auditons une installation existante.

2. Au moins deux dépôts vraiment indépendants

Un dépôt rapide sur disque, ou sur Ceph avec Object Lock, pour les restores du quotidien. Et un second dépôt air-gap pour la rétention longue : bande LTO, ou un cluster Ceph physiquement isolé dans un autre site, ou les deux. La règle 3-2-1-1-0 n'est pas une suggestion optionnelle, c'est le minimum vers lequel il faut raisonnablement viser. Si votre plan de sauvegarde actuel tient dans un seul dépôt, vous avez un problème.

3. Vérification automatique. Activez-la vraiment.

Bacula permet de planifier des jobs qui relisent les volumes et comparent les checksums. Activez-les. Sérieusement. C'est la seule façon de détecter une altération, une dégradation du support, ou une erreur matérielle bizarre avant de la découvrir le pire jour possible — le jour où vous avez besoin d'un restore d'urgence. Notre recommandation habituelle est au minimum hebdomadaire, plus fréquent quand l'infrastructure le supporte.

4. Des rétentions qu'on ne peut pas raccourcir à la main

Les durées de rétention sont définies dans le director et "scellées" au moment de l'écriture sur un volume immuable. Une fois qu'un volume a été écrit sur une bande WORM ou dans un bucket Object Lock actif, il n'existe aucune console Bacula ni aucun client de base de données qui puisse réduire cette rétention. Ce volume va exister jusqu'à son expiration, point final. C'est exactement ce qui protège votre sauvegarde contre un insider malveillant ou un attaquant avec des identifiants valides.

5. Un plan de reprise écrit et réellement testé

Une sauvegarde qu'on ne restaure jamais n'existe pas. Bacula rend la partie restore plutôt agréable à opérer, mais répéter l'exercice sérieusement — avec des minutages, des responsables, des points de décision — c'est le travail de l'équipe. Chez SIXE, nous l'intégrons au Plan de Rétablissement en cas de Catastrophe du client, avec des exercices programmés au moins deux fois par an. Il n'y a pas de raccourci sur ce point.

Migrer depuis Veeam ou Veritas sans perdre un seul octet

L'objection qu'on nous fait lors du premier appel est presque toujours mot pour mot la même : "on a sept ans d'historique dans Veeam, on ne peut pas se permettre de le perdre". Et ils ont entièrement raison. Dans la banque, la santé, l'administration publique, ou tout environnement régi par le RGPD, ISO 27001, NIS2 ou des référentiels sectoriels, la rétention longue n'est pas une préférence — c'est une obligation légale. La bonne nouvelle, c'est qu'il n'y a aucune raison technique de perdre quoi que ce soit. Il suffit de concevoir la migration calmement.

Chez SIXE, nous procédons en trois phases :

1. Fenêtre de coexistence. On laisse l'ancien système tourner à pleine puissance, faisant ses sauvegardes quotidiennes comme avant. Bacula commence à protéger en parallèle. Pendant quelques semaines, vous avez une couverture double et un risque nul. Ça rassure aussi pas mal les équipes sécurité qui fronçaient les sourcils au départ.
2. Des restores réels avant d'éteindre quoi que ce soit. C'est ici qu'on gagne ou qu'on perd une migration. On ne fait pas le classique test de restore sur une VM témoin — on restaure des charges qui feraient vraiment mal si elles échouaient. Une base de données critique. Un serveur de fichiers sous contrainte réglementaire. Quand ces restores valident que la conception de Bacula couvre bien le scénario, on passe à la phase suivante. Pas avant.
3. Archive historique en lecture seule. L'historique de l'ancien système n'est pas touché. Il reste accessible aussi longtemps que votre politique de rétention l'exige, en lecture seule, comme une archive vivante. Si on vous demande un fichier de 2023 l'année prochaine, il est toujours là. Et Bacula s'occupe de tout ce qui est nouveau en parallèle.

C'est honnêtement l'un des services qu'on nous demande le plus en ce moment. Le cocktail est parfait : les hausses de prix propriétaires qui s'enchaînent chaque année, la pression nouvelle autour de la sauvegarde immuable, et la prise de conscience progressive que la sauvegarde était dans la pile "risque non traité" depuis bien trop longtemps. Si vous voulez voir le détail complet du service — SLAs, cas d'usage, exemples sectoriels — tout est là : Support technique et migration vers Bacula.

Par où commencer dès aujourd'hui

Si vous êtes arrivé jusqu'ici et que vous vous dites "il faudrait vraiment qu'on regarde notre sauvegarde de plus près", vous avez sans doute raison. Pas besoin de lancer un gros projet pour faire le premier pas. Honnêtement, ce qui est le plus utile, c'est généralement un audit court qui répond honnêtement à trois questions :

• Est-ce que mes sauvegardes sont vraiment immuables ? Si un attaquant avait des identifiants d'admin sur mon réseau maintenant, pourrait-il les détruire ?
• Sont-elles vérifiées automatiquement ? Ou est-ce que je ne saurai qu'elles sont corrompues que le jour où j'en aurai vraiment besoin ?
• Combien est-ce que je paie par To protégé par an, et à quoi ressemblera cette facture dans trois ans ?

Vous pouvez répondre aux trois avec votre équipe actuelle, sans appeler personne. Et si l'une des réponses vous met mal à l'aise, parlons-en. Sans commercial, sans slides, directement avec quelqu'un de l'équipe technique qui a déjà mis les mains dans des projets comme le vôtre.

Pour aller plus loin

• 10 erreurs d'architecture et de ROI dans l'exode post-VMware — un autre cas où le licensing propriétaire force à revoir des décisions qu'on avait laissées de côté pendant des années
• Migration de VMware vers Proxmox VE — Bacula s'intègre naturellement avec Proxmox pour une sauvegarde cohérente au niveau VM, et les deux projets vont souvent de pair
• Support technique Ceph — si votre dépôt immuable va être un Ceph avec Object Lock, c'est l'autre moitié de notre spécialité