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

Dernière mise à jour: 2026-08-06

Les sauvegardes qu'il faut penser à lancer soi-même finissent par ne pas être faites. cron, lui, s'en souvient, et la CLI Relayium est conçue pour cela : une seule commande non interactive qui copie (ou met en miroir) un répertoire vers une autre machine, vérifie chaque fichier, et reprend là où elle s'est arrêtée si le réseau coupe.

Ce guide couvre la planification de relayium push et du relayium sync incrémental via cron, les deux modes de transport que l'un comme l'autre peuvent utiliser, et des lignes de crontab prêtes à copier.

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 envoie une copie via SSH ou daemon-direct à chaque exécution — simple, et cela fonctionne même vers un serveur nu sans relayium installé grâce à un repli tar. sync, lui, maintient la destination comme un miroir incrémental et unidirectionnel de la source : seuls les fichiers modifiés sont renvoyés, si bien qu'une synchronisation nocturne d'un grand répertoire est rapide après la première exécution. sync a toujours besoin du protocole natif de relayium des deux côtés — il n'a pas de repli tar.

Utilisez push pour une copie planifiée simple, surtout vers un serveur qui pourrait ne pas avoir relayium installé.
Utilisez sync pour un répertoire volumineux ou qui change souvent, où tout renvoyer chaque nuit serait un gaspillage.
Les deux sont vérifiés par SHA-256 fichier par fichier et reprenables en cas d'interruption.

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 -o relayium ./cmd/relayium).
relayium --version confirme l'installation. Sans cela, les commandes ci-dessous affichent seulement « command not found ».

Deux modes de transport : SSH ou daemon-direct

Pointez l'une ou l'autre commande vers une destination SSH (style scp, en utilisant votre ~/.ssh/config) ou, si l'autre machine exécute relayium serve, directement vers elle via le protocole daemon-direct — sans SSH.

# destination SSH — utilise vos clés et votre configuration SSH existantes
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct — la destination exécute "relayium serve", aucun SSH requis
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 les deux mêmes formes de destination que push.

Le planifier avec cron

Ce qu'il vous faut avant l'étape 1

La CLI sur cette machine, et sur la destination aussi si vous comptez utiliser sync. sync n'a aucun repli sur tar.
Une clé SSH sans phrase de passe, ou une destination qui fait tourner relayium serve. cron n'a ni agent ni terminal : il ne peut pas répondre à une demande de phrase de passe.
Un répertoire source qui existe au moment où cron se déclenche — pas un montage réseau présent seulement pendant que vous êtes connecté.
Un endroit où écrire un journal. Une tâche cron dont la sortie ne va nulle part est une sauvegarde dont vous découvrirez l'état le jour où vous en aurez besoin.

push et sync sont tous deux des commandes uniques et non interactives, elles s'intègrent donc directement dans une crontab. Pointez-les vers une clé sans phrase de passe (ou vers un agent), et journalisez la sortie pour repérer les échecs :

# copie complète chaque nuit à 2 h — à ajouter à votre crontab (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-backup.log 2>&1

# à la place, un miroir incrémental toutes les 15 minutes
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&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
```
Vérifiez que la clé fonctionne sans personne au clavier. BatchMode=yes échoue au lieu de demander, ce qui est exactement la situation de cron.
```
ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
```
Exécutez la commande entière une fois à la main, écrite exactement comme cron l'exécutera, chemin absolu compris.
```
/usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/
```
Ensuite seulement, ajoutez la planification. Gardez le chemin absolu et la redirection.
```
crontab -e
```
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
```

À quoi ressemble une installation qui fonctionne

relayium se résout en un chemin absolu que vous pouvez coller dans la crontab, et la vérification ssh avec BatchMode se termine par 0 sans rien afficher ni rien demander. Une sauvegarde qui ne marche que depuis votre shell interactif n'est pas encore planifiée.

$ command -v relayium
/usr/local/bin/relayium
$ ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
$ 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.
Une exécution interrompue reprend simplement ou rattrape son retard à la prochaine exécution planifiée.

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 user@backup-server:/srv/backups/ --delete met en miroir les suppressions (le récepteur a besoin de serve --allow-delete).
relayium sync ./data user@backup-server:/srv/backups/ --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.

Symptôme, vérification, correction

Le journal indique relayium: command not found, alors que la même commande marche dans votre shell.

tail -n 5 ~/relayium-backup.log
# /bin/sh: relayium: command not found

cron tourne avec un PATH minimal, en général seulement /usr/bin:/bin. Si install.sh n'a pas pu écrire dans /usr/local/bin, le binaire est dans ~/.local/bin, que cron ne cherchera jamais. Mettez le chemin absolu donné par command -v dans la ligne de crontab, ou ajoutez une ligne PATH= en tête de crontab.

Le journal montre une connexion ssh refusée, ou plus rien après la première exécution.

ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
# Permission denied (publickey).

cron n'a ni ssh-agent ni terminal, une clé protégée par phrase de passe ne peut donc que bloquer ou échouer. Pointez -i sur une clé sans phrase de passe réservée aux sauvegardes, et vérifiez avec BatchMode=yes, qui refuse de demander plutôt que d'attendre quelqu'un qui n'est pas là.

sync s'exécute proprement, mais les fichiers supprimés à la source sont toujours sur la destination.

grep -i deni ~/relayium-sync.log

La suppression se décide côté récepteur. Sans serve --allow-delete en face, les suppressions sont ignorées et renvoyées comme refusées — voilà pourquoi la réponse est dans le journal et pas dans le code de sortie. Relancez l'écouteur d'en face avec --allow-delete.

sync refuse purement et simplement --delete.

relayium sync ~/documents user@backup-server:/srv/backups/ --delete
# refusing --delete with an empty source: this would delete everything on the destination. Check the path(s).

La source n'a résolu aucun fichier, le miroir aurait donc vidé la destination. Ce refus est délibéré. Vérifiez le chemin, et vérifiez que ce qui doit y être monté l'est bien à l'heure où cron se déclenche et pas seulement quand vous êtes connecté.

La sauvegarde tourne, se termine par 0, et n'est pas ce que vous croyez.

ssh user@backup-server command -v relayium

Quand la machine distante n'a pas relayium, push se rabat sur un simple flux tar via SSH. Les fichiers arrivent, donc rien ne se plaint — mais ce chemin n'a ni vérification SHA-256 fichier par fichier ni reprise, c'est-à-dire précisément les deux raisons de planifier ceci plutôt qu'un scp. Installez la CLI sur la destination pour les retrouver. sync n'a pas ce défaut : n'ayant aucun repli, il échoue bruyamment à la place.

Questions fréquentes

Le serveur de sauvegarde a-t-il besoin de relayium installé ?

Cela dépend de la commande. push fonctionne dans les deux cas : avec relayium installé, il utilise le protocole natif (reprise + vérification SHA-256 par fichier) ; sans, push bascule sur un simple flux tar via SSH, si bien qu'un serveur nu fonctionne quand même. sync a toujours besoin du protocole natif de relayium côté distant — il n'y a pas de repli tar pour sync, installez-le donc là-bas au préalable.

La sauvegarde est-elle chiffrée et vérifiée ?

Oui. Chaque fichier est vérifié de bout en bout par un hachage SHA-256, et en poussant via SSH ou daemon-direct, les octets sont déjà protégés par le chiffrement propre à cette connexion — rien à configurer en plus.

Que se passe-t-il si la tâche cron est interrompue en cours de route ?

Avec relayium des deux côtés, la prochaine exécution planifiée reprend les fichiers partiels au lieu de tout renvoyer. Passez --no-resume si vous voulez plutôt un renvoi complet et propre.

--delete peut-il vider ma destination par accident ?

sync refuse de s'exécuter avec --delete si le répertoire source ne contient aucun fichier, et le récepteur doit être démarré avec serve --allow-delete pour que les suppressions prennent effet — sinon elles sont ignorées et vous sont signalées.

Ai-je besoin d'un compte, est-ce payant ?

Non. La CLI est gratuite et ne nécessite aucun compte pour push, pull ou sync — le transfert passe par votre propre connexion SSH ou une connexion daemon directe, pas par les serveurs de Relayium.

Confiez vos sauvegardes à une planification dont vous n'avez pas à vous souvenir — chiffré, reprenable et gratuit.

Obtenir la CLI