Sauvegarde et reprise après sinistre

ObjectOS est lui-même sans état — le runtime peut être reconstruit à partir de l'image de conteneur. Les sauvegardes concernent les données dont dépend ObjectOS, et non ObjectOS lui-même. Planifiez la reprise autour de ces jeux de données.

Quoi sauvegarder

ObjectOS ne nécessite pas de sauvegarde distincte de son système de fichiers de conteneur. Les répertoires de cache (OS_CACHE_DIR) sont reconstructibles.

Sauvegardes de base de données

Adaptez la stratégie au driver :

Quel que soit le driver, vérifiez que :

• les sauvegardes s'achèvent dans le RPO du client ;
• une base de données neuve peut démarrer ObjectOS à partir du même artefact et traiter le trafic ;
• les tests de restauration sont exécutés de bout en bout au moins une fois par trimestre.

Déploiements SQLite

SQLite est le driver par défaut et constitue un choix de production légitime pour un ObjectOS mononœud — applications de bureau, outils internes pour une petite équipe, appliances edge / on-prem, environnements d'évaluation. Le compromis est structurel : SQLite n'autorise qu'un seul rédacteur, il ne convient donc pas à un ObjectOS multinœud, à un débit d'écriture concurrent élevé ou aux déploiements à base de données partagée. Pour ces cas, utilisez PostgreSQL.

Lorsque vous exécutez SQLite en production, la configuration qui le rend sûr et la recette de sauvegarde vont de pair :

Configuration du runtime

• Activez le WAL : PRAGMA journal_mode=WAL (les lecteurs ne bloquent pas le rédacteur ; résistant aux pannes).
• PRAGMA synchronous=NORMAL est la valeur par défaut habituelle pour les postes de travail / mononœuds — sûre avec le WAL, bien plus rapide que FULL.
• Conservez le fichier de base de données sur un disque local. Ne le placez pas sur NFS, SMB, ni dans un dossier synchronisé par Dropbox / OneDrive / iCloud pendant que le runtime est en cours d'exécution — le verrouillage de SQLite n'est pas fiable dans ces cas, et c'est la cause la plus fréquente de corruption des déploiements SQLite.

Snapshot à chaud (sans interruption)

Le runtime continue de traiter le trafic pendant que vous prenez un snapshot à l'aide de l'Online Backup API de SQLite ou de VACUUM INTO :

VACUUM INTO '/var/backups/objectos/db-2026-05-27T13-00Z.sqlite';

Planifiez-le (cron, timer systemd ou le planificateur in-process) à une cadence correspondant à votre RPO. Étiquetez chaque snapshot avec la version d'artefact qui l'a produit, afin de pouvoir restaurer ensemble la base de données et l'artefact (voir Versionnage des artefacts ci-dessous).

Copie hors site

Un snapshot local ne survit pas à la perte du disque. Poussez chaque snapshot vers un stockage durable :

• Serveur / VM : poussez vers S3 ou tout bucket compatible S3 (vous en avez probablement déjà un configuré pour la capacité storage).
• Application de bureau : écrivez le snapshot dans un dossier de synchronisation contrôlé par l'utilisateur (OneDrive / iCloud / Google Drive) — acceptable ici car le fichier de snapshot est fermé et immuable, contrairement à la base de données active.

Réplication continue (RPO réduit)

Pour un RPO inférieur à la minute sans renoncer à SQLite, exécutez Litestream aux côtés du processus ObjectOS. Il diffuse le WAL vers un stockage compatible S3 et prend en charge la restauration à un instant précis. C'est la voie recommandée lorsqu'un déploiement SQLite mononœud exige une perte de données quasi nulle.

Restauration

Arrêtez le runtime, remplacez le fichier de base de données par le snapshot choisi (ou exécutez litestream restore), démarrez le runtime avec la même version d'artefact que celle ayant produit le snapshot.

Versionnage des artefacts

Considérez les artefacts publiés comme immuables. Étiquetez chaque artefact avec l'identifiant de release utilisé pour le compiler (par exemple objectstack-2026-05-24.json). La reprise vers un état métier sain implique généralement de :

1. Restaurer la base de données à l'instant choisi.
2. Re-pointer ObjectOS vers la version d'artefact qui était active à ce moment-là.
3. Redémarrer le runtime.

Si vous écrasez les artefacts sur place, vous perdez la possibilité de revenir en arrière proprement, même lorsque la sauvegarde de la base de données est parfaite.

Planification RPO/RTO

Un objectif de départ réaliste pour les déploiements clients :

Des objectifs plus stricts nécessitent des changements de plateforme extérieurs au conteneur ObjectOS lui-même (base de données HA, ingress multi-AZ, réplicas préchauffés).

Modes de défaillance à répéter

• Base de données indisponible sur une longue période. Confirmez que le runtime renvoie un 503 clair et que les sondes marquent correctement les pods comme défaillants.
• Régression d'artefact. Revenez au pointeur d'artefact précédent ; les données ne sont pas affectées.
• Rotation de secret. La rotation de AUTH_SECRET invalide toutes les sessions. Effectuez-la pendant une fenêtre de maintenance ou échelonnez-la entre les réplicas.
• Panne de région. Si le client exige un basculement de région, la base de données métier, le gestionnaire de secrets et l'ingress doivent tous être inter-régions. ObjectOS lui-même peut s'exécuter partout où l'image est disponible.

Que consigner dans le runbook

• Calendrier de sauvegarde, rétention et contact d'astreinte pour chaque jeu de données.
• Procédure de restauration étape par étape (base de données d'abord, puis artefact, puis démarrage d'ObjectOS).
• Requêtes de vérification pour confirmer que la base de données restaurée est cohérente.
• Plan de rollback à la fois pour l'image ObjectOS et la version d'artefact (voir Mise à niveau et rollback).
• Modèle de communication pour les incidents visibles par les clients.