Au départ, mon stockage était franchement bordélique. Ma bibliothèque Plex vivotait sur un vieux Synology, avec plusieurs SSD externes branchés au Mac mini, posés là au petit bonheur, avec les films rangés à plat et chaque disque qui traînait ses propres conventions et ses trous.

Je vous en avais d'ailleurs déjà parlé, et ça marchait, mais c'était un peu le foutraque, et surtout impossible à automatiser proprement, parce qu'une chaîne d'acquisition sérieuse exige un rangement carré jusqu'au moindre fichier.

D'où la grande décision de remettre tout ça à plat. L'objectif ? Consolider la médiathèque sur du matériel récent, séparer une bonne fois deux mondes qui n'ont rien à faire ensemble, les médias d'un côté et les sauvegardes de l'autre, et déléguer le plus gros de la configuration à Claude Code, l'assistant de codage d'Anthropic, piloté à distance depuis mon Mac mini.

UGREEN m'avait proposé depuis quelque temps de tester les deux NAS de sa gamme GT, j'ai donc accepté. Puis j'ai acheté mes disques une fortune, on y reviendra. Pour Plex, mon choix s'est porté sur le plus costaud de la gamme, un DXP4800 GT quatre baies sous AMD Ryzen.

Sa vraie raison d'être, c'est le débit. Ses deux ports réseau 10 Gbit confiés à des contrôleurs Aquantia ont craché 9,30 Gbit par seconde dès le premier flux en direct, soit le maximum théorique, sans une seule retransmission. Sur ce terrain, il est clairement irréprochable.

Sous le capot, on trouve un Ryzen Embedded R2514 à quatre cœurs, 8 Go de DDR4 extensibles à 64 Go, quatre baies qui se manipulent sans outil dont deux acceptent des SSD U.2 NVMe, plus deux emplacements M.2, le tout jusqu'à 144 To. Il tourne sous UGOS Pro, un système bâti sur une base Debian très peu verrouillée, avec un vrai SSH administrateur, Docker, et une plateforme x86 ouverte où l'on peut installer à peu près tout ce qu'on veut.

Le seul vrai bémol, c'est son moteur vidéo un peu daté, qui ne tient que deux flux Plex 4K transcodés en même temps et ignore l'AV1, donc pour une grosse médiathèque partagée à plusieurs, mieux vaut lui donner des fichiers déjà au bon format, ou transcoder sur une autre machine, ce qui est mon cas avec le Mac mini. Pour le stockage, j'ai récupéré 4 disques 28 To sur Amazon , à un prix que je n'ose même pas vous donner (660 euros pièce, et au moment où j'écris cet article leurs prix ont bondi à 780 euros).

Le gros morceau, c'était la migration, faire passer 36 To et 22 000 fichiers du Synology vers ce nouveau NAS. Perso je n'ai pas fait grand-chose, Claude Code s'est occupé de tout ça en SSH, en passant par les API de Plex, Radarr et Sonarr.

Derrière Plex tourne d'ailleurs toute une chaîne, Radarr et Sonarr, Prowlarr pour les sources, une seedbox Whatbox et Seerr.

Pour l'anecdote, le plus gros problème ça a été de régler les problèmes posés par les fichiers avec des accents. Près de 17 000 fichiers (de vidéos de vacances bien sûr) au chemin accentué devenaient injouables sur l'Apple TV alors que l'iPhone les lisait sans broncher, parce que Plex sur Mac jongle entre deux façons de coder un accent en Unicode quand le partage NFS strict d'UGOS n'en accepte qu'une seule à l'octet près.

Bon, maintenant on ne va pas se mentir, il y a eu des ratés avec l'IA, comme la disparition de près de 800 fichiers effacés par un bug des scripts, sans corbeille ni snapshot, mais comme le volume tourne en Btrfs et qu'il restait de la place, Claude a gelé le volume, remonté des centaines d'états internes du système de fichiers et rapatrié plus de 98 % des fichiers. Les pertes sont au final négligeables. C'était évitable, mais je n'ai pas été assez vigilant.

Ce socle sauvegarde même le code de Selene Racer, mon jeu de course de rovers sur la Lune hébergé dans le cloud sur lequel je bosse en ce moment ( vous pouvez le tester ici , il se joue dans n'importe quel navigateur, sur ordi ou téléphone), et dont les sources atterrissent sur le NAS via Dropbox. Quant au NAS deux baies qui encaisse Time Machine, les archives et les sauvegardes, c'est son petit frère le DXP2800 GT, que je teste sur Mac4ever .

Si comme moi vous n'êtes pas super fort en code et en réseau, et que vous avez suffisamment de sauvegardes de vos données, confier votre vie numérique à une IA et à un NAS de ce type est donc tout à fait envisageable, et c'est même assez chouette à mettre en place.

Les DXP4800 GT et le DXP2800 GT sont disponibles sur Amazon, et je vous les recommande les yeux fermés.

OnePlus is closing its North American Community on August 16. Learn how to save your posts, photos, guides, and files before they become inaccessible.

The post OnePlus Community Is Ending: What Users Should Save First appeared first on TechRepublic.

Looking for the best Microsoft 365 backup solutions in 2026? Compare pricing, workload coverage, retention, security, and recovery options for your business.

The post 5 Best Microsoft 365 Backup Solutions for 2026 appeared first on TechRepublic.

Le truc cool avec un disque de backup, c'est quand vous arrêtez de le sortir du tiroir. Et c'est ce que permet de faire le DATO Ares Q4 (lien affilié) qui se trouve être aimanté et que je peux donc coller direct sur le côté de mon Mac Studio . Je l'ai depuis bientôt un an, et c'est devenu mon disque de Time Machine à résidence.

Il est trop mignon parce qu'il est tout petit, puisqu'il mesure 64 par 64 mm, 12 mm d'épaisseur, et 40 grammes, soit à peine plus gros qu'un bloc de petits Post-it, sauf que dedans y'a 4 To de NVMe en USB4. Les aimants sont prévus pour s'accrocher à un iPhone 15/16/17 Pro façon MagSafe, mais en pratique ils tiennent aussi nickel sur n'importe quelle machine, si vous collez le petit aimant-sticker livré avec.

Après je sais pas si coller un aimant sur un ordinateur c'est le move le plus intelligent que j'ai fait de ma vie mais je l'ai collé y'a 1 an, et ça bouge pas et j'ai aucun souci. Après c'est pas des GROS aimants non plus hein... C'est assez fin et pas très aimanté non plus. Et niveau connectique, c'est livré avec un câble USB-C rikiki de 10 cm.

Côté débits l'USB4 crache du 4000 Mo/s en lecture et 3600 Mo/s en écriture et comme c'est du natif, y'a pas de puce intermédiaire entre le NVMe et le port, donc on est max de ce qu'on peut avoir en vitesse avec ce genre de disque. Par contre, faut un port USB4 ou Thunderbolt 4/5 côté Mac, sinon ça retombe sur de l'USB 3.2 classique. C'est pas dramatique mais ça va 'achement moins vite quand même.

Et comme mon Mac Studio embarque 4 To en interne, c'est pile la taille du DATO que je dédie à ma sauvegarde Time Machine. Le sparsebundle peut donc grossir jusqu'à occuper tout le disque sans que je m'en occupe ! Et comme je ne le remplis jamais à 100%, je suis assez tranquille.

En plus de ce SSD, je fais toujours des backups sur mon NAS Synology avec Carbon Copy Cloner à côté parce que je suis parano et qu'on sait jamais...

Côté chauffe, la surprise est plutôt bonne, il reste froid / tiède même en plein transfert. Alors je suis pas sûr mais je me dis que le boîtier en alu du Mac Studio, joue peut-être un petit rôle de dissipateur thermique mais j'sais pas, peut-être pas... En tout cas, ça chauffe pas quoi.

Ce disque est compatible Mac, PC, Linux, et même iPhone Pro en USB-C comme ça si vous avez besoin de filmer de la 4K ProRes HDR direct sur un SSD plutôt que sur la mémoire interne, c'est possible ! Et il est garanti 5 ans, ce qui est toujours bon à prendre.

Voilà, si ça vous intéresse, le DATO Ares Q4 (lien affilié) est dispo sur Amazon en versions 1 To, 2 To ou 4 To .

On archive nos photos avec Immich , nos documents avec Readur , nos mots de passe avec Vaultwarden ... mais nos emails ? Ah bah non, ça on les laisse chez Google en croisant les doigts pour que tout se passe bien jusqu'à la fin de nos jours. C'est quand même un peu dinguo quand on y réfléchit sérieusement.

Et pourtant, y'a des années de conversations là-dedans ! Des factures en pièce jointe, des confirmations de commande, des échanges pro avec votre comptable, des mots de passe envoyés en clair (oui, hélas, ça arrive encore). Du coup, quand un hébergeur mail décide de changer ses conditions générales ou de fermer boutique, tout part à la poubelle si vous n'y faites pas attention.

Eonvelope , c'est un outil open source en Python qui permet de sauvegarder automatiquement tout ça sur votre propre serveur et qui se lance avec un simple docker compose up.

Le truc, c'est que des outils comme Gmvault font déjà le boulot via cron, mais uniquement pour Gmail et en ligne de commande alors qu'Eonvelope, lui, un peu à la manière de Bichon , tourne en arrière-plan avec une interface web et archive en continu tous vos comptes. Franchement, c'est pas le même délire. Vous branchez vos comptes IMAP, POP3, Exchange, et même JMAP (le protocole poussé par Fastmail qui commence tout juste à se démocratiser), vous réglez la fréquence, et hop, vos mails atterrissent dans votre instance sans que vous ayez à y penser.

Attention par contre, c'est de l'archivage, pas un client mail... vous ne répondrez pas à vos mails depuis l'interface.

Côté installation, c'est du Docker avec seulement 2 conteneurs, le serveur web et la base de données. En fait, comptez 5 minutes chrono si vous avez déjà un serveur dédié ou un VPS, le fichier docker-compose.yml est fourni et les variables d'environnement sont bien documentées sur ReadTheDocs . Y'a même un mode basse consommation pour ceux qui font tourner ça sur un Raspberry Pi 4 avec 2 Go de RAM ou un petit Synology ! SSL et HTTPS sont inclus par défaut, et l'authentification multifacteur aussi.

Mais le vrai point fort, c'est les intégrations avec le reste de l'écosystème self-hosted. Concrètement, vous pouvez envoyer vos pièces jointes PDF vers Paperless-ngx pour l'OCR, les photos vers Immich, et exporter vos contacts vers votre carnet d'adresses Nextcloud. Y'a aussi un endpoint Prometheus pour brancher Grafana et suivre vos stats d'archivage. En gros, si vous avez déjà un homelab qui tourne, ça vient se brancher dessus comme une pièce de Lego.

L'interface web est en PWA (donc utilisable sur votre téléphone), avec un moteur de recherche, du filtrage par date et par expéditeur, des fils de conversation reconstitués et de l'import/export en EML et MBOX. Franchement, c'est propre. Y'a aussi une API REST pour ceux qui préfèrent scripter par-dessus plutôt que de passer par l'interface.

Le projet est sous licence AGPLv3 et son dev déclare l'utiliser lui-même au quotidien, ce qui est souvent bon signe. Notez que la migration depuis un backup existant n'est pas forcément fluide mais qui ne tente rien n'a rien !

Bref, ça comble un vrai manque dans la stack de nos machins auto-hébergés mais je trouve que l'approche est clairement plus intégrée que ce qui existe (genre MailPiler ou un combo fetchmail+dovecot). À surveiller donc !

Source

Vous faites des sauvegardes régulières de vos données ? Non ?

Bon, je ne vais pas vous faire la morale, mais le jour où votre disque dur décidera de rendre l'âme ou que votre serveur VPS partira en fumée, vous allez vraiment regretter de ne pas avoir investi dix minutes dans un système de backup sérieux.

Alors, ouiiii, c'est vrai, on a souvent la flemme parce que c'est chiant à configurer. Entre les scripts bash qui plantent sans prévenir et les crontabs illisibles, y’a de quoi s'arracher les cheveux. C'est là qu'intervient Zerobyte , un projet open source qui veut réconcilier les allergiques du terminal avec la sécurité de leurs données.

Zerobyte est donc une plateforme d'automatisation de sauvegarde auto-hébergée qui vient poser une interface web moderne et ultra propre par-dessus le moteur Restic. Si vous avez déjà lu mon guide sur les backups avec Restic , vous savez que c'est du solide. Ça fait du chiffrement côté client, de la déduplication et de la compression. En gros, vos données sont blindées avant même de quitter votre machine et seules les modifs sont envoyées, ce qui est parfait pour ne pas exploser son forfait data ou son stockage cloud.

L'interface web permet surtout de tout piloter sans jamais toucher à une ligne de commande. Vous définissez vos "volumes" (ce qu'il faut sauver), vos "repositories" (où stocker tout ça) et vos "jobs" (quand lancer les opérations).

Pour les sources, l'outil est hyper flexible puisqu'il supporte aussi bien les dossiers locaux que les partages réseau via NFS, SMB, WebDAV ou SFTP et côté destination, c'est carrément Byzance puisque vous pouvez envoyer vos snapshots vers du S3 (AWS, MinIO, Wasabi), du Google Cloud, de l'Azure ou utiliser l'intégration rclone qui ouvre la porte à plus de 70 fournisseurs différents. C’est l’outil idéal pour mettre en place une véritable stratégie 3-2-1 sans se prendre la tête.

Pour l'installation, pas de surprise, ça se passe via Docker Compose. C'est léger, ça s'isole bien et ça tourne en deux minutes. Un petit bémol quand même le projet est encore jeune donc ça peut encore bouger pas mal au niveau de l'architecture. Mais pour du monitoring et de la gestion simplifiée de snapshots Restic, c'est déjà redoutable. Vous pouvez explorer vos sauvegardes directement depuis le dashboard et restaurer un fichier précis en trois clics.

Et pour ne rien gâcher, le projet est sous licence libre, ce qui colle parfaitement à l'esprit qu'on aime ici !

Bref, si vous cherchez une solution pour centraliser la gestion de vos sauvegardes sans finir en PLS devant un terminal, Zerobyte mérite clairement que vous y jetiez un œil.

Edit du 22/12/2025 : Bonne nouvelle ! Le développeur a finalement récupéré son compte. Un employé d'Apple Executive Relations basé à Singapour l'a contacté pour lui annoncer que tout était réglé. Il s'avère que la carte cadeau qu'il avait essayé d'utiliser avait déjà été "consommée" d'une manière ou d'une autre (probablement du tampering classique de carte cadeau), et son compte s'est retrouvé flaggé à cause de ça. Apple lui a conseillé de n'acheter des cartes cadeaux que directement chez eux et quand il a demandé si ça signifiait que leur chaîne d'approvisionnement (Blackhawk Network, InComm et autres revendeurs) était peu fiable, Apple a refusé de commenter. Comme quoi, même après 25 ans de fidélité, faut quand même gueuler un bon coup pour que ça bouge...

Vous vous souvenez de mes conseils sur les backups ? Ceux que je vous rabâche régulièrement depuis des années ? Hé bien voici une histoire qui va vous donner envie de les suivre une bonne fois pour toutes.

Dr Paris Buttfield-Addison, c'est un développeur Apple depuis 25 ans. Le mec a écrit plus de 20 bouquins sur Objective-C et Swift, il co-organise le plus ancien événement développeur Apple non-officiel... Bref, c'est pas un random qui a téléchargé une app météo une fois. C'est un évangéliste Apple depuis 30 ans.

Et bien du jour au lendemain, son compte Apple ID a été fermé. Sans explication. Sans recours. Sans rien.

L'élément déclencheur ? Il a essayé de racheter une carte cadeau Apple de 500 dollars pour payer son abonnement iCloud+ de 6 To. Le code a foiré, le vendeur lui a proposé un remplacement, et quelques temps après... boom, compte verrouillé.

Résultat : environ 30 000 dollars de matos Apple devenu inutilisable, des milliers de dollars de logiciels et médias achetés auxquels il n'a plus accès, plus d'iMessage, et surtout des téraoctets de photos de famille qu'il ne peut plus récupérer. 25 ans de souvenirs numériques, volatilisés.

Le support Apple ? Réponse standard : fermé pour "conformité avec les conditions". Pas d'explication. Zéro escalade possible. Et comme conseil : créer un nouveau compte. Sauf que ça pourrait aussi le faire bannir ce nouveau compte. Logique Apple...

Et le pompon ? On lui a également suggéré de se présenter physiquement au siège australien d'Apple. Comme si le mec allait prendre un billet d'avion pour aller plaider sa cause en personne. C'est difficilement compréhensible comme réponse venant d'une boîte qui vaut 3000 milliards de dollars.

Le truc, c'est que cette histoire peut arriver à n'importe qui. Que ce soit chez Apple, Google ou Microsoft, vous êtes à la merci d'un algorithme qui décide un beau matin que votre compte est suspect. Et bonne chance pour trouver un interlocuteur prêt à mouiller sa chemise pour vous. Spoiler : y'en a pas.

Moi-même j'ai eu tellement de problèmes de synchro avec iCloud au fil des années que j'ai perdu des fichiers. C'est de la merde, vraiment. Optez pour un truc mieux si vous le pouvez.

Du coup, comment éviter ça ? L'idéal c'est l'auto-hébergement si vous avez le temps et les compétences. Sinon, au minimum, faites des backups réguliers de vos données. Pour Apple Notes par exemple, y'a un outil qui s'appelle Exporter qui permet d'exporter toutes vos notes vers du Markdown ou du HTML. Comme ça le jour où Tim Cook décide que votre tronche lui revient pas, vous aurez au moins une copie de vos données quelque part.

Bref, ne faites jamais confiance à 100% à ces plateformes avec vos données les plus précieuses. Elles peuvent vous couper l'accès du jour au lendemain, et vous n'aurez aucun recours...

Source : hey.paris

Vous avez des dossiers sensibles que vous aimeriez chiffrer avant de les balancer sur un cloud ou un disque externe ? Ça tombe bien, je vous ai trouvé un petit outil en Rust qui va vous plaire.

Obsidenc , c'est son nom, est un utilitaire de chiffrement que son créateur qualifie de "paranoid-grade". Et après avoir jeté un œil au code source, je peux vous dire que c'est pas du marketing puisque ce truc archive votre répertoire en TAR et le chiffre avec XChaCha20-Poly1305, un algorithme AEAD moderne qui assure à la fois la confidentialité et l'intégrité de vos données.

Côté dérivation de clé, ça utilise Argon2id conforme à la RFC 9106. Pour les non-initiés, Argon2id c'est l'algo qui a gagné le Password Hashing Competition et qui est spécifiquement conçu pour résister aux attaques par GPU et circuits spécialisés (ASIC). L'outil adapte automatiquement les paramètres à votre machine en utilisant 85% de votre RAM disponible (entre 512 Mo minimum et 2 Go maximum) afin de rendre le brute-force astronomiquement coûteux. Et si vous avez moins de RAM dispo, il compense en augmentant le nombre d'itérations.

C'est du code Rust bien propre qui utilise les bibliothèques cryptographiques RustCrypto (bien auditées par la communauté) et le code implémente des bonnes pratiques de sécurité comme le memory locking (mlock sur Unix, VirtualLock sur Windows) pour éviter que vos clés se retrouvent dans le swap, et le zeroize pour effacer la mémoire sensible après utilisation.

Vous compilez ça avec cargo build --release, puis pour chiffrer un dossier :

obsidenc encrypt ~/mon-dossier ~/mon-dossier.oen

Pour déchiffrer :

obsidenc decrypt ~/mon-dossier.oen ~/mon-dossier-dechiffre

Le mot de passe doit faire minimum 20 caractères (pas de négociation possible, déso pas déso) et vous devez le confirmer deux fois. Vous pouvez aussi ajouter un fichier de clé en plus du mot de passe pour du 2FA old-school.

L'outil a aussi quelques protections défensives sympas. Par exemple, il refuse les symlinks (vecteur d'attaque classique), limite le nombre de fichiers à 1 million et la longueur des chemins à 4096 caractères pour éviter les zip bombs. Sur les systèmes Unix, il vérifie même que votre fichier de clé n'est pas lisible par tout le monde (chmod 600 obligatoire).

Cet outil part du principe qu'un attaquant peut avoir accès à votre fichier chiffré et dispose de temps illimité pour tenter de le casser, du coup, tout est conçu pour rendre l'attaque offline la plus douloureuse possible.

Bref, si vous cherchez un moyen de sauvegarder vos dossiers sensibles de manière vraiment sécurisée avant de les balancer sur un cloud ou un disque externe, obsidenc fait le taf et en plus c'est open source (MIT/Apache 2.0) !

Vous vous souvenez de cette règle de base en informatique, que je vous rabâche régulièrement, et qui dit de toujours avoir plusieurs sauvegardes de vos données critiques ?

Hé bien apparemment, le gouvernement sud-coréen a zappé ce cours, car le 26 septembre dernier, un incendie s’est produit au centre de données NIRS (National Information Resources Service) à Daejeon et a cramé 858 téraoctets de fichiers gouvernementaux . Et y’a pas de backup. Nada.

Le feu a démarré pendant une opération de maintenance sur une batterie lithium-ion dans laquelle une cellule a lâché , déclenchant ce qu’on appelle un emballement thermique… En gros, la batterie s’est transformée en bombe incendiaire et le brasier s’est propagé dans la salle serveur du cinquième étage, faisant tomber 647 services en ligne gouvernementaux d’un coup. Parmi eux, 96 systèmes critiques ont été directement détruits, et 551 autres ont été coupés préventivement pour éviter que la chaleur les bousille aussi.

Le système qui a morflé le plus, c’est G-Drive, le cloud de stockage utilisé par les fonctionnaires sud-coréens depuis 2018. Environ 750 000 employés du gouvernement central peuvent stocker leurs documents de travail dessus, mais seulement 125 000 l’utilisaient vraiment. Chacun disposait d’environ 30 Go d’espace de stockage, ce qui fait qu’au total le système contenait 858 To de données de travail accumulées sur huit ans.

Snif…

En fait, leur G-Drive est conçu comme un système de stockage haute capacité, mais basse performance, et ils ont des contraintes réglementaires qui imposent un stockage exclusif sur cette plateforme afin d’éviter les fuites de données.

Donc autrement dit, pour se prémunir contre les risques de fuite, ils ont créé un point de défaillance unique. Et comme y’avait pas de backup, c’est la cata… Bravo !

Du coup, quand l’incendie a détruit les serveurs physiques, tout est parti en fumée. Huit ans de documents de travail pour certains ministères, qui ont été complètement perdus… C’est surtout le ministère de la Gestion du Personnel qui s’est pris la claque la plus violente parce qu’il avait rendu obligatoire le stockage de tous les documents sur G-Drive uniquement. D’autres organismes comme le Bureau de Coordination des Politiques Gouvernementales, qui utilisaient moins la plateforme, ont moins souffert.

Bref, les autorités essaient maintenant de récupérer ce qu’elles peuvent depuis d’autres sources. Y’a des petits bouts de fichiers sauvegardés localement sur les ordinateurs personnels des fonctionnaires le mois précédent, les emails, les documents officiels validés et les archives papier… Bref, pour tous les documents officiels passés par des processus d’approbation formels, il y a un espoir de récupération via leur système OnNara (un autre système gouvernemental qui stocke les rapports finaux), mais pour tout le reste (brouillons, fichiers de travail en cours, notes internes…etc.) c’est mort de chez mort…

Le ministère de l’Intérieur a expliqué que la plupart des systèmes du centre de Daejeon sont normalement sauvegardés quotidiennement sur des équipements séparés dans le même centre ET dans une installation de backup distante. Mais G-Drive, lui, n’avait pas, comme je vous le disais, cette possibilité.

Évidemment, cet incident a déclenché une vague de critiques acerbes sur la gestion des données gouvernementales sud-coréennes. Un système de backup en miroir en temps réel qui duplique le serveur principal pour assurer la continuité de service en cas de panne, était complètement absent de l’infrastructure et pour un système aussi critique que le stockage de documents de 750 000 fonctionnaires, c’est difficilement compréhensible.

Voilà donc le gouvernement estime qu’il faudra jusqu’à un mois pour récupérer complètement les 96 systèmes de base directement endommagés par l’incendie et pour G-Drive et ses 858 To de données, par contre, c’est une autre histoire, car sans backup, les données sont définitivement perdues.

De plus, cet incendie déclenche actuellement un genre d’examen mondial des batteries lithium-ion dans les datacenters et des architectures de plan de reprise d’activité (PRA). Les batteries lithium-ion sont en effet utilisées partout pour l’alimentation de secours, mais leur risque d’emballement thermique en cas de défaillance pose de sérieuses questions sur leur place dans des infrastructures critiques…

Bref, je souhaite bon courage aux Coréens, et j’espère que tout le monde saura tirer des enseignements de ce malheureux incendie…

Source