Vos sauvegardes d’applications auto-hébergées sont-elles cohérentes ? Testez la base de données, les fichiers et l’ordre de restauration
La réussite d’une tâche de sauvegarde ne prouve pas qu’une application auto-hébergée peut être restaurée avec ses enregistrements et ses pièces jointes synchronisés. Recensez les éléments à sauvegarder, vérifiez comment ils sont capturés et testez une restauration représentative.

Une sauvegarde peut réussir alors que l’application n’est toujours pas synchronisée
Une application métier peut stocker ses enregistrements dans une base de données et ses fichiers téléversés dans un répertoire distinct ou un service de stockage. Les sauvegardes de ces composants peuvent être lisibles individuellement tout en correspondant à des moments différents. Après une restauration, un enregistrement peut faire référence à une pièce jointe manquante, ou un fichier peut exister sans l’enregistrement qui y est associé.
L’objectif est de déterminer si l’application peut être reconstruite à partir d’un ensemble de sauvegardes compatibles, et pas seulement si des fichiers de sauvegarde ont été créés. Un rapport de tâche réussi indique qu’un processus s’est exécuté ; à lui seul, il ne prouve pas que le service complet peut être restauré.
- Choisissez un enregistrement représentatif auquel est associé une pièce jointe ou un autre fichier lié.
- Déterminez où sont stockés l’enregistrement, le fichier et le lien qui les relie.
- Examinez les calendriers de sauvegarde distincts sans en déduire, à eux seuls, que les composants sont ou ne sont pas coordonnés.

Recensez les éléments dont l’application a besoin
Consultez la documentation de l’application et les paramètres de déploiement pour déterminer ce qui doit être présent lors d’une restauration. Ne partez pas du principe que la base de données constitue à elle seule l’ensemble du service ou que les fichiers sont stockés à côté. Si vous ne pouvez pas examiner un composant, demandez au fournisseur d’hébergement de préciser ce qui est couvert.
Les instructions d’une application peuvent définir les sauvegardes comme étant composées de plusieurs éléments. Par exemple, le guide de sauvegarde de Hudu pour les installations auto-hébergées décrit une sauvegarde complète comme comprenant deux parties distinctes et indique qu’une base de données PostgreSQL est l’une d’elles. Consultez les instructions de votre application pour déterminer les composants nécessaires : [Assistance Hudu : sauvegardes et restaurations auto-hébergées](https://support.hudu.com/hc/en-us/articles/11653994397079-Self-Hosted-Backups-and-Restores).
- La base de données et les fichiers persistants, notamment les pièces jointes et les autres contenus téléversés.
- La configuration ainsi que les identifiants, clés de chiffrement ou jetons nécessaires à la récupération.
- Le stockage externe ou les services dont dépend l’application.
- Les versions de l’application et de la base de données, ou les détails de déploiement requis par la procédure de restauration documentée.

Vérifiez comment et quand chaque composant est capturé
Demandez si les composants associés sont capturés ensemble ou selon des calendriers indépendants. Réfléchissez à ce qui se passe si des utilisateurs modifient des enregistrements ou téléversent des fichiers, ou si des tâches d’arrière-plan modifient des données pendant une sauvegarde.
Suivez la procédure de sauvegarde documentée pour votre base de données et votre application. Ne présumez pas qu’une méthode de capture convient à tous les systèmes.
- Les sauvegardes de la base de données et des fichiers sont-elles effectuées ensemble ou selon des calendriers distincts ?
- Si elles sont séparées, comment le processus garantit-il qu’elles correspondent à un état compatible de l’application ?
- Comment les modifications en cours, les téléversements, les tâches planifiées et les traitements en arrière-plan sont-ils gérés lors de la capture ?
- L’application documente-t-elle une procédure de sauvegarde ou de maintenance à suivre ?
Confirmez la portée des sauvegardes d’hébergement
Le mot « sauvegarde » ne précise pas ce qu’un processus d’hébergement inclut. Confirmez si la base de données, le stockage persistant des fichiers et les autres données nécessaires à l’application sont couverts, et si les composants associés sont coordonnés.
Airbip exécute les instances d’applications sous forme de charges de travail Docker sur des serveurs cloud Airbip et propose des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ces fonctionnalités ne permettent pas, à elles seules, de déterminer ce qu’inclut une sauvegarde donnée, comment les composants sont coordonnés ni ce qu’une restauration récupérera. Vérifiez la portée et le processus de restauration applicables à votre instance plutôt que de les déduire du calendrier.
Consignez les réponses obtenues et les tâches de récupération qui vous incombent, notamment qui demande une restauration et qui la valide.
- Quelles données et quels emplacements de stockage sont inclus ? Qu’est-ce qui est exclu ou traité séparément ?
- Le fournisseur peut-il confirmer comment sont capturées la base de données et les données de fichiers ?
- Qui lance une restauration, fournit les informations nécessaires sur l’application et vérifie le service restauré ?
- Où consulter le calendrier de sauvegarde actuel et les conditions de service applicables ?
Restaurez l’application conformément à ses instructions
Il n’existe pas d’ordre de restauration universel pour toutes les applications auto-hébergées. Suivez les instructions officielles de restauration de l’application et la procédure applicable à votre hébergement. Vérifiez les dépendances avant de commencer et déterminez à quel moment vous pouvez démarrer l’application ou reconnecter les utilisateurs et les tâches d’arrière-plan.
Sauf si votre plan prévoit explicitement une autre approche, utilisez un environnement de test isolé. Pendant le test, séparez les données restaurées de l’environnement de production.
- Confirmez l’environnement cible et les accès nécessaires pour y effectuer la restauration.
- Récupérez la configuration et les secrets nécessaires en suivant la procédure sécurisée appropriée.
- Restaurez la base de données et les fichiers selon la procédure documentée.
- Notez les composants qui doivent être recréés ou reconnectés plutôt que restaurés à partir d’une sauvegarde.
Testez les enregistrements liés et le fonctionnement de l’application
Un test de restauration fournit des éléments concrets attestant que les sauvegardes sont utilisables. Choisissez un ensemble de sauvegardes représentatif et testez-le dans un environnement isolé. Vérifiez des enregistrements ordinaires ainsi que des enregistrements avec pièces jointes, et pas seulement le démarrage de la base de données ou de l’application.
Comparez les données restaurées à des exemples connus de l’environnement source, notamment aux modifications récentes qui devraient figurer dans la sauvegarde sélectionnée. Si un élément manque, consignez le problème et cherchez s’il est lié à la portée de la sauvegarde, au moment de la capture, à la procédure de restauration ou à une dépendance externe.
- Ouvrez des enregistrements représentatifs et vérifiez que leurs pièces jointes ou fichiers liés sont accessibles.
- Vérifiez les enregistrements récents et les modifications qui devraient figurer dans la sauvegarde sélectionnée.
- Lorsque l’application permet de le vérifier, recherchez les fichiers orphelins ou les enregistrements qui pointent vers des fichiers manquants.
- Testez un flux de travail normal de l’application, et pas seulement la réussite de la connexion.
- Consignez les erreurs, les données manquantes et les éventuelles étapes de récupération manuelles.
Documentez et réexaminez le plan de récupération
Conservez un bref relevé des sauvegardes à un endroit où le personnel chargé de la récupération peut le trouver. Distinguez les informations confirmées des suppositions et des questions sans réponse. Un calendrier de sauvegarde indique la fréquence à laquelle des sauvegardes peuvent être effectuées ; à lui seul, il ne précise ni la durée de conservation, ni la couverture, ni la cohérence.
Réexaminez ce relevé lorsque l’application, le stockage, la configuration ou l’hébergement change, et périodiquement selon vos besoins opérationnels. Si un détail important n’est toujours pas confirmé, marquez-le comme non vérifié et décidez s’il faut obtenir une réponse documentée ou effectuer un test.
- Consignez la couverture, les exclusions, le calendrier, la durée de conservation et le processus d’accès aux données de sauvegarde une fois ces éléments confirmés.
- Désignez les personnes qui contacteront le fournisseur, fourniront les informations propres à l’application et valideront une restauration.
- Conservez les résultats datés des tests de restauration, y compris les vérifications échouées et les actions de suivi.
- Après des changements, revérifiez les dépendances et répétez les tests de restauration pertinents.
Questions fréquentes
Est-ce suffisant si la base de données et les fichiers sont tous deux sauvegardés ?
Pas nécessairement. Ils peuvent avoir été capturés à des moments différents, ou une sauvegarde peut omettre un autre composant nécessaire à l’application. Vérifiez ce qui est couvert et testez une restauration avec des enregistrements liés à des fichiers.
Quel est le bon ordre pour restaurer une application auto-hébergée ?
Il n’existe pas d’ordre unique pour toutes les applications. Suivez les instructions officielles de restauration de l’application et la procédure applicable à votre hébergement, puis vérifiez les dépendances avant de redémarrer le service.
Une sauvegarde d’hébergement garantit-elle la synchronisation des pièces jointes et de la base de données ?
Un calendrier ne permet pas à lui seul de déterminer ce qui est inclus ni comment les composants sont capturés. Demandez des précisions sur la couverture, les exclusions et le processus de restauration pour votre instance.
Comment savoir si un test de restauration a réussi ?
Ne vérifiez pas seulement si le service démarre. Contrôlez des enregistrements et des pièces jointes représentatifs, les modifications récentes qui devraient figurer dans la sauvegarde sélectionnée, ainsi qu’un flux de travail normal de l’application. Consignez les données manquantes, les erreurs ou les étapes de récupération manuelles.
Sources et lectures complémentaires
- Self-Hosted: Backups and Restores — Hudu Support
- Self-hosting without panic (10/12): Backups that restore — Stackademic
- How often do you test a full restore of your self-hosted ... — Reddit