Vous savez, ce script bash de backup que vous avez écrit en 2018 et que vous n’osez plus toucher ? Celui avec les 150 lignes de mysqldump + tar + gzip + aws s3 cp qui marche à moitié et que vous relancez manuellement quand il plante ?
Hé bien vous allez pouvoir le foutre à la poubelle parce que maintenant y’a GoBackup !
GoBackup c’est un binaire codé en Go qui remplace tous vos scripts de backup maison d’un coup. MySQL, PostgreSQL, MongoDB, Redis, peu importe. Local, FTP, S3, Google Cloud, Azure, peu importe. Vous installez, vous configurez un fichier YAML, et c’est fini.
Ensuite, vous n’aurez plus jamais besoin de retoucher à tout ce bordel.
Avant GoBackup y’avait backup/backup, une gem Ruby qui faisait exactement ce job avec de la sauvegarde automatique, multi-bases, multi-destinations et c’était bien. Sauf que Ruby c’est lourd et les dépendances Ruby c’est l’enfer. Du coup le projet est mort tout doucement. Heureusement, huacnlee, un dev chinois, en a eu marre alors il a tout réécrit en Go. Zéro dépendance externe et un seul binaire compilé (installable aussi avec Brew pour ceux qui sont sous macOS).
Vous pouvez l’installer comme ceci (vérifiez le script) :
Connexioncurl -sSL https://gobackup.github.io/install | sh
Ou via homebrew comme ceci :
brew install gobackup
Avec GoBackup, vous définissez vos bases de données, vos fichiers à archiver, vos destinations de stockage, votre planning, tout dans un fichier YAML propre et ensuite le binaire gère tout : Compression, chiffrement, upload, rotation des backups, notifications si ça échoue…etc. Bref, tout ce que vous faisiez à la main avec vos scripts pourris.
Et GoBackup est pas juste un CLI (Interface en ligne de commande). C’est un CLI + un daemon + une Web UI + un scheduler. Comme ça vous lancez “gobackup start” et ça tourne en background.
Le daemon surveille alors le planning défini dans votre config et lance les backups automatiquement. Et l’interface web vous permet de voir l’état des backups, les logs, les erreurs.
Avec GoBackup, vous remplacez littéralement 5 outils en un : votre script bash + cron + un monitoring pourri + un truc pour lire les logs + l’interface d’admin que vous avez jamais eu le temps de faire.
Votre config ressemble à ça :
models:
mon_app:
compress:
type: tgz
databases:
mon_mysql:
type: mysql
host: localhost
database: ma_base
username: user
password: $MYSQL_PASSWORD
storages:
mon_s3:
type: s3
bucket: mes-backups
region: eu-west-1
access_key_id: $AWS_KEY
secret_access_key: $AWS_SECRET
schedule:
every: 1day
at: "04:05"
Et c’est tout. Avec ce fichier, GoBackup dump votre base MySQL tous les jours à 4h05, compresse en .tar.gz, chiffre si vous voulez, et upload sur S3. Et si ça échoue vous recevez une notif. Et si ça marche vous avez les logs comme ça, pas besoin de surveiller, ni de débugger à 3h du matin parce que le backup a planté et que vous avez perdu 6 mois de données.
Notez quand même que GoBackup fait du backup classique, et pas du backup incrémental intelligent à la Restic ou à la Borg donc si vous avez 500 GB de données à backup tous les jours vous allez peut-être préférer un outil plus sophistiqué mais pour 90% des cas d’usage sysadmin standard, GoBackup suffira largement.
Votre script bash dégeu a eu une belle vie, il peut maintenant partir à la retraite.
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…
VMScape (CVE-2025-40300) : une faille de sécurité affecte certains processeurs AMD et Intel, et menace les environnements Cloud avec KVM et QEMU.
The post VMScape : Linux se protège de la nouvelle vulnérabilité ciblant les CPU Intel et AMD first appeared on IT-Connect.
Le 1er septembre 2025, Cloudflare a annoncé sur son compte X avoir déjoué une cyberattaque d’une ampleur inédite. Survenue durant l’été, cette attaque par déni de service distribué (DDoS) aurait atteint un pic de 11,5 térabits par seconde, établissant ainsi un nouveau record mondial selon l’entreprise américaine spécialisée dans les solutions de sécurité cloud.
Parfois, il m’arrive d’utiliser SwissTransfer à titre personnel, mais je n’en avais encore jamais parlé ici… à tort. En tant qu’adepte de l’auto-hébergement avec mon NAS, j’essaie habituellement de gérer mes besoins de partage de fichiers avec mes propres outils. Mais il faut reconnaître qu’il y a quelques limites dès qu’il s’agit d’envoyer ponctuellement de très gros volumes à des contacts externes : bande passante restreinte, accès au NAS limité ou disponibilité variable, etc. C’est précisément pour répondre à ces situations qu’Infomaniak propose ce service gratuit qui permet d’envoyer jusqu’à 50 Go en une seule fois, simplement et sans publicité…
SwissTransfer mise avant tout sur la simplicité d’utilisation de son service :
L’expérience utilisateur est volontairement minimaliste : pas de compte à créer, pas de publicité, pas de fonctionnalités superflues. Franchement, c’est très appréciable
Tous les fichiers sont stockés dans les centres de données d’Infomaniak, situés exclusivement en Suisse. À l’expiration définie par l’utilisateur, ils sont automatiquement supprimés. Contrairement à certains services extra-européens, les fichiers ne sont pas utilisés pour l’entraînement de modèles d’IA ni exploités à des fins publicitaires. L’exemple récent de WeTransfer, qui avait annoncé vouloir entraîner ses IA avec les fichiers déposés avant de faire machine arrière, illustre bien pourquoi la question de la confiance est centrale.
SwissTransfer présente plusieurs avantages : la possibilité d’envoyer gratuitement de très gros fichiers (jusqu’à 50 Go), l’absence de publicité, une interface simple et l’assurance que les données restent stockées en Suisse. En revanche, il faut garder en tête que le service se concentre uniquement sur le transfert. Il n’offre pas de stockage permanent ni d’outils collaboratifs. Pour l’archivage ou le travail en équipe, Infomaniak propose d’autres services payants
SwissTransfer s’est rapidement imposé comme une alternative à des services dominés par les géants américains. Simple, gratuit et transparent, le service permet de partager de gros fichiers en toute sécurité, sans conditions cachées.
Et vous, utilisez-vous un service pour envoyer de gros fichiers ? Si oui, lequel et pourquoi ?
Syncthing est un logiciel open source qui permet de synchroniser des fichiers entre plusieurs appareils (ordinateurs, NAS, smartphones, etc.). Contrairement aux Clouds propriétaires, les données restent stockées sur vos propres appareils. La sortie de Syncthing 2.0 marque une étape importante et apporte de nombreuses améliorations… aussi bien pour les particuliers que pour les administrateurs de NAS.
Pour rappel, Syncthing est particulièrement intéressant pour ceux qui possèdent un NAS. En effet, le logiciel offre une synchronisation chiffrée, sécurisée et automatique… avec un contrôle total des données. C’est une solution idéale pour les particuliers et professionnels qui veulent bénéficier du confort du Cloud sans dépendre d’un fournisseur externe.
La sortie de Syncthing 2.0 marque un tournant technique, tout en maintenant la compatibilité protocolaire avec la branche 1.x. Voici les principaux changements :
Au moment d’écrire ces lignes, la version la plus récente est Syncthing 2.0.3. Elle corrige plusieurs points de jeunesse :
La réponse est oui, mais avec précaution. Avant de migrer, il est recommandé de sauvegarder le répertoire de configuration et de prévoir un temps au système… surtout si votre base de données est importante. La compatibilité avec la version 1.x permet une transition progressive, appareil par appareil.
Avec Syncthing 2.0, l’outil gagne en fiabilité et en performances sans remettre en cause ses fondamentaux : une synchronisation sécurisée, décentralisée et respectueuse de la vie privée. Pour les utilisateurs de NAS comme pour les adeptes de l’auto-hébergement, cette mise à jour constitue une évolution solide et durable.
