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

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

Pousser (push) un répertoire vers votre serveur

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 :

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

2. Déterminez le protocole que vous obtiendrez. Un chemin annonce le protocole natif — contrôle de collision en amont et SHA-256 par fichier ; aucune sortie annonce le flux tar, qui ne vérifie rien fichier par fichier.

   ssh user@your-server command -v relayium

3. 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/

4. 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/

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

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 : tout le lot est contrôlé pour les collisions avant le moindre octet, et chaque fichier transféré est vérifié par SHA-256 puis mis en place.
• 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.

L'intégrité est intégrée d'office — la reprise, non

Quand relayium est présent des deux côtés, chaque fichier que push transfère est vérifié de bout en bout par un hachage SHA-256 et placé en zone d'attente avant d'être installé — ce qui arrive sur le serveur est identique octet pour octet à ce que vous avez envoyé. Cela, c'est réel, et c'est la raison d'installer relayium sur la destination.

Ce que push ne fait pas, c'est reprendre. Les fichiers sont installés un à un au fur et à mesure, donc une coupure en cours de route laisse en place ceux qui sont déjà arrivés — et comme ils existent désormais, relancer le même push est refusé par le contrôle de collision au lieu de continuer. Poussez explicitement les chemins manquants, ou utilisez relayium sync, le mode qui saute ce qui correspond déjà et qui, lui, poursuit un fichier partiel lors d'une exécution ultérieure.

--no-resume est accepté par push et pull et n'y fait rien. Il est réel sur un processus serve à l'écoute qui reçoit un sync — c'est le seul endroit où un fichier partiel peut exister.

• Ni push ni pull ne reprend, dans aucun des deux protocoles. Utilisez sync pour un répertoire que vous vous attendez à voir interrompu ; le repli tar, lui, ne reprend rien et ne vérifie rien fichier par fichier.
• 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

Planifiez sync, pas push. push refuse une destination qui existe déjà, donc un push nocturne vers le même répertoire réussit une fois et est refusé toutes les nuits suivantes. sync est le mode conçu pour une exécution répétée : il saute les fichiers dont la taille et la date de modification n'ont pas changé, n'envoie que ce qui a changé, et poursuit un fichier partiel laissé par une exécution interrompue. C'est une commande unique et non interactive qui utilise vos clés SSH, donc elle s'intègre directement dans cron. 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 sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

• Un sync nocturne interrompu continue simplement la nuit suivante : ce qui correspond déjà est sauté, et un fichier partiel est poursuivi plutôt que repris de zéro.
• 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.