Skip to main content

A_liens entre Claude et le KDRIVE

kDrive API REST — Infomaniak

Paramètre Valeur
Drive ID 591617
Token Bearer cnAZannhRpecgAfsQM7QiO4Vqh37g6Ht_hm4f0E6eDihMRaP2ZckKCmW959T5ST2Nv3qhGlqs0ltpNAb
Base URL https://api.infomaniak.com/3/drive/591617

Endpoints fonctionnels

Méthode Endpoint Usage
GET /files/{dir_id}/files Lister le contenu d'un dossier
GET /files/{file_id} Métadonnées d'un fichier
POST /upload?directory_id={id}&file_name={name}&conflict=replace&total_size={bytes} Uploader un fichier. ⚠ conflict=replace n'est pas accepté par kDrive — l'API répond 422 en silence et l'upload est perdu. C'est ce qui avait cassé toutes les sauvegardes du 2026-06-12 au 2026-06-19. conflict=version crée une nouvelle version.

Recovery automatique FUSE — monitor-rclone.sh (2026-06-24)

Le script /home/debian/monitor-rclone.sh (cron */5 * * * *) surveille les 5 mounts rclone et effectue une recovery complète si l'un d'eux est mort.

Fonctionnement

Pour chaque mount (/music, /komga, /livres, /audiobookshelf/audiobooks, /photo) :

timeout 10 ls — si inaccessible : sudo systemctl restart (kdrive-music, kdrive-komga, kdrive-livres, rclone-audiobooks, rclone-photo) Attente 5s + vérification que le mount répond Restart des containers Docker associés : /music → navidrome-navidrome-1 /komga → komga /livres → Kavita /audiobookshelf/audiobooks → audiobookshelf /photo → Immich-SERVER Immich-MICROSERVICES

Le script est silencieux quand tout va bien — il ne logue que les pannes et recoveries. Log : /home/debian/logs/rclone-monitor.log

Avant cette refactorisation, le script lançait un rclone mount direct (en parallèle des services systemd) et ne redémarrait pas les containers — le FUSE était remonté mais Navidrome gardait l'ancienne référence corrompue.

Suppression de fichiers — non fonctionnelle (testé 2026-06-09)

Tous les endpoints suivants retournent {"result":"error","error":{"code":"method_not_found"}} :

  • DELETE /files/{file_id}
  • POST /files/trash avec body {"file_ids":[id]}
  • POST /files/trash avec body {"ids":[id]}
  • POST /files/{file_id}/trash
  • PUT /files/{file_id} avec {"deleted":true}
  • DELETE /files avec body {"ids":[id]}

La doc officielle (developer.infomaniak.com) n'est pas accessible publiquement. L'endpoint de suppression reste inconnu.

Stratégie de rétention — rotation par jour de la semaine

Puisque la suppression via API ne fonctionne pas, le script de backup utilise une rotation par jour de la semaine (date +%u → 1=lundi … 7=dimanche) avec conflict=version. Résultat : exactement 7 fichiers max par service, les anciens sont écrasés automatiquement chaque semaine.

Script : /opt/backups/vps_backup.sh — cron : 0 2 * * *

Dossiers kDrive (TOOJUX/jux_vps)

Service Dossier ID Exemple de fichier
BookStack 1427916 bookstack_db_day1.7z
Immich 1427919 immich_db_day1.7z
Joplin 1427920 joplin_db_day1.7z (~630 Mo)
Mealie 1427921 mealie_db_day1.7z
Readeck 1427922 readeck_db_day1.7z
Baïkal 1467771 baikal_day1.7z (contacts + agendas + config)
Documents (dossier Syncthing) 1485489 documents_day1.7z (~489 Mo) — ajouté le 2026-08-30
Documents — mensuel 1486390 documents_month01.7z à month12.7z — année glissante

Télécharger un fichier depuis kDrive — il faut suivre la redirection (2026-08-30)

Point découvert en testant la restauration d'une sauvegarde. L'endpoint de téléchargement est en API v2, pas v3, et il répond 302 vers un hôte séparé (*.download.kdrive.infomaniakusercontent.com) :

curl -sL -H "Authorization: Bearer $TOKEN" -o archive.7z \
  "https://api.infomaniak.com/2/drive/591617/files/{file_id}/download"
  • Sans -L, on obtient un fichier de 0 octet et aucune erreur — le piège est silencieux et fait croire à une sauvegarde corrompue.
  • La variante v3 (/3/drive/…/download) répond 404 : l'upload est en v3, le téléchargement en v2.
  • Débit mesuré VPS → kDrive : 489 Mo téléversés en 6 s (~80 Mo/s).

Sauvegarde du dossier Syncthing ~/Documents (2026-08-30)

Septième service ajouté à /opt/backups/vps_backup.sh. Le détail du pourquoi est sur la page 23_Syncthing ; ici, le côté kDrive :

Dossier kDrive1485489 (backups/documents)
Fichier (quotidien)documents_day{1-7}.7z, rotation hebdomadaire comme les autres
Fichier (mensuel)documents_month{01-12}.7z dans le sous-dossier mensuel (1486390) Taille489 Mo par nuit (1 760 entrées) Durée34 s au total (26 s de compression, 6 s d'upload) Niveau 7z-mx=1 et non -mx=5

Pourquoi -mx=1 : 73 % du volume est le coffre Cryptomator « Vault 2603 » (fichiers .c9r), déjà chiffré donc incompressible. Mesuré : -mx=1 rend 2,9 % en 44 s. Monter le niveau coûterait des minutes de CPU pour un gain nul.

Pourquoi une archive et pas un rclone sync : le remote kdrive: est un WebDAV vendor = other — rclone backend features kdrive: renvoie Hashes: [] et une Precision de 100 ans, autrement dit ni empreinte ni date de modification exploitables. rclone n'y compare que les tailles et raterait toute modification à taille constante — typiquement un bloc de coffre Cryptomator réécrit. L'archive monolithique supprime cette dépendance.

Restauration vérifiée de bout en bout le 2026-08-30 : archive re-téléchargée depuis kDrive, 7z t → Everything is Ok, tar extrait (1 760 entrées, masterkey.cryptomator présent), et un fichier témoin comparé à la source — identique à l'octet près.

Profondeur de rétention — copie mensuelle sur un an (2026-08-30)

La rotation par jour de la semaine ne donne que 7 jours de recul : une suppression repérée au bout de huit jours était perdue. Une seconde copie a donc été ajoutée, sur le même principe de nom qui revient — puisque la suppression via l'API kDrive ne fonctionne pas (voir plus haut), on ne purge pas, on écrase un nom déjà pris.

    date +%d vaut 01 → on produit documents_month$(date +%m).7z dans le dossier 1486390. Les autres jours, la fonction sort en succès sans rien faire (ligne « Ignore : copie mensuelle seulement le 1er du mois » au journal), pour ne pas inscrire un faux échec au bilan de fin de log. Au bout d'un an, month08 est écrasé par le mois d'août suivant : la fenêtre reste glissante sans aucune purge.

    Coût réel : 12 × 489 Mo ≈ 5,9 Go — et non 1,5 Go comme estimé de tête au moment de la décision. kDrive avait 2,0 To libres à cette date, la question ne se pose donc pas.

    Le tar est produit par une fonction commune documents_tar(), appelée par les deux copies. Le 1er du mois l'archive est donc construite deux fois (~33 s de plus) : c'est le prix de l'indépendance des deux séries — un échec du quotidien n'empêche pas le mensuel.

    Back to top