Mes sauvegardes avec restic : 1,4 To de S3 offert, et enfin une vraie stratégie

Je savais que je n'avais pas de vraies sauvegardes. Comme tout le monde, j'ai reporté, encore, et encore, et encore : c'est long, c'est compliqué, et j'avais jamais le temps. Très important MAIS jamais prioritaire, donc ça passe toujours après tout le reste.

Si je m'y suis enfin mis, c'est parce que Claude (l'IA d'Anthropic) m'a aidé de bout en bout : le plan, les scripts, les déploiements, les tests. Sans lui, honnêtement, je ne me serais jamais lancé là-dedans.

Mes ~300 Go de photos tournent sur un Immich auto-hébergé. Les originaux sont rangés sur une Storage Box Hetzner, montée en rclone chiffré. C'est pratique, c'est pas cher, ça marche. MAIS c'est la seule copie. Le jour où la box lâche, ou le jour où je paume la clé de chiffrement : RIP toutes mes photos.

Et puis Next (ex-Next INpact) s'est mis à offrir à ses abonnés 1 To de stockage S3, plus 100 Go par année d'ancienneté. Chez moi ça fait 1,4 To qui dormaient. Elle est où l'arnaque ? Pas vraiment d'arnaque, on en reparle plus bas.

Bref, l'occasion de tout remettre à plat et de faire une vraie stratégie de sauvegarde, au lieu d'une collection de scripts qui marchent « normalement ».

D'abord, trier : tout ne se vaut pas

Avant de parler outils, j'ai fait la liste de ce que je veux VRAIMENT garder. Et assez vite, ça tombe en deux tas.

Le petit tas qui pique : les mots de passe (export chiffré de Vaultwarden), les bases et fichiers de mes sites WordPress, les configs de mes serveurs (docker-compose, .env, vault Ansible), le dump de la base d'Immich, quelques Go de paperasse administrative. Pas lourd. MAIS si ça fuit ou si ça disparaît, c'est la galère absolue.

Et pour moi, c'est pas qu'une question de confort perso. Je suis à mon compte, et je gère des sites pour des clients. Ces WordPress, c'est de la prod : le jour où un client me demande de remettre son site d'hier, « ah bah j'ai pas de sauvegarde » n'est PAS une réponse possible. Professionnellement, il faut que ces sauvegardes existent, qu'elles tournent toutes seules, et que je sache qu'elles marchent.

Le gros tas qui pèse : les photos et vidéos d'Immich (~300 Go), et une partie de mon Drive (1,2 To au total, dont une bonne partie peut dégager, il faut juste que je me motive pour faire le tri).

Et il y a ce que je ne sauvegarde pas, et c'est tout aussi important de le décider :

• les vidéos réencodées et les miniatures d'Immich (~57 Go + 25 Go) : Immich les régénère tout seul à partir des originaux ;
• les films, séries et autres téléchargements (~160 Go) : ça se retélécharge.

Petit piège au passage : Immich m'affichait « 553 GiB utilisés ». C'est l'occupation de tout le disque où il est monté, pas de mes photos. J'ai failli dimensionner sur le double de ce qu'il fallait.

Où mettre tout ça ? La règle du 3-2-1

La règle est vieille comme le monde : 3 copies, sur 2 supports différents, dont 1 hors de chez toi. Mes candidats :

Ce qui donne :

• le petit tas → Next + Hetzner chaque nuit, et les disques de temps en temps ;
• le gros tas → Next chaque nuit + les disques de temps en temps. Les photos ont ENFIN une deuxième copie.

Deux détails qui changent tout côté Hetzner. Les serveurs écrivent avec un sous-compte qui ne voit que son dossier : même piraté, un serveur ne peut pas toucher aux originaux des photos. Et la Storage Box fait un snapshot automatique chaque matin (7 gardés, inclus dans le prix). Un serveur ne peut pas les effacer : c'est ma ceinture de sécurité contre le pire scénario, celui où un attaquant supprime les sauvegardes en ligne.

Quant aux disques : un chez moi, un ailleurs, et on les échange de temps en temps. Si ma maison brûle, il reste une copie ailleurs, au pire un peu vieille. Là on est au-delà du 3-2-1. 😎

Et avec 2 To par disque, tout rentre : ~300 Go de photos, quelques Go de critique, et il reste de la place pour le Drive une fois trié (budget ~700-800 Go, pour tenir aussi dans les 1,4 To de Next avec l'historique).

Le S3 de Next, alors, elle est où l'arnaque ?

Il n'y en a pas vraiment, mais il faut lire la FAQ jusqu'au bout :

• c'est du best-effort sur un seul site. Next le dit lui-même : ne comptez pas que sur nous, faites du 3-2-1. Respect pour l'honnêteté
• un seul bucket, et c'est à toi de chiffrer avant d'envoyer
• la clé secrète n'est pas stockée chez eux : tu la perds, c'est fini
• si tu arrêtes l'abonnement : 30 jours normaux, 30 jours en lecture seule, puis tout est effacé.

Bref, parfait comme UNE des copies. Pas comme la seule.

Pourquoi restic (et pas un script maison)

J'ai hésité à tout faire à la main avec tar, gpg et rclone. MAIS un script maison, il faut le tester, le surveiller, le maintenir, et c'est exactement le genre de truc qui finit par planter en silence sans que personne ne le voie. Done is better than perfect, d'accord. Une sauvegarde, il vaut mieux qu'elle soit les deux.

J'ai pris restic, piloté par resticprofile :

• un seul exécutable, sans dépendances, pour Mac, Linux et Windows. Dans dix ans, sur n'importe quel PC, je pourrai encore restaurer
• il parle à tout : S3, SFTP, disque local, et via rclone à peu près n'importe quoi d'autre. Next, Hetzner et le disque dur avec UN seul outil
• chiffrement obligatoire (impossible d'oublier de l'activer), déduplication, compression ;
• resticprofile, c'est un fichier YAML qui dit « ce dossier → telle destination, tel rythme, telle rétention ». Exactement la liste que je voulais
• une communauté énorme, un projet qui a passé les 10 ans. Bref, l'outil ennuyeux, dans le bon sens.

Les défauts, pour être honnête : pas d'interface graphique (il y a Backrest si tu veux), le nettoyage des vieux snapshots est lourd sur les gros dépôts, et si tu perds le mot de passe, c'est fini.

Ce que j'ai écarté :

• Borg : excellent et rapide, MAIS uniquement en SSH. Pas de S3, donc pas de Next. Eriatolc prépare d'ailleurs un article dessus, restez branchés ;
• Kopia : une jolie interface, rapide, mais plus jeune et avec une communauté plus petite
• Duplicati : c'est celui du tuto de Next, graphique, mais pas mal de retours de corruption de sa base locale
• rclone sync tout seul : ce n'est PAS une sauvegarde, c'est un miroir. Tu supprimes une photo, elle disparaît aussi de la copie à la synchro suivante. Et tu ne la reverras jamais.

Comment ça marche, en vrai

Ma première question était bête mais légitime : pour envoyer 300 Go, il faut 300 Go de libre pour faire l'archive ? Et pour restaurer, il faut tout redescendre, extraire, comparer ?

Non. restic, ce n'est pas un gros tar qu'on balance d'un bloc. Il lit tes fichiers, les découpe en petits blocs de quelques Mo, chiffre chaque bloc et l'envoie direct. Rien n'est écrit en local, à part un petit cache. Deux blocs identiques n'existent qu'une fois. Un snapshot, c'est juste la liste « ce jour-là, il y avait tels fichiers, faits de tels blocs ».

Cas 1 : le premier envoi, puis les nuits d'après

• Nuit 1 : restic lit les 300 Go et envoie 300 Go. J'avais prévu un jour ou deux : finalement ça a pris quelques heures (6 h 05 chez moi). Si ça coupe, tu relances, il reprend où il en était.
• Nuit 2 : tu as ajouté 20 photos. restic voit que tout le reste n'a pas bougé (même taille, même date) et ne le relit même pas. Il envoie 100 Mo, en quelques minutes. Et pourtant le snapshot de la nuit 2 est COMPLET.
• Tu déplaces un album : les blocs existent déjà, quasiment rien ne part.

Chaque nuit a la tête d'une sauvegarde complète, MAIS ne coûte que ce qui a changé.

Cas 2 : la photo supprimée par erreur il y a 3 mois

restic snapshots
restic restore <id-de-juillet> --include "/library/.../IMG_1234.HEIC" --target ~/recup

restic télécharge les blocs de CETTE photo (3 Mo), et c'est tout. Encore plus simple : restic mount ~/backup affiche tous les snapshots comme des dossiers datés, et tu fouilles dedans avec ton explorateur de fichiers.

Cas 3 : la catastrophe, Hetzner a cramé

restic restore latest --target /nouveau/disque/immich

Il redescend les 300 Go et écrit les fichiers directement à leur place. Pas d'archive intermédiaire : 300 Go de libre suffisent, pas 600. Tu rebranches Immich dessus, tu restaures le dump de sa base, et c'est reparti.

« J'ai fait le ménage » vs « j'ai fait une connerie »

Le jour où je vire 500 photos floues et doublons d'Immich, est-ce que les sauvegardes les suppriment aussi ? Et si c'était une erreur ?

Les snapshots déjà faits ne bougent JAMAIS. Ceux d'avant le ménage contiennent les photos, ceux d'après non. Et les photos disparaissent vraiment quand le dernier snapshot qui les contient expire. Chez moi, je garde 7 snapshots quotidiens, 4 hebdos et 12 mensuels :

C'est le temps qui fait la différence entre l'erreur et le ménage :

• une connerie : j'ai un an pour m'en rendre compte ;
• un vrai ménage : je ne fais RIEN. Les photos sortent toutes seules des sauvegardes au bout d'un an.

Et si je veux récupérer la place tout de suite (40 Go de vidéos ratées, par exemple) : restic rewrite --exclude … les retire de tous les snapshots, puis prune. Opération volontaire et rare, à faire les yeux ouverts.

Les deux disques durs (la prochaine étape)

Mes photos ne sont pas sur mon Mac, et je ne peux pas brancher un disque sur un serveur chez OVH. Donc chaque disque devient un dépôt restic de plus, rempli depuis la copie qui est chez Next. Un disque chez moi, un ailleurs.

Une fois pour toutes :

1. formater chaque disque en APFS chiffré (restic chiffre déjà, mais ça cache même la structure des dépôts) ;
2. créer les dépôts avec restic init --from-repo <next> --copy-chunker-params, pour que les deux côtés découpent les fichiers pareil et que la copie ne prenne que ce qui manque ;
3. remplir le premier depuis Next (une nuit ou deux), puis le second depuis le premier, en local, c'est bien plus rapide ;
4. poser sur chaque disque l'exécutable restic (Mac, Linux, Windows) et un LISEZMOI pour restaurer. Sans le mot de passe, évidemment.

Ensuite, en théorie une fois par mois (en vrai : quand j'y pense 🙃), je branche le disque qui est à la maison, je lance UNE commande (,sauvegarde-disque), elle copie les nouveaux blocs, vérifie un échantillon, et j'éjecte. Un disque qui revient d'ailleurs avec trois mois de retard se rattrape en une seule passe.

Les clés Next et le mot de passe restic vivent dans le trousseau du Mac, jamais dans un fichier. Le jour où j'ai besoin des disques, c'est que tout le reste a brûlé : il faut qu'ils se lisent sur n'importe quel ordinateur, avec juste la feuille de papier.

La mise en place

Bon, le plan c'est bien. Voilà ce que ça a donné en vrai, en deux jours.

Chaque serveur envoie ses propres sauvegardes

J'ai d'abord imaginé un VPS dédié, un « coffre » qui va tout chercher et qui est le seul à avoir les clés. Sur le papier, c'est le plus sûr. Dans la vraie vie : un VPS de plus à payer, à mettre à jour, à surveiller, quatre dépôts, une quinzaine de sondes… Trop compliqué. Et un argument tout bête m'a fait trancher : si la machine centrale tombe, plus rien ne part.

Donc restic tourne sur mes deux serveurs (un serveur perso, mon fourre-tout, et un serveur pro, celui des sites clients), chacun avec son propre mot de passe : un serveur piraté ne peut pas relire les sauvegardes de l'autre. Il pourrait les effacer en ligne (Next ne donne qu'une seule clé…) MAIS pas les snapshots Hetzner, ni les disques. Compromis assumé. Le tout est déployé par un seul playbook Ansible, avec des versions de restic et resticprofile figées.

Les flèches numérotées, ce sont les seuls transferts : ① le serveur pro à 4 h 30, ② le serveur perso à 5 h, ③ les photos juste après, ④ de temps en temps vers les disques.

Ce qui part chaque nuit

Les bases se dumpent toutes seules

Le script ne contient aucune liste de sites. Il trouve tout seul chaque conteneur MariaDB ou Postgres qui tourne et le dumpe, pareil pour chaque base SQLite. Nouveau site demain = sauvegardé dès la nuit suivante, sans que j'y pense.

Et pour être sûr de rien oublier, chaque site de ma config doit avoir un dump frais, sinon ça crie. Ça a servi dès le premier lancement : un site est sorti en alerte avec une base de 4 Ko. Normal, il était encore sur un mutualisé, pas encore migré. Je l'ai migré l'après-midi même, l'alerte est repassée au vert. 👌

Deux bases ont résisté : Anki garde un verrou exclusif permanent sur la sienne, et Audiobookshelf a un schéma trop récent pour le sqlite3 d'Ubuntu 22.04. Pour celles-là : copie brute (la base + son journal), à 5 h du matin, quand personne ne s'en sert.

💡 L'astuce qui divise par 20. Au début, mes dumps étaient en gzip : 250 Mo ajoutés chaque nuit alors que presque rien ne bougeait. Un .gz change en entier dès qu'une ligne de la base change, donc restic ne peut rien dédupliquer. En SQL clair, restic compresse lui-même et ne garde que les morceaux modifiés : 11 Mo par nuit.

Les chiffres

• Serveur pro : 20 Go lus, 6,8 Go stockés grâce à la déduplication et à la compression (dont 7,3 Go de médias pour un seul site).
• Premier envoi des photos : 302,7 Go en 6 h 05, lancé en priorité basse (2 cœurs, 20 Mo/s max) pour ne pas gêner Immich et Jellyfin.
• Ensuite, chaque nuit : 1 h… pour envoyer 11 Mo. Le temps passe à parcourir 83 000 photos et 55 000 dossiers à travers le montage SFTP de la Storage Box. À 5 h du matin, honnêtement, je m'en fiche.

Une seule sonde, et des mails lisibles

Chaque serveur dépose un petit fichier d'état dans le bucket (OK ou ÉCHEC, et la date). Le serveur perso lit les deux et envoie un seul statut à Gatus. Rouge = mail. Rien reçu depuis 26 h = mail aussi. Un seul voyant à regarder, c'est tout ce que je veux.

Petite galère au passage : le curl d'Ubuntu 22.04 (7.81) signe mal les requêtes S3. Résultat, un petit script Python de 60 lignes, bibliothèque standard uniquement. Et les mails de Gatus sont vraiment nuls par défaut (« failed 1 time(s) in a row », merci…), donc j'ai ajouté une description qui dit où regarder.

Et la restauration, alors ?

Testée pour Vaultwarden (mon gestionnaire de mots de passe, le truc qui me faisait le plus peur) : restauré depuis Next, base intègre, 3 utilisateurs et 561 éléments, exactement comme en prod, et un Vaultwarden jetable démarre dessus. L'ancien script maison qui le sauvegardait a été retiré dans la foulée. Toutes les procédures sont écrites dans un RESTAURATION.md, pour le jour où ce ne sera pas un test.

Ce qu'il reste

• Les sites clients, Vaultwarden et les configs, chaque nuit, à deux endroits
• Les photos, enfin en deux exemplaires
• Une sonde qui crie si ça ne tourne pas
• Un vrai test de restauration (Vaultwarden)
• Les deux disques durs
• Le Drive, une fois trié (le plus dur, comme prévu)
• Tester aussi un WordPress et quelques photos
• La feuille de papier avec les mots de passe, en deux exemplaires

⚠️ Une sauvegarde jamais restaurée n'est pas une sauvegarde. Un restic check --read-data-subset chaque semaine, et une vraie restauration de test chaque trimestre.

Voilà

Si tu es abonné à Next, va voir l'onglet Stockage de ton profil : tu as peut-être 1 To qui dort, toi aussi. Et même sans Next, la recette reste la même : trier ce qui compte, trois copies dont une ailleurs, un outil qui chiffre et qui garde l'historique, et une alerte quand ça ne tourne plus.

Le plus dur, c'est pas la technique. C'est de faire le tri dans son Drive. 😅

À bientôt pour la suite du chantier (et les corrections) !