Ce qui arrive sur votre serveur

L’arborescence

/
├── usr/local/bin/
│   └── neverwiped                          l’agent (un seul binaire statique)
├── etc/
│   ├── neverwiped/
│   │   ├── config.json                     configuration, clé du serveur, identifiant de stockage (0600, root)
│   │   └── repo.key                        clé de chiffrement du dépôt, jamais envoyée (0600, root)
│   └── systemd/system/
│       └── neverwiped-backup.{service,timer}   planification (ou /etc/cron.d/neverwiped, ou la crontab de root)
└── var/
    ├── lib/neverwiped/
    │   ├── bin/restic-0.18.1               restic, empreinte vérifiée
    │   ├── dumps/                          exports de bases pendant une sauvegarde, vidé ensuite
    │   ├── volumes/                        copies en pause des volumes Docker pendant une sauvegarde, vidé ensuite
    │   └── paused                          conteneurs mis en pause pour cette copie, jusqu’à leur relance
    ├── cache/neverwiped/                   cache de restic
    └── log/neverwiped.log                  journal local, une ligne horodatée par événement

Ce qui est sauvegardé par défaut : /etc, /var/spool/cron, /root et /home s’ils ne sont pas vides, les fichiers web (/var/www, /srv, racines déclarées dans nginx, Apache ou Caddy), les applications de /opt, PostgreSQL et MySQL/MariaDB (locaux ou dans Docker, en exports cohérents), les volumes Docker (à chaud, ou copiés avec leurs conteneurs en pause quelques secondes : Un volume Docker). Exclus par défaut : **/node_modules, **/.cache, /var/cache, /var/lib/docker/overlay2, /root/.npm, /root/go/pkg, et restic lui-même. Des préréglages facultatifs (logs, build, trash, disk-images, archives) en excluent davantage : voir Taille et exclusions.

Débit, CPU et priorité

Une sauvegarde lit vos fichiers, les compresse et les chiffre, puis envoie au stockage ce qui a changé. Par défaut elle tourne en priorité basse (nice 10 et classe disque idle), pour que votre site passe d’abord, sans limite de débit d’envoi ni de cœurs. Pour en garder davantage pour votre site :

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

Les mêmes options marchent avec neverwiped install, pour que la première sauvegarde soit déjà limitée. Elles sont enregistrées dans /etc/neverwiped/config.json, conservées quand vous relancez install, et affichées par neverwiped status. Elles s’appliquent à chaque sauvegarde, planifiée ou manuelle, et au nettoyage des anciennes sauvegardes. **Les restaurations et neverwiped list ne sont jamais limitées.**

Bon à savoir :

• La première sauvegarde envoie tout. Avec une limite d’envoi, l’installation affiche le temps maximal d’envoi du plan (moins après compression et déduplication). Une sauvegarde lancée par le minuteur systemd est arrêtée au bout de 12 heures : si la première demande plus, lancez neverwiped limits --limit-upload off, puis neverwiped backup now, et remettez la limite une fois celle-ci terminée. Les suivantes n’envoient que les changements.
• Exports des bases : la priorité basse s’applique à l’outil d’export (pg_dumpall, mysqldump), pas au travail du serveur de base de données lui-même. Pour une base dans Docker, l’export tourne dans le conteneur, à la priorité du conteneur.
• Les volumes Docker copiés en pause sont toujours copiés en priorité normale, pour que leurs conteneurs repartent au plus tôt.
• La classe disque (ionice -c 3) n’agit qu’avec un ordonnanceur de disque qui la prend en compte (BFQ, et mq-deadline sur les noyaux récents) ; sur beaucoup de disques virtuels (none) elle ne change rien, et ce sont le niveau nice et les limites ci-dessus qui comptent.
• Les anciens agents avaient Nice=10 et IOSchedulingClass=idle dans neverwiped-backup.service. L’agent fixe désormais la priorité lui-même ; l’unité est réécrite à la sauvegarde suivante ou au prochain changement par neverwiped limits.

Mettre à jour l’agent

neverwiped update --check     # version installée, épinglage, ce qui est disponible
neverwiped update             # l’installe, après confirmation
neverwiped update --rollback  # remet la version précédente (sans réseau)

Une mise à jour n’installe qu’une version signée. NeverWiped signe la liste des versions avec une clé conservée hors ligne, et l’agent porte la clé publique correspondante : la plateforme qui sert les fichiers ne peut pas signer, donc une liste ou un binaire modifié est refusé. L’agent refuse aussi une liste expirée ou plus ancienne qu’une liste déjà acceptée, vérifie l’empreinte SHA-256 et la taille du binaire, et le lance une fois avant qu’il remplace l’actuel, gardé dans /var/lib/neverwiped/bin/neverwiped.previous. Si une étape échoue, rien ne change. Configuration, clés, dépôt et plan ne sont pas touchés.

• Épinglez une version (--pin 0.3.1), une branche qui ne reçoit que des corrections (--pin 0.3), ou suivez la dernière (--pin none). --rollback épingle la version qu’il remet.
• La mise à jour automatique est coupée par défaut. neverwiped update --auto on laisse la sauvegarde de nuit installer ce que l’épinglage permet, au plus une fois par jour, après la sauvegarde ; une mise à jour ratée ne fait jamais échouer la sauvegarde.
• Une version retirée n’est jamais installée, et un serveur qui la fait tourner revient à la dernière bonne version de sa branche.
• Vérifiez un binaire vous-même : https://neverwiped.com/downloads/releases/releases.json donne la taille et l’empreinte SHA-256 de chaque version, et sha256sum /usr/local/bin/neverwiped doit afficher l’une d’elles.

Toutes les options : référence des commandes.

Désinstaller

neverwiped uninstall --yes

Dans l’ordre, la commande :

1. refuse tant qu’une sauvegarde, une restauration ou une vérification tourne (attendez, puis relancez-la), et relance tout conteneur Docker qu’une exécution interrompue a laissé en pause. Si l’un d’eux ne peut pas être relancé, elle s’arrête sans rien retirer ;
2. retire la planification (minuteur systemd ou ligne cron) ;
3. prévient la plateforme : le serveur passe à « agent désinstallé » et sa clé est révoquée. Le titulaire du compte reçoit un e-mail ;
4. efface /var/lib/neverwiped (état, restic, l’agent précédent gardé pour update --rollback), /var/cache/neverwiped, /etc/neverwiped et /usr/local/bin/neverwiped, et affiche chaque chemin retiré ou gardé. Si un chemin ne peut pas être retiré, elle l’indique, garde le binaire pour que vous puissiez la relancer, et se termine en erreur.

Le journal /var/log/neverwiped.log est conservé ; --remove-log l’efface aussi. Rien d’autre n’est touché sur le serveur.

Vos sauvegardes : conservées ou supprimées, au choix

Sans --yes, la commande vous demande votre choix.

Pourquoi le serveur ne peut pas les supprimer lui-même : les clés enregistrées sur le serveur peuvent ajouter des sauvegardes, pas en supprimer à la demande. La seule suppression à laquelle elles participent est le nettoyage hebdomadaire selon votre conservation, dans une fenêtre d’une heure (nettoyage). C’est ce qui protège vos sauvegardes si quelqu’un prend la main sur le serveur. La suppression se termine donc toujours par une confirmation dans l’espace client, connecté. Vous pouvez aussi vous passer de la commande et supprimer le serveur directement là.

Avant de désinstaller sans --keep-config, vérifiez que la clé de récupération que vous gardez ouvre toujours ces sauvegardes :

neverwiped recovery-key check

Une fois /etc/neverwiped effacé, seule cette clé peut les lire.

Garder la configuration

Pour garder la configuration et la clé locale, afin qu’une réinstallation reprenne là où vous en étiez :

neverwiped uninstall --yes --keep-config

Sur une machine copiée (VM clonée, /etc/neverwiped recopié), la désinstallation ne retire que la copie locale. Elle ne prévient pas la plateforme et ne demande aucune suppression, car les sauvegardes appartiennent au serveur d’origine.