Des sauvegardes que vous pouvez vraiment restaurer

Une sauvegarde ne vaut que ce que vous arrivez à en ressortir. Ce guide porte sur les deux endroits qui en décident discrètement : combien de temps une copie survit, et ce qui se passe au moment où vous en restaurez une.

Le guide sur la duplication d'un environnement couvre la prise d'une sauvegarde et le clonage. Celui-ci couvre le reste de la vie de cette copie — y compris la partie que personne ne lit avant le mauvais jour.

Où elle vit, et qui peut y toucher

Tout se passe dans l'onglet Sauvegardes de l'environnement, et l'onglet lui-même n'apparaît qu'avec la permission environments.backups. Le bouton Restaurer en exige une seconde, environments.restore, et il est absent — pas grisé — pour qui ne l'a pas.

Les deux appartiennent au rôle Développeur et au-dessus. Un Lecteur ne voit aucun onglet Sauvegardes : la liste porte les tailles, les dates et les liens de téléchargement de toute votre base.

Une copie est stockée à l'écart de l'environnement, elle survit donc à un environnement cassé. Elle ne survit pas à un environnement supprimé : supprimer un environnement purge toutes ses sauvegardes. C'est l'enchaînement irréversible à retenir — télécharger d'abord, supprimer ensuite.

La planification, et le plafond qui n'est pas la rétention

Sauvegardes automatiques, c'est un interrupteur, une fréquence et une rétention. La fréquence propose exactement deux choix : quotidienne à 02:00 UTC, ou hebdomadaire, le lundi à 02:00 UTC. En UTC, pas en heure locale — à Douala, elle tourne à 03:00.

C'est dans la rétention que sont les surprises, et il y en a trois.

La date d'expiration est apposée à la création. Chaque sauvegarde porte sa propre expiration, calculée une fois, à partir de la rétention en vigueur à cet instant. Passer la rétention de 7 à 90 jours ne prolonge aucune sauvegarde déjà dans la liste — cela ne change que celles prises à partir de maintenant.

« Sauvegarder maintenant » n'utilise pas ce champ. Une sauvegarde prise à la main n'est pas rattachée à la planification : elle reçoit la valeur par défaut de la plateforme, 30 jours, quel que soit le nombre affiché dans la case. Le champ appartient au bloc dans lequel il se trouve : il date les copies planifiées.

L'âge n'est pas la seule chose qui retire une copie. Un balayage nocturne conserve les dix sauvegardes réussies les plus récentes par environnement et supprime le surplus, quelle que soit leur date d'expiration. Une planification quotidienne avec 365 jours de rétention ne donne donc pas un an d'historique : elle en donne une dizaine de jours. La rétention fixe combien de temps une copie peut vivre ; le balayage fixe combien peuvent vivre en même temps, et le premier des deux atteint l'emporte.

Un dernier nombre se comporte encore autrement : un environnement peut détenir vingt sauvegardes, et atteindre ce plafond refuse la suivante au lieu de supprimer une ancienne. Si « Sauvegarder maintenant » répond que le quota est atteint, rien n'est cassé — supprimez une copie dont vous n'avez plus besoin et reprenez-la.

Restaurer remplace cet environnement

Restaurer remet une sauvegarde dans l'environnement que vous regardez. Pas dans une copie de celui-ci. La base et le filestore actuels sont remplacés, et tout ce qui a été écrit depuis cette sauvegarde disparaît.

Trois choses méritent d'être sues avant de rencontrer cette fenêtre.

Elle demande de saisir le nom de l'environnement, et le bouton reste inerte tant que ce n'est pas fait. Sur un écran qui a cette conséquence, un clic que l'on peut faire par réflexe n'est pas une confirmation.

L'environnement s'arrête pendant l'opération. La restauration a besoin de la base pour elle seule : la plateforme l'arrête, restaure, puis la relance. Vos utilisateurs sont hors ligne pendant toute la durée, soit des dizaines de minutes pour une grande base.

Et un nouvel essai ne peut pas devenir une seconde restauration. Chaque tentative porte un nom que la plateforme reconnaît : une requête rejouée après un délai dépassé ou une connexion perdue reçoit le résultat de la première — ou s'entend dire clairement qu'elle tourne encore — au lieu d'en lancer une autre par-dessus les données que la première est en train d'écrire. Cela compte plus qu'il n'y paraît : une restauration n'a aucun moyen naturel de refuser un doublon, et deux en même temps n'ont aucune issue heureuse.

Seule une sauvegarde réussie peut être restaurée. Une copie échouée ou encore en cours laisse le bouton désactivé, et son infobulle en donne la raison.

La copie de sécurité, et ce qu'elle n'est pas

Avant d'écraser quoi que ce soit, la plateforme prend une copie de l'état actuel de l'environnement. C'est vrai, et c'est la phrase la plus susceptible d'être mal lue.

Cette copie n'apparaît pas dans cet onglet. Elle ne peut être ni téléchargée, ni restaurée depuis cet écran. C'est un filet tenu par la plateforme, conservé environ une semaine, et l'atteindre passe par le support — ce n'est pas un bouton d'annulation, et il ne faut pas aborder une restauration en comptant dessus.

La conséquence pratique tient en une habitude : si vous voulez une copie de l'état actuel que vous maîtrisez, prenez une sauvegarde avant de restaurer. Cela coûte un clic et quelques minutes, et c'est la différence entre « on peut revenir en arrière » et « on peut demander si quelqu'un peut revenir en arrière ».

Ce qui tourne, et ce qui s'est déjà passé

L'historique des restaurations, sous la liste, enregistre les restaurations que vous lancez depuis cet écran : quand chacune a démarré, sur place ou non, et comment elle s'est terminée. Tant qu'une restauration tourne, sa ligne se met à jour d'elle-même.

Chaque ligne ouvre ses journaux — en direct pendant la restauration, conservés ensuite, si bien qu'une restauration échouée pendant la nuit reste lisible au matin.

Une distinction évite beaucoup de confusion : les restaurations qui tournent pendant la création d'un environnement — depuis un modèle de base ou depuis un clone — ne sont pas dans cet historique. Elles ont leur propre bouton en haut de l'onglet, Journaux de provisionnement. Quand un nouvel environnement refuse de démarrer, c'est là que se trouve sa restauration, et la chercher dans l'historique ne donne rien du tout.

Faire entrer une copie, et en faire sortir une

Télécharger vous remet l'archive elle-même, par un lien valable quinze minutes. C'est ainsi que l'on garde une copie hors de la plateforme, et c'est la réponse honnête à « et si nous partons ? ».

Importer va dans l'autre sens : un fichier que vous avez déjà — .zip, .sql, .sql.gz, .gz, .dump ou .backup — devient une sauvegarde de cet environnement, restaurable comme n'importe quelle autre. Le fichier va directement de votre navigateur vers le stockage, sans passer par la plateforme : c'est ce qui rend possible un téléversement de plusieurs gigaoctets, et c'est aussi ce qui rend un échec à cette étape si peu bavard. Un import qui échoue immédiatement, c'est en général la connexion ou le fichier, pas la plateforme qui refuse.

Une copie importée compte dans les vingt, comme les autres.

Supprimer une sauvegarde retire l'archive stockée. C'est irréversible, et c'est la copie qui part, pas l'environnement — la confirmation dit de quelle copie il s'agit, par sa date, parce que « supprimer cette sauvegarde ? » sans rien d'autre à l'écran n'est pas une question à laquelle on peut répondre sans risque.

Quand ça refuse

Les refus qu'il vaut la peine de reconnaître, et ce que chacun veut dire :

Et une dernière habitude, la seule chose de cette page qui soit vraiment un test : restaurez une sauvegarde avant d'en avoir besoin. Clonez la plus récente dans un environnement jetable, ouvrez Odoo, vérifiez une pièce jointe et pas seulement une fiche, puis supprimez le clone. Une sauvegarde que personne n'a jamais restaurée est une croyance. Le clone rend ce test sans risque, et le guide sur la duplication d'un environnement le déroule pas à pas.