Pourquoi une copie miroir Rsync répercute-t-elle les suppressions accidentelles sur la sauvegarde ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Why Does an Rsync Mirror Copy Accidental Deletions to the Backup?

Un miroir rsync copie les suppressions accidentelles car un miroir est conçu pour faire correspondre la destination à la source actuelle. Lorsque la tâche utilise --delete ou une option de suppression associée, un fichier manquant sur le NAS domestique est traité comme un fichier supplémentaire sur la destination de sauvegarde et est supprimé lors de la synchronisation. Ce comportement est correct pour un miroir, mais il est dangereux comme seule histoire de récupération.

Rsync suit une règle de miroir, pas la conservation de chaque version passée

Sans option de suppression, rsync copie normalement les fichiers nouveaux et modifiés mais laisse en place les fichiers présents uniquement sur la destination. Avec --delete, la destination est réconciliée avec la source. Une explication concise de ce drapeau indique que supprimer un fichier de la source le supprime aussi de la destination afin que la destination reste un véritable miroir.

Pour un NAS domestique ZimaSpace, cela signifie qu'une photo de famille supprimée, un dossier média renommé, une configuration de conteneur supprimée ou un montage temporairement manquant peut être reflété sur le miroir USB ou distant lors de la prochaine exécution programmée.

La suppression commence par un chemin source manquant

Rsync ne sait pas si un fichier a disparu parce que vous l'avez intentionnellement supprimé, qu'une application l'a nettoyé, qu'un utilisateur a fait une erreur, qu'un ransomware a modifié l'arborescence, ou qu'un jeu de données source n'a pas pu être monté. Il compare l'arbre source visible avec l'arbre de destination. Si un objet existe uniquement côté réception et que la suppression est activée, il devient un candidat à la suppression.

Événement source	Ce que rsync voit	Résultat du miroir avec suppression activée
L'utilisateur supprime un dossier photo	Dossier absent de la source	Dossier supprimé du miroir
L'application conteneur supprime les anciens médias	Fichiers absents du chemin app-data	Fichiers supprimés du miroir
Le pool de données NAS ne parvient pas à se monter	Le chemin source peut apparaître vide	Un grand ensemble de suppressions peut être proposé
Modifications du chemin partagé	L'ancien arbre source n'est plus scanné	L'ancien contenu de destination peut être supprimé

Le moment de la suppression change quand les fichiers sont supprimés, pas s'ils le sont.

Les options associées contrôlent la phase du transfert. --delete-before supprime les fichiers présents uniquement sur la destination avant la copie, --delete-during supprime pendant que les répertoires sont traités, et --delete-after attend que les transferts se terminent. Ils affectent le comportement de l'espace libre et l'exposition aux échecs, mais ils ne transforment pas le miroir en une sauvegarde versionnée.

Utilisez le timing délibérément. Supprimer avant le transfert peut libérer de la capacité mais supprime l'état miroir précédent plus tôt. Supprimer après le transfert préserve plus longtemps l'ancien contenu de destination, mais le résultat final correspond toujours à la source si la tâche se termine.

Un montage manquant peut ressembler à une suppression massive

Un des cas les plus dangereux sur un serveur domestique survient lorsque le chemin source planifié existe toujours en tant que répertoire vide après l’échec du montage du pool de stockage réel. Rsync peut alors comparer une source vide avec une destination remplie. Une mesure de sécurité proposée est de faire une vérification à sec et compter les suppressions prévues avant d’autoriser la synchronisation réelle.

Sur un NAS domestique, faites échouer la tâche si le montage source attendu, l’UUID du système de fichiers, le répertoire marqueur ou le nombre minimum de fichiers est manquant. Ne considérez pas l’existence d’un chemin vide comme une source saine.

Mettez le travail en pause avant d’essayer de récupérer un fichier supprimé

Désactivez immédiatement la tâche rsync planifiée.
Ne relancez pas la commande pour « voir si ça se répare tout seul ».
Vérifiez les snapshots, corbeilles, dépôts de sauvegarde versionnés et la seconde copie hors ligne.
Si le miroir contient encore le fichier, copiez-le vers un chemin de quarantaine en dehors de la destination rsync avant la prochaine exécution.
Confirmez si la suppression source était intentionnelle avant de la restaurer dans le partage actif.

L’article ZimaSpace sur la conservation des photos de famille en plusieurs copies indépendantes est pertinent ici : un miroir synchronisé doit être une couche, pas le seul endroit où un fichier plus ancien peut survivre.

Prévisualiser l’ensemble exact des suppressions

Exécutez la même commande avec --dry-run, une itemisation détaillée et un rapport de suppression. Vérifiez les chemins source et destination, les barres obliques finales, les exclusions, l’état du montage et le nombre de suppressions prévues. Un article récent sur la sécurité de rsync souligne que un miroir peut reproduire une suppression accidentelle ou un dommage par ransomware et nécessite donc une couche d’historique séparée.

rsync -a --delete --dry-run --itemize-changes   /srv/storage/family/ /mnt/usb-mirror/family/

Considérez un nombre de suppressions inattendu comme un échec de la vérification préalable. Arrêtez-vous et vérifiez que le dataset NAS prévu est monté et que la commande ne cible pas un répertoire parent ou un mauvais disque amovible.

Déplacer les fichiers supprimés vers une zone de récupération

Si vous avez besoin d'un miroir mais souhaitez aussi une courte fenêtre de récupération, combinez la suppression avec un répertoire de sauvegarde ou une couche d'instantanés. Rsync peut déplacer les fichiers remplacés ou supprimés de la destination dans un répertoire de récupération daté au lieu de les détruire immédiatement. Les conseils communautaires pour conserver les données supprimées par rsync recommandent de garder les fichiers supprimés dans un emplacement séparé avec sa propre politique de nettoyage.

rsync -a --delete   --backup   --backup-dir="/mnt/usb-mirror/deleted/$(date +%F)"   /srv/storage/family/ /mnt/usb-mirror/current/

Testez la commande d'abord avec des données non critiques. Le répertoire de récupération doit être en dehors du sous-arbre miroir, sinon une exécution future pourrait le traiter comme partie de la source ou le supprimer selon la même politique.

Utilisez des instantanés versionnés lorsque les états passés comptent

Un miroir actuel répond à « à quoi ressemble la source maintenant ? » Une sauvegarde répond à « à quoi ressemblait la source avant l'erreur ? » Si vous avez besoin des deux, conservez le miroir pour un accès rapide et ajoutez des instantanés de système de fichiers, des répertoires d'instantanés avec liens physiques, un outil de sauvegarde versionné ou un second disque hors ligne.

Un récit de suppression accidentelle avec rsync décrit clairement la faiblesse sous-jacente : un flux de travail rsync fait main nécessite des protections explicites pour la rotation et la suppression. Ne comptez pas sur une destination mutable unique pour fournir à la fois une synchronisation exacte et un historique à long terme.

FAQ

Si je supprime `--delete`, le miroir devient-il une sauvegarde ?

Pas seule. Les fichiers présents uniquement sur la destination resteront, mais les fichiers écrasés peuvent toujours perdre leur contenu précédent, et il n'y a pas de point de restauration propre pour une date spécifique. Ajoutez des instantanés ou un dépôt de sauvegarde versionné.

Quelle option de timing de suppression est la plus sûre ?

--delete-after retarde les suppressions jusqu'à la fin des transferts, ce qui préserve plus longtemps l'état ancien de la destination pendant l'exécution. Il supprime néanmoins les fichiers présents uniquement sur la destination à la fin, donc les vérifications préalables et l'historique des versions restent nécessaires.

Comment arrêter une suppression massive inattendue ?

Désactivez le planning, effectuez une simulation avec sortie des suppressions, vérifiez le montage et le chemin source, et définissez un seuil de nombre de suppressions ou une vérification de fichier marqueur. Ne relancez pas la commande en direct tant que la liste des suppressions proposées n'est pas comprise.

Conclusion finale

Rsync reflète les suppressions accidentelles car les options de suppression font correspondre la destination de la sauvegarde à la source NAS visible. Protégez un flux de travail de serveur domestique ZimaSpace en vérifiant les montages, en prévisualisant les suppressions, en mettant en quarantaine les fichiers supprimés et en conservant des points de récupération versionnés ou hors ligne. Un miroir peut être utile, mais un miroir exact sans historique n'est pas une protection suffisante contre les erreurs humaines.