Reprise après sinistre

La reprise après sinistre conserve une copie de secours d’une installation sur un second serveur, idéalement dans un autre bâtiment ou un autre centre de données. Si le site qui exécute l’installation est perdu, un administrateur peut basculer : la copie de secours devient l’installation qu’utilisent les utilisateurs.

La reprise est asynchrone. La copie de secours a toujours un léger retard, donc les écritures les plus récentes peuvent être perdues lors d’un basculement.

Fonctionnement

Lorsque vous activez la reprise après sinistre pour une installation, la plateforme :

Crée une installation de secours sur le serveur que vous choisissez, nommée d’après l’originale avec (PRA) ajouté, par exemple Analyses des programmes (PRA), avec l’état En attente. Seules les bases de données de la copie de secours tournent. L’application elle-même reste arrêtée et ne sert personne : la copie de secours n’a pas de route, son adresse web répond donc HTTP 404 jusqu’à sa promotion.
Toutes les 15 minutes, fait sauvegarder par l’agent du serveur d’origine chaque base de données déclarée par l’application, et téléverser la sauvegarde dans votre magasin d’artefacts, un bucket compatible S3. Chaque téléversement est un point de restauration. Les sauvegardes sont chiffrées avec un mot de passe de dépôt que vous choisissez. Au niveau Continu, les bases de données PostgreSQL et MariaDB envoient aussi leurs modifications toutes les deux minutes environ.
Fait restaurer par l’agent du serveur de reprise chaque nouveau point de restauration dans les bases de données de la copie de secours.
Une fois par jour, restaure le dernier point de restauration dans une base de données temporaire sur le serveur de reprise et la vérifie, puis supprime la copie temporaire. Un point de restauration qui passe cette vérification est marqué VERIFIED (vérifié).

Le basculement n’est jamais automatique. C’est un administrateur qui le lance.

Objectif de point de récupération

L’objectif de point de récupération (RPO) correspond à la quantité de données récentes que vous pourriez perdre. La reprise propose deux niveaux :

Niveau	Ce qui est envoyé au magasin d’artefacts	Données que vous pouvez perdre
Intervalle (T1)	Une sauvegarde logique de chaque base de données toutes les 15 minutes	Jusqu’à 30 minutes
Continu (T2)	Pour les bases de données PostgreSQL et MariaDB : leurs modifications toutes les 2 minutes environ, en plus d’une base toutes les 6 heures	En général 1 à 3 minutes

Chaque installation démarre en Intervalle. Dès que l’offre de votre organisation inclut le niveau Continu et que la vérification quotidienne montre les bases de données prêtes, un Administrateur de l’organisation peut y passer depuis l’onglet Reprise après sinistre. Voir Niveau Continu.

En Continu, seules les bases de données PostgreSQL et MariaDB sont envoyées en continu. Les autres bases de données de l’application, comme MongoDB, et ses fichiers gardent la sauvegarde toutes les 15 minutes : ils peuvent donc toujours perdre jusqu’à 30 minutes. Le RPO affiché en titre est le plus lent d’entre eux.

Avant de commencer

La reprise doit être activée pour votre organisation. Scolah l’active organisation par organisation. D’ici là, l’onglet Reprise après sinistre affiche La reprise après sinistre n’est pas activée. Contactez votre représentant Scolah pour l’activer.
Vous devez être Administrateur de l’organisation pour activer ou désactiver la reprise, lancer un test, basculer, revenir au principal et utiliser la promotion d’urgence. Les membres peuvent voir l’onglet d’une installation protégée et utiliser Sauvegarder maintenant.
Un second serveur, serveur Docker ou cluster Kubernetes, différent de celui sur lequel tourne l’installation, qui soit :
- connecté, avec un signal au cours des 5 dernières minutes
- marqué éligible à la reprise
- au moins aussi puissant que le serveur d’origine : autant de cœurs CPU et 95 % de sa mémoire, pour que la copie de secours puisse prendre en charge toute la charge
- avec au moins 10 Gio de disque libre (50 Gio ou plus évitent un avertissement)
Un bucket compatible S3 que les deux serveurs peuvent joindre, et une clé d’accès pour ce bucket. Tenez-le à l’écart du site d’origine, sinon une panne du site emporte vos points de restauration avec lui. Sans bucket, le serveur de reprise n’a rien à partir de quoi restaurer (voir Magasin d’artefacts).
Un domaine sur l’installation. Le basculement déplace les domaines de l’installation vers le serveur de reprise. Les utilisateurs qui accèdent à l’installation par son adresse IP ne suivront pas.

L’installation et sa copie de secours peuvent chacune tourner sur un serveur Docker ou sur un cluster Kubernetes. Voir Clusters Kubernetes.

Lorsque l’onglet affiche un avis

Si la reprise n’est pas activée pour l’installation et que vous ne pouvez pas l’activer, l’onglet Reprise après sinistre en explique la raison au lieu d’afficher l’assistant :

Avis	Raison
La reprise après sinistre n’est pas activée	Scolah n’a pas encore activé la reprise pour votre organisation.
La reprise après sinistre est gérée par les administrateurs de votre organisation	Vous êtes membre. Seul un Administrateur de l’organisation peut activer la reprise ; une fois activée, vous pouvez suivre son état dans l’onglet.
La reprise après sinistre est temporairement indisponible	Scolah a désactivé la reprise sur la plateforme pour le moment. Les installations déjà protégées le restent. Réessayez plus tard.
L’état de la reprise après sinistre n’a pas pu être vérifié	Le portail n’a pas pu déterminer si la reprise est disponible. Rechargez la page.

L'onglet Reprise après sinistre lorsque la reprise n'est pas activée pour l'organisation

Applications protégées

L’application doit décrire ses données dans une spécification de sauvegarde (backup.json). Ces applications du catalogue en ont une :

Application	Bases de données sauvegardées	Fichiers
Scolah Compass	PostgreSQL (4 bases), MongoDB	Fichiers média (MinIO)
Scolah Compass Resources	PostgreSQL	Justificatifs (MinIO)
DHIS2	PostgreSQL	Dossier home de DHIS2
ERPNext	MariaDB	Dossier des sites
HOPE	PostgreSQL	Dossier de données
Keycloak	PostgreSQL	—
KoboToolbox	PostgreSQL (2 bases), MongoDB	—
LiteLLM	PostgreSQL	—
Metabase	PostgreSQL	—
Moodle	PostgreSQL	Dossier de données Moodle
OpenEWS	PostgreSQL	—
openIMIS	PostgreSQL	Dossier des photos
OpenMRS	MariaDB	Dossier de données

Les caches Redis sont ignorés, car l’application les reconstruit. La file de tâches Redis de KoboToolbox est sauvegardée et restaurée avec ses bases de données, les tâches en file suivent donc l’installation vers la copie de secours. Sample (nginx) ne conserve aucune donnée qui mérite d’être protégée.

Activer la reprise après sinistre

Ouvrez l’installation et cliquez sur l’onglet Reprise après sinistre.
Suivez les six étapes de Activer la reprise après sinistre, puis cliquez sur Activer la reprise.

1. Serveur de reprise

Choisissez le serveur qui hébergera la copie de secours. La liste n’affiche que les serveurs éligibles à la reprise autres que celui de l’installation. Si elle est vide, vous voyez Aucun serveur éligible à la reprise. Marquez d’abord un autre serveur comme éligible. : marquez d’abord un serveur comme éligible.

2. Objectif RPO

Objectif de point de récupération propose une seule option : Intervalle — jusqu’à 30 min (sauvegarde toutes les 15 min). La reprise démarre toujours en Intervalle. Vous pourrez passer en Continu depuis l’onglet Reprise après sinistre ensuite, dès que ce niveau est disponible (voir Niveau Continu).

Étape 2 : l'objectif de point de récupération

3. Base de données de reprise

Topologie de base de données détermine où tournent les bases de données de la copie de secours :

Gérée par l’agent (base de données conteneurisée), par défaut. L’agent exécute les bases de données de la copie de secours dans des conteneurs, comme pour toute installation.
Gérée par vous (votre base de données sur le serveur de reprise). Les bases de données de la copie de secours sont placées sur un serveur de base de données que vous exploitez déjà sur le serveur de reprise. Voir Une base de données que vous gérez.

Étape 3 : la topologie de base de données

Une base de données que vous gérez

Choisissez Gérée par vous : une liste apparaît, avec un champ pour chacune des bases de données de l’application, par exemple postgres ou mongodb. Dans chacun, choisissez l’une des bases de données enregistrées dans Services externes sur le serveur de reprise, du même type. Si aucune de ce type n’est enregistrée, le champ l’indique, avec un lien vers la page du serveur de reprise pour en ajouter une. Suivant reste désactivé tant que chaque base de données n’en a pas une.

Si l’option est grisée, l’application n’a aucune base de données pouvant être placée sur un serveur que vous gérez. Les caches et le stockage objet, comme Redis et MinIO, restent toujours gérés par l’agent.

Avant de la choisir, vérifiez que :

le serveur de base de données est enregistré dans Services externes sur le serveur de reprise
Docker sur le serveur de reprise peut le joindre : il doit accepter les connexions depuis le réseau de Docker, pas seulement depuis localhost
le compte enregistré dispose des droits nécessaires pour créer les bases de données de l’application :
- PostgreSQL : CREATEDB, CREATEROLE et l’appartenance à pg_signal_backend, ou superutilisateur
- MySQL / MariaDB : CREATE, DROP, ALTER et GRANT OPTION sur les bases de données de l’application, ainsi que CREATE USER
- MongoDB : un compte capable de créer des utilisateurs et des bases de données
pour une application qui utilise PostGIS (DHIS2, HOPE, KoboToolbox), le compte est superutilisateur, ou PostGIS est installé dans la base template1 afin que chaque nouvelle base en dispose. Le compte de l’application ne peut pas installer l’extension
pour MySQL avec la journalisation binaire activée, log_bin_trust_function_creators est défini, sinon les déclencheurs et fonctions restaurés échouent
sa version majeure est au moins celle qu’utilise l’application, par exemple PostgreSQL 16 ou plus récent pour une application sous PostgreSQL 16
les deux serveurs sont des serveurs Docker. Les clusters ne sont pas pris en charge avec une base de données que vous gérez
le serveur de reprise exécute la dernière version de l’agent

Lorsque vous activez la reprise, la plateforme crée les bases de données de l’application et un compte propriétaire pour elle sur votre serveur de base de données, comme pour une installation utilisant ce serveur. Chaque restauration remplace ces bases de données, et tout ce qui est restauré appartient au compte de l’application. Sous PostgreSQL, le compte enregistré devient membre du compte de l’application pour pouvoir gérer ces bases, et le reste.

Aucune copie de retour arrière des données précédentes n’est conservée sur votre serveur. Les points de restauration de votre magasin d’artefacts servent de retour arrière : pour revenir en arrière, restaurez-en un plus ancien. Si vous désactivez la reprise, les bases de données restent sur votre serveur ; supprimez-les vous-même lorsque vous n’en avez plus besoin.

Après l’activation de la reprise, et avant la première sauvegarde, l’agent du serveur de reprise vérifie la base de données : qu’il peut la joindre, les droits du compte enregistré et sa version. L’onglet Reprise après sinistre affiche le résultat de chaque vérification, sous Vérifications de la base de données que vous gérez. Si une vérification échoue, l’installation affiche Non protégé avec la raison. Corrigez la base de données et cliquez sur Relancer la vérification.

4. Magasin d’artefacts

L’emplacement où sont écrits les points de restauration chiffrés :

Champ	Que saisir
URL du point de terminaison	L’adresse du service compatible S3, comme `https://s3.eu-west-1.amazonaws.com` ou votre adresse MinIO.
Bucket / chemin	Le bucket, éventuellement avec un dossier, comme `dr-backups/this-org`. Utilisez un dossier différent pour chaque installation protégée.
ID de clé d’accès / Clé d’accès secrète	Une clé qui peut lire et écrire dans ce bucket.
Mot de passe du dépôt	Chiffre les points de restauration. Conservez-le en lieu sûr : sans lui, personne ne peut les lire.
Clé de récupération (facultatif)	Un second mot de passe qui peut aussi ouvrir les points de restauration. Conservez-le en lieu sûr en dehors des deux serveurs, pour que les sauvegardes restent lisibles si le serveur de reprise est perdu.
Object Lock est activé sur ce bucket	Cochez cette case uniquement si le bucket a été créé avec Object Lock (WORM), pour que les points de restauration ne puissent être ni supprimés ni écrasés.
Période de verrouillage (jours)	Apparaît lorsque vous cochez Object Lock et devient alors obligatoire : la durée de rétention Object Lock du bucket, un nombre entier de 1 à 3650. Les points de restauration plus récents que cette durée ne sont jamais supprimés. Voir Durée de conservation des points de restauration.

Si vous laissez le point de terminaison et le bucket vides, les points de restauration sont conservés dans un dépôt local sur le serveur de l’installation elle-même, et le récapitulatif affiche Dépôt local (développement). Le serveur de reprise ne peut pas restaurer à partir de ce dépôt, donc la copie de secours n’est jamais mise à jour, et les points de restauration sont perdus avec le serveur. Réservez-le aux tests : pour protéger une installation, définissez un magasin d’artefacts. Si l’un des deux serveurs est un cluster Kubernetes, vous devez en définir un.

5. Pré-vérification

La plateforme vérifie que la reprise peut fonctionner et liste chaque résultat. Une croix rouge vous bloque ; corrigez le problème, puis cliquez sur Relancer les pré-vérifications. Un avertissement ne vous bloque pas.

Vérification	Échoue ou avertit lorsque
Déjà activée	La reprise est déjà activée pour cette installation.
Serveur de reprise	Le serveur est introuvable, n’est pas éligible à la reprise, ou est le serveur de l’installation elle-même.
Agent de reprise	Aucun agent n’est enrôlé sur le serveur de reprise, ou il n’a pas envoyé de signal au cours des 5 dernières minutes.
Capacité	Le serveur de reprise a moins de cœurs CPU ou moins de mémoire que le serveur de l’installation. Un avertissement s’affiche plutôt lorsqu’un serveur n’a pas encore remonté ses ressources.
Disque	Moins de 10 Gio libres échoue ; moins de 50 Gio avertit.
Magasin d’artefacts	Avertit lorsqu’aucun n’est défini, car le serveur de reprise ne peut pas restaurer à partir d’un dépôt local. Échoue dans ce cas lorsque l’un des deux serveurs est un cluster Kubernetes. Lorsqu’un magasin est défini, avertit aussi lorsque Object Lock est activé sur ce bucket n’est pas coché, et lorsqu’aucune Clé de récupération (facultatif) n’est saisie.
Base de données que vous gérez	Uniquement avec Gérée par vous. Échoue lorsque l’un des deux serveurs est un cluster Kubernetes, lorsque l’agent du serveur de reprise est trop ancien, ou lorsqu’aucune base de données enregistrée du bon type n’a été choisie pour une base de données.
Base de données que vous gérez sur le serveur d’origine	L’installation elle-même utilise une base de données que vous gérez (voir Limites).
Connexions	Avertit lorsque l’installation a des connexions. Elles la suivent lors du basculement, mais les installations restées sur le serveur d’origine les perdent jusqu’à ce qu’elles suivent à leur tour.

Cochez Object Lock est activé sur ce bucket et saisissez une Clé de récupération (facultatif), et ces deux avertissements disparaissent à la pré-vérification suivante. Dans tous les cas, ils ne vous empêchent pas d’activer la reprise. La clé de récupération est ajoutée au dépôt comme seconde clé lors de l’activation.

6. Récapitulatif

Vérifiez le résumé et cliquez sur Activer la reprise. Si Object Lock est coché, le résumé affiche aussi la Période de verrouillage (jours).

Et ensuite

La copie de secours apparaît dans Installations sur le serveur de reprise, par exemple Analyses des programmes (PRA). Elle affiche En attente : ses bases de données tournent et attendent d’être en bonne santé, et l’application elle-même n’y tourne pas.

L’onglet Reprise après sinistre affiche Synchronisation. La première sauvegarde s’exécute en une minute ou deux. Une fois téléversée, l’état passe à Synchronisé et le titre à Protégé. Une minute plus tard, le serveur de reprise la restaure dans la copie de secours, et la première vérification quotidienne s’exécute.

Surveiller la protection

L’onglet Reprise après sinistre de l’installation protégée affiche :

Un titre : Protégé (vert) lorsque l’état est Synchronisé ou Promu, sinon Non protégé (rouge).
RPO pire classe : l’âge du point de restauration le plus récent, avec une ventilation par Base de données et, si l’application a des fichiers, Fichiers. En Continu, c’est la base de données la plus lente.
Niveau (Intervalle ou Continu), et Époque (un compteur qui augmente à chaque basculement et à chaque retour au principal).
Dernière vérification : la date de la dernière vérification quotidienne réussie.
RTO du dernier test : la durée de restauration du dernier test, en secondes.
Le sélecteur Niveau et la Vérification des bases de données. Voir Niveau Continu.
Points de restauration, du plus récent au plus ancien, avec leur type (DUMP pour les bases de données, FILES pour les fichiers, SNAPSHOT_BASE pour une base du niveau Continu), leur état et leur âge.

Une installation protégée par la reprise après sinistre

État	Signification
Synchronisation	Activée, en attente du premier point de restauration.
Synchronisé	Les points de restauration arrivent.
Obsolète	La vérification quotidienne du dernier point de restauration a échoué. L’état revient à Synchronisé lorsqu’une vérification ultérieure réussit. Ne comptez pas sur la copie de secours d’ici là.
Basculement	Un basculement est en cours.
Promu	La copie de secours est désormais l’installation active.
Retour arrière	Le service est en cours de retour vers l’installation d’origine.
Échec	Un basculement n’a pas pu démarrer la copie de secours. L’installation d’origine continue de servir.

Un point de restauration est AVAILABLE (disponible) une fois téléversé, VERIFIED (vérifié) lorsque la vérification quotidienne le restaure avec succès, et CORRUPT (corrompu) si cette vérification échoue.

Durée de conservation des points de restauration

Une fois par jour, l’agent du serveur d’origine supprime les points de restauration devenus inutiles, puis libère l’espace qu’ils occupaient dans le bucket :

Toutes les sauvegardes des dernières 48 heures sont conservées.
Au-delà, une sauvegarde par jour est conservée pendant 30 jours.
Les sauvegardes de plus de 30 jours sont supprimées.

Les points de restauration des bases de données et des fichiers sont comptés séparément, et le plus récent n’est jamais supprimé. Un point supprimé disparaît de Points de restauration.

En Continu, les bases physiques et les modifications envoyées depuis sont conservées 7 jours, plus ce dont la plus ancienne base conservée a encore besoin pour être rejouée. C’est la fenêtre qu’un test à un instant précis peut atteindre : environ les 7 derniers jours. Les sauvegardes quotidiennes sont conservées comme ci-dessus.

Si le bucket utilise Object Lock, le nettoyage ne supprime jamais un point de restauration plus récent que la Période de verrouillage (jours) saisie à l’étape 4, même lorsque les règles ci-dessus le feraient. Un point de restauration que le bucket refuse encore de supprimer reste dans la liste, et un passage ultérieur le supprime une fois le verrou expiré. Saisissez la durée de rétention réelle du bucket : la plateforme ne la lit pas dans le bucket.

Le nettoyage quotidien attend la fin d’une sauvegarde ou d’une restauration en cours, et ne s’exécute pas pendant un basculement ou un retour arrière.

La page Santé liste aussi toutes les installations protégées, et déclenche une alerte lorsque la protection échoue ou que les points de restauration cessent d’arriver.

Niveau Continu

Au niveau Continu (T2), l’agent du serveur d’origine récupère en continu les modifications de chaque base de données et les téléverse dans le magasin d’artefacts toutes les 2 minutes environ. Toutes les 6 heures, il téléverse aussi une base : une copie complète de la base de données sur laquelle les modifications sont rejouées. Le serveur de reprise rejoue chaque nouveau lot dans la copie de secours, qui reste une copie chaude juste derrière l’originale. Vous perdez en général 1 à 3 minutes de données.

Moteur	Modifications envoyées	Base
PostgreSQL	Son journal d’écriture anticipée (WAL), lu depuis un slot de réplication	Une copie physique de la base de données
MariaDB	Son journal binaire (binlog)	Un dump logique qui enregistre la position du binlog au moment où il a été pris

Sous MariaDB, le serveur de reprise applique les binlogs à la base de données en marche de la copie de secours. Les tests à un instant précis et le basculement fonctionnent comme pour PostgreSQL.

Rien n’est envoyé directement d’un site à l’autre : les deux agents ne parlent qu’au magasin d’artefacts, comme en Intervalle. Passer en Continu ne redémarre rien sur le serveur d’origine. Sous PostgreSQL, le seul réglage de base de données modifié est la limite du slot de réplication décrite plus bas. Sur un cluster, l’agent ajoute aussi une ligne de réplication au pg_hba.conf de PostgreSQL, qui ne demande pas non plus de redémarrage. MariaDB n’a besoin d’aucune modification de ce genre, quel que soit le type de serveur.

Avant de passer en Continu

L’offre de votre organisation l’inclut. Scolah accorde le niveau Continu organisation par organisation, et un supplément de facturation s’applique à la part reprise d’une installation qui l’utilise (voir Facturation). D’ici là, l’onglet indique L’offre de votre organisation n’inclut pas le niveau Continu. Contactez votre représentant Scolah.
La vérification quotidienne montre chaque base de données envoyée en continu prête. Une fois par jour, l’agent du serveur d’origine vérifie chaque base de données que l’application envoie en continu. Pour PostgreSQL :
- wal_level vaut replica ou logical (la valeur par défaut des bases de données fournies)
- un slot de réplication et un émetteur WAL sont libres (max_replication_slots, max_wal_senders)
- son compte a REPLICATION ou est superutilisateur
- une connexion de réplication fonctionne
Sur un serveur Docker, l’agent se connecte par le réseau de conteneurs de la base de données elle-même : les bases de données fournies n’ont besoin d’aucune modification de pg_hba.conf. Sur un cluster, l’agent y ajoute une ligne : voir Niveau Continu avec un serveur principal sur un cluster.

Pour MariaDB :
- la journalisation binaire est activée (log_bin)
- le format du binlog est par ligne (binlog_format vaut ROW)
- son compte a le droit REPLICATION SLAVE et REPLICATION CLIENT (BINLOG MONITOR sur les versions récentes de MariaDB)
Les bases de données fournies d’ERPNext et d’OpenMRS remplissent toutes ces conditions. Sur une installation créée avant que la journalisation binaire leur soit ajoutée, la mise à niveau de l’installation l’active, ce qui redémarre sa base de données une fois.
Le serveur est un MariaDB. Les serveurs Oracle MySQL ne peuvent pas passer en Continu et restent en Intervalle.
L’un ou l’autre serveur peut être un cluster Kubernetes, pour PostgreSQL comme pour MariaDB. L’installation d’origine et le serveur de reprise peuvent chacun exécuter Docker ou être un cluster : voir Niveau Continu avec un serveur principal sur un cluster et Niveau Continu avec le serveur de reprise sur un cluster.
Les bases de données de la copie de secours sont gérées par l’agent. Le niveau Continu n’est pas disponible avec une base de données que vous gérez sur le serveur de reprise.
Les deux serveurs utilisent la dernière version de l’agent.

Passer en Continu

Ouvrez l’onglet Reprise après sinistre de l’installation protégée.
Sous Niveau, cliquez sur Continu (T2). S’il est grisé, les raisons sont listées dessous : l’offre, une base de données que vous gérez, un problème sur le cluster de l’un des serveurs (par exemple The Continuous tier can’t run on this pairing’s cluster yet: The DR cluster has no default StorageClass for the standby’s work volumes), ou le problème exact trouvé par la vérification quotidienne pour chaque base de données, par exemple wal_level is minimal; replica or logical is needed.
Confirmez. La plateforme prend d’abord une base physique, puis commence à envoyer les modifications.

Pour revenir en arrière, cliquez sur Intervalle (T1) et confirmez. L’envoi s’arrête. Pour PostgreSQL, le slot de réplication est supprimé de la base de données du serveur d’origine et, sur un cluster, l’agent retire aussi sa ligne de pg_hba.conf. Sur un cluster, le pod expéditeur et son volume sont supprimés, pour PostgreSQL comme pour MariaDB.

Ce que l’onglet affiche en Continu

RPO pire classe est la base de données la plus lente.
Un tableau avec une ligne par base de données : son niveau (Continu pour une base envoyée en continu, Intervalle pour les autres), son RPO, et :
- pour PostgreSQL, le Retard du slot, c’est-à-dire la quantité de WAL que le serveur d’origine conserve pour le slot, affichée sous la forme x sur 10 Go, et l’État WAL du slot : reserved est normal, extended signifie qu’il dépasse la taille habituelle du WAL, et unreserved ou lost signifie que le serveur principal supprime du WAL dont la copie de secours a encore besoin.
- pour MariaDB, la quantité de binlog pas encore envoyée, affichée sous la forme x pas encore expédiés. Il n’y a pas de slot, donc ni limite ni état WAL. Le seul badge est un badge rouge Binlog purgé sur le primaire lorsque le serveur d’origine a supprimé un binlog avant son envoi.
Vérification des bases de données : quand la vérification quotidienne a eu lieu pour la dernière fois et, pour chaque base de données, son moteur et sa version, sa taille, et soit Prête pour le niveau Continu, soit Reste en Intervalle (les bases de données que l’application n’envoie pas en continu, comme MongoDB), soit le problème trouvé. Des notes orange en dessous signalent ce qui ne bloque pas le niveau Continu, par exemple que l’architecture de processeur d’une base de secours sur un cluster de reprise aux architectures mixtes n’a pas pu être vérifiée.
Un avertissement lorsque le ou les 2 derniers envois ont échoué.

Retour automatique en Intervalle

Le niveau Continu revient de lui-même en Intervalle, et l’onglet affiche Le niveau Continu est revenu en Intervalle avec la raison, lorsque :

3 envois de suite échouent
le slot de réplication est perdu sur le serveur d’origine
un binlog MariaDB est purgé sur le serveur d’origine avant son envoi (voir Les binlogs MariaDB)
l’offre de votre organisation n’inclut plus le niveau Continu
la vérification quotidienne ne montre plus toutes les bases de données prêtes

Les sauvegardes continuent en Intervalle : l’installation reste protégée, avec le RPO de l’Intervalle. Pendant que la plateforme supprime le slot de réplication de la base de données du serveur d’origine, l’onglet affiche Nettoyage du slot de réplication sur le serveur principal…. Corrigez la cause, puis repassez en Continu. Si le nettoyage échoue, la plateforme le relance en attendant un peu plus à chaque fois (jusqu’à une heure), et la note indique combien de fois il a échoué, quand aura lieu la prochaine tentative et la dernière erreur, mot pour mot. Après 3 tentatives échouées, la page Santé déclenche dr-cleanup-pending avec le nombre d’échecs et la dernière erreur, jusqu’à ce que le nettoyage réussisse. La page Santé déclenche dr-demoted jusqu’à ce que vous choisissiez un niveau.

Le slot de réplication et le disque du serveur principal

Un slot de réplication oblige la base de données du serveur d’origine à garder le WAL que l’agent n’a pas encore envoyé. Si l’envoi s’arrête, ce WAL grossirait jusqu’à remplir le disque. Pour protéger le disque, la plateforme limite le slot à 10 Go (max_slot_wal_keep_size). Au-delà, la base de données supprime le WAL le plus ancien : le slot est perdu et le niveau Continu revient en Intervalle, mais l’installation d’origine continue de fonctionner.

La page Santé avertit avec dr-slot-lag dès que le slot atteint la moitié de la limite, et déclenche dr-slot-at-risk lorsque son état WAL est unreserved ou lost. Assurez-vous que le disque du serveur d’origine dispose d’au moins 10 Go libres en plus de ce dont la base de données a besoin.

Les binlogs MariaDB

MariaDB n’a pas de slot de réplication : rien n’oblige le serveur d’origine à garder un binlog jusqu’à son envoi. Les bases de données fournies gardent leurs binlogs 2 jours (binlog_expire_logs_seconds). Si l’envoi s’arrête plus longtemps, par exemple pendant que l’agent du serveur d’origine est hors ligne, la base de données supprime un binlog dont la copie de secours a encore besoin. Le niveau Continu revient alors immédiatement en Intervalle, et repasser en Continu prend une nouvelle base.

La page Santé déclenche alors dr-slot-at-risk. Elle ne déclenche jamais dr-slot-lag pour MariaDB, car il n’y a pas de limite à remplir.

Sauvegarder maintenant

Sauvegarder maintenant crée immédiatement un point de restauration au lieu d’attendre la prochaine sauvegarde des 15 minutes. Utilisez-le avant une maintenance planifiée sur le serveur d’origine.

Lancer un test

Un test vérifie que vous pouvez effectuer une reprise sans toucher à quoi que ce soit en production. Lancer un test restaure le point de restauration le plus récent dans une base de données temporaire sur le serveur de reprise, la vérifie, la supprime, et enregistre la durée de la restauration sous RTO du dernier test. La copie de secours et l’installation d’origine continuent de fonctionner normalement.

Un test utilise le point de restauration le plus récent, qu’il soit déjà VERIFIED ou non. S’il n’y en a aucun, par exemple juste après l’activation de la reprise, le test est refusé avec No recovery point available to drill yet (aucun point de restauration disponible pour un test) : cliquez sur Sauvegarder maintenant, attendez une minute, et relancez le test.

Lancez un test après avoir activé la reprise, puis de nouveau chaque fois que les données de l’installation augmentent fortement, afin de savoir combien de temps prendrait une vraie reprise.

Test à un instant précis

En Continu, Lancer un test demande jusqu’où restaurer :

Le plus récent : tout ce qui a été envoyé jusqu’ici.
Un instant précis : une date et une heure, dans le fuseau horaire de votre navigateur, dans la fenêtre affichée sous le sélecteur. La fenêtre va de la plus ancienne base physique conservée au dernier envoi, soit environ les 7 derniers jours. Le test rejoue les modifications jusqu’à cet instant, vérifie la base de données et enregistre la durée sous RTO du dernier test.

Un instant dans le futur ou hors de la fenêtre est refusé avec la raison. Avant la première base physique, seul Le plus récent est proposé. En Intervalle, un test utilise toujours le point de restauration le plus récent.

Sur un serveur de reprise Docker, la base temporaire du test tourne dans la même image de base de données que la base de l’installation de reprise elle-même, avec les mêmes bibliothèques préchargées. Les applications qui utilisent PostGIS (DHIS2, HOPE, KoboToolbox), les bases avec des bibliothèques préchargées comme pg_stat_statements et le PostgreSQL 13 d’openIMIS sont donc restaurés exactement comme la base de secours tourne. Cela nécessite le dernier agent.

Basculer

Ne basculez que si l’installation d’origine ne peut pas être rétablie rapidement.

Dans l’onglet Reprise après sinistre, cliquez sur Basculer…. Cette action est disponible lorsque l’état est Synchronisé ou Obsolète.
Lisez l’avertissement. Depuis l’état Obsolète, il peut manquer à la copie de secours plus de données récentes que d’habitude.
Saisissez FAILOVER et confirmez.

La plateforme arrête l’application sur le serveur d’origine, si elle peut encore joindre l’agent de ce serveur, et démarre l’application complète sur la copie de secours. Une fois la copie de secours démarrée, la plateforme :

y déplace les domaines de l’installation, et les fait servir par le serveur de reprise, en HTTPS selon le mode TLS du domaine
fait pointer les enregistrements DNS qu’elle gère (sous-domaines Scolah) vers l’adresse IP publique du serveur de reprise
fait de l’installation d’origine la copie de secours : elle affiche En attente, son application reste arrêtée et ses domaines sont retirés de son serveur, son adresse web répond donc HTTP 404, même si ce serveur revient en ligne plus tard

L’état devient Promu. Si la copie de secours ne démarre pas, l’état devient Échec et l’installation d’origine continue de servir.

En Continu, le serveur de reprise rejoue d’abord tout jusqu’au dernier envoi, puis promeut les bases de données de la copie de secours. Le basculement restaure toujours jusqu’au dernier envoi : vous ne pouvez pas basculer vers un instant antérieur.

Si vous utilisez votre propre domaine, vérifiez que son enregistrement A pointe vers l’adresse IP publique du serveur de reprise, et modifiez-le chez votre fournisseur DNS si ce n’est pas le cas. L’onglet Domaines de l’installation promue affiche chaque domaine comme Routé une fois que le serveur de reprise le sert.

Revenir au principal

Après un basculement, une fois le serveur d’origine rétabli, vous pouvez y ramener le service.

Cliquez sur Revenir au principal…. Ce bouton n’apparaît que lorsque l’état est Promu.
Saisissez FAILBACK et confirmez.

La plateforme effectue alors, une étape à la fois :

une sauvegarde de l’installation d’origine en l’état, comme copie de sécurité
une sauvegarde des données actuelles de la copie de secours promue
la restauration de ces données sur l’installation d’origine, en écrasant sa base de données
le démarrage de l’installation d’origine, et l’arrêt de l’application sur la copie de secours
le retour des domaines et du DNS, et le retour de la copie de secours à son rôle de secours

L’état est Retour arrière pendant l’opération, puis Synchronisé. Si une étape échoue, l’opération s’arrête, l’état revient à Promu, et la copie de secours continue de servir.

Le retour au principal copie toujours les données avec une sauvegarde logique, même en Continu. Ensuite, une installation en Continu prend une nouvelle base physique et recommence les envois : la fenêtre d’un test à un instant précis repart donc de ce moment.

Promotion d’urgence

Un basculement normal nécessite la plateforme. La promotion d’urgence permet à une personne présente sur le serveur de reprise de promouvoir la copie de secours même lorsque la plateforme est injoignable.

Pendant que tout fonctionne, cliquez sur Armer sous Promotion d’urgence et définissez un Secret de déblocage. Conservez ce secret dans un endroit accessible à vos opérateurs pendant une panne, pas uniquement dans le portail.
L’agent du serveur de reprise conserve un jeton de promotion signé, valable 90 jours à partir du moment où vous l’armez. Si la copie de secours change, l’état affiche Obsolète — réarmer : cliquez sur Réarmer.
En cas d’urgence, sur le serveur de reprise, exécutez :
Terminal window
```
scolah-agent break-glass promote --secret <release secret>
```
L’agent vérifie le jeton et le secret, puis démarre l’application complète sur la copie de secours. Lorsque la plateforme peut de nouveau joindre l’agent, elle termine le basculement comme si vous l’aviez lancé depuis le portail : elle déplace les domaines, fait de l’installation d’origine la copie de secours, et l’état devient Promu.

D’ici là, rien n’arrête l’installation d’origine ni ne modifie le DNS. Assurez-vous que l’installation d’origine est vraiment hors service, et faites vous-même pointer votre domaine vers le serveur de reprise si les utilisateurs en ont besoin avant le retour de la plateforme.

Désarmer retire le jeton du serveur de reprise.

Désactiver la reprise après sinistre

Cliquez sur Désactiver la reprise et confirmez. La copie de secours est supprimée du serveur de reprise, avec ses données, et la liste des points de restauration est vidée. Si la copie de secours utilisait une base de données que vous gérez, ses bases de données sur votre serveur sont conservées. L’installation d’origine n’est pas affectée. Les sauvegardes déjà téléversées restent dans votre bucket jusqu’à ce que vous les supprimiez.

En Continu, la désactivation nettoie aussi le serveur d’origine : le slot de réplication est supprimé de sa base de données et, sur un cluster, la ligne de pg_hba.conf ainsi que le pod expéditeur et son volume aussi. Si le serveur d’origine est hors ligne, le nettoyage se fait automatiquement dès que son agent est de retour en ligne. En attendant, le slot oblige la base de données à conserver le WAL, jusqu’à la limite. Si le nettoyage échoue, la plateforme continue de le relancer. La page Santé déclenche dr-cleanup-pending après 3 tentatives échouées, avec le nombre d’échecs et la dernière erreur, ou 10 minutes après la désactivation si l’agent du serveur d’origine est toujours hors ligne, et l’alerte disparaît dès que le nettoyage réussit.

Tant que ce nettoyage n’est pas terminé, le niveau Continu ne peut pas être activé pour une nouvelle reprise d’une installation sur le même serveur d’origine : il est refusé avec un message qui nomme le slot de réplication de l’ancienne reprise encore à nettoyer. L’Intervalle fonctionne normalement en attendant.

Vous ne pouvez pas désactiver la reprise pendant un basculement ou un retour au principal, ni lorsque la copie de secours est promue.

Facturation

La copie de secours compte comme une installation à part entière, avec des jours actifs comme toute autre. Dans Facturation → Utilisation, sa ligne est marquée DR. Scolah facture ses jours à une fraction réduite du tarif de l’application, sans frais de mise en place, et une application gratuite reste gratuite. Voir Facturation.

En Continu, un supplément en pourcentage s’ajoute à la part reprise.

La fraction réduite s’applique toujours au côté qui ne sert pas. Après un basculement, l’installation promue est facturée au tarif plein et l’installation d’origine, devenue la copie de secours, à la fraction réduite, jusqu’au retour au principal.

Clusters Kubernetes

Un cluster Kubernetes peut participer à la reprise après sinistre des deux côtés. Une installation sur un cluster peut être protégée, et un cluster peut héberger des copies de secours une fois marqué éligible à la reprise. Vous pouvez associer un serveur Docker à un cluster dans un sens ou dans l’autre, ou deux clusters entre eux.

Activez la reprise comme pour toute installation. Lorsqu’un cluster est concerné :

Un magasin d’artefacts est obligatoire. Dès que l’un des deux serveurs est un cluster, le magasin d’artefacts est la seule chose que partagent les deux serveurs, la pré-vérification échoue donc sans lui.
Les sauvegardes s’exécutent dans le cluster. Toutes les 15 minutes, un pod éphémère dans le namespace de l’installation sauvegarde les bases de données et les volumes de fichiers, comme le dossier de données Moodle, et les téléverse dans le même format qu’un serveur Docker. Un point de restauration pris sur un cluster peut être restauré sur une copie de secours Docker, et inversement.
Une copie de secours sur un cluster garde ses bases de données en marche pendant que les charges de travail de l’application sont réduites à zéro, et n’a pas de route. Sa ressource Installation affiche la phase Standby.
Le niveau Continu fonctionne pour PostgreSQL et MariaDB des deux côtés. Un serveur principal Docker avec une copie de secours sur un cluster, un cluster avec une copie de secours Docker, et deux clusters entre eux fonctionnent tous. Voir Niveau Continu avec un serveur principal sur un cluster et Niveau Continu avec le serveur de reprise sur un cluster.
Les tests et la vérification quotidienne s’exécutent sur la copie de secours, où qu’elle soit. Sur un cluster, ils s’exécutent dans le namespace de la copie de secours et nettoient derrière eux, et la durée de restauration du test apparaît sous RTO du dernier test, comme sur un serveur Docker.

Le basculement et le retour au principal fonctionnent comme décrit plus haut, sur un cluster comme sur un serveur Docker. L’installation qui prend le relais reçoit les domaines ; celle qui cède la place perd sa route, son adresse web répond donc HTTP 404. Lors d’un retour au principal vers un cluster, l’installation d’origine est redémarrée sans routes, sauvegardée comme copie de sécurité, alimentée avec les données du serveur de reprise, et ses pods applicatifs sont redémarrés avant que les domaines ne reviennent vers elle.

Niveau Continu avec un serveur principal sur un cluster

Une installation sur un cluster Kubernetes peut passer en Continu, que son serveur de reprise exécute Docker ou soit lui aussi un cluster. Ses bases de données PostgreSQL envoient leur WAL et ses bases MariaDB leur binlog comme sur un serveur Docker, et le serveur de reprise les rejoue dans la copie de secours de la même façon. Les téléversements, les bases, les tests à un instant précis, le basculement et l’onglet fonctionnent tous comme sur un serveur Docker.

Avant de passer en Continu, le cluster de l’installation d’origine doit avoir :

L’agent 0.0.2 ou plus récent sur le cluster.
L’image de l’agent lui-même téléchargeable depuis le namespace de l’installation. Certaines étapes du niveau Continu s’exécutent dans des pods éphémères qui utilisent l’image de l’agent : voir Registres privés sur un cluster.
Une StorageClass par défaut avec de la place pour le volume de l’expéditeur : la limite du slot (10 Go) plus 2 Go par base de données envoyée en continu.
La même architecture de processeur que le serveur de reprise. La plateforme vérifie le nœud sur lequel tourne réellement chaque base de données : la vérification est donc exacte même sur un cluster qui mélange les architectures. Une différence bloque le niveau Continu, par exemple The database of store db runs on an arm64 node and the DR server on amd64.

Pour PostgreSQL, en plus :

Un compte de base de données superutilisateur. Les bases de données fournies en utilisent un.
pg_hba.conf dans le répertoire de données de la base, comme dans les images PostgreSQL officielles.
Une règle générale host all all all dans pg_hba.conf. L’agent reprend sa méthode d’authentification.
Un volume de base de données qui n’est pas ReadWriteOncePod. Le niveau Continu le monte depuis un second pod sur le même nœud.

Pour MariaDB, en plus :

La journalisation binaire activée, au format par ligne, et un compte avec le droit REPLICATION SLAVE et REPLICATION CLIENT (ou BINLOG MONITOR), comme indiqué sous Avant de passer en Continu. Les bases de données fournies d’ERPNext et d’OpenMRS les ont.

S’il manque l’un de ces points, Continu (T2) reste grisé et la raison est listée dessous, par exemple The Continuous tier can’t run on this pairing’s cluster yet: The cluster has no default StorageClass for the WAL shipper’s volume, ou The cluster’s agent is 0.0.1; streaming MariaDB on a cluster needs agent 0.0.2 or later.

Pour PostgreSQL, l’agent ajoute deux choses au cluster :

Une ligne dans pg_hba.conf. Les images PostgreSQL standard refusent les connexions de réplication venant d’autres pods ; l’agent ajoute donc une ligne qui autorise le compte de la base de données à répliquer, par exemple host replication "postgres" all scram-sha-256 # scolah-dr 1a2b3c4d. La méthode est celle de votre règle générale, et le commentaire marque la ligne comme celle de la plateforme. L’agent l’écrit par SQL puis recharge la configuration : la base de données n’est pas redémarrée. Si PostgreSQL signale ensuite une erreur dans le fichier, l’agent remet l’original. La ligne autorise la réplication pour ce seul compte depuis tout ce qui peut joindre le Service de la base de données, avec la méthode d’authentification que l’application utilise déjà : elle n’ouvre rien de plus que l’accès de l’application elle-même. Quand vous revenez en Intervalle ou désactivez la reprise, l’agent retire la ligne et recharge à nouveau, toujours sans redémarrage. Chaque ajout et chaque retrait est enregistré dans le Journal d’activité sous dr.pg_hba.line_added ou dr.pg_hba.line_removed, sur l’installation d’origine, avec la base de données et la somme de contrôle du fichier avant et après la modification. Lorsque la somme de contrôle après un retrait correspond à celle d’avant l’ajout, le fichier a été remis à l’identique, octet pour octet.
Un pod expéditeur, scolah-drship-<base>, dans le namespace de l’installation. Il reçoit le WAL et le garde jusqu’au téléversement suivant, sur son propre volume de la StorageClass par défaut, dimensionné à la limite du slot plus 2 Go. Le pod, son volume et son secret sont supprimés quand le niveau Continu est désactivé.

Pour MariaDB, l’agent n’ajoute qu’un pod expéditeur, scolah-drship-<base>, avec son propre volume (la limite du slot plus 2 Go, dans la StorageClass par défaut) et son secret. Il lit le binlog par le Service de la base de données, comme le ferait un réplica, et le garde jusqu’au téléversement suivant. Rien ne change dans la base de données : les droits de réplication autorisent déjà la lecture du binlog à distance, il n’y a donc ni modification du type pg_hba.conf ni redémarrage. Le pod, son volume et son secret sont supprimés quand le niveau Continu est désactivé.

Registres privés sur un cluster

La reprise après sinistre effectue son travail dans des pods éphémères, dans le namespace de l’installation : sauvegardes, restaurations, amorçage, tests à un instant précis et expéditeur du niveau Continu. Ils utilisent l’image de l’agent lui-même et les images des bases de données de l’application, et chacun télécharge ses images avec ces deux Secrets lorsqu’ils existent :

scolah-registry-auth, l’identifiant de registre de l’installation, que l’agent écrit déjà pour les applications aux images privées.
scolah-dr-agent-pull, une copie des imagePullSecrets définis dans le chart Helm de l’agent. Un pod ne peut pas utiliser un Secret d’un autre namespace : l’agent copie donc les pull secrets du chart dans le namespace de chaque installation avant d’y démarrer l’un de ces pods, et y laisse la copie.

Si l’image de l’agent est dans un registre privé, définissez imagePullSecrets dans le chart de l’agent, par exemple --set 'imagePullSecrets[0].name=my-registry', avec ce Secret dans scolah-system. Si la copie échoue, l’agent le journalise et démarre le pod sans elle : une image publique fonctionne donc toujours.

Niveau Continu avec le serveur de reprise sur un cluster

Une copie de secours sur un cluster Kubernetes peut passer en Continu pour PostgreSQL et MariaDB, que l’installation d’origine tourne sur un serveur Docker ou sur un cluster. La copie de secours rejoue le WAL ou le binlog envoyé comme sur un serveur Docker, et les tests à un instant précis, la promotion lors du basculement et l’onglet fonctionnent de la même façon.

Avant de passer en Continu, le cluster de reprise doit avoir :

L’agent 0.0.2 ou plus récent sur le cluster de reprise.
L’image de l’agent lui-même téléchargeable depuis le namespace de la copie de secours, comme côté principal.
Une StorageClass par défaut. L’amorçage de la copie de secours et les tests utilisent des volumes de travail éphémères pris dans cette StorageClass.
La même architecture de processeur que le serveur d’origine. Lorsque tous les nœuds du cluster de reprise partagent une même architecture, la plateforme compare celle-ci. Sur un cluster qui mélange les architectures, elle ne peut pas savoir sur quel nœud tournera la base de secours avant qu’elle ne tourne : elle compare donc le nœud où tourne l’agent de reprise, et l’onglet garde une note orange. Fixez la base de secours sur l’architecture de la base d’origine, par exemple avec un sélecteur de nœud kubernetes.io/arch.
Pour PostgreSQL, le répertoire de données de la base de secours sur un volume, monté sans subPath. C’est le cas des bases de données fournies.
Pour PostgreSQL, un volume de base de données de secours qui n’est pas ReadWriteOncePod. Chaque mise à jour le monte depuis un second pod sur le même nœud.

S’il manque l’un de ces points, Continu (T2) reste grisé et la raison est listée dessous, par exemple The Continuous tier can’t run on this pairing’s cluster yet: The DR cluster has no default StorageClass for the standby’s work volumes, ou The DR cluster’s agent is 0.0.1; a MariaDB standby on a cluster needs agent 0.0.2 or later.

Ce qui se passe sur le cluster de reprise pour PostgreSQL :

Amorçage. La première fois, puis chaque fois que la copie de secours doit être reconstruite à partir d’une autre base (par exemple après un retour au principal ou une nouvelle timeline), l’agent arrête brièvement la base de données de secours : son pod est ramené à zéro pendant qu’un pod éphémère restaure le répertoire de données de la base à partir de la base physique. La base de données redémarre ensuite comme copie de secours active (hot standby) et rejoue le WAL envoyé. L’application de secours reste à zéro pendant tout ce temps, comme toujours sur une copie de secours.
Mises à jour. Après l’amorçage, chaque mise à jour ne récupère que le WAL envoyé depuis la précédente dans la base de données de secours en marche. Rien n’est redémarré.
Les tests à un instant précis s’exécutent dans un pod jetable, scolah-drpitr-…, dans le namespace de la copie de secours. Il construit sa propre copie de la base sur un volume temporaire, n’écoute sur aucun port réseau, et est supprimé à la fin du test. La copie de secours continue de rejouer.
Le basculement récupère d’abord le dernier envoi, attend que la copie de secours l’ait rejoué, puis promeut la base de données et démarre l’application.

Si un amorçage échoue après que le répertoire de données de la base de secours a été vidé, ou si l’agent s’arrête au milieu d’un amorçage (par exemple parce que son pod est redémarré), la base de données de secours reste ramenée à zéro, car son répertoire de données est incomplet. Jusqu’à ce qu’elle soit amorcée à nouveau :

Le basculement et la promotion d’urgence sont refusés, avec un message indiquant que la base de secours est incomplète et doit d’abord être amorcée à nouveau.
La mise à jour suivante en Continu l’amorce à nouveau à partir d’une base, puis démarre la base de données.
Une mise à jour en Intervalle la reconstruit : l’agent vide la base incomplète, la laisse redémarrer comme une base neuve et vide, puis la remplit à partir de la dernière sauvegarde en Intervalle. Pendant ce court laps de temps, la base de secours ne contient aucune donnée, et le basculement reste refusé jusqu’à la fin du remplissage. Le résultat de la mise à jour liste les bases reconstruites (reinitialised=…).

Ce qui se passe sur le cluster de reprise pour MariaDB :

La base de données de secours reste en marche. Contrairement à PostgreSQL, elle n’est jamais arrêtée, même pour l’amorçage : des pods éphémères chargent la base et rejouent le binlog envoyé par le Service de la base de données. Si un rejeu échoue, la mise à jour suivante l’amorce à nouveau à partir de la base.
Les tests à un instant précis s’exécutent dans un pod jetable scolah-drpitr-… qui construit sa propre copie de la base, n’écoute sur aucun port réseau, et est supprimé à la fin du test.
Le basculement rejoue d’abord tout jusqu’au dernier envoi, puis démarre l’application.

Limites

Le niveau Continu est réservé aux bases de données PostgreSQL et MariaDB, sur les serveurs Docker comme sur les clusters Kubernetes. MongoDB et les fichiers gardent toujours la sauvegarde toutes les 15 minutes.
Les serveurs Oracle MySQL ne sont pas pris en charge en Continu ; MariaDB l’est.
Le niveau Continu n’est pas disponible avec une base de données que vous gérez sur le serveur de reprise.
Le basculement est à sens unique jusqu’au retour au principal. Il n’y a pas d’annulation une fois les domaines déplacés.
Synchronisé signifie que des points de restauration sont téléversés. Cela ne prouve pas que la copie de secours peut être restaurée : fiez-vous à Dernière vérification et aux tests.
Une application sans spécification de sauvegarde peut afficher Synchronisé sans rien dans ses points de restauration.
Seules les bases de données PostgreSQL sont restaurées dans une copie temporaire et vérifiées avant de remplacer les données de la copie de secours. Les autres bases de données sont restaurées directement.
La durée de conservation est fixe : toutes les sauvegardes pendant 48 heures, puis une par jour pendant 30 jours, et en Continu les bases physiques et les modifications envoyées pendant 7 jours. Elle ne se règle pas par installation, sauf qu’une période Object Lock plus longue conserve les points de restauration plus longtemps.
Une installation qui utilise une base de données que vous gérez vous-même (un service externe enregistré) ne peut pas encore être protégée. La vérification préalable la refuse, car la copie de secours n’aurait aucune copie de cette base.