Génération de Sauvegardes de Bases de Données (Français)

Génération de Sauvegardes de Bases de Données (Français)

Introduction :

La protection des données est une pierre angulaire de toute infrastructure technologique. La perte de données, qu'elle soit due à des défaillances matérielles, des erreurs humaines, des attaques malveillantes ou des catastrophes naturelles, peut avoir des conséquences désastreuses pour une organisation. Une stratégie de sauvegarde robuste et bien mise en œuvre est essentielle pour assurer la continuité des activités, la reprise après sinistre et la conformité réglementaire.

Ce document fournit un guide détaillé pour la génération de sauvegardes des types de bases de données les plus pertinents aujourd'hui, dans les environnements sur site et dans le cloud. Nous aborderons les bases de données relationnelles (SQL) et non relationnelles (NoSQL), en soulignant les spécificités de chacune et les meilleures pratiques pour garantir l'intégrité et la disponibilité des données.

1. Concepts Généraux et Meilleures Pratiques pour les Sauvegardes de Bases de Données :

Avant d'aborder des bases de données spécifiques, il est crucial de comprendre certains concepts fondamentaux et les meilleures pratiques applicables à toute stratégie de sauvegarde :

• Types de Sauvegardes :
• Sauvegarde Complète (Full Backup) : Copie toutes les données de la base de données à un moment donné. C'est la base de toute stratégie de sauvegarde et elle permet une restauration complète.
• Sauvegarde Différentielle (Differential Backup) : Copie uniquement les données qui ont changé depuis la dernière sauvegarde complète. Elle nécessite une sauvegarde complète précédente pour la restauration.
• Sauvegarde Incrémentielle (Incremental Backup) : Copie uniquement les données qui ont changé depuis la dernière sauvegarde (complète ou incrémentielle). Elle nécessite la restauration de la dernière sauvegarde complète et de toutes les sauvegardes incrémentielles ultérieures.
• Sauvegarde Logique (Logical Backup) : Exporte la structure de la base de données (schéma, tables, index, etc.) et les données dans un format lisible (par exemple, fichiers SQL, JSON, CSV). Utile pour les migrations, les audits et la récupération au niveau de l'objet.
• Sauvegarde Physique (Physical Backup) : Copie les fichiers de données sous-jacents qui composent la base de données. Généralement plus rapide et plus efficace pour les restaurations complètes.
• Fréquence et Planification des Sauvegardes : La fréquence des sauvegardes doit être basée sur la criticité des données et le taux de changement. Les bases de données à forte activité nécessiteront des sauvegardes plus fréquentes. Des calendriers de sauvegarde automatisés doivent être établis pour éviter la dépendance aux processus manuels.
• Politiques de Rétention des Sauvegardes : Définissez la durée pendant laquelle les sauvegardes doivent être conservées. Cela peut varier en fonction des exigences réglementaires, des besoins de l'entreprise et des limitations de stockage. Des politiques de rétention hiérarchiques doivent être mises en œuvre (par exemple, sauvegardes quotidiennes pendant une semaine, sauvegardes hebdomadaires pendant un mois, sauvegardes mensuelles pendant un an).
• Tests et Validation des Sauvegardes : Il est essentiel de tester périodiquement les sauvegardes pour s'assurer de leur intégrité et de la capacité à restaurer la base de données en cas de besoin. Les tests doivent simuler différents scénarios de perte de données.
• Sécurité des Sauvegardes : Les sauvegardes doivent être protégées contre l'accès non autorisé, la modification et la suppression. Cela comprend le cryptage des sauvegardes, le contrôle d'accès au stockage des sauvegardes et la mise en œuvre de mesures de sécurité physiques et logiques.
• Considérations de Reprise Après Sinistre (DR) : La stratégie de sauvegarde doit être intégrée au plan de reprise après sinistre de l'organisation. Cela peut impliquer le stockage des sauvegardes dans un emplacement secondaire (hors site) ou l'utilisation de solutions de réplication et de basculement.

2. Sauvegardes de Bases de Données Relationnelles (SQL) :

Les bases de données relationnelles stockent les données dans des tables avec des relations définies. Certains des systèmes de gestion de bases de données relationnelles (SGBDR) les plus populaires incluent MySQL, PostgreSQL, Microsoft SQL Server et Oracle Database.

2.1. MySQL :

• Sur Site (On-Premise) :
• Sauvegarde Logique : Utiliser l'utilitaire mysqldump pour exporter la base de données vers un fichier SQL.
  Bash
  mysqldump -u [utilisateur] -p[mot_de_passe] --databases [nom_bd1] [nom_bd2] ... > sauvegarde.sql
  Pour une sauvegarde complète de toutes les bases de données :
  Bash
  mysqldump -u [utilisateur] -p[mot_de_passe] --all-databases --routines --events > sauvegarde_complete.sql
  
  
• Sauvegarde Physique :
• Copie de Fichiers : Si MySQL est configuré avec le moteur de stockage InnoDB et l'option innodb_file_per_table activée, les fichiers .ibd (données) et .frm (structure) de chaque table peuvent être copiés. Cependant, cela nécessite d'arrêter le serveur MySQL ou d'utiliser des outils comme xtrabackup.
• Xtrabackup : Un outil open source de Percona qui permet d'effectuer des sauvegardes physiques à chaud (sans interruption) des bases de données MySQL InnoDB.
• Sauvegardes Incrémentielles : xtrabackup prend également en charge les sauvegardes incrémentielles basées sur le numéro de séquence de journalisation (LSN).
• Cloud (AWS RDS, Azure Database pour MySQL, Google Cloud SQL pour MySQL) :
• Les fournisseurs de services cloud offrent des mécanismes de sauvegarde gérés.
• AWS RDS : Utilise des snapshots EBS (Elastic Block Store) pour les sauvegardes physiques. Les sauvegardes automatisées peuvent être configurées avec une fenêtre de temps spécifiée et une période de rétention. Des snapshots manuels peuvent également être créés.
• Azure Database pour MySQL : Offre des sauvegardes de serveur automatisées (sauvegardes complètes quotidiennes, sauvegardes différentielles toutes les heures ou toutes les cinq minutes). La période de rétention est configurable.
• Google Cloud SQL pour MySQL : Effectue des sauvegardes quotidiennes automatisées. L'heure et la fréquence des sauvegardes peuvent être configurées. Des sauvegardes à la demande peuvent également être créées.
• Dans les environnements cloud, des sauvegardes logiques peuvent également être effectuées à l'aide des outils standard de MySQL à partir d'une instance connectée à la base de données cloud.

2.2. PostgreSQL :

• Sur Site (On-Premise) :
• Sauvegarde Logique : Utiliser l'utilitaire pg_dump pour exporter la base de données vers un fichier SQL.
  Bash
  pg_dump -U [utilisateur] -d [nom_bd] -f sauvegarde.sql
  Pour une sauvegarde complète de toutes les bases de données :
  Bash
  pg_dumpall -U [utilisateur] -f sauvegarde_complete.sql
  
  
• Sauvegarde Physique :
• Copie de Fichiers : Une copie des fichiers de données du répertoire PGDATA du serveur PostgreSQL peut être effectuée. Cela nécessite d'arrêter le serveur pour assurer la cohérence.
• Sauvegardes à Chaud avec pg_basebackup : Un outil pour effectuer des sauvegardes physiques à chaud (en ligne) d'un cluster PostgreSQL en cours d'exécution.
  Bash
  pg_basebackup -h [hôte] -U [utilisateur] -D [répertoire_sauvegarde] -P -v
  
  
• Sauvegardes Incrémentielles : PostgreSQL prend en charge la journalisation WAL (Write-Ahead Logging), qui peut être archivée pour la récupération à un point dans le temps (PITR). Cela permet de restaurer la base de données à un moment précis.
• Cloud (AWS RDS, Azure Database pour PostgreSQL, Google Cloud SQL pour PostgreSQL) :
• Similaire à MySQL, les fournisseurs cloud offrent des services de sauvegarde gérés.
• AWS RDS : Utilise des snapshots EBS pour les sauvegardes physiques. Les sauvegardes automatisées et les snapshots manuels peuvent être configurés. La récupération PITR est également prise en charge grâce à la conservation des journaux de transactions.
• Azure Database pour PostgreSQL : Offre des sauvegardes de serveur automatisées (sauvegardes complètes hebdomadaires, sauvegardes différentielles quotidiennes). La récupération PITR est prise en charge avec une période de rétention configurable.
• Google Cloud SQL pour PostgreSQL : Effectue des sauvegardes quotidiennes automatisées et prend en charge la récupération PITR grâce à la conservation des journaux de transactions. Des sauvegardes à la demande peuvent également être créées.
• Les outils standard de PostgreSQL peuvent être utilisés pour effectuer des sauvegardes logiques à partir d'un client connecté.

2.3. Microsoft SQL Server :

• Sur Site (On-Premise) :
• Sauvegarde Complète : Utiliser SQL Server Management Studio (SSMS) ou les commandes T-SQL :
  SQL
  BACKUP DATABASE [NomDeLaBaseDeDonnées]
  TO DISK = 'C:\Sauvegarde\NomDeLaBaseDeDonnées.bak'
  WITH FORMAT;
  
  
• Sauvegarde Différentielle :
  SQL
  BACKUP DATABASE [NomDeLaBaseDeDonnées]
  TO DISK = 'C:\Sauvegarde\NomDeLaBaseDeDonnées_diff.bak'
  WITH DIFFERENTIAL;
  
  
• Sauvegarde du Journal des Transactions : Essentiel pour la récupération à un point dans le temps (PITR) dans le modèle de récupération Full ou Bulk-Logged.
  SQL
  BACKUP LOG [NomDeLaBaseDeDonnées]
  TO DISK = 'C:\Sauvegarde\NomDeLaBaseDeDonnées_log.trn';
  
  
• Agents de Sauvegarde : SQL Server Agent permet de planifier des sauvegardes automatisées.
• Cloud (Azure SQL Database, AWS RDS pour SQL Server, Google Cloud SQL pour SQL Server) :
• Azure SQL Database : Effectue des sauvegardes automatisées (sauvegardes complètes hebdomadaires, sauvegardes différentielles quotidiennes, sauvegardes du journal des transactions toutes les 5 à 10 minutes). La rétention est configurable. Des sauvegardes à la demande peuvent également être effectuées.
• AWS RDS pour SQL Server : Offre des sauvegardes automatisées (snapshots du volume de stockage) et des sauvegardes manuelles (snapshots de l'instance de base de données). La récupération PITR est également prise en charge grâce à la conservation des journaux de transactions.
• Google Cloud SQL pour SQL Server : Effectue des sauvegardes quotidiennes automatisées. L'heure et la fréquence peuvent être configurées. Des sauvegardes à la demande sont également disponibles et la récupération PITR est prise en charge.
• Les outils standard de SQL Server (SSMS, commandes T-SQL) peuvent être utilisés pour interagir avec les bases de données cloud et effectuer des sauvegardes.

2.4. Oracle Database :

• Sur Site (On-Premise) :
• Recovery Manager (RMAN) : L'outil recommandé par Oracle pour effectuer les sauvegardes et les récupérations. RMAN permet les sauvegardes complètes, incrémentielles, les sauvegardes à chaud et la récupération PITR.
  Fragmento de código
  RMAN> CONNECT TARGET /
  RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
  
  
• Sauvegardes à Froid (Hors Ligne) : Nécessite l'arrêt de la base de données. Les fichiers de données, les fichiers de contrôle et les fichiers de redo log sont copiés.
• Sauvegardes à Chaud (En Ligne) : La base de données reste opérationnelle. Nécessite de placer les tablespaces en mode de sauvegarde et d'archiver les redo logs. RMAN simplifie ce processus.
• Cloud (AWS RDS pour Oracle, Azure Database pour Oracle, Google Cloud SQL pour Oracle) :
• AWS RDS pour Oracle : Offre des sauvegardes automatisées (snapshots du volume de stockage) et des sauvegardes manuelles (snapshots de l'instance de base de données). La récupération PITR est prise en charge grâce à la conservation des fichiers journaux archivés. RMAN peut être utilisé pour des sauvegardes plus avancées.
• Azure Database pour Oracle : Offre des sauvegardes automatisées et permet d'effectuer des sauvegardes à la demande. La récupération PITR est prise en charge avec une période de rétention configurable.
• Google Cloud SQL pour Oracle : Effectue des sauvegardes quotidiennes automatisées et permet d'effectuer des sauvegardes à la demande. La récupération PITR est prise en charge grâce à la conservation des fichiers journaux archivés. RMAN peut également être utilisé.

3. Sauvegardes de Bases de Données Non Relationnelles (NoSQL) :

Les bases de données NoSQL ont des modèles de données et des architectures différents de ceux des bases de données relationnelles. Cela influence les stratégies de sauvegarde.

3.1. MongoDB :

• Sur Site (On-Premise) :
• Sauvegarde Logique : Utiliser l'utilitaire mongodump pour exporter les données au format BSON ou JSON.
  Bash
  mongodump --host [hôte] --port [port] --username [utilisateur] --password [mot_de_passe] --db [nom_bd] --out /chemin/sauvegarde
  Pour une sauvegarde complète de toutes les bases de données :
  Bash
  mongodump --host [hôte] --port [port] --username [utilisateur] --password [mot_de_passe] --all --out /chemin/sauvegarde
  
  
• Sauvegarde Physique :
• Copie de Fichiers : Si MongoDB est configuré avec le moteur de stockage WiredTiger, les fichiers de données du répertoire dbPath peuvent être copiés. Cela nécessite d'arrêter le serveur ou d'utiliser la commande db.fsyncLock() pour assurer la cohérence.
• Sauvegardes à Chaud avec mongorestore et Oplog : Pour les sauvegardes à chaud, mongodump peut être utilisé pour une copie initiale, puis les opérations de l'oplog (journal des opérations) peuvent être appliquées pour mettre la copie à jour.
• MongoDB Atlas (service cloud géré) : Effectue des sauvegardes continues et permet la récupération à un point dans le temps.
• Cloud (AWS DocumentDB, Azure Cosmos DB API pour MongoDB, Google Cloud Firestore en mode Datastore) :
• AWS DocumentDB : Effectue des sauvegardes automatisées et permet de créer des snapshots manuels. La récupération PITR est prise en charge avec une période de rétention configurable.
• Azure Cosmos DB API pour MongoDB : Offre des sauvegardes automatisées et à la demande. La restauration peut être effectuée à un point dans le temps spécifique pendant la période de rétention.
• Google Cloud Firestore en mode Datastore : Effectue des sauvegardes quotidiennes automatisées et permet d'effectuer des sauvegardes à la demande.

3.2. Cassandra :

• Sur Site (On-Premise) :
• Snapshots : Cassandra fournit une fonctionnalité de snapshots qui crée une copie cohérente des fichiers de données (SSTables) sur le disque. Les snapshots sont rapides et n'affectent pas les performances.
  Bash
  nodetool snapshot -t [nom_snapshot] [keyspace.table]
  
  
• Sauvegardes Complètes : Pour une sauvegarde complète, les répertoires de données de chaque nœud du cluster doivent être copiés.
• Outils Tiers : Des outils comme Medusa peuvent faciliter la gestion des sauvegardes Cassandra.
• Cloud (AWS Keyspaces pour Cassandra, Azure Managed Instance pour Apache Cassandra, Google Cloud Memorystore pour Redis - bien que Redis ne soit pas Cassandra) :
• AWS Keyspaces : Effectue des sauvegardes automatisées et permet d'effectuer des sauvegardes à la demande.
• Azure Managed Instance pour Apache Cassandra : Offre des sauvegardes automatisées et permet d'effectuer des sauvegardes à la demande.
• Google Cloud Memorystore pour Redis : N'est pas Cassandra. Pour Cassandra sur GCP, la version auto-gérée sur Compute Engine peut être utilisée avec les stratégies sur site, ou des solutions partenaires peuvent être utilisées.

3.3. Redis :

• Sur Site (On-Premise) :
• RDB (Redis Database File) : Redis peut enregistrer des snapshots de la base de données sur disque au format RDB. Ceci est configuré dans le fichier redis.conf ou via des commandes.
  Bash
  redis-cli SAVE
  Des règles peuvent être configurées pour enregistrer automatiquement la base de données après un certain nombre de modifications dans une période donnée.
• AOF (Append Only File) : Redis peut également enregistrer chaque opération d'écriture dans un fichier AOF. Cela offre une durabilité supérieure à RDB. Il peut être configuré pour écrire sur disque à chaque commande, chaque seconde ou jamais.
• Sauvegarde Manuelle : Copier les fichiers dump.rdb (pour RDB) et appendonly.aof (pour AOF).
• Cloud (AWS ElastiCache pour Redis, Azure Cache pour Redis, Google Cloud Memorystore pour Redis) :
• AWS ElastiCache pour Redis : Permet de créer des snapshots et de configurer des sauvegardes automatisées.
• Azure Cache pour Redis : Offre des sauvegardes automatisées et permet d'effectuer des sauvegardes à la demande.
• Google Cloud Memorystore pour Redis : Effectue des sauvegardes quotidiennes automatisées et permet d'effectuer des sauvegardes à la demande.

3.4. Elasticsearch :

• Sur Site (On-Premise) :
• Snapshots : Elasticsearch fournit une API pour créer des snapshots d'indices. Tout d'abord, un référentiel de snapshots doit être enregistré.
  JSON
  PUT _snapshot/mon_repertoire_sauvegarde
  {
    "type": "fs",
    "settings": {
      "location": "/mnt/data/sauvegardes_elasticsearch"
    }
  }
  Ensuite, un snapshot peut être créé :
  JSON
  PUT _snapshot/mon_repertoire_sauvegarde/snapshot_20230406
  {
    "indices": "mon-index-*"
  }
  
  
• Outils Tiers : Des outils comme Curator aident à gérer les snapshots et les politiques de rétention.
• Cloud (AWS OpenSearch Service, Azure Cognitive Search, Google Cloud Elasticsearch) :
• AWS OpenSearch Service : Permet de créer des snapshots manuels et automatisés.
• Azure Cognitive Search : Offre des mécanismes de sauvegarde et de restauration.
• Google Cloud Elasticsearch : Prend en charge les snapshots d'indices. Un bucket Google Cloud Storage doit être configuré comme référentiel de snapshots.

Conclusion :

La mise en œuvre d'une stratégie de sauvegarde efficace est fondamentale pour la protection des données dans tout environnement. Ce document a fourni un aperçu des considérations clés et des techniques spécifiques pour sauvegarder les bases de données relationnelles et non relationnelles les plus pertinentes, à la fois sur site et dans le cloud.

Il est important de se rappeler que la stratégie de sauvegarde optimale dépendra des exigences spécifiques de chaque organisation, y compris la criticité des données, la tolérance à la perte de données (RPO - Recovery Point Objective), le temps d'arrêt acceptable (RTO - Recovery Time Objective) et les contraintes budgétaires.

Il est fortement recommandé de tester et de valider périodiquement les sauvegardes, ainsi que de réviser et de mettre à jour la stratégie de sauvegarde à mesure que les besoins de l'entreprise et les technologies de bases de données évoluent. Investir dans une stratégie de sauvegarde solide est un investissement dans la résilience et la continuité des activités.