Automatiser les sauvegardes serveur chiffrées avec une tâche cron

push ou sync : copie complète ou miroir incrémental

push et sync déplacent tous deux un répertoire vers une autre machine, et tous deux peuvent être exécutés sans risque de façon répétée, mais ils résolvent des problèmes de sauvegarde légèrement différents.

push crée une copie daemon-direct ponctuelle protégée contre les collisions et refuse une destination existante au lieu de l'écraser ou de reprendre — ce qui ne convient pas à une tâche répétée vers un répertoire de réception fixe. sync, lui, maintient une destination comme miroir incrémental à sens unique de la source : les fichiers inchangés sont sautés, les fichiers modifiés envoyés, et un fichier partiel est poursuivi à l'exécution suivante. En tant que miroir, il reflète l'état actuel et non l'historique : la suppression ou la corruption d'un fichier source peut être propagée.

• Utilisez push vers une destination datée quand chaque exécution doit être autonome et que les copies plus anciennes doivent survivre.
• Utilisez sync pour un répertoire volumineux ou qui change souvent, où tout renvoyer chaque nuit serait un gaspillage.
• Les deux vérifient chaque fichier transféré par SHA-256. push ne reprend pas ; sync poursuit un fichier partiel lors d'une exécution ultérieure.

Avant de commencer

Tout ci-dessous passe par la CLI relayium, alors installez-la d'abord si ce n'est pas fait. Sous macOS ou Linux, une commande place un binaire précompilé dans votre PATH :

curl -fsSL https://relayium.com/install.sh | sh

• Vous préférez choisir le fichier vous-même, ou sous Windows ? Récupérez un binaire depuis la page des releases — relayium.com/cli liste toutes les options (avec Go, go build ./cmd/relayium).
• relayium --version confirme l'installation. Sans cela, les commandes ci-dessous affichent seulement « command not found ».

Un seul transport : daemon-direct

Pointez l'une ou l'autre commande vers une destination relayium:// dont la machine réceptrice exécute relayium serve. Les destinations SSH sont retirées.

# daemon-direct : la destination exécute "relayium serve"
relayium push ./data relayium://backup-server:9031

• Les connexions daemon-direct utilisent du TLS 1.3 épinglé avec confiance à la première utilisation (trust-on-first-use), puis sont vérifiées contre cette même empreinte à chaque exécution suivante.
• sync accepte la même forme de destination relayium:// que push.

Le planifier avec cron

Une fois l'expéditeur pré-autorisé, sync est une seule commande non interactive qui s'insère directement dans une crontab. Journalisez la sortie pour que les échecs soient visibles :

# miroir incrémental toutes les 15 minutes
*/15 * * * * relayium sync ~/documents relayium://backup-server:9031 >> ~/relayium-sync.log 2>&1

1. Trouvez où se trouve réellement relayium. cron n'utilise pas le PATH de votre shell, et install.sh se rabat sur ~/.local/bin quand /usr/local/bin n'est pas accessible en écriture — précisément l'endroit que cron ne voit jamais.

   command -v relayium

2. Vérifiez que l'écouteur est joignable et que cet expéditeur a déjà été autorisé.

   relayium id

3. Exécutez la commande entière une fois à la main, écrite exactement comme cron l'exécutera, chemin absolu compris.

   /usr/local/bin/relayium sync ~/documents relayium://backup-server:9031

4. Ensuite seulement, ajoutez la planification. Gardez le chemin absolu et la redirection.

   crontab -e

5. Après le premier passage planifié, lisez le journal au lieu de supposer. C'est l'étape que l'on saute, et c'est celle qui vous l'aurait dit.

   tail -n 20 ~/relayium-backup.log

$ command -v relayium
/usr/local/bin/relayium
$ /usr/local/bin/relayium sync ~/documents relayium://backup-server:9031
$ echo $?
0

• La commande se termine avec un code non nul si un fichier échoue à sa vérification d'intégrité, si bien que la notification par e-mail en cas d'échec de cron détecte les problèmes.
• Un sync interrompu rattrape son retard à l'exécution planifiée suivante : ce qui correspond déjà est sauté et un fichier partiel est poursuivi.

Mettre en miroir les suppressions et synchroniser en temps réel

Par défaut, sync ne fait qu'ajouter ou mettre à jour des fichiers du côté destination. Ajoutez --delete pour en faire un véritable miroir qui supprime aussi les fichiers que la source n'a plus — le côté récepteur doit explicitement écouter avec serve --allow-delete, sinon les suppressions sont silencieusement ignorées et signalées comme refusées. sync refuse aussi purement et simplement --delete si le répertoire source ne résout aucun fichier, si bien qu'une faute de frappe dans le chemin source ne peut pas vider la destination.

Si vous préférez ne pas attendre le prochain passage de cron, --watch garde relayium sync en cours d'exécution et resynchronise automatiquement peu après qu'un fichier sous la source change — une solution légère, sans interrogation périodique.

• relayium sync ./data relayium://backup-server:9031 --delete met en miroir les suppressions (le récepteur a besoin de serve --allow-delete).
• relayium sync ./data relayium://backup-server:9031 --watch reste en cours d'exécution et resynchronise à chaque changement, au lieu d'une exécution unique via cron.

Quand ça ne marche pas

Chacun de ces cas est invisible tant que vous ne regardez pas le journal — c'est pourquoi la redirection figure dans la ligne de crontab et n'est pas facultative. Le cinquième est pire qu'invisible : il ressemble à une réussite.