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 kDrive
1485489 (
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)
Taille
489 Mo par nuit (1 760 entrées)
Durée
34 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.