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 :

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.

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 :

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

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 :

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)

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 :

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 :

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 :

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 :

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.

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.

# 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.

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 :

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

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 :

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é) :

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) :

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) :

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.

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) :

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 :

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.