rsyncLa commande : rsync -aE --delete ~/Documents/ /Volumes/Backup/Documents/
-E est la moitié propre à macOS, et l'omettre fait perdre sans bruit les attributs étendus et les resource forks.
-a est le mode archive : récursif, et préserve les autorisations, le propriétaire, les dates et les liens symboliques. C'est l'option que tout le monde connaît.-E préserve les attributs étendus et les resource forks de macOS. Les tags du Finder, les marqueurs de quarantaine, les icônes personnalisées et une bonne partie des métadonnées des applications s'y trouvent. Sans lui, ils disparaissent, et rien ne vous le dit.--delete retire de la destination les fichiers qui ont disparu de la source. C'est ce qui fait de la copie un miroir, et c'est l'option à laquelle il faut le plus réfléchir.-v pour l'affichage, -n pour un essai à blanc. Faites toujours un essai à blanc la première fois qu'une commande contient --delete.~/Documents copie le dossier dans la destination, ce qui donne /Volumes/Backup/Documents/Documents. ~/Documents/ copie son contenu, ce qui est presque toujours ce que vous vouliez. Dans une commande qui contient aussi --delete, se tromper supprime tout ce qu'il y avait d'autre dans la destination.--exclude pour ce qui ne vaut pas la peine d'être copié : --exclude '.DS_Store', --exclude 'node_modules', --exclude 'Library/Caches'.macOS fournit une version de rsync suffisante pour cela. Si vous voulez la version amont plus récente, Homebrew la propose, et elle gère mieux les ACL sur macOS.
rsync rend la destination identique à la source. C'est une copie, et une copie n'est pas un historique. Un document supprimé mardi dernier disparaît de la sauvegarde à l'exécution suivante. Tout comme la bonne version d'un fichier que vous avez écrasé depuis, et tout ce que le ransomware a atteint avant que la tâche ne se lance.
Retirer --delete ne règle pas le problème. Vous obtenez une destination qui accumule tous les fichiers que vous avez jamais eus, toujours avec une seule version de chacun, et aucun moyen de savoir ce qui est à jour.
--link-destL'astuce classique consiste à créer un nouveau dossier daté à chaque exécution et à faire des liens physiques des fichiers inchangés vers le précédent, pour que les fichiers identiques ne coûtent rien :
DEST=/Volumes/Backup
TODAY=$(date +%F)
rsync -aE --delete \
--link-dest="$DEST/latest" \
~/Documents "$DEST/$TODAY"
ln -snf "$DEST/$TODAY" "$DEST/latest"Chaque dossier daté ressemble maintenant à une sauvegarde complète et seuls les fichiers modifiés prennent de la place. C'est à peu près l'idée sur laquelle repose Time Machine.
Deux réserves. Avec les liens physiques, les copies ne sont pas indépendantes : une corruption du bloc sous-jacent touche chaque instantané qui le partage. Et il faut un système de fichiers qui gère les liens physiques : cela marche sur un disque externe, pas dans la plupart des dossiers cloud.
rsync ne chiffre rien au repos. Si la destination est un dossier cloud ou un disque qui quitte le bâtiment, chiffrez avant d'écrire :
tar -cJf - ~/Documents | openssl enc -aes-256-cbc -pbkdf2 -out /Volumes/Backup/documents.tar.xz.encC'est une seule archive opaque : pas de copie incrémentielle, pas de restauration d'un seul fichier sans tout décompresser, et une seule phrase de passe entre vous et tout le reste. Ce compromis compte, et c'est là que la plupart des gens arrêtent de tout faire à la main.
cron existe toujours sur macOS, mais launchd est la méthode prise en charge. Un plist dans ~/Library/LaunchAgents/ avec un StartCalendarInterval lance votre script chaque jour. macOS demandera l'Accès complet au disque pour ce qui le lance, car la lecture de Documents et du Bureau est protégée.
Quoi que vous planifiiez, faites-le écrire son résultat à un endroit que vous verrez vraiment, et vérifiez que la sauvegarde est récente :
find /Volumes/Backup -type f -newermt '-7 days' | headUne tâche silencieuse, voilà la panne. Elle ne s'arrête pas avec une erreur à l'écran, elle s'arrête une nuit, il y a quatre mois.
Les commandes ci-dessus couvrent la copie. Ce qu'elles ne couvrent pas, c'est ce que vous voulez vraiment le jour où quelque chose tourne mal : des versions qui survivent à un passage du miroir, un chiffrement qui permet encore de restaurer un seul fichier, une relecture qui vérifie chaque morceau avec son empreinte, et quelque chose qui vous prévient quand le disque n'a pas été vu depuis une semaine.
Chacun de ces points représente un week-end de scripts, et ensuite c'est à vous de les maintenir. Copy Shelter suit la même idée avec ces parties intégrées, et il est gratuit pour un emplacement.
rsync perd-elle les tags du Finder ?Parce que -a seul ne transporte pas les attributs étendus sur macOS. Ajoutez -E. S'il vous faut aussi les ACL, utilisez -A, et envisagez la version Homebrew, qui les gère de façon plus fiable que celle du système.
Oui, soit vers un partage monté sous /Volumes, soit via SSH directement vers le NAS. Via SSH c'est plus rapide et cela ne dépend pas de la présence du montage, et beaucoup de NAS intègrent rsync.
sudo ?Pas pour votre propre dossier personnel. Vous devez en revanche accorder l'Accès complet au disque à Terminal, ou à ce que lance launchd, avant que macOS ne le laisse lire Documents, Bureau et Téléchargements.
--delete est-il dangereux ?Il fait exactement ce que vous avez demandé, et c'est là le danger. Faites un essai à blanc avec -n la première fois, et vérifiez le chemin de destination : une faute de frappe avec --delete pointé vers le mauvais dossier y supprime des fichiers.
Oui, c'est à ça que sert rsync. Relancez-le et il ne transfère que ce qui manque ou a changé. Ajoutez --partial pour qu'un gros fichier à moitié transféré soit conservé et repris.
Ensuite : comment vérifier que la copie est vraiment lisible.