rsync sur un VPN : quel côté fait foi ?

Deux serveurs, un VPN, un répertoire qui doit exister aux deux endroits, et une commande facile à lancer et difficile à annuler. Avant de la taper, décidez quelle copie fait autorité, car chaque question rsync qui suit dépend de cette réponse. Une réplique à sens unique, un dossier de travail partagé et une archive versionnée demandent des règles différentes pour les modifications et les suppressions. Le tunnel fournit le chemin et n'a d'avis sur aucune d'elles.

Décidez quelle copie gagne avant de taper une commande

Écrivez la direction en une phrase, avec le nom d'hôte et le chemin de chaque côté, et faites-la valider par le propriétaire des données. Dans ce parcours, la source est /srv/publish/ et la destination est un compte sur fileserver.example qui ne peut écrire que dans /srv/mirror/.

Confirmez les faits de transport avant la copie : la clé d'hôte SSH est vérifiée, le compte de destination peut écrire dans la zone de réplique et nulle part ailleurs, et les deux hôtes ont des versions rsync compatibles. Ces préconditions empêchent une petite erreur de planification de devenir un incident de permissions. Elles vous disent aussi quel compte apparaîtra dans les journaux de la destination quand quelque chose tourne mal.

Prévisualisez la copie et lisez la liste détaillée

Lancez d'abord la copie avec l'option de prévisualisation, et conservez la sortie. Les changements détaillés vous disent ce qui arriverait à chaque chemin, ce qui est bien plus utile qu'un résumé d'achèvement après coup. Conservez la sortie dans le registre des changements pour que l'exécution suivante ait de quoi être comparée.

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

La barre oblique finale compte. Côté source, elle désigne le contenu de ce répertoire, tandis que l'omettre ajoute un niveau de répertoire portant le nom de la source. Le manuel rsync documente les deux formes ainsi que les options de préservation, et le jeu d'options dont vous avez besoin dépend des données plutôt que de l'habitude.

Lisez chaque ligne par rapport à la destination que vous visiez. Retirer l'option de prévisualisation exécute la copie et peut écraser des fichiers, et sans option de suppression les fichiers supplémentaires déjà présents à la destination restent simplement où ils sont. Ce n'est le comportement sûr par défaut que si vous avez réellement décidé que des fichiers périmés laissés derrière sont acceptables. Si la réponse est non, c'est la décision de suppression ci-dessous qu'il faut prendre, pas une option supplémentaire à saupoudrer dans cette commande.

Décidez ensuite si les suppressions voyagent

Faire de la destination un miroir est une seconde décision, et non un raffinement de la première. Prévisualisez-la séparément, avec l'option de suppression ajoutée et rien d'autre modifié, afin que la différence dans la liste appartienne entièrement à cette décision.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Les suppressions retirent les fichiers superflus du côté récepteur dans la portée synchronisée, et c'est pourquoi un chemin source erroné, un répertoire non monté ou un filtre qui exclut plus que prévu peuvent faire passer une exécution destructrice pour un miroir propre. La liste de prévisualisation est le seul endroit où cette différence devient visible avant qu'elle ne coûte cher. Gardez une copie de récupération indépendante là où les données le justifient, et rappelez-vous qu'un miroir reproduit fidèlement une suppression accidentelle au lieu de conserver l'historique.

Une prévisualisation ne verrouille rien non plus. Les gens modifient des fichiers entre l'essai et l'exécution réelle, et les systèmes de fichiers ont leurs propres avis, donc l'exécution que vous approuvez et celle qui s'exécute ne sont pas la même opération tant que les deux arborescences ne sont pas au repos.

Deux tâches à sens unique ne font pas une synchronisation bidirectionnelle

Lancer la même commande dans les deux sens est la façon la plus courante de perdre des données dans ce scénario. Chaque sens traite l'autre côté comme destination et écrase allègrement un contenu plus récent, et les suppressions se répliquent dans l'ordre où la planification se déclenche.

Si les utilisateurs doivent modifier les deux copies, c'est une autre décision produit : gestion des conflits, suivi des suppressions et un outil conçu pour ce modèle. L'approximer par l'ordre de planification est la façon dont un dossier partagé accumule deux versions de chaque document que personne ne peut réconcilier. Décidez-le explicitement au lieu de l'approximer avec deux entrées cron et d'espérer.

N'automatisez qu'après avoir écrit la politique

Une tâche planifiée doit porter la direction, les chemins, la politique de métadonnées et la décision de suppression approuvée. Placez ces cinq faits dans le fichier de tâche lui-même, pas dans une page wiki que le prochain administrateur ne lira peut-être jamais. Empêchez les exécutions qui se chevauchent, car deux copies écrivant la même arborescence en même temps produisent un état que ni l'une ni l'autre n'avait prévu.

Quand la source est une base de données active ou un autre jeu de données multi-fichiers, prenez d'abord un export cohérent avec l'application ou un instantané coordonné. Un parcours récursif de fichiers n'est pas une transaction, et une copie d'un jeu de données en cours de modification n'est pas cohérente.

Enregistrez les achèvements et les échecs, et vérifiez le jeu de données à la destination plutôt que seulement le code de sortie. Rétablir le VPN après une panne rétablit la connectivité ; cela ne dit rien sur la fin de la dernière copie ni sur la résolution d'éventuelles modifications conflictuelles.