12 erreurs courantes lors de la sauvegarde des bases de données

par Alexey Kovyazin, 11 novembre 2015

Télécharger le PDF (anglais) Cet article était initialement destiné aux développeurs et administrateurs de SGBD Firebird, mais les contacts avec les administrateurs d’autres bases de données ont clairement montré que la plupart des erreurs sont également courantes parmi eux et que littéralement tout le monde trébuche sur à peu près les mêmes pierres. Si vous pouvez ajouter quelque chose à cette liste (même quelque chose de spécifique à un SGBD particulier), contactez-nous via notre e-mail [email protected].

1. Supprimer la copie de sauvegarde précédente avant qu’une nouvelle copie de sauvegarde ne soit créée

Cette erreur est la plus courante parmi les débutants qui ne réalisent pas que l’objectif principal d’une copie de sauvegarde de base de données n’est pas seulement de créer une copie de la base de données, mais de rendre le temps d’arrêt d’un système d’information (dont la base de données est une partie importante) aussi court que possible.

En conséquence, le système reste sans protection depuis le moment où la dernière copie de sauvegarde est supprimée jusqu’au moment où la nouvelle est créée, car la base de données ne dispose d’aucune copie de sauvegarde pendant cette période. Étant donné que la création d’une copie de sauvegarde peut prendre un certain temps, c’est le moment idéal pour que la loi de Murphy s’applique. Cette approche fonctionne particulièrement bien lorsqu’elle est combinée avec le problème 7 (voir ci-dessous).

Recommandations : ne supprimez pas la copie de sauvegarde précédente avant que la nouvelle ne soit créée ! (et ne créez pas une nouvelle copie de sauvegarde dans un fichier existant).

Recommandation pour Firebird : il existe un outil FBDataGuard inclus dans HQbird (un package de distribution avancé de Firebird) qui supprime la copie de sauvegarde la plus ancienne de l’historique seulement après qu’une nouvelle a été créée.

2. Écraser une base de données existante lors de sa restauration à partir d’une copie de sauvegarde

Cette erreur est moins courante, bien que les résultats puissent être bien pires. Si la copie de sauvegarde n’a pas été vérifiée et s’avère corrompue (voir problème 6), vous n’aurez ni la copie précédente de la base de données ni une copie de sauvegarde valide.

Un gâchis comme celui-ci se produit généralement un vendredi soir, quand les choses s’emballent et que les directives de la direction sont quelque peu contradictoires. Un peu de malchance et un week-end languissant dans la salle des serveurs vous attendent.

Firebird dispose d’une sorte de protection contre cette erreur - il ne sera pas possible de restaurer une base de données à partir d’une copie de sauvegarde à l’aide de l’utilitaire gbak si son commutateur -create par défaut est activé et si le nom de fichier spécifié pointe vers une base de données existante. Malheureusement, il existe un moyen de contourner cette protection : le commutateur -rep permet toujours d’écraser le fichier existant.

Recommandation : n’écrasez jamais le fichier d’une base de données en fonctionnement sans une directive écrite de votre direction.

Recommandation pour Firebird : utilisez FBDataGuard car il n’écrase jamais le fichier de la base de données.

3. Utiliser une sauvegarde/restauration en une seule étape sans utiliser de fichier de sauvegarde intermédiaire

Les flux d’entrée/sortie standard permettent de réaliser une astuce amusante avec de nombreux SGBD (y compris Firebird) : mettre en œuvre une sauvegarde en flux avec restauration de la base de données à partir de celle-ci en une seule fois. Aucun fichier de sauvegarde intermédiaire n’est créé en conséquence. C’est pratique pour la maintenance de routine et pour exécuter une opération de restauration de test (à condition qu’une autre copie de sauvegarde soit disponible), mais vous ne devez pas l’utiliser pour la sauvegarde automatique !

Par exemple, si une grave défaillance de disque survient pendant ce processus de sauvegarde/restauration, la base de données initiale peut être endommagée alors qu’aucune nouvelle base de données n’a encore été créée. Bien sûr, si vous tenez compte du problème 1 et qu’il existe une copie de la base de données issue de la tentative précédente, seules les données créées ou mises à jour dans la base de données après la création de cette copie seront perdues.

Recommandations : n’utilisez pas la sauvegarde/restauration en une seule étape en mode automatique et vérifiez toujours la disponibilité d’une copie suffisamment à jour en mode manuel.

4. Stocker les copies de sauvegarde et la base de données sur un même dispositif physique

Beaucoup d’entre vous trouveront amusant que le conseil que nous donnons soit un peu enfantin - l’ABC de la sauvegarde. C’est vrai, mais la base de données et le disque peuvent finir par être stockés sur un même système de stockage en raison de la popularité des environnements virtuels. Et cela échouera certainement au moment le plus inopportun. De plus, il y a encore des gens qui croient que rien ne peut arriver à leurs données s’ils utilisent des matrices RAID (version 1 ou supérieure :)). En outre, il y a des gens qui croient que certains serveurs de « marque » sont infaillibles, mais c’est un cas particulier.

Recommandations : ne stockez pas les copies de sauvegarde et la base de données sur un même dispositif, aussi fiable qu’il puisse paraître.

5. Aucun contrôle sur la bonne exécution du processus de sauvegarde

C’est une erreur assez courante parmi les administrateurs comme parmi les responsables de services informatiques. Si vous ne vérifiez pas les résultats du processus de sauvegarde, autant ne pas l’exécuter du tout. Vous devez recevoir des notifications concernant la bonne exécution du processus de sauvegarde par e-mail ou, mieux encore, également par SMS. Et l’absence de telles notifications est le signe d’un problème !

Un lecteur attentif qui a atteint ce point de notre article (bien qu’il soit encore trop tôt pour décerner un prix pour cela) pourrait demander : « Mais quel est le rapport avec la direction ? » Voici : l’administrateur configure généralement le processus de sauvegarde, mais il trouve trop ennuyeux de vérifier les notifications, surtout lorsqu’elles sont stockées dans un dossier séparé, donc il n’est jamais superflu de demander des rapports supplémentaires sur l’état du processus. C’est à propos de la question de savoir qui est à blâmer quand il semble que les copies de sauvegarde étaient là, mais qu’elles ne sont en réalité pas là au moment où vous en avez besoin :)

! une fois combiné avec le problème 2, nous n’avons ni la base de données ni sa copie de sauvegarde.

Recommandations : utilisez des outils d’automatisation de sauvegarde capables de surveiller les processus de sauvegarde réussis et infructueux, de notifier les utilisateurs des problèmes et d’offrir des outils de contrôle récapitulatif (c’est particulièrement pertinent lorsque vous devez contrôler des dizaines et des centaines de processus de sauvegarde sur différents serveurs).

Recommandation pour Firebird : FBDataGuard vérifie si le processus de sauvegarde a été mené à bien et envoie la notification correspondante. Pour les systèmes comportant de nombreuses bases de données, il existe une surveillance récapitulative de second niveau à l’aide de l’outil Control Center qui vous permet de voir les états de tous les serveurs et bases de données surveillés sur une seule page.

6. Aucune validation des sauvegardes

Le fait que des copies de sauvegarde soient stockées quelque part ne signifie pas qu’elles peuvent être lues à partir de là.

C’est pourquoi vous devez régulièrement vérifier les copies de sauvegarde que vous créez afin de vous assurer qu’elles ne sont pas corrompues ou copiées vers /dev/null.

Recommandation pour Firebird : vous pouvez automatiser la validation des sauvegardes à l’aide de FBDataGuard.

7. Aucune vérification de l’état de la base de données lors de l’utilisation de copies de sauvegarde non vérifiées

Habituellement, les bases de données utilisent plusieurs types de sauvegarde - dumps, copies de sauvegarde régulières, etc. Sans entrer dans les détails, nous pouvons distinguer deux catégories : vérifiées et non vérifiées. Dans le cas de Firebird, il s’agit de gbak et nbackup.

Gbak lit toute la base de données au niveau des enregistrements afin de créer un fichier de sauvegarde et crée une base de données en insérant des enregistrements dans une nouvelle base de données, vérifiant ainsi la copie de sauvegarde (il existe des moyens pour que des erreurs se glissent dans la copie restaurée, mais c’est une autre façon pour l’administrateur de base de données de gâcher les choses en lien avec une migration mal organisée) et la base de données elle-même (si elle peut être lue du début à la fin, elle n’est très probablement pas corrompue).

Nbackup (alias sauvegarde incrémentielle) verrouille temporairement le fichier principal de la base de données pour les mises à jour (dans l’état cohérent) et permet de copier rapidement le fichier de la base de données (complètement ou partiellement/incrémentalement).

Dans le cas de grandes bases de données Firebird (supérieures à 500 Go), il est conseillé d’utiliser nbackup afin de ne pas ralentir les opérations des utilisateurs, mais en même temps il est nécessaire de valider la base de données car les copies de sauvegarde non vérifiées qu’il crée sont des copies de pages de la base de données et si une erreur réside au niveau des enregistrements (en raison d’une défaillance de la RAM) ou au niveau logique, une copie de sauvegarde non vérifiée la contiendra tout comme la base de données d’origine.

Pour éviter cela, vous devez utiliser la validation en ligne pour la base de données d’origine (la validation en ligne à l’aide de gfix est disponible à partir de la version 2.5.4 de Firebird, tandis que notre outil FBDataGuard prend en charge la validation en ligne des bases de données pour les versions 1.5-2.5).

De plus, il est conseillé d’effectuer une sauvegarde vérifiée de temps en temps (une fois par semaine, par exemple) en plus de la sauvegarde non vérifiée.

Recommandation pour Firebird : outre la vérification de l’état en ligne, FBDataGuard vous permet de tester le processus de restauration de sauvegarde en mode automatique.

8. Aucun contrôle de l’espace libre pour les copies de sauvegarde

En fait, c’est une erreur classique : s’il n’y a pas assez d’espace, les copies de sauvegarde occupent tout l’espace libre et le processus se termine par une erreur. Stocker les copies de sauvegarde sur un même disque que la base de données peut entraîner une interruption du fonctionnement de la base de données et les stocker sur le disque système peut entraîner une défaillance du système.

En combinaison avec le problème 4, le meilleur résultat possible sera celui où le système cesse de fonctionner parce que la base de données a aussi besoin d’espace libre, mais celui-ci est occupé par les copies de sauvegarde. Quant à la combinaison avec les problèmes 5 et 2, elle nous laisse à nouveau sans base de données ni copie de sauvegarde.

Recommandations : utilisez des outils de sauvegarde qui prédisent la taille de la sauvegarde et vous avertissent du manque possible d’espace libre.

Recommandation pour Firebird : FBDataGuard contrôle la taille de l’espace libre à des fins de sauvegarde ainsi que la taille de l’espace libre sur le disque contenant les bases de données ainsi que sur le disque système.

9. Aucun contrôle du temps nécessaire à la création d’une copie de sauvegarde

Le processus de sauvegarde prenait 40 minutes il y a littéralement six mois et puis soudainement il prend déjà trois heures - pourquoi donc ? La taille de la base de données a peut-être augmenté ou un disque a peut-être lâché dans votre matrice RAID, entraînant des performances d’écriture considérablement réduites, et toutes vos copies de sauvegarde sont peut-être sur le point de quitter ce monde. Ou un bon collègue a peut-être lancé un autre système de sauvegarde en même temps (d’ailleurs, Firebird vous permet de lancer plusieurs processus de sauvegarde à la fois, bien qu’on ne voie pas très bien pourquoi on pourrait en avoir besoin). Si vous ne contrôlez pas le temps nécessaire à la création d’une copie de sauvegarde, vous risquez de négliger un problème nouvellement apparu et de manquer l’occasion de le corriger avant qu’il ne devienne massif.

De plus, si le système de sauvegarde ne surveille pas les états des tâches de sauvegarde et les exécute simplement selon un calendrier, vous pouvez facilement « griller les étapes », ce qui signifie la situation où le système lance un nouveau processus de sauvegarde alors que le précédent n’est pas encore terminé.

Recommandations : utilisez des outils qui contrôlent le temps que prend le processus de sauvegarde !

Recommandation pour Firebird : FBDataGuard contrôle le temps que prend le processus de sauvegarde.

10. Sauvegarder la base de données pendant l’application des mises à jour du système d’exploitation

C’est un problème très courant, surtout en combinaison avec le problème 9 et les mises à jour automatiques de Windows activées (par défaut, les mises à jour sont appliquées à 3 heures du matin). Cela entraîne au mieux un ralentissement, mais si le système d’exploitation est redémarré pour appliquer les mises à jour, la copie de sauvegarde sera endommagée. Au moins, la bonne nouvelle est que le système d’exploitation n’est pas mis à jour tous les jours.

Recommandations : planifiez les mises à jour du système d’exploitation à un moment où elles n’interfèrent pas avec le processus de sauvegarde.

11. Sauvegarder la base de données à l’aide d’outils de sauvegarde de fichiers ou d’outils de sauvegarde de machines virtuelles pendant que le serveur de base de données est en cours d’exécution

De nombreux administrateurs oublient que tout SGBD dispose d’un cache actif et complexe qui contient les données en cours de lecture et d’écriture, tandis que les fichiers de base de données eux-mêmes sont ouverts en mode accès aléatoire. C’est pourquoi il est nécessaire d’utiliser des types de sauvegarde spéciaux au lieu de la simple sauvegarde de fichiers (y compris la simple copie des fichiers de base de données) ou de la sauvegarde de machines virtuelles. Les outils de sauvegarde de fichiers lisent la base de données séquentiellement et cela peut prendre un certain temps, surtout dans le cas de grandes bases de données, il est donc impossible de garantir l’intégrité de la copie de sauvegarde créée.

Les machines virtuelles peuvent utiliser les mécanismes de snapshots et de Changed Block Tracking, mais il est nécessaire de synchroniser les copies de sauvegarde créées afin d’obtenir une copie de sauvegarde cohérente de la base de données, car la copie de sauvegarde sera incohérente en cas d’opérations d’écriture actives sur la base de données au moment du tri de la collecte des blocs modifiés.

Pour ceux qui souhaitent sauvegarder leurs bases de données à l’aide d’outils de sauvegarde de fichiers ou de machines virtuelles, nous pouvons proposer deux méthodes :

1. arrêter complètement les services et processus du SGBD afin qu’il ne reste rien dans le cache,
2. utiliser des agents et/ou des scripts qui basculent la base de données dans un mode spécial rendant sûr la copie séquentielle du fichier de base de données. Par exemple, il existe un mécanisme appelé VSS writer pour les bases de données MSSQL. Sur demande, il bascule la base de données dans le mode compatible avec les snapshots au moment où un snapshot est réalisé. Si vous utilisez des mécanismes basés sur le Changed Block Tracking, vous devez vous assurer vous-même que la base de données est cohérente au moment de la synchronisation.

Si vous ne basculez pas la base de données dans le mode compatible avec la sauvegarde, la copie de base de données obtenue sera comme si une réinitialisation forcée (par exemple, une coupure de courant) s’était produite sur l’ordinateur hôte. Ce niveau de fiabilité est absolument insuffisant pour la plupart des entreprises. Vous pouvez en apprendre davantage à ce sujet dans l’article « Particularités du travail avec les bases de données sur les machines virtuelles ».

Pour Firebird, il est nécessaire de verrouiller le fichier principal de la base de données à l’aide de nbackup avant le début du processus de sauvegarde et de le déverrouiller une fois le processus terminé. Pour les autres SGBD, il existe des outils similaires pour activer/désactiver les modes correspondants.

Certains administrateurs de bases de données sont convaincus qu’ils peuvent sauvegarder leurs bases de données en toute sécurité à l’aide d’outils de sauvegarde de fichiers standard si le SGBD dispose d’un journal de transactions, car seul ce journal sera corrompu au pire. C’est une idée fausse dangereuse que les développeurs de SGBD ne soutiennent pas.

Les racines de cette idée fausse sont claires : la publicité agressive des développeurs de machines virtuelles et d’outils de sauvegarde omet généralement de mentionner que les bases de données, comme les autres fichiers mis à jour intensivement, nécessitent une configuration avancée. Ne croyez pas au battage médiatique - tous les yaourts n’ont pas les mêmes bienfaits.

Recommandations : n’utilisez pas d’outils de sauvegarde de fichiers et de machines virtuelles sans les outils d’automatisation correspondants pour les bases de données.

Recommandation pour Firebird : utilisez FBDataGuard (fourni avec la distribution HQbird), il assure l’intégration avec les outils de sauvegarde compatibles VSS.

12. Remplacer la sauvegarde par la réplication

La sauvegarde des données et la réplication des données sont utilisées pour augmenter la fiabilité et prévenir la perte de données, mais elles restent néanmoins très différentes.

Tout le monde aime la réplication pour sa capacité à synchroniser les données sur un autre serveur avec un délai minimal, mais la sauvegarde présente également des avantages incontestés. Par exemple, en cas de suppression accidentelle (ou intentionnelle) de données, la réplication enverra rapidement et imperturbablement les modifications vers le réplica, tandis que la sauvegarde (en particulier avec des copies sur des supports en lecture seule) est immunisée contre de telles opérations. Il faut un certain effort pour configurer correctement la réplication et la sauvegarde, et la possibilité d’erreurs existe toujours.

Recommandations : si vous avez configuré la réplication, ne négligez pas les copies de sauvegarde, utilisez les deux.

Recommandation pour Firebird : utilisez la distribution HQbird Enterprise, elle inclut à la fois des outils de sauvegarde et de réplication.

Résumé

Configurer la sauvegarde pour votre SGBD préféré n’est pas si facile, c’est pourquoi les administrateurs de bases de données des organisations qui accordent de l’importance à leurs données utilisent généralement des outils de sauvegarde professionnels qui leur permettent de prendre en compte les problèmes mentionnés ci-dessus et de prévenir les difficultés.

Pour Firebird (toutes nos excuses pour la publicité), il existe un package appelé HQbird qui inclut FBDataGuard.

De plus, notre société fournit un support complet de sauvegarde et de maintenance pour Firebird et d’autres bases de données, c’est un bon choix pour ceux qui ne connaissent pas tous les détails techniques des sauvegardes.

Et, bien sûr, continuez à chérir votre paranoïa d’administrateur, par exemple, levez-vous et vérifiez vos copies de sauvegarde dès maintenant :)

Contacts

N’hésitez pas à poser toutes vos questions : [email protected]

Vous voulez recevoir des actualités et des articles sur Firebird ? Rejoignez-nous sur Telegram https://t.me/firebirdsql