Présentation des sauvegardes

Cette page décrit ce qu'est une sauvegarde, comment elle fonctionne, certains cas d'utilisation courants et les bonnes pratiques à suivre pour créer et utiliser des sauvegardes. Pour apprendre à créer et à gérer des sauvegardes, ainsi qu'à restaurer une instance Filestore à partir d'une sauvegarde, consultez la page Sauvegarder des données pour la reprise après sinistre.

Qu'est-ce qu'une sauvegarde ?

Une sauvegarde Filestore est une copie d'un partage de fichiers qui inclut toutes les données et métadonnées de celui-ci à partir du moment où la sauvegarde est créée.

Une fois que vous avez créé une sauvegarde d'un partage de fichiers, vous pouvez modifier ou supprimer le partage de fichiers d'origine sans affecter la sauvegarde.

Vous pouvez utiliser une sauvegarde pour restaurer un partage de fichiers sur une nouvelle instance Filestore ou, pour les instances de niveau de base, sur la source d'un partage de fichiers existant.

Les sauvegardes sont des ressources régionales qui restent dans la région que vous spécifiez au moment de la création. Vous pouvez créer des sauvegardes dans la même région que l'instance Filestore ou dans une autre région pour réduire le risque de perte de données.

Les sauvegardes sont globalement adressables et peuvent servir à restaurer des partages de fichiers vers n'importe quelle région, mais elles ne peuvent pas être partagées entre plusieurs projets.

Tarifs

Les frais de transfert réseau s'appliquent au trafic réseau interrégional. Pour en savoir plus, consultez la page Tarifs.

Créer une sauvegarde

La première sauvegarde que vous créez est une copie complète de toutes les données et métadonnées d'un partage de fichiers. Chaque sauvegarde ultérieure copie toutes les modifications successives apportées aux données depuis la sauvegarde précédente.

Chaînes de sauvegarde

Un groupe de sauvegardes associé à la même instance, à la même région et à la même CMEK (le cas échéant) est appelé chaîne de sauvegarde.

Une chaîne de sauvegarde se trouve dans un seul bucket et une seule région Cloud Storage, et peut se trouver en dehors de la région utilisée pour stocker l'instance source.

Tous les niveaux de service acceptent plusieurs chaînes de sauvegarde, ce qui vous permet de stocker les sauvegardes d'une instance dans plusieurs régions.

Chaque fois qu'une sauvegarde est créée, la sauvegarde précédente est analysée pour détecter les modifications différentielles et incrémentielles:

  • Modifications différentielles:inclut les modifications apportées aux fichiers du partage, telles que les modifications, les ajouts ou les suppressions de fichiers.

  • Modifications incrémentielles:inclut les modifications apportées au stockage dans le bucket où se trouvent les données de sauvegarde. Cela peut inclure la déduplication des données précédemment référencées dans la chaîne.

Chaque fois que vous enregistrez une sauvegarde dans la même chaîne de sauvegarde, la sauvegarde précédente est analysée pour détecter les modifications différentielles et incrémentielles. Dans ce cas, une copie complète n'est pas nécessaire.

Toutefois, le stockage des données d'une instance dans plusieurs chaînes de sauvegarde implique que vous enregistrez et stockez des sauvegardes dans des emplacements alternés.

Chaque fois que vous créez une sauvegarde dans un emplacement alternatif, une copie complète de la sauvegarde est générée à nouveau. Attendez-vous à une latence plus élevée pour les opérations create de sauvegarde lorsque vous alternez entre des chaînes de sauvegarde.

Les données non modifiées contenues dans les sauvegardes précédentes sont référencées, mais pas copiées, dans des sauvegardes plus récentes. Si une sauvegarde plus ancienne est supprimée, ses données uniques sont copiées sur la dernière sauvegarde la plus récente et toutes les références de données internes sont automatiquement mises à jour.

En interne, l'historique d'une chaîne de sauvegarde est suivi à l'aide d'instantanés, qui consomment de la capacité sur l'instance source.

La création de la sauvegarde est instantanée, mais son délai est proportionnel à la quantité de données copiées avant que la sauvegarde ne soit disponible. Au cours de cette période, la sauvegarde passe par trois états :

État Durée Description
Création Quelques secondes Capturer l'état actuel du partage de fichiers Toute nouvelle modification des données de partage de fichiers peut ou non être incluse dans la sauvegarde. Les écritures stables confirmées par l'instance avant le lancement de la sauvegarde sont incluses.
Finalisation… Selon la taille Importer des données dans la sauvegarde Aucune nouvelle modification apportée aux données de partage de fichiers n'est incluse dans la sauvegarde.
Ready Jusqu'à la suppression de la sauvegarde La sauvegarde est prête à l'emploi.

Une fois créées, les sauvegardes de niveau de base sont automatiquement compressées afin de réduire les coûts. Les performances des instances peuvent être réduites lors de la création d'une sauvegarde pour les instances des niveaux de service zonal, régional et entreprise. La création d'une sauvegarde n'a aucune incidence sur la disponibilité ni les performances des instances de niveau de base.

Traiter les données redondantes

Par défaut, les sauvegardes sont incrémentielles pour éviter de facturer des données redondantes et réduire l'utilisation de l'espace de stockage. Pour garantir la fiabilité de l'historique des modifications sous-jacent, une sauvegarde peut occasionnellement capturer une copie complète de l'instance.

Pour en savoir plus, consultez Comparer les instantanés et les sauvegardes.

Suppression des sauvegardes

Les sauvegardes sont des ressources au niveau du projet, et non une sous-ressource de l'instance source. Elles nécessitent leur propre stockage distinct. Par conséquent, le cycle de vie d'une sauvegarde n'est pas lié à celui de l'instance source. La suppression de la source ne supprime pas les sauvegardes qui lui sont associées. Si vous souhaitez supprimer une sauvegarde, vous devez effectuer explicitement une opération de suppression sur la sauvegarde, et non sur l'instance.

Veillez à supprimer toutes les sauvegardes indésirables. Si une instance source est supprimée, les sauvegardes restantes continuent de générer des frais.

La suppression d'une sauvegarde est définitive et ne peut pas être annulée. Si la suppression d'une sauvegarde échoue, l'état est marqué comme invalid. Dans ce cas, réessayez l'opération delete.

Cohérence des sauvegardes

Les sauvegardes Filestore ont une sémantique de cohérence NFSv3 et NFSv4.1. Avant le lancement d'une sauvegarde, toute écriture que l'instance Filestore reconnaît comme étant écrite dans un espace de stockage stable ou suivie d'un COMMIT confirmé est incluse dans la sauvegarde. Pour en savoir plus, consultez la section 3.3.7 du document RFC-1813 NFSv3 ou À propos des protocoles de système de fichiers compatibles.

Cas d'utilisation courants

Les sections suivantes décrivent les cas d'utilisation courants des sauvegardes.

Sauvegarder des données pour la reprise après sinistre

Imaginons que vous disposiez d'une instance Filestore dans us-west1-c et que vous souhaitiez protéger vos données contre les sinistres qui affectent cette région. Vous pouvez programmer une tâche qui crée régulièrement des sauvegardes de cette instance vers une région distante, par exemple us- east1. Si un sinistre concerne us-west1-c, vous pouvez créer une instance dans un autre emplacement à partir d'une sauvegarde précédente.

Sauvegarder des données pour vous protéger contre les modifications accidentelles

Si vous souhaitez protéger vos données Filestore contre les modifications inattendues, vous pouvez planifier une tâche qui crée régulièrement des sauvegardes de l'instance. Si vous perdez des données, vous pouvez parcourir la liste des sauvegardes pour identifier celle qui comporte la version du fichier nécessaire. Vous pouvez ensuite créer une instance Filestore à partir de la sauvegarde, l'installer sur le même client que l'instance d'origine, puis copier le fichier.

Avant de copier le fichier, vous pouvez utiliser la commande Linux diff sur les deux points d'installation pour vérifier les différences entre les données de l'instance d'origine et celles qui sont restaurées à partir de la sauvegarde. Une fois les données récupérées, vous pouvez supprimer l'instance restaurée et créer une nouvelle sauvegarde pour conserver l'état actuel de vos données pour une utilisation ultérieure.

Vous pouvez également effectuer une restauration sur place où les données de sauvegarde sont directement restaurées dans l'instance Filestore d'origine, en remplaçant toutes les données dessus par celles de la sauvegarde. Nous vous recommandons de créer une sauvegarde des données les plus récentes avant d'effectuer une restauration sur place, car toutes les données non sauvegardées sont perdues.

Créer des clones pour le développement et les tests

Imaginons que vous disposez d'une base de données configurée sur une instance Filestore qui diffuse le trafic de production. Si vous souhaitez exécuter un test avec une base de données comme entrée, vous pouvez créer une instance Filestore à partir d'une sauvegarde de l'instance de production pour le test. Ainsi, l'utilisation du test n'interfère pas avec l'environnement de production.

De même, vous pouvez utiliser des sauvegardes pour une analyse et une enquête hors connexion sans affecter la production.

Migration de données

Une fois que vous avez créé une instance Filestore, vous ne pouvez plus modifier son emplacement ni son niveau de service. Pour migrer vos données vers une autre région, vous pouvez en créer une sauvegarde et utiliser la sauvegarde pour créer une instance Filestore ou la restaurer sur une instance existante.

Limites des fonctionnalités

Les sauvegardes Filestore sont en disponibilité générale (GA) pour tous les niveaux de service.

Les sauvegardes Filestore ne peuvent pas être combinées à la fonctionnalité de multipartages Filestore.

Les sections suivantes décrivent en détail les autres limites des fonctionnalités liées aux performances, au stockage, à la capacité, au chiffrement et à d'autres sujets.

Performances

  • Pour les instances très utilisées, les performances peuvent être réduites de 15 % maximum lors de l'importation d'une sauvegarde. Les performances des instances de niveau de base ne sont pas affectées par les opérations de sauvegarde create.

  • Le stockage des données d'une instance dans plusieurs chaînes de sauvegarde a un impact sur les performances de sauvegarde. Attendez-vous à une latence plus élevée pour les opérations create de sauvegarde lorsque vous alternez entre des chaînes de sauvegarde.

  • Les opérations d'instance telles que l'instance restore ou l'instance delete peuvent être retardées jusqu'à la fin d'une opération de sauvegarde create.

  • Dans certains cas, les opérations delete peuvent prendre jusqu'à 24 heures.

Simultanéité des opérations

  • Les opérations delete de sauvegarde associées à la même instance source doivent être effectuées une par une.

  • Les opérations de sauvegarde groupée delete dans une chaîne de sauvegarde ne sont pas prises en charge. Lorsqu'une opération delete est en attente, toutes les nouvelles opérations delete de la même chaîne de sauvegarde renvoient une erreur RESOURCE_EXHAUSTED. Cela ne dépend pas de l'instance source ayant été supprimée. Si l'instance source a été supprimée, une erreur FAILED_PRECONDITION s'affiche.

    Filestore prend en charge les opérations delete de sauvegarde simultanées lorsque les sauvegardes font référence à des instances sources distinctes.

    Par exemple, une instance libellée Source1 contient des données de sauvegarde référencées dans Backup1 et Backup2. Source2 contient des données de sauvegarde référencées dans Backup3 et Backup4. Backup1 et Backup2 ne peuvent pas être supprimés en parallèle, mais Backup2 et Backup3 peuvent l'être.

  • Les opérations de sauvegarde create et de sauvegarde delete lancées dans la même chaîne de sauvegarde peuvent s'exécuter simultanément. Si vous avez déjà commencé à créer une sauvegarde, vous devez attendre la fin de l'opération pour supprimer la sauvegarde existante la plus récente. En effet, la sauvegarde la plus récente contient les données les plus critiques nécessaires à la réussite de l'opération create de sauvegarde. Si vous essayez de supprimer la sauvegarde la plus récente, l'erreur FAILED_PRECONDITION s'affiche.

    Par exemple,Source1 dispose d'une chaîne de sauvegarde composée de Backup1 et de Backup2. Lorsque vous commencez une opération create pour Backup3, vous ne pouvez pas supprimer Backup2 tant que l'opération create n'est pas terminée.

  • Pour en savoir plus sur les limites de débit des opérations, consultez la section Limites de débit des opérations pour les sauvegardes.

Stockage

  • Vous pouvez restaurer une sauvegarde d'une instance de base sur l'instance source du même niveau de service. Si vous restaurez une instance de base sur une nouvelle instance, vous pouvez choisir entre une instance HDD de base et une instance SSD de base, quel que soit le niveau de l'instance source.

  • Vous ne pouvez pas restaurer des instances zonales, régionales et Enterprise sur l'instance source ni sur une instance existante. Vous ne pouvez restaurer ces sauvegardes que sur une nouvelle instance. Dans ce cas, le niveau de l'instance de destination n'a pas besoin de correspondre à celui de l'instance source. Par exemple, vous pouvez restaurer une sauvegarde d'une instance régionale sur une instance zonale. La capacité provisionnée de la nouvelle instance doit être égale ou supérieure à celle de l'instance source.

Capacité

  • Les sauvegardes créées pour les instances zonales, régionales et
    Enterprise peuvent consommer de la capacité d'instance. Cette capacité varie en fonction de l'étendue des modifications apportées aux données depuis la création de la sauvegarde. Plus précisément, lorsqu'une sauvegarde est créée, Filestore crée un instantané interne du système de fichiers, qui occupe également une partie de la capacité disponible de l'instance.

  • La taille de l'instantané est également liée à l'étendue des modifications apportées aux données du partage depuis la création de la dernière sauvegarde. Cet instantané continue d'exister jusqu'à ce que la prochaine sauvegarde soit créée et mise en ligne.

  • Toutes les données référencées par la sauvegarde restent dans l'état dans lequel elles se trouvaient au moment de la capture et continuent de prendre de la place dans le système de fichiers. Par exemple, si vous supprimez des données du système de fichiers installé, cette action ne libère pas de capacité. Pour ce faire, vous devez créer une nouvelle sauvegarde après avoir supprimé ou écrasé de grandes quantités de données.

    Pour obtenir une description détaillée des modifications différentielles et incrémentielles et de leur gestion, consultez la section Création de sauvegardes.

  • Pour prévoir une capacité suffisante pour vos charges de travail, envisagez d'appliquer l'une des mesures suivantes:

    • Augmentez la capacité des instances pour les charges de travail avec des modifications de données importantes et fréquentes ou un taux de modification élevé.

    • Effectuez des sauvegardes fréquentes. Si la dernière sauvegarde est obsolète, l'instantané interne peut accumuler davantage de modifications et consommer davantage de capacité d'instance.

Chiffrement

Lorsque vous utilisez CMEK pour chiffrer vos chaînes de sauvegarde, les restrictions suivantes s'appliquent:

  • Une chaîne de sauvegarde complète est chiffrée à l'aide de la même clé CMEK.

  • Lorsque vous créez une sauvegarde avec CMEK, CMEK doit se trouver dans la même région que la sauvegarde cible.

  • Si vous stockez une chaîne de sauvegarde dans une région distincte de l'instance source, vous devrez peut-être appliquer des clés distinctes, une pour la source et une pour la chaîne de sauvegarde.

    • Tous les niveaux de service acceptent plusieurs chaînes de sauvegarde ou la possibilité de stocker les sauvegardes d'une instance dans plusieurs régions. Si vous choisissez d'utiliser CMEK pour le chiffrement, une clé CMEK doit se trouver dans la même région que la ressource qu'elle chiffre. Si vous stockez des sauvegardes dans une région distincte de la source et que la clé CMEK n'est pas une clé multirégionale, vous devez utiliser des clés CMEK distinctes. Pour en savoir plus, consultez les pages Restrictions CMEK et Choisir le meilleur emplacement CMEK.

  • Un seul CMEK est appliqué au bucket Cloud Storage où la chaîne de sauvegarde est stockée. Il ne peut pas être combiné ni remplacé.

  • La compatibilité CMEK n'est pas disponible pour les sauvegardes de niveau de base.

Pour en savoir plus, consultez la section Compatibilité de CMEK avec les chaînes de sauvegarde.

Protocoles

  • Lors de la restauration d'une sauvegarde, la nouvelle instance doit utiliser le même protocole que l'instance source.

Bonnes pratiques

Les sections suivantes décrivent les bonnes pratiques recommandées.

Préparer votre partage de fichiers pour une meilleure cohérence des sauvegardes

La qualité d'une sauvegarde dépend de la capacité de votre application à effectuer la récupération à partir de sauvegardes créées lors d'importantes charges de travail d'écriture. Dans la plupart des cas, vous pouvez créer des sauvegardes avec une bonne cohérence même lorsque vos applications écrivent des données dans le partage de fichiers. Toutefois, si vos applications nécessitent une cohérence stricte, nous vous recommandons d'effectuer l'une ou plusieurs des opérations suivantes :

  • Utilisez l'installation de synchronisation. Pour en savoir plus, consultez la section "Option d'installation de synchronisation" dans nfs(5). Vous pouvez également ouvrir des fichiers avec les options O_DIRECT|O_SYNC. Pour en savoir plus, consultez open(2).
  • Mettez en veille les applications ou les processus du système d'exploitation qui écrivent des données dans le partage de fichiers, et forcez leur modification au partage de fichiers avant de lancer la sauvegarde. Pour en savoir plus, consultez fsync(2).
  • Si vos applications nécessitent une cohérence entre plusieurs partages, mettez en pause toutes les applications sur toutes les instances qui écrivent dans tous les partages de fichiers et créez des sauvegardes de tous les partages de fichiers avant de reprendre vos applications.
  • Si vous avez besoin d'une cohérence au niveau de l'application, arrêtez vos applications et désinstallez le partage de fichiers avant de créer une sauvegarde.

Utiliser des sauvegardes existantes comme référence pour réduire les délais de création des sauvegardes

Les sauvegardes existantes d'un partage de fichiers dans une région sont utilisées comme base pour créer de nouvelles sauvegardes du partage de fichiers, ce qui réduit le temps de création des sauvegardes. Par conséquent, nous vous recommandons d'effectuer les opérations suivantes:

  • Effectuez une nouvelle sauvegarde d'un partage de fichiers avant de supprimer la sauvegarde précédente de ce partage de fichiers.

  • Attendez que les nouvelles sauvegardes soient à l'état Ready avant de créer des sauvegardes suivantes du même partage de fichiers.

Planifier des sauvegardes pendant les heures creuses pour réduire le délai de création des sauvegardes

La création de sauvegardes pendant les heures creuses permet de réduire le temps nécessaire à la création d'une sauvegarde. Si vous planifiez des sauvegardes régulières de vos partages de fichiers, nous vous recommandons de les planifier pendant les heures creuses, lorsque cela est possible.

Les heures pleines pour la création de sauvegardes sont la fin de chaque jour ouvré et minuit dans la région où se trouve l'instance Filestore. Nous vous recommandons de créer vos sauvegardes le matin ou en début de journée.

Organiser vos données sur des instances Filestore distinctes pour optimiser l'efficacité

Plus le partage de fichiers est important, plus la sauvegarde est grande, et plus le coût est élevé. Pour ne sauvegarder que les données à sauvegarder, nous vous recommandons d'organiser vos données sur des partages de fichiers distincts, à savoir:

  • Stocker des données critiques avec différents modèles d'écriture ou différentes exigences de sauvegarde sur différents partages de fichiers
  • Limiter le nombre de sauvegardes à créer en conservant des données similaires dans un partage de fichiers.

Quota

Une limite de quota existe concernant le nombre de sauvegardes par région pour les niveaux de service SSD de base et HDD de base.

Les limites de quota de sauvegarde ne s'appliquent pas aux niveaux de service zonal, régional et entreprise.

Pour en savoir plus, consultez Niveaux de service et quota.

Premiers pas avec les sauvegardes Filestore

Pour commencer à utiliser cette fonctionnalité, consultez Sauvegarder des données pour la reprise après sinistre.

Étape suivante