Un guide de sauvegarde des bases de données

«Oh, aucun abri ne peut résister à un impact de météore. Mais vous, comme tout le monde, avez une réserve, alors ne vous inquiétez pas.



Stanislav Lem, "Les journaux intimes d'Iyon le Tikhoi"

La sauvegarde consiste à conserver une copie de vos données quelque part en dehors de l'emplacement de stockage principal.







Le but principal de la sauvegarde est de récupérer les données après leur perte. À cet égard, nous entendons souvent dire que si vous avez une réplique d'une base de données, vous pouvez toujours restaurer les données à partir de celle-ci, et vous n'avez pas besoin d'une sauvegarde. En fait, la sauvegarde vous permet de résoudre au moins trois tâches qui ne peuvent pas être résolues à l'aide d'une réplique, et une réplique ne peut pas être initialisée sans sauvegarde.



Tout d'abord, une sauvegarde vous permet de récupérer des données après une erreur logique. Par exemple, un comptable a supprimé un groupe de transactions ou un DBA a détruit un tablespace. Les deux opérations sont absolument légitimes du point de vue de la base de données, et le processus de réplication les reproduira dans la base de données réplique.



Deuxièmement, les SGBD modernes sont des systèmes logiciels très fiables, mais des dommages occasionnels aux structures internes de la base de données se produisent, après quoi l'accès aux données est perdu. Ce qui est particulièrement offensant, une telle violation se produit généralement à charge élevée ou lors de l'installation d'une sorte de mise à jour. Mais la charge élevée et les mises à jour régulières indiquent que la base de données n'est pas une base de données de test et que les données qui y sont stockées sont précieuses.



Enfin, la troisième tâche, dont la solution nécessite une copie de sauvegarde, est le clonage de la base de données, par exemple à des fins de test.



La sauvegarde de la base de données est en quelque sorte basée sur l'un des deux principes suivants:

• Récupération des données avec sauvegarde ultérieure dans un format arbitraire;
• Instantané des fichiers de base de données et enregistrement des journaux.

Examinons de plus près ces principes et les outils qui les mettent en œuvre.

Téléchargement de données

L'ensemble des utilitaires fournis avec tout SGBD doit avoir des outils pour télécharger et télécharger des données. Les données sont stockées soit au format texte, soit dans un format binaire spécifique à un SGBD particulier. Le tableau ci-dessous répertorie ces outils:





Le format texte est bon car il peut être édité ou même créé par des programmes externes, et le format binaire, à son tour, est bon car il vous permet de décharger et de charger rapidement des données en parallélisant le téléchargement et en économisant des ressources lors de la conversion de format.



Malgré la simplicité et l'évidence de l'idée de télécharger des données, cette méthode est rarement utilisée pour sauvegarder des bases industrielles chargées. Voici les raisons pour lesquelles le déchargement ne convient pas pour une sauvegarde complète:

• le processus de déchargement crée une charge importante sur le système source;
• le déchargement prend beaucoup de temps - au moment où le déchargement sera terminé, cela deviendra inutile;
• il est presque impossible de procéder à un déchargement cohérent de la base de données entière sous une charge élevée, car le SGBD est obligé de conserver un instantané de son état au moment du début du déchargement. Plus il y a de transactions validées depuis le début du téléchargement, plus le volume de snapshot est important (copies non pertinentes de données dans PostgreSQL, annulation d'espace dans Oracle, tempdb dans Microsoft SQL Server, etc.);
• le déchargement préserve la structure logique des données, mais ne préserve pas leur structure physique - paramètres de stockage physique des tables, index, etc. la reconstruction des index au démarrage peut prendre du temps.

Néanmoins, le déchargement présente des avantages:

• sélectivité élevée: vous pouvez décharger des tables individuelles, des champs individuels et même des lignes individuelles;
• les données téléchargées peuvent être chargées dans une base de données d'une autre version, et si le téléchargement est effectué au format texte, puis dans une autre base de données.

Ainsi, le déchargement est principalement utilisé pour des tâches telles que la sauvegarde de petites tables (par exemple, des répertoires) ou la distribution de jeux de données avec la prochaine version de l'application.



La méthode la plus courante de sauvegarde de bases de données consiste à copier les fichiers de base de données.

Sauvegarde "à froid" des fichiers de la base de données

L'idée évidente est d'arrêter la base de données et de copier tous ses fichiers. C'est ce qu'on appelle une sauvegarde à froid. La méthode est extrêmement fiable et simple, mais elle présente deux inconvénients évidents:

• à partir d'une sauvegarde à froid, vous ne pouvez restaurer que l'état de la base de données qui était au moment de l'arrêt; les transactions effectuées après le redémarrage de la base de données ne seront pas incluses dans la sauvegarde «à froid»;
• toutes les bases de données n'ont pas de fenêtre technologique lorsque la base de données peut être arrêtée.

Si vous êtes satisfait des sauvegardes à froid, n'oubliez pas que

• «» . , «» , . , Oracle online redo, , , . PostgreSQL , , .
• , . , «» .

«»

La plupart des sauvegardes de base de données modernes sont effectuées en copiant les fichiers de base de données sans arrêter la base de données. Plusieurs problèmes sont visibles ici:

• Au début de la copie, le contenu de la base de données peut ne pas coïncider avec le contenu des fichiers, car certaines informations se trouvent dans le cache et n'ont pas encore été écrites sur le disque.
• Pendant la copie, le contenu de la base de données peut changer. Si des structures de données mutables sont utilisées, le contenu des fichiers change, et lorsque des structures immuables sont utilisées, l'ensemble des fichiers change: de nouveaux fichiers apparaissent et les anciens sont supprimés.
• Étant donné que l'écriture des données dans la base de données et la lecture des fichiers de la base de données ne sont en aucun cas synchronisées, le programme de sauvegarde peut lire une page incorrecte, dont la moitié proviendra de l'ancienne version de la page et l'autre moitié de la nouvelle.

Pour que la sauvegarde soit cohérente, chaque SGBD dispose d'une commande qui informe que le processus de sauvegarde a commencé. Syntaxiquement, cette commande peut être différente:

• dans Oracle, il s'agit d'une commande distincte ALTER DATABASE / TABLESPACE BEGIN BACKUP;
• dans PostgreSQL, la fonction pg_start_backup ();
• sur Microsoft SQL Server et DB2, la préparation d'une sauvegarde est implicite lors de la commande BACKUP DATABASE;
• dans MySQL Enterprise, Percoba Server, Cassandra et MongoDB, la préparation est implicitement effectuée par un utilitaire externe - mysqlbackup, Percona XtraBackup, OpsCenter et Ops Manager, respectivement.

Malgré les différences syntaxiques, le processus de préparation d'une sauvegarde se présente de la même manière.



Voici à quoi ressemble la préparation des sauvegardes dans un SGBD avec des structures de disque variables, c'est-à-dire dans tous les systèmes relationnels de disque traditionnels:

1. Le moment du début de la sauvegarde est mémorisé; la sauvegarde devra désormais contenir les journaux de la base de données.
2. Un point de contrôle est effectué, c'est-à-dire que toutes les modifications qui se sont produites dans les pages de données jusqu'à ce moment précis sont vidées sur le disque. Cela garantit qu'aucun journal n'est requis avant le début de la sauvegarde pendant la restauration.
3. : , , , . , . , . , , .
4. , , . , , .

Une fois toutes les procédures ci-dessus terminées, vous pouvez copier des fichiers de données à l'aide des outils du système d'exploitation - cp, rsync et autres. L'activation du mode de sauvegarde réduit les performances de la base de données: d'une part, le volume des journaux augmente, et d'autre part, si soudainement une panne survient en mode de sauvegarde, la récupération prendra plus de temps, car les en-têtes des fichiers de données ne sont pas mis à jour. Plus la sauvegarde est effectuée rapidement, mieux c'est pour la base de données, il est donc approprié d'utiliser des outils tels qu'un instantané du système de fichiers ou une rupture de miroir (BCV) dans une matrice de disques. Certains SGBD (Oracle, PostgreSQL) laissent à l'administrateur la possibilité de choisir indépendamment la méthode de copie,d'autres (Microsoft SQL Server) fournissent une interface pour intégrer des utilitaires de sauvegarde natifs avec un système de fichiers ou des moteurs de stockage.



Lorsque la sauvegarde est terminée, vous devez ramener la base de données à son état normal. Dans Oracle, cela se fait avec la commande ALTER DATABASE / TABLESPACE END BACKUP, dans PostgreSQL, en appelant la fonction pg_stop_backup (), et dans d'autres bases de données, par des routines internes des commandes correspondantes ou des services externes.



Voici à quoi ressemble la chronologie du processus de sauvegarde:

• La préparation de la sauvegarde (commencer la sauvegarde) prend du temps, parfois considérable. Même si des volumes en miroir ou des systèmes de fichiers de clichés sont utilisés, le processus de sauvegarde ne sera pas instantané.
• Avec les fichiers de données, il est nécessaire de sauvegarder les journaux à partir du moment où la préparation de la sauvegarde a commencé et se terminant avec le moment où la base de données est revenue à son état normal.
• Vous pouvez récupérer à partir de cette sauvegarde au moment où la base de données revient à son état normal . La récupération à un moment antérieur n'est pas possible.

Avec des bases de données utilisant des structures de données immuables (instantanés, arborescences LSM), la situation est plus simple. La préparation de la sauvegarde comprend les étapes suivantes:

1. Les données de la mémoire sont vidées sur le disque.
2. La liste des fichiers inclus dans la sauvegarde est enregistrée. Tant que le processus de sauvegarde n'est pas terminé, il est interdit à la base de données de supprimer ces fichiers, même s'ils ne sont plus nécessaires.

Lors d'un signal de fin de sauvegarde, une base de données avec des structures immuables peut à nouveau supprimer les fichiers inutiles.

Récupération de points

La sauvegarde permet de restaurer l'état de la base de données au moment où la commande de retour du mode sauvegarde est terminée. Cependant, un sinistre nécessitant une récupération peut survenir à tout moment. La tâche de restauration de l'état de la base de données à un moment arbitraire est appelée récupération à un moment donné.



Pour ce faire, vous devez enregistrer les journaux de la base de données à partir du moment où la sauvegarde est terminée et continuer à appliquer les journaux à la copie restaurée pendant le processus de restauration. Une fois la base de données restaurée à partir d'une copie de sauvegarde à la fin de la copie, l'état de la base de données (fichiers et pages en cache) est garanti correct, de sorte qu'un mode de journalisation spécial n'est pas nécessaire. En appliquant les journaux jusqu'au moment souhaité, vous pouvez obtenir l'état de la base de données à tout moment.



Si la vitesse de restauration d'une sauvegarde est limitée uniquement par la bande passante du disque, la vitesse d'application des journaux est généralement limitée par les performances du processeur. Si des modifications dans la base de données principale se produisent en parallèle, pendant la récupération, toutes les modifications sont effectuées de manière séquentielle - dans l'ordre où elles ont été lues dans le journal. Par conséquent, le temps de récupération dépend linéairement de la distance entre le point de récupération et le point final de la sauvegarde. Pour cette raison, vous devez effectuer des sauvegardes complètes assez souvent - au moins une fois par semaine pour les bases de données à faible charge transactionnelle et avant la copie quotidienne de bases de données très chargées.

Sauvegardes incrémentielles

Pour accélérer la récupération point à point, j'aimerais pouvoir effectuer des sauvegardes aussi souvent que possible, mais en même temps, ne pas prendre d'espace disque supplémentaire et ne pas surcharger la base de données avec des tâches de sauvegarde.



La solution au problème est une sauvegarde incrémentielle, c'est-à-dire ne copiant que les pages de données qui ont changé depuis la sauvegarde précédente.

Les sauvegardes incrémentielles n'ont de sens que pour les SGBD qui utilisent des structures de données modifiables.



L'incrément peut être calculé à la fois à partir de la sauvegarde complète (copie cumulative) et de toute copie précédente (copie différentielle).







Malheureusement, il n'y a pas de terminologie uniforme et différents fabricants utilisent des termes différents:





Avec les sauvegardes incrémentielles, le processus de restauration point à point ressemble à ceci:

• la dernière sauvegarde complète effectuée avant la restauration de la restauration;
• les copies incrémentielles sont restaurées sur la copie complète;
• fait rouler les journaux du point où la sauvegarde a commencé au point de récupération.

Avoir une copie cumulative accélère le processus de récupération. Ainsi, par exemple, pour restaurer l'état de base à un point entre T3 et T4, vous devez restaurer deux copies incrémentielles et restaurer à un point après T4 - un seul.

Évidemment, le volume d'une copie cumulative est inférieur au volume de plusieurs copies différentielles, car certaines pages ont changé plusieurs fois et chaque copie incrémentielle contient sa propre version de la page.



Il existe trois façons de créer une copie incrémentielle:

1. créer une copie complète et calculer la différence avec la copie complète précédente;
2. analyse des journaux, création d'une liste des pages modifiées et sauvegarde des pages incluses dans la liste;
3. demande de pages modifiées dans la base de données.

La première méthode économise de l'espace disque, mais ne résout pas le problème de la réduction de la charge sur la base de données. De plus, si nous avons une sauvegarde complète, il est inutile de la transformer en sauvegarde incrémentielle, car la restauration d'une sauvegarde complète est plus rapide que la restauration d'une copie complète précédente et d'un incrément. Avec cette approche, il est préférable de transférer la tâche d'économie d'espace disque vers des composants spéciaux dotés de mécanismes de déduplication intégrés. Il peut s'agir de systèmes de stockage spéciaux (EMC DataDomain, HPE StorageWorks VLS, toute la gamme NetApp) ou de produits logiciels (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).



Les deuxième et troisième méthodes diffèrent par le mécanisme de détermination de la liste des pages modifiées. L'analyse des journaux est plus gourmande en ressources, et vous devez connaître la structure des fichiers journaux pour l'implémenter. Il est plus facile de demander à la base de données elle-même quelles pages ont changé, mais pour cela le noyau du SGBD doit avoir la fonctionnalité de suivi des blocs modifiés (suivi des modifications de bloc).



La fonctionnalité de sauvegarde incrémentielle a été introduite pour la première fois avec le logiciel Oracle Recovery Manager (RMAN), qui a été introduit avec la version Oracle 8i. Oracle a immédiatement mis en œuvre le suivi des blocs modifiés, il n'est donc pas nécessaire d'analyser les journaux.



PostgreSQL ne suit pas les blocs modifiés, donc l'utilitaire pg_probackup, développé par la société russe Postgres Professional, détecte les pages modifiées en analysant le journal. Cependant, la société fournit également PostgresPro, qui comprend une extension ptrack qui suit les changements de page. Lors de l'utilisation de pg_probackup avec PostgresPro, l'utilitaire interroge la base de données elle-même pour les pages modifiées, tout comme le fait RMAN.



Microsoft SQL Server, comme Oracle, garde une trace des pages modifiées, mais la commande BACKUP n'autorise que des sauvegardes complètes et cumulatives.



DB2 a la capacité de suivre les pages modifiées, mais il est désactivé par défaut. Une fois activé, DB2 autorisera les sauvegardes complètes, différentielles et cumulatives.



Une différence importante entre les outils décrits dans cette section (à l'exception de pg_probackup) et les outils de sauvegarde basés sur des fichiers est qu'ils interrogent la base de données pour les images de page plutôt que de lire les données à partir du disque eux-mêmes. L'inconvénient de cette approche est la faible charge supplémentaire sur la base. Cependant, cet inconvénient est plus que compensé par le fait que la page lue est toujours correcte, il n'est donc pas nécessaire d'activer un mode de journalisation spécial pendant la sauvegarde.



Notez à nouveau que la présence de sauvegardes incrémentielles ne remplace pas l'exigence de restauration des journaux à un moment arbitraire. Par conséquent, dans les bases de données industrielles, les journaux sont constamment réécrits sur des supports externes et des sauvegardes, complètes et / ou incrémentielles, sont créées selon un calendrier.



La meilleure implémentation de l'idée de sauvegarde incrémentielle aujourd'hui est le Zero Data Loss Recovery Appliance (système conçu selon la terminologie Oracle) - une solution Oracle spécialisée pour sauvegarder sa propre base de données. Le complexe est un cluster de serveurs avec un grand volume de disques, sur lesquels une version modifiée du logiciel Recovery Manager est installée et peut fonctionner à la fois avec d'autres complexes logiciels et matériels Oracle (Database Appliance, Exadata, SPARC Supercluster) et avec des bases de données Oracle sur une infrastructure traditionnelle. Contrairement au RMAN «normal», ZDLRA implémente le concept «incrémental pour toujours». Le système crée une copie complète de la base de données une seule fois, puis effectue uniquement des copies incrémentielles. Des modules RMAN supplémentaires vous permettent de fusionner des copies,créer de nouvelles copies complètes à partir de copies incrémentielles.



Au crédit des développeurs russes, il faut noter que pg_probackup est également capable de combiner des copies incrémentielles.







Contrairement à de nombreuses questions similaires, la question «quelle méthode de sauvegarde est la meilleure» a une réponse sans ambiguïté - le meilleur est l'utilitaire natif pour le SGBD utilisé qui offre la possibilité de sauvegardes incrémentielles.



Pour le DBA, les problèmes les plus importants sont le choix de la stratégie de sauvegarde et l'intégration des sauvegardes de base de données dans l'infrastructure de l'entreprise. Mais ces questions sortent du cadre de cet article.