# Restaurer

Trois situations : récupérer un fichier ou un dossier, revenir en arrière sur tout le serveur, ou reconstruire après la perte du serveur. Dans tous les cas, commencez par la liste :

```sh
neverwiped list
```

## Restaurer dans un dossier à part (recommandé)

C’est la méthode sûre : rien n’est écrasé, vous comparez puis copiez ce dont vous avez besoin.

```sh
neverwiped restore 2026-11-03 --target /root/restauration --yes
```

- `2026-11-03` : la dernière sauvegarde de ce jour. Aussi : `latest`, une minute précise (`"2026-11-03 22:59"`) ou un identifiant (`8b28999a`).
- Les chemins d’origine sont recréés sous la cible : `/var/www/site/index.html` se retrouve dans `/root/restauration/var/www/site/index.html`.
- `--yes` est nécessaire seulement si la cible n’est pas vide (confirmation des fichiers de même nom).

Puis, par exemple :

```sh
diff -r /root/restauration/var/www/site /var/www/site
cp -a /root/restauration/var/www/site/uploads/. /var/www/site/uploads/
```

## Restaurer un seul dossier ou fichier

```sh
neverwiped restore latest --include /var/www/site/uploads --target /root/restauration
```

`--include` prend le chemin complet tel qu’il était sur le serveur (majuscules et minuscules comptent) ; il est répétable. Pour un seul fichier, vérifiez qu’il est revenu, recopiez-le, puis supprimez le dossier :

```sh
neverwiped restore latest --include /var/www/site/wp-config.php --target /root/restauration
ls -l /root/restauration/var/www/site/wp-config.php
cp -a /root/restauration/var/www/site/wp-config.php /var/www/site/wp-config.php
rm -rf /root/restauration
```

- Si `ls` répond *Aucun fichier ou dossier de ce type* (*No such file*), ce chemin n’est pas dans cette sauvegarde : vérifiez l’orthographe, ou choisissez une sauvegarde plus ancienne dans `neverwiped list` (le fichier a peut-être été supprimé avant elle).
- `cp -a` garde le propriétaire et les droits du fichier.
- Supprimez le dossier ensuite : sinon la copie est sauvegardée à nouveau à la prochaine sauvegarde si `/root` fait partie de votre plan.

## Restaurer en place (écraser les fichiers actuels)

```sh
neverwiped restore 2026-11-03
```

L’agent affiche ce qui va être écrasé et demande de taper le mot de confirmation : `RESTAURER` en français, `RESTORE` en anglais, `RESTAURAR` en espagnol (l’agent suit la langue du système ; `NEVERWIPED_LANG=fr|en|es` la force). Sortie en français :

```text
Restauration EN PLACE de la sauvegarde du 2026-11-03 22:59 (e7ef4663).
Les fichiers existants de /etc, /var/lib/neverwiped/dumps, /var/spool/cron, /var/www seront ÉCRASÉS par leur version sauvegardée.
Pour restaurer ailleurs sans rien écraser : --target /root/restauration
Tapez RESTAURER pour confirmer :
```

En mode non interactif, `--yes` vaut confirmation explicite : `neverwiped restore 2026-11-03 --yes`. Sans terminal et sans `--yes`, la restauration est refusée et rien n’est modifié.

Conseils : arrêtez d’abord l’application (`systemctl stop …` ou `docker compose stop`), restaurez de préférence avec `--include` les seuls dossiers utiles plutôt que `/etc` en entier, puis redémarrez.

## Restaurer une base de données

Chaque sauvegarde contient un export complet des bases détectées, sous forme de fichiers `.sql` :

| Fichier | Source |
|---|---|
| `postgresql-local.sql` | PostgreSQL installé sur le serveur (`pg_dumpall`) |
| `mysql-local.sql` | MySQL ou MariaDB installé sur le serveur |
| `postgresql-docker-<conteneur>.sql`, `mysql-docker-<conteneur>.sql` | base dans un conteneur Docker |

**Quel moment.** Vous revenez à l’heure d’une sauvegarde, pas à n’importe quel instant entre deux : chaque nuit en Pro et Business, une fois par semaine en Essentiel. Les changements faits après la dernière sauvegarde ne sont dans aucune. Avant une opération risquée (migration, gros import), lancez `neverwiped backup now`. Pour PostgreSQL, l’export est fait par `pg_dumpall` : toutes les bases, chacune cohérente à elle seule, plus les rôles. Pour MySQL et MariaDB, par `mysqldump` (ou `mariadb-dump`) `--all-databases --single-transaction` : toutes les bases lues dans un même instantané sans bloquer le site (tables InnoDB ; les tables MyISAM ou Aria sont copiées à leur tour, et le journal le signale), plus les utilisateurs et leurs droits. Un export coupé avant la fin fait échouer la sauvegarde.

1. Choisissez la sauvegarde dans `neverwiped list` (minute, jour ou identifiant) et restaurez ses exports dans un dossier à part :

```sh
neverwiped list
neverwiped restore "2026-11-03 02:16" --include /var/lib/neverwiped/dumps --target /root/restauration --yes
ls -l /root/restauration/var/lib/neverwiped/dumps
```

2. Arrêtez l’application qui écrit dans la base. Les fichiers ne sont lisibles que par root : c’est votre shell root qui les lit (`<`) ; `psql -f` lancé en `postgres` ne peut pas les ouvrir.

3. **Une seule base PostgreSQL abîmée, les autres intactes** : ne réimportez pas le fichier entier par-dessus des bases qui existent encore (lignes en double, ou arrêt à mi-chemin sur des erreurs). Extrayez la base voulue (ici `shop`), mettez la base abîmée de côté sous un autre nom, puis importez la partie extraite seule :

```sh
sed -n '/^-- Database "shop" dump$/,/^-- PostgreSQL database dump complete$/p' /root/restauration/var/lib/neverwiped/dumps/postgresql-local.sql > /root/restauration/shop.sql
grep -c '^CREATE DATABASE' /root/restauration/shop.sql
runuser -u postgres -- psql -d postgres -c 'ALTER DATABASE shop RENAME TO shop_damaged'
runuser -u postgres -- psql -v ON_ERROR_STOP=1 -d postgres < /root/restauration/shop.sql
```

`grep -c` doit afficher `1` (`0` : pas de base de ce nom dans cette sauvegarde ; `grep '^-- Database'` sur le fichier les liste). Si le renommage répond « is being accessed by other users », l’application est encore connectée. Vérifiez l’application, reprenez dans `shop_damaged` ce qu’il faut de récent, puis `runuser -u postgres -- psql -d postgres -c 'DROP DATABASE shop_damaged'`. Ne vaut pas pour les bases `postgres` et `template1`, qu’un export ne recrée jamais.

3 bis. **Une seule base MySQL ou MariaDB abîmée, les autres intactes** : prenez les réglages du début du fichier (jeu de caractères, fuseau horaire, clés étrangères) et la partie de la base voulue (ici `shop`), gardez une copie de la base abîmée, puis importez cette partie. Chaque table de la sauvegarde y est supprimée puis recréée telle qu’elle était ; les utilisateurs ne sont pas touchés.

```sh
D=/root/restauration/var/lib/neverwiped/dumps
grep '^-- Current Database' $D/mysql-local.sql
{ sed -n '1,/^-- Current Database: /p' $D/mysql-local.sql; sed -n '/^-- Current Database: `shop`$/,/^-- Current Database: /p' $D/mysql-local.sql; } > /root/restauration/shop.sql
grep -c '^USE `shop`;' /root/restauration/shop.sql
mysqldump --single-transaction --routines --events --triggers --databases shop > /root/restauration/shop-damaged.sql
mysql < /root/restauration/shop.sql
```

`grep -c` doit afficher `1`. `mysql` s’arrête à la première erreur. Sur MariaDB 11 sans `mysql` ni `mysqldump`, tapez `mariadb` et `mariadb-dump`.

4. **Toutes les bases ont disparu, ou serveur neuf** : réimportez le fichier entier (l’agent affiche ces commandes à la fin de la restauration). Les erreurs `role "…" already exists` sont sans conséquence.

```sh
# PostgreSQL local (export de toutes les bases, rôles compris)
runuser -u postgres -- psql postgres < /root/restauration/var/lib/neverwiped/dumps/postgresql-local.sql
# MySQL / MariaDB local
mysql < /root/restauration/var/lib/neverwiped/dumps/mysql-local.sql
# PostgreSQL dans Docker
docker exec -i <conteneur> sh -c 'exec psql -U "${POSTGRES_USER:-postgres}" -d postgres' < /root/restauration/var/lib/neverwiped/dumps/postgresql-docker-<conteneur>.sql
# MySQL / MariaDB dans Docker
docker exec -i <conteneur> sh -c 'M=$(command -v mariadb || command -v mysql); MYSQL_PWD="${MARIADB_ROOT_PASSWORD:-${MYSQL_ROOT_PASSWORD:-}}" exec "$M" -uroot' < /root/restauration/var/lib/neverwiped/dumps/mysql-docker-<conteneur>.sql
```

Pour MySQL et MariaDB, le fichier entier ramène aussi les utilisateurs, mots de passe et droits de cette sauvegarde (un mot de passe changé depuis redevient l’ancien). Importez-le dans le même produit (MySQL dans MySQL, MariaDB dans MariaDB), en version égale ou plus récente (puis `mariadb-upgrade` sur un MariaDB plus récent). `Unknown command '\-'` à la ligne 1 : le fichier vient d’un MariaDB récent et le client est plus ancien ; `sed -i '1{/999999/d}' <fichier>` puis relancez. `Got a packet bigger than 'max_allowed_packet'` : ajoutez `--max-allowed-packet=1G` après `mysql`.

Rien n’est réimporté automatiquement, volontairement. Une fois fini, `rm -rf /root/restauration` : sinon les exports sont sauvegardés à nouveau si `/root` est dans votre plan.

Si vous restaurez **en place**, les exports arrivent dans `/var/lib/neverwiped/dumps` : copiez-les ailleurs avant la prochaine sauvegarde, qui vide ce dossier.

## Restaurer un volume Docker

Chaque volume est pris **à chaud** (lu pendant que ses conteneurs tournent ; dans la sauvegarde sous `/var/lib/docker/volumes/<nom>/_data`) ou **copié avec ses conteneurs en pause** le temps d’une copie locale (proposé pour Redis, MongoDB, Elasticsearch… ; dans la sauvegarde sous `/var/lib/neverwiped/volumes/<nom>`). `neverwiped status` indique lequel ; `neverwiped install --yes --pause-volume <nom>` ou `--live-volume <nom>` le change.

```sh
V=app_uploads
neverwiped restore latest --include /var/lib/docker/volumes/$V/_data --target /root/restauration   # ou /var/lib/neverwiped/volumes/$V
SRC=/root/restauration/var/lib/docker/volumes/$V/_data                                             # ou /root/restauration/var/lib/neverwiped/volumes/$V
docker ps -a --filter volume=$V          # les conteneurs qui l’utilisent
docker compose stop                      # dans le dossier de l’application
MP=$(docker volume inspect -f '{{.Mountpoint}}' $V)
mkdir -p /root/volume-avant && cp -a "$MP/." /root/volume-avant/
test -d "$MP/" && find "$MP" -mindepth 1 -delete
cp -a "$SRC/." "$MP/"
docker compose start
```

Si le volume n’existe plus (nouveau serveur, `docker compose down -v`), lancez d’abord `docker compose up --no-start`, qui le crée sans démarrer les conteneurs. Ne restaurez pas un volume à chaud en place pendant que ses conteneurs tournent. Détails : documentation, « Démarrer », section « Un volume Docker ».

## Pendant un impayé ou après l’essai

Quand les nouvelles sauvegardes sont suspendues (essai terminé sans abonnement, impayé après la période de grâce), **la restauration reste possible** jusqu’à la suppression des données annoncée par e-mail. `neverwiped status` affiche alors `SUSPENDUES (restauration toujours possible)`.

## Si le serveur est perdu

Il vous faut seulement **une clé d’API de compte** (espace client, « Clés d’API ») et votre **clé de récupération** notée à l’installation. Tout se fait sur le nouveau serveur, sans le support.

1. Installez l’agent seul, sans l’enregistrer comme nouveau serveur :

```sh
curl -fsSL https://neverwiped.com/install.sh | NEVERWIPED_NO_SETUP=1 sh
```

2. Donnez à ce serveur l’accès aux sauvegardes du serveur perdu :

```sh
neverwiped recover
```

   L’agent demande la clé d’API, liste les serveurs du compte (choisissez celui qui a été perdu), demande la clé de récupération (masquée pendant la saisie) puis une confirmation, car **l’ancien identifiant de stockage et l’ancienne clé d’agent sont révoqués** : si l’ancien serveur tournait encore, ou revenait, il ne pourrait plus lire ni ajouter de sauvegardes. La clé de récupération reste sur ce serveur (elle devient sa clé, `/etc/neverwiped/repo.key`) et n’est jamais envoyée.

   Sans terminal (script) : mettez la clé dans un fichier réservé à root (`cat`, collez, Entrée, Ctrl-D), hors de l’historique du shell :

```sh
umask 077
cat > /root/recovery.key
NEVERWIPED_API_KEY=nw_acc_VOTRE_CLE neverwiped recover --server NOM-DU-SERVEUR-PERDU --recovery-key-file /root/recovery.key --yes
rm -f /root/recovery.key
```

3. Restaurez tout dans un dossier (rien n’est écrasé) :

```sh
neverwiped list
neverwiped restore latest --target /root/restauration
```

4. Remettez en place vos dossiers de données et d’applications, et les fichiers de configuration de vos logiciels **un par un** (installez d’abord ces logiciels avec le gestionnaire de paquets) :

```sh
cp -a /root/restauration/var/www/. /var/www/
```

   Ne copiez pas tout `/root/restauration/etc` sur `/etc` et ne restaurez pas en place sur un nouveau serveur : le réseau, `fstab`, les réglages SSH de l’ancienne machine et `/etc/neverwiped` (la configuration d’agent du serveur perdu, dont les clés viennent d’être révoquées) reviendraient avec. Réimportez les bases depuis `/root/restauration/var/lib/neverwiped/dumps` (fichier entier, voir plus haut).

5. Supprimez le dossier, puis reprenez les sauvegardes sur ce serveur, dans le même dépôt (pas de nouveau serveur, pas de nouvelle clé de récupération : gardez la vôtre) :

```sh
rm -rf /root/restauration
neverwiped install --yes
```

   Sans le `rm -rf`, la copie restaurée partirait dans la prochaine sauvegarde si `/root` est dans le plan.

Si la clé de récupération est refusée (`la clé de récupération n’ouvre pas les sauvegardes de …`), rien n’est conservé sur le serveur : vérifiez la clé (6 groupes de 6 caractères) et relancez `neverwiped recover`. L’espace client affiche alors ce serveur sous le nom du nouveau serveur ; avec `--server`, donnez son identifiant. Détails des options : [Référence des commandes](https://docs.neverwiped.com/commandes).

### Dernier recours : sans l’agent, avec restic seul

Si vous ne pouvez pas utiliser l’agent (plus d’accès à votre compte, par exemple), écrivez au support depuis l’adresse du compte : il vous délivre par un canal sûr un nouvel identifiant d’accès au dépôt (l’ancien est invalidé ; il ne peut pas lire vos sauvegardes). Puis, sur le nouveau serveur, installez restic 0.18.1 en vérifiant son empreinte (amd64 ; pour arm64 : fichier `restic_0.18.1_linux_arm64.bz2`, empreinte `87f53fddde38764095e9c058a3b31834052c37e5826d2acf34e18923c006bd45`) :

```sh
curl -fsSLO https://github.com/restic/restic/releases/download/v0.18.1/restic_0.18.1_linux_amd64.bz2
echo "680838f19d67151adba227e1570cdd8af12c19cf1735783ed1ba928bc41f363d  restic_0.18.1_linux_amd64.bz2" | sha256sum -c
bunzip2 restic_0.18.1_linux_amd64.bz2 && install -m 0755 restic_0.18.1_linux_amd64 /usr/local/bin/restic
umask 077
printf '%s' 'VOTRE-CLE-DE-RECUPERATION' > /root/recovery.key
export RESTIC_REPOSITORY='rest:https://IDENTIFIANT:MOT_DE_PASSE@storage.neverwiped.com/IDENTIFIANT/'
export RESTIC_PASSWORD_FILE=/root/recovery.key
restic snapshots
restic restore latest --target /root/restauration
```

Sans la clé de récupération, et sans l’ancien serveur, **les sauvegardes sont illisibles pour tout le monde**, nous compris. C’est le prix du chiffrement côté client.

## Tester ses restaurations

Une sauvegarde jamais restaurée n’est qu’une hypothèse. Nous vous recommandons, au moins une fois par mois et après chaque changement important du serveur :

```sh
neverwiped restore latest --target /root/test-restauration --yes
ls -R /root/test-restauration | head
# pour une base : vérifiez que l’export n’est pas vide et se réimporte dans une base de test
rm -rf /root/test-restauration
```

et de vérifier que vous retrouvez votre clé de récupération dans votre gestionnaire de mots de passe.