Sauvegarder un serveur Linux personnel : rsync, restic, BorgBackup (guide 2026)

1. Pourquoi un serveur Linux perso n'est pas un NAS

Un Synology ou un QNAP livre Hyper Backup ou HBS 3 préinstallés, avec un assistant graphique qui configure la tâche en quelques clics. Un VPS Debian ou Ubuntu, ou un Raspberry Pi qui fait tourner un serveur web personnel, n'a rien de tel. La sauvegarde y est un choix actif, pas un réflexe guidé par l'interface — ce qui explique pourquoi tant de home labs et de petits VPS personnels n'ont, en pratique, aucune sauvegarde du tout jusqu'au jour où un disque lâche ou une mauvaise commande rm -rf efface la mauvaise arborescence.

La bonne nouvelle : les outils disponibles sur Linux pour cet usage sont matures, gratuits et scriptables. rsync existe depuis 1996 et reste l'un des outils les plus utilisés du monde Linux pour les transferts différentiels. Restic et BorgBackup, plus récents, ajoutent chiffrement, déduplication et versionnement — ce que rsync seul ne fait pas. Le choix entre ces outils dépend moins d'une préférence personnelle que du profil réel de votre serveur : volume de données, fréquence de changement, destination de stockage visée et niveau de menace (un VPS exposé sur Internet n'a pas le même profil de risque qu'un Raspberry Pi isolé derrière votre box).

Si vous cherchez d'abord à comprendre les principes généraux de la sauvegarde avant d'entrer dans les commandes, notre guide complet de la règle 3-2-1 pose le cadre ; ce dossier se concentre spécifiquement sur son application à un serveur Linux administré en ligne de commande.

2. rsync : la base, avec ses limites

rsync transfère uniquement les blocs de données modifiés entre la source et la destination, ce qui en fait un outil rapide même sur des arborescences volumineuses déjà largement synchronisées. La commande de base pour sauvegarder un répertoire vers un stockage distant monté ou accessible en SSH ressemble à ceci :

C'est précisément cette dernière remarque qui borne l'usage de rsync seul comme outil de sauvegarde. Sans option de versionnement (comme --link-dest pour créer des snapshots incrémentaux via des hardlinks), une suppression accidentelle sur le serveur source se propage à l'identique sur la destination au prochain passage de la tâche cron. rsync n'a par ailleurs aucun chiffrement natif : les données transitent en clair sur le réseau (sauf tunnel SSH, qui chiffre le transport mais pas le stockage final) et restent en clair sur le disque de destination. Pour un serveur personnel hébergeant des données sensibles — base de données d'un site, configurations avec secrets, documents personnels — ce n'est pas suffisant en soi.

rsync garde toutefois un usage légitime et efficace : la réplication rapide vers un second serveur local ou un stockage intermédiaire avant qu'un outil versionné comme restic ne traite ces données pour la copie de sauvegarde réelle. C'est un outil de transport, pas un outil de protection complet.

3. restic vs BorgBackup : lequel choisir

Restic et BorgBackup répondent tous deux au manque de rsync : chiffrement systématique, déduplication par blocs, versionnement avec possibilité de revenir à n'importe quel instantané antérieur, et vérification d'intégrité intégrée. Leurs différences pratiques déterminent lequel convient le mieux à votre configuration.

En pratique, si vous partez de zéro sans historique de sauvegarde existant, restic est le choix le plus simple à démarrer : la configuration est plus courte, les backends cloud sont directement supportés sans passer par un serveur SSH intermédiaire, et la communauté autour de l'outil s'est nettement étoffée ces dernières années. BorgBackup reste préférable si vous administrez déjà un serveur SSH dédié au stockage de sauvegardes (un second VPS bon marché, par exemple) et que vous voulez la meilleure efficacité de déduplication sur un historique de plusieurs mois voire années — un cas fréquent chez les utilisateurs qui gèrent plusieurs machines depuis un seul dépôt centralisé.

Un détail technique mérite d'être connu avant de choisir : restic (en version 0.18, la plus répandue en 2026) ne gère pas encore nativement l'Object Lock S3 de façon transparente, car l'outil a besoin de pouvoir supprimer ses propres verrous temporaires en fonctionnement normal. Cela ne bloque pas l'usage de restic avec du stockage S3 immuable, mais impose une configuration spécifique détaillée plus bas plutôt qu'une activation en un clic.

4. Configurer restic avec cron, pas à pas

Voici une configuration restic complète et automatisée, adaptée à un VPS ou un Raspberry Pi personnel, avec Backblaze B2 comme destination — un choix pertinent pour un particulier grâce à des tarifs prévisibles et, lorsque le trafic sortant passe par le réseau Cloudflare, une facturation d'egress réduite voire nulle selon les accords en vigueur au moment de la configuration.

1. Installer restic — sur Debian/Ubuntu récent : sudo apt install restic, ou téléchargement du binaire officiel pour une version plus récente que celle du dépôt distribution.
2. Créer le dépôt chiffré — restic -r b2:mon-bucket:chemin init après avoir exporté les variables B2_ACCOUNT_ID et B2_ACCOUNT_KEY. restic demande un mot de passe de chiffrement à conserver hors du serveur sauvegardé — dans un gestionnaire de mots de passe séparé, jamais dans le même dossier que les sauvegardes.
3. Premier instantané — restic -r b2:mon-bucket:chemin backup /etc /home /var/www --exclude-file=/etc/restic/exclude.txt, en excluant les caches et fichiers temporaires volumineux qui n'ont pas besoin d'être sauvegardés.
4. Script cron avec purge des anciennes versions — un script quotidien qui lance le backup puis applique une politique de rétention (restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 6 --prune) pour éviter une croissance illimitée du dépôt.
5. Vérification d'intégrité planifiée — restic check une fois par semaine dans un second job cron, pour détecter une corruption du dépôt avant qu'elle ne devienne un problème au moment de la restauration.

Le script cron typique ressemble à ceci, placé dans /etc/cron.daily/ ou géré par un timer systemd pour un contrôle plus fin des logs et des tentatives de retry :

Pour une base de données (MySQL, PostgreSQL) hébergée sur le même serveur, ne sauvegardez jamais les fichiers de données bruts pendant que le service tourne : la cohérence n'est pas garantie. Générez d'abord un dump (mysqldump ou pg_dump) vers un fichier, puis laissez restic sauvegarder ce fichier de dump — une pratique standard qui évite les incohérences de restauration observées sur des sauvegardes de fichiers bruts de bases actives.

5. rclone : répliquer vers un second fournisseur

rclone n'est pas un concurrent direct de restic ou BorgBackup : c'est un outil de synchronisation de fichiers vers plus de 70 fournisseurs cloud (S3, Wasabi, Cloudflare R2, Backblaze B2, Google Drive, et bien d'autres), avec un remote crypt qui chiffre côté client — le fournisseur ne voit ni le contenu ni même les noms de fichiers en clair. Son usage le plus pertinent dans une stratégie serveur Linux est la réplication d'un dépôt restic déjà constitué vers un second fournisseur, pour respecter la règle des deux supports différents sans dupliquer manuellement la configuration de sauvegarde elle-même.

Concrètement : restic sauvegarde en continu vers Backblaze B2 (destination principale), puis une tâche rclone hebdomadaire synchronise le contenu du bucket B2 vers un second bucket chez un fournisseur différent (Wasabi ou un stockage S3-compatible chez un hébergeur français comme OVHcloud). Si le compte B2 est compromis ou suspendu, la copie chez le second fournisseur reste intacte et restaurable.

6. Se protéger d'un serveur compromis : append-only et Object Lock

Le scénario de menace propre à un serveur Linux personnel diffère de celui d'un NAS domestique : un VPS exposé sur Internet peut être directement compromis (faille applicative, identifiants volés, mauvaise configuration SSH), et si les identifiants de sauvegarde sont stockés sur ce même serveur, un attaquant qui obtient un accès root peut aussi supprimer ou corrompre les sauvegardes avant de chiffrer le reste. C'est le point faible de toute sauvegarde où le serveur source dispose des mêmes droits d'écriture ET de suppression sur la destination.

Deux approches corrigent ce point faible. La première, pour BorgBackup, consiste à utiliser un dépôt SSH en mode append-only (borg serve --append-only côté serveur de destination) : le client peut ajouter de nouvelles données mais ne peut ni supprimer ni modifier ce qui existe déjà, même avec les identifiants du client compromis. C'est la protection native la plus robuste de Borg, largement documentée comme référence pour ce cas d'usage.

La seconde, pour restic vers S3 ou compatible, passe soit par un rest-server restic configuré en --append-only, soit par l'Object Lock S3 en mode COMPLIANCE — à distinguer du mode GOVERNANCE, qui reste contournable par un compte disposant de permissions spéciales, alors que le mode COMPLIANCE n'a aucun mécanisme de contournement, y compris pour l'administrateur du compte. Activer l'Object Lock sur un bucket S3 se fait en quelques minutes depuis la console du fournisseur, mais doit être décidé à la création du bucket : il ne peut pas toujours être ajouté après coup selon les fournisseurs.

Pour approfondir la logique générale de protection contre le chiffrement malveillant des sauvegardes, au-delà du cas spécifique d'un serveur Linux, notre guide de protection contre les ransomwares détaille les principes applicables à tout type de support.

7. Tester la restauration avant d'en avoir besoin

Une sauvegarde jamais restaurée n'est qu'une hypothèse. Sur un serveur en ligne de commande, ce test est encore plus facilement négligé que sur un NAS avec interface graphique, car la commande de restauration n'est tapée qu'en situation de crise réelle — le pire moment pour découvrir un mot de passe de chiffrement perdu ou une erreur de syntaxe dans une commande jamais exécutée avant.

Pour restic, la commande de restauration vers un dossier temporaire est simple à tester régulièrement :

Pour un serveur qui héberge un service critique (site web, application), le test le plus rigoureux consiste à provisionner une machine virtuelle jetable, y restaurer l'intégralité de la sauvegarde, et vérifier que le service redémarre correctement avec les données restaurées — pas seulement que les fichiers existent, mais que l'application fonctionne réellement dessus.

8. Une stratégie 3-2-1 complète pour un serveur perso

En rassemblant les éléments précédents, une configuration sérieuse pour un serveur Linux personnel ressemble à ceci : restic (ou BorgBackup selon votre profil) comme outil principal, exécuté quotidiennement par cron ou systemd timer vers un stockage cloud immuable (Backblaze B2 avec Object Lock, ou un rest-server append-only) ; une réplication hebdomadaire via rclone vers un second fournisseur pour respecter la règle des deux supports différents ; et un test de restauration trimestriel documenté, avec le mot de passe de chiffrement conservé hors du serveur lui-même.

Cette architecture répond aux trois exigences de la règle 3-2-1 : trois copies (le serveur en production, le dépôt restic principal, la réplique rclone), deux supports différents (le disque du serveur et le stockage objet cloud), et une copie hors-site par construction puisque le stockage cloud est physiquement séparé du serveur. L'ajout de l'append-only ou de l'Object Lock répond à l'extension 3-2-1-1 pensée pour résister à un scénario de compromission active, pas seulement à une panne matérielle classique.

Le coût réel de cette configuration reste modeste : Backblaze B2 facture environ 6 € par mois par téraoctet stocké, un second fournisseur pour la réplique ajoute un montant comparable si vous répliquez l'intégralité du dépôt, et le temps de configuration initiale se compte en heures, pas en jours, une fois les scripts cron rédigés une première fois. Pour approfondir la comparaison des solutions de sauvegarde automatisée, y compris celles pensées pour un usage moins technique, consultez notre comparatif des logiciels de sauvegarde automatique. Si votre serveur personnel héberge aussi des services domestiques connectés, notre article sur la création d'un cloud personnel à la maison couvre l'aspect hébergement complémentaire à cette question de sauvegarde.