> rsync command generator — dry-run d'abord, suppression avec un filet▋

Qu'est-ce qui sépare une synchronisation d'un effacement ? Souvent une seule option. Tape rsync -a --delete /mnt/empty-usb/ /home/you/ et rsync fera fidèlement correspondre ta destination à ta source — tout, y compris la partie où ton dossier personnel est désormais vide. Tous les générateurs que j'ai trouvés en première page câblent allègrement cette option derrière une case à cocher ; l'un étiquette même sa sortie « généré par IA et pas encore vérifié », ce qui est audacieux à imprimer au-dessus d'une commande de suppression. C'est le mensonge que cet outil refuse : qu'assembler la syntaxe rsync et comprendre la sémantique rsync sont le même métier. Le rsync command generator est en ligne — il construit la commande, nomme les pièges en mots simples, et traite --delete comme l'arme chargée qu'elle est.

Pourquoi --delete mérite-t-il un avertissement ?

Parce que le contrat de rsync, c'est rendre la destination identique à la source, et --delete étend ce contrat aux suppressions. La page man ne fait pas dans la nuance : l'option signifie « delete extraneous files from the destination dir ». Extraneous, autrement dit tout ce que la source n'a pas — y compris ce qui manque seulement parce que tu as visé la mauvaise source, monté la mauvaise clé USB ou mal tapé un chemin. Le travail du générateur, c'est de rendre cette conséquence visible avant l'exécution de la commande, pas après :

Option	Ce qu'elle fait	Ce qu'elle fait quand tu te trompes
--delete	Les fichiers de la destination absents de la source sont supprimés	Mauvais chemin source → fichiers de la destination « extraneous » → disparus
src/ vs src	Le slash final copie le contenu ; sans slash, c'est le dossier lui-même qui est copié	Un caractère, et une destination organisée tout autrement
-a	Archive : récursif + permissions, dates, propriétaires, liens symboliques	Oubliée → une « sauvegarde » qui en silence n'en est pas une
--partial	Conserve les fichiers à moitié transférés en cas d'interruption	Lien capricieux → tout le transfert repart de zéro

La ligne du slash final, c'est le grand classique. La documentation de rsync elle-même dit qu'un slash final sur la source « changes this behavior to avoid creating an extra directory at the destination » — ce qui se traduit de la langue documentation par : src/ verse le contenu dans la destination, src crée dest/src et verse le contenu dedans. Deux caractères. Le générateur affiche la phrase qui s'applique pendant que tu tapes, parce que le slash final est aussi la seule option rsync qui ait avalé plus de dossiers personnels que rm -rf dans toute sa carrière.

Comment armer une suppression sans danger ?

Tu ne retired pas la sécurité — tu ajoutes un filet. Le flux d'armement du générateur a deux temps : la commande sort avec --dry-run et tu lis ce qui se passerait ; seulement ensuite tu bascules l'interrupteur d'armement pour le vrai tir. Et dès que --delete entre en jeu, l'outil refuse de produire une suppression nue. Il ajoute le filet :

rsync -a --delete \
  --backup --backup-dir=/mnt/backup/_rsync_backup_$(date +%F) \
  /mnt/usb/ /mnt/backup/

Avec --backup --backup-dir en place, rsync ne détruit pas les fichiers qu'il retire ou écrase — il les met de côté dans le dossier daté d'abord. Le miroir reste exact au final. Le jour où tu constates que c'est la mauvaise source qui était montée, tes fichiers sont posés dans _rsync_backup_2026-10-16/ au lieu d'être une leçon. La réversibilité, c'est la différence entre un miroir et un souvenir.

Oui : rsync -a --delete --backup --backup-dir=DEST/_rsync_backup_$(date +%F) SRC/ DEST/. Les deux options du filet déplacent chaque fichier supprimé ou écrasé dans un dossier daté au lieu de l'effacer, donc le miroir reste exact et les suppressions restent réversibles. Dry-run d'abord avec -n, lis la liste, puis arme.

vérifier : man rsync → --backup dit « make a backup of every file installed » · les lignes --backup-dir atterrissent dans DEST/_rsync_backup_<date>/, pas dans le vide

Quelles options le générateur câble-t-il ?

L'ensemble qui couvre presque tout transfert réel, groupé selon les questions que tu te poses vraiment :

• Chemins — local ou distant de chaque côté (user@host:/path), avec le port SSH câblé via -e "ssh -p 2222" quand ce n'est pas 22.
• Direction — le toggle du slash final, avec la phrase contenu-contre-dossier affichée en direct.
• Filtres — motifs --exclude avec des préréglages pour les suspects habituels : .git, node_modules, caches, logs.
• La politesse — compression -z, --bwlimit pour que la sauvegarde de 3 h du matin cesse de saturer toute la maison, -P pour la progression et la reprise, -c quand le mtime ment.
• La voie d'armement — dry-run par défaut, étape d'armement explicite, filet auto-attaché à tout --delete.

La sortie, c'est une ligne prête à coller (ou un multi-lignes à backslashes, à ton terminal de choisir), plus un snippet intégrable si tu veux le builder sur ta propre page. Comme le GGUF VRAM calculator, c'est un seul fichier HTML qui fait les calculs dans ton navigateur — rien de ce que tu tapes ne quitte la page, parce qu'un outil qui parle de copies sûres n'a pas à se connecter chez personne.

Où il se range dans la boîte à outils

Le générateur compose la commande ; les articles voisins portent la théorie. Rsync vs scp explique pourquoi le transfert delta de rsync bat une copie bête et quand scp reste très bien. Cron vs timers systemd est la moitié planification — une commande rsync sortie du générateur se dépose dans un timer, et le versant journal pour savoir si elle a tourné est dans l'antisèche journalctl.

Un dry-run que tu sautes, c'est une suppression que tu n'avais pas voulue.

L'outil est sur github.com/mrsaynothing/rsync-builder — MIT, un fichier, aucune étape de build. Si le flux d'armement te semble parfois faire la morale, c'est que la fonctionnalité marche ; et si tu sais nommer une combinaison d'options que le filet ne couvre pas, ouvre une issue — les coins dangereux sont précisément ceux qui méritent d'être cartographiés.