> ## Documentation Index > Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt > Use this file to discover all available pages before exploring further. # Boîtes & stockage > Ce qui vit où sur le disque : la base SQLite, le répertoire de blobs adressé par contenu, l'index de recherche ; les quotas, la corbeille et la restauration, les fenêtres de rétention, et les commandes de maintenance du stockage. Une instance OxiMail stocke tout à trois endroits, tous sous votre contrôle : | Emplacement (défauts) | Contenu | Clé de configuration | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | | `/var/lib/oximail/data.db` | La base SQLite : dossiers, métadonnées de messages, drapeaux, contacts, événements, tâches, le journal de changements, tout le structuré. Chiffrée en SQLCipher. | `[storage] sqlite_path` | | `/var/lib/oximail/blobs/` | Le blob store adressé par contenu : messages bruts, pièces jointes, contenu du drive. Chiffré selon le [modèle au repos](./encryption-at-rest). | `[storage] blob_path` | | le répertoire d'index de recherche | L'index plein texte Tantivy. Reconstructible à tout moment depuis les deux autres. | `[storage] search_path` | Plus `/etc/oximail/` : la configuration, les clés DKIM, et le **matériel de clés** sans lequel les deux stockages de données ne sont que du chiffré. Les trois emplacements de données plus `/etc/oximail` forment la surface de sauvegarde complète ([exploitation](./operations)). ## Comment le courrier est rangé Un message est stocké **une fois, sous deux formes** (ADR-009) : les octets bruts RFC 5322 comme blob, et les métadonnées analysées (en-têtes, structure, `hasAttachment`, aperçu, fil) comme lignes. Rien n'est ré-analysé à la lecture. Les blobs sont adressés par le SHA-256 de leur clair : une pièce jointe envoyée à dix collègues est stockée une fois par organisation. La déduplication opère sous le niveau des boîtes, et deux copies d'un message dans deux boîtes sont toujours deux lignes de métadonnées pointant vers un blob (jamais de déduplication au niveau du message : cette classe de bug est exclue par construction). Le répertoire de blobs est cloisonné par organisation et par compte (`{tenant}/{compte}/...`, avec une zone réservée `_tenant/` pour le contenu d'organisation) : c'est ce qui rend la crypto-suppression par compte et l'isolation par organisation physiques plutôt que logiques. ## Les dossiers Les dossiers sont des Mailboxes JMAP avec les rôles RFC 8621 (`inbox`, `sent`, `drafts`, `trash`, `junk`, `archive`), provisionnés par compte dans la langue du compte. La hiérarchie, les compteurs par dossier et le partage (`shareWith`) sont des données. La passerelle IMAP montre le même arbre. Les dossiers en double laissés par d'anciens imports se réparent avec `oximail account dedupe-folders` ([migration](./migration)). ## Corbeille, restauration et rétention La destruction est **en deux temps avec une corbeille visible** (ADR-035) : un objet détruit atterrit dans `deleted_items` et peut être restauré. C'est ce qui soutient les corbeilles de tous les clients et la récupération des ressources DAV détruites. Indépendamment de la corbeille utilisateur, deux fenêtres de rétention comptent en exploitation : * **`change_log` : 90 jours.** L'historique de synchronisation incrémentale (`/changes`, `sync-collection`) est élagué au-delà de 90 jours ; un client absent plus longtemps fait une resynchronisation complète au lieu d'une incrémentale. C'est voulu : le journal de changements est un mécanisme de synchronisation, pas une piste d'audit. * **`audit_log` : des années.** La piste d'audit administrative a son propre horizon long, avec un worker de rétention qui l'applique ([conformité](./compliance)). Le ramasse-miettes des blobs supprime les blobs que plus aucune ligne ne référence, avec un suivi de références qui inclut les détenteurs non évidents comme l'historique d'édition : le GC n'orpheline jamais un contenu que quelque chose peut encore afficher. ## Les quotas * **Par compte** : `oximail account quota --account --mb ` (0 = pas de limite par compte). Exposé aux clients via `Quota/get`. * **Par collection** : des plafonds de volume (ADR-072) bornent la croissance de chaque collection. * **Les plafonds de capacité du chat** sont à part ([multi-tenant](./multi-tenancy)). ## L'index de recherche est jetable L'index Tantivy ne porte aucune donnée primaire. S'il est perdu, corrompu, ou si vous changez son stockage, reconstruisez-le : ```bash theme={null} oximail reindex --config /etc/oximail/oximail.toml ... ``` La réindexation fait passer chaque message par la même extraction qu'à l'ingestion ; une file d'arrière-plan fait converger le travail. À noter : l'index est le seul stockage dont le contenu n'est **pas** chiffré par compte (il doit être découpé en jetons côté serveur pour être interrogeable), et c'est pourquoi l'effacement de compte le balaie explicitement. ## Maintenance de la base Aucune planifiée, et c'est voulu. Le checkpoint du WAL est automatique (borné vers 64 Mio, checkpoint à l'arrêt), les statistiques du planificateur de requêtes sont rafraîchies après les migrations, et le pool de connexions n'a pas besoin de réglage en dessous de quelques centaines d'utilisateurs simultanés (`[storage] pool_size`, 32 par défaut, à augmenter sur une machine chargée en lecture). L'histoire opérationnelle de la base tient en trois points : garder de l'espace disque, garder des [sauvegardes](./operations), et laisser le serveur tourner. `oximail sql` existe comme échappatoire gardée pour les scénarios de support ; l'inspection au quotidien passe par les verbes CLI (`oximail mailbox`, `oximail email`) et par les vues de données par compte de l'API d'administration.