Vykar : sauvegarde chiffrée et dédupliquée pour homelab, écrite en Rust

Sauvegarder un homelab vers du stockage objet suppose en général de choisir entre Borg (dédup et chiffrement solides, mais lent) et Restic (plus rapide, écosystème plus large). Vykar, un nouveau venu en Rust, tente de prendre le meilleur des deux sans les compromis historiques — au prix d’une maturité encore limitée.

Ce que fait Vykar

Vykar est un outil de sauvegarde en ligne de commande qui stocke des snapshots versionnés de répertoires dans un dépôt chiffré, avec déduplication par découpage en blocs à contenu variable (FastCDC). Il est développé par l’équipe de BorgBase, l’hébergeur de dépôts Borg/Restic actif depuis près de dix ans — le projet revendique s’inspirer de BorgBackup, Borgmatic, Restic et Rustic, mais utilise son propre format de dépôt, incompatible avec les trois.

Toute la configuration tient dans un seul fichier YAML : sources à sauvegarder, dépôts cibles, chiffrement, compression, exclusions, rétention et planification. Le binaire unique gère aussi bien le backup ponctuel qu’un mode démon avec scheduling intégré (pas besoin de cron), plusieurs machines peuvent écrire dans le même dépôt en parallèle (seule la phase de commit est sérialisée), et un serveur WebDAV local permet de parcourir les snapshots sans les extraire.

À noter avant tout : le projet est en statut bêta et les mainteneurs déconseillent explicitement de l’utiliser en production pour l’instant — recommandation à prendre au sérieux pour un outil de sauvegarde.

Installation

# Linux / macOS — script d'installation officiel
curl -fsSL https://vykar.borgbase.com/install.sh | sh

# Depuis un binaire précompilé (releases GitHub)
tar xzf vykar-*.tar.gz
sudo cp vykar /usr/local/bin/

# Depuis les sources (nécessite Rust 1.88+)
git clone https://github.com/borgbase/vykar.git
cd vykar
cargo build --release
cp target/release/vykar /usr/local/bin/

# Docker
docker pull ghcr.io/borgbase/vykar

# Ansible
ansible-galaxy role install borgbase.vykar

# Windows — binaire précompilé
Expand-Archive vykar-*.zip -DestinationPath .
Move-Item .\vykar.exe "$env:USERPROFILE\bin\vykar.exe"

Des binaires précompilés existent pour Linux (x86_64/aarch64, glibc et musl), macOS Apple Silicon et Windows. Dernière version publiée au moment de la rédaction : v0.19.1 (juillet 2026, patch centré sur macOS — pas de changement fonctionnel pour Linux/Windows).

Configuration YAML

vykar config génère un fichier de départ à éditer. Configuration minimale :

repositories:
  - url: "/backup/repo"

sources:
  - "/home/user/documents"

Une configuration plus complète pour un homelab, avec dépôt distant, chiffrement explicite, compression, rétention et planification :

repositories:
  - label: "b2"
    url: "s3://s3.us-west-002.backblazeb2.com/mon-bucket/vykar"
    region: "us-west-002"
    access_key_id: "0012xxxx"
    secret_access_key: "K002xxxx"

sources:
  - label: "docker-volumes"
    path: "/srv/docker"
    exclude: ["*.tmp", ".cache/**"]
    retention:
      keep_daily: 7
      keep_weekly: 4
      keep_monthly: 6

encryption:
  mode: "chacha20poly1305"
  passcommand: "pass show vykar-homelab"

compression:
  algorithm: "zstd"
  zstd_level: 6

schedule:
  enabled: true
  every: "6h"
  on_startup: true

hooks:
  failed: "notify-send 'vykar backup failed'"

Le chiffrement est activé par défaut (mode auto, dérivation de clé Argon2id) et repose sur AES-256-GCM ou ChaCha20-Poly1305 selon la configuration. La compression LZ4 (par défaut) privilégie la vitesse ; Zstandard est disponible pour un meilleur ratio.

Backends de stockage supportés

Le backend est déterminé par le format de l’URL du dépôt :

# Local
repositories:
  - label: "local"
    url: "/backups/repo"

# S3 / compatible (AWS, Backblaze B2, Hetzner, MinIO...)
repositories:
  - label: "s3"
    url: "s3://s3.us-east-1.amazonaws.com/my-bucket/vykar"
    region: "us-east-1"
    access_key_id: "AKIA..."
    secret_access_key: "..."

# SFTP (implémentation SSH pure Rust)
repositories:
  - label: "nas"
    url: "sftp://backup@nas.local/backups/vykar"
    sftp_key: "/home/user/.ssh/id_rsa"
    sftp_known_hosts: "/home/user/.ssh/known_hosts"

# Serveur REST dédié (vykar-server)
repositories:
  - label: "server"
    url: "https://backup.example.com"
    access_token: "my-secret-token"

Le backend S3 gère l’upload multipart au-delà de 16 MiB, le S3 Object Lock (append-only pour se protéger d’un ransomware) et un mode s3_soft_delete: true qui remplace les suppressions par des tombstones vides — utile pour limiter les permissions IAM à PutObject/GetObject/ListBucket. Le HTTP simple est bloqué par défaut ; il faut allow_insecure_http: true pour l’autoriser explicitement sur un réseau de confiance. Backblaze B2, Hetzner Object Storage et MinIO sont utilisables comme n’importe quel endpoint S3-compatible via ce même backend s3://.

Utilisation courante

# Initialiser le dépôt défini dans la config
vykar init

# Lancer un cycle de sauvegarde
vykar backup

# Lister les snapshots existants
vykar list

# Explorer le contenu d'un snapshot
vykar snapshot list a1b2c3d4

# Rechercher un fichier dans l'historique
vykar snapshot find --name '*.txt' --since 7d

# Restaurer un snapshot vers un répertoire
vykar restore a1b2c3d4 /tmp/restored

# Parcourir les snapshots via WebDAV + interface web intégrée
vykar mount

+ Les points forts

• Rapide — dans les benchmarks publiés par l’équipe Vykar elle-même (49 GiB, 367 000 fichiers), Vykar termine devant Restic, Borg et Kopia en temps de backup et de restauration, avec une consommation CPU nettement inférieure à Restic
• Configuration unifiée — un seul fichier YAML pour sources, dépôts, chiffrement, rétention et planification, plutôt qu’une CLI + un fichier de scheduling séparé (à la Borgmatic)
• Backends flexibles — S3 et compatibles (Backblaze B2, Hetzner, MinIO), SFTP en Rust pur, serveur REST dédié ou stockage local
• Multi-clients concurrents — plusieurs machines peuvent écrire dans le même dépôt sans conflit
• Licence libre — GPL-3.0, code source ouvert

- Les points faibles

• Statut bêta assumé — les mainteneurs déconseillent eux-mêmes une utilisation en production actuellement ; c’est un point bloquant pour un outil dont la seule raison d’être est la fiabilité des sauvegardes
• Benchmarks non indépendants — les chiffres de performance mis en avant proviennent de l’équipe du projet, pas d’un tiers ; à vérifier soi-même avant d’en tirer des conclusions définitives
• Format propriétaire et récent — dépôt incompatible avec Borg ou Restic, pas d’historique de robustesse en conditions réelles comparable à ces deux projets qui ont des années de production derrière eux
• Écosystème jeune — pas encore d’équivalent aux intégrations tierces mûres de Restic (rest-server largement éprouvé, intégrations backup-as-a-service multiples)
• Consommation mémoire plus élevée — supérieure à Borg et Restic sur les benchmarks publiés, à surveiller sur un homelab aux ressources limitées

Vykar vs Restic vs BorgBackup

	Vykar	Restic	BorgBackup
Langage	Rust	Go	Python/C
Licence	GPL-3.0	BSD-2	BSD-3
Configuration	Fichier YAML unique	Flags CLI (+ wrapper externe pour scheduling)	Flags CLI (Borgmatic pour le YAML)
Déduplication	FastCDC (CDC)	Rabin CDC	Rolling hash CDC
Chiffrement	AES-256-GCM / ChaCha20-Poly1305, Argon2id	AES-256, scrypt	AES-256-CTR + HMAC
Backends	Local, S3/compatible, SFTP, REST dédié	Local, S3, B2, SFTP, REST, et plus	Local, SFTP (via BorgBase, rsync.net…)
Multi-clients concurrents	✅	Limité	❌ (verrouillage exclusif)
GUI native	✅ (Slint)	❌ (tiers)	❌ (tiers, ex. Vorta)
Maturité en production	⚠️ Bêta, déconseillé	✅ Éprouvé	✅ Éprouvé (10+ ans)

En résumé

Vykar est un projet prometteur pour qui veut tester une alternative moderne en Rust à Borg/Restic sur un homelab, avec une configuration YAML plus lisible et des performances annoncées supérieures. Mais pour la seule chose qui compte vraiment dans un outil de sauvegarde — la fiabilité éprouvée — Restic et BorgBackup restent le choix par défaut : ils tournent en production depuis des années et leurs formats de dépôt ont survécu à l’épreuve du temps. Vykar mérite d’être testé en parallèle d’une solution existante, pas de la remplacer tant que le projet reste en bêta.

---

Voir aussi :

• rclone — synchroniser des fichiers vers le cloud, sans déduplication ni versioning (complémentaire, pas un substitut à un vrai outil de backup)
• Uptime Kuma — surveiller que vos cycles de sauvegarde planifiés s’exécutent bien