Comment rendre mes sauvegardes immuables contre les ransomwares sur mon propre serveur ?

Que signifie « immuable » pour une sauvegarde ?

Un rançongiciel qui prend le contrôle d'un serveur récupère généralement aussi les identifiants de sauvegarde qui y sont stockés. Si ces identifiants permettent de supprimer les anciennes sauvegardes, l'attaquant les supprime avant de chiffrer quoi que ce soit.

Une sauvegarde immuable ferme cette porte. La machine sauvegardée peut ajouter de nouvelles données, mais rien de ce qu'elle détient ne peut supprimer ou réécrire les anciennes versions. Certaines méthodes l'imposent par les droits d'accès, d'autres par un verrou avec une date d'expiration.

Si la machine que vous protégez peut supprimer ses propres sauvegardes, alors quiconque prend le contrôle de cette machine le peut aussi.

Comment restic et Borg fonctionnent-ils en mode append-only ?

Le rest-server de restic dispose d'un flag --append-only. Son README indique que ce mode autorise les nouvelles sauvegardes mais empêche la suppression et la modification des existantes. Lancez le prune depuis une machine d'administration via une seconde instance sans le flag, ou directement sur le serveur.

Borg impose ce mode avec une commande forcée dans authorized_keys, ou avec append_only = 1 dans la configuration du dépôt. Sa documentation en liste clairement les limites :

• borg delete et borg prune fonctionnent toujours ; ils ne font que marquer les données comme supprimées.
• La prochaine écriture en mode normal supprime ces données définitivement, donc un prune automatique rend le mode inopérant.
• Lancez borg check avant de faire un prune sur un dépôt append-only.
• rm fonctionne toujours sur les fichiers, donc les clients doivent accéder au dépôt uniquement via borg serve.

Les deux outils sont comparés sur restic ou Borg pour des sauvegardes hors site.

# restic: rest-server, one private repository per user
rest-server --path /tank/restic --append-only --private-repos --tls \
  --tls-cert /etc/rest-server/cert.pem --tls-key /etc/rest-server/key.pem

# Borg: in ~backup/.ssh/authorized_keys, one line per client key
command="borg serve --append-only --restrict-to-path /tank/borg/web1",restrict ssh-ed25519 AAAA... web1

Comment Proxmox Backup Server et Veeam verrouillent-ils les sauvegardes ?

Proxmox Backup Server fonctionne par rôles. Un utilisateur disposant de DatastoreBackup peut sauvegarder et restaurer ses propres sauvegardes, mais le prune nécessite DatastorePowerUser. Le garbage collection attend aussi 24 heures et 5 minutes avant de supprimer des chunks. Associez-le à une tâche de sync tirée par le serveur hors site, afin que le site local ne détienne aucun identifiant hors site. L'installation complète est sur un Proxmox Backup Server hors site sur un serveur loué.

Le hardened repository de Veeam fonctionne par le temps. Les fichiers restent immuables de 7 à 9999 jours, et les identifiants qui ont installé les services Veeam n'ont jamais été stockés. Les étapes pour une machine louée sont sur un dépôt Veeam hardened sur un serveur Linux loué.

Puis-je utiliser S3 Object Lock sur mon propre serveur ?

Uniquement si votre serveur S3 l'implémente, et les deux options open source les plus connues diffèrent.

• MinIO documente le verrouillage d'objets sur des buckets versionnés, en mode GOVERNANCE ou COMPLIANCE. En mode COMPLIANCE, aucun utilisateur ne peut modifier une version verrouillée, root compris. Mais le dépôt communautaire de MinIO a été archivé le 25 avril 2026, n'est plus maintenu et n'est livré qu'en code source.
• Garage liste Object Lock et le versioning de bucket comme absents sur sa page de compatibilité S3.

Côté client, Kopia prend en charge Object Lock : le bucket doit l'avoir activé à sa création, et Kopia recommande le mode compliance. Son autre conseil fonctionne partout : une clé d'accès sans permissions de suppression. Les autres serveurs S3 sont comparés sur les meilleures alternatives à MinIO pour du S3 auto-hébergé.

Comment les snapshots ZFS protègent-ils une sauvegarde contre son propre client ?

Laissez le client écrire via SFTP ou rsync avec un compte ordinaire, et laissez root prendre les snapshots. OpenZFS décrit un snapshot comme une copie en lecture seule d'un système de fichiers. Le compte du client n'obtient aucun droit destroy via zfs allow, il ne peut donc pas les supprimer.

Un hold ajoute un second verrou. Tant qu'un snapshot a un hold, zfs destroy dessus échoue avec EBUSY jusqu'à ce que quelqu'un lève le hold.

Des snapshots pris par root, sur un dataset où le client écrit, transforment toute cible rsync ou SFTP en cible versionnée et append-only.

snap=tank/backup@$(date +%F)
zfs snapshot "$snap"
zfs hold keep "$snap"
zfs holds "$snap"        # lists the hold named keep

Qu'est-ce qui supprime encore les sauvegardes immuables sur un serveur loué ?

Deux choses, et toutes deux se situent en dehors du logiciel de sauvegarde.

• Root sur le serveur de sauvegarde. Toutes les méthodes ci-dessus cèdent finalement devant root. Gardez root sur une clé qui ne se trouve jamais sur les machines que vous sauvegardez, et limitez SSH à votre adresse d'administration.
• La location elle-même. Chaque serveur est payé d'avance depuis votre solde crypto, pour 30 jours, 3 mois, 6 mois ou 12 mois selon le choix effectué au paiement. Le renouvellement automatique recharge la même durée au prix de départ, sauf si vous définissez une autre durée pour le renouvellement suivant dans le tableau de bord ; si le solde est insuffisant, le serveur s'arrête à la fin de sa période, ses disques sont conservés pendant 7 jours puis effacés. Les redémarrages, réinstallations et annulations se demandent dans le tableau de bord et sont traités par l'équipe ; une réinstallation efface tous les disques, disques de données compris. Un verrou plus long que la durée payée ne protège rien.

Un serveur de stockage n'est pas la sauvegarde de lui-même : nous ne conservons aucune copie de vos données ailleurs, une seconde copie à un autre endroit reste donc à votre charge. Les versions verrouillées ne peuvent pas non plus être élaguées par anticipation, donc le pool grandit à chaque version conservée. L'enquête de Basalthold sur 2 November 2026 a constaté que les serveurs de stockage de 72 TB ou plus coûtent une médiane de $4.86 par TB et par mois chez des hébergeurs acceptant la crypto sans KYC. Hold 100 coûte $3.77/TB, brut. Les durées allant jusqu'à 12 mois sont sur la liste de prix des hold.