Stockage objet

Déposer des fichiers dans des buckets, répartis et chiffrés sur les nodes ecloudserv.

Un bucket est un espace de noms isolé pour tes fichiers : médias, exports, sauvegardes applicatives. Il se gère depuis Stockage objet.

Où sont réellement tes fichiers#

Le stockage n'est pas sous-traité à un fournisseur externe : chaque fichier est découpé en morceaux, chiffré, puis recopié sur plusieurs nodes ecloudserv. Deux exemplaires par défaut, sur deux machines différentes.

Un node qui tombe ne coupe rien : le fichier reste servi depuis l'autre exemplaire, et la plateforme en refabrique un troisième ailleurs.
Les nodes ne stockent que du chiffré (AES-256-GCM). Le disque d'une machine, pris isolément, ne dit rien du contenu.
Une modification d'un octet sur un node ne peut pas passer inaperçue : l'étiquette d'authentification ne colle plus, et la lecture bascule sur un autre exemplaire.

Créer un bucket#

Le nom fait 3 à 50 caractères : minuscules, chiffres et tirets. Il est unique à ton compte, pas à la plateforme entière — deux clients peuvent avoir un bucket medias.

Lecture publique#

Un bucket privé (le défaut) ne se télécharge qu'avec ta session ou ta clé d'API. En lecture publique, ses objets sont servis sans authentification à une adresse de la forme https://api.ecloudserv.fr/storage/public/<bucket>/<clé>.

À réserver à ce qui est destiné à être public

Images, polices, ressources d'un site. Tout ce qui touche à des données de tes utilisateurs doit rester privé : un objet public est lisible par quiconque connaît son URL, sans authentification.

Envoyer des fichiers#

Depuis l'interface : bouton d'envoi, ou glisser-déposer sur la liste. Une barre de progression suit le transfert, qui passe par l'API — c'est elle qui chiffre le contenu avant qu'il ne touche le moindre disque.

Le fichier est lu au fil de l'eau : sa taille n'est pas limitée par la mémoire de l'API, seulement par le plafond réglé par la plateforme (1 Go par défaut).
Réutiliser une clé existante remplace l'objet. L'ancien n'est retiré qu'une fois le nouveau écrit en entier.

Depuis un script#

Un seul appel : un PUT avec le fichier en corps de requête. La clé de l'objet se donne en paramètre d'URL.

envoi et téléchargement

# envoyer
curl -X PUT -H "Authorization: Bearer TA_CLE" \
  -H "Content-Type: application/pdf" \
  --upload-file rapport.pdf \
  "https://api.ecloudserv.fr/storage/buckets/<id-du-bucket>/objects?key=rapports/2026-08.pdf"

# relire
curl -H "Authorization: Bearer TA_CLE" -o rapport.pdf \
  "https://api.ecloudserv.fr/storage/buckets/<id-du-bucket>/download?key=rapports/2026-08.pdf"

L'isolement ne repose pas sur la confiance

Tu n'envoies jamais que l'identifiant du bucket et la clé de l'objet. Le rattachement au compte propriétaire est fait côté serveur, et une clé qui tenterait de remonter d'un dossier (../) est refusée avant d'atteindre quoi que ce soit.

États d'un objet#

En cours — reçu et conservé par la plateforme, les nodes n'en ont pas encore pris copie. Le fichier est déjà lisible et n'est pas en danger.
Réparti — le nombre d'exemplaires demandé est atteint, et l'API a vérifié qu'elle savait le relire depuis un node.
Fragile — il manque des exemplaires (un node ne répond plus). La plateforme en replace un automatiquement dès qu'une machine est disponible.

Le bouton i d'une ligne montre, node par node, où se trouvent les octets.

Quotas#

L'espace est celui de ton offre, partagé avec les sauvegardes hors-site. La page affiche l'occupation réelle, calculée à partir des objets eux-mêmes : rien n'est estimé.

Voir aussi Clés d'API pour automatiser, et Sécurité pour les sauvegardes.