Sauvegardes de tes données

36 min · 11 rubriques

Ce guide parle de la seule sauvegarde qui te sauve vraiment : celle qui sort du NAS.

Tout le reste de ce que LGM-OS fait pour tes données vit dans le même dispositif. Le RAID encaisse la panne d’un disque, pas celle du dispositif. Les instantanés annulent une suppression, pas un incendie, un vol, une surtension qui emporte les disques ni un rançongiciel qui chiffre ce que le NAS a monté. La sauvegarde de la configuration (nas-config-*.tar.gz) remet le panneau comme il était, et pas un seul de tes fichiers.

1. La règle 3-2-1 appliquée à ce NAS

3 copies de chaque donnée · sur 2 supports différents · dont 1 hors du bâtiment.

Dans un NAS domestique, ça se traduit par quelque chose de très concret :

Les instantanés ne comptent pas comme une copie : ils partagent les disques avec l’original. Ils comptent comme un historique, ce qui est tout aussi utile, mais pour un autre problème.

Si tu peux, monte la barre à 3-2-1-1-0 : une des copies débranchée (un disque USB rangé dans un tiroir ou hors de chez toi, qu’on ne branche que pour copier — c’est la seule chose qu’un rançongiciel ne peut pas atteindre) et 0 erreur, c’est-à-dire des restaurations de test qu’on fait et qu’on note (section 6).

2. Quoi sauvegarder

Tout ne mérite pas de sortir du NAS : la sauvegarde externe est souvent la ressource la plus chère et la plus lente que tu aies. Trie selon ce qui se passerait si ça disparaissait.

Deux détails qu’on oublie toujours :

• Inclus la configuration du NAS. Télécharge un nas-config-*.tar.gz (Panneau de configuration → Sauvegarde de la configuration) dans un dossier qui entre dans la sauvegarde externe, ou planifie la tâche de configuration vers ce dossier. Sans elle, récupérer le dispositif revient à reconstruire à la main utilisateurs, droits d’accès et partages.
• Arrête l’écriture avant de copier les données d’une app. Une base de données copiée à chaud peut être restaurée corrompue. Arrête le conteneur (ou utilise son propre export planifié) et copie ensuite. Pour les fichiers ordinaires, ce n’est pas nécessaire.

Et attention à la corbeille réseau : elle vit dans le dossier de la maison lui-même, donc elle est copiée avec lui. Planifie une tâche « Vider la vieille corbeille » (Panneau de configuration → Tâches planifiées) pour que ce que tu as supprimé il y a des mois ne continue pas de voyager vers ta sauvegarde externe.

2 ante. Mon dossier partout (le « Drive » du NAS)

Avant tout, la phrase à lire deux fois : ceci n’est pas une sauvegarde.

Un dossier synchronisé est un miroir vivant : ce que tu enregistres sur le portable apparaît sur le NAS et sur tes autres dispositifs, et ce que tu supprimes sur l’un disparaît de tous. C’est exactement ce que tu veux pour travailler —le fichier est là où tu es— et exactement ce que tu ne veux pas pour te protéger : une suppression, un chiffrement ou un « enregistrer par dessus » voyagent aussi vite qu’un nouveau fichier. Ce qui te protège de ça, ce sont les instantanés du NAS, qui vont de leur côté, ne prennent presque pas de place et qu’un chiffrement du portable n’atteint pas.

Ça se configure dans Sauvegardes → Synchronisation, tout en haut.

Comment c’est fait

Par WebDAV, que le NAS sert déjà : tu coches « WebDAV » sur le dossier de la maison, tu le choisis ici, et il est publié. Sur l’ordinateur, on utilise rclone, qui existe pour Windows, Mac et Linux et qui est le même programme que ce NAS utilise pour tout le reste. Le panneau te donne la configuration toute prête, avec le nom du NAS, le dossier et l’intervalle déjà remplis.

Il n’y a pas de programme maison à installer sur chaque dispositif, et c’est voulu : un client de bureau pour trois systèmes, ce sont trois installateurs, trois signatures et trois mises à jour à maintenir pour toujours, et chacune est une nouvelle façon pour le NAS de ta maison de se retrouver sans support.

Le mot de passe ne sort pas du NAS. Le texte que tu copies contient un emplacement vide que tu remplis sur l’ordinateur lui-même. Un texte qu’on copie-colle finit dans le presse-papiers, dans une discussion et dans une capture d’écran.

Les conflits : on ne jette jamais rien

Deux ordinateurs touchent le même fichier sans se voir —l’un dans l’avion, l’autre à la maison—. Il y a deux règles et aucune des deux ne supprime :

Choisir à ta place et jeter le travail de l’autre n’est pas une option. Quand un conflit apparaît, le NAS te prévient en disant où se trouve l’autre version : sans cette phrase, les gens cherchent dans la corbeille et tiennent pour perdu ce qu’ils ont juste à côté.

Et ce qu’un rclone bisync à la main ne donne pas : savoir si ça marche encore

Chaque ordinateur envoie un compte rendu à la fin de chaque passage, et le panneau affiche un voyant par dispositif. Si l’un se tait, le NAS te prévient. C’est la même raison que pour les ordinateurs de la maison : un dossier qui a cessé de se synchroniser en mars a exactement la même allure qu’un dossier synchronisé il y a cinq minutes —les fichiers sont toujours là— et la différence n’apparaît que le jour où tu cherches ce que tu croyais à l’abri.

Le délai est de douze fois l’intervalle de ce dispositif : avec cinq minutes, une heure. Un portable fermé un moment n’est pas un portable cassé.

Des détails qui coûtent cher si on ne les connaît pas

• Le premier passage est différent. Il utilise --resync et apparie les deux côtés ; ensuite, on ne s’en sert plus. Le mettre à chaque passage transforme le miroir en « ce que dit l’un des deux côtés », c’est-à-dire l’ordre qui efface le travail de l’autre.
• La synchronisation se fait en tant qu’utilisateur du NAS, avec ses droits d’accès : si cette personne ne peut pas écrire dans le dossier, la synchronisation non plus.
• Arrêter de synchroniser ne supprime rien. Retirer le dossier de la liste coupe le miroir ; les fichiers restent sur le NAS et sur les ordinateurs.

2 bis. Les ordinateurs de la maison : sauvegarder le portable et le PC SUR le NAS

Tout ce qui précède parle de faire sortir du NAS ce qui s’y trouve déjà. Ici, c’est l’inverse : que le portable et le PC de la maison déposent leur sauvegarde sur le NAS. Et il y a une raison de le traiter à part : le disque d’un portable est ce qui se perd le plus dans toute la maison —il tombe, il prend l’eau, on le vole— et c’est ce que presque personne ne sauvegarde.

Dans Sauvegardes → Dispositifs, un assistant règle tout en une étape : il crée un dossier de la maison rien que pour cet utilisateur, lui fixe sa limite d’espace, active Time Machine si c’est un Mac et te dit exactement sur quoi appuyer sur ce dispositif. Aucun protocole n’est inventé : Time Machine et l’Historique des fichiers de Windows savent déjà copier vers un dossier réseau.

Ce qui compte vraiment : s’apercevoir qu’il a cessé de sauvegarder

Copier, les deux systèmes savaient déjà le faire. Ce que personne ne faisait, c’était remarquer que l’un des deux s’était arrêté, et c’est là qu’on perd vraiment des données :

• Time Machine abandonne en silence quand il ne trouve pas le disque plusieurs fois de suite.
• L’Historique des fichiers de Windows se désactive tout seul quand on change de réseau.
• Le quota se remplit et la sauvegarde cesse d’écrire.

Aucune de ces trois choses ne fait de bruit. Une sauvegarde arrêtée en mars et découverte en décembre, ce sont neuf mois de photos. C’est pour ça que chaque dispositif enregistré a son voyant —à jour, en retard, SANS SAUVEGARDE— et que le NAS te prévient quand l’un se tait. Le délai se règle par dispositif (« attendu tous les N jours ») et l’alerte ne se déclenche qu’après trois fois ce délai : un portable éteint le week-end n’est pas un portable cassé, et un système qui crie pour ça apprend à l’ignorer.

Pour savoir quand il a sauvegardé, le NAS regarde la date de l’élément le plus récent dans le dossier de ce dispositif. Rien à installer : Time Machine et l’Historique des fichiers ne racontent à personne ce qu’ils font, alors soit on regarde le dossier, soit on ne sait pas.

Le script, si tu veux choisir toi-même les dossiers

Pour Linux, ou pour qui veut quelque chose de plus précis que Time Machine, le panneau donne un script —quatre lignes de PowerShell ou de shell, avec le nom du NAS et le dossier déjà remplis— qui copie ce que tu lui indiques et raconte au NAS comment ça s’est passé. Avec le script, le voyant cesse d’être une déduction et devient un compte rendu : si robocopy ou rsync échouent, l’alerte arrive la nuit même au lieu d’attendre trois délais.

Il copie avec ce que le système fournit déjà —robocopy sous Windows, rsync sous Mac et Linux— et pas avec un programme à installer et à maintenir sur chaque portable de la maison. Et les versions, ce n’est pas le script qui les fait : il laisse un miroir, et les versions sont les instantanés du NAS, qui se font déjà tout seuls, ne prennent presque pas de place et qu’un chiffrement du PC n’atteint pas.

Le script contient un jeton propre à ce dispositif. Il sert uniquement à dire « j’ai sauvegardé » —il ne donne accès à rien— et on le révoque en retirant le dispositif de la liste.

Ce que ça ne fait PAS

Ça ne clone pas le disque entier d’un PC et ne permet pas de démarrer depuis la sauvegarde (bare metal). On copie des fichiers, pas des systèmes. Si un portable casse, tu récupères tes documents et tes photos, mais Windows ou macOS sont à réinstaller.

Et retirer un dispositif de la liste ne supprime ni son dossier ni ce qu’il a déjà copié : il n’est simplement plus surveillé. Supprimer les données de quelqu’un parce qu’on l’a retiré d’une liste, c’est le genre de surprise qu’un système de sauvegarde ne doit jamais faire.

3. Où sauvegarder

L’app gère trois types de destination : locale (un chemin du NAS, en général un disque USB monté), distante par SSH (rsync vers un autre serveur) et cloud (Google Drive, OneDrive, Dropbox, Box, pCloud, MEGA, WebDAV, Amazon S3, Wasabi, MinIO et Backblaze B2).

Une formule qui marche très bien et ne coûte rien : la sauvegarde réciproque. Ton NAS sauvegarde chez ton frère et le sien sauvegarde chez toi. Chacun fournit le disque et l’électricité, personne ne paie d’abonnement, et les deux copies sont à des kilomètres l’une de l’autre.

Blinder la destination (pour que le NAS ne puisse pas supprimer ses propres sauvegardes)

La clé SSH et le jeton du cloud vivent dans le NAS, c’est-à-dire justement la machine qu’on suppose compromise quand un chiffrement arrive. Un rançongiciel sérieux ne commence pas par tes photos : il commence par les sauvegardes, et les supprime avec tes propres identifiants avant de demander la rançon.

Chaque destination a un interrupteur Blinder cette destination, et ce qu’il fait dépend du type :

Et le plus important : on le teste, on ne le promet pas. Le bouton Tester le verrou dépose un fichier leurre sur la destination et essaie de le supprimer. Que la suppression échoue, c’est le bon résultat. C’est la seule façon de le savoir : un lock_days enregistré dans la configuration ne prouve pas que le bucket a Object Lock, et une clé « restreinte » que personne n’a testée l’est rarement. Le NAS répète ce test une fois par semaine et ne te prévient que si une destination blindée cesse de l’être — quelqu’un a réinstallé le serveur et remis la clé sans restriction, le bucket a été recréé sans Object Lock…

Pour une destination par SSH, le panneau te donne toute prête la ligne à coller dans ~/.ssh/authorized_keys de l’utilisateur des sauvegardes, à l’autre bout. L’écrire à la main, c’est là qu’on se trompe.

Sauvegardes dans le cloud

Sauvegardes → Destinations → Ajouter une destination → Cloud. Il y a deux façons de se connecter, selon le fournisseur :

• Avec ton compte (Google Drive, OneDrive, Dropbox, Box, pCloud). Le panneau te donne un lien, tu te connectes avec ton compte sur le site du fournisseur et tu recolles l’adresse vers laquelle il te redirige. Le NAS garde l’autorisation, pas ton mot de passe.
• Avec des clés (S3, Wasabi, MinIO, Backblaze B2, WebDAV, MEGA). Tu colles la clé d’accès et la clé secrète que te donne le service. Sur S3 et B2, le nom du bucket est le premier morceau du dossier de destination : monbucket/LGM-OS.

Comment les versions sont conservées. Sur un disque ou par SSH, chaque sauvegarde réutilise les fichiers qui n’ont pas changé grâce à des liens physiques, si bien qu’une version quotidienne n’occupe que ce qui a changé. Dans le cloud, il n’y a pas de liens physiques, donc ça fonctionne autrement : actual/ est un miroir de tes dossiers et, chaque fois qu’un fichier est remplacé ou supprimé, la version précédente est mise de côté dans un dossier portant la date de la sauvegarde précédente. Rien ne se perd, mais une ancienne version contient uniquement les fichiers qui ont changé ensuite, pas la photo complète de ce jour-là.

Chiffrement de bout en bout (facultatif, et recommandé). En créant la destination, tu peux activer le chiffrement : les noms et le contenu sont chiffrés sur le NAS avant tout envoi et le fournisseur ne voit que des données illisibles — ni tes photos ni leurs noms. La clé est générée par le NAS, qui te la montre une seule fois sous forme de phrase de récupération : note-la hors du NAS (papier, gestionnaire de mots de passe). Le NAS la garde pour sauvegarder chaque nuit, mais si le NAS meurt, cette phrase est la seule chose qui ouvre la sauvegarde ; avec elle et n’importe quel rclone, on récupère tout depuis n’importe quel dispositif. Ça se décide à la création de la destination et ne peut plus être changé ensuite : chiffrer une destination qui contient déjà des sauvegardes couperait le miroir en deux moitiés illisibles l’une pour l’autre. L’explorateur et la restauration fonctionnent de la même façon avec ou sans chiffrement.

Avant de commencer : regarde la taille de tes dossiers. Envoyer 2 To sur une fibre domestique à 300 Mb/s en envoi, c’est environ quinze jours à plein régime. Le plus sage est de commencer par sauvegarder uniquement l’irremplaçable (documents, photos) et de laisser de côté ce qu’on peut retélécharger.

Ce que ça ne fait PAS encore (et pourquoi on le dit ici)

• Le chiffrement d’un dossier du NAS lui-même ou d’une destination par SSH. Là, chaque version est construite avec des liens physiques vers la précédente, et un chiffrement par fichier change le contenu à chaque passage : ça casserait justement ce qui rend les versions bon marché et permet de restaurer un fichier isolé. Dans le cloud et sur un disque USB, il existe (voir plus haut et 5.1), parce que là la sauvegarde est un miroir et qu’il n’y a pas de liens physiques à perdre. Si le serveur distant n’est pas à toi, chiffre le disque à l’autre bout (LUKS).
• L’image du disque système (bare metal). En cas de catastrophe, on réinstalle depuis l’ISO et on restaure la configuration ; c’est rapide, mais ce n’est pas « cloner et démarrer ». C’est expliqué dans disaster-recovery.md.

Sur la confidentialité de la destination : le transport est chiffré quand tu sauvegardes par SSH, mais les fichiers qui arrivent sont lisibles par qui administre ce dispositif. Si la destination n’est pas à toi, chiffre le disque de destination (LUKS à l’autre bout, ou le disque USB lui-même) et garde ce mot de passe hors du NAS (gestionnaire de mots de passe, papier dans un tiroir).

4. À quelle fréquence

La bonne question n’est pas « à quelle fréquence je sauvegarde » mais combien de travail je suis prêt à perdre. C’est ça, la fréquence.

Planifie les sauvegardes en dehors de tes heures d’utilisation et pas toutes en même temps : une sauvegarde externe à la même heure qu’un scrub rend le NAS lent pendant des heures. Une bonne répartition : sauvegarde à 03:00 et scrub un dimanche par mois à 05:00.

Et une chose que personne ne fait avant que ça lui arrive : active les alertes (Panneau de configuration → Alertes, SMTP ou webhook). Une tâche de sauvegarde qui échoue en silence depuis trois mois est exactement aussi utile que pas de sauvegarde du tout. L’onglet d’état de l’app te prévient en plus quand aucune sauvegarde n’est configurée, quand la dernière a échoué, quand une tâche ne s’est pas exécutée depuis trop longtemps, quand elle est désactivée ou quand sa destination n’est pas disponible.

5. Configurer une sauvegarde pas à pas

L’app Sauvegardes sépare deux choses, et ça vaut la peine de comprendre pourquoi :

• Destinations — où on enregistre : le disque USB ou le serveur distant. On les définit une fois et on les teste avec le bouton « Tester la connexion », qui ne dit pas seulement si ça marche : il montre étape par étape quelle vérification échoue (le dossier, les droits, la clé, le rsync de l’autre côté) et quelle commande lancer pour corriger. Teste-les avant de leur faire confiance, et à nouveau quand tu changes quelque chose : une clé USB débranchée ou un serveur éteint, mieux vaut le découvrir là qu’à trois heures du matin.
• Tâches — quoi on copie et quand : dossiers source (avec exclusions facultatives), destination, horaire et ce qu’on conserve — la rétention intelligente par défaut, ou par nombre de versions, ou par ancienneté en jours.

Chaque tâche a aussi une vitesse maximale en Mo/s, à la dernière étape de l’assistant. Laisse-la vide et la sauvegarde ira aussi vite qu’elle peut ; mets-y un nombre et elle ne le dépassera pas. C’est ce que tu veux quand la sauvegarde part vers un autre dispositif ou vers le cloud et que tu ne veux pas qu’elle prenne tout l’envoi de la maison : avec 100 Mb/s en envoi (environ 12 Mo/s), une limite de 6 Mo/s laisse la moitié libre pour le reste. Ça ne freine que les sauvegardes : la restauration n’est jamais freinée, parce que là, il y a toujours quelqu’un qui attend.

Chaque exécution laisse une version restaurable sur la destination et une entrée dans l’historique (avec la date, la taille et l’erreur exacte en cas d’échec). Avec Explorer, tu entres dans n’importe quelle version comme dans un dossier —quels fichiers il y avait ce jour-là, avec leur taille et leur date— et tu restaures la version entière ou seulement ce que tu coches, jusqu’à un fichier isolé.

5.1 Vers un disque USB ou un autre pool (destination locale)

1. Branche le disque. S’il vient de Windows, formate-le depuis Stockage (ext4/Btrfs) ou laisse-le en NTFS/exFAT : LGM-OS le monte quand même, mais **NTFS et exFAT ne conservent ni les droits ni les propriétaires Linux**, donc ce que tu restaureras arrivera sans eux. Pour des sauvegardes sérieuses, utilise un disque au format Linux.
2. Crée une destination de type locale avec le chemin où le disque est monté, et teste-la : le test écrit vraiment dans ce dossier, c’est la seule façon de savoir qu’on peut le faire.
3. Crée la tâche : nom, dossiers source, cette destination, horaire et versions à conserver.
4. Lance-la une fois à la main et vérifie qu’elle se termine. Contrôle ensuite la taille sur la destination : si ça fait 4 Go pour un dossier de 400, revois les dossiers choisis comme source.

Si ce disque sort de la maison, chiffre-le. Quand le dossier de la destination se trouve sur un disque USB, l’option « Chiffrer ce qui est enregistré sur ce disque » apparaît à la création. Interrupteur activé, les noms et le contenu sont chiffrés sur le NAS avant toute écriture : un disque perdu ou volé ne peut pas être lu. Le disque garde son format habituel —exFAT, NTFS, ext4— et, avec la phrase de récupération, il s’ouvre sur n’importe quel ordinateur équipé de rclone, même si le NAS n’existe plus. La phrase n’est montrée qu’une seule fois, à la création de la destination : note-la hors du NAS et loin du disque, car sans elle, on ne récupère rien. Ça se décide à la création et ne peut plus être changé ensuite. En contrepartie, cette destination conserve les versions comme celles du cloud (un miroir actual/ et, à la date de chaque passage, ce qui a été remplacé) au lieu de liens physiques.

5.2 Vers un autre serveur par SSH (destination distante)

C’est ici que se concentrent 90 % des questions, alors on entre dans tous les détails. On appellera NAS ton dispositif et serveur distant celui qui reçoit la sauvegarde.

Étape 1 — Récupère la clé publique du NAS

Dans l’app Sauvegardes, quand tu crées une destination distante, le NAS génère sa propre paire de clés SSH et te montre la clé publique. C’est une seule ligne, qui ressemble à celle-ci :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

La clé privée reste sur le NAS, dans /etc/nas/ssh, un répertoire que seul root peut lire : ni le panneau ni aucune route de l’API ne peuvent l’afficher, parce que le processus qui sert le web tourne sans privilèges. Copie la clé publique telle quelle, en entier et sur une seule ligne : si elle se coupe en deux au collage, l’autorisation ne marchera pas.

Étape 2 — Crée l’utilisateur qui recevra la sauvegarde (sur le serveur distant)

N’utilise ni root ni ton utilisateur personnel. Un utilisateur dédié, sans mot de passe de connexion :

sudo adduser --disabled-password --gecos "" copias
sudo install -d -m 750 -o copias -g copias /copias/nas    # dossier de destination

Étape 3 — Autorise la clé (sur le serveur distant)

L’app te donne cette même commande déjà prête avec ta clé, à copier-coller dans une session SSH du serveur distant ouverte avec l’utilisateur qui recevra la sauvegarde :

mkdir -p ~/.ssh && chmod 700 ~/.ssh \
  && echo 'ssh-ed25519 AAAA…' >> ~/.ssh/authorized_keys \
  && chmod 600 ~/.ssh/authorized_keys

Si tu préfères le faire depuis un autre compte avec sudo, l’équivalent est :

sudo install -d -m 700 -o copias -g copias /home/copias/.ssh
sudo -u copias tee -a /home/copias/.ssh/authorized_keys >/dev/null
# colle ici la ligne complète de la clé publique, appuie sur Entrée puis sur Ctrl+D
sudo chmod 600 /home/copias/.ssh/authorized_keys

Les droits ne sont pas un détail esthétique : si .ssh n’est pas en 700 ou authorized_keys en 600, OpenSSH ignore la clé sans dire pourquoi et tu verras un déroutant « Permission denied (publickey) ».

Recommandé — limite ce que cette clé peut faire en ajoutant des options au début de la même ligne, avant ssh-ed25519 :

restrict,from="203.0.113.10" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

• restrict désactive la redirection de ports, l’agent, X11 et le terminal interactif. rsync continue de fonctionner (il faut OpenSSH 7.2 ou plus récent ; Debian 11 et 12 sont largement au-dessus).
• from="…" n’accepte cette clé que depuis ton IP publique. Si ton IP est dynamique, ça accepte ton nom DDNS (from="micasa.duckdns.org"), sinon retire l’option.

Niveau avancé, si le serveur distant n’est pas entièrement à toi : rrsync enferme la clé dans un seul répertoire et en écriture seule, de sorte qu’elle ne peut même pas lire le reste du disque. Sous Debian 12, il est fourni avec le paquet rsync dans /usr/bin/rrsync (dans les versions précédentes, compressé dans /usr/share/doc/rsync/scripts/) :

command="/usr/bin/rrsync -wo /copias/nas",restrict ssh-ed25519 AAAA…

Attention : avec -wo (écriture seule), la sauvegarde entre mais tu ne peux pas restaurer par ce même chemin : la restauration se fait depuis le serveur distant ou en retirant temporairement cette restriction. C’est un compromis assumé, pas un oubli.

Étape 4 — Vérifie l’empreinte du serveur distant

La première connexion te demandera d’accepter l’empreinte du serveur. L’accepter les yeux fermés, c’est accepter n’importe quel dispositif qui s’interposerait ; récupère donc la vraie en lançant sur le serveur distant :

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare cette chaîne SHA256:… avec celle que le NAS t’affiche quand tu testes la destination. Elles coïncident, ou tu ne l’acceptes pas.

Étape 5 — Teste la connexion et enregistre

Utilise le bouton de test de la destination dans l’app : il vérifie que le NAS entre, que le dossier existe et qu’il peut y écrire. Si tu préfères le voir depuis la console du NAS, fais-le en tant que root et en visant la clé gérée, celle qu’utiliseront les sauvegardes (c’est le processus privilégié qui lance rsync, pas l’utilisateur de service) :

sudo ssh -i /etc/nas/ssh/id_ed25519 -p 22 copias@servidor.example.com 'touch /copias/nas/.prueba && echo ok'

Ce que veut dire chaque erreur courante :

Étape 6 — Crée la tâche de sauvegarde

Nom, dossiers source, cette destination distante, horaire et ce qu’on conserve. Si le dispositif de destination n’est pas à toi, chiffre là-bas le disque qui reçoit la sauvegarde (LUKS) : le panneau ne chiffre pas encore la sauvegarde à la source, et il le dit. Première exécution à la main : la sauvegarde initiale envoie tout et peut prendre des heures ou des jours selon le débit montant. Les suivantes sont incrémentales (rsync n’envoie que ce qui a changé) et durent quelques minutes. Si la première sauvegarde par internet est impossible, fais-la en local : emporte le NAS ou un disque USB là où se trouve le serveur distant, copie par le réseau local, puis passe la destination en connexion distante — rsync verra que presque tout est déjà là et n’enverra que les différences.

5.3 Rétention : la sauvegarde n’est pas un miroir

Un détail qui décide si tu survis ou non à un rançongiciel. Si la sauvegarde se contente de refléter la source, un fichier supprimé (ou chiffré) aujourd’hui sur le NAS sera supprimé (ou chiffré) cette nuit aussi dans la sauvegarde.

Les défenses, de la plus faible à la plus forte :

1. Versions conservées dans la tâche : chaque exécution laisse une version, et seules les plus anciennes sont supprimées quand on dépasse le nombre que tu as fixé. Avec 7 versions quotidiennes, tu as une semaine pour t’apercevoir que quelque chose s’est cassé ; avec 1 version, aucune. Compte l’espace : N versions prennent plus de place qu’une seule, même si les parties qui ne changent pas sont partagées entre elles. La rétention intelligente (celle par défaut) fait ça sans chiffres : elle garde toutes les sauvegardes des dernières 24 heures, une par jour pendant 7 jours, une par semaine pendant 4 semaines et une par mois pendant 12 mois — assez récentes pour une frayeur du jour, et un an de profondeur pour ce qu’on découvre tard. Elle compte « les N dernières périodes avec des sauvegardes », comme restic : si le NAS est resté éteint des mois, ce qui précède le trou n’est pas jeté juste parce que c’est vieux.
2. Instantanés sur la destination : si le serveur distant est un autre NAS avec ZFS ou Btrfs, qu’il fasse ses propres instantanés du répertoire des sauvegardes. C’est la protection la moins chère et la plus efficace.
3. Une copie débranchée : le disque USB du tiroir. Rien de ce qui n’est pas branché ne peut être chiffré.

6. Prouver que la sauvegarde sert à quelque chose (la seule partie qui n’est pas facultative)

Une sauvegarde non vérifiée n’est pas une sauvegarde : c’est un gros dossier auquel tu fais confiance par acte de foi. Les trois indicateurs qui ne prouvent rien sont la tâche en vert, la taille de la destination et « rsync n’a pas signalé d’erreur ».

Le bouton Vérifier de chaque tâche fait la moitié du travail sans déplacer un octet : il lit la sauvegarde entière sur la destination et vérifie qu’elle correspond à ce qui a été noté au moment de la copie (sur disque et par SSH, le nombre de fichiers et la taille de la version ; dans le cloud, la comparaison entre le poids du miroir et celui de la source). Le résultat reste sur la carte et dans l’historique, et si ça ne correspond pas, le NAS te prévient comme pour une sauvegarde échouée. Il détecte la sauvegarde restée à moitié, la destination qui a perdu des fichiers et le disque en train de mourir — ce qu’il ne peut pas prouver, c’est que les octets à l’intérieur de chaque fichier sont toujours les bons : cette vérification complète donc le vrai test, elle ne le remplace pas.

Le seul test valable, c’est de restaurer pour de vrai et d’ouvrir le fichier restauré. Avec l’explorateur, ça n’a jamais été aussi simple : entre dans une version, coche trois fichiers au hasard et restaure-les dans un dossier temporaire.

Et si le disque de destination est chiffré (LUKS), le test inclut de l’ouvrir avec son mot de passe : un disque chiffré dont personne ne se rappelle la clé, c’est de l’espace occupé, pas une sauvegarde.

L’exercice de restauration automatique (le NAS le fait tout seul)

Tout ce qui précède est très bien, et presque personne ne le fait. C’est pourquoi le NAS s’en charge : une fois par mois, il prend quelques fichiers au hasard dans la dernière sauvegarde de chaque tâche, les restaure pour de vrai dans un dossier temporaire et les compare avec l’original. Ensuite, il supprime ce qui a été restauré et le raconte dans le rapport hebdomadaire.

Ce n’est pas la vérification du bouton Vérifier —celle-là regarde la taille et le nombre de fichiers—. Le test restaure, avec les mêmes programmes et le même chemin que tu utiliserais le mauvais jour, et compare octet par octet avec l’original : c’est la seule chose qui révèle une destination qui accepte les écritures et rend n’importe quoi, une clé de chiffrement perdue ou un disque qui lit mal justement le secteur où se trouvaient les photos.

Comment il évite de déranger et comment il évite de mentir :

• Vingt fichiers, un demi-giga et un quart d’heure au maximum. Sur une sauvegarde de deux téras, ça ne se remarque pas ; et comme c’est au hasard, en un an, la moitié de la sauvegarde a été testée.
• Il ne choisit que des fichiers qui existaient déjà au moment de la sauvegarde. Si tu as modifié l’original ensuite, la sauvegarde doit être différente et les comparer donnerait une erreur inventée. Avec cette règle, « différent » ne peut vouloir dire qu’une chose : « la sauvegarde est abîmée ».
• Il ne touche à rien. Il restaure dans un dossier temporaire et le supprime à la fin.
• Ce qui n’a pas pu être comparé n’est pas tenu pour bon. C’est compté à part : le nombre affiché comme vérifié est celui des fichiers réellement comparés.

On le voit dans Sauvegardes → Tâches, sous la liste, avec un bouton Tester maintenant si tu ne veux pas attendre le mois suivant. Et il figure dans le rapport hebdomadaire, dans sa propre rubrique ; si une sauvegarde ne revient pas, une alerte arrive en plus et la note du rapport baisse beaucoup : une sauvegarde qui existe et ne revient pas est pire que pas de sauvegarde, parce que personne n’en cherche une autre.

Plan de tests

Restauration de test (mensuelle)

Depuis l’app : choisis la tâche, la version que tu veux récupérer et un nouveau dossier de destination — jamais par-dessus l’original, parce que si quelque chose tourne mal, tu voudras pouvoir comparer les deux. La restauration tourne comme une tâche, avec sa progression, tout comme la sauvegarde.

Ensuite, ouvre quelques fichiers : une photo qui s’affiche, un PDF qui s’ouvre, une vidéo qui se lit. Un fichier de 4 Mo qui existe mais ne s’ouvre pas est un fichier perdu. Et supprime ensuite le dossier de test, qui occupe autant que ce que tu as restauré.

Restauration complète d’un dossier (trimestrielle)

Restaure depuis l’app un dossier entier dans /mnt/<pool>/prueba-restauracion et compare-le avec l’original. Depuis la console du NAS :

# 1. Comparer avec l’original : aucune différence ne doit s’afficher
sudo diff -qr /mnt/tanque/documentos /mnt/tanque/prueba-restauracion

# 2. Vérification stricte (compare le contenu, pas les dates ni les tailles)
sudo rsync -avnc --delete /mnt/tanque/documentos/ /mnt/tanque/prueba-restauracion/

# 3. Supprimer le dossier de test une fois terminé
sudo rm -rf /mnt/tanque/prueba-restauracion

À l’étape 2, -c compare les sommes de contrôle (lent mais honnête) et -n ne modifie rien : si cette commande n’affiche aucun fichier, le contenu est identique bit à bit. Attention à l’espace : le test duplique temporairement ce que tu restaures, alors choisis un dossier qui tient.

Une nuance importante si tu restaures une ancienne version : les différences avec l’original d’aujourd’hui sont normales (c’est ce qui a changé depuis). Pour cette comparaison, utilise la dernière version, ou ne compare que des fichiers dont tu sais qu’ils n’ont pas été touchés.

Note le résultat

Deux lignes par test, où tu veux, mais note-les :

2026-07-25 · 4 fichiers restaurés depuis la sauvegarde distante · s’ouvrent bien · 3 min
2026-07-25 · Restauration complète de « documentos » (38 Go) · diff sans différences · 41 min

La donnée que presque personne ne mesure, c’est le temps de restauration. Savoir que récupérer 2 To par internet prend quatre jours change les décisions : tu voudras peut-être la sauvegarde locale en plus de la distante, ou un disque que tu peux aller chercher en voiture.

Que faire si le test échoue

C’est le test qui échoue, pas le jour de la catastrophe : c’est exactement à ça qu’il sert. Revois les sources de la tâche (il manquait un dossier ?), les droits sur la destination, l’historique au cas où ça échouait en silence depuis des semaines et, si le disque de destination est chiffré, que le mot de passe est bien celui que tu crois. Corrige, sauvegarde à nouveau et teste à nouveau.

7. Ce que cette sauvegarde ne couvre pas

En toute honnêteté, pour que ça ne te prenne pas par surprise :

• Un fichier corrompu qui est copié corrompu. rsync copie ce qu’il y a. Contre ça, il y a les sommes de contrôle de ZFS/Btrfs et les scrubs planifiés, qui détectent la corruption à la source avant qu’elle ne se propage.
• Ce que tu n’as pas choisi comme source. Un nouveau dossier de la maison n’entre tout seul dans aucune tâche : quand tu en crées un, ajoute-le à la tâche qui lui correspond, sinon il restera hors de la sauvegarde sans que personne te prévienne.
• Le temps d’envoi. Une ligne domestique à 300 Mb/s en réception en a souvent 30 en envoi : environ 10 Go par heure dans le meilleur des cas. Dimensionne la première sauvegarde en gardant ça en tête.
• Les mots de passe et la validation en deux étapes. La sauvegarde de la configuration ne contient pas la clé de signature des sessions (elle est régénérée) et tes codes TOTP sont sur ton téléphone, pas sur le NAS. Garde les codes de récupération ailleurs.

8. La sauvegarde dans le cloud échoue

D’abord : le message d’erreur, dans l’app Sauvegardes, dit maintenant ce que le cloud a répondu (plus d’espace, autorisation expirée, mauvaise adresse…). Ce texte est le diagnostic ; ce qui suit concerne les cas qui reviennent souvent.

Nextcloud et autres WebDAV : utilise un mot de passe d’application, pas celui de ton compte (Paramètres → Sécurité → Dispositifs et sessions). Si le serveur est derrière un proxy qui limite la taille des envois, cette limite l’emporte sur n’importe quel réglage du NAS.

Voir aussi

• Reprise après sinistre — que faire quand c’est déjà arrivé.
• Guide d’administration — instantanés, scrubs, alertes.