Questions fréquentes

Trouvez des réponses aux questions les plus courantes sur Databasus : installation, configuration et stratégies de sauvegarde.

Pourquoi Databasus n'utilise-t-il pas le format de dump SQL brut pour les sauvegardes logiques PostgreSQL ?

Pour les sauvegardes logiques, Databasus utilise le format custom de pg_dump avec compression zstd au niveau 5 au lieu du format SQL brut, parce qu'il offre l'équilibre le plus efficace entre :

• La vitesse de création du backup
• La vitesse de restauration
• La taille des fichiers (jusqu'à 20 fois plus petits que le format SQL brut)

Cette décision a été prise après des tests et des benchmarks approfondis de différents formats de sauvegarde PostgreSQL et méthodes de compression. Vous pouvez en lire plus sur ces tests ici : PostgreSQL backups: comparing pg_dump speed in different formats and with different compression.

Databasus n'inclura pas le format de dump SQL brut, car :

• la variété superflue nuit à l'expérience ;
• elle rend le code plus difficile à maintenir ;
• le format actuel convient à 99 % des cas

Où Databasus est-il installé via le script .sh ?

Databasus est installé dans le répertoire /opt/databasus/.

Comment fonctionnent les sauvegardes physiques et PITR (Point-in-Time Recovery) ?

Databasus exécute les sauvegardes physiques à distance, depuis son propre hôte, en se connectant à votre PostgreSQL via le protocole de réplication standard, donc rien n'est à installer sur le serveur de base de données. Si la base se trouve dans un réseau fermé, Databasus peut l'atteindre par un tunnel SSH vers un hôte interne ou un bastion, si bien que la base n'a jamais besoin d'être exposée publiquement.

Comment fonctionnent les sauvegardes :

• Les sauvegardes complètes sont créées avec pg_basebackup, streamées directement vers Databasus
• Les incrémentales par blocs utilisent pg_basebackup --incremental : les résumés WAL côté serveur de PostgreSQL 17 (summarize_wal = on) suivent les changements pour ne transférer que les blocs modifiés
• Les WAL sont streamés en continu via pg_receivewal pour garder la chaîne de récupération complète entre les sauvegardes
• Les sauvegardes physiques exigent PostgreSQL 17 ou plus récent ; sur les versions antérieures, vous utilisez les sauvegardes logiques pg_dump

Comment fonctionne la restauration :

• pg_combinebackup reconstruit un répertoire de données exécutable à partir de la sauvegarde complète et de sa chaîne d'incrémentales
• PostgreSQL rejoue ensuite les WAL jusqu'à l'instant cible que vous choisissez, avec une restauration possible à n'importe quelle seconde entre deux sauvegardes
• Une fois PostgreSQL démarré, il termine la récupération, se promeut en primaire et reprend un fonctionnement normal

Pourquoi nous utilisons les sauvegardes natives de PG 17 :

• Elles réutilisent la mécanique de sauvegarde de PostgreSQL au lieu de la réinventer, vous profitez donc d'internes éprouvés, avec des milliers de tests et de cas limites derrière eux
• Elles fonctionnent avec des bases distantes, y compris les services managés comme Amazon RDS et Google Cloud SQL qui exposent le protocole de réplication mais interdisent d'installer des logiciels sur l'hôte
• Elles offrent une perte de données quasi nulle, avec une restauration possible à n'importe quelle seconde entre deux sauvegardes

Pourquoi Databasus a-t-il abandonné les sauvegardes par agent ?

Une version antérieure de Databasus fournissait un agent de sauvegarde : un binaire qui tournait sur l'hôte de la base pour streamer les WAL et créer des sauvegardes physiques en local. Cette première implémentation s'est révélée être une erreur, et nous l'avons supprimée. Les sauvegardes physiques s'exécutent maintenant à distance depuis l'hôte Databasus, comme décrit ci-dessus.

Pourquoi l'agent était la mauvaise approche :

• C'était une implémentation naïve qui ne faisait que copier les WAL par-dessus des sauvegardes complètes, avec un RTO long à la clé
• Les utilisateurs devaient configurer à la fois Databasus et un agent séparé, alors que tout faire à distance depuis un seul endroit est bien plus simple
• Comme l'agent vivait en dehors du système principal, il était difficile de couvrir tous les cas de test
• Il n'y a en réalité qu'un seul problème qu'un agent résout : atteindre une base inaccessible de l'extérieur. Pour 99 % des utilisateurs, c'est déjà réglé en exécutant Databasus dans le réseau privé ou en se connectant via SSH ; l'agent réinventait donc la roue et rendait un problème simple bien plus compliqué que nécessaire
• Il ne pouvait pas tourner sur les bases managées comme RDS et Cloud SQL, qui interdisent les installations sur l'hôte mais exposent déjà le protocole de réplication : un chemin distant était donc nécessaire de toute façon
• Il s'accompagnait aussi de nombreux cas limites. Les connexions interrompues, la gestion des mises à jour de l'agent et la collecte des journaux d'un processus séparé étaient toutes pénibles, et moins un système a de pièces mobiles, plus il est fiable au quotidien

Nous avons veillé à ce que les backups existants restent en sécurité. Si vous mettez à jour depuis une version qui a encore des sauvegardes par agent, Databasus ne le fera pas silencieusement : il vous avertit du changement et vous laisse soit rester sur la version 3.42.0 prise en charge, soit supprimer vous-même les anciennes sauvegardes par agent avant la mise à jour. L'implémentation par agent reste disponible jusqu'à la version 3.42.0 et continuera de fonctionner pendant longtemps, donc rien ne casse.

Vous pouvez lire le raisonnement complet dans les architecture decision records : ADR-0008: PG17-native backups with mandatory WAL summary et ADR-0009: remote physical backups instead of agents.

Comment l'IA est-elle utilisée dans le développement de Databasus ?

Des questions sur l'usage de l'IA dans le développement du projet ont été posées dans les issues et les discussions. Comme le projet met l'accent sur la sécurité, la fiabilité et l'usage en production, il est important d'expliquer comment l'IA intervient dans le processus de développement.

L'IA est utilisée comme assistant pour :

• Vérifier la qualité du code et rechercher des vulnérabilités
• Nettoyer et améliorer la documentation, les commentaires et le code
• Aider pendant le développement
• Revérifier les PR et les commits après relecture humaine

L'IA n'est PAS utilisée pour :

• Écrire du code entier
• L'approche "vibe code"
• Du code sans vérification ligne par ligne par un humain
• Du code sans tests

Le projet dispose de :

• Une couverture de tests solide (tests unitaires et d'intégration)
• Une automatisation CI/CD avec tests et linting pour garantir la qualité du code
• Une vérification par des développeurs aguerris, expérimentés sur de gros projets sécurisés

L'IA n'est donc qu'un assistant et un outil permettant aux développeurs de gagner en productivité et de garantir la qualité du code. Le travail est fait par les développeurs.

Il est d'ailleurs important de noter que nous ne faisons pas de différence entre du mauvais code humain et du vibe code d'IA. Des exigences strictes s'appliquent à tout code fusionné, pour garder la base de code maintenable.

Même écrit à la main par un humain, un code n'est pas garanti d'être fusionné. Le vibe code n'est pas autorisé du tout et toutes les PR de ce type sont rejetées par défaut (voir le guide de contribution).

Nous attachons aussi de l'importance à la résolution rapide des problèmes et au signalement des vulnérabilités de sécurité.

Comment sauvegarder Databasus lui-même ?

Si vous voulez sauvegarder votre instance Databasus (avec toutes les configurations, bases de données et identifiants), suivez ces étapes :

1. Allez dans /opt/databasus (ou le dossier où vous avez installé Databasus)
2. Rendez-vous dans le répertoire databasus-data

Vous devez sauvegarder :

• secret.key : la clé de chiffrement de vos identifiants
• /pgdata : la base PostgreSQL interne de Databasus qui contient toutes vos configurations et les métadonnées des backups

Si vous utilisez le stockage local pour vos backups, vous pouvez aussi sauvegarder le dossier backups.

Important : il existe deux scénarios de récupération différents :

• Récupérer les backups sans l'interface Databasus : vous pouvez récupérer vos backups de bases avec le seul fichier secret.key, sans avoir besoin de Databasus ni de ses données internes. Consultez le guide de récupération manuelle pour des instructions détaillées.
• Restaurer l'interface Databasus et toutes les configurations : pour restaurer l'interface Databasus avec toutes vos configurations, sauvegardes planifiées et historique, vous devez sauvegarder à la fois secret.key et le dossier /pgdata (qui contient les métadonnées de chiffrement et toutes les configurations Databasus).

Pour restaurer Databasus sur un autre serveur : recréez simplement la structure du dossier databasus-data avec les fichiers sauvegardés et démarrez Databasus.

Comment Databasus est-il soutenu par les programmes open source d'Anthropic et d'OpenAI ?

En mars 2026, Databasus a été accepté à la fois dans Claude for Open Source d'Anthropic et Codex for Open Source d'OpenAI. Il est très précieux pour nous que le projet ait été reconnu comme un logiciel open source important pour le secteur par deux des plus grandes entreprises d'IA au monde, d'autant plus que les critères d'éligibilité des deux programmes sont exigeants.

Qu'est-ce que cela signifie pour les utilisateurs ? C'est une confirmation de fiabilité supplémentaire : le projet a été évalué de manière indépendante et reconnu par des leaders du secteur comme une infrastructure critique méritant d'être soutenue. Nous en tirons une qualité de code encore plus élevée, des revues de sécurité plus rapides et un développement actif continu grâce à l'accès illimité aux dernières IA.

Malgré l'accès à ces programmes, Databasus maintient des règles strictes d'usage de l'IA, décrites dans la section sur l'usage de l'IA. Tout code exige une vérification humaine ligne par ligne, une couverture de tests complète et une relecture par des développeurs expérimentés. Le vibe coding n'est pas autorisé. L'IA reste un outil pour les développeurs, pas un substitut au jugement humain.