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 écrasen'est lepas fichieraccepté existantpar dekDrive même— nom.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=replaceversion. 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

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) Fichierdocuments_day{1-7}.7z, rotation hebdomadaire comme les autres 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.

    Back to top