Premiers pas

Avant de commencer

• Un serveur Linux en amd64 (x86_64) ou arm64 (aarch64) : Debian, Ubuntu, RHEL et dérivés (Rocky, AlmaLinux, Fedora), Alpine. Noyau Linux 3.2 ou plus récent ; les systèmes 32 bits ne sont pas pris en charge. Avec systemd, ou cron avec son démon lancé (sur Alpine : rc-update add crond default && rc-service crond start).
• Sur la famille RHEL, sudo ne cherche pas dans /usr/local/bin : tapez sudo /usr/local/bin/neverwiped …, ou travaillez dans un shell root (sudo -i).
• Un accès root, ou sudo.
• curl ou wget, et sha256sum ou openssl (présents sur presque toutes les distributions).
• Des connexions HTTPS sortantes (port 443) vers https://neverwiped.com (la plateforme), https://storage.neverwiped.com (le stockage des sauvegardes, en France) et https://github.com (restic est téléchargé une fois, à l’installation, et son empreinte SHA-256 vérifiée).
• Un compte NeverWiped avec une adresse e-mail confirmée : l’essai gratuit dure 14 jours, sans carte. Puis une clé d’API : espace client › Clés d’API › Créer. Elle commence par nw_acc_ et n’est affichée qu’une fois.

1. Installer en une commande

Sur le serveur, en root :

curl -fsSL https://neverwiped.com/install.sh | sh

Le script demande votre clé d’API, montre ce qu’il va sauvegarder et attend votre accord. Pour tout répondre d’avance (scripts, agents IA) :

curl -fsSL https://neverwiped.com/install.sh | sh -s -- --api-key "$NEVERWIPED_API_KEY" --yes

Pas root ? Remplacez | sh par | sudo sh. Pas de curl ? wget -qO- https://neverwiped.com/install.sh | sh.

Plus rapide : le tableau de bord de votre espace client fabrique cette commande avec une nouvelle clé d’API déjà dedans (… | sh -s -- --api-key CLÉ). Un clic, un collage : le script ne pose plus que les questions sur le plan et la première sauvegarde. La clé reste dans l’historique de votre shell ; elle sert seulement à enregistrer des serveurs, et vous pouvez la révoquer dans Clés d’API une fois vos serveurs installés, sans arrêter leurs sauvegardes.

Ce qui se passe, dans l’ordre :

1. Le script télécharge l’agent pour votre architecture, vérifie son empreinte SHA-256 et l’installe dans /usr/local/bin/neverwiped.
2. neverwiped install télécharge restic 0.18.1 (empreinte vérifiée), repère vos sites, vos bases et vos volumes Docker, et affiche le plan.
3. Après votre accord, il enregistre le serveur, crée le dépôt chiffré avec une clé générée sur le serveur, et affiche une seule fois la clé de récupération.
4. Il planifie les sauvegardes selon votre formule et lance la première.

Pour ajuster le plan, ajoutez des options après --yes : --include /data, --exclude "*.log", --no-databases, --no-docker. Voir la référence des commandes.

Taille et exclusions avant la première sauvegarde

Avant de vous demander de valider le plan, l’installation le mesure : taille et nombre de fichiers de chaque dossier et volume Docker une fois les exclusions appliquées, les plus gros dossiers, la taille des fichiers des bases locales, et ce que retirerait chaque préréglage d’exclusions. Elle ne lit que les tailles (aucun contenu) et n’envoie rien. Elle s’arrête au bout de 90 secondes et affiche alors « au moins » ; --no-estimate la saute.

Vous pouvez lancer la même mesure avant de souscrire, avec les mêmes options que l’installation. Rien n’est enregistré, aucun appel réseau n’est fait :

neverwiped estimate
neverwiped estimate --preset logs --exclude /var/www/site/tmp
neverwiped estimate --json

Le chiffre est la taille avant compression et déduplication : la première sauvegarde envoie au plus ce volume. Le texte et les bases se compressent en général bien, les photos, vidéos et archives presque pas. Les exports de bases n’y sont pas comptés : l’estimation affiche à la place la taille des fichiers des bases sur le disque, et un export est en général plus petit. Pour les bases dans Docker, la taille de l’export n’est pas mesurée. Comparez le total avec l’espace de chaque formule sur la page des tarifs.

Une fois le serveur enregistré, l’installation compare l’estimation avec l’espace restant de votre abonnement. Si les fichiers et volumes dépassent à eux seuls cet espace, elle demande avant la première sauvegarde, avec « non » comme réponse par défaut. Avec --yes, elle ne lance pas la première sauvegarde, pour qu’elle ne s’arrête pas à mi-chemin au quota. Les sauvegardes planifiées restent actives.

Préréglages. Aucun n’est appliqué par défaut. Ajoutez-en avec --preset NOM (répétable, ou --preset logs,build, ou --preset all), avec estimate ou install. L’estimation propose ceux qui feraient gagner au moins 100 Mio sur votre serveur.

Ne choisissez archives que si ces fichiers sont des copies de données que le plan sauvegarde déjà : une archive qui est votre seule copie de quelque chose ne serait plus sauvegardée. De même pour logs si vous avez besoin des anciens journaux (un audit, par exemple). Les motifs suivent la syntaxe de restic : un motif sans / au début s’applique à toute profondeur. Comme toutes les options, les préréglages ne sont pas mémorisés : répétez-les quand vous relancez neverwiped install.

2. Ranger la clé de récupération

À la fin de l’installation, l’agent affiche cet encadré :

========================================================================
CLÉ DE RÉCUPÉRATION — notez-la maintenant, hors de ce serveur.

    Ab3dEf-GhJkMn-PqRsTu-VwXyZa-b2c3d4-e5f6g7

Serveur : web-01 (identifiant 0b6a3c1e-2f4d-4e8a-9c7b-5d1e2f3a4b5c). Code de contrôle de cette clé : 4342-B317.
Notez le nom du serveur et le code de contrôle à côté de la clé : chaque serveur a sa propre clé de récupération.
Elle ne sera plus jamais affichée et NeverWiped ne la connaît pas.
Sans elle, si ce serveur est perdu, vos sauvegardes sont illisibles.
========================================================================

Rangez-la tout de suite dans votre gestionnaire de mots de passe, pas sur le serveur. Pourquoi c’est important : chiffrement et clé de récupération.

Puis testez la copie notée : sudo neverwiped recovery-key check (la clé n’est envoyée nulle part). Perdue plus tard ? Tant que le serveur tourne, sudo neverwiped recovery-key new en crée une nouvelle : clé de récupération perdue.

3. La première sauvegarde

L’installation la lance pour vous (sauf avec --no-backup). Lancez-en une quand vous voulez :

neverwiped backup now

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

Seuls les changements sont envoyés. Ensuite, les sauvegardes tournent seules : chaque nuit en Pro et Business, une fois par semaine en Essentiel, à heure fixe entre 1 h et 6 h environ, heure du serveur. Elles tournent en priorité basse ; pour plafonner aussi leur débit d’envoi ou leur CPU, voir Débit, CPU et priorité.

4. Vérifier l’état

neverwiped status
neverwiped list

status affiche le serveur, ce qui est sauvegardé, votre formule, l’état des sauvegardes, l’espace utilisé et la dernière sauvegarde :

Serveur      : vps-prod (identifiant be1e7955-1dd6-4211-8002-7746d6ede9e2)
Plateforme   : https://neverwiped.com
Agent        : neverwiped 0.2.0, restic 0.18.1
Dossiers     : /etc, /var/spool/cron, /var/www
Base         : postgresql (locale)
Abonnement   : Essentiel (trialing)
Sauvegardes  : hebdomadaire, actives
Espace       : 5,3 Mo utilisés sur 5,0 Go
Dernière     : 2026-11-04 02:16
Planification: minuteur systemd (…)

À vérifier : Sauvegardes indique actives, Dernière est une date récente, et Planification a trouvé un minuteur ou une tâche cron. Vous recevez aussi un e-mail si une sauvegarde échoue ou si aucune n’a lieu pendant un moment : voir état et alertes.

5. Restaurer

Commencez par la liste des sauvegardes ; les dates sont à l’heure du serveur.

neverwiped list

Toutes les restaurations ci-dessous vont dans un dossier à part : rien n’est écrasé sur le serveur. Les chemins d’origine sont recréés dessous : /var/www/site/index.html revient dans /root/restore/var/www/site/index.html.

Un fichier

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

--include prend le chemin complet tel qu’il était sur le serveur ; majuscules et minuscules comptent. Si ls répond No such file (ou Aucun fichier), ce chemin n’est pas dans cette sauvegarde : vérifiez l’orthographe, ou choisissez une sauvegarde plus ancienne dans neverwiped list. cp -a garde le propriétaire et les droits du fichier. Supprimez ensuite le dossier : sinon la copie est sauvegardée à nouveau à la prochaine sauvegarde si /root fait partie de votre plan.

Un dossier

Choisissez la nuit d’avant l’incident (ici le 3 novembre), comparez, puis recopiez ce qu’il faut :

neverwiped restore 2026-11-03 --include /var/www/site/uploads --target /root/restore
diff -rq /root/restore/var/www/site/uploads /var/www/site/uploads
cp -a /root/restore/var/www/site/uploads/. /var/www/site/uploads/

Une date désigne la dernière sauvegarde de ce jour. Vous pouvez aussi donner latest, une minute ("2026-11-03 22:59") ou un identifiant vu dans neverwiped list. Ajoutez --yes si le dossier n’est pas vide.

Une base de données

Chaque sauvegarde contient un export des bases trouvées, en fichiers .sql, fait pendant qu’elles tournent. Pour PostgreSQL c’est pg_dumpall : toutes les bases, chacune cohérente à elle seule, plus les rôles. Pour MySQL et MariaDB c’est mysqldump (ou mariadb-dump) --all-databases --single-transaction : toutes les bases lues dans un même instantané sans bloquer le site, plus les utilisateurs et leurs droits, les procédures, triggers et événements. Un export coupé avant la fin fait échouer la sauvegarde ; il n’est jamais gardé comme bon. Rien n’est réimporté automatiquement, volontairement.

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.

Choisissez la sauvegarde dans neverwiped list (heure du serveur), puis ramenez ses exports dans un dossier à part. Donnez la minute affichée par list, un jour (la dernière sauvegarde de ce jour) ou un identifiant :

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

Arrêtez d’abord 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.

Une seule base PostgreSQL abîmée, les autres intactes (un DELETE de trop, une migration ratée). Ne réimportez pas le fichier entier par-dessus des bases qui existent encore : il remet des lignes en double dans leurs tables, ou s’arrête à mi-chemin sur des erreurs. Extrayez la partie de la base voulue (ici shop), mettez la base abîmée de côté sous un autre nom, puis importez cette partie seule :

sed -n '/^-- Database "shop" dump$/,/^-- PostgreSQL database dump complete$/p' /root/restore/var/lib/neverwiped/dumps/postgresql-local.sql > /root/restore/shop.sql
grep -c '^CREATE DATABASE' /root/restore/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/restore/shop.sql

grep -c doit afficher 1. 0 veut dire que cette sauvegarde n’a pas de base de ce nom : listez-les avec grep '^-- Database' /root/restore/var/lib/neverwiped/dumps/postgresql-local.sql. Si le renommage répond que la base « is being accessed by other users », l’application est encore connectée. ON_ERROR_STOP=1 s’arrête à la première erreur au lieu de continuer. Vérifiez votre application, reprenez dans shop_damaged ce qu’il vous faut de récent, puis supprimez-la avec runuser -u postgres -- psql -d postgres -c 'DROP DATABASE shop_damaged'. Cela vaut pour toute base sauf postgres et template1, qu’un export ne recrée jamais : pour celles-là, prenez le fichier entier sur un serveur neuf.

Une base MySQL ou MariaDB abîmée, les autres intactes. Le fichier contient toutes les bases l’une après l’autre, et chaque table y commence par DROP TABLE IF EXISTS. Prenez les réglages du début du fichier (jeu de caractères, fuseau horaire, contrôle des clés étrangères) et la partie de votre base (ici shop), mettez la base abîmée de côté, puis importez cette partie :

D=/root/restore/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/restore/shop.sql
grep -c '^USE `shop`;' /root/restore/shop.sql
mysqldump --single-transaction --routines --events --triggers --databases shop > /root/restore/shop-damaged.sql
mysql < /root/restore/shop.sql

grep -c doit afficher 1. 0 veut dire que cette sauvegarde n’a pas de base de ce nom : le premier grep liste celles qu’elle contient. mysql s’arrête à la première erreur. Chaque table de la sauvegarde est supprimée et recréée telle qu’elle était ; une table créée depuis reste telle quelle ; les utilisateurs et mots de passe ne sont pas touchés. Vérifiez votre application : shop-damaged.sql contient la base telle qu’elle était juste avant, si vous y cherchez quelque chose de récent. Sur MariaDB 11 sans les commandes mysql et mysqldump, tapez mariadb et mariadb-dump. Quand root a un mot de passe, ces commandes le lisent dans /root/.my.cnf ; sur une ancienne Debian qui se connecte avec /etc/mysql/debian.cnf, ajoutez --defaults-extra-file=/etc/mysql/debian.cnf juste après mysql et mysqldump.

Toutes les bases ont disparu, ou c’est un serveur neuf : réimportez le fichier entier. Il recrée aussi les rôles ; là où un rôle existe déjà, vous voyez role "…" already exists, sans conséquence.

# PostgreSQL sur le serveur (toutes les bases, rôles compris)
runuser -u postgres -- psql postgres < /root/restore/var/lib/neverwiped/dumps/postgresql-local.sql
# MySQL ou MariaDB sur le serveur
mysql < /root/restore/var/lib/neverwiped/dumps/mysql-local.sql

Sur Alpine, qui n’a pas runuser, utilisez su postgres -c 'psql postgres' avec le même < fichier, et de même pour les autres lignes psql.

Pour MySQL et MariaDB, le fichier entier ramène aussi les utilisateurs, leurs mots de passe et leurs droits tels qu’ils étaient à cette sauvegarde (un mot de passe changé depuis redevient l’ancien), et les rend actifs (FLUSH PRIVILEGES). Importez-le dans le même produit (MySQL dans MySQL, MariaDB dans MariaDB), en version égale ou plus récente ; sur MariaDB, lancez ensuite mariadb-upgrade si la version est plus récente. De MySQL vers MariaDB ou l’inverse, importez les bases une par une comme ci-dessus et recréez les utilisateurs. Deux messages possibles : Unknown command '\-' à la ligne 1 veut dire que le fichier vient d’un MariaDB récent et que votre client est plus ancien, ou est celui de MySQL : supprimez cette première ligne avec sed -i '1{/999999/d}' <fichier> et relancez l’import. Got a packet bigger than 'max_allowed_packet' : ajoutez --max-allowed-packet=1G après mysql ; si c’est le serveur qui refuse, augmentez max_allowed_packet dans sa configuration.

Tables MySQL ou MariaDB hors InnoDB. L’instantané unique couvre les tables InnoDB, le moteur par défaut. Si des tables sont en MyISAM ou Aria, le journal des sauvegardes (/var/log/neverwiped.log) le signale : ces tables sont copiées telles qu’elles sont quand vient leur tour, pas au même instant que le reste. Listez-les toutes, puis convertissez-les à un moment calme (la conversion réécrit la table) :

mysql -e "SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND ENGINE <> 'InnoDB' AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')"
mysql -e 'ALTER TABLE shop.hits ENGINE=InnoDB'

Les bases dans Docker reviennent en postgresql-docker-<conteneur>.sql ou mysql-docker-<conteneur>.sql ; les commandes pour les conteneurs sont dans la référence. Les étapes « une seule base » ci-dessus marchent de même avec docker exec -i <conteneur> sh -c 'exec psql -U "${POSTGRES_USER:-postgres}" -v ON_ERROR_STOP=1 -d postgres' < /root/restore/shop.sql. Pour MySQL ou MariaDB dans un conteneur, fabriquez shop.sql de la même façon à partir de mysql-docker-<conteneur>.sql et importez-le avec la commande pour conteneur de la référence à la place de mysql. Une fois fini, rm -rf /root/restore : sinon les exports sont sauvegardés à nouveau par la prochaine sauvegarde si /root est dans votre plan.

Un volume Docker

Comment un volume est sauvegardé. neverwiped status liste vos volumes et la façon dont chacun est pris :

• à chaud (le choix par défaut pour les fichiers envoyés, les fichiers et la configuration) : lu pendant que ses conteneurs tournent. Dans la sauvegarde, il se trouve sous /var/lib/docker/volumes/<nom>/_data.
• copié avec ses conteneurs en pause (proposé à l’installation pour Redis, Valkey, MongoDB, Elasticsearch, OpenSearch, InfluxDB, RabbitMQ, Vaultwarden et semblables) : les conteneurs en marche qui utilisent le volume sont mis en pause (docker pause : figés, ni arrêtés ni redémarrés), le volume est copié sur le même disque, ils repartent, puis la copie est envoyée. La pause dure le temps de la copie locale, quelques secondes pour quelques Go. Dans la sauvegarde, il se trouve sous /var/lib/neverwiped/volumes/<nom>. La copie est ce qu’une coupure de courant à cet instant laisserait sur le disque : une application qui tient un journal (Redis, MongoDB, SQLite…) repart de là comme après un arrêt brutal.

La copie en pause demande, sur le disque de /var/lib/neverwiped, la taille du volume plus 10 % et 1 Go d’espace libre, et elle est arrêtée au bout de 5 minutes. Quand elle ne peut pas être faite, le volume est sauvegardé à chaud cette fois-là et la sauvegarde est marquée en échec avec la raison, pour que vous le voyiez. Changez la façon de prendre un volume avec neverwiped install --yes --pause-volume <nom> ou --live-volume <nom> (redonnez ces options à chaque nouveau install). Les volumes des conteneurs PostgreSQL, MySQL et MariaDB ne sont pas copiés en fichiers : c’est leur export qui l’est (Une base de données). Les dossiers montés depuis l’hôte (./data:/data) sont sauvegardés avec ce dossier, à chaud.

Remettre un volume. Restaurez-le dans un dossier à part ; le CLI affiche où il est revenu :

V=app_uploads
neverwiped restore latest --include /var/lib/docker/volumes/$V/_data --target /root/restore   # volume à chaud
neverwiped restore latest --include /var/lib/neverwiped/volumes/$V --target /root/restore      # copie en pause
SRC=/root/restore/var/lib/docker/volumes/$V/_data      # ou /root/restore/var/lib/neverwiped/volumes/$V

Puis arrêtez ce qui l’utilise, mettez son contenu actuel de côté et recopiez la sauvegarde :

docker ps -a --filter volume=$V                 # les conteneurs qui l’utilisent
docker compose stop                             # dans le dossier de l’application (ou : docker stop <conteneur>…)
MP=$(docker volume inspect -f '{{.Mountpoint}}' $V)
mkdir -p /root/volume-before && cp -a "$MP/." /root/volume-before/
test -d "$MP/" && find "$MP" -mindepth 1 -delete
cp -a "$SRC/." "$MP/"
docker compose start                            # (ou : docker start <conteneur>…)

Propriétaires, droits et liens reviennent comme avant. Le volume n’existe plus (nouveau serveur, docker compose down -v) : lancez d’abord docker compose up --no-start dans le dossier de l’application, qui crée le volume et les conteneurs sans les démarrer, puis les trois dernières lignes (ou docker volume create $V sans Compose). Un volume au nom de 64 caractères est anonyme : il appartient à un conteneur et change de nom quand le conteneur est recréé ; recopiez donc dans le volume du nouveau conteneur (docker inspect -f '{{range .Mounts}}{{.Name}} {{end}}' <conteneur>). Ne restaurez pas un volume à chaud en place (sans --target) pendant que ses conteneurs tournent : les fichiers changeraient sous l’application, et les fichiers créés depuis la sauvegarde resteraient. Quand tout fonctionne : rm -rf /root/restore /root/volume-before.

Un serveur entier

Le serveur tourne encore (mise à jour ratée, configuration cassée) : restaurez en place. Les chemins sauvegardés sont remplacés par leur version de cette nuit-là. Arrêtez d’abord vos applications.

neverwiped restore 2026-11-03

L’agent montre ce qui va être écrasé et demande de taper RESTAURER. Sans terminal il refuse, sauf avec --yes, qui vaut accord explicite d’écrasement.

Le serveur est perdu (supprimé, disque cassé, plus d’accès). Il vous faut deux choses : une clé d’API de compte (espace client › Clés d’API › Créer) et votre clé de récupération. Tout se fait sur le nouveau serveur, sans le support. Installez-y d’abord vos logiciels de base (serveur web, serveur de bases de données) avec le gestionnaire de paquets, comme sur l’ancien.

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

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

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

neverwiped recover

Il demande la clé d’API, affiche les serveurs de votre compte (choisissez le serveur perdu), demande la clé de récupération (masquée pendant que vous la collez) puis une confirmation. Il révoque alors l’identifiant de stockage et la clé d’agent du serveur perdu : si l’ancienne machine tourne encore, ou revient, elle ne peut plus lire ni ajouter de sauvegardes. Votre clé de récupération devient la clé de ce serveur (/etc/neverwiped/repo.key) et ne nous est jamais envoyée ; gardez votre copie, aucune nouvelle clé n’est créée. Un e-mail vous en informe.

Si la clé 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 ; pour le désigner avec --server, utilisez son identifiant.

Avec plusieurs serveurs, recover compare d’abord votre clé au code de contrôle du serveur choisi (le code affiché avec la clé à l’installation et sur la page du serveur). Une clé d’un autre serveur est refusée avant toute révocation, et le message nomme le serveur auquel elle appartient. Voir plusieurs serveurs.

Dans un script (sans terminal), passez tout en options. Mettez d’abord la clé de récupération dans un fichier réservé à root (cat, collez, Entrée, Ctrl-D), pour qu’elle reste hors de l’historique du shell :

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é sur le nouveau serveur :

neverwiped list
neverwiped restore latest --target /root/restore

4. Remettez en place ce dont vous avez besoin. C’est une nouvelle machine : copiez vos dossiers de données et d’applications, et les fichiers de configuration de vos logiciels un par un, pas le système entier. Par exemple :

cp -a /root/restore/var/www/. /var/www/
cp -a /root/restore/etc/nginx/sites-available/example.com /etc/nginx/sites-available/

Ne copiez pas /root/restore/etc par-dessus /etc, et ne lancez pas neverwiped restore en place sur un nouveau serveur. Cela ramènerait le réseau, les disques (fstab) et les réglages SSH de l’ancienne machine, ainsi que /etc/neverwiped, la configuration d’agent du serveur perdu dont recover vient de révoquer les clés : l’agent cesserait de fonctionner. Réimportez ensuite les bases avec les lignes « nouveau serveur » de une base de données (les fichiers sont dans /root/restore/var/lib/neverwiped/dumps), puis démarrez vos applications.

5. Nettoyez, 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) :

rm -rf /root/restore
neverwiped install --yes

Supprimez d’abord le dossier : sinon la copie restaurée part dans la prochaine sauvegarde si /root est dans votre plan. neverwiped list montre ensuite les sauvegardes de l’ancien serveur à côté des nouvelles ; vous pouvez toujours restaurer depuis les anciennes.

Dernier recours, restic seul, sans l’agent (plus d’accès à votre compte, par exemple) : écrivez au support depuis l’adresse de votre compte, avec le nom du serveur perdu. Le support délivre un nouvel identifiant de stockage pour ce dépôt, par un canal sûr, et invalide l’ancien. Le support ne peut pas lire vos sauvegardes : il n’a pas la clé. Puis, sur le nouveau serveur, installez restic 0.18.1 et vérifiez son empreinte (arm64 : restic_0.18.1_linux_arm64.bz2, empreinte 87f53fddde38764095e9c058a3b31834052c37e5826d2acf34e18923c006bd45), et restaurez avec la clé de récupération (remplacez les majuscules par votre clé et l’identifiant fourni par le support) :

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/restore
rm -f /root/recovery.key

Reprenez ensuite à l’étape 4.

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 d’un chiffrement que nous ne pouvons pas ouvrir.

Par un agent IA : le plan, puis l’accord

Quand un agent IA (Claude Code, Codex, Cursor) restaure pour vous, faites-lui d’abord demander avec un plan. --plan n’écrit rien, ne prend pas le verrou et ne contacte pas NeverWiped :

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

Il affiche quelle sauvegarde (date et identifiant), quels chemins, où il écrirait (un dossier à part, vide ou non, ou en place), un code d’accord et la commande exacte qui lance cette restauration. L’agent vous montre ce plan et attend. Après votre accord, il lance la commande affichée sans la modifier, par exemple (l’identifiant et le code sont des exemples) :

neverwiped restore 8b28999a --include /var/www/site/uploads --target /root/restauration --approve K7QD-2M9F

Avant d’écrire quoi que ce soit, l’agent NeverWiped recalcule le code à partir de la sauvegarde, du dossier et des chemins. Si l’un d’eux diffère du plan que vous avez approuvé (latest désigne maintenant une sauvegarde plus récente, un dossier ou un chemin a été changé), il refuse et rien n’est écrit : demandez un nouveau plan. La commande affichée désigne la sauvegarde par son identifiant : une sauvegarde lancée entre votre accord et la restauration ne change pas ce qui revient.

Le code n’est pas un mot de passe et n’empêche personne en root de restaurer sans lui. Il lie votre accord à un plan. Recopier des fichiers de /root/restauration sur les fichiers en service est une étape à part, et un accord à part. La page agents IA donne un prompt pour cela.

6. Tester une restauration dès aujourd’hui

Une sauvegarde jamais restaurée n’est qu’un espoir. Faites-le le premier jour, puis une fois par mois :

neverwiped restore latest --target /root/test-restore --yes
ls -R /root/test-restore | head
rm -rf /root/test-restore

Puis vérifiez que vous retrouvez la clé de récupération dans votre gestionnaire de mots de passe.

Ensuite

• Chiffrement et clé de récupération : ce que nous pouvons faire, et ce que nous ne pouvons pas.
• Stockage, conservation et nettoyage : l’ajout seul, et la fenêtre d’une heure.
• Ce qui arrive sur votre serveur, et comment désinstaller.
• Toutes les commandes et options, tous les messages d’erreur.