Stack · Sauvegarde
Sauvegarde & reprise Odoo
Tout le monde a des sauvegardes. Presque personne n'a déjà essayé d'en restaurer une. La différence se découvre le seul jour où ça compte.
C’est le chapitre que tout le monde coche et que presque personne ne vérifie. Sur les audits que nous menons, la question « avez-vous des sauvegardes ? » reçoit toujours un oui. La question suivante — « quand avez-vous restauré la dernière fois ? » — reçoit presque toujours un silence.
Ces deux réponses ne décrivent pas la même situation. La première est une intention, la seconde est un fait.
Une sauvegarde, ce sont deux choses
Les deux se sauvegardent ensemble, se datent ensemble, se restaurent ensemble. Une sauvegarde de base seule est une demi-sauvegarde, ce qui, le jour de l’incident, revient à aucune.
Les deux questions qui décident de tout
Avant de parler d’outil, deux questions de gestion :
Combien d’heures de saisie acceptez-vous de perdre ? Une sauvegarde quotidienne à 3 h, sur un ERP qui encaisse des commandes toute la journée, signifie qu’un incident à 17 h efface quatorze heures de travail. Est-ce acceptable ? C’est une décision de direction, pas un réglage technique.
Combien de temps l’entreprise peut-elle rester à l’arrêt ? Une heure ? Une journée ? La réponse détermine s’il faut une simple archive ou un environnement de secours prêt à prendre le relais — et les coûts n’ont rien à voir.
Ces deux nombres sont le vrai cahier des charges. Tout le reste en découle.
La seule preuve : une restauration
Un fichier de sauvegarde n’est pas une sauvegarde. C’est un fichier. Il peut être tronqué, produit par une version incompatible, amputé des pièces jointes, ou chiffré avec une clé que personne ne retrouve.
La seule preuve qu’une sauvegarde fonctionne, c’est une restauration réussie, jouée sur un environnement séparé, et datée. Nous la faisons à la mise en place, puis périodiquement — parce qu’une sauvegarde qui marchait il y a un an peut avoir cessé de marcher sans que rien ne le signale.
C’est aussi à ce moment-là qu’on mesure le délai réel de reprise. Le chiffre surprend : entre récupérer l’archive, remonter un serveur, restaurer, vérifier et rebasculer, plusieurs heures passent. Mieux vaut le savoir à froid.
Où stocker
| Emplacement | Verdict |
|---|---|
| Sur le même serveur | Inutile — le serveur brûle avec ses sauvegardes |
| Sur le même compte d’hébergement | Insuffisant — un compte compromis ou suspendu emporte tout |
| Chez un tiers, hors du fournisseur | La bonne réponse |
| Une copie hors ligne | Recommandé contre les rançongiciels, qui chiffrent aussi les sauvegardes accessibles |
La règle tient en une phrase : une sauvegarde doit survivre à la disparition complète de l’environnement qu’elle protège. Y compris à sa compromission.
Ce que nous mettons en place
- Sauvegarde base + fichiers, automatisée, datée, avec rétention décidée avec vous.
- Externalisation hors du serveur et hors du compte.
- Restauration de vérification à la mise en place, puis périodique.
- Alerte quand une sauvegarde échoue — une sauvegarde silencieusement arrêtée depuis trois mois est le scénario le plus fréquent.
- La procédure de restauration écrite, exécutable par quelqu’un d’autre que nous.
Ce dernier point compte : une procédure que seul votre prestataire sait exécuter n’est pas un plan de reprise, c’est une dépendance.
Les limites, dites franchement
Une sauvegarde ne protège pas d’une erreur humaine non détectée. Si quelqu’un corrompt des données en mars et que personne ne le voit avant juin, vos sauvegardes de juin contiennent la corruption. La rétention longue limite le risque, elle ne le supprime pas.
Un plan de reprise a un coût proportionnel à l’ambition. Repartir en une heure suppose une infrastructure en attente qui se paie. Repartir en une journée coûte beaucoup moins. C’est un arbitrage de gestion, à faire les yeux ouverts.
Nous ne sommes pas hébergeur. Nous mettons en place, nous testons, nous documentons. Quelqu’un doit ensuite surveiller que ça continue de tourner — et il faut que ce quelqu’un existe. Voir hébergement.
Questions fréquentes
Mon hébergeur fait des sauvegardes, ça suffit ?
Rarement. Les sauvegardes d’hébergeur sont conçues pour restaurer un serveur, pas votre base à hier soir sans écraser le reste. Elles sont souvent conservées peu de temps, et surtout : personne n’a vérifié qu’elles contiennent ce que vous croyez. Ça ne remplace pas une sauvegarde applicative que vous maîtrisez.
Faut-il sauvegarder les fichiers en plus de la base ?
Oui, obligatoirement. Odoo stocke une partie des pièces jointes hors de la base. Une restauration avec la seule base vous rend un système qui fonctionne et dont toutes les pièces jointes sont introuvables. Les deux se sauvegardent ensemble et se restaurent ensemble.
À quelle fréquence sauvegarder ?
Cela découle d’une question de gestion, pas d’une norme : combien d’heures de saisie acceptez-vous de perdre ? Pour un ERP qui encaisse des commandes toute la journée, une sauvegarde quotidienne signifie perdre jusqu’à une journée de travail. C’est une décision à prendre en connaissance de cause, pas un réglage par défaut.
Comment savoir si une sauvegarde est bonne ?
En la restaurant. Il n’y a pas d’autre méthode. Un fichier de sauvegarde qui existe, qui pèse le bon poids et qui est daté d’hier peut être inexploitable — dump interrompu, version incompatible, fichiers manquants. Tant qu’une restauration n’a pas été jouée, vous avez des fichiers, pas des sauvegardes.
Combien de temps pour repartir après un incident ?
Cela se mesure une fois, à froid, en le faisant. Le chiffre surprend souvent : entre récupérer l’archive, remonter un serveur, restaurer, vérifier et rebasculer, il s’écoule facilement plusieurs heures. Autant le savoir avant, et le décider, plutôt que le découvrir un mardi matin.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.