Chiffrer les sauvegardes d'un serveur Linux avant de les envoyer hors site

Une sauvegarde complète, testée et envoyée chaque nuit vers un stockage distant peut encore trahir son propriétaire. Tant qu'elle reste en clair, le fichier est lisible par l'exploitant du stockage, par toute personne qui met la main sur la clé d'API utilisée par le script d'envoi, et par quiconque retrouve un jeton oublié dans un dépôt Git. Le chiffrement ne remplace pas une stratégie de sauvegarde, il ferme la dernière porte : celle du stockage que vous ne contrôlez pas.

Ce tutoriel couvre trois approches complémentaires, du plus simple au plus intégré : une archive de sauvegarde chiffrée avec age, un chiffrement symétrique avec GPG pour les environnements les plus sobres, un dépôt de sauvegarde chiffré de bout en bout avec restic, et enfin une couche de chiffrement posée sur un stockage distant existant avec rclone crypt. Vous verrez ensuite où conserver la clé, où poser la copie chiffrée, comment envoyer l'archive avec rsync et comment prouver qu'une restauration reste possible.

Pourquoi chiffrer une sauvegarde avant de l'envoyer hors site

La règle classique des trois copies, dont une hors site, protège contre la panne matérielle, la suppression accidentelle et l'incendie. Elle ne protège pas contre la lecture : une archive de sauvegarde non chiffrée déposée dans un compartiment objet, sur un serveur de stockage mutualisé ou sur un espace FTP reste un fichier en clair, disponible pour l'opérateur de ce stockage comme pour n'importe quel accès compromis à votre compte.

Les fuites réelles suivent presque toujours le même chemin : une clé d'API de stockage laissée dans un script lisible par tous, un jeton présent dans l'historique d'un dépôt Git, un ancien compte utilisateur encore actif, un partage de fichiers trop ouvert. Le chiffrement côté client change la donne : même si l'accès au stockage distant est compromis, l'attaquant récupère un flux illisible sans la clé privée, qui n'a jamais quitté vos machines.

Un second argument, plus administratif, concerne les données personnelles et les données clients présentes dans une sauvegarde : comptes joueurs, adresses e-mail, journaux d'authentification, fichiers de configuration avec identifiants, bases de données de serveur de jeu. Chiffrer avant l'envoi réduit la surface de risque en cas d'incident chez le tiers qui héberge la copie, sans rien changer à vos obligations de conservation.

Le modèle de menace : qui peut lire vos sauvegardes

Avant de choisir un outil, listez ce contre quoi vous voulez vous protéger. Quatre situations reviennent :

• Le stockage distant lui-même : un espace de sauvegarde chez un prestataire, un compartiment objet, un serveur de fichiers. Le chiffrement côté client est la seule réponse possible.
• Un accès volé à votre infrastructure : clé d'API, jeton, mot de passe de compte de stockage. Là encore, un contenu chiffré reste inutilisable sans la clé privée de déchiffrement.
• Une suppression ou un chiffrement malveillant : un rançongiciel qui parcourt vos montages atteint aussi les dépôts de sauvegarde montés. Une copie chiffrée hors site, montée en lecture seule ou déposée par un canal unidirectionnel, résiste mieux.
• Un transfert en clair : copier la sauvegarde par un canal non chiffré expose le contenu pendant le transport. Le chiffrement de l'archive règle ce point, mais vous devez aussi vérifier le canal d'envoi.

En revanche, si votre objectif est uniquement de protéger la sauvegarde contre une panne matérielle, le chiffrement n'apporte rien : vous payez une complexité de gestion de clé qui ne servira à rien. Décidez du niveau de protection avant de choisir l'outil.

Ce qu'il faut réellement sauvegarder sur un serveur Linux

Le chiffrement s'applique à une archive, encore faut-il que cette archive contienne ce qui compte. Sur un serveur Linux classique, la liste est courte mais elle oublie souvent deux ou trois éléments :

• Les données applicatives : racines web avec les scripts PHP, fichiers statiques, médias. Sur un serveur web, il s'agit par exemple de /var/www, avec un serveur comme Apache ou Nginx devant.
• Les bases de données : une base MySQL ou MariaDB ne se sauvegarde pas proprement en copiant ses fichiers sous charge. On passe par un export logique, par exemple mysqldump --single-transaction, avant de chiffrer le résultat.
• La configuration système : /etc, les unités systemd, les règles de pare-feu, les comptes et les tâches planifiées. C'est souvent la partie la plus longue à reconstruire à la main.
• Les certificats TLS : les certificats et les clés privées associées, notamment ceux renouvelés automatiquement, évitent de tout redemander après une reconstruction. Ils ne doivent jamais être stockés en clair dans la sauvegarde.
• Les données métier : pour un panel de serveurs de jeu, l'ensemble des serveurs, leurs volumes et leurs configurations, par exemple sous /var/lib/pterodactyl.
• Les fichiers de déploiement : scripts de sauvegarde, fichiers d'environnement, listes de paquets installés.

Un export de base de données se chiffre exactement comme une archive : le flux sort du serveur déjà chiffré, ce qui évite de laisser un dump MySQL en clair sur le disque, même quelques minutes.

sudo mysqldump --single-transaction --all-databases \
  | age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p \
    -o dump-mysql.sql.age

Chiffrer une archive de sauvegarde avec age

age est un outil de chiffrement de fichiers conçu pour être simple : de petites clés explicites, aucune option de configuration, et une composition à la manière des outils Unix. Ses commandes sont donc courtes, ce qui compte lorsqu'on doit les relire six mois plus tard dans un script de sauvegarde.

On commence par créer une paire de clés. La clé privée, appelée identité, est le seul élément à protéger ; la clé publique peut être diffusée sans précaution particulière.

age-keygen -o /root/backup-identity.txt
# Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

La sauvegarde elle-même tient en un pipeline : une archive en flux, un chiffrement, un fichier de sortie. Le destinataire est désigné par sa clé publique, ce qui permet de chiffrer une sauvegarde sans jamais manipuler la clé privée sur la machine sauvegardée.

tar -C /var/www -czf - mon-site \
  | age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p \
    -o sauvegarde-site.tar.gz.age

La restauration reprend le même flux dans l'autre sens, avec l'identité cette fois :

age --decrypt -i /root/backup-identity.txt sauvegarde-site.tar.gz.age \
  | tar -C /srv/restauration -xzf -

Quelques options utiles pour un usage opérationnel :

• -R fichier permet d'indiquer plusieurs destinataires listés un par ligne dans un fichier, pratique pour que deux personnes puissent déchiffrer la même archive, par exemple vous et un collègue.
• -a produit une sortie armée, en texte, utile si la sauvegarde doit passer par un canal qui ne transporte pas de binaire.
• -p chiffre avec une phrase de passe plutôt qu'avec une clé publique : pratique pour une archive ponctuelle, plus risqué pour une sauvegarde automatique, car la phrase de passe doit alors exister quelque part sur la machine.
• Une clé publique SSH reconnue, de type ssh-ed25519 ou ssh-rsa, peut servir de destinataire, ce qui évite de créer une paire supplémentaire. Attention toutefois : l'agent SSH n'est pas utilisé pour le déchiffrement.
• age-inspect affiche les métadonnées d'un fichier chiffré sans le déchiffrer, utile pour vérifier vers quel destinataire une archive a effectivement été chiffrée.

Côté installation, age est disponible dans la plupart des dépôts : paquet age sur Debian 12 et plus, Ubuntu 22.04 et plus, Fedora 33 et plus, Arch, Alpine ou openSUSE. Pour la partie serveur, les VPS Linux et les serveurs dédiés que nous proposons utilisent ces distributions, la mise en place se limite donc à un paquet à installer.

Variante GPG : chiffrement symétrique avec phrase de passe

GPG reste présent partout et sait chiffrer un document avec une simple phrase de passe, sans aucune paire de clés. C'est la solution la plus courte quand vous êtes seul à devoir relire la sauvegarde et que vous voulez éviter toute gestion de clé publique.

gpg --symmetric --cipher-algo AES256 --output dump.sql.gpg dump.sql
gpg --decrypt --output dump.sql dump.sql.gpg

Le principe est celui du chiffrement à clé symétrique : la clé qui alimente le chiffrement est dérivée de la phrase de passe fournie au moment du chiffrement. Ce mode est adapté quand la phrase de passe n'a pas besoin d'être communiquée à un tiers. Il existe aussi le mode à clé publique, où chaque destinataire est désigné par son identifiant :

gpg --output dump.sql.gpg --encrypt --recipient vous@exemple.fr dump.sql

Point important pour une sauvegarde automatique : ne mettez jamais la phrase de passe directement dans la ligne de commande du planificateur. Elle apparaîtrait dans la liste des processus pendant l'exécution. Placez-la dans un fichier de mot de passe lisible uniquement par root, et vérifiez que le script qui l'appelle l'est aussi.

La solution intégrée : un dépôt de sauvegarde chiffré avec restic

Si vous partez de zéro, un outil de sauvegarde dédié fait le travail de chiffrement à votre place, et il le fait côté client : les données sont chiffrées avant de quitter la machine. restic fonctionne ainsi, avec des dépôts qui contiennent les données, les métadonnées et les clés de chiffrement, accessibles uniquement avec un mot de passe de dépôt.

export RESTIC_REPOSITORY="sftp:backup@stockage.exemple:/srv/restic-repo"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo restic init
sudo restic backup /var/lib/pterodactyl /etc
sudo restic snapshots
sudo restic restore latest --target /srv/restauration

Plusieurs détails méritent d'être connus avant de s'engager :

• Le mot de passe du dépôt peut être fourni par variable d'environnement, par fichier avec l'option --password-file ou par une commande appelée à la demande avec --password-command. Pour une tâche planifiée, le fichier de mot de passe aux droits restrictifs reste le plus simple à auditer.
• Un dépôt peut contenir plusieurs clés d'accès, ce qui permet d'en ajouter une pour une seconde personne sans réécrire le dépôt.
• Le mot de passe perdu signifie données perdues : la documentation de restic l'indique explicitement, aucun mécanisme de récupération n'existe. Cette phrase doit figurer dans votre procédure interne, pas seulement dans la documentation de l'outil.
• La version 2 du format de dépôt, par défaut depuis restic 0.14, apporte la compression. Depuis la version stable actuelle, c'est le choix par défaut.
• Un dépôt posé sur un partage CIFS ou SMB n'est pas recommandé par la documentation, en raison de problèmes de compatibilité sur d'anciens noyaux Linux.

L'intérêt de cette approche est qu'elle gère aussi la rétention et les instantanés : vous gardez un historique de sauvegardes chiffrées, avec la possibilité de restaurer une date précise, sans script maison pour la rotation.

Chiffrer un dépôt existant avec rclone crypt

Si votre sauvegarde existe déjà en clair et part vers un stockage distant, vous pouvez insérer une couche de chiffrement sans changer votre méthode. Un dépôt rclone de type crypt n'accède jamais directement au stockage : il encapsule un autre dépôt, qui lui parle au stockage. Le résultat est un chiffrement côté client, transparent pour vos commandes habituelles, avec des données stockées chiffrées au repos.

rclone copy /var/backups secret:sauvegardes
rclone cryptdecode secret: --reverse "sauvegardes/dump.sql"

Quelques caractéristiques à garder en tête :

• Le contenu est chiffré avec NaCl SecretBox, construit sur le chiffrement XSalsa20 et l'authentification Poly1305. L'intégrité et la confidentialité sont donc assurées par le même mécanisme.
• Les noms de fichiers et de répertoires sont chiffrés par défaut, ce qui évite de divulguer la structure de vos sauvegardes. Ce chiffrement des noms est déterministe et utilise AES avec une clé de 256 bits.
• La clé est dérivée de deux secrets : un mot de passe et, en option, un sel. Le sel joue le rôle d'un second mot de passe et doit être mémorisé, car rclone ne stocke aucune information sur le dépôt distant.
• Le mot de passe est conservé dans le fichier de configuration, sous une forme légèrement obscurcie. Si la machine n'est pas sûre, activez le chiffrement de configuration.
• Un point de vigilance : si vous accédez au dépôt sous-jacent directement, vous contournez le chiffrement. Réservez donc un chemin dédié au contenu chiffré et n'y accédez que par le dépôt crypt.

Symétrique, asymétrique, cryptage : le vocabulaire utile

Les outils ci-dessus emploient deux familles de chiffrement, et les confondre mène à des choix discutables :

• Le chiffrement symétrique utilise une seule clé de chiffrement, dérivée d'une phrase de passe ou d'un mot de passe. C'est le mode de GPG en option symétrique, celui de rclone crypt, et celui d'age avec -p. Il est simple et rapide, mais la clé doit être disponible partout où l'on déchiffre.
• Le chiffrement asymétrique repose sur une paire de clés : une clé publique pour chiffrer, une clé privée pour déchiffrer. C'est le mode d'age avec -r et celui de GPG avec un destinataire. Il est plus pratique pour une sauvegarde automatique, car la machine qui produit l'archive n'a besoin que de la clé publique.
• L'algorithme désigne la méthode mathématique utilisée, par exemple AES ou ChaCha20-Poly1305. Vous n'avez pas à le choisir dans la plupart des cas, les outils récents utilisent des valeurs sûres par défaut.

Un mot sur le vocabulaire : beaucoup d'articles parlent de fichiers cryptés, de cryptage ou de chiffrage. En français technique, on parle de chiffrement, d'une archive chiffrée, et l'action de retrouver le contenu s'appelle déchiffrer ou décrypter. Ce sont les mêmes outils dans les deux cas, seule la formulation change.

Où poser la copie chiffrée

Une fois l'archive chiffrée, la destination n'a plus d'importance du point de vue de la confidentialité, mais elle en a beaucoup du point de vue de la disponibilité et de la vitesse de restauration. Les options courantes :

• Un disque dur interne ou une partition dédiée sur la machine, utile pour les restaurations rapides, mais insuffisant seul : il disparaît avec le serveur.
• Un disque dur externe ou un périphérique amovible, comme une clé USB, que l'on débranche après la copie. C'est la copie hors ligne la plus simple, et la plus efficace contre un rançongiciel, puisqu'elle n'est pas montée en permanence.
• Un NAS sur votre réseau local, accessible par NFS ou SMB, pratique pour plusieurs machines et pour les sauvegardes automatisées. Attention : monter le NAS sur le serveur exposé recrée le risque de chiffrement malveillant, préférez une écriture en lecture seule depuis le serveur.
• Une grappe RAID ou un volume redondant chez vous : cela protège de la panne d'un disque dur, pas d'une suppression, d'un vol ou d'un incendie. Une grappe RAID n'est pas une sauvegarde.
• Un espace cloud chez un hébergeur, accessible par SSH, rsync ou une API objet. C'est la copie hors site la plus simple à automatiser, et celle qui justifie le plus le chiffrement côté client.

Le bon réflexe reste la combinaison : une copie locale rapide pour restaurer, une copie distante chiffrée pour survivre à un sinistre. Sur un poste sous Windows ou sur un Mac, la logique est identique, seuls les outils changent.

Où garder la clé de déchiffrement

C'est le point où la plupart des stratégies de sauvegarde chiffrée échouent. Une clé stockée uniquement sur le serveur sauvegardé disparaîtra avec lui, et un rançongiciel qui parcourt le disque la trouvera en même temps que les données. Trois règles suffisent :

• Jamais une seule copie de la clé, et jamais uniquement sur la machine sauvegardée. Une copie hors ligne, dans un gestionnaire de mots de passe ou sur un support séparé, reste accessible le jour où le serveur ne démarre plus.
• Une clé privée peut elle-même être protégée par une phrase de passe. C'est particulièrement utile quand le fichier d'identité doit être stocké ailleurs que sur la machine d'origine.
• La procédure doit être écrite pour quelqu'un d'autre que vous. Où se trouve la clé, comment on restaure, qui y a accès : si cette information n'existe que dans votre mémoire, la sauvegarde chiffrée est un pari.

Si vos identités d'administration sont des clés SSH, la même discipline s'applique : une clé privée ne se balade pas, et on prépare toujours un accès de secours avant de changer une configuration. Le guide pour configurer une clé SSH sur un VPS Linux sans perdre l'accès détaille cette préparation.

Envoyer l'archive chiffrée avec rsync

Pour pousser une archive chiffrée vers un serveur distant, rsync reste l'outil le plus courant : il reprend un transfert interrompu et ne recopie que ce qui manque. La commande suivante envoie l'archive en gardant les droits et les horodatages :

sudo rsync -av --partial -e ssh /var/backups/sauvegarde-site.tar.gz.age \
  backup@stockage.exemple:/srv/sauvegardes/

Quelques précautions évitent les mauvaises surprises :

• Testez d'abord avec --dry-run : vous voyez le nom du fichier de destination et les transferts prévus avant d'écrire quoi que ce soit sur le serveur distant.
• Vérifiez le code de retour de la commande et l'empreinte de l'archive après transfert, sinon une coupure réseau laissera un fichier partiel avec un nom complet.
• Utilisez une clé SSH dédiée à la sauvegarde, limitée au strict nécessaire, plutôt que le compte administrateur du serveur de stockage.
• Ne passez pas votre mot de passe ou votre phrase de passe en argument, même avec sudo : la ligne reste visible dans la liste des processus pendant toute la durée du transfert.
• Numérotez ou datez systématiquement les archives, sinon l'écrasement silencieux d'une sauvegarde correcte par une sauvegarde partielle passera inaperçu.

Automatiser l'envoi chiffré et tester la restauration

Une sauvegarde chiffrée automatisée tient dans un script court, appelé par un minuteur systemd ou une tâche planifiée. Quatre points doivent y figurer :

• Le script de sauvegarde est lisible uniquement par son propriétaire, comme le fichier qui contient le mot de passe du dépôt ou la phrase de passe.
• Chaque étape vérifie son code de retour et interrompt la chaîne en cas d'erreur : une archive incomplète, chiffrée puis envoyée, c'est une fausse sauvegarde.
• La taille de l'archive et l'espace disponible avant l'envoi sont contrôlés, sinon une saturation de disque produira un fichier tronqué que personne ne remarquera avant le jour de la restauration.
• Une empreinte de contrôle est calculée avant l'envoi, puis vérifiée après la copie vers le stockage distant.

Consacrez ensuite un temps fixe au test de restauration, par exemple une fois par mois, sur une machine différente de celle qui a produit la sauvegarde. Une sauvegarde chiffrée jamais restaurée est une hypothèse, pas une protection. C'est exactement le même travail que pour un serveur de jeu, où l'on vérifie régulièrement que les sauvegardes se rechargent et que le serveur redémarre avec, comme le décrit la procédure de restauration d'une sauvegarde Pterodactyl.

Le monitoring compte autant que la copie. Une sauvegarde qui échoue en silence pendant trois semaines revient à ne pas avoir de sauvegarde du tout : surveillez l'espace disque de la machine source, la date du dernier dépôt réussi et la place disponible côté distant.

Chiffrer ne remplace pas la redondance

Le chiffrement protège la confidentialité, pas la disponibilité. Une archive chiffrée unique reste un point unique de défaillance : si le stockage distant devient inaccessible, vous perdez vos sauvegardes même si elles étaient parfaitement protégées. Une copie supplémentaire, sur un support ou un site différent, reste nécessaire pour couvrir les cas où le stockage principal disparaît.

Sur ce point, les contraintes de disque et de matériel comptent autant que la cryptographie : sauvegarder une base de données volumineuse chaque nuit consomme de la place chez vous comme chez le stockage distant, et la durée de rétention dépend directement de la capacité disponible. Pour des serveurs de jeu ou des bases de production, c'est souvent ce qui pousse vers une machine avec du stockage dédié. Les principes d'une stratégie de sauvegarde à haute disponibilité sur serveur dédié prolongent directement ce guide.

Les erreurs fréquentes

• Chiffrer sans jamais tester le déchiffrement. Vous ne connaissez pas votre procédure de restauration tant que vous ne l'avez pas exécutée sur une machine neuve.
• Laisser la clé privée sur la machine sauvegardée, et nulle part ailleurs. Le pire des deux mondes : exposée en cas d'intrusion, perdue en cas de panne.
• Mettre le mot de passe dans la commande planifiée. Il devient visible dans la liste des processus de la machine.
• Confondre transport et stockage. Un transfert en SSH protège le trajet, pas le fichier une fois déposé : sans chiffrement de l'archive, la donnée est en clair chez le destinataire.
• Chiffrer deux fois sans le savoir. Un dépôt de sauvegarde chiffré par l'outil, puis envoyé dans un dépôt rclone crypt, fonctionne, mais complique inutilement la restauration. Choisissez une seule couche.
• Oublier les noms de fichiers. Un contenu chiffré avec des noms lisibles révèle déjà beaucoup : noms de bases, de sites, de comptes.
• Confondre sauvegarde et redondance. Une grappe RAID ou une réplication ne remplace pas des données sauvegardées et chiffrées hors site.
• Négliger la rétention. Sans règle de rétention, le stockage distant grossit jusqu'à la saturation, et la sauvegarde échoue au pire moment.

En résumé : cinq étapes

1. Définir le niveau de protection attendu : panne matérielle, intrusion, fuite chez un tiers.
2. Choisir une seule couche de chiffrement : archive age, symétrique GPG, dépôt restic ou dépôt rclone crypt.
3. Conserver la clé hors de la machine sauvegardée, avec une procédure écrite et un accès de secours.
4. Automatiser l'envoi avec rsync, vérifier les codes de retour, l'espace disque et l'empreinte des archives envoyées.
5. Tester une restauration complète sur une autre machine, à intervalle fixe.

Un serveur Linux hébergé chez un prestataire, un VPS ou un serveur dédié, se sauvegarde avec les mêmes outils : ce qui change, c'est la discipline autour des clés et des tests. La différence entre une sauvegarde qui protège et une sauvegarde décorative tient rarement à l'outil choisi, elle tient à la clé conservée au bon endroit et à la restauration testée pour de vrai.