Pourquoi un outil dédié plutôt qu'un pg_dump dans une crontab
La sauvegarde la plus répandue tient en une ligne : un pg_dump lancé chaque nuit par cron, compressé dans un répertoire. Elle fonctionne jusqu'au jour où l'on découvre qu'elle échouait depuis trois semaines sans que personne ne soit prévenu, que le disque était plein, ou que le fichier ne se restaure pas faute du bon rôle.
Databasus traite précisément ces angles morts : il notifie chaque échec, applique une politique de rétention, envoie les copies hors de la machine, et prouve qu'elles se restaurent. Pour PostgreSQL, il ajoute ce qu'un dump ne sait pas faire : des sauvegardes physiques incrémentales et le flux WAL, qui permettent de revenir à la minute près avant une erreur.
Ce que Databasus apporte
- PostgreSQL physique et logique — sauvegardes complètes, incrémentales, flux WAL et restauration à un instant donné (PITR).
- MySQL, MariaDB, MongoDB — sauvegardes logiques compressées depuis la même interface.
- Planification fine — horaire, quotidienne, hebdomadaire, mensuelle ou expression cron.
- Restauration vérifiée — restauration réelle dans une base temporaire et rapport par table.
- Stockages multiples — disque local, S3, Cloudflare R2, Google Drive, SFTP, Rclone.
- Chiffrement AES-256-GCM — fichiers illisibles même sur un stockage partagé.
- Équipe — espaces de travail, rôles, journal d'audit et notifications e-mail, Telegram, Slack ou webhook.
Databasus face aux méthodes courantes
Faites défiler le tableau
| Databasus | pg_dump + cron | Instantané du VPS | |
|---|---|---|---|
| Alerte en cas d'échec | Oui, plusieurs canaux | À écrire soi-même | Selon l'hébergeur |
| Restauration à un instant donné | Oui (flux WAL) | Non | Non, seulement l'heure de l'instantané |
| Copie hors de la machine | S3, R2, SFTP, Drive… | À scripter | Chez l'hébergeur |
| Restauration vérifiée | Automatique, avec rapport | Manuelle | Manuelle |
| Granularité | Par base | Par base | Le disque entier |
| Interface et équipe | Oui, rôles et audit | Non | Console de l'hébergeur |
Prérequis
Un VPS Ubuntu 24.04 avec 1 Go de RAM suffit pour piloter les sauvegardes ; prévoyez de l'espace disque si vous gardez des copies en local, ou un bucket S3 ou R2 pour les envoyer ailleurs. Il vous faut Docker et le plugin Compose. Côté bases, vous aurez besoin d'un accès réseau depuis le VPS et d'un utilisateur dédié aux sauvegardes.
Si vos bases tournent sur d'autres serveurs, ouvrez leur port uniquement à l'adresse IP du VPS Databasus, jamais à tout Internet : un pare-feu qui n'accepte que cette source réduit l'exposition à une seule machine, que vous contrôlez. Pour une base sur le même VPS, aucune ouverture de port vers l'extérieur n'est nécessaire.
Installer Databasus avec Docker Compose
Créer le fichier Compose
Créez un répertoire
/opt/databasuset placez-y cedocker-compose.yml. Le port n'est publié que sur la boucle locale, etextra_hostspermet au conteneur de joindre une base installée sur le VPS lui-même par le nomhost.docker.internal.services: databasus: image: databasus/databasus:v3.62.0 restart: unless-stopped ports: - "127.0.0.1:4005:4005" extra_hosts: - "host.docker.internal:host-gateway" volumes: - databasus-data:/databasus-data volumes: databasus-data: {}Démarrer le conteneur
Lancez Databasus et suivez son démarrage :
docker compose up -d docker compose logs -f databasusAu premier lancement, l'image initialise sa propre base de métadonnées et applique ses migrations dans le volume
databasus-data. La lignehttp server listening on :4005indique qu'il est prêt, en quelques secondes.Ouvrir l'interface et créer le compte
Depuis votre poste, ouvrez un tunnel SSH vers le VPS :
ssh -L 4005:127.0.0.1:4005 root@<ip-vps>Rendez-vous ensuite sur http://localhost:4005 et créez votre compte : le premier compte créé devient administrateur. Les inscriptions suivantes restent ouvertes par défaut avec un rôle de membre : désactivez les inscriptions externes dans les paramètres.
Déclarer une base PostgreSQL
Créez sur le serveur PostgreSQL un rôle dédié, qui ne peut que lire :
CREATE ROLE databasus WITH LOGIN PASSWORD 'un-mot-de-passe-long'; GRANT pg_read_all_data TO databasus;Dans Databasus, ajoutez la base avec son hôte (pour une base du même VPS :
host.docker.internal), son port, ce rôle et son mot de passe, puis une destination de stockage et une planification. Lancez une première sauvegarde à la main pour vérifier qu'elle va au bout.
Une copie hors du VPS, toujours
Une sauvegarde gardée sur le disque du serveur protège contre un DROP TABLE malheureux, pas contre la perte de la machine. Ajoutez au moins une destination externe — un bucket S3 ou R2 — et activez le chiffrement : le fichier reste alors inutilisable pour qui y accéderait sans la clé.
Choisir une politique de rétention
Databasus propose quatre façons de borner l'historique : une durée (garder sept jours, trois mois, un an), un nombre (les trente dernières), une rotation GFS (grand-père, père, fils : des copies horaires, quotidiennes, hebdomadaires, mensuelles et annuelles conservées indépendamment) et des plafonds de taille, par sauvegarde et au total.
Pour une application en production, un bon point de départ est une sauvegarde quotidienne gardée trente jours, complétée par une rotation GFS mensuelle sur un an, et un plafond de taille total qui empêche le stockage de déborder. Ajoutez le flux WAL si une perte d'une journée de données est inacceptable.
Vérifier que la restauration fonctionne
C'est la fonctionnalité qui distingue Databasus. Après chaque sauvegarde, ou selon un calendrier, il démarre une base temporaire, y restaure la copie, compare la taille obtenue à celle de la sauvegarde et liste chaque table avec son nombre de lignes. Le rapport peut vous être envoyé, ou seulement les échecs.
Programmez au minimum une vérification hebdomadaire de la base la plus importante. Le jour d'un incident, vous ne découvrirez pas qu'il manquait une extension ou un rôle : la vérification l'aura dit des semaines plus tôt.
Gardez aussi une trace de ces rapports : ils constituent la preuve, datée, que votre plan de reprise a été exercé. C'est souvent la première question d'un client ou d'un auditeur après un incident, et la réponse « nous restaurons chaque semaine, voici les rapports » clôt la discussion.
Dépannage
La connexion à une base du même VPS échoue. Le serveur de base n'écoute que sur 127.0.0.1 : ajoutez l'interface du réseau Docker à listen_addresses (PostgreSQL) ou à bind-address (MySQL), autorisez le sous-réseau Docker dans pg_hba.conf, puis redémarrez le service.
Une sauvegarde vers S3 échoue. Vérifiez la région, le nom du bucket et les droits de la clé d'accès : elle doit pouvoir écrire, lister et supprimer les objets du préfixe choisi, sans quoi la rétention ne peut pas purger les anciennes copies.
Aucune notification n'arrive. Testez le canal depuis sa page de configuration ; pour l'e-mail, un serveur SMTP doit être renseigné dans les paramètres.
L'interface ne répond plus. Lisez les journaux avec docker compose logs --tail 100 databasus : chaque tâche de fond y est journalisée au démarrage.
Installation en un clic depuis le Marketplace ServOrbit
Le Marketplace ServOrbit installe Databasus sur votre VPS sans ligne de commande : il déploie le conteneur avec l'accès host.docker.internal déjà déclaré, publie le port sur la boucle locale et vous indique dans l'espace client le port à utiliser pour le tunnel SSH. Vous pouvez aussi lui attacher un domaine pour un accès permanent en HTTPS.
