Héberger Backrest : sauvegardes chiffrées sans ligne de commande

La sauvegarde d'un VPS est la tâche que tout le monde repousse, parce qu'elle ne rapporte rien tant qu'elle ne sauve pas tout. Les instantanés proposés par les hébergeurs sont pratiques mais copient la machine entière chez le même fournisseur, au même endroit : ils protègent d'une erreur humaine, pas de la perte du compte ni d'un incident sur l'infrastructure. Et un instantané ne permet pas de récupérer un seul fichier écrasé ce matin.

La réponse open source de référence s'appelle restic : chiffrement de bout en bout, déduplication, sauvegardes incrémentales, et une compatibilité avec pratiquement tous les stockages objets. Son seul défaut est ergonomique — c'est un outil en ligne de commande. En pratique, l'adopter signifie écrire ses propres scripts, ses entrées cron, sa politique de rétention, sa purge périodique, sa supervision. Beaucoup s'arrêtent au premier script, et personne ne remarque quand il cesse de tourner.

Backrest est léger, mais quelques conditions matérielles et logicielles sont à vérifier avant de déployer. Côté serveur, 512 Mo de RAM est le minimum fonctionnel — suffisant pour une machine dédiée à la sauvegarde ; si le VPS héberge d'autres services actifs, 1 Go est plus confortable. La version de restic embarquée dans l'image Docker de Backrest est récente par construction, mais si vous gérez restic indépendamment, assurez-vous d'utiliser restic ≥ 0.16.0 : les versions antérieures ne gèrent pas certaines politiques de rétention JSON et peuvent ignorer silencieusement les règles --keep-*.

Backrest expose son interface sur le port 9898 (TCP). Ce port doit être ouvert dans votre pare-feu côté VPS (ufw allow 9898/tcp ou l'équivalent), mais ne doit pas être exposé publiquement sans authentification : au premier démarrage, protégez-le en filtrant par IP source le temps de créer votre compte administrateur. Enfin, le répertoire de données Backrest — /var/lib/backrest dans la recette ServOrbit — requiert l'accès en écriture pour le processus conteneurisé : un volume Docker mal monté en lecture seule fait échouer silencieusement la sauvegarde de la configuration.

Backrest est un binaire Go unique qui embarque restic. Il tourne dans un seul conteneur, sans base de données ni cache externe : sa configuration vit dans un fichier JSON et son état dans un répertoire de données. C'est l'inverse des piles de sauvegarde d'entreprise, et c'est ce qui le rend adapté à un VPS modeste.

Le point important est le sens du chiffrement. restic chiffre chaque instantané localement, sur votre serveur, avant le moindre octet transmis : la destination ne reçoit que des blocs opaques. Le mot de passe du dépôt est la clé, et vous seul le détenez — ce qui signifie que le stockage peut être un fournisseur bon marché et non approuvé sans que cela pose un problème de confidentialité, mais aussi que perdre ce mot de passe rend les sauvegardes définitivement illisibles. C'est le compromis explicite de tout chiffrement côté client.

Dans la recette ServOrbit, les répertoires /home, /root et /etc de l'hôte sont montés en lecture seule sous /host dans le conteneur. Backrest peut donc sauvegarder les données et la configuration du serveur sans jamais pouvoir les modifier.

La restauration dans Backrest se fait en deux niveaux selon la granularité souhaitée.

Depuis l'interface web : ouvrez l'onglet « Snapshots » de votre plan, sélectionnez un instantané par date, naviguez dans l'arborescence et cliquez sur « Restore » pour un fichier ou un dossier. Backrest déclenche une restauration vers le chemin de destination que vous spécifiez — par exemple /tmp/restore-test/ pour ne pas écraser le fichier en production.

Depuis la ligne de commande restic (utile pour les restaurations volumineuses ou scriptées) : entrez dans le conteneur avec docker exec -it backrest sh, puis lancez restic -r <votre-repo-url> restore latest --target /tmp/restore/. Pour restaurer un chemin spécifique plutôt que tout l'instantané, ajoutez --include /host/home/user/projet — restic ne restaure que ce sous-arbre. Après une restauration, validez l'intégrité de l'instantané source avec restic check --read-data-subset=5% : cette option vérifie un échantillon aléatoire des blobs de données (pas seulement les métadonnées), sans avoir à tout télécharger.

Échec silencieux du cron. Si le plan ne se déclenche jamais malgré une planification correcte, vérifiez que le conteneur Backrest est bien démarré (docker ps) et que son horloge interne est synchronisée avec l'hôte (passez --env TZ=Europe/Paris ou l'équivalent de votre timezone à la création du conteneur). Un décalage d'horloge peut faire passer le déclenchement sans journalisation d'erreur.

Erreur wrong password or no key found. Cette erreur survient quand le mot de passe saisi ne correspond pas à la clé stockée dans le dépôt. Elle peut aussi indiquer que le dépôt a été initialisé une première fois avec un mot de passe différent — chaque dépôt restic ne peut avoir qu'un seul jeu de clés actif. Vérifiez que vous n'avez pas un espace ou un caractère invisible dans le mot de passe copié-collé. Si vous avez perdu le mot de passe, le dépôt est définitivement illisible — c'est la contrepartie du chiffrement côté client.

Espace disque insuffisant sur le backend. Backrest affiche une erreur repository is full ou similaire quand le quota du bucket est atteint. Activez le prune automatique dans votre plan pour éviter l'accumulation des anciens instantanés au-delà de la politique de rétention. Sur Backblaze B2, vous pouvez aussi configurer une règle de cycle de vie sur le bucket pour supprimer automatiquement les objets marqués par restic comme supprimés (restic forget ne supprime les blobs qu'après un prune).

Backrest ne répond plus sur le port 9898. Vérifiez d'abord que le conteneur tourne (docker ps), puis que le port est bien lié (ss -tlnp | grep 9898). Si le conteneur est en état restarting, consultez les logs avec docker logs backrest --tail 50 — une corruption du fichier de configuration JSON est la cause la plus fréquente après une interruption brutale.