[{"data":1,"prerenderedAt":1779},["ShallowReactive",2],{"tag-posts-grpc":3},[4],{"id":5,"title":6,"author":7,"body":8,"category":1682,"categorySlug":1683,"date":1684,"description":14,"excerpt":1685,"extension":1764,"location":1765,"meta":1766,"navigation":1767,"path":1768,"published":1767,"seo":1769,"slug":1770,"stem":1771,"tags":1772,"timeToRead":1777,"__hash__":1778},"posts\u002Fposts\u002FWoodstock\u002F2026-04-26_woodstock_v2.md","Woodstock Backup v2.0.0 - La réécriture complète en Rust","Ulrich Vandenhekke",{"type":9,"value":10,"toc":1645},"minimark",[11,15,18,21,115,118,127,132,137,140,147,151,159,166,169,173,180,188,191,195,202,206,209,212,216,223,227,231,238,245,249,252,340,354,358,366,394,397,404,408,419,429,433,436,439,443,447,453,456,459,462,465,469,472,476,479,485,488,492,502,505,528,531,542,548,552,556,559,781,784,818,822,825,879,882,886,889,896,899,906,909,916,919,926,943,950,953,957,961,964,970,985,988,992,995,999,1002,1021,1572,1575,1578,1581,1587,1594,1600,1607,1618,1622,1625,1628,1642],[12,13,14],"p",{},"Bonjour à tous,",[12,16,17],{},"Six ans. Il m'aura fallu six ans entre la première version de Woodstock Backup et cette v2. Si vous m'aviez dit en 2020\nque je passerais la moitié de la décennie à réécrire trois fois le même logiciel de sauvegarde... j'aurais quand même\nfoncé tête baissée. C'est ma façon de faire. Me voilà donc avec une version 2 stable,\nentièrement réécrite en Rust, qui tourne en production sur ma petite infrastructure depuis plus d'un an. Et je suis\nvraiment content du résultat. 😄",[12,19,20],{},"Pour ceux qui me lisent depuis longtemps, voici un récapitulatif des articles qui ont précédé celui-ci :",[22,23,24,40],"table",{},[25,26,27],"thead",{},[28,29,30,34,37],"tr",{},[31,32,33],"th",{},"Article",[31,35,36],{},"Date",[31,38,39],{},"Sujet",[41,42,43,59,73,87,101],"tbody",{},[28,44,45,53,56],{},[46,47,48],"td",{},[49,50,52],"a",{"href":51},"\u002Fpost\u002Fwoodstock","Woodstock Backup v1.0.0",[46,54,55],{},"2020-09-20",[46,57,58],{},"Présentation du projet, prototype TypeScript + rsync",[28,60,61,67,70],{},[46,62,63],{},[49,64,66],{"href":65},"\u002Fpost\u002Fwoodstock_brtfs","Woodstock Backup - Btrfs",[46,68,69],{},"2021-01-12",[46,71,72],{},"Abandon de Btrfs, écriture d'un pool custom",[28,74,75,81,84],{},[46,76,77],{},[49,78,80],{"href":79},"\u002Fpost\u002Fwoodstock_protocol_language_sauvegarde","Woodstock Backup - Protocole et Langage de sauvegarde",[46,82,83],{},"2021-04-18",[46,85,86],{},"Protocole gRPC maison",[28,88,89,95,98],{},[46,90,91],{},[49,92,94],{"href":93},"\u002Fpost\u002Fwoodstock_rust","Woodstock Backup - Optimiser Node.js avec Rust",[46,96,97],{},"2023-05-10",[46,99,100],{},"NAPI-RS et bindings Rust pour réduire la consommation mémoire",[28,102,103,109,112],{},[46,104,105],{},[49,106,108],{"href":107},"\u002Fpost\u002Fpr_backuppc_pool","Woodstock Backup - Reverse engineering de BackupPC",[46,110,111],{},"2024-05-07",[46,113,114],{},"Migration du pool BackupPC vers Woodstock",[12,116,117],{},"Pour les nouveaux, je résume : Woodstock Backup est mon logiciel de sauvegarde personnel, centralisé, qui sauvegarde\ntoutes les machines de mon réseau local et mes serveurs distants sur un NAS. L'idée de départ était simple. Le résultat\nest... un peu plus complexe. :)",[12,119,120],{},[121,122],"img",{"alt":123,"src":124,"className":125},"Pool of chunks","\u002FWoodstock\u002Fv2_splash.png",[126],"img-center",[128,129,131],"h2",{"id":130},"le-long-chemin-de-2020-à-2026","Le long chemin de 2020 à 2026",[133,134,136],"h3",{"id":135},"prototype-1-typescript-rsync-btrfs-2020","Prototype 1 : TypeScript + rsync + Btrfs (2020)",[12,138,139],{},"Tout a commencé avec un prototype en TypeScript qui utilisait rsync pour copier les fichiers et Btrfs pour les\nsnapshots incrémentaux. L'idée était élégante sur le papier : rsync calcule le delta, Btrfs déduplique, tout le monde\nest content.",[12,141,142,143,146],{},"En pratique, je me suis rapidement retrouvé avec des problèmes de stabilité de Btrfs lorsque le nombre de snapshots\ndevient élevé et que le système de fichiers approche de la saturation. J'en ai ",[49,144,145],{"href":65},"parlé en détail dans mon article sur\nBtrfs",". En résumé : abandonné.",[133,148,150],{"id":149},"prototype-2-typescript-grpc-pool-custom-2021","Prototype 2 : TypeScript + gRPC + pool custom (2021)",[12,152,153,154,158],{},"L'abandon de Btrfs m'a forcé à écrire mon propre pool de stockage basé sur le principe de ",[155,156,157],"strong",{},"Content-Addressable\nStorage"," (CAS) : chaque bloc de fichier (chunk) est identifié par son hash, et si deux fichiers partagent des blocs\nidentiques, ces blocs ne sont stockés qu'une seule fois. La déduplication est donc native.",[12,160,161,162,165],{},"Pour transférer les fichiers entre les machines à sauvegarder et le serveur, j'ai abandonné rsync et développé ",[49,163,164],{"href":79},"mon\npropre protocole basé sur gRPC",". gRPC s'appuie sur HTTP\u002F2, offre une\ncompression et un TLS natifs, et les bibliothèques existent pour tous les langages. Parfait.",[12,167,168],{},"Ce prototype, toujours en TypeScript, fonctionnait. Mais le moteur JavaScript de Node.js a ses limites. En particulier,\nla représentation en mémoire des objets JavaScript est beaucoup plus gourmande que celle d'un langage compilé. Pour un\noutil qui doit gérer des millions de fichiers, c'est un vrai problème.",[133,170,172],{"id":171},"lère-des-bindings-rust-2023","L'ère des bindings Rust (2023)",[12,174,175,176,179],{},"L'idée de cette phase était séduisante : garder toute la partie cœur en Rust pour les performances, et conserver le\nTypeScript pour la couche GraphQL et la logique applicative. Rust pour ce qui est critique, TypeScript pour ce qui est\nlisible et rapide à écrire. C'est ce que j'ai ",[49,177,178],{"href":93},"décrit dans mon article de 2023",".",[12,181,182,183,187],{},"Bien sûr, je me trompais. En pratique, il fallait des bindings d'exposition NAPI-RS pour chaque interface entre les\ndeux langages, des DTOs côté TypeScript qui doublonnaient les structures Rust, et surtout, plus le temps passait, plus\nle cœur métier migrait vers Rust — laissant de moins en moins de code côté TypeScript. La complexité était réelle :\ngérer des équivalents d'",[184,185,186],"code",{},"Observable"," ou du streaming en passant par des bindings NAPI-RS n'est pas trivial, même si\nles dernières versions de NAPI-RS ont depuis apporté des solutions à ces problèmes.",[12,189,190],{},"Le tout en restant performant malgré le coût du passage par les bindings TypeScript. C'était jouable, mais c'était\nde la jonglerie.",[133,192,194],{"id":193},"la-migration-du-pool-backuppc-2024","La migration du pool BackupPC (2024)",[12,196,197,198,201],{},"En parallèle, j'ai travaillé sur la migration de mon pool BackupPC existant vers le format Woodstock. La première\napproche envisagée consistait à monter les sauvegardes BackupPC via FUSE et à les lire comme un système de fichiers\nnormal. J'ai finalement opté pour une approche plus directe : ",[49,199,200],{"href":107},"lire directement le format interne de BackupPC",",\nce qui impliquait un travail de rétro-ingénierie non négligeable. La migration a été un succès, et j'ai pu enfin\nabandonner complètement BackupPC.",[133,203,205],{"id":204},"la-décision-de-tout-réécrire-en-rust-2024","La décision de tout réécrire en Rust (2024)",[12,207,208],{},"À ce stade, la situation était devenue évidente : la partie TypeScript avait tellement rétréci qu'il ne restait plus\ngrand-chose dedans. Un serveur NestJS (framework Node.js) pour l'API, une interface web en Vue.js, et quelques couches\nde glue — le reste était déjà en Rust. Maintenir deux écosystèmes pour si peu de code TypeScript n'avait plus aucun\nsens.",[12,210,211],{},"J'ai donc décidé de sauter le pas : supprimer les bindings, réécrire intégralement le backend en Rust. Plus de\nNAPI-RS, plus de DTOs en double, plus de jonglerie entre deux compilateurs. Du Rust pur, de bout en bout.",[133,213,215],{"id":214},"woodstock-backup-v2-la-version-stable-2026","Woodstock Backup v2 : la version stable (2026)",[12,217,218,219,222],{},"La version ",[184,220,221],{},"2.0.0"," est en production depuis plus d'un an maintenant, et je la considère comme stable. Les sauvegardes tournent tous les jours, les restaurations\nfonctionnent, et je dors tranquille.",[128,224,226],{"id":225},"architecture-de-woodstock-backup-v2","Architecture de Woodstock Backup v2",[133,228,230],{"id":229},"vue-densemble-le-modèle-pull","Vue d'ensemble : le modèle Pull",[12,232,233,234,237],{},"L'architecture reste fondée sur le ",[155,235,236],{},"modèle pull"," : c'est le serveur de sauvegarde qui initie les connexions vers les\npériphériques, et non l'inverse. Cela offre une garantie de sécurité importante : un périphérique compromis ne peut\npas écrire de données arbitraires dans le serveur de sauvegarde.",[239,240,241],"center",{},[121,242],{"alt":243,"src":244},"Architecture Pull - Woodstock v2","https:\u002F\u002Fwww.plantuml.com\u002Fplantuml\u002Fpng\u002FVLJDRjD04BxxAOPm81M47hZbK9N-g19AfLAZ7b2aQB8UnzkiPvsTtRJSE25nHJm0Hy9h-4tw9E3ysaxAnPPs_hxvlfav5O_EXzn4Btn6EK6Edfp6A1hRH-Z4vEOK72G4Wc5E4tG9TU3bG4yoVsO2HG05Eg-LBf0zYCee2OPSw_tUZaSFratt3CfeOZ_2Ge-agjMsDmm9UXoZ47G-sE0OpP2Vlls0QsITadZg00hShqmDznjh3Po_ZuVSFJCufNUlFujFZfR-XRKc8avWR1_NNT-K2wUBhFhE0a7vgzQystH_vOYuXVP1Hkk64gJSSWD4p5X8Pdq5mhjKZk_YU0L1rfQc-nVnvU-SXfmGf5fbcfmitLFPuMNh2UoSN8qfw4DCpeCX0KUpKFxn970NwEsz3BbxUnb_EhvoM6GV1sz0a0Km-EmeYjhmeNUoBn3q8VyqYE7fwqyGFM4qb1Dxi6mqqx5Dq-eVHTjHgBBiz8S-N9GBPOXLHc2mHksGkqB6CXG6cJLFZY9KNi_HKts0Qhbw9tkKGn_EBJCzQiimkRqvNw8TSbUpzhfLiLPWJxf3P6o4geguSa4GUFlMa7MNTwljDhPt0gb07mQaV71KxPPvXMvi7OaYLhGBJYLA1NhDofl1WDfSH0dLWo9ZRG4tw9GDJY0XsNd2FcMzja83BPuQOT0LxmZpfIe0JGtMA_UFbVAxSdhLLTXk8d6oGMI30vLXjLKg2po577aMaFrUpWEwNb2ErJ8aOHLyi9K6LLkATn4x6PuPdcSpjqcwvBdLzTJD1ggxKgdbhPhYX20f5qaeZ9w5Sj6wG_yXT7tee77dLepM9DyEMUrjRw0FmhlMiZnmLSMg5qUfie4RcMgxTqgSXDpy1G00",[133,246,248],{"id":247},"les-composants-rust","Les composants Rust",[12,250,251],{},"L'ensemble de la solution est écrit en Rust. Côté serveur, quatre microservices ; côté client, un démon déployé sur\nchaque machine à sauvegarder :",[22,253,254,267],{},[25,255,256],{},[28,257,258,261,264],{},[31,259,260],{},"Composant",[31,262,263],{},"Déployé sur",[31,265,266],{},"Rôle",[41,268,269,282,298,313,325],{},[28,270,271,276,279],{},[46,272,273],{},[184,274,275],{},"api_server",[46,277,278],{},"Serveur",[46,280,281],{},"API REST\u002FGraphQL pour l'interface Vue.js — hors du chemin de sauvegarde",[28,283,284,289,291],{},[46,285,286],{},[184,287,288],{},"client_api_server",[46,290,278],{},[46,292,293,294,297],{},"Reçoit les connexions mTLS de ",[184,295,296],{},"ws_client_daemon"," pour le signalement online\u002Foffline",[28,299,300,305,307],{},[46,301,302],{},[184,303,304],{},"job_worker",[46,306,278],{},[46,308,309,310,312],{},"Exécute les sauvegardes : connexion gRPC vers ",[184,311,296],{},", transfert des chunks, déduplication",[28,314,315,320,322],{},[46,316,317],{},[184,318,319],{},"scheduler",[46,321,278],{},[46,323,324],{},"Gère le planning, déclenche les jobs selon les règles définies",[28,326,327,331,334],{},[46,328,329],{},[184,330,296],{},[46,332,333],{},"Chaque périphérique",[46,335,336,337,339],{},"Reçoit les connexions de ",[184,338,304],{},", crée les snapshots, envoie les chunks",[12,341,342,343,349,350,353],{},"La gestion des jobs de sauvegarde est assurée par ",[49,344,348],{"href":345,"rel":346},"https:\u002F\u002Fgithub.com\u002Fgeofmureithi\u002Fapalis",[347],"nofollow","Apalis",", qui s'appuie sur\n",[155,351,352],{},"Redis\u002FValkey"," comme backend de file d'attente. Apalis remplace ici BullMQ, qui remplissait ce rôle dans l'ancienne\nversion NestJS. C'est une architecture simple et fiable, qui permet également de distribuer les workers si un jour\nl'infrastructure venait à grossir.",[133,355,357],{"id":356},"le-pool-de-stockage-cas-blake3zstd","Le pool de stockage : CAS Blake3+Zstd",[12,359,360,361,365],{},"Le cœur du système est le pool CAS (",[362,363,364],"em",{},"Content-Addressable Storage","). Son fonctionnement est le suivant :",[367,368,369,377,384,387],"ol",{},[370,371,372,373,376],"li",{},"Chaque fichier est découpé en ",[155,374,375],{},"chunks"," de taille variable.",[370,378,379,380,383],{},"Chaque chunk est haché avec ",[155,381,382],{},"Blake3"," (un algorithme de hachage moderne, très rapide).",[370,385,386],{},"Si le hash du chunk est déjà présent dans le pool, il n'est pas retransféré ni re-stocké.",[370,388,389,390,393],{},"Si le chunk est nouveau, il est compressé avec ",[155,391,392],{},"Zstd"," avant d'être écrit sur disque.",[12,395,396],{},"La déduplication est donc réalisée au niveau des chunks, et non au niveau des fichiers entiers. Cela signifie que si\nun fichier de 10 Go n'a été modifié qu'à 1 %, seul 1 % sera retransféré et stocké.",[12,398,399,400,403],{},"Le pool maintient également un ",[155,401,402],{},"compteur de références"," (refcount) par chunk : quand une sauvegarde est supprimée,\nles chunks qui ne sont plus référencés sont supprimés du pool. Ce mécanisme de garbage collection permet de garder le\npool propre sans intervention manuelle.",[133,405,407],{"id":406},"sauvegardes-windows-vss-natif","Sauvegardes Windows : VSS natif",[12,409,410,411,414,415,418],{},"Depuis la version ",[184,412,413],{},"alpha.57",", le client Windows utilise le ",[155,416,417],{},"Volume Shadow Copy Service (VSS)"," de Windows pour créer\nun snapshot cohérent du système de fichiers avant la sauvegarde. Cela permet de sauvegarder des fichiers verrouillés\n(comme les bases de données, les fichiers de profil Outlook, etc.) sans erreur.",[12,420,421,422,424,425,428],{},"Plus besoin de rsync, de Cygwin, ou d'outils tiers : le client ",[184,423,296],{}," est un binaire Rust natif pour\nWindows, compilé avec la cible ",[184,426,427],{},"x86_64-pc-windows-msvc",", qui utilise les APIs Win32 directement. C'est\nnettement plus propre que l'ancienne approche.",[133,430,432],{"id":431},"sauvegardes-linux-snapshots-btrfs","Sauvegardes Linux : snapshots Btrfs",[12,434,435],{},"Sur les machines Linux dont le système de fichiers est Btrfs, le client crée un snapshot en lecture seule avant de\nlancer la sauvegarde. Cela garantit la cohérence des données sauvegardées, même si des fichiers sont modifiés pendant\nla sauvegarde.",[12,437,438],{},"Contrairement au premier prototype qui utilisait Btrfs côté serveur (ce qui causait les problèmes évoqués plus haut),\nici les snapshots sont créés côté client et uniquement pour la durée de la sauvegarde. C'est une utilisation beaucoup\nplus conservative de Btrfs.",[128,440,442],{"id":441},"les-défis-techniques","Les défis techniques",[133,444,446],{"id":445},"le-refcounting-un-problème-de-cohérence","Le refcounting : un problème de cohérence",[12,448,449,450,452],{},"Le plus grand défi de cette réécriture a été l'implémentation correcte du ",[155,451,402],{}," du pool CAS.",[12,454,455],{},"Le problème est le suivant : lorsqu'une sauvegarde est en cours, des chunks sont ajoutés au pool et leur refcount est\nincrémenté. Si la sauvegarde est interrompue (coupure réseau, arrêt du serveur, etc.), le pool peut se retrouver dans\nun état incohérent : des chunks présents dans le pool sans être référencés par aucune sauvegarde complète.",[12,457,458],{},"C'est la solution la plus complexe et qui a nécessité le plus de travail pour être implémentée de manière fiable. En\neffet, il faut s'assurer que le comptage de référence est bon si on ne veux pas se retrouver à éliminer des chunks encore référencés.",[12,460,461],{},"Afin de garantir que le comptage de référence est bon, un outil de récupération a été développé : il analyse le pool et les manifestes des sauvegardes, et corrige les refcounts en cas d'incohérence. Il n'est normallement nécessaire qu'en cas de\ncrash du serveur (coupure de courant, etc.) pendant une sauvegarde.",[12,463,464],{},"Actuellement la structure du pool repose sur le système de fichiers. L'inconvénient est à aujourd'hui la durée\nd'execution du fsck qui peut être très longue (taille du pool). En échange les opérations de lecture\u002Fécriture sont très\nrapides.",[133,466,468],{"id":467},"les-breaking-changes","Les BREAKING CHANGES",[12,470,471],{},"Par rapport à la version 1, on est sur une réécriture complète. Vu le peu de monde qui utilise cette version 1, il n'y a\npas de migration prévue. La version 2 est un nouveau projet, avec une nouvelle API, et des changements majeurs dans la façon dont les sauvegardes sont gérées.",[133,473,475],{"id":474},"windows-sans-rsync-binaire-natif-cross-compilé","Windows sans rsync : binaire natif cross-compilé",[12,477,478],{},"Dans la version 1, le client Windows était un serveur rsyncd couplé à Cygwin. C'était fonctionnel, mais peu élégant,\ndifficile à installer, et les permissions NTFS n'étaient pas correctement sauvegardées.",[12,480,481,482,484],{},"Dans la version 2, le client Windows est un binaire Rust compilé en cross-compilation depuis Linux avec la cible\n",[184,483,427],{}," et le linker LLVM\u002FClang. Le binaire est distribué seul, sans dépendance. Il se connecte au\nserveur de sauvegarde via gRPC mTLS, crée un snapshot VSS, parcourt le système de fichiers et envoie les chunks.",[12,486,487],{},"Les ACLs NTFS, les attributs étendus, les points de jonction et les liens symboliques Windows sont correctement\ngérés. C'est un vrai progrès.",[133,489,491],{"id":490},"la-sécurité-mtls-de-bout-en-bout","La sécurité : mTLS de bout en bout",[12,493,494,495,497,498,501],{},"Toutes les communications impliquant ",[184,496,296],{}," sont chiffrées et authentifiées par ",[155,499,500],{},"mutual TLS (mTLS)",".\nChaque périphérique possède un certificat client signé par une autorité de certification interne au serveur Woodstock.",[12,503,504],{},"Deux canaux mTLS distincts :",[506,507,508,518],"ul",{},[370,509,510,517],{},[155,511,512,514,515],{},[184,513,304],{}," ↔ ",[184,516,296],{}," (gRPC) : le canal de sauvegarde, à l'initiative du serveur.",[370,519,520,527],{},[155,521,522,524,525],{},[184,523,296],{}," → ",[184,526,288],{}," (REST) : le canal de présence, à l'initiative du client, qui lui permet\nde signaler son statut online\u002Foffline.",[12,529,530],{},"Cela garantit que :",[506,532,533,536,539],{},[370,534,535],{},"Les données sauvegardées sont chiffrées en transit.",[370,537,538],{},"Seul le serveur Woodstock peut déclencher une sauvegarde sur un périphérique enregistré.",[370,540,541],{},"Un périphérique ne peut pas usurper l'identité d'un autre.",[12,543,544,545,547],{},"À noter : ",[184,546,275],{},", qui sert l'interface Vue.js, ne dispose pas encore d'authentification. C'est prévu, mais pas encore fait (voir plus bas).",[128,549,551],{"id":550},"en-production-depuis-plus-dun-an","En production depuis plus d'un an",[133,553,555],{"id":554},"les-machines-sauvegardées","Les machines sauvegardées",[12,557,558],{},"Voici un tableau récapitulatif de mes neuf machines sauvegardées au 26 avril 2026 :",[22,560,561,582],{},[25,562,563],{},[28,564,565,568,570,573,576,579],{},[31,566,567],{},"Machine",[31,569,266],{},[31,571,572],{},"Sauvegardes",[31,574,575],{},"Fichiers",[31,577,578],{},"Taille brute",[31,580,581],{},"Compressé",[41,583,584,606,628,650,672,694,716,737,759],{},[28,585,586,591,594,597,600,603],{},[46,587,588],{},[184,589,590],{},"localhost",[46,592,593],{},"NAS local (Debian)",[46,595,596],{},"43",[46,598,599],{},"13 346",[46,601,602],{},"1,3 Go",[46,604,605],{},"0,8 Go",[28,607,608,613,616,619,622,625],{},[46,609,610],{},[184,611,612],{},"pc-eve",[46,614,615],{},"PC principal de la famille (Windows)",[46,617,618],{},"211",[46,620,621],{},"563 333",[46,623,624],{},"473 Go",[46,626,627],{},"413 Go",[28,629,630,635,638,641,644,647],{},[46,631,632],{},[184,633,634],{},"pc-m-eve",[46,636,637],{},"Ordinateur portable familial (Windows)",[46,639,640],{},"26",[46,642,643],{},"146 243",[46,645,646],{},"21,6 Go",[46,648,649],{},"13,5 Go",[28,651,652,657,660,663,666,669],{},[46,653,654],{},[184,655,656],{},"pc-m-ulrich",[46,658,659],{},"Mon portable personnel (Linux)",[46,661,662],{},"53",[46,664,665],{},"43 185",[46,667,668],{},"125 Go",[46,670,671],{},"64,5 Go",[28,673,674,679,682,685,688,691],{},[46,675,676],{},[184,677,678],{},"pc-ulrich",[46,680,681],{},"Mon PC de bureau (Linux)",[46,683,684],{},"322",[46,686,687],{},"1 385 001",[46,689,690],{},"108 Go",[46,692,693],{},"76,7 Go",[28,695,696,701,704,707,710,713],{},[46,697,698],{},[184,699,700],{},"pc-alex-linux",[46,702,703],{},"PC Linux secondaire",[46,705,706],{},"4",[46,708,709],{},"210 006",[46,711,712],{},"25 Go",[46,714,715],{},"14,5 Go",[28,717,718,723,726,729,732,735],{},[46,719,720],{},[184,721,722],{},"pc-alex-windows",[46,724,725],{},"PC Windows secondaire",[46,727,728],{},"360",[46,730,731],{},"429 368",[46,733,734],{},"147 Go",[46,736,690],{},[28,738,739,744,747,750,753,756],{},[46,740,741],{},[184,742,743],{},"server",[46,745,746],{},"Serveur dédié OVH principal",[46,748,749],{},"450",[46,751,752],{},"243 074",[46,754,755],{},"810 Go",[46,757,758],{},"752 Go",[28,760,761,766,769,772,775,778],{},[46,762,763],{},[184,764,765],{},"server-ovh-6",[46,767,768],{},"Second serveur OVH",[46,770,771],{},"472",[46,773,774],{},"493 441",[46,776,777],{},"194 Go",[46,779,780],{},"173 Go",[12,782,783],{},"Quelques observations :",[506,785,786,798,805],{},[370,787,788,792,793,797],{},[155,789,790],{},[184,791,743],{}," et ",[155,794,795],{},[184,796,765],{}," ont le plus grand nombre de sauvegardes (450 et 472). Ce sont des serveurs qui\ntournent 24\u002F7, avec des données critiques.",[370,799,800,804],{},[155,801,802],{},[184,803,678],{}," cumule plus de 1,3 million de fichiers sauvegardés, ce qui en fait la machine avec le plus grand\nnombre de fichiers individuels. Mon répertoire de développement est manifestement très fragmenté. 😄",[370,806,807,808,812,813,817],{},"La compression Zstd est particulièrement efficace sur ",[155,809,810],{},[184,811,656],{}," (49 % d'économie) et beaucoup moins\nsur ",[155,814,815],{},[184,816,743],{}," (7 %), ce qui s'explique par la nature des données stockées : données de développement vs.\ndonnées déjà compressées (archives, images Docker, etc.).",[133,819,821],{"id":820},"le-pool-global","Le pool global",[12,823,824],{},"Le pool CAS central agrège toutes les sauvegardes :",[22,826,827,837],{},[25,828,829],{},[28,830,831,834],{},[31,832,833],{},"Statistique",[31,835,836],{},"Valeur",[41,838,839,847,855,863,871],{},[28,840,841,844],{},[46,842,843],{},"Chunks uniques",[46,845,846],{},"3 365 564",[28,848,849,852],{},[46,850,851],{},"Références totales",[46,853,854],{},"60 888 193",[28,856,857,860],{},[46,858,859],{},"Espace pool compressé",[46,861,862],{},"1,95 To",[28,864,865,868],{},[46,866,867],{},"Espace disque total",[46,869,870],{},"9,6 To",[28,872,873,876],{},[46,874,875],{},"Espace disque utilisé",[46,877,878],{},"6,4 To",[12,880,881],{},"Le ratio références\u002Fchunks (60,9 M \u002F 3,4 M ≈ 18x) illustre l'efficacité de la déduplication : chaque chunk unique est\nen moyenne référencé 18 fois par différentes sauvegardes. L'historique long des sauvegardes explique cette valeur\nélevée.",[133,883,885],{"id":884},"interface-web","Interface web",[12,887,888],{},"L'interface web Vue.js 3 \u002F Vuetify permet de visualiser l'état de l'infrastructure, du pool, et de l'historique des\nsauvegardes de chaque machine.",[12,890,891],{},[121,892],{"alt":893,"src":894,"className":895},"Page Devices - liste des machines sauvegardées","\u002FWoodstock\u002Fv2_devices.png",[126],[12,897,898],{},"La page principale liste les neuf machines avec leur état, le nombre de sauvegardes, la taille brute et compressée.",[12,900,901],{},[121,902],{"alt":903,"src":904,"className":905},"Page Pool - statistiques du pool CAS","\u002FWoodstock\u002Fv2_pool.png",[126],[12,907,908],{},"La page pool affiche les statistiques globales du stockage : occupation disque, nombre de chunks, nombre de\nréférences, et l'évolution depuis le mois précédent.",[12,910,911],{},[121,912],{"alt":913,"src":914,"className":915},"Page Backups - détail des sauvegardes d'une machine","\u002FWoodstock\u002Fv2_host_detail.png",[126],[12,917,918],{},"La page de détail d'une machine liste l'historique complet de ses sauvegardes avec la date, la durée, et la liste des\npartitions sauvegardées.",[12,920,921],{},[121,922],{"alt":923,"src":924,"className":925},"Liste des sauvegardes avec état, durée et politique de rétention","\u002FWoodstock\u002Fv2_backup_list.png",[126],[12,927,928,929,932,933,932,936,939,940,179],{},"Chaque entrée de la liste indique le numéro de sauvegarde, la date de démarrage, la durée, le nombre de fichiers\ntotaux et nouveaux, les fichiers modifiés et supprimés, le compteur d'erreurs, et la politique de rétention\nappliquée : ",[155,930,931],{},"Horaire",", ",[155,934,935],{},"Quotidien",[155,937,938],{},"Hebdo"," ou ",[155,941,942],{},"Mensuel",[12,944,945],{},[121,946],{"alt":947,"src":948,"className":949},"Navigation dans les fichiers d'une sauvegarde","\u002FWoodstock\u002Fv2_backup_browse.png",[126],[12,951,952],{},"En cliquant sur une sauvegarde, on accède à la vue détaillée : statistiques complètes (fichiers, tailles, durée,\nvitesse), partitions sauvegardées avec leur type (Btrfs ou VSS), et un explorateur de fichiers permettant de\nnaviguer dans l'arborescence et de télécharger ou restaurer individuellement n'importe quel fichier.",[128,954,956],{"id":955},"perspectives","Perspectives",[133,958,960],{"id":959},"archivage-hors-site-sur-disque-usb","Archivage hors-site sur disque USB",[12,962,963],{},"Une fonctionnalité que je veux mettre en place depuis la v1 est l'archivage de la dernière version des sauvegardes\nsur un disque dur USB, qui est ensuite stocké hors-site. L'idée est d'avoir une copie physique des données dans un\nautre lieu en cas de sinistre (incendie, vol, etc.).",[12,965,966,967,179],{},"Dans la version 1 avec BackupPC, j'avais un script qui utilisait le connecteur FUSE de BackupPC pour monter les\nsauvegardes et les synchroniser avec rsync vers le disque USB. Ce script posait des problèmes avec les gros fichiers\net les permissions Windows, comme je l'avais mentionné ",[49,968,969],{"href":51},"dans le tout premier article",[12,971,972,973,976,977,980,981,984],{},"Dans Woodstock v2, l'outil en ligne de commande ",[184,974,975],{},"ws_console"," dispose d'une commande ",[184,978,979],{},"mount"," qui permet de monter\nune sauvegarde comme un système de fichiers FUSE. Il sera donc possible de faire un ",[184,982,983],{},"rsync"," depuis ce point de\nmontage vers le disque USB, avec une gestion correcte des permissions et des gros fichiers.",[12,986,987],{},"Ce n'est pas encore automatisé, mais c'est la prochaine chose que je veux mettre en place.",[133,989,991],{"id":990},"ajout-dun-format-de-stockage","Ajout d'un format de stockage",[12,993,994],{},"J'envisage également de pouvoir stocker directement le pool sur un bucket S3 ou compatible (SeaweedFS, RustFS). Avant de me lancer dans cette implémentation, je veux d'abord tester\nles performances d'un tel choix.",[128,996,998],{"id":997},"comparaison-avec-les-solutions-existantes","Comparaison avec les solutions existantes",[12,1000,1001],{},"Avant de conclure, voici une comparaison honnête avec les alternatives réalistes. Si un autre outil correspond mieux à vos besoins, utilisez-le. Sans rancune.",[12,1003,1004,1005,932,1008,932,1011,932,1014,792,1017,1020],{},"Les outils couverts : ",[155,1006,1007],{},"Restic",[155,1009,1010],{},"BorgBackup",[155,1012,1013],{},"BackupPC",[155,1015,1016],{},"URBackup",[155,1018,1019],{},"Kopia",". Ils représentent les principales solutions open-source pour une infrastructure self-hostée multi-machines — ce qui correspond grosso modo au problème que Woodstock cherche à résoudre.",[22,1022,1023,1043],{},[25,1024,1025],{},[28,1026,1027,1030,1033,1035,1037,1039,1041],{},[31,1028,1029],{},"Critère",[31,1031,1032],{},"Woodstock v2",[31,1034,1007],{},[31,1036,1010],{},[31,1038,1013],{},[31,1040,1016],{},[31,1042,1019],{},[41,1044,1045,1069,1094,1117,1142,1166,1190,1214,1238,1261,1285,1309,1333,1358,1383,1408,1427,1447,1469,1490,1510,1530,1549],{},[28,1046,1047,1052,1055,1058,1061,1064,1067],{},[46,1048,1049],{},[155,1050,1051],{},"Langage",[46,1053,1054],{},"Rust",[46,1056,1057],{},"Go",[46,1059,1060],{},"Python + C",[46,1062,1063],{},"Perl",[46,1065,1066],{},"C++",[46,1068,1057],{},[28,1070,1071,1076,1079,1082,1085,1088,1091],{},[46,1072,1073],{},[155,1074,1075],{},"Licence",[46,1077,1078],{},"MIT",[46,1080,1081],{},"BSD-2",[46,1083,1084],{},"BSD",[46,1086,1087],{},"GPL v2+",[46,1089,1090],{},"AGPLv3+",[46,1092,1093],{},"Apache 2.0",[28,1095,1096,1101,1104,1107,1110,1113,1115],{},[46,1097,1098],{},[155,1099,1100],{},"Développement actif",[46,1102,1103],{},"✅ 2026",[46,1105,1106],{},"✅ 2025",[46,1108,1109],{},"✅ 2024",[46,1111,1112],{},"❌ 2020¹",[46,1114,1103],{},[46,1116,1106],{},[28,1118,1119,1124,1127,1130,1133,1136,1139],{},[46,1120,1121],{},[155,1122,1123],{},"Modèle de synchronisation",[46,1125,1126],{},"Pull (initié par le serveur)",[46,1128,1129],{},"Push (le client pousse)",[46,1131,1132],{},"Push (SSH ou local)",[46,1134,1135],{},"Pull (rsync\u002Ftar\u002FSMB)",[46,1137,1138],{},"Pull-like (découverte LAN)",[46,1140,1141],{},"Push \u002F mode serveur",[28,1143,1144,1149,1152,1155,1158,1161,1163],{},[46,1145,1146],{},[155,1147,1148],{},"Agent requis sur le client",[46,1150,1151],{},"✅ daemon",[46,1153,1154],{},"❌ binaire unique",[46,1156,1157],{},"❌ accès SSH",[46,1159,1160],{},"❌ rsync\u002FSMB",[46,1162,1151],{},[46,1164,1165],{},"❌ \u002F ✅ serveur optionnel",[28,1167,1168,1173,1176,1179,1182,1185,1187],{},[46,1169,1170],{},[155,1171,1172],{},"Planificateur intégré",[46,1174,1175],{},"✅ (Apalis + Redis)",[46,1177,1178],{},"❌ (cron\u002Fsystemd)",[46,1180,1181],{},"❌ (cron\u002FBorgmatic)",[46,1183,1184],{},"✅",[46,1186,1184],{},[46,1188,1189],{},"✅ (mode serveur)",[28,1191,1192,1197,1200,1203,1206,1209,1211],{},[46,1193,1194],{},[155,1195,1196],{},"Backends cloud\u002Fdistants",[46,1198,1199],{},"❌ self-hosted uniquement",[46,1201,1202],{},"✅ S3, B2, SFTP, Azure, GCS, rclone…",[46,1204,1205],{},"⚠️ SSH \u002F BorgBase",[46,1207,1208],{},"❌ disque local uniquement",[46,1210,1199],{},[46,1212,1213],{},"✅ S3, Azure, GCS, B2, SFTP, rclone…",[28,1215,1216,1221,1224,1227,1230,1233,1236],{},[46,1217,1218],{},[155,1219,1220],{},"Format de stockage",[46,1222,1223],{},"Pool CAS, fichiers sur disque",[46,1225,1226],{},"Pack files CAS",[46,1228,1229],{},"Journal de segments + index",[46,1231,1232],{},"Pool MD5 (niveau fichier) + reverse deltas",[46,1234,1235],{},"Snapshots de fichiers + images de blocs",[46,1237,1226],{},[28,1239,1240,1245,1248,1250,1253,1256,1259],{},[46,1241,1242],{},[155,1243,1244],{},"Granularité de déduplication",[46,1246,1247],{},"Chunk (CDC)",[46,1249,1247],{},[46,1251,1252],{},"Chunk (BUZHASH CDC)",[46,1254,1255],{},"Fichier (MD5 fichier complet, sans hardlinks en v4)",[46,1257,1258],{},"Fichier",[46,1260,1247],{},[28,1262,1263,1268,1271,1274,1277,1280,1283],{},[46,1264,1265],{},[155,1266,1267],{},"Dédup cross-machines",[46,1269,1270],{},"✅ (un pool partagé)",[46,1272,1273],{},"⚠️ uniquement si dépôt partagé",[46,1275,1276],{},"⚠️ uniquement au sein d'un dépôt",[46,1278,1279],{},"✅ (pool MD5 partagé)",[46,1281,1282],{},"✅ (niveau fichier)",[46,1284,1276],{},[28,1286,1287,1292,1294,1297,1300,1303,1306],{},[46,1288,1289],{},[155,1290,1291],{},"Compression",[46,1293,392],{},[46,1295,1296],{},"Zstd (depuis 0.14)",[46,1298,1299],{},"lz4, zstd, zlib, lzma",[46,1301,1302],{},"gzip \u002F bzip2",[46,1304,1305],{},"lzo \u002F zstd (optionnel)",[46,1307,1308],{},"zstd, lz4, gzip…",[28,1310,1311,1316,1319,1322,1325,1327,1330],{},[46,1312,1313],{},[155,1314,1315],{},"Chiffrement au repos",[46,1317,1318],{},"❌ pool en clair",[46,1320,1321],{},"✅ AES-256-CTR + Poly1305 (obligatoire)",[46,1323,1324],{},"✅ AES-256-CTR + HMAC (optionnel)",[46,1326,1318],{},[46,1328,1329],{},"⚠️ optionnel",[46,1331,1332],{},"✅ AES-256-GCM ou ChaCha20 (optionnel)",[28,1334,1335,1340,1343,1346,1349,1352,1355],{},[46,1336,1337],{},[155,1338,1339],{},"Chiffrement en transit",[46,1341,1342],{},"✅ mTLS (gRPC + REST)",[46,1344,1345],{},"⚠️ dépend du backend",[46,1347,1348],{},"⚠️ SSH ou local",[46,1350,1351],{},"⚠️ SSH ou SMB (optionnel)",[46,1353,1354],{},"⚠️ TLS optionnel",[46,1356,1357],{},"⚠️ TLS en mode serveur (optionnel)",[28,1359,1360,1365,1368,1371,1374,1377,1380],{},[46,1361,1362],{},[155,1363,1364],{},"Vérification d'intégrité",[46,1366,1367],{},"Hash Blake3 par chunk",[46,1369,1370],{},"SHA-256 par blob",[46,1372,1373],{},"HMAC-SHA256 \u002F BLAKE2b",[46,1375,1376],{},"MD5 fichier complet (v4+)",[46,1378,1379],{},"Hash",[46,1381,1382],{},"BLAKE2B ou SHA256",[28,1384,1385,1390,1393,1396,1399,1402,1405],{},[46,1386,1387],{},[155,1388,1389],{},"Modèle d'authentification",[46,1391,1392],{},"mTLS par appareil (CA interne)",[46,1394,1395],{},"Mot de passe + fichiers clés",[46,1397,1398],{},"Clés SSH + passphrase",[46,1400,1401],{},"Clés SSH",[46,1403,1404],{},"Certificats clients optionnels",[46,1406,1407],{},"Mot de passe + TLS optionnel",[28,1409,1410,1415,1417,1419,1421,1423,1425],{},[46,1411,1412],{},[155,1413,1414],{},"Linux",[46,1416,1184],{},[46,1418,1184],{},[46,1420,1184],{},[46,1422,1184],{},[46,1424,1184],{},[46,1426,1184],{},[28,1428,1429,1434,1437,1439,1441,1443,1445],{},[46,1430,1431],{},[155,1432,1433],{},"macOS",[46,1435,1436],{},"❌²",[46,1438,1184],{},[46,1440,1184],{},[46,1442,1184],{},[46,1444,1184],{},[46,1446,1184],{},[28,1448,1449,1454,1457,1459,1462,1465,1467],{},[46,1450,1451],{},[155,1452,1453],{},"Windows (natif)",[46,1455,1456],{},"✅ (binaire MSVC)",[46,1458,1184],{},[46,1460,1461],{},"❌ (WSL2 uniquement)",[46,1463,1464],{},"⚠️ (rsync\u002FCygwin ou SMB)",[46,1466,1184],{},[46,1468,1184],{},[28,1470,1471,1476,1478,1481,1484,1486,1488],{},[46,1472,1473],{},[155,1474,1475],{},"Snapshots VSS (Windows)",[46,1477,1184],{},[46,1479,1480],{},"✅ (depuis 0.12)",[46,1482,1483],{},"❌",[46,1485,1483],{},[46,1487,1184],{},[46,1489,1184],{},[28,1491,1492,1497,1499,1502,1504,1506,1508],{},[46,1493,1494],{},[155,1495,1496],{},"Snapshots Btrfs (Linux)",[46,1498,1184],{},[46,1500,1501],{},"❌ (hooks manuels)",[46,1503,1501],{},[46,1505,1483],{},[46,1507,1483],{},[46,1509,1483],{},[28,1511,1512,1517,1519,1521,1523,1525,1528],{},[46,1513,1514],{},[155,1515,1516],{},"Sauvegarde image \u002F bare-metal",[46,1518,1483],{},[46,1520,1483],{},[46,1522,1483],{},[46,1524,1483],{},[46,1526,1527],{},"✅ (Windows + Linux)",[46,1529,1483],{},[28,1531,1532,1537,1539,1541,1543,1545,1547],{},[46,1533,1534],{},[155,1535,1536],{},"Montage FUSE",[46,1538,1184],{},[46,1540,1184],{},[46,1542,1184],{},[46,1544,1483],{},[46,1546,1483],{},[46,1548,1184],{},[28,1550,1551,1555,1558,1561,1564,1567,1569],{},[46,1552,1553],{},[155,1554,885],{},[46,1556,1557],{},"✅ (sans auth pour l'instant)",[46,1559,1560],{},"❌ (tiers : Restic Browser)",[46,1562,1563],{},"❌ (tiers : Vorta)",[46,1565,1566],{},"✅ (CGI\u002FPerl)",[46,1568,1184],{},[46,1570,1571],{},"✅ (KopiaUI)",[12,1573,1574],{},"¹ La dernière version de BackupPC date de juin 2020. La base de code est stable mais n'est plus maintenue.",[12,1576,1577],{},"² La prise en charge de macOS n'est pas encore implémentée dans Woodstock.",[12,1579,1580],{},"Quelques points à souligner :",[12,1582,1583,1584,1586],{},"Le ",[155,1585,236],{}," (Woodstock, BackupPC, URBackup) signifie qu'un client compromis ne peut pas écrire de données arbitraires sur le serveur de sauvegarde. Le modèle push (Restic, Borg, Kopia) est plus simple à mettre en place, mais accorde davantage de confiance à chaque client.",[12,1588,1589,1590,1593],{},"La ",[155,1591,1592],{},"déduplication au niveau des chunks"," signifie que si un fichier de 10 Go est modifié d'1 Ko, seul cet 1 Ko est transféré et stocké. La déduplication au niveau fichier (BackupPC, URBackup) signifie que si un fichier change, le nouveau fichier entier est stocké dans le pool. Pour BackupPC spécifiquement, rsync gère le transfert de manière efficiente — seuls les blocs modifiés transitent sur le réseau — mais comme la correspondance dans le pool est basée sur un MD5 du fichier complet, un fichier modifié génère toujours une nouvelle entrée complète dans le pool. Pour les gros fichiers mutables — bases de données, disques de machines virtuelles, fichiers PST Outlook — la différence d'efficacité de stockage est considérable.",[12,1595,1589,1596,1599],{},[155,1597,1598],{},"déduplication cross-machines"," est moins courante. Si dix machines possèdent chacune une copie du même installeur de 500 Mo, Woodstock ne le stocke qu'une seule fois. Restic et Borg ne dédupliquent qu'au sein d'un même dépôt — pour obtenir une déduplication cross-machines, il faudrait mettre toutes les machines dans le même dépôt, ce qui crée des problèmes de contention de verrous et de contrôle d'accès.",[12,1601,1602,1603,1606],{},"La principale faiblesse de Woodstock : ",[155,1604,1605],{},"le pool n'est pas chiffré au repos",". Si quelqu'un obtient un accès physique ou système à votre NAS, il peut lire vos données de sauvegarde directement. L'approche de Restic — tout chiffrer, de manière obligatoire — est clairement plus solide si quelqu'un met la main sur votre disque. Sur un NAS de LAN privé que vous contrôlez physiquement, c'est un compromis que j'accepte. Pour un stockage distant ou dans le cloud, c'est une vraie limitation. Il est possible de contrer ce problème en chiffrant le disque lui-même (LUKS, BitLocker, etc.), mais c'est une couche supplémentaire à gérer.",[12,1608,1609,1610,1613,1614,1617],{},"Si vous avez besoin d'une ",[155,1611,1612],{},"restauration bare-metal",", URBackup est le seul outil de cette liste qui le fait nativement. Si vous avez besoin de ",[155,1615,1616],{},"BorgBackup sur Windows",", c'est impossible sans WSL2.",[128,1619,1621],{"id":1620},"conclusion","Conclusion",[12,1623,1624],{},"Ce projet m'a appris énormément de choses : Rust, gRPC, mTLS, la gestion de pools CAS, le VSS Windows, les snapshots\nBtrfs, la gestion de jobs distribués avec Redis, et probablement une dizaine d'autres sujets que j'ai oubliés depuis.",[12,1626,1627],{},"Est-ce que c'était raisonnable de passer six ans à construire son propre logiciel de sauvegarde alors qu'il en existe\ndes dizaines ? Bien sur que oui 😄.",[12,1629,1630,1631,1636,1637,179],{},"Le logiciel est disponible sur ",[49,1632,1635],{"href":1633,"rel":1634},"https:\u002F\u002Fgogs.shadoware.org\u002FShadowareOrg\u002Fwoodstock-backup",[347],"mon instance Gitea"," et la\ndocumentation est sur ",[49,1638,1641],{"href":1639,"rel":1640},"https:\u002F\u002Fwoodstock.shadoware.org",[347],"woodstock.shadoware.org",[12,1643,1644],{},"À bientôt !",{"title":1646,"searchDepth":1647,"depth":1647,"links":1648},"",2,[1649,1658,1665,1671,1676,1680,1681],{"id":130,"depth":1647,"text":131,"children":1650},[1651,1653,1654,1655,1656,1657],{"id":135,"depth":1652,"text":136},3,{"id":149,"depth":1652,"text":150},{"id":171,"depth":1652,"text":172},{"id":193,"depth":1652,"text":194},{"id":204,"depth":1652,"text":205},{"id":214,"depth":1652,"text":215},{"id":225,"depth":1647,"text":226,"children":1659},[1660,1661,1662,1663,1664],{"id":229,"depth":1652,"text":230},{"id":247,"depth":1652,"text":248},{"id":356,"depth":1652,"text":357},{"id":406,"depth":1652,"text":407},{"id":431,"depth":1652,"text":432},{"id":441,"depth":1647,"text":442,"children":1666},[1667,1668,1669,1670],{"id":445,"depth":1652,"text":446},{"id":467,"depth":1652,"text":468},{"id":474,"depth":1652,"text":475},{"id":490,"depth":1652,"text":491},{"id":550,"depth":1647,"text":551,"children":1672},[1673,1674,1675],{"id":554,"depth":1652,"text":555},{"id":820,"depth":1652,"text":821},{"id":884,"depth":1652,"text":885},{"id":955,"depth":1647,"text":956,"children":1677},[1678,1679],{"id":959,"depth":1652,"text":960},{"id":990,"depth":1652,"text":991},{"id":997,"depth":1647,"text":998},{"id":1620,"depth":1647,"text":1621},"Woodstock","woodstock","2026-04-26",{"type":9,"value":1686},[1687,1689,1691,1693,1757,1759],[12,1688,14],{},[12,1690,17],{},[12,1692,20],{},[22,1694,1695,1705],{},[25,1696,1697],{},[28,1698,1699,1701,1703],{},[31,1700,33],{},[31,1702,36],{},[31,1704,39],{},[41,1706,1707,1717,1727,1737,1747],{},[28,1708,1709,1713,1715],{},[46,1710,1711],{},[49,1712,52],{"href":51},[46,1714,55],{},[46,1716,58],{},[28,1718,1719,1723,1725],{},[46,1720,1721],{},[49,1722,66],{"href":65},[46,1724,69],{},[46,1726,72],{},[28,1728,1729,1733,1735],{},[46,1730,1731],{},[49,1732,80],{"href":79},[46,1734,83],{},[46,1736,86],{},[28,1738,1739,1743,1745],{},[46,1740,1741],{},[49,1742,94],{"href":93},[46,1744,97],{},[46,1746,100],{},[28,1748,1749,1753,1755],{},[46,1750,1751],{},[49,1752,108],{"href":107},[46,1754,111],{},[46,1756,114],{},[12,1758,117],{},[12,1760,1761],{},[121,1762],{"alt":123,"src":124,"className":1763},[126],"md","Lille, France",{"planet":1767},true,"\u002Fpost\u002Fwoodstock_v2",{"title":6,"description":14},"woodstock_v2","posts\u002FWoodstock\u002F2026-04-26_woodstock_v2",[1683,1773,1774,1775,1776],"backup","sauvegarde","rust","grpc",22,"gu0ISxCDyWPA2zrYBtgiI1k0uw4o8BK0cd-5g09z838",1777582399251]