Reprise après sinistre

12 min · 9 rubriques

Ce que couvre chaque mécanisme

Le RAID n’est pas une sauvegarde : il protège des pannes de disque, pas des suppressions, des rançongiciels ni des incendies. La sauvegarde qui sort du dispositif se configure et se teste en suivant backups.md ; ce guide, c’est ce qu’on fait quand quelque chose est déjà arrivé.

Avant que quoi que ce soit n’arrive

Cinq minutes aujourd’hui, des heures d’angoisse en moins le mauvais jour :

1. Une sauvegarde externe configurée et testée en restaurant (backups.md).
2. Un nas-config-*.tar.gz récent dans cette sauvegarde externe (pas seulement sur le NAS).
3. Des alertes par e-mail ou webhook activées (Panneau de configuration → Alertes) : un disque qui tombe en panne ou une sauvegarde qui échoue depuis un mois doivent te prévenir.
4. Noté quelque part en dehors du NAS : les noms des pools, le nom du serveur, le domaine DDNS et les codes de récupération de la validation en deux étapes.

Disque de données en panne

1. Tu recevras une alerte (Pool X en estado DEGRADED ou SMART critique).
2. Repère le disque dans Stockage → Protection → Santé et chiffrement (numéro de série et état de chaque disque).
3. Branche le nouveau disque. Si le dispositif accepte le remplacement à chaud, tu peux le faire sans éteindre ; sinon, éteins (Panneau de configuration → Éteindre et redémarrer), remplace le disque et rallume.
4. Stockage → Protection → Santé et chiffrement → Disques de chaque volume → « Remplacer » sur le disque en panne, et choisis le disque de remplacement. L’opération tourne comme une tâche en arrière-plan : la reconstruction (resilver en ZFS) ou la copie (Btrfs) peut prendre des heures, et le pool reste utilisable pendant ce temps.
5. Surveille l’avancement dans Stockage (ligne « scan ») jusqu’à ce que le pool soit de nouveau sain. Ne retire pas un autre disque pendant l’opération : c’est le moment où la redondance est la plus faible.

Si tu préfères la console, l’équivalent est zpool replace <pool> <ancien-disque> /dev/sdX en ZFS et btrfs replace start <devid> /dev/sdX /mnt/<pool> en Btrfs.

Réinstaller le système en gardant les données

Quand le disque système meurt mais que les disques de données sont intacts. Les pools vivent sur les disques de données ; le système est remplaçable :

1. Installe LGM-OS sur un nouveau disque système (install.sh ou l’ISO).
2. Restaure la configuration : Panneau de configuration → Sauvegarde de la configuration → « Restaurer depuis un fichier… » avec ton dernier nas-config-*.tar.gz, puis redémarre le service. Les utilisateurs, les groupes et les dossiers de la maison reviennent avec leurs droits d’accès ; la clé de signature des sessions est régénérée (tout le monde devra se reconnecter).
3. Importe les pools :
• ZFS : zpool import -f <pool> (ou zpool import pour les lister).
• Btrfs : les unités de montage restaurées montent automatiquement par étiquette ; sinon : mount /dev/disk/by-label/<pool> /mnt/<pool>.
4. Réapplique les services depuis l’interface (SMB/NFS/WebDAV sont réécrits à l’enregistrement).

Repartir de zéro sans réinstaller

Quand le dispositif va bien mais que tu veux le panneau comme au premier jour — le NAS change de mains, ou tu préfères refaire la configuration de zéro —, pas besoin de réinstaller : Panneau de configuration → Réinitialiser aux paramètres d’usine. Les comptes sont supprimés, les dossiers cessent d’être partagés et les applications et les réglages sont retirés ; les volumes, avec toutes tes données, et le réseau restent.

Il demande ton mot de passe, ton code de validation en deux étapes et un code qui ne s’affiche que sur l’écran branché au NAS : il faut donc l’avoir devant toi. Avant de toucher à quoi que ce soit, il met les anciens réglages de côté dans /var/nas/apartados. Tout est expliqué dans le Guide d’administration.

Si le NAS quitte la maison, ça n’efface pas tes données : les volumes restent avec tout dedans. Pour les effacer, supprime le pool dans Stockage.

Perte totale du matériel

Le NAS n’existe plus : incendie, inondation, vol, surtension qui a emporté la carte mère et les disques, ou un rançongiciel qui a chiffré tout ce que le NAS avait de monté. Les données ne sont pas dans le dispositif, elles sont dans ta sauvegarde externe, et la procédure consiste à reconstruire le NAS autour d’elle.

Prérequis : une sauvegarde externe récente et testée. Si tu n’as jamais restauré à partir d’elle, c’est aujourd’hui que tu découvres si elle sert à quelque chose. C’est exactement le scénario que backups.md cherche à éviter.

Ordre des opérations

1. Le matériel. Il n’a pas besoin d’être identique à l’ancien. Il te faut des disques de données d’une capacité au moins égale à ce que tu vas restaurer, et un disque pour le système.

2. Installe LGM-OS. Démarre sur l’ISO et réponds aux quatre questions (nom du serveur, réseau, utilisateur de la console et disque système). À la fin, va sur https://<ip>:5001 et crée l’administrateur dans l’assistant de premier accès.

3. Restaure la configuration. Récupère le nas-config-*.tar.gz dans la sauvegarde externe (il fait partie des fichiers sauvegardés ; si la sauvegarde est sur un disque USB, branche-le et prends-le là) et envoie-le dans Panneau de configuration → Sauvegarde de la configuration → « Restaurer depuis un fichier… ». Ensuite :

sudo systemctl restart nas-backend

Les utilisateurs, les groupes, les dossiers de la maison avec leurs droits d’accès, les services, le réseau, les tâches planifiées et les alertes reviennent. Il n’y a encore ni données ni pools : c’est l’étape suivante.

4. Crée les pools avec les mêmes noms. Stockage → « Créer un volume ». Il est important que le nom soit le même qu’avant : les dossiers de la maison, les exports et les apps font référence à des chemins /mnt/<pool>/…, et avec un autre nom il faudrait les refaire un par un.

5. Recrée les dossiers de la maison depuis le Panneau de configuration (ils sont toujours définis après l’étape 3 : il suffit de les enregistrer pour qu’ils soient créés sur le nouveau volume avec leurs droits d’accès).

6. Restaure les données avec l’app Sauvegardes. Les destinations et les tâches sont revenues avec la configuration de l’étape 3 : l’app sait donc déjà où se trouve ta sauvegarde. Deux mises en garde avant de commencer :

• Si la destination est distante, le nouveau NAS a une nouvelle clé SSH : autorise-la sur le serveur distant comme la première fois (étape 3 de backups.md), sinon il ne pourra même pas lire la sauvegarde.
• Si la destination est un disque USB, branche-le et vérifie que la destination apparaît comme disponible.

Ensuite, pour chaque tâche : choisis la version que tu veux (en général la dernière bonne) et le dossier de destination. Commence par l’irremplaçable — documents et photos — et garde la collection multimédia pour la fin : comme ça, l’important est disponible en quelques heures, même si le reste prend des jours. Si la tâche était chiffrée, il te faut le mot de passe de chiffrement ; sans lui, aucune restauration n’est possible.

Si tu préfères (ou si tu dois) le faire à la main depuis la console, par exemple avec un disque USB monté sur /mnt/usb-copia :

sudo rsync -aHAX --numeric-ids --info=progress2 \
     /mnt/usb-copia/<chemin-de-la-version>/documentos/ /mnt/tanque/documentos/

Attention aux barres obliques finales : origine/ copie le contenu de ce dossier dans la destination ; sans la barre, il copierait le dossier entier dedans.

Si la destination distante a été autorisée avec rrsync -wo (écriture seule), cette clé ne peut pas lire : restaure depuis le serveur distant lui-même ou retire temporairement cette restriction de son authorized_keys.

7. Réapplique les services (SMB/NFS/WebDAV) en les enregistrant depuis l’interface et vérifie depuis un PC que les partages sont visibles et qu’on peut y écrire.

8. Les apps Docker. Réinstalle-les depuis le Centre de paquets et, avant de les démarrer, restaure leurs données dans /var/nas/apps/<app>/. Démarrer une app avec la base de données vide et la restaurer ensuite finit généralement mal.

9. L’accès externe. Le certificat Let's Encrypt n’est pas restauré : il est réémis tout seul depuis Panneau de configuration → Accès externe dès que le domaine pointe vers la nouvelle IP (vérifie le DDNS et la redirection de ports du nouveau routeur).

10. Remets les sauvegardes en route. Vérifie que les destinations sont disponibles et que les tâches restent actives et programmées. Un NAS restauré sans sauvegarde externe, c’est un sinistre à moitié réparé : le prochain te prendra de court comme celui-ci.

11. Teste la sauvegarde. Lance une tâche à la main et restaure deux ou trois fichiers de la version qu’elle vient de créer. Boucle la boucle le jour même, pas « quand j’aurai un moment ».

Combien de temps ça prend

À titre indicatif, pour que tu ajustes tes attentes et que tu décides par où commencer :

Que la restauration par le réseau soit si lente, c’est la raison d’avoir aussi une sauvegarde locale (ou une que tu peux aller chercher en voiture) : la sauvegarde distante est ton assurance contre l’incendie, la locale est celle qui te remet au travail le jour même.

Restaurer des fichiers depuis un instantané

• ZFS : les instantanés sont visibles dans /mnt/<pool>/<dataset>/.zfs/snapshot/<nom>/ — copie ce dont tu as besoin sans toucher au reste. Le rollback depuis l’interface ramène le dataset entier en arrière (il détruit les instantanés postérieurs).
• Btrfs : « Restaurer » crée /mnt/<pool>/restaurado-<date> avec le contenu de l’instantané ; copie ce dont tu as besoin et supprime ce dossier (c’est un sous-volume : btrfs subvolume delete).

Sauvegarde de la configuration

Télécharge-la à la main depuis Panneau de configuration → Sauvegarde de la configuration, ou automatise-la : Panneau de configuration → Tâches planifiées → type « backup » vers /mnt/<pool>/backups (par exemple chaque semaine). Garde ce dossier dans la sauvegarde externe : c’est la première chose dont tu auras besoin dans le scénario précédent.

Ce que contient le nas-config-*.tar.gz

• state/ — tout l’état de /var/nas/state : utilisateurs et groupes, dossiers de la maison avec leurs droits d’accès par utilisateur et par groupe, SMB, NFS, WebDAV, SSH, pare-feu, réseau, pools enregistrés, tâches planifiées, alertes, notifications, boutique d’apps, SNMP, portail d’accès, onduleur et blocage automatique d’IP. C’est ce qui est restauré.
• etc/ — copie des fichiers générés (smb.conf, exports, nftables, sshd, htpasswd) **à titre de référence uniquement** : la restauration ne les écrase pas, ils se réécrivent tout seuls quand on réapplique les services depuis l’interface.

Ce qu’il ne contient PAS, exprès

Seulement des secrets du dispositif et de l’état jetable ; jamais de configuration :

Toute autre clé d’état entre dans la sauvegarde par défaut, y compris celles des fonctions futures : le tableau est la seule exception, et backend/tests/test_backup_state.py échoue si quelqu’un ajoute un nouvel état sans décider de quel côté il tombe. Avant, c’était l’inverse — une liste de douze fichiers à inclure —, et les dossiers de la maison se perdaient en silence à chaque restauration.

Restaurer

Panneau de configuration → Sauvegarde de la configuration → « Restaurer depuis un fichier… ». Seules les entrées state/<clé>.json du format propre sont acceptées (tout chemin qui sort du répertoire d’état est refusé) et les clés protégées du tableau sont ignorées même si elles figurent dans l’archive. Ensuite : systemctl restart nas-backend et réapplique les services depuis l’interface.

⚠️ Cette sauvegarde ne contient pas tes données : pour ça, il y a les instantanés (dans le dispositif) et la sauvegarde externe (en dehors).

Ce qui reste non couvert

Avec la sauvegarde externe configurée, la perte totale cesse d’être une impasse. Il vaut quand même mieux savoir où sont les limites :

• Ce qui s’est passé depuis la dernière sauvegarde est perdu. Si tu sauvegardes au petit matin et que le dispositif brûle à 20 h, la journée de travail est perdue. Augmente la fréquence pour ce que tu ne peux pas refaire.
• Ce qui n’était dans aucune tâche n’y est pas. Un dossier de la maison créé après la configuration des sauvegardes n’y entre pas tout seul : vérifie de temps en temps les sources de tes tâches.
• Il n’y a pas d’image du disque système (bare metal) : LGM-OS se réinstalle depuis l’ISO et on restaure la configuration. C’est rapide, mais ce n’est pas un « cloner et démarrer ».
• Si la sauvegarde était à côté du NAS, le sinistre l’a emportée aussi. Une sauvegarde sur un USB branché en permanence au dispositif ne survit ni à un incendie, ni à un vol, ni à un rançongiciel. C’est pour ça qu’une des sauvegardes doit être ailleurs.
• Sessions et validation en deux étapes : la clé de signature est régénérée et tout le monde se reconnecte ; les codes TOTP sont sur le téléphone de chaque utilisateur. Garde les codes de récupération à part.
• Les clés et les certificats du dispositif sont nouveaux : il faut réautoriser la clé SSH du NAS sur la destination de sauvegarde et réémettre le certificat Let's Encrypt.