Chez ITdaily, un QNAP exécutant TrueNAS fonctionne hors site en tant que copie exacte de notre serveur, prêt à prendre le relais en cas de panne. La réplication ZFS et une structure de jeux de données bien pensée garantissent que nos données ainsi que nos conteneurs continuent de fonctionner de manière quasi fluide.
Le cœur de notre infrastructure est un serveur TrueNAS auto-construit au bureau, équipé d’un processeur Intel Core i5-12600K et d’une cinquantaine de conteneurs que nous gérons via Portainer. Traefik y tourne notamment en tant que reverse proxy pour les outils devant être disponibles hors du réseau (ITdaily est hébergé par Combell). Ce serveur est le cœur battant ; s’il tombe en panne, une grande partie de nos activités numériques s’arrête.
Pour pallier ce risque, nous avons transformé un QNAP TVS-h874T en une seconde machine TrueNAS. Celle-ci est délibérément placée sur un autre site physique et fait office de miroir exact. Le matériel est comparable : le QNAP fonctionne également avec un processeur Intel de 12e génération, architecturalement presque identique à notre Intel Core i5-12600K. Cela rend les deux machines interchangeables sans avoir à se soucier de la compatibilité au niveau du processeur.
La réplication ZFS comme moteur
Le mécanisme derrière ce miroir est la réplication ZFS. Au lieu de copier des fichiers, notre serveur de bureau crée des instantanés (snapshots) de ses jeux de données à des moments fixes et n’envoie que les blocs modifiés au NAS QNAP. Cette approche incrémentielle limite le trafic de données : après la première synchronisation complète, les transferts suivants sont compacts.
ZFS fonctionne au niveau du jeu de données (dataset), et non au niveau du disque. C’est un point important, car cela signifie que la configuration RAID sous-jacente des deux machines n’a pas besoin d’être identique. Un côté peut avoir une topologie vdev différente de l’autre ; la réplication envoie simplement un flux de blocs que la machine réceptrice écrit sur son propre pool. L’intégrité des données de la copie reste ainsi garantie.
Mêmes jeux de données, mêmes chemins
L’astuce permettant non seulement aux données, mais aussi aux conteneurs de migrer de manière fluide, réside dans la structure. Portainer enregistre chaque conteneur sous forme de fichier docker-compose dans une structure de dossiers. Tant que cette structure se trouve sur un jeu de données répliqué, le QNAP dispose exactement des mêmes définitions de stack que le serveur du bureau. Nous répliquons les volumes correspondants (bases de données, configuration, médias) en tant que jeux de données distincts.
La seule condition sine qua non est que les chemins de montage soient identiques sur les deux machines. Si un conteneur au bureau tire ses données d’un certain chemin, ce même chemin doit exister sur le QNAP. Nous résolvons cela en donnant à nos jeux de données les mêmes noms et points de montage sur les deux appareils. Résultat : si vous lancez les conteneurs sur le QNAP, ils pointent vers les mêmes emplacements qu’au bureau.
Ce que nous ne répliquons justement pas
Tout ne doit pas figurer dans le miroir. Nous gardons délibérément deux composants à part : Tailscale et Portainer lui-même. Tailscale, qui assure notre réseau sécurisé entre les deux sites, conserve une identité spécifique à la machine. Si vous la répliquiez, deux appareils avec la même identité se connecteraient soudainement au réseau, entraînant des conflits.
La solution consiste à installer Tailscale et Portainer séparément sur les deux machines avant de commencer la réplication. Ainsi, chaque machine possède sa propre identité, tandis que nous ne codons que nos données réelles et nos fichiers compose. En d’autres termes, nous répliquons de manière ciblée par jeu de données, au lieu de transférer aveuglément tout le pool.
D’abord localement, puis à distance
Une copie exacte de dizaines de téraoctets ne se pompe pas simplement via une connexion internet. C’est pourquoi nous avons effectué la première synchronisation complète localement, via un réseau 10GbE rapide, avec les deux machines dans la même pièce. Ce transfert initial est de loin le plus lourd. Ensuite, les instantanés incrémentiels compacts suffisent.
Ce n’est qu’après cette première synchronisation que le QNAP a été déplacé vers son site distant. Là-bas, l’appareil n’a en principe besoin de rien d’autre que de l’électricité et d’une connexion internet. La liaison entre les deux machines passe par Tailscale, qui attribue à chaque machine une adresse fixe qui ne change pas lorsque l’emplacement physique est modifié. Par conséquent, nous n’avons presque rien eu à reconfigurer après le déménagement : la réplication reprend simplement, mais plus lentement que sur le réseau local.
Basculement en quelques étapes
Le scénario pour lequel nous construisons tout cela est le moment où le serveur du bureau tombe en panne. Les jeux de données répliqués sur le QNAP sont par défaut en lecture seule. En cas de panne, nous les passons en lecture-écriture, nous ouvrons Portainer et nous lançons les stacks. Comme les chemins sont identiques, les conteneurs redémarrent immédiatement.
Il est important de souligner qu’il ne s’agit pas d’un basculement (failover) entièrement automatique. C’est une procédure manuelle, mais rapide. Nous avons délibérément choisi de ne pas opter pour une configuration active-active où les deux sites écrivent simultanément. C’est nettement plus complexe et la réplication ZFS n’est pas l’outil approprié pour cela. Pour nos besoins, un miroir bien pensé que nous activons en quelques étapes via TrueNAS suffit.
Bonnes pratiques autour des sauvegardes
Un miroir est précieux, mais ce n’est pas en soi une stratégie de sauvegarde complète. Quiconque prend ses données au sérieux doit garder quelques principes à l’esprit.
La règle d’or la plus connue est le 3-2-1 : conservez au moins trois copies de vos données, sur deux supports différents, dont une sur un autre site. Notre QNAP hors site remplit précisément ce dernier volet crucial.
Attention toutefois à un piège : la réplication copie également vos erreurs. Si vous supprimez accidentellement un fichier ou si un ransomware chiffre vos données, ce sinistre se propage à la copie. C’est précisément pour cela que les instantanés ZFS sont si précieux : ils figent l’état à un moment donné, vous permettant de revenir à une version antérieure à l’incident. Maintenez un schéma de rétention réfléchi, avec plusieurs instantanés sur différentes périodes, et rendez-les immuables si possible.
Tout aussi essentiel, et souvent oublié : testez votre restauration. Une sauvegarde que vous n’avez jamais essayée est une supposition, pas une certitude. Effectuez périodiquement un véritable test de basculement et vérifiez que vos conteneurs et vos données démarrent effectivement. Ajoutez à cela une surveillance qui vous alerte lorsqu’une tâche de réplication échoue, afin de ne pas découvrir seulement lors d’une catastrophe que le miroir est arrêté depuis des semaines.
Enfin, il est payant que votre site hors site le soit réellement : une autre alimentation électrique, un autre réseau (et fournisseur télécom), idéalement un autre bâtiment. Un deuxième serveur placé à côté du premier vous protège contre un crash de disque, mais pas contre un incendie, un vol ou une surtension. C’est précisément cette séparation qui fait la différence entre une copie pratique et une véritable stratégie de repli.