Un conteneur qui plante, ça se relance. Une base de données corrompue ou un volume effacé par erreur, ça ne se rattrape pas sans une sauvegarde. Pourtant, j’ai constaté à plusieurs reprises que la plupart des installations de Docker, la sauvegarde se résume à « ça fonctionne… ça devrait aller ». Aujourd’hui, je vous propose un petit guide, générique, qui peut s’appliquer à de nombreuses distributions Linux (Ubuntu Server, Debian, Fedora…) mais aussi sur un NAS.

Sauvegarde Docker

Un environnement Docker se décompose en 3 éléments :

• La configuration : les fichiers docker-compose.yml et .env, il ne pèse que quelques octets ;
• Les données : ce sont les volumes et bind mounts contenant les bases de données, les fichiers envoyés, les configurations d’application générées à l’exécution ;
• Les images : elles se (re)téléchargent depuis un registre, peu d’intérêt les sauvegarder (sauf retour arrière instantané).

Il est important de ne pas confondre ces catégories. Il ne sert à rien de sauvegarder l’intégralité de /var/lib/docker. Ça prend de la place pour rien et complique la restauration.

Étape 1 : Configurations de côté

Chaque stack (ou Projet Docker) repose sur des fichiers texte : docker-compose.yml, .env et parfois un Dockerfile. Ces derniers décrivent comment tout est imbriqué. Regroupez-les dans un dossier (ex : docker-configs), avec un sous-dossier par stack. Ce dossier sera ensuite inclus dans la sauvegarde automatisée (voir ci-dessous), comme les volumes de données.

Vous pouvez également mettre en place un dossier sous Git, même un simple dépôt local. Cela permettra de garder un historique des modifications et de revenir en arrière en cas d’erreur de configuration.

L’objectif, c’est de pouvoir recréer une stack entière (projet docker) en question de minutes… Sur un NAS Synology, les fichiers de configuration sont généralement logés dans /volume1/docker

Étape 2 : Identifier les volumes

Passons aux données et plus précisément leurs volumes. Pour cela, vous pouvez taper :

docker volume ls

Pour chaque volume, il faut se poser la question : s’il disparait demain, est-ce que je perds quelque chose d’irremplaçable ? Je vous recommande les dossiers utilisateurs, les bases de données (voir ci-dessous) et la configuration de votre application. Il n’est pas nécessaire de sauvegarder un cache ou des fichiers temporaires.

Pour retrouver le chemin réel d’un volume, il faut taper :

docker volume inspect <nom_du_volume>

Recherchez Mountpoint qui devrait ressembler à cela : /var/lib/docker/volumes/monVolume

Étape 3 : Choisir un outil de sauvegarde de volumes

Pour un homelab, il existe plusieurs possibilités :

• docker-volume-backup : il s’agit d’une image docker qui monte vos volumes, les archives en .tar.gz puis envoie le résultat vers un stockage local, WebDAV, Dropbox, SFTP, S3… la référence ;
• Restic ou Kopia : outils de déduplication, de chiffrement et de gestion du versioning (plusieurs points de restauration dans le temps).

Pour démarrer, docker-volume-backup suffit largement. Relativement simple, vous y mettrez les informations de chaque projet Docker et bien sûr le Mountpoint correspondant pour vos données. Restic et Kopia demandent pas mal de configuration, mais ce dernier (Kopia) dispose d’une interface graphique embarqué, ce qui peut faciliter son utilisation.

Cas particulier

Y’a toujours une exception qui confirme la règle : la base de données en fonctionnement. Si techniquement la sauvegarde avec docker-volume-backup sera OK, la base données posera des soucis lors d’une restauration.

2 solutions sont possibles :

• Dump avant archivage : pg_dump pour PostgreSQL, mysqldump pour MySQL/MariaDB génère un fichier texte (exportation brute de son contenu et de sa structure), indépendant de l’état du volume, via cron ;
• Arrêt du conteneur : plus simple à automatiser, mais implique une coupure de service temporaire pour la sauvegarde.

Dans docker-volume-backup, tout conteneur portant l’étiquette docker-volume-backup.stop-during-backup=true sera arrêté avant le lancement de la sauvegarde, puis redémarré une fois celle-ci terminée.

A noter également que de nombreuses applications (Immich, Home Assistant, Jellyfin…) proposent des systèmes de sauvegarde internes.

Étape 4 : automatiser et stocker ailleurs

Une sauvegarde qui reste sur le même disque/SSD que les données originales n’est pas une sauvegarde ! C’est une copie qui disparait avec la panne de votre PC. Dans l’idéal, il faudra créer un tâche planifié (cron) qui déclenche le script ou le conteneur de sauvegarde à intervalle régulier (une fois par jour par exemple) vers un NAS ou un autre machine distante.

Étape 5 : tester vos sauvegardes

Une erreur fréquente consiste à penser qu’une sauvegarde fonctionne… sans jamais l’avoir testée. Une sauvegarde corrompue ou incomplète, ça arrive ne sert à rien. Prenez le temps de vérifier régulièrement vos fichiers. Ouvrez-les, restaurez-les, assurez-vous qu’ils sont exploitables.

Le seul à faire, c’est reconstruire une stack/projet sur une machine vierge ou une machine virtuelle, à partir du dossier de configuration et de l’archive du/des volumes pour les données. Si l’opération échoue, alors il est nécessaire de revoir votre procédure de sauvegarde. Planifiez ce genre de test au moins une fois tous les trimestres.

Synology et Docker

Synology utilise docker à travers l’outil maison Container Station. Ce dernier fait tourner les projets (stack) directement sur le NAS dans /volume1/docker avec un sous-dossier par projet. Généralement, on y retrouve la configuration et les données côte à côte. Il est important de noter que Container Manager ne propose aucune fonction de sauvegarde.

Pour cela, il est possible d’utiliser Hyper Backup par exemple… mais vous aurez le même souci au niveau de vos bases de données.

Les Snapshots Btrfs apporteront une réponse. En effet, si le snapshot est « quasi instantané » même pendant une écriture, cela sera comparable à une coupure de courant brutale. Heureusement, les systèmes de base de données (PostgreSQL, MySQL/MariaDB) sont conçus pour se remettre de ce genre de situation grâce à des mécanismes de récupération internes. Cependant, un snapshot n’est pas une sauvegarde propre de la base de données. Pour les données importantes, je vous recommande de créer un dump. A noter que la problématique (snapshot au niveau système de fichiers/hyperviseur) reste la même pour QNAP, Asustor, Proxmox, etc.

En synthèse

Vous l’aurez compris, la sauvegarde d’un environnement Docker n’est pas forcément complexe… mais il faut faire attention. Il y a 3 grandes familles de données à sauvegarder pour un projet Docker : la configuration, les données et l’image (optionnelle). L’outil docker-volume-backup sera idéal pour la majorité des utilisateurs. Cependant, il faudra être vigilant si votre projet contient une base de données. Aussi, regardez dans vos applications favorites s’il n’existe pas un système de sauvegarde intégré

Les utilisateurs avancés regarderont du côté des applications Restic ou Kopia.

ASUSTOR a mis en ligne ADM 5.1.4. Cette mise à jour vient corriger plusieurs failles de sécurité au niveau du noyau Linux, mais aussi du côté ADM. Le fabricant a également apporté quelques améliorations. Voici ce qu’il faut retenir avant de lancer la mise à jour…

ASUSTOR ADM 5.1.4

Si on regarde le journal des modifications, cette version corrige :

• Noyau Linux : CVE-2026-46242 et CVE-2026-46331 (failles « Bad Epoll » et « pedit COW »), ainsi que CVE-2026-43499 et CVE-2026-43503 (« GhostLock » et « DirtyClone ») ;
• ADM en lui-même : 9 CVE au total réparties sur trois avis (AS-2026-018, AS-2026-019, AS-2026-020) ;
• OpenSSL : mise à jour vers la version 3.5.7 (CVE-2026-45447) ;
• FFmpeg : mise à jour vers la version 7.1.5 (CVE-2026-8461) ;
• Cifs-utils : correction de CVE-2026-46243.

Le moins que l’on puisse dire, c’est qu’Asustor prend très au sérieux les mises à jour de sécurité, même pendant la période estivale. Ces corrections valent à elle seule l’installation rapide sur votre NAS. Mais le fabricant n’en reste pas là, il ajoute également :

• Le cache SSD utilise désormais par défaut le mode lecture seule pour améliorer performance et intégrité ;
• Lors de l’initialisation du NAS, un mot de passe minimum de 8 caractères est obligatoire ;
• Le processus de mise à jour vérifiera en amont l’état SMART des disques, l’avancement de mises à niveau de volumes et demandera à l’utilisateur avant de continuer ;
• SMB3 peut être défini comme version minimale du protocole ;
• ADM Defender autorise désormais les ponts réseau Docker utilisant des noms d’interface personnalisés ;
• Correction d’un souci au niveau des archives (multifichiers) téléchargées vers le PC ;
• Diverses corrections pour l’Explorateur de fichiers, la Centrale de sauvegarde, le Gestionnaire de stockage, etc.

Pour en savoir plus, rendez-vous à cette adresse…

Mettre à jour son NAS

Vous l’aurez compris, la mise à jour est importante. Les corrections de sécurité sont nombreuses et des améliorations sont également présentes. Même si les mises à jour Asustor fonctionnent sans risque dans 99,9% des cas, il est important d’avoir une sauvegarde de ses données.

Allez sur le Panneau de configuration > Mise à jour du firmware ou directement via les notifications ADM si la mise à jour est déjà détectée. Le NAS devrait lancer automatiquement le téléchargement d’ADM, puis il ne reste plus qu’à l’appliquer… et le NAS va redémarrer automatiquement pour finaliser la procédure. Comptez entre 10 et 15 minutes…

Synology vient d’officialiser 4 nouveaux NAS pour le marché asiatique et africain : DS725neo+, DS925neo+, DS1525neo+ et DS1825neo+. Si pour le moment rien n’indique que ces modèles arriveront sur d’autres marchés, l’objectif est de proposer des NAS en adéquation avec les conditions actuelles du marché autour de la mémoire vive (RAMpocalypse). Mais plusieurs incohérences subsistent…

Synology DS725neo+, DS925neo+, DS1525neo+ et DS1825neo+

Si on devait résumer ces nouveaux produits, il s’agit des mêmes NAS DS725+, DS925+, DS1525+ et DS1825+ sortis en 2025, mais avec des différences au niveau de la RAM (mémoire vive).

Commencé par un rappel, c’est en 2020 que Synology lançait ses premiers NAS avec de la mémoire ECC (Error-Correcting Code ou en français code à correcteur d’erreurs). Or, cette mémoire ECC n’a jamais été un prérequis pour les NAS grand public. Les professionnels la recommandent sur les très gros serveurs d’entreprise, ou lors de utilisation du système de fichier ZFS. Comme indiqué précédemment, Synology avait intégré la mémoire ECC dans ses NAS non pas par nécessité, mais parce que le processeur embarqué le permettait. Et c’est un argument marketing implacable : la mémoire ECC corrige les erreurs, vous n’aurez donc jamais de données corrompues. Au passage, cela permettait également d’augmenter le prix de vente de la mémoire officielle.

Depuis, l’IA est passée par là et les besoins en mémoire (RAM et SSD) ont explosé… Les prix ont considérablement augmenté, ce qui fait que Synology est désormais dans une situation très inconfortable (y compris les autres fabricants), car il fournit des NAS prêt à l’emploi.

Heureusement que Synology n’avait pas sauté le pas vers la mémoire DDR5, car la hausse est encore plus impressionnante qu’en DDR4.

Synology DS725neo+ et DS925neo+ : même quantité de RAM

Les NAS Synology DS725+ et DS925+ sont livrés par défaut avec 4 Go de RAM DDR4 ECC. Les versions neo+ (DS725neo+ et DS925neo+) reprennent les mêmes caractéristiques, y compris la quantité de mémoire vive… à l’exception du type de mémoire. Il n’y a pas plus d’ECC ici, donc ils devraient être légèrement moins chers. Ne croyez pas pour autant qu’il s’agit d’une refonte majeure de la part de Synology, les précédents modèles étaient déjà compatibles avec la mémoire non-ECC.

Synology DS1525neo+ et DS1825neo+

Les DS1525+ et DS1825+ sont des modèles destinés à des besoins de stockage plus important… plutôt orienté petites et moyennes entreprises. C’est pour cette raison qu’ils embarquaient 8 Go de RAM DDR4 ECC. Comme pour les autres modèles neo+, les DS1525neo+ et DS1825neo+ n’ont que de la RAM DDR 4 (non-ECC) et leur quantité passe de 8 à 4 Go. On revient aux standards de RAM datant de 2018, avec un processeur déjà présent en 2020. La double peine…

En synthèse

À ce jour, rien n’indique que la gamme DSx25neo+ débarquera en Europe. Les prix n’ont pas encore été communiqués, mais rien ne laisse penser qu’il y aura une baisse important par rapport aux modèles actuels (avec ECC). L’avenir nous le dira.

À suivre…

Après avoir testé le puissant Flint 2, nous restons aujourd’hui chez GL.iNet mais avec un changement radical de format. Place au Brume 3 (GL-MT5000), une passerelle de sécurité et routeur de poche qui fait un choix audacieux : se passer totalement de Wi-Fi.

Actuellement installé, depuis 8 mois environ, comme routeur principal sur mon infrastructure, ce petit boîtier promet de concentrer toute la puissance de routage et de chiffrement VPN dans un format lilliputien. Tient-il toutes ses promesses au quotidien ? C’est ce que nous allons voir.

De bêta-testeur à routeur principal : les coulisses de mon installation

Pour la petite histoire, j’ai eu l’opportunité de participer à une sélection de profils pour devenir bêta-testeur de ce Brume 3, et mon profil a été retenu. Reçu début décembre 2025, l’appareil est arrivé accompagné d’une feuille de route bien précise : une liste d’éléments à éprouver scrupuleusement, consignée dans un fichier Excel à remplir et à renvoyer aux équipes de développement de GL.iNet.

Au départ, l’intégration de ce petit routeur dans mon architecture réseau m’a laissé perplexe. Mon installation était déjà bien rôdée autour du Flint 2, qui était caché dans un caisson du meuble TV dans mon salon, pour gérer à la fois le routage et le Wi-Fi. Cette configuration m’imposait d’ailleurs une petite gymnastique de câblage : deux câbles Ethernet devaient faire l’aller-retour entre mon salon et mon sous-sol (où arrive ma box opérateur). Le premier remontait le flux Internet vers le Flint 2, tandis que le second redescendait le réseau filtré vers mon switch 2.5G principal, chargé d’arroser les NAS, les mini-PC Geekom et les prises des chambres et bureaux.

L’arrivée du Brume 3 a bousculé cette routine. Taillé pour le routage pur et nativement pensé pour le VPN, ce petit boîtier méritait logiquement de prendre la place de tête de réseau. J’ai donc sauté le pas : le Brume 3 a pris ses quartiers au sous-sol pour piloter l’infrastructure, tandis que le Flint 2 a été rétrogradé au rôle de simple point d’accès Wi-Fi (récemment installé dans mon bureau après changement de meuble TV, WAF non compatible). Ce jeu de chaises musicales m’a permis d’optimiser mon câblage dans le salon : j’ai ainsi libéré un câble réseau pour relier ma box TV directement à la Bbox du sous-sol, le second restant dédié à mon Apple TV. En clair, j’allie désormais le meilleur des deux mondes : la puissance de routage et du VPN pour le Brume 3, et la couverture Wi-Fi pour le Flint 2.

Le matériel : Un concentré de puissance sous le capot

Si le Flint 2 impressionnait par ses antennes et son volume, le Brume 3 (GL-MT5000) surprend par l’extrême inverse. C’est un boîtier compact, léger, discret, conçu pour se faire oublier dans une baie réseau ou s’isoler derrière une box opérateur avec ses petites dimensions de : 75 x 92 x 25 mm. Et pour seulement une masse de 148 g, ce routeur format mini peut se transporter facilement en voyage pour bénéficier du client VPN intégré ou pour partager une connexion mobile en filaire sur plusieurs ordinateurs.

Ayant eu la chance de participer au programme de bêta-test de l’appareil, j’avais initialement noté quelques petits défauts de jeunesse sur les finitions du boîtier. Force est de constater que GL.iNet est une marque à l’écoute de sa communauté : sur la version commerciale finale, le marquage des ports USB-C est désormais parfaitement lisible et la luminosité de la LED a été ajustée pour ne pas transformer votre bureau en boîte de nuit.

Côté caractéristiques techniques, le Brume 3 ne fait pas semblant et s’intègre parfaitement dans une topologie réseau moderne en 2,5 Gb/s pour maximiser les débits filaires. Il embarque :

• Processeur : MediaTek, Quad-core @2.0GHz (il s’agit d’un SoC performant capable d’encaisser le routage et surtout le chiffrement lourd).
• Mémoire : 1 Go de DDR4 et un eMMC de 8 Go. C’est une configuration solide en RAM (bien qu’un peu léger en quantié de RAM) et en stockage Flash pour faire tourner l’OS maison et ajouter des packages.

• Connectique :
  • 1 x port ethernet WAN en 2,5 Gb/s
  • 2 x ports Ethernet LAN en 2,5 Gb/s également (dont un qui peut servir en WAN supplémentaire)
  • 1 x port USB 3.0 Type-C
  • 1 x port USB Type-C d’alimentation (uniquelent) en 5V/3A
  • 1 x bouton reset

Ce brume 3 possèdes des ports à la hauteur de nos exigences actuelles (bien qu’un port LAN ou deux supplémentaires n’auraient pas été de refus), complétés par un port USB indispensable pour y coupler une clé 4G/5G en backup, ou encore y brancher un smarphone pour faire du thethering (partage de connexion), ou enfin pour y brancher un périphérique de stockage USB (clé USB, disque-dur USB…).

Contenu du colis

• 1 x Brume 3 (GL-MT5000)
• 1 x Adaptateur secteur
• 1 x Câble Ethernet
• 1 x Manuel d’utilisation
• 1 x Carte de remerciement
• 1 x Convertisseur (selon le pays de livraison)

Installation et premier démarrage

Fidèle à la réputation de la marque, la mise en route est un modèle du genre. On branche l’alimentation (via USB-C), on s’y connecte en filaire, et l’assistant nous guide à travers les premières étapes indispensables :

• Choix de la langue et définition du mot de passe administrateur.
• Détection et configuration de l’accès Internet (DHCP, PPPoE ou IP fixe).
• Mise à jour immédiate du firmware (une étape essentielle pour la sécurité).

Il existe au besoin un guide d’utilisation et de configuration disponible sur le site de GL.iNet.

Le système d’exploitation et les fonctionnalités

L’interface logicielle de GL.iNet, propulsée ici par une version stable et récente du firmware v4.9.0 (disponible depuis le 27 juillet 2026, loin de la version v4.8.4beta2 de mes premiers essais en décembre 2025), reste un modèle du genre pour concilier simplicité et fonctionnalités avancées.

Pour télécharger la dernière version du firmare manuellement plutôt que de laisser le routeur le faire, il faut aller sur le centre de téléchargement de GL.iNet (lien pour le Brume3).

L’interface GL.iNet

Le tableau de bord offre une vue claire sur l’état du réseau et des clients, il est très similaire à celui du Flint2 que j’ai testé il y a presque deux ans maintenant.

Voici quelques captures d’écrans de cette interface de gestion :

La gestion des flux : le DPI (Deep Packet Inspection)

Une nouvelle fonctionnalité introduite dans la version 4.8.4 bêta du firmware du Brume3 est la gestion des flux via le DPI (Deep Packet Inspection) avec filtrage de contenu, ainsi que la QoS (Quality of Service) et le SQM (Smart Queue Management). Le contrôle parental, quant à lui, est arrivé avec la version 4.9.

Cette nouvelle fonctionnalité avait suscité quelques craintes lors de la bêta car le DPI (Deep Packet Inspection), qui affichait initialement des mentions de « Free Trial » ou de licence à obtenir. Rassurez-vous, il n’en est rien. Cette brique d’analyse réseau est aujourd’hui totalement gratuite et disponible sans surcoût. Il est bon de noter que cette fonctionnalité est encore en version bêta et donc toujours en développement.

Techniquement, cette fonctionnalité s’appuie sur le moteur tiers Netify (nDPI) (voir la documentation à ce sujet). Ce dernier utilisant un modèle de double licence (commerciale et open-source), cela explique les lignes de code et les mentions de licence qui s’étaient glissées dans l’interface de test. C’est désormais de l’histoire ancienne, et l’outil s’avère redoutable pour identifier précisément la nature du trafic qui transite sur votre réseau.

Les fonctionnalités suivantes sont disponible à la configuration :

• Activation du contrôle de flux (documentation ici) ;
• Statistiques des données (documentation ici) ;
• Gestion des filtres de contenus (documentation ici) ;
• La gestion QoS (documentation ici) ;
• La gestion SQM (documentation ici) ;
• Et le contrôle parental (documentation ici).

AdGuard Home intégré

Comme sur les grands modèles, l’intégration native d’AdGuard Home (AdGH) permet de bloquer les publicités, les trackers et les domaines malveillants directement à la racine du réseau, sans installer la moindre extension sur vos appareils. (Ayant une instance dans un LXC dédié, j’ai activé l’application sur le routeur pour faire les captures.)

Les autres applications préinstallées

D’autres applications sont préinstallées avec le firwmare GL.iNet :

OpenWRT (LuCI) dans l’ombre

Pour les utilisateurs avancés, un simple clic permet de basculer sur l’interface LuCI classique d’OpenWRT (après l’avoir installé via un clic également). C’est ici que l’on peut configurer des règles de pare-feu complexes, des VLANs ou installer des paquets supplémentaires via opkg (la version d’Openwrt 21 sur laquelle est basée le firmware GL.iNet est vieille et est encore avec le gestionnaire de paquet opkg, c’est probablement le seul reproche que je ferais sur ce routeur).

Serveur et Client VPN : Le gros point fort

C’est précisément sur ce terrain que le Brume 3 (GL-MT5000) était attendu au tournant, d’autant plus en position de routeur principal sur une infrastructure 2,5 Gb/s. Les tests de performance brute en situation réelle avec des fournisseurs comme Windscribe et Mullvad sous le protocole WireGuard confirment la puissance de la machine.

• Mode Client VPN : Le processeur encaisse le chiffrement WireGuard sans sourciller, permettant d’exploiter d’excellents débits sans saturer le CPU du routeur. Grâce aux politiques de routage, vous décidez à la carte quelles machines (comme votre NAS ou votre PC principal) passent par le tunnel chiffré de Mullvad ou Windscribe, et lesquelles sortent en direct sur votre connexion classique.

Voici quelques résultats (benchmarks) fait lors de la phase de beta-test (via mon Macbook Air M2 avec un adaptateur USB-TJ45 Asustor AS-U2.5G2) :

Ces résultats sont vraiment très bons compte tenu que ma connexion internet est à 2000 Mbps en téléchargement et 900 Mbps en envoi.

• Mode Serveur VPN : Idéal pour configurer un accès distant sécurisé vers votre domicile. Même à l’extérieur, vous vous connectez en WireGuard sur le Brume 3 et vous accédez à vos services locaux à pleine vitesse. Je n’ai pas pu réaliser de benchmarks car je n’ai jamais pu avoir une connexion en dehors de chez moi assez rapide pour que le test ait une vraie valeur. Mais en ce qui me concerne, j’utilise quasi quotidiennement la connexion wireguard sur mon brume3, surtout en 4G/5G. J’ai également le serveur OpenVPN en secours.

Performances et Consommation électrique

N’ayant pas de Wi-Fi à tester, l’accent a été mis sur les capacités de routage pur et la tenue en charge des tunnels chiffrés.

• Débits et Stabilité : En routage classique, le Brume 3 sature les liaisons sans ciller. Lors des transferts intensifs à travers le tunnel WireGuard, le processeur encaisse la charge sans montrer de signes de faiblesse ni provoquer de latence sur le reste du réseau.
• Consommation et Température : Le boîtier chauffe modérément en charge intensive. Côté consommation, elle reste dérisoire par rapport à un routeur classique ou un mini-PC, ce qui en fait un excellent candidat pour tourner H24 sans impacter la facture d’électricité.

Fin décembre 2025, CachyOS annonçait travailler sur une « Server Edition » destinée aux NAS, aux stations de travail et aux environnements serveurs. L’idée derrière cette annonce était une image vérifiée, à configuration durcie et aux paquets optimisés… tout ce qui a fait le succès de CachyOS dans le gaming. Depuis, plus aucune information.

CachyOS Server Edition

Pour ceux qui ne connaissent pas encore CachyOS, il s’agit d’une distribution Linux basée sur Arch, qui s’est fait un nom ces dernières années dans le monde du gaming et PC haute performance. Son argument principal : des optimisations poussées au niveau du noyau et de la compilation (PGO, AutoFDO), un support soigné des dernières générations de GPU et une bonne intégration de Proton pour faire tourner les jeux Windows. Une réputation qui lui a valu de devenir l’une des distributions les plus utilisées par la communauté ProtonDB…

8 mois plus tard, force est de constater qu’il n’y a pas eu de suite officielle. Les 4 dernière releases se concentrent exclusivement sur l’usage PC et gaming avec notamment le support Wayland (protocole de serveur d’affichage), un nouvel environnement Hyprland Noctalia, optimisations GCC et Python, gestion des pilotes NVIDIA… Aucune mention d’une Server Edition, d’un NAS ou même d’une feuille de route sur le sujet.

Pourtant, rien n’indique que le projet soit abandonné ! CachyOS reste une petite équipe qui priorise visiblement son cœur de cible historique, les joueurs et les utilisateurs de PC au quotidien. Mais à ce stade, il s’agit davantage d’une intention affichée que d’un projet engagé avec un calendrier.

Marché déjà bien occupé

Si CachyOS venait à fournir cette Server Edition, elle arriverait sur un terrain loin d’être vierge. Il y a déjà des acteurs installés comme OpenMediaVault, TrueNAS ou Unraid… mais aussi d’autres acteurs plus récents avec des solutions pensées spécifiquement pour le NAS DIY : FygoOS, ZimaOS et HexOS. Autant de concurrents avec une longueur d’avance sur l’expérience utilisateur dédiée au stockage, quand CachyOS partirait d’une base généraliste Arch Linux.

On garde le sujet à l’œil et on mettra à jour cet article dès qu’une information concrète émergera du côté de l’équipe CachyOS.

A suivre…

[edit] L’éditeur vient d’annoncer « l’ajout d’une prise en charge expérimentale des profils d’installation de la future Server Edition ».

Entre TinyPNG pour compresser une image, iLovePDF pour fusionner un contrat, et CloudConvert pour transformer un MOV en MP4, on finit tous par uploader nos fichiers sur une demi-douzaine de services tiers. SnapOtter part d’un principe simple : regrouper ces 200+ outils dans un seul conteneur Docker, hébergé chez vous, sans que rien ne quitte votre réseau.

SnapOtter

SnapOtter propose 5 grandes familles d’outils : image (105 outils : redimensionnement, compression, conversion, retouche, détection de doublons, photos d’identité, prise en charge de 55+ formats dont 23 RAW), vidéo (57 outils : conversion, compression, recadrage, extraction audio, stabilisation), audio (27 outils : normalisation, fade, réduction de bruit, changement de tonalité), PDF (29 outils : fusion, OCR, protection, signature) et fichiers génériques (23 outils : conversion CSV/JSON/XML/YAML, ZIP, Excel vers CSV).

Il existe un éditeur d’image par calques intégré, directement dans le navigateur, avec pinceaux, formes, courbes et raccourcis clavier… pas besoin d’ouvrir un logiciel tiers pour une retouche rapide. Ensuite, il y a également module d’IA locale : suppression d’arrière-plan, upscaling, restauration de vieilles photos, floutage de visages, OCR, transcription audio, sous-titres automatiques. Tout tourne sur votre matériel, sans connexion internet requise ! Pas mal non ?

SnapOtter permet égalementd’automatiser des actions (via un pipeline) et des modèles prêts à l’emploi. Voici quelques exemples :

• Peaufiner un podcast : Supprime les silences, normalise le volume et ajoute des fondus à un enregistrement ;
• Restaurer une ancienne photo : Répare, colorise et agrandit une photo ancienne ou abîmée avec l’IA ;
• Nettoyage de confidentialité : Supprime les métadonnées EXIF, GPS et autres, puis compresse…

Installation facile

La version par défaut embarque PostgreSQL 17 et Redis 8 directement dans le conteneur… c’est facile et idéal pour mettre sur un NAS.

services: 
    snapotter:
        image: snapotter/snapotter:latest
        container_name: snapotter
        ports: 
            - 1349:1349
        volumes:
            - ./:/data

Pour une utilisation plus soutenue, un stack Docker Compose à 3 conteneurs (App + Postgres + Redis séparés) est disponible, avec une variante GPU NVIDIA pour accélérer les tâches d’IA. Sur DSM ou dans Portainer, l’un ou l’autre s’intègre sans souci via Container Manager.

services:
  snapotter:
    image: snapotter/snapotter:latest
    ports: ["1349:1349"]
    environment:
      DATABASE_URL: postgres://snapotter:snapotter@postgres:5432/snapotter
      REDIS_URL: redis://redis:6379
    volumes:
      - SnapOtter-data:/data
    depends_on: [postgres, redis]
    restart: unless-stopped
  postgres:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: snapotter
      POSTGRES_PASSWORD: snapotter
      POSTGRES_DB: snapotter
    volumes: ["SnapOtter-pgdata:/var/lib/postgresql/data"]
    restart: unless-stopped
  redis:
    image: redis:8-alpine
    volumes: ["SnapOtter-redisdata:/data"]
    restart: unless-stopped
volumes:
  SnapOtter-data:
  SnapOtter-pgdata:
  SnapOtter-redisdata:

Le projet est multi-arch (AMD64 et ARM64), ce qui couvre tous les NAS ou un Raspberry Pi et autre un mini PC. Il gère l’authentification OIDC/SSO (Google, GitHub, Okta), 21 langues dont le français et expose une API REST complète avec documentation.

Point de vigilance

Attention au premier lancement, l’identifiant est admin et le mot de passe admin. Le changement de mot de passe est imposé dès la première connexion, mais si vous exposez l’instance (sur Internet par exemple), passez par un reverse proxy avec authentification…

En synthèse

SnapOtter comble un vrai vide entre Stirling-PDF (limité aux PDF) et ConvertX (limité aux conversions). Pour qui héberge déjà son NAS et veut arrêter d’uploader ses fichiers personnels sur des services gratuits douteux, c’est une brique qui mérite sa place à côté d’Immich ou de Bitwarden. SnapOtter est gratuit (licence AGPLv3)et une version commerciale existe pour un usage dans un produit propriétaire ou en mode SaaS. Pour un usage personnel et familial sur NAS, l’AGPLv3 ne pose aucune contrainte

Seagate vient de préciser sa feuille de route autour du HAMR et confirme la sortie des premiers disques durs de 50 To dès l’année prochaine. Le fabricant en profite pour détailler l’avenir de sa technologie de stockage haute densité…

Seagate Mozaic 5 et les 50 To

Commençons par un petit rappel de la technologie HAMR (Heat-Assisted Magnetic Recording) utilisée par Seagate. Celle-ci repose sur un laser qui chauffe localement à plusieurs centaines de degrés pour polariser les grains magnétiques et augmenter la densité d’enregistrement. Après Mozaic 3 (30 To et plus) et Mozaic 4 (jusqu’à 44 To), Seagate prépare Mozaic 5…

Cette troisième génération vise une densité supérieure à 5 To par plateau. Avec 10 plateaux par disque, c’est le maximum actuel chez Seagate (Western Digital et Toshiba montent respectivement jusqu’à 11 et 12 plateaux), cela ouvre la voie à des capacités dépassant les 50 To sur un seul HDD. Le PDG de Seagate a confirmé que les premières livraisons sont attendues fin 2027, avant une disponibilité plus large en 2028. Vous l’aurez compris, ces disques ne sont pas près d’arriver dans nos NAS et autres serveurs domestiques.

Et après ?

En mars 2021, Seagate dévoilait déjà une feuille de route ambitieuse. À l’époque, le fabricant annonçait l’arrivée de disques de 30 To pour 2023, 40 To pour fin 2024 / début 2025 et 50 To pour 2026… pour atteindre 100 To en 2030. Si le calendrier a légèrement glissé depuis, le fabricant confirme ses ambitions.

Seagate ne compte pas s’arrêter au Mozaic 5… L’entreprise a déjà validé (en laboratoire) une densité de 6,9 To par plateau, soit 69 To sur un disque à 10 plateaux ! À l’horizon 2032, l’objectif affiché est de 10 To par plateau, ouvrant la voie à des disques durs de 100 To, voire 150 To et au-delà selon les pistes explorées par le constructeur (nouvelles architectures système, nouvelles conceptions de têtes de lecture).

En synthèse

Ce n’est pas la première fois que Seagate annonce l’arrivée de disques de 50 To et plus. Aussi, le fabricant se trouve dans une position financière confortable, avec des bénéfices en hausse à 3,184 milliards de dollars sur l’exercice 2026 et une marge brute de 45,6 % ! La demande liée à l’IA et au Coud tire les prix vers le haut…

Pour les utilisateurs de NAS grand public, ces annonces restent un rêve lointain. Reste à voir combien de temps il faudra avant que cette densité redescende vers les gammes accessibles aux particuliers et aux petites structures.

source

Infuse est la référence de ceux qui gère leur vidéothèque depuis un NAS et souhaite la lire proprement sur iPhone, iPad, Apple TV, Mac ou encore Vision Pro. La version 8.5 vient de sortir et apporte une fonctionnalité que beaucoup d’utilisateurs de serveurs Plex, Emby et Jellyfin attendaient : des options de transcodage natives, directement intégrées au flux de lecture.

Infuse 8.5

Pour rappel, Infuse est développé par la société Firecore. Il s’agit d’un gestionnaire de vidéothèque et un lecteur vidéo pour l’écosystème Apple (iPhone, iPad, Mac, Apple TV, Vision Pro). Il est reconnu pour sa capacité à lire quasiment tous les formats et codecs sans conversion (y compris les fichiers exotiques). Historiquement, l’application se limitait aux protocoles de partage réseau classiques (FTP, SMB, NFS et UPnP/DLNA), idéal pour ceux qui possédaient un NAS. Au fil des versions, Infuse a élargi son champ d’action en ajoutant la compatibilité avec les principaux serveurs média du marché (Plex, Emby, Jellyfin), ainsi que l’ajout du WebDAV…

Une de ses force, c’est sa capacité à lire quasiment n’importe quel format sans conversion (Direct Play), mais dès qu’on sort de son domicile, avec une 4G limitée ou depuis le WiFi d’un hôtel, le Direct Play montre vite ses limites sur les gros fichiers (mise en cache interminable, coupures toutes les 10 secondes… ou tout simplement échec de lecture).

Comment ça fonctionne concrètement

Avec Infuse 8.5, un appui long sur le bouton Lecture (Play en anglais) fait apparaître une liste des versions transcodées disponibles, générées à la demande par votre serveur Plex, Emby ou Jellyfin. Le lecteur Infuse va demander au serveur de transcoder le flux à la volée, dans une version plus légère, plutôt que d’envoyer le fichier original tel quel.

Si votre vidéothèque contient plusieurs versions d’une même vidéo (4K et 1080p par exemple), le même menu permet de choisir directement la version souhaitée via le bouton Version. Et pour les utilisateurs qui préfèrent ne pas avoir à faire cette manipulation à chaque lecture, l’application propose d’afficher cette invite automatiquement dès le lancement de la lecture. Pour cela, allez dans le menu Réglages > Lecture.

Le Direct Play reste le choix par défaut et recommandé chaque fois que c’est possible. L’application ne modifie rien au flux audio et vidéo, vous profitez de la meilleure qualité de votre fichier. Le transcodage devient donc une option de confort pour les cas où la bande passante est le facteur limitant. Pour rappel, le transcodage se fait côté serveur… cela peut consommer beaucoup de ressources (mémoire et surtout processeur) sur votre NAS.

Une recherche plus lisible

Autre nouveauté avec Infuse 8.5, la recherche a été retravaillée pour offrir un rendu plus cohérent sur vos différents appareils. Les résultats sont désormais mieux organisés, ce qui facilite la distinction entre un film, une série, un épisode, une collection ou une encore une personne (acteur, réalisateur, etc.).

Et le reste ?

L’éditeur mentionne également des améliorations sur la connexion WebDAV et sur la gestion des serveurs média en général, ainsi que des correctifs (sans plus de détails).

En synthèse

Firecore continue d’améliorer son application, après l’ajout du saut automatique des intros, crédits et résumés dans la précédente mise à jour. Pour les utilisateurs de NAS qui font tourner Plex, Emby ou Jellyfin et consomment leur contenu en mobilité, cette nouveauté comble un vrai manque. Jusqu’ici, il fallait souvent jongler entre plusieurs applications ou télécharger ses contenus à l’avance avant de partir. Désormais, le pilotage du transcodage se gère nativement dans Infuse, sans sacrifier la qualité en Direct Play quand la connexion le permet. Un bémol à garder en tête tout de même, le transcodage vidéo à la volée reste une opération gourmande, notamment en ressources CPU côté serveur (NAS).

source

6 mois, ça passe vite. Entre 2 comparatifs, 3 guides Docker et quelques nuits un peu courtes à corriger des tutos, je souhaitais prendre un peu de recul pour regarder ce qui s’est passé sur Cachem depuis janvier : ce que vous avez le plus lu, ce qui vous a fait réagir et les sujets qui reviennent souvent. Comme c’est la période estivale, je me suis dit que ce serait intéressant de faire un petit état des lieux…

Le trafic d’abord

Le nombre de pages vues a progressé de 19,5% sur le premier semestre 2026 (versus S1 2025). Rien de spectaculaire, mais concrètement, ça veut dire que de plus en plus d’entre vous viennent chercher ici des réponses concrètes sur le NAS et le homelab. Et ça, ça me motive à continuer…

Top des articles

Sans surprise, c’est Docker qui truste la première place. Voici ce que vous avez le plus lu :

1. Top 10 des conteneurs Docker indispensables sur NAS Synology en 2026, c’est largement le plus lu ;
2. Immich passe en v3 : voici comment mettre à jour votre NAS, l’auto-hébergement de photos continue de plaire ;
3. Comparatif des meilleurs NAS 2026, le classique qui ne déçoit jamais, année après année.
4. Installer Immich sur un NAS Synology (Guide complet 2026), c’est sur un article riche (en lien avec celui en 2e position) ;
5. Quel NAS pour DSM 7.4 ? Compatibilité, limites et nos recommandations, tout est dans le titre…

Ce qui vous a fait réagir

Le trafic, c’est une chose… mais les commentaires, c’en est une autre et souvent souvent plus révélateur. Voici les articles qui ont généré le plus d’échanges ce semestre (hors concours) :

• Cachem.fr : pourquoi je continue (et pourquoi parfois je doute), c’est un article très personnel qui vous a fait le plus réagir (merci pour vos messages, ça compte plus que vous ne l’imaginez) ;
• Top 10 des conteneurs Docker indispensables sur NAS Synology 2026, c’est assez logique, vu le trafic, mais ça confirme surtout que vous avez plein de suggestions et de retours d’expérience à partager ;
• Zorin OS : donner une seconde vie à son PC/Mac (Linux), un sujet un peu à part du NAS pur, mais qui a visiblement touché une corde sensible chez pas mal d’entre vous.

Et pour la suite ?

Ce petit bilan me conforte dans une chose… c’est que les NAS, Docker et le self-hosting restent les piliers à creuser encore davantage sur la seconde moitié de l’année. Plusieurs articles sont déjà en préparation ! Je n’oublie pas les NAS qui reste le point central de Cachem.

Pour information (ou rappel), la première newsletter Cachem est sortie il y a quelques jours. J’espère sincèrement qu’elle vous a plu Pour ceux qui ne sont pas encore inscrit, il n’est jamais trop tard

Allez, je vous laisse… le meilleur reste à écrire.