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) :

curl -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…

Source

UNRAID c’est bien. Mais UNRAID sauvegardé c’est mieux. Enfin… à moins de refaire mon boulet…
Et je ne parle pas des données telles que photos, films, musiques, etc, au moins sécurisées par la parité, mais bien de celles liées à l’OS (configuration globale, plugins…) ou aux Dockers eux-mêmes (images, configs…).

Si on peut installer X outils de sauvegarde indépendants (Kopia, Duplicati, Restic…), je pense qu’on est surtout très nombreux à utiliser le plugin Appdata Backup (qui ne devrait plus être maintenu, mais) qui fait le boulot avec du backup incrémental des données des Dockers et du /boot. Surtout qu’on peut lui ajouter des scripts avant/après chaque étape, histoire de personnaliser à fond tout ça.

Cependant, 2 précautions valent mieux qu’une, et l’outil UNRAID Config Guardian de stephondoestech permet de créer des sauvegardes récurrentes (cron en variable du Docker) des configurations d’UNRAID et des Dockers (qui tournent, pas les stoppés pour l’instant). De surcroît avec un script de restauration d’urgence pour tout remettre en place simplement et rapidement. Utilisé en parallèle du plugin Appdata Backup, cet outil se concentre sur l’OS même, sa configuration, ses plugins et sort un gros compose.yml pour remettre en branle tous les Dockers.

« UCG » permet de lister les containers et leurs volumes/variables

et d’en faire une sauvegarde via un chemin local. Ce dernier pouvant être un disque dur, une clé USB, un montage de NAS/FTP, un montage rClone…

Et ce ne sont que des configurations, ça ne prend donc pas de place à stocker.

admin@DockerLab:/volume1/mnt/BackUp UNRAiD Config Guardian$ ls -lsha
total 308K
196K -rwxrwxrwx+ 1 admin users 195K Sep 24 15:28 container-templates.zip
 36K -rwxrwxrwx+ 1 admin users  36K Sep 24 15:28 docker-compose.yml
4.0K -rwxrwxrwx+ 1 admin users 1.2K Sep 24 15:28 README.md
4.0K -rwxrwxrwx+ 1 admin users 2.7K Sep 24 15:28 restore.sh
 68K -rwxrwxrwx+ 1 admin users  66K Sep 24 15:28 unraid-config.json

En cas de pépin, ça se restaure simplement en copiant tous les fichiers sur le serveur et en lançant restore.sh

# Unraid Backup Documentation

**Generated:** 2025-09-24 15:28:57
**Server:** HomeBox
**Containers:** 45

## Quick Recovery (Recommended: Unraid Templates)

1. Install fresh Unraid
2. Restore flash drive from backup
3. Set up disk array
4. Run: `bash restore.sh` (restores XML templates)
5. Go to Docker tab → Add Container → Select your templates
6. Configure paths and restore appdata from backup

## Files

- `unraid-config.json` - Complete system configuration
- `container-templates.zip` - XML templates for native Unraid restore
- `docker-compose.yml` - Fallback container definitions
- `restore.sh` - Automated restoration script
- `README.md` - This file

## Restore Methods

### Method 1: Native Unraid Templates (Recommended)
```bash
bash restore.sh  # Extracts templates to /boot/config/plugins/dockerMan/templates-user
```
Then use Unraid WebUI to add containers from templates.

### Method 2: Docker Compose (Emergency Fallback)
```bash
docker-compose up -d  # Or: docker compose up -d
docker-compose ps
```
Note: Bypasses Unraid's container management system.

Keep this documentation safe and test your restore process!

On le trouve évidemment dans les applis d’UNRAID, il faut cependant au préalable installer le container dockersocket. Puis on peut configurer « UCG » en y mettant l’IP de dockersocket :

Voilà le genre d’outil qui ne consomme pas de ressource, ne prend quasi pas de place et peut permettre de se sentir moins seul en cas de gros pépin

Vous avez des milliers de notes éparpillées dans Evernote, Notion, Google Keep ou ailleurs, et à juste titre, vous commencez à flipper parce que votre app favorite devient payante ou menace de fermer ? Heureusement, il y a Jimmy qui va pouvoir vous aider dans ces épreuves de la vie ^^ !

Développé par marph91, Jimmy est donc un convertisseur universel de notes qui transforme tout en Markdown. Il gère plus de 40 applications différentes et tourne sur Linux, Windows et macOS sans aucune dépendance. Vous téléchargez l’exécutable, vous le lancez, et c’est parti.

Jimmy supporte une liste impressionnante d’applications : Anki, Anytype, Bear, Cacher, CherryTree, Day One, Drafts, Evernote, Facebook, Google Docs, Google Keep, Joplin, Notion, Obsidian, QOwnNotes, Roam Research, Simplenote, Telegram, Tiddlywiki, UpNote, Zettelkasten, Zim, Zoho Notebook, et j’en passe.

Il gère aussi les formats classiques comme DOCX, ODT, HTML, EPUB, CSV et même les Jupyter Notebooks. Par contre, pas d’Apple Notes dans le lot… Pour celui-là, vous devrez utiliser Exporter .

Jimmy propose deux modes d’utilisation. Soit en ligne de commande (CLI) pour les scripteurs, et une interface texte interactive (TUI) pour les autres.

Par exemple, pour convertir un seul fichier, faites :

jimmy-linux cli mon_document.docx

jimmy-linux cli /chemin/vers/mes/notes

jimmy-linux cli takeout-20240401.zip --format google_keep

jimmy-linux cli Evernote_backup.enex