Sauvegarde de base OpenShip : hébergée ou autonome ?

Choisissez la sauvegarde de base OpenShip hébergée si votre équipe ne peut pas surveiller et tester régulièrement la reprise ; choisissez l’option autonome uniquement si vous maîtrisez déjà PostgreSQL, le stockage isolé, les secrets et les exercices de restauration. La formule hybride convient lorsque vous voulez conserver les données sensibles sous votre contrôle tout en déléguant une partie de l’exploitation.

Cette analyse s’adresse à trois profils : les développeurs qui font passer un prototype en production, les petites équipes qui doivent préserver les sessions d’Agent, les fichiers utilisateurs et l’état métier, ainsi que les responsables techniques qui arbitrent entre service hébergé et serveur administré en interne.

1. Cartographier la responsabilité avant le prix

Le premier piège consiste à considérer OpenShip comme un système de sauvegarde uniforme. La responsabilité change selon la forme de déploiement. La documentation officielle distingue l’environnement hébergé, les serveurs que vous contrôlez et une approche hybride ; elle présente notamment PostgreSQL, Redis et le stockage objet comme des services distincts à intégrer dans l’architecture. La présentation officielle des formes de déploiement OpenShip doit donc être lue avant toute comparaison de coûts.

Pour la version hébergée, la page tarifaire indique actuellement que les offres sont suspendues, que les tarifs Cloud ne sont pas encore annoncés et que les sauvegardes sont prévues dans l’offre managée. Le même document mentionne des sauvegardes quotidiennes et la récupération à un instant donné comme capacités annoncées, mais cela ne donne ni un prix, ni une durée de conservation, ni un engagement contractuel complet. La page officielle des plans et de leur disponibilité est la référence à vérifier avant un achat.

Dans une installation autonome, vous devez au contraire répondre vous-même à plusieurs questions :

• Où est écrit le fichier de sauvegarde ?
• Le stockage se trouve-t-il sur une autre machine ou dans une autre zone de panne ?
• Qui reçoit l’alerte si la tâche échoue ?
• Les clés d’accès sont-elles séparées du serveur sauvegardé ?
• Qui peut lancer une restauration et qui peut valider les données ?
• Comment les fichiers, les tâches asynchrones et Redis sont-ils récupérés avec PostgreSQL ?

Ne déduisez jamais les garanties de l’offre hébergée de votre serveur autonome. Le fait qu’OpenShip annonce une capacité de sauvegarde pour un environnement Cloud ne signifie pas que votre instance locale planifie une tâche, conserve les archives ou teste leur restauration.

2. Distinguer le coût visible du coût exploité

Le prix du stockage est seulement une variable. Pour une décision fiable, utilisez la formule suivante :

Coût total mensuel = stockage des sauvegardes + réplication + trafic de sortie + ressources temporaires de restauration + temps de maintenance + coût attendu des échecs.

Le dernier terme est souvent oublié. Il ne s’agit pas de prédire une panne avec précision, mais de reconnaître qu’un fichier inutilisable, une clé expirée ou une restauration non documentée peut prolonger l’interruption.

Pour l’option hébergée, renseignez :

• le prix de l’offre au moment de la souscription ;
• la quantité incluse de stockage ;
• les frais liés à la conservation supplémentaire ;
• les modalités de restauration ;
• les limites de support et les rôles autorisés ;
• la localisation annoncée des données, si elle est explicitement documentée.

Pour l’option autonome, renseignez :

• la taille initiale des bases et sa croissance mensuelle ;
• le nombre de copies conservées ;
• le coût du stockage séparé ;
• le coût éventuel d’une seconde machine ;
• le temps nécessaire pour vérifier les journaux ;
• le temps nécessaire pour traiter un échec ;
• la procédure de mise à niveau de PostgreSQL, Redis et des outils de sauvegarde.

La documentation PostgreSQL distingue trois familles de méthodes : export SQL, sauvegarde au niveau du système de fichiers et archivage continu. Elle précise également qu’un export pg_dump produit une copie cohérente, mais qu’il faut tenir compte des rôles et des objets globaux lors d’une reprise complète. La documentation officielle PostgreSQL sur la sauvegarde et la restauration apporte le cadre technique nécessaire.

Une conséquence pratique est importante : un script qui lance uniquement pg_dump ne sauvegarde pas nécessairement tout ce dont votre SaaS a besoin. Il peut manquer les rôles, les paramètres, les fichiers déposés dans un stockage objet, les secrets et l’état d’une file de tâches.

3. Choisir selon le profil de votre équipe

Prototype individuel

Un prototype peut accepter une restauration moins rapide si les données sont générables, si aucun utilisateur réel n’est concerné et si vous pouvez reconstruire l’environnement depuis le dépôt de code. Cela ne justifie pas l’absence de sauvegarde.

Votre minimum devrait comprendre :

• un export de configuration OpenShip ;
• une copie de la base dans un stockage séparé ;
• une liste des variables d’environnement nécessaires ;
• une procédure de restauration écrite ;
• un test de restauration avant toute démonstration importante.

Si votre projet traite déjà des conversations privées, des paiements, des fichiers audio ou vidéo envoyés par des utilisateurs, il ne s’agit plus d’un simple prototype du point de vue du risque. Les données peuvent être difficiles à recréer et leur suppression peut avoir des conséquences contractuelles ou réglementaires.

Développeur indépendant

Pour un indépendant, le temps est généralement la dépense cachée la plus importante. Vous devrez écrire le script, protéger les identifiants, créer la rotation, surveiller les erreurs, nettoyer le stockage, vérifier la compatibilité des versions et documenter la restauration.

Le script est rarement le problème principal. Le problème est de savoir si vous l’exécuterez encore après plusieurs semaines, pendant une période de livraison ou au milieu d’un incident. Si vous ne pouvez pas réserver un créneau régulier pour examiner les résultats et restaurer une copie, une solution uniquement choisie pour son faible coût de stockage n’est probablement pas la moins chère.

Petite équipe

Une petite équipe doit nommer un responsable, même si plusieurs personnes possèdent des droits techniques. La sauvegarde hébergée peut réduire le nombre d’opérations quotidiennes, mais elle ne supprime pas les décisions liées à la conservation, aux permissions, aux données sensibles et à la validation métier.

En autonome, séparez au minimum :

• le compte qui crée la sauvegarde ;
• le compte qui peut supprimer les archives ;
• le compte qui peut restaurer ;
• le compte qui valide le retour du service ;
• les clés d’accès au stockage.

La documentation d’OpenShip indique que les projets Cloud sont canoniques à un seul endroit et que l’instance autonome peut agir comme passerelle. Elle précise aussi que le transfert d’un projet ne remplace pas automatiquement toutes les étapes opérationnelles : les secrets locaux chiffrés peuvent devoir être saisis à nouveau, et le retour d’un projet ne reconnecte pas nécessairement les domaines ou les conteneurs sans action complémentaire. La documentation officielle sur la propriété des projets et les transferts mérite d’être intégrée à votre procédure de changement.

SaaS IA en fonctionnement continu

Pour un service qui conserve des sessions d’Agent, des résultats générés, des fichiers, des quotas ou des paiements, vous devez définir deux objectifs distincts :

• la perte de données acceptable, c’est-à-dire la période maximale que vous accepteriez de perdre ;
• le délai de remise en service, c’est-à-dire le temps maximal avant que l’application soit de nouveau utilisable.

Ces objectifs ne doivent pas être inventés à partir des capacités marketing d’une plateforme. Ils doivent venir de votre produit. Une application de génération d’images peut tolérer la régénération de certains rendus, mais pas la perte des crédits consommés. Un outil audio peut recréer un fichier intermédiaire, mais pas toujours les droits, les métadonnées et l’historique de facturation.

NIST recommande d’intégrer les sauvegardes à la gestion des changements, de les tester et de les examiner durant des exercices de reprise. Les recommandations NIST sur la planification de continuité donnent un cadre indépendant du fournisseur.

4. Comparer les trois modèles

Le modèle hybride n’est pas automatiquement plus sûr. Il ajoute des dépendances : réseau entre services, comptes distincts, synchronisation des politiques de rétention et clarification de la responsabilité en cas de panne. Utilisez-le seulement si vous pouvez écrire noir sur blanc quelle partie est restaurée par qui.

5. Exécuter une restauration avant la mise en production

Voici une séquence opérationnelle en six étapes. Elle doit être exécutée sur une copie, jamais directement sur la base de production.

1. Inventoriez les données. Listez PostgreSQL, Redis, le stockage objet, les tâches planifiées, les files de messages, les secrets, les domaines et les paramètres OpenShip. Pour Redis, précisez si les données sont seulement un cache ou si elles représentent un état métier durable. La documentation officielle Redis sur la persistance rappelle que la stratégie dépend du rôle réel de Redis dans votre application.

2. Définissez le point de reprise. Écrivez la perte de données acceptable et le délai de remise en service. Si vous ne pouvez pas les exprimer, vous ne pouvez pas comparer sérieusement un service hébergé et un stockage autonome.

3. Produisez une archive isolée. Exécutez la sauvegarde avec un compte dédié, puis copiez le résultat vers un stockage auquel le serveur de production ne peut pas supprimer librement les archives. Conservez aussi la version des outils et les paramètres utilisés.

4. Recréez l’environnement. Déployez une instance de test avec la même version de PostgreSQL, les mêmes extensions nécessaires, les variables d’environnement documentées et une base vide. Un fichier présent dans un répertoire n’est pas encore une reprise validée.

5. Restaurez puis reconnectez l’application. Chargez PostgreSQL, rétablissez les rôles, remettez les fichiers objet, réinitialisez les connexions Redis et relancez les tâches nécessaires. Pour un format d’archive PostgreSQL, utilisez l’outil de restauration correspondant ; la référence officielle pg_dump et pg_restore décrit notamment les formats d’archive et leurs contraintes.

6. Validez un parcours métier. Connectez un compte de test, ouvrez une session d’Agent, récupérez un fichier, vérifiez un quota, relancez une tâche et contrôlez les journaux. Notez le temps total, les étapes manuelles et les éléments manquants. C’est cette preuve qui doit guider votre choix final.

Attention : « sauvegarde réussie » signifie généralement que la tâche a produit un résultat sans erreur détectée. « restauration réussie » signifie que l’environnement reconstruit sert réellement les données attendues et que l’application fonctionne. Les deux statuts ne sont pas interchangeables.

Questions fréquentes avant l’arbitrage

Une base autogérée dans OpenShip est-elle sauvegardée automatiquement ?

Non, vous ne devez pas déduire les garanties de la formule hébergée de votre installation autonome. Dans ce cas, la fréquence, la conservation, le stockage externe, les alertes et la restauration dépendent de votre propre procédure. Tant que vous n’avez pas produit puis restauré un fichier dans un environnement isolé, considérez la sauvegarde comme non vérifiée.

Est-il plus rentable d’utiliser une sauvegarde hébergée ou un script maison ?

Le script maison peut coûter moins cher en stockage, mais son coût total inclut la surveillance, la rotation, les alertes, les mises à jour, la gestion des secrets et les exercices de restauration. La solution hébergée devient souvent plus rationnelle lorsque personne n’est responsable de ces tâches. Comparez donc le coût mensuel et le temps d’intervention, pas seulement l’abonnement.

Quelle durée de conservation faut-il prévoir pour une base de données ?

Il n’existe pas de durée universelle. Décidez-la à partir de la perte de données acceptable, des obligations de suppression et de la possibilité de détecter une corruption tardive. Un prototype peut conserver une copie vérifiée pour une courte période, tandis qu’un SaaS avec facturation, fichiers utilisateurs ou historique métier doit définir plusieurs niveaux de conservation documentés.

Pourquoi une sauvegarde indiquée comme réussie peut-elle être inutilisable ?

La création d’un fichier ne prouve pas que l’application pourra redémarrer. Il peut manquer les rôles PostgreSQL, les secrets, les fichiers objet, les files de tâches, les versions compatibles ou les droits réseau. Une reprise réelle doit charger la base dans un environnement séparé, reconnecter l’application et vérifier un parcours métier représentatif.

Comment estimer le coût de reprise avant le lancement d’un SaaS IA ?

Listez chaque composant à restaurer, définissez la perte de données maximale et le délai d’indisponibilité acceptable, puis additionnez stockage, réplication, trafic, machines temporaires et temps humain. Faites ensuite un exercice complet. Le temps réellement observé et les blocages rencontrés valent davantage qu’une estimation fondée uniquement sur le statut « sauvegarde réussie ».

6. Fixer la conservation et les contrôles d’accès

La durée de conservation doit répondre à trois contraintes : la durée pendant laquelle une corruption peut rester invisible, les obligations de suppression et la capacité de stockage. Conserver toutes les copies indéfiniment augmente la surface d’exposition et peut rendre une demande de suppression difficile à exécuter.

Pour des données utilisateurs, vérifiez :

• le chiffrement pendant le transport et au repos ;
• les journaux d’accès aux archives ;
• la possibilité de supprimer une donnée dans les sauvegardes ;
• la localisation déclarée du stockage ;
• la séparation des environnements de test et de production ;
• la responsabilité du fournisseur et vos propres obligations.

Ne complétez pas une page officielle avec des certifications, des régions ou des engagements qui ne sont pas explicitement documentés. Si une exigence de conformité impose une localisation précise ou un contrôle direct des clés, l’autonomie peut devenir nécessaire, mais seulement si vous disposez des compétences et des procédures pour l’assumer.

Pour une application contenant des fichiers de design, des pistes audio, des vidéos ou des sorties générées par IA, n’oubliez pas que la base ne représente qu’une partie de la valeur. Une sauvegarde PostgreSQL peut restaurer les références sans restaurer les fichiers eux-mêmes. Le plan doit donc inclure le stockage objet, ses règles de cycle de vie et ses éventuelles répliques.

7. Utiliser une grille de décision par étape

Avant de sélectionner une formule, cochez les cases correspondant à votre situation :

• [ ] Les données peuvent-elles être régénérées sans impact pour un utilisateur réel ?
• [ ] Les informations personnelles, fichiers ou historiques de paiement sont-ils inclus dans le périmètre ?
• [ ] Une personne identifiée vérifie-t-elle les sauvegardes à intervalles définis ?
• [ ] Les archives sont-elles stockées sur une infrastructure séparée de la production ?
• [ ] Les clés de sauvegarde et de suppression sont-elles distinctes ?
• [ ] Une restauration complète a-t-elle déjà été réalisée dans un environnement isolé ?
• [ ] L’application a-t-elle été reconnectée après la restauration ?
• [ ] PostgreSQL, Redis, fichiers objet et files de tâches ont-ils été testés ensemble ?
• [ ] Le délai de reprise observé correspond-il au besoin du produit ?
• [ ] Les exigences de localisation, d’audit et de suppression sont-elles documentées ?

Si vous cochez moins de la moitié des cases, commencez par une solution hébergée ou par un périmètre hybride très simple. Si vous cochez presque toutes les cases et que votre équipe possède déjà une procédure d’astreinte, l’autonomie peut être économiquement rationnelle. Dans les deux cas, répétez l’exercice après une mise à niveau importante ou un changement de stockage.

8. Décider au moment du changement

Le choix le plus raisonnable pour un prototype reste une sauvegarde simple, séparée et restaurée au moins une fois. Pour un indépendant, la formule hébergée devient intéressante lorsque le temps passé à surveiller les scripts dépasse la valeur de l’économie réalisée sur le stockage. Pour une petite équipe, la décision dépend surtout de la présence d’un responsable et de la clarté des permissions. Pour un SaaS continu, choisissez d’abord les objectifs de reprise, puis l’architecture.

Le prix Cloud d’OpenShip n’étant pas annoncé sur la page officielle consultée le 2 août 2026, vous ne pouvez pas produire un montant fiable en le recopiant d’un tableau ancien ou d’une publication non officielle. Utilisez plutôt la formule de coût, demandez les conditions de rétention et vérifiez le parcours de restauration lorsque l’offre sera ouverte.

Si votre solution actuelle repose sur un seul serveur, elle cumule généralement trois défauts : le stockage de sauvegarde peut tomber avec la production, la restauration dépend d’une personne précise et les données annexes peuvent être oubliées. Si vous ajoutez des scripts sans exercices, vous obtenez davantage de complexité sans preuve de reprise. Pour un test temporaire, une démonstration audio ou vidéo, ou un environnement de validation qui ne doit pas rester allumé en permanence, louer une machine Mac auprès de Kvmkit peut offrir un cadre plus simple à isoler que votre serveur habituel. Vous pouvez également consulter la présentation de Kvmkit pour vérifier le périmètre du service avant de comparer cette option avec un achat de matériel. Ce n’est pas un remplacement pour une base de production durable, mais une option cohérente lorsque votre objectif est de tester, migrer ou valider un flux sans acheter immédiatement une infrastructure dédiée.

Avant de souscrire une capacité hébergée ou de préparer un nouveau nœud autonome, exportez la configuration, les variables nécessaires, les bases, les fichiers objet, les règles de tâches et la procédure de reconnexion. Réalisez ensuite une restauration complète. Le bon choix n’est pas celui dont la sauvegarde paraît la moins chère ; c’est celui dont la reprise est démontrable lorsque votre SaaS IA en a réellement besoin.

FAQ