Protéger vos données à l'aide de sauvegardes

Sélectionnez une version de la documentation :

Cette page décrit l'architecture de référence AlloyDB Omni avec disponibilité standard, qui assure la protection des données à l'aide de sauvegardes.

Cas d'utilisation

Cette architecture de référence est compatible avec les scénarios suivants :

  • Vous disposez de bases de données qui peuvent tolérer un certain temps d'arrêt et une perte de données depuis la dernière sauvegarde.
  • Vous souhaitez protéger votre base de données AlloyDB Omni contre les erreurs des utilisateurs, une éventuelle corruption ou des défaillances physiques au niveau de la base de données (par opposition aux instantanés de volume ou de nœud).
  • Vous souhaitez récupérer votre base de données sur place ou à distance, en remontant éventuellement jusqu'à un moment précis.

Fonctionnement de l'architecture de référence

L'architecture de référence à disponibilité standard couvre la sauvegarde et la récupération de vos bases de données AlloyDB Omni.

Bien que la disponibilité standard soit une implémentation de base qui minimise le matériel ou les services supplémentaires requis, l'objectif de temps de récupération (RTO) augmente à mesure que la base de données s'agrandit. Plus il y a de données à sauvegarder, plus la restauration et la récupération de la base de données prennent du temps. La perte de données dépend du type de sauvegarde. Si seuls les fichiers de données sont sauvegardés régulièrement, vous perdez les données produites après la dernière sauvegarde lorsque vous effectuez une restauration.

Réduire le RPO

La fonctionnalité d'archivage continu de PostgreSQL vous permet d'atteindre un objectif de point de récupération (RPO) faible et de procéder à une récupération à un moment précis par le biais de sauvegardes. Ce processus implique l'archivage des fichiers de journalisation WAL (Write-Ahead Logging) et la diffusion par flux des données WAL, potentiellement vers un emplacement de stockage distant.

Si les fichiers WAL ne sont archivés que lorsqu'ils sont pleins ou à des intervalles spécifiques, une perte complète de la base de données (y compris les fichiers WAL en cours d'utilisation) limite la récupération au dernier fichier WAL archivé. Cela implique que votre RPO doit tenir compte de la perte de données potentielle. À l'inverse, le transfert continu des données WAL réduit au maximum le risque de perte de données.

Lorsque vous configurez des sauvegardes continues, vous pouvez restaurer les données à un moment précis. La récupération à un moment précis vous permet de restaurer une base de données à un état antérieur à la survenue d'une erreur telle que la suppression accidentelle d'une table ou une mise à jour groupée incorrecte. Cette méthode de récupération a toutefois un impact sur le RPO et le RTO, sauf si vous utilisez une base de données auxiliaire temporaire. La restauration d'une base de données entière sur place annule les transactions ultérieures sur les tables non affectées et met la base de données hors connexion, tandis que la restauration vers une base de données auxiliaire temporaire vous permet de ne copier que les données récupérées.

Stratégies de sauvegarde

AlloyDB Omni est compatible avec les stratégies de protection des données telles que les sauvegardes physiques périodiques, la récupération à un moment précis, l'archivage et le streaming WAL, ainsi que le stockage des sauvegardes à différents emplacements. Vous pouvez également choisir d'effectuer une sauvegarde logique de la base de données (à l'aide de pg_dump pour une seule base de données ou de pg_dumpall pour l'ensemble du cluster) si la base de données est de petite taille, puis de la restaurer à l'aide de pg_restore.

Outils de sauvegarde

Pour les déploiements Kubernetes, vous pouvez configurer des sauvegardes continues à l'aide d'un plan de sauvegarde (BackupPlan) géré par l'opérateur AlloyDB Omni pour chaque cluster de bases de données. Pour en savoir plus, consultez Sauvegarder et restaurer dans Kubernetes.

Selon l'option de déploiement choisie, vous pouvez configurer AlloyDB Omni pour stocker les sauvegardes sur un espace de stockage local ou distant, tel que Cloud Storage ou les options de stockage fournies par n'importe quel fournisseur de services cloud. Bien que le stockage local puisse être plus rapide pour la sauvegarde et la récupération, le stockage à distance est généralement plus robuste lorsqu'il s'agit de gérer les défaillances d'un nœud ou d'une zone entière. Pour en savoir plus, consultez la figure 1, qui présente les destinations de sauvegarde potentielles.

AlloyDB Omni avec options de sauvegarde

Figure 1 : AlloyDB Omni avec options de sauvegarde.

Vous pouvez effectuer des sauvegardes sur des options de stockage locales ou à distance. Les sauvegardes locales ont tendance à être plus rapides, car elles ne dépendent que du débit d'E/S, tandis que les sauvegardes à distance ont généralement une latence plus élevée et une bande passante réseau plus faible. Toutefois, les sauvegardes à distance offrent une meilleure protection contre les défaillances d'hôte et de zone que les sauvegardes locales.

Vous pouvez également répartir les sauvegardes locales entre le stockage local et le stockage partagé. Bien que le stockage local des nœuds ne dispose pas d'options de reprise après sinistre en cas de défaillance d'un nœud de base de données, le stockage partagé vous permet d'associer ce stockage à un autre nœud et de l'utiliser pour la récupération. Cela signifie que le stockage partagé peut offrir un RTO plus rapide.

Pour les déploiements de stockage local, partagé et distant, vous pouvez planifier les types de sauvegardes suivants ou les effectuer manuellement à la demande :

  • Sauvegardes complètes : sauvegardes complètes de tous les fichiers de base de données nécessaires à la récupération des données.
  • Sauvegardes différentielles : sauvegardes des modifications apportées aux fichiers depuis la dernière sauvegarde complète.
  • Sauvegardes incrémentielles : sauvegardes des modifications apportées aux fichiers depuis la dernière sauvegarde, quel que soit son type.

Récupération à un moment précis

Les sauvegardes continues des fichiers WAL de PostgreSQL permettent la récupération à un moment précis. Si, après un événement de défaillance, les fichiers WAL sont intacts et utilisables, vous pouvez vous en servir pour effectuer une récupération à un moment précis et limiter la perte de données.

Planifications de sauvegarde

Dans les déploiements Kubernetes, vous configurez des planifications de sauvegarde automatique et des règles de conservation à l'aide d'expressions cron dans un fichier manifeste BackupPlan.

Dans la plupart des environnements, les sauvegardes sont généralement planifiées sur la semaine. Voici un exemple de programme de sauvegarde hebdomadaire :

  • Dimanche : sauvegarde complète
  • Lundi et mardi : sauvegarde incrémentielle
  • Mercredi : sauvegarde différentielle
  • Jeudi et vendredi : sauvegarde incrémentielle
  • Samedi : sauvegarde différentielle

Si vous utilisez ce calendrier type, une période de récupération continue d'une semaine nécessite de l'espace de stockage pour un maximum de trois sauvegardes complètes, ainsi que pour les sauvegardes incrémentielles ou différentielles requises. Cette approche permet de récupérer les données si une défaillance se produit lors de la sauvegarde complète du dimanche. La récupération de la base de données doit s'étendre au dimanche précédant le début de la sauvegarde.

Pour un RTO réduit et un RPO potentiellement plus élevé, des bases de données supplémentaires peuvent fonctionner en mode de récupération continue. Ce mode implique la relecture des sauvegardes et la mise à jour en continu de l'environnement secondaire par le biais de l'archivage et de la relecture des nouveaux fichiers WAL. Le RPO réel, qui reflète la perte de données potentielle, dépend de la fréquence des transactions, de la taille des fichiers WAL et de l'utilisation de la diffusion de données WAL par flux.

Restauration de sauvegarde

Vous pouvez restaurer une base de données AlloyDB Omni à partir d'une sauvegarde stockée ou effectuer une récupération à un moment précis de votre période de conservation. Selon votre environnement de déploiement et vos besoins de récupération, vous pouvez restaurer les données sur place ou restaurer la sauvegarde dans une nouvelle instance ou un nouveau cluster de base de données.

Pour les déploiements Kubernetes, l'opérateur AlloyDB Omni permet de récupérer une base de données dans le même cluster et le même espace de noms Kubernetes à partir d'une sauvegarde nommée ou d'un clone reposant sur un point dans le temps. Pour en savoir plus, consultez Sauvegarder et restaurer dans Kubernetes et Présentation du clonage manuel d'un cluster de bases de données à partir d'une sauvegarde Kubernetes.

Implémentation

Lorsque vous choisissez une architecture de référence de disponibilité, gardez à l'esprit les avantages, les limites et les alternatives suivants.

Avantages

  • Facile à utiliser et à gérer, et adapté aux bases de données non critiques avec un RTO et un RPO souples.
  • Nécessite un minimum de matériel supplémentaire.
  • Fournit les sauvegardes de base requises pour un plan de reprise après sinistre.
  • Permet de récupérer les données correspondant à n'importe quel moment de la période de récupération.

Limites

  • Peut nécessiter plus d'espace de stockage que la base de données elle-même, en fonction de vos exigences de conservation.
  • La récupération peut être lente et entraîner un RTO plus élevé.
  • Cela peut conduire à une perte de données, selon la disponibilité des données WAL actuelles après une défaillance de la base de données. Cela peut avoir un impact négatif sur le RPO.

Alternatives

Envisagez d'utiliser l'architecture de référence de disponibilité améliorée ou de disponibilité Premium pour améliorer la disponibilité et les options de reprise après sinistre.

Étapes suivantes