Sauvegarder des fichiers sur son propre serveur via SSH avec la CLI Relayium

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

Si vous avez déjà un accès SSH à une machine — un VPS, un serveur personnel, un NAS, un poste de travail —, vous pouvez y sauvegarder des fichiers avec la CLI Relayium sans mettre en place un service de synchronisation ni de compte. Le transfert passe par votre connexion SSH existante, si bien que les octets vont directement à votre serveur et ne transitent jamais par Relayium.

Ce guide couvre le push et le pull de répertoires, ce que la reprise et la vérification d'intégrité vous apportent, et comment le planifier avec cron.

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 ».

Pousser (push) un répertoire vers votre serveur

Ce qu'il vous faut

L'accès SSH que vous utilisez déjà. ssh user@your-server true doit revenir en silence — push réutilise exactement cette connexion et ne configure rien de son côté.
Une destination inscriptible sur le serveur. Le répertoire parent du chemin de destination doit exister et être inscriptible par cet utilisateur SSH.
Éventuellement relayium sur le serveur, car c'est lui qui apporte la reprise et le SHA-256 par fichier. Sans lui, push fonctionne quand même, via un simple flux tar.
Aucun compte Relayium et aucun démon d'un côté ou de l'autre. Rien ici ne parle aux serveurs de Relayium.

push prend une ou plusieurs sources et une destination de style scp. Relayium se connecte en SSH avec vos clés et votre configuration habituelles, puis diffuse les fichiers vers le répertoire de destination :

Confirmez l'accès SSH que push va réutiliser. Un retour silencieux signifie que vos clés, votre alias d'hôte et votre port sont déjà bons.
```
ssh user@your-server true
```
Déterminez le protocole que vous obtiendrez. Un chemin annonce le protocole natif — reprise et SHA-256 par fichier ; aucune sortie annonce le flux tar.
```
ssh user@your-server command -v relayium
```
Poussez le répertoire. La destination est de style scp, et la barre oblique finale signifie « à l'intérieur de ce répertoire ».
```
relayium push ./photos user@your-server:backups/
```
Indiquez la clé ou le port pour cette seule commande si votre configuration ssh ne couvre pas encore cet hôte.
```
relayium push -i ~/.ssh/id_ed25519 -p 2222 ./photos user@your-server:backups/
```
Vérifiez ce qui est arrivé. push ./photos recrée photos/ sous la destination, le nom du dossier suit donc.
```
ssh user@your-server ls backups/photos
```

À quoi ressemble une exécution réussie

Sur le protocole natif, push affiche une ligne par fichier terminé et se termine par 0. Face à un serveur nu, il affiche une seule ligne de résumé — c'est la voie tar, et c'est aussi une réussite.

relayium push ./photos user@your-server:backups/
  photos/IMG_0413.jpg (2314518 bytes)
  photos/IMG_0414.jpg (1998233 bytes)

# against a server with no relayium installed, one summary line instead:
sent 2 file(s) (zero-dependency mode)

Il réutilise votre ~/.ssh/config, donc les alias d'hôtes, les clés et les ports déjà configurés fonctionnent tels quels.
Si relayium est installé sur le serveur, il utilise le protocole natif : reprise par fichier et vérification SHA-256 sur chaque fichier.
Sinon, il bascule sur l'envoi d'un flux tar par tube vers la machine distante, si bien qu'un serveur nu sans relayium fonctionne quand même.

Récupérer les fichiers avec pull

La restauration est la même commande en sens inverse : indiquez une source distante et un répertoire de destination local. C'est ainsi que vous récupérez une sauvegarde, ou que vous synchronisez la sortie d'un serveur vers votre portable :

relayium pull user@your-server:backups/ ./restore

Contrairement à push, pull a toujours besoin de relayium déjà installé côté distant — il n'a pas de repli tar, installez-le donc là-bas d'abord s'il manque.

Reprise et intégrité intégrées d'office

Les sauvegardes ont tendance à être volumineuses, et les réseaux ont tendance à se couper. Quand relayium est présent des deux côtés, un transfert interrompu reprend là où il s'est arrêté lors de l'exécution suivante au lieu de tout renvoyer, et chaque fichier est vérifié de bout en bout par un hachage SHA-256 — ce qui arrive sur le serveur est identique octet pour octet à ce que vous avez envoyé.

Si vous voulez un renvoi complet et propre plutôt que la reprise d'un fichier partiel, passez --no-resume.

La reprise nécessite relayium côté distant (le protocole natif) ; le repli tar envoie toujours l'intégralité.
La vérification SHA-256 s'exécute automatiquement ; une divergence est signalée et le fichier est marqué en échec.

Le planifier avec cron

Comme push est une commande unique et non interactive qui utilise vos clés SSH, elle s'intègre directement dans cron pour une sauvegarde récurrente. Pointez-la vers une clé sans phrase de passe (ou vers un agent), et journalisez la sortie pour repérer les échecs :

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

Combinée à la reprise, une tâche nocturne interrompue continue simplement la nuit suivante.
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.

Quand une sauvegarde n'arrive pas

Une sauvegarde planifiée échoue par nature en silence, puisque personne ne regarde le terminal. Ces quatre cas couvrent presque tout, et chacun se tranche par une commande que vous pouvez lancer tout de suite.

Symptôme, vérification, correction

La tâche cron reste bloquée, ou le journal s'arrête sur une demande de mot de passe.

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

BatchMode=yes refuse de demander quoi que ce soit et échoue, ce qui transforme un blocage muet en cette ligne. Ajoutez la partie publique de cette clé au fichier ~/.ssh/authorized_keys du serveur, ou pointez la tâche sur une clé que l'agent détient déjà.

La ligne de crontab s'exécute mais le journal reste vide.

command -v relayium
# /usr/local/bin/relayium

cron tourne avec un PATH minimal qui n'inclut généralement pas /usr/local/bin, donc la ligne échoue avant même que relayium démarre. Écrivez dans l'entrée crontab le chemin absolu que la vérification vient d'afficher, et gardez la redirection >> ~/relayium-backup.log 2>&1 pour que la prochaine panne soit visible.

Un transfert interrompu repart de zéro à l'exécution suivante.

ssh user@your-server command -v relayium
# (n'affiche rien)

La reprise appartient au protocole natif, et l'absence de relayium en face signifie le flux tar, qui renvoie toujours chaque fichier en entier. Installez-le sur le serveur pour obtenir la reprise par fichier, et vérifiez que vous ne passez pas --no-resume, qui la désactive volontairement.

« N file(s) failed integrity check » et un code de sortie non nul.

relayium push ./photos user@your-server:backups/
# 1 file(s) failed integrity check: [photos/IMG_0413.jpg]
echo $?
# 1

Le SHA-256 calculé à l'arrivée ne correspondait pas à celui envoyé, ce fichier n'est donc pas fiable sur le serveur. Relancez le push et regardez à nouveau le code de sortie. Si le même fichier échoue systématiquement, poussez-le seul pour distinguer une source abîmée d'un lien abîmé.

Questions fréquentes

Les fichiers passent-ils par les serveurs de Relayium ?

Non. push et pull s'exécutent entièrement sur votre propre connexion SSH. Les serveurs de Relayium ne sont jamais impliqués et aucun compte n'est nécessaire.

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

Cela dépend du sens. Pour push, c'est optionnel : avec relayium côté distant, vous obtenez le protocole natif — transferts avec reprise et vérifications SHA-256 par fichier — et sans cela, push bascule sur un flux tar via SSH, qui fonctionne toujours mais renvoie systématiquement chaque fichier en entier. Pour pull, c'est requis : pull a toujours besoin de relayium côté distant (aucun repli tar), installez-le donc là-bas au préalable.

Comment choisit-il quelle clé SSH et quel port utiliser ?

Il lit votre ~/.ssh/config comme le fait ssh, si bien que les alias d'hôtes, les clés et les ports sont repris automatiquement. Vous pouvez aussi les surcharger par commande avec -i pour le fichier d'identité et -p pour le port.

Est-ce plus rapide que rsync ?

Pour pousser vers votre propre serveur, c'est dans le même ordre de grandeur que rsync via SSH ; l'objectif n'est pas de battre rsync mais de vous offrir un seul outil qui gère aussi les transferts entre réseaux et de serveur à serveur, avec les mêmes garanties de reprise et d'intégrité.

Sauvegardez votre prochain répertoire de la manière la plus directe — via votre propre SSH, avec reprise possible, intégrité vérifiée, et gratuit.

Obtenir la CLI