# Référence des commandes

L’agent s’appelle `neverwiped` et s’installe dans `/usr/local/bin/neverwiped`. Toutes les commandes se lancent **en root** (sinon : `neverwiped doit être lancé en root (par exemple : sudo neverwiped …)`).

Les options s’écrivent `--option valeur` ou `--option=valeur`, avant ou après les arguments. `-y` équivaut à `--yes`.

**Langue.** L’agent parle anglais, français ou espagnol. Il suit la langue du système (`LC_ALL`, `LC_MESSAGES`, puis `LANG` : `fr_FR.UTF-8` donne le français, `es_ES.UTF-8` l’espagnol), et l’anglais par défaut (`C`, `POSIX` ou une autre langue). Pour la forcer : variable `NEVERWIPED_LANG=fr|en|es` (prioritaire), ou option `--lang fr|en|es` sur n’importe quelle commande. Les exemples de cette documentation montrent la sortie en français (`NEVERWIPED_LANG=fr`). Les sorties `--json` et les codes de sortie ne dépendent pas de la langue.

## Résumé

| Commande | Rôle |
|---|---|
| `neverwiped install` | Enregistre le serveur, détecte quoi sauvegarder, propose un plan, planifie, lance la première sauvegarde. |
| `neverwiped status` | État de l’agent, de l’abonnement, de la dernière sauvegarde et de la planification (`--json` pour les scripts). |
| `neverwiped limits` | Affiche ou change le débit d’envoi, les cœurs CPU et la priorité des sauvegardes. |
| `neverwiped backup now` | Lance une sauvegarde immédiatement. |
| `neverwiped check` | Vérifie les sauvegardes sur le stockage (restic check) ; se lance aussi seule chaque semaine. |
| `neverwiped list` | Liste les sauvegardes disponibles. |
| `neverwiped restore <date\|id\|latest>` | Restaure une sauvegarde. |
| `neverwiped recover` | Sur un nouveau serveur, après la perte de l’ancien : redonne l’accès à ses sauvegardes (clé d’API de compte + clé de récupération). |
| `neverwiped recovery-key check\|new` | Sur le serveur, tant qu’il tourne : teste une clé de récupération, ou en crée une nouvelle si elle est perdue. |
| `neverwiped feedback` | Envoie un message à l’équipe (bug, idée, demande d’aide…). |
| `neverwiped update` | Met à jour l’agent avec une version signée, revient à la précédente, épingle une version (`--check`, `--rollback`, `--pin`, `--auto`). |
| `neverwiped uninstall` | Retire l’agent du serveur (les sauvegardes restent sur le stockage). |
| `neverwiped version` | Version de l’agent et de restic. |
| `neverwiped help` | Aide intégrée. |

## Script d’installation : install.sh

```sh
curl -fsSL https://neverwiped.com/install.sh | sh                                         # interactif
curl -fsSL https://neverwiped.com/install.sh | sh -s -- --api-key nw_acc_VOTRE_CLE --yes  # non interactif
curl -fsSL https://neverwiped.com/install.sh | NEVERWIPED_NO_SETUP=1 sh                   # binaire seul
```

Le script détecte l’architecture (amd64 ou arm64), télécharge `https://neverwiped.com/downloads/neverwiped-linux-<arch>`, vérifie son empreinte SHA-256 (inscrite dans le script lui-même), l’installe dans `/usr/local/bin/neverwiped`, puis exécute `neverwiped install --api-url https://neverwiped.com` avec les arguments placés après `sh -s --`. Sans argument et avec un terminal, les questions sont posées sur le terminal.

`NEVERWIPED_NO_SETUP=1` installe seulement le binaire et affiche la commande à lancer ensuite.

## neverwiped install

```text
neverwiped install [--api-key CLÉ] [--yes] [--no-backup] [--include CHEMIN]... [--exclude MOTIF]...
                   [--no-databases] [--no-docker] [--pause-volume NOM]... [--live-volume NOM]...
                   [--preset NOM]... [--no-estimate] [--limit-upload DÉBIT] [--limit-cpus N]
                   [--priority low|normal] [--same-server] [--api-url URL]
```

| Option | Effet |
|---|---|
| `--api-key CLÉ` | Clé d’API **de compte** (`nw_acc_…`), créée dans l’espace client, rubrique « Clés d’API ». Sinon : variable `NEVERWIPED_API_KEY`, sinon question sur le terminal. Ignorée si le serveur est déjà enregistré. |
| `--yes`, `-y` | Répond oui à toutes les questions : valide le plan proposé et lance la première sauvegarde. Obligatoire sans terminal (scripts, agents IA). |
| `--no-backup` | Ne lance pas la première sauvegarde (elle aura lieu à l’heure planifiée, ou avec `neverwiped backup now`). |
| `--include CHEMIN` | Ajoute un dossier au plan. Répétable : `--include /data --include /opt/app`. |
| `--exclude MOTIF` | Exclut des fichiers (motif restic, par exemple `"*.log"` ou `/var/www/site/tmp`). Répétable. |
| `--preset NOM` | Ajoute un jeu d’exclusions : `logs`, `build`, `trash`, `disk-images`, `archives`, ou `all`. Répétable, ou séparé par des virgules. Aucun n’est actif par défaut. |
| `--no-estimate` | Saute l’estimation de taille affichée avec le plan, et la vérification du quota avant la première sauvegarde. |
| `--limit-upload DÉBIT`, `--limit-cpus N`, `--priority low\|normal` | Limites des sauvegardes, dès la première : voir `neverwiped limits` plus bas. Conservées si `install` est relancée sans elles. |
| `--no-databases` | Ne sauvegarde aucune base de données (ni locale ni dans Docker). |
| `--no-docker` | Ignore Docker : ni volumes, ni bases dans des conteneurs. |
| `--same-server` | À utiliser seulement si l’agent refuse parce que la configuration semble copiée d’une autre machine alors que c’est bien le même serveur (son identifiant de machine a changé, par exemple après une réinstallation du système). L’agent enregistre le nouvel identifiant et continue. Sur une vraie copie, lancez plutôt `neverwiped uninstall --yes`. |
| `--api-url URL` | Adresse de la plateforme. Par défaut `https://neverwiped.com` (install.sh la passe déjà). Sinon : variable `NEVERWIPED_API_URL`. |

Déroulement :

1. Téléchargement de restic 0.18.1 dans `/var/lib/neverwiped/bin/`, empreinte SHA-256 vérifiée (sinon : arrêt, rien n’est installé).
2. Détection et affichage du **plan** : `/etc`, `/var/spool/cron`, `/root`, `/home` s’ils ne sont pas vides, fichiers web (`/var/www`, `/srv`, racines déclarées dans nginx, Apache ou Caddy), applications dans `/opt/*`, PostgreSQL et MySQL/MariaDB locaux, bases dans des conteneurs Docker, volumes Docker.
3. Estimation de taille (sauf `--no-estimate`) : taille et nombre de fichiers de chaque dossier et volume après exclusions, plus gros dossiers, taille des fichiers des bases locales, gain de chaque préréglage. Seules les tailles sont lues, rien n’est envoyé, arrêt à 90 secondes (« au moins »). Puis confirmation du plan. **Si vous refusez, rien n’est enregistré.**
4. Enregistrement du serveur sur votre compte (une seule fois par serveur), création du dépôt chiffré avec une clé générée sur le serveur (`/etc/neverwiped/repo.key`), ajout de la clé de récupération, affichée une seule fois.
5. Planification selon la formule : minuteur systemd `neverwiped-backup.timer` si systemd est présent, sinon `/etc/cron.d/neverwiped`, sinon la crontab de root (BusyBox).
6. Première sauvegarde (sauf `--no-backup`). Si les fichiers et volumes estimés dépassent l’espace restant de l’abonnement, la question est posée avec « non » par défaut ; avec `--yes`, la première sauvegarde n’est pas lancée (les sauvegardes planifiées restent actives).

Exclusions par défaut : `**/node_modules`, `**/.cache`, `/var/lib/neverwiped/bin`, `/var/cache`, `/var/lib/docker/overlay2`, `/root/.npm`, `/root/go/pkg`.

Préréglages (`--preset`, aucun par défaut ; l’estimation propose ceux qui feraient gagner au moins 100 Mio) :

- `logs` : `*.log`, `*.log.[0-9]*`, `*.log.gz`, `**/storage/logs`, `**/var/log` ;
- `build` : `**/.next/cache`, `**/.nuxt`, `**/.parcel-cache`, `**/.turbo`, `**/__pycache__`, `**/.pytest_cache`, `**/.mypy_cache`, `**/.tox`, `**/.gradle`, `**/.terraform`, `**/.yarn/cache`, `**/.pnpm-store`, et les caches Maven (`.m2/repository`), Cargo (`.cargo/registry`), Composer (`.composer/cache`), npm et Go de `/root` et `/home/*` ;
- `trash` : `**/.Trash-*`, `**/.local/share/Trash` ;
- `disk-images` : `*.iso`, `*.qcow2`, `*.vmdk`, `*.vdi`, `*.vhd`, `*.vhdx` ;
- `archives` : `*.tar`, `*.tar.gz`, `*.tgz`, `*.tar.bz2`, `*.tar.xz`, `*.tar.zst`, `*.sql.gz`, `*.sql.zst`, `*.sql.xz`, `*.bak`. À ne choisir que si ces fichiers sont des copies de données déjà sauvegardées par le plan.

Bases de données : export complet à chaque sauvegarde (`pg_dumpall` en tant que `postgres` ; `mysqldump` ou `mariadb-dump --all-databases --single-transaction` (utilisateurs et droits compris, en utf8mb4, export refusé s’il est coupé avant la fin) avec `/root/.my.cnf` ou `/etc/mysql/debian.cnf` ; dans Docker par `docker exec` avec les variables standard des images officielles). Les exports sont écrits dans `/var/lib/neverwiped/dumps`, intégrés à la sauvegarde, puis effacés. Les volumes Docker d’un conteneur de base déjà exportée sont ignorés (une copie à chaud serait incohérente). Les autres volumes sont lus à chaud, sauf ceux des images à état (Redis, MongoDB, Elasticsearch…) : leurs conteneurs sont mis en pause (`docker pause`) le temps d’une copie locale dans `/var/lib/neverwiped/volumes`, au plus 5 minutes, puis relancés, et c’est la copie qui est sauvegardée. `--pause-volume NOM` / `--live-volume NOM` à l’installation changent ce choix.

**Relancer `neverwiped install`** sur un serveur déjà installé ne crée pas de nouveau serveur : le plan est recalculé (répétez vos options `--include`, `--exclude`…), envoyé à la plateforme, et la planification réinstallée. La clé de récupération n’est pas réaffichée : elle n’est créée qu’une fois, avec le dépôt.

## neverwiped estimate

```text
neverwiped estimate [--include CHEMIN]... [--exclude MOTIF]... [--preset NOM]... [--no-databases]
                    [--no-docker] [--pause-volume NOM]... [--live-volume NOM]... [--json] [--max-seconds N]
```

Montre le plan que proposerait `neverwiped install` (mêmes options) et le mesure, **sans rien enregistrer ni envoyer** : à lancer avant de souscrire pour choisir une formule. Taille avant compression et déduplication ; les exports de bases ne sont pas comptés (la taille des fichiers des bases locales sur le disque est affichée à la place, un export est en général plus petit). `--json` donne `plan` et `estimate` pour les scripts et agents IA ; `--max-seconds N` limite la durée de la mesure (pas de limite par défaut). Préréglages : voir plus haut, après les exclusions par défaut.

## neverwiped status

```sh
neverwiped status
neverwiped status --json
```

Affiche le serveur et son identifiant, la plateforme, les versions, le plan (dossiers, bases, volumes), la formule et l’état de l’abonnement (`trialing` pendant l’essai, `active`, `past_due` en cas d’impayé, `suspended`…), l’état des sauvegardes (`actives`, ou `SUSPENDUES (restauration toujours possible)`), l’espace utilisé et le quota, la date de la dernière sauvegarde réussie, la planification trouvée et les 5 dernières lignes du journal.

| Option | Effet |
|---|---|
| `--json` | Sortie JSON, clés en anglais indépendantes de la langue : `hostname`, `server_id`, `api_url`, `agent_version`, `restic_version`, `plan`, `platform` (`server_status`, `plan_code`, `plan_name`, `subscription_status`, `can_backup`, `frequency`, `on_calendar`, `used_bytes`, `quota_bytes`, `last_backup_at`, `last_check_at`, `last_check_result` : `ok`, `damaged`, `failed`, absent si jamais vérifié), `platform_error` si la plateforme ne répond pas, `schedule` (`kind` : `systemd`, `cron.d`, `crontab` ou `none`), `limits` (comme `neverwiped limits --json`), `log_file`. |

## neverwiped limits

```sh
neverwiped limits
neverwiped limits --limit-upload 20mbit
neverwiped limits --limit-cpus 1 --priority normal
neverwiped limits --limit-upload off --limit-cpus off --priority low
neverwiped limits --json
```

Affiche ou change ce que les sauvegardes peuvent prendre au serveur. Sans option, affiche les limites en place. Par défaut : aucune limite d’envoi, tous les cœurs, priorité basse. Les limites sont dans `/etc/neverwiped/config.json` (aucun appel réseau) et s’appliquent dès la sauvegarde suivante, planifiée ou manuelle, et au nettoyage des anciennes sauvegardes. **Les restaurations et `neverwiped list` ne sont jamais limitées.**

| Option | Effet |
|---|---|
| `--limit-upload DÉBIT` | Plafonne l’envoi vers le stockage (`--limit-upload` de restic) : `20mbit` (ou `20Mbps`), `800kbit`, `2MB`, `500KiB` ; `off` retire la limite. L’unité est obligatoire. |
| `--limit-cpus N` | restic utilise au plus N cœurs (`GOMAXPROCS`) ; `off` : tous. Plafond de travail en parallèle, pas un quota exact. |
| `--priority low\|normal` | `low` (par défaut) : restic et les outils d’export des bases locales tournent sous `nice 10` et `ionice -c 3`. `normal` : comme tout autre processus. La copie des volumes Docker mis en pause est toujours en priorité normale. |
| `--json` | `upload_kib_s` (0 = sans limite), `cpus` (0 = tous), `cpus_total`, `priority` (`low` ou `normal`). |

Avec une limite d’envoi, `neverwiped install` affiche le temps maximal d’envoi de la première sauvegarde. Une sauvegarde lancée par le minuteur systemd est arrêtée au bout de 12 heures : si la première demande plus, retirez la limite le temps de `neverwiped backup now`, puis remettez-la. Détails : « Débit, CPU et priorité » dans la page « Ce qui arrive sur votre serveur ».

## neverwiped backup now

```sh
neverwiped backup now
```

Lance une sauvegarde tout de suite, avec le plan enregistré. Sortie en cas de succès :

```text
Sauvegarde démarrée (manual)
Export postgresql (toutes les bases)…
Sauvegarde réussie en 2s : 2,0 Mo ajoutés, 5,3 Mo stockés au total, instantané a31a3fb5
```

Dans le journal `/var/log/neverwiped.log`, la ligne de succès porte une étiquette stable, la même dans toutes les langues : `[backup-ok]` (`[backup-failed]` en cas d’échec), par exemple `2026-11-04T02:16:09Z [backup-ok] Sauvegarde réussie en 2s : …`. Pour un script : `grep '\[backup-ok\]' /var/log/neverwiped.log | tail -1`.

Seuls les changements depuis la sauvegarde précédente sont envoyés. Une seule opération `neverwiped` à la fois (sinon : `une autre opération neverwiped est déjà en cours`). Après une sauvegarde réussie, l’agent supprime les sauvegardes trop anciennes selon votre formule quand c’est dû (une fois par semaine), pendant une courte fenêtre de maintenance délivrée par la plateforme.

`neverwiped backup --scheduled` est la forme utilisée par la planification ; inutile de la lancer à la main.

## neverwiped check

```sh
neverwiped check               # structure : index, instantanés, dossiers
neverwiped check --read 5%     # + relit 5 % du contenu, tiré au hasard (ou --read 1/26, --read 2G)
neverwiped check --full        # + relit tout le contenu : télécharge tout le dépôt
```

Vérifie que les sauvegardes stockées sont lisibles et complètes, avec `restic check` et votre clé (la plateforme et le stockage ne peuvent pas le faire à votre place : ils n’ont pas la clé). Rien n’est modifié. Sans option, seule la structure est relue ; `--read` relit aussi une part du contenu chiffré et la déchiffre, `--full` le relit en entier (long, et autant de téléchargement que la taille du dépôt). Le cache local n’est pas utilisé : c’est bien ce qui est sur le stockage qui est relu.

Automatiquement, environ une fois par semaine, après une sauvegarde réussie, l’agent fait cette vérification en relisant une part différente du contenu à chaque fois (1/26 par défaut), pour avoir tout relu en six mois environ. Le résultat est envoyé à la plateforme et affiché par `neverwiped status` (ligne « Vérification ») et sur la page du serveur dans votre espace client.

Dans le journal, la ligne de résultat porte une étiquette stable : `[check-ok]`, `[check-damaged]` (erreurs trouvées) ou `[check-failed]` (la vérification n’a pas pu se faire : réseau, autre opération en cours). Code de sortie `0` si aucune erreur n’est trouvée, `1` sinon.

Si des erreurs sont trouvées, notre équipe est prévenue tout de suite ; vous recevez un e-mail si une deuxième vérification les confirme. Les fichiers de votre serveur ne sont pas touchés. Ne désinstallez pas l’agent et ne supprimez pas le serveur de votre compte : la réparation se fait avec vous.

## neverwiped list

```sh
neverwiped list
neverwiped list --json
```

| Option | Effet |
|---|---|
| `--json` | Sortie JSON (tableau d’instantanés restic : `id`, `short_id`, `time`, `hostname`, `paths`, `tags`, `summary`), pour les scripts et les agents IA. |

Sortie texte :

```text
DATE               ID            AJOUTÉ  CONTENU
2026-11-03 22:59   8b28999a      3,3 Mo  /etc /var/lib/neverwiped/dumps /var/spool/cron /var/www
2026-11-04 02:16   e7ef4663     25,4 Ko  /etc /var/lib/neverwiped/dumps /var/spool/cron /var/www

Restaurer : neverwiped restore <DATE ou ID> [--target DOSSIER]
```

Les dates sont à l’heure locale du serveur. Sans sauvegarde : `Aucune sauvegarde pour l’instant (lancez « neverwiped backup now »).`

## neverwiped restore

```text
neverwiped restore <date|id|latest> [--target DOSSIER] [--include CHEMIN]... [--yes] [--plan | --approve CODE]
```

Quelle sauvegarde :

| Valeur | Sauvegarde choisie |
|---|---|
| `latest` (ou `dernière`, `derniere`, `última`, `ultima`) | la plus récente |
| `2026-11-03` (AAAA-MM-JJ) | la dernière de ce jour (heure locale du serveur) |
| `"2026-11-03 22:59"` ou `2026-11-03T22:59` | celle de cette minute |
| `8b28999a` (au moins 4 caractères) | celle dont l’identifiant commence ainsi |

| Option | Effet |
|---|---|
| `--target DOSSIER` | Restaure dans ce dossier, **sans toucher aux fichiers en place**. Les chemins d’origine sont recréés dessous : `/var/www` devient `DOSSIER/var/www`. Si le dossier n’est pas vide, une confirmation est demandée. |
| `--include CHEMIN` | Ne restaure que ce chemin (tel qu’il était sur le serveur, par exemple `/var/www/site`). Répétable. |
| `--yes`, `-y` | Confirme sans question. Pour une restauration en place, c’est une **confirmation explicite d’écrasement**. |
| `--plan` | N’écrit rien : affiche ce qui serait restauré (sauvegarde, dossier, chemins) et un code d’accord. Ne prend pas le verrou et ne contacte pas NeverWiped. Prévu pour les agents IA, qui demandent ainsi votre accord avant d’agir. |
| `--approve CODE` | Lance la restauration décrite par le plan que vous avez approuvé (même sauvegarde, même dossier, mêmes chemins). Si quelque chose diffère, rien n’est écrit. Incompatible avec `--plan`. |

Sans `--target` (ou avec `--target /`), la restauration se fait **en place** : les fichiers existants sont écrasés par leur version sauvegardée. L’agent demande de taper le mot de confirmation de sa langue : `RESTAURER` en français, `RESTORE` en anglais, `RESTAURAR` en espagnol (majuscules, sans accent ; seul le mot de la langue affichée est accepté). Sans terminal et sans `--yes`, il refuse et ne modifie rien.

La restauration est signalée à la plateforme (succès ou échec seulement : ni fichiers, ni chemins, ni tailles), en un seul essai court : si la plateforme est injoignable, une ligne d’avertissement s’affiche et la restauration se fait normalement.

Les exports de bases sont restaurés comme fichiers `.sql` dans `<DOSSIER>/var/lib/neverwiped/dumps/`, avec la commande de réimport affichée. Rien n’est réimporté automatiquement. Détails : [Restaurer](https://docs.neverwiped.com/restauration).

La restauration reste possible même si les nouvelles sauvegardes sont suspendues (essai terminé, impayé).

## neverwiped recover

```text
neverwiped recover [--api-key CLÉ] [--server ID|NOM] [--recovery-key-file FICHIER] [--repo-key] [--yes] [--api-url URL]
```

À lancer **sur un nouveau serveur** quand l’ancien est perdu (disque mort, serveur supprimé chez l’hébergeur…), avec deux choses seulement : une clé d’API de compte (espace client, « Clés d’API ») et la **clé de récupération** notée à l’installation. Sans passer par le support. Pour obtenir l’agent seul sur le nouveau serveur : `curl -fsSL https://neverwiped.com/install.sh | NEVERWIPED_NO_SETUP=1 sh`.

| Option | Effet |
|---|---|
| `--api-key CLÉ` | Clé d’API **de compte** (`nw_acc_…`). Sinon : variable `NEVERWIPED_API_KEY`, sinon question. |
| `--server ID\|NOM` | Le serveur perdu, par identifiant ou par nom. Sans cette option : choisi d’office s’il n’y en a qu’un, sinon liste numérotée (avec `--yes` et plusieurs serveurs : erreur qui les liste). |
| `--recovery-key-file FICHIER` | Fichier contenant la clé de récupération. Sinon : variable `NEVERWIPED_RECOVERY_KEY`, sinon question (saisie masquée sur un terminal). |
| `--repo-key` | Le fichier contient une copie du `/etc/neverwiped/repo.key` du serveur perdu (copie du dossier, instantané disque), pas une clé de récupération : le code de contrôle n’est pas comparé, restic vérifie la clé après la ré-émission des accès. |
| `--yes`, `-y` | Confirme sans question. |
| `--api-url URL` | Adresse de la plateforme (sinon `NEVERWIPED_API_URL`). |

Déroulement :

1. Refus si ce serveur a déjà une configuration neverwiped : sur le serveur d’origine, utilisez directement `list` et `restore`.
2. Liste des serveurs du compte, choix du serveur perdu.
3. Confirmation : **l’identifiant de stockage et la clé d’agent du serveur perdu sont révoqués** ; une machine qui tournerait encore avec eux cesse de sauvegarder.
4. Installation de restic (empreinte vérifiée), nouvel identifiant de stockage pour le même dépôt, configuration écrite dans `/etc/neverwiped/config.json`. La clé de récupération devient la clé de ce serveur (`/etc/neverwiped/repo.key`, 0600) : **aucune nouvelle clé de récupération n’est créée**, gardez la vôtre. Elle n’est jamais envoyée à la plateforme ni écrite dans le journal.
5. Vérification avec la liste des sauvegardes. Si la clé ne les ouvre pas : rien n’est conservé sur le serveur et l’agent affiche `la clé de récupération n’ouvre pas les sauvegardes de …` ; l’ancien identifiant a quand même été révoqué, relancez `recover` avec la bonne clé.

Sortie (exemple) :

```text
Accès aux sauvegardes de vps-prod récupéré : 12 sauvegarde(s), la dernière le 2026-11-03 22:59.
Votre clé de récupération est maintenant la clé de ce serveur (/etc/neverwiped/repo.key). Gardez votre copie : aucune nouvelle clé de récupération n’est créée.

Ensuite :
  neverwiped list                                       les sauvegardes
  neverwiped restore latest --target /root/restauration   restaurer sans rien écraser
  neverwiped install --yes                              puis : plan et sauvegardes planifiées de ce serveur, dans le même dépôt
```

`neverwiped install --yes` après `recover` ne crée ni nouveau serveur ni nouveau dépôt, et n’affiche pas de nouvelle clé de récupération : il détecte le plan de ce serveur et planifie ses sauvegardes, qui continuent dans le dépôt de l’ancien serveur.

## neverwiped recovery-key

```text
neverwiped recovery-key check [--recovery-key-file FICHIER]
neverwiped recovery-key new [--yes]
```

À lancer **sur le serveur lui-même, tant qu’il tourne** (il faut `/etc/neverwiped/repo.key`).

- `check` teste une clé : ouvre-t-elle les sauvegardes de ce serveur, et est-ce la clé de récupération actuelle ? La clé est lue dans `--recovery-key-file`, sinon `NEVERWIPED_RECOVERY_KEY`, sinon demandée (saisie masquée). Elle n’est envoyée nulle part.
- `new` ajoute une nouvelle clé de récupération au dépôt avec `repo.key`, vérifie qu’elle ouvre les sauvegardes, puis l’affiche **une fois** avec son code de contrôle. Seul le code est envoyé à la plateforme, qui garde aussi l’ancien code et prévient le titulaire du compte par e-mail.
- **L’ancienne clé n’est pas supprimée** : le stockage n’accepte que des ajouts depuis le serveur, elle ouvre donc toujours les sauvegardes. Si elle a pu être vue par quelqu’un d’autre, c’est une fuite : voir [Chiffrement](/fr/docs/encryption#leak).
- Une fois le serveur perdu, aucune des deux commandes ne peut aider : il faut une clé de récupération (ou une copie de `repo.key`) et `neverwiped recover`.

## neverwiped feedback

```text
neverwiped feedback [MESSAGE…] [--kind bug|idea|help|other] [--yes] [--api-key CLÉ]
```

Envoie un message à l’équipe NeverWiped. Le message se donne en arguments (`neverwiped feedback "la restauration est lente"`) ou sur l’entrée standard, jusqu’à la fin ou une ligne vide (5 000 caractères au plus). Avant l’envoi, l’agent affiche **exactement** ce qui part : le message, son type (`--kind`, `other` par défaut) et la version de l’agent ; ni nom de serveur, ni journal, ni chemins. Puis confirmation (sauf `--yes`) et `Merci ! Message reçu (référence …).`

Utilise la clé d’agent du serveur ; sur un serveur sans agent, passez une clé de compte avec `--api-key`.

## neverwiped update

```text
neverwiped update [--check] [--to VERSION] [--yes]
neverwiped update --rollback [--yes]
neverwiped update --pin VERSION|X.Y|none
neverwiped update --auto on|off
```

| Option | Effet |
|---|---|
| (aucune) | Installe la version que l’épinglage permet (sans épinglage : la dernière), après confirmation. |
| `--check` | Affiche la version installée, l’épinglage, la mise à jour automatique et la version disponible. N’installe rien. |
| `--to VERSION` | Installe cette version précise, même plus ancienne (confirmation par défaut « non » dans ce cas). |
| `--rollback` | Remet le binaire remplacé par la dernière mise à jour, sans réseau, et épingle cette version. Relancé, il annule le retour arrière. |
| `--pin VERSION` | Reste sur cette version (ex. `0.3.1`). |
| `--pin X.Y` | Reste sur cette branche (ex. `0.3`) : seulement ses corrections. |
| `--pin none` | Supprime l’épinglage : suit la dernière version. |
| `--auto on\|off` | Mise à jour automatique après la sauvegarde planifiée, au plus une fois par jour. **Coupée par défaut.** Elle suit l’épinglage et ne change jamais le résultat de la sauvegarde. |
| `--yes`, `-y` | Confirme sans question. |

`--pin` et `--auto` changent seulement les réglages (rien n’est téléchargé) ; une seule de ces formes à la fois, sinon :

```text
utilisation : neverwiped update [--check] [--to VERSION] [--yes] | --rollback | --pin VERSION|X.Y|none | --auto on|off (une à la fois)
```

**Ce qui est vérifié avant de remplacer quoi que ce soit.** La liste des versions (`releases.json`) doit être signée (Ed25519) par une clé de publication intégrée à l’agent ; la plateforme ne détient pas cette clé. La liste a une date d’expiration et ne peut pas être plus ancienne que la dernière déjà acceptée par ce serveur. Le binaire téléchargé doit avoir l’empreinte SHA-256 et la taille inscrites dans la liste signée, puis il est lancé une fois (`neverwiped version`) et doit annoncer la version attendue. Ensuite seulement il remplace `/usr/local/bin/neverwiped` ; l’ancien est gardé dans `/var/lib/neverwiped/bin/neverwiped.previous`. Si une étape échoue, rien n’est changé. Une version retirée par l’équipe (défaut grave) n’est jamais installée ; un serveur qui la fait tourner revient à la dernière bonne version de sa branche.

La mise à jour ne touche ni la configuration, ni la clé, ni le dépôt, ni le plan de sauvegarde. La prochaine sauvegarde utilise la nouvelle version ; si celle-ci fige une version de restic plus récente, elle la télécharge (empreinte vérifiée) avant la sauvegarde, et garde l’ancienne en cas d’échec.

Messages possibles :

- `cette version de l’agent n’a pas de clé de publication : la mise à jour intégrée est désactivée. Mettez à jour avec le script d’installation (voir la référence des commandes, « neverwiped update »)` : agent construit sans clé de publication. Mettez-le à jour avec `curl -fsSL https://neverwiped.com/install.sh | NEVERWIPED_NO_SETUP=1 sh` (configuration et clé conservées).
- `liste des versions refusée, rien n’a été installé : …` : signature absente ou invalide, liste expirée ou plus ancienne que la précédente. Ne contournez pas : écrivez au support.
- `aucune version précédente n’est conservée sur ce serveur (aucune mise à jour n’y a encore été installée) : utilisez neverwiped update --to VERSION`
- `mise à jour annulée, rien n’a été modifié`
- `échec de la mise à jour vers …, la version actuelle reste en place : …` : téléchargement, empreinte ou essai du nouveau binaire en échec.

## neverwiped uninstall

```text
neverwiped uninstall [--yes] [--keep-config] [--keep-backups | --delete-backups] [--remove-log]
```

| Option | Effet |
|---|---|
| `--yes`, `-y` | Confirme sans question (les sauvegardes sont alors conservées, sauf `--delete-backups`). |
| `--keep-config` | Garde `/etc/neverwiped` (configuration et clé de chiffrement locale). |
| `--keep-backups` | Garde les sauvegardes sur le stockage sans poser la question (le choix par défaut). |
| `--delete-backups` | Demande la suppression des sauvegardes de ce serveur : le titulaire du compte reçoit un e-mail avec un lien et confirme dans l’espace client. Rien n’est supprimé depuis le serveur. |
| `--remove-log` | Efface aussi le journal `/var/log/neverwiped.log` (conservé par défaut). |

Refuse tant qu’une sauvegarde, une restauration ou une vérification tourne, et relance d’abord les conteneurs Docker qu’une exécution interrompue a laissés en pause (si l’un ne repart pas, rien n’est retiré). Ensuite : retire la planification, prévient la plateforme (le serveur passe à « agent désinstallé », sa clé d’agent est révoquée, le titulaire du compte reçoit un e-mail), efface `/var/lib/neverwiped`, `/var/cache/neverwiped`, `/etc/neverwiped` (sauf `--keep-config`) et le binaire `/usr/local/bin/neverwiped`, en affichant chaque chemin retiré ou gardé. Si un chemin ne peut pas être retiré, la commande l’indique, garde le binaire pour être relancée, et se termine en erreur.

**Les sauvegardes restent sur le stockage** par défaut : elles se restaurent avec votre clé de récupération, comptent dans votre stockage, et la désinstallation ne résilie pas l’abonnement. Pour les supprimer : `--delete-backups`, ou directement « Supprimer ce serveur » sur la page du serveur dans l’espace client. Les clés du serveur ne peuvent pas supprimer de sauvegarde à la demande : la suppression se confirme toujours dans l’espace client. Sans `--keep-config`, la clé locale est effacée et seule votre clé de récupération permet encore de lire les sauvegardes : vérifiez-la d’abord avec `neverwiped recovery-key check`.

## neverwiped version

```text
$ neverwiped version
neverwiped 0.3.0 (restic 0.18.1)
```

Aussi : `neverwiped --version`, `neverwiped -v`. L’aide : `neverwiped help`, `--help` ou `-h`.

## Variables d’environnement

| Variable | Effet |
|---|---|
| `NEVERWIPED_API_KEY` | Clé d’API de compte pour `install`, `recover` et `feedback`, à la place de `--api-key`. |
| `NEVERWIPED_API_URL` | Adresse de la plateforme pour `install`, `recover` et `feedback`, à la place de `--api-url`. |
| `NEVERWIPED_LANG` | Langue des messages : `fr`, `en` ou `es` (sinon `LC_ALL`, `LC_MESSAGES`, `LANG`, puis l’anglais). |
| `NEVERWIPED_RECOVERY_KEY` | Clé de récupération pour `recover` et `recovery-key check`, à la place de `--recovery-key-file`. |
| `NEVERWIPED_RELEASES_URL` | Pour `update` : autre adresse des versions signées (miroir, par défaut `<plateforme>/downloads/releases`). La signature reste vérifiée avec les clés intégrées. |
| `NEVERWIPED_RESTIC_BASE_URL` | Miroir de téléchargement de restic (mêmes noms de fichiers que les versions GitHub, par exemple `restic_0.18.1_linux_amd64.bz2`). L’empreinte SHA-256 reste vérifiée. |
| `NEVERWIPED_NO_SETUP=1` | Pour `install.sh` uniquement : installe le binaire sans lancer `neverwiped install`. |
| `NEVERWIPED_ROOT` | Préfixe de tous les chemins ci-dessous (tests, conteneurs). Ne pas utiliser en production. |

## Fichiers

| Chemin | Contenu |
|---|---|
| `/usr/local/bin/neverwiped` | l’agent |
| `/etc/neverwiped/config.json` | configuration, clé d’agent, identifiant du dépôt, limites des sauvegardes (root seulement, 0600) |
| `/etc/neverwiped/repo.key` | clé de chiffrement du dépôt, générée sur le serveur, jamais envoyée (0600) |
| `/var/lib/neverwiped/bin/restic-0.18.1` | restic |
| `/var/lib/neverwiped/bin/neverwiped.previous` | binaire remplacé par la dernière `neverwiped update`, pour `--rollback` |
| `/var/lib/neverwiped/dumps/` | exports de bases pendant une sauvegarde (vidé ensuite) |
| `/var/cache/neverwiped/` | cache de restic |
| `/var/log/neverwiped.log` | journal local, une ligne horodatée par événement, dans la langue de l’agent (étiquettes stables `[backup-ok]` et `[backup-failed]`) |
| `/etc/systemd/system/neverwiped-backup.{service,timer}` | planification systemd, ou `/etc/cron.d/neverwiped`, ou la crontab de root |

## Codes de sortie

| Code | Signification |
|---|---|
| `0` | succès |
| `1` | échec (message après `Erreur :` sur la sortie d’erreur ; `Error:` en anglais et en espagnol) |
| `2` | mauvaise utilisation : commande ou option inconnue, argument manquant, clé d’API absente en mode `--yes`, commande lancée sans argument |