Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Sauvegarde Kubernetes (héritée)

Cette page décrit l’approche de sauvegarde héritée utilisant des scripts. Pour SUSE® Observability v2.7.0 ou plus récent, utilisez le nouveau CLI de sauvegarde à la place.

Changements majeurs dans v2.7.0 :

  • backup.enabled est remplacé par global.backup.enabled - Les déploiements Helm échoueront si backup.enabled est défini sur true

  • Toutes les sauvegardes sont contrôlées par une seule valeur global.backup.enabled au lieu d’une activation par magasin de données

  • Les valeurs *.restore.enabled ont été supprimées

Présentation

SUSE® Observability dispose d’un mécanisme de sauvegarde et de restauration intégré qui peut être configuré pour stocker les sauvegardes dans des grappes locales, sur AWS S3 ou sur Azure Blob Storage.

Portée de la sauvegarde

Les données suivantes peuvent être automatiquement sauvegardées :

  • Données de configuration et de topologie stockées dans StackGraph

  • Métriques stockées dans l’instance(s) de Victoria Metrics de SUSE Observability

  • Données de télémétrie stockées dans l’instance de Elasticsearch de SUSE Observability

  • Données OpenTelemetry stockées dans l’instance de ClickHouse de SUSE Observability

Les données suivantes ne seront pas sauvegardées :

  • Mises à jour de topologie et de télémétrie en transit stockées dans Kafka - celles-ci n’ont qu’une valeur temporaire et seraient inutiles lors de la restauration d’une sauvegarde

  • État des négociations du nœud maître stocké dans ZooKeeper - cet état d’exécution serait incorrect lors de la restauration et sera automatiquement déterminé à l’exécution

  • État de configuration de Kubernetes et état brut du volume persistant - cet état peut être reconstruit en réinstallant SUSE Observability et en restaurant les sauvegardes.

  • Les journaux Kubernetes - ceux-ci sont éphémères.

Options de stockage

Les sauvegardes sont envoyées à une instance de MinIO (min.io), qui est automatiquement démarrée par le chart Helm suse-observability lorsque les sauvegardes automatiques sont activées. MinIO est un système de stockage d’objets avec la même API qu’AWS S3. Il peut stocker ses données localement ou agir comme une passerelle vers AWS S3 (min.io), Azure Blob Storage (min.io) et d’autres systèmes.

L’instance MinIO intégrée peut être configurée pour stocker les sauvegardes à trois emplacements :

Activer les sauvegardes

AWS S3

Chiffrement

Les clés gérées par Amazon S3 (SSE-S3) doivent être utilisées lors du chiffrement des buckets S3 qui stockent les sauvegardes.

⚠️ Le chiffrement avec des clés AWS KMS stockées dans le service de gestion des clés AWS (SSE-KMS) n’est pas pris en charge. Cela entraînera des erreurs telles que celle-ci dans les journaux Elasticsearch :

Caused by: org.elasticsearch.common.io.stream.NotSerializableExceptionWrapper: sdk_client_exception: Unable to verify integrity of data upload. Client calculated content hash (contentMD5: ZX4D/ZDUzZWRhNDUyZTI1MTc= in base 64) didn’t match hash (etag: c75faa31280154027542f6530c9e543e in hex) calculated by Amazon S3. You may need to delete the data stored in Amazon S3. (metadata.contentMD5: null, md5DigestStream: com.amazonaws.services.s3.internal.MD5DigestCalculatingInputStream@5481a656, bucketName: suse-observability-elasticsearch-backup, key: tests-UG34QIV9s32tTzQWdPsZL/master.dat)",

Pour activer les sauvegardes planifiées vers les buckets AWS S3, ajoutez le fragment YAML suivant au fichier Helm values.yaml utilisé pour installer SUSE Observability :

global:
  backup:
    enabled: true
backup:
  stackGraph:
    bucketName: AWS_STACKGRAPH_BUCKET
  elasticsearch:
    bucketName: AWS_ELASTICSEARCH_BUCKET
  configuration:
    bucketName: AWS_CONFIGURATION_BUCKET
victoria-metrics-0:
  backup:
    bucketName: AWS_VICTORIA_METRICS_BUCKET
victoria-metrics-1:
  backup:
    bucketName: AWS_VICTORIA_METRICS_BUCKET
clickhouse:
  backup:
    bucketName: AWS_CLICKHOUSE_BUCKET
minio:
  accessKey: YOUR_ACCESS_KEY
  secretKey: YOUR_SECRET_KEY
  s3gateway:
    enabled: true
    accessKey: AWS_ACCESS_KEY
    secretKey: AWS_SECRET_KEY

Remplacez les valeurs suivantes :

  • YOUR_ACCESS_KEY et YOUR_SECRET_KEY sont les identifiants qui seront utilisés pour sécuriser le système MinIO. Ces identifiants sont définis sur le système MinIO et utilisés par les tâches de sauvegarde automatiques et les tâches de restauration. Ils sont également requis si vous souhaitez accéder manuellement au système MinIO.

    • VOTRE_CLE_D_ACCES doit contenir de 5 à 20 caractères alphanumériques.

    • VOTRE_CLE_SECRETE doit contenir entre 8 et 40 caractères alphanumériques.

  • AWS_ACCESS_KEY et AWS_SECRET_KEY sont les identifiants AWS pour l’utilisateur IAM qui a accès aux buckets S3 où les sauvegardes seront stockées. Voir ci-dessous la politique de permission qui doit être attachée à cet utilisateur.

  • AWS_STACKGRAPH_BUCKET, AWS_CONFIGURATION_BUCKET, AWS_ELASTICSEARCH_BUCKET, AWS_VICTORIA_METRICS_BUCKET et AWS_CLICKHOUSE_BUCKET sont les noms des buckets S3 où les sauvegardes doivent être stockées. Remarque : Les noms des buckets S3 d’AWS sont globaux à l’ensemble d’AWS, par conséquent, les buckets S3 avec le nom par défaut (sts-elasticsearch-backup, sts-configuration-backup, sts-stackgraph-backup, sts-victoria-metrics-backup et sts-clickhouse-backup) ne seront probablement pas disponibles.

L’utilisateur IAM identifié par AWS_ACCESS_KEY et AWS_SECRET_KEY doit être configuré avec la politique de permission suivante pour accéder aux buckets S3 :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListMinioBackupBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::AWS_STACKGRAPH_BUCKET",
                "arn:aws:s3:::AWS_ELASTICSEARCH_BUCKET",
                "arn:aws:s3:::AWS_VICTORIA_METRICS_BUCKET",
                "arn:aws:s3:::AWS_CLICKHOUSE_BUCKET",
                "arn:aws:s3:::AWS_CONFIGURATION_BUCKET"
            ]
        },
        {
            "Sid": "AllowWriteMinioBackupBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::AWS_STACKGRAPH_BUCKET/*",
                "arn:aws:s3:::AWS_ELASTICSEARCH_BUCKET/*",
                "arn:aws:s3:::AWS_VICTORIA_METRICS_BUCKET/*",
                "arn:aws:s3:::AWS_CLICKHOUSE_BUCKET/*",
                "arn:aws:s3:::AWS_CONFIGURATION_BUCKET"
            ]
        }
    ]
}

Azure Blob Storage

Pour activer les sauvegardes vers un compte Azure Blob Storage, ajoutez le fragment YAML suivant au fichier Helm values.yaml utilisé pour installer SUSE Observability :

global:
  backup:
    enabled: true
minio:
  accessKey: AZURE_STORAGE_ACCOUNT_NAME
  secretKey: AZURE_STORAGE_ACCOUNT_KEY
  azuregateway:
    enabled: true

Remplacez les valeurs suivantes :

Les sauvegardes de StackGraph, Elasticsearch et Victoria Metrics sont stockées dans des conteneurs BLOB appelés sts-stackgraph-backup, sts-configuration-backup, sts-elasticsearch-backup, sts-victoria-metrics-backup, sts-clickhouse-backup respectivement. Ces noms peuvent être modifiés en définissant les valeurs Helm backup.stackGraph.bucketName, backup.elasticsearch.bucketName, victoria-metrics-0.backup.bucketName, victoria-metrics-1.backup.bucketName et clickhouse.backup.bucketName respectivement.

Stockage Kubernetes

Si MinIO est configuré pour stocker ses données dans le stockage Kubernetes, une PersistentVolumeClaim (PVC) est utilisée pour demander du stockage au cluster Kubernetes. Le type de stockage alloué dépend de la configuration du cluster.

Il est conseillé d’utiliser AWS S3 pour les clusters fonctionnant sur Amazon AWS et Azure Blob Storage pour les clusters fonctionnant sur Azure pour les raisons suivantes :

  1. Les clusters Kubernetes fonctionnant chez un fournisseur de cloud mappent généralement les PVCs à du stockage de blocs, tels que Elastic Block Storage pour AWS ou Azure Block Storage. Le stockage de blocs est coûteux, surtout pour de grands volumes de données.

  2. Les Volumes Persistants sont détruits lorsque le cluster qui les a créés est détruit. Cela signifie qu’une suppression (accidentelle) de votre cluster détruira également toutes les sauvegardes stockées dans les Volumes Persistants.

  3. Les volumes persistants ne peuvent pas être accessibles depuis un autre cluster. Cela signifie qu’il n’est pas possible de restaurer SUSE Observability à partir d’une sauvegarde effectuée sur un autre cluster.

Pour permettre les sauvegardes vers un stockage local au cluster, activez MinIO en ajoutant le fragment YAML suivant au fichier Helm values.yaml utilisé pour installer SUSE Observability :

global:
  backup:
    enabled: true
minio:
  accessKey: YOUR_ACCESS_KEY
  secretKey: YOUR_SECRET_KEY
  persistence:
    enabled: true

Remplacez les valeurs suivantes :

  • YOUR_ACCESS_KEY et YOUR_SECRET_KEY - les identifiants qui seront utilisés pour sécuriser le système MinIO. Les tâches de sauvegarde automatiques et les tâches de restauration les utiliseront. Ils sont également nécessaires pour accéder manuellement au stockage MinIO. YOUR_ACCESS_KEY doit contenir de 5 à 20 caractères alphanumériques et YOUR_SECRET_KEY doit contenir de 8 à 40 caractères alphanumériques.

Données de configuration et de topologie (StackGraph)

Les sauvegardes des données de configuration et de topologie (StackGraph) sont des sauvegardes complètes, stockées dans un seul fichier avec l’extension .graph. Chaque fichier contient une sauvegarde complète et peut être déplacé, copié ou supprimé selon les besoins.

Plan de sauvegarde

Par défaut, les sauvegardes StackGraph sont créées quotidiennement à 03h00, heure du serveur.

Le plan de sauvegarde peut être configuré en utilisant la valeur Helm backup.stackGraph.scheduled.schedule, spécifiée dans la syntaxe de planification cron Kubernetes (kubernetes.io).

Conservation des sauvegardes

Par défaut, les sauvegardes StackGraph sont conservées pendant 30 jours. Comme les sauvegardes StackGraph sont des sauvegardes complètes, cela peut nécessiter beaucoup d’espace de stockage.

Le delta de conservation des sauvegardes peut être configuré en utilisant la valeur Helm backup.stackGraph.scheduled.backupRetentionTimeDelta, spécifiée au format de l’argument de date GNU --date. Par exemple, la valeur par défaut est 30 days ago. Voir les éléments relatifs dans les chaînes de date pour plus d’exemples.

Désactiver les sauvegardes programmées

Pour désactiver les sauvegardes programmées de StackGraph, définissez le plan de sauvegarde à une date lointaine dans le passé en utilisant la valeur Helm backup.stackGraph.scheduled.schedule :

backup:
  stackGraph:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

Métriques (Victoria Metrics)

Victoria Metrics utilise des sauvegardes incrémentielles sans versionnage d’un bucket, cela signifie que la nouvelle sauvegarde remplace complètement la précédente.

Dans le cas où vous rencontrez l’une des situations suivantes :

  • monter un volume vide dans le répertoire /storage des instances de Victoria Metrics

  • supprimer le répertoire /storage ou les fichiers à l’intérieur des instances de Victoria Metrics

La prochaine sauvegarde (vide) créée sera étiquetée avec une nouvelle version et l’ancienne, avant que le volume ne soit vidé, sera préservée. Les deux sauvegardes seront à partir de ce moment listées comme disponibles pour restauration.

Les métriques (Victoria Metrics) utilisent des instantanés pour stocker des données dans des sauvegardes incrémentielles. De nombreuses instances de Victoria Metrics peuvent stocker des sauvegardes dans le même bucket, chacune d’elles sera stockée dans un répertoire séparé. Tous les fichiers situés dans le répertoire doivent être traités comme un tout unique et ne peuvent être déplacés, copiés ou supprimés que dans leur ensemble.

Les déploiements à haute disponibilité doivent être déployés avec deux instances de Victoria Metrics. Les sauvegardes sont activées/configurées indépendamment pour chacune d’elles.

Les extraits de code/commandes suivants sont fournis pour la première instance de Victoria Metrics victoria-metrics-0. Pour sauvegarder/configurer la deuxième instance, vous devez utiliser victoria-metrics-1

Plan de sauvegarde

Par défaut, les sauvegardes de Victoria Metrics sont créées toutes les 1 h :

  • victoria-metrics-0 - 25 minutes après l’heure

  • victoria-metrics-1 - 35 minutes après l’heure

Le calendrier de sauvegarde peut être configuré en utilisant la valeur Helm victoria-metrics-0.backup.scheduled.schedule selon le format cronexpr

Désactiver les sauvegardes programmées

Pour désactiver les sauvegardes programmées de Victoria Metrics, définissez le calendrier de sauvegarde pour les deux instances à une date lointaine dans le passé :

victoria-metrics-0:
  backup:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)
victoria-metrics-1:
  backup:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

OpenTelemetry (ClickHouse)

ClickHouse utilise à la fois des sauvegardes incrémentales et complètes. Par défaut, les sauvegardes complètes sont exécutées quotidiennement à 00h45, et les sauvegardes incrémentales sont effectuées chaque heure. Chaque sauvegarde crée un nouveau répertoire et les anciennes sauvegardes (répertoires) sont supprimées automatiquement. Tous les fichiers situés dans un répertoire de sauvegarde sont traités comme un groupe unique et ne peuvent être déplacés, copiés ou supprimés qu’en tant que groupe. Il est recommandé d’utiliser l’outil clickhouse-backup disponible sur le Pod suse-observability-clickhouse-shard0-0 pour gérer les sauvegardes.

Plan de sauvegarde

Par défaut, les sauvegardes ClickHouse sont créées :

  • Sauvegarde complète - à 00h45 chaque jour

  • Sauvegarde incrémentale - 45 minutes après l’heure (de 3h à 12h)

Les sauvegardes ont des difficultés avec l’exécution parallèle. Si une deuxième sauvegarde commence avant que la première ne soit terminée, elle perturbera la première sauvegarde. Par conséquent, il est crucial d’éviter l’exécution parallèle. Par exemple, la première sauvegarde incrémentale doit être exécutée trois heures après la complète.

Le calendrier des sauvegardes peut être configuré en utilisant la valeur Helm clickhouse.backup.scheduled.full_schedule et clickhouse.backup.scheduled.incremental_schedule selon le format cronexpr.

Conservation des sauvegardes

Par défaut, l’outil conserve les 308 dernières sauvegardes (complètes et incrémentales), ce qui équivaut à environ 14 jours.

La rétention des sauvegardes peut être configurée en utilisant la valeur Helm clickhouse.backup.config.keep_remote.

Désactiver les sauvegardes programmées

Pour désactiver les sauvegardes ClickHouse programmées, définissez les horaires de sauvegarde complète et incrémentale à une date lointaine dans le passé :

clickhouse:
  backup:
    scheduled:
      full_schedule: '0 0 1 1 1970'         # January 1, 1970 (epoch start)
      incremental_schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

Données de télémétrie (Elasticsearch)

Les instantanés des données de télémétrie (Elasticsearch) sont incrémentaux et stockés dans des fichiers avec l’extension .dat. Les fichiers dans l’emplacement de stockage des sauvegardes Elasticsearch doivent être traités comme un tout unique et ne peuvent être déplacés, copiés ou supprimés qu’en tant que tout.

Les extraits de configuration fournis dans la section activer les sauvegardes activeront les instantanés quotidiens d’Elasticsearch.

Désactiver les instantanés programmés

Pour désactiver les instantanés Elasticsearch programmés, définissez le calendrier des instantanés à une date très ancienne en utilisant la valeur Helm backup.elasticsearch.scheduled.schedule :

backup:
  elasticsearch:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

Calendrier des instantanés

Par défaut, les instantanés Elasticsearch sont créés quotidiennement à 03h00, heure du serveur.

Le calendrier de sauvegarde peut être configuré en utilisant la valeur Helm backup.elasticsearch.scheduled.schedule, spécifiée dans la syntaxe de calendrier cron Elasticsearch (elastic.co).

Conservation des instantanés

Par défaut, les instantanés Elasticsearch sont conservés pendant 30 jours, avec un minimum de 5 instantanés et un maximum de 30 instantanés.

Le temps de conservation et le nombre d’instantanés conservés peuvent être configurés en utilisant les valeurs Helm suivantes :

  • backup.elasticsearch.scheduled.snapshotRetentionExpireAfter, spécifié dans les unités de temps Elasticsearch (elastic.co).

  • backup.elasticsearch.scheduled.snapshotRetentionMinCount

  • backup.elasticsearch.scheduled.snapshotRetentionMaxCount

Par défaut, la tâche de conservation elle-même s’exécute quotidiennement à 1h30 UTC (elastic.co). Si vous définissez les instantanés pour expirer plus rapidement qu’en une journée, par exemple à des fins de test, vous devrez modifier le calendrier de la tâche de conservation.

Indices des instantanés

Par défaut, un instantané est créé pour les indices Elasticsearch dont les noms commencent par sts.

Les indices pour lesquels un instantané est créé peuvent être configurés en utilisant la valeur Helm backup.elasticsearch.scheduled.indices, spécifiée dans le format de tableau JSON (w3schools.com).

Restaurer les sauvegardes et les instantanés

Des scripts pour lister et restaurer les sauvegardes et les instantanés peuvent être téléchargés depuis la dernière version du chart Helm SUSE Observability. Téléchargez et extrayez le backup-scripts-<version>.tar.gz pour commencer.

Avant d’utiliser les scripts, assurez-vous que :

  • Le binaire kubectl est installé et configuré pour se connecter à :

    1. Le cluster Kubernetes où SUSE Observability a été installé.

    2. L’espace de noms dans ce cluster où SUSE Observability a été installé.

  • La valeur Helm global.backup.enabled est définie sur true.

Lister les sauvegardes StackGraph

Pour lister les sauvegardes StackGraph, exécutez la commande suivante :

./restore/list-stackgraph-backups.sh

Le résultat doit ressembler à ceci :

job.batch/stackgraph-list-backups-20210222t111942 created
Waiting for job to start...
=== Listing StackGraph backups in bucket "sts-stackgraph-backup"...
sts-backup-20210215-0300.graph
sts-backup-20210216-0300.graph
sts-backup-20210217-0300.graph
sts-backup-20210218-0300.graph
sts-backup-20210219-0300.graph
sts-backup-20210220-0300.graph
sts-backup-20210221-0300.graph
sts-backup-20210222-0300.graph
===
job.batch "stackgraph-list-backups-20210222t111942" deleted

L’horodatage lorsque la sauvegarde a été effectuée fait partie du nom de la sauvegarde.

Les lignes dans la sortie qui commencent par Error from server (BadRequest): sont attendues. Elles apparaissent lorsque le script attend que le pod démarre.

Restaurer une sauvegarde StackGraph

Pour éviter la perte inattendue de données existantes, une sauvegarde ne peut être restaurée que dans un environnement propre par défaut. Si vous êtes complètement sûr que les données existantes peuvent être écrasées, vous pouvez contourner cette fonctionnalité de sécurité en utilisant la commande -force. N’exécutez la commande de restauration que lorsque vous êtes sûr de vouloir restaurer la sauvegarde.

Pour restaurer une sauvegarde StackGraph dans un environnement propre, sélectionnez un nom de sauvegarde et passez-le comme premier paramètre dans la commande suivante :

./restore/restore-stackgraph-backup.sh sts-backup-20210216-0300.graph

Pour restaurer une sauvegarde StackGraph dans un environnement avec des données existantes, sélectionnez un nom de sauvegarde et passez-le comme premier paramètre dans la commande suivante à côté d’un second paramètre -force :

Notez que les données existantes seront écrasées lorsque la sauvegarde sera restaurée.

Ne faites cela que si vous êtes complètement sûr que les données existantes peuvent être écrasées.

 
./restore/restore-stackgraph-backup.sh sts-backup-20210216-0300.graph -force

Le résultat doit ressembler à ceci :

job.batch/stackgraph-restore-20210222t112142 created
Waiting for job to start...
=== Downloading StackGraph backup "sts-backup-20210216-0300.graph" from bucket "sts-stackgraph-backup"...
download: s3://sts-stackgraph-backup/sts-backup-20210216-1252.graph to ../../tmp/sts-backup-20210216-0300.graph
=== Importing StackGraph data from "sts-backup-20210216-0300.graph"...
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1 (file:/opt/docker/lib/org.codehaus.groovy.groovy-2.5.4.jar) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.vmplugin.v7.Java7$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
===
job.batch "stackgraph-restore-20210222t112142" deleted

Dans le cas où vous exécutez une commande de restauration sans le drapeau -force sur une base de données non vide, la sortie contiendra une erreur comme celle-ci :

ERROR com.stackvista.graph.migration.Restore - Restore isn't possible in a non empty.

Les lignes qui commencent par WARNING: sont attendues. Elles sont générées par Groovy s’exécutant dans JDK 11 et peuvent être ignorées.

Lister les sauvegardes de Victoria Metrics

Pour lister les sauvegardes de Victoria Metrics, exécutez la commande suivante :

./restore/list-victoria-metrics-backups.sh

Le résultat doit ressembler à ceci :

job.batch/victoria-metrics-list-backups-20231016t125557 created
Waiting for job to start...
Waiting for job to start...
=== Fetching timestamps of last completed incremental backups
victoria-metrics-0 victoria-metrics-0-20231128160000 "Wed, 29 Nov 2023 07:36:00 GMT"
victoria-metrics-0 victoria-metrics-0-20231129092200 "Wed, 29 Nov 2023 10:56:00 GMT"

===
job.batch "victoria-metrics-list-backups-20231016t125557" deleted

où vous pouvez voir l’instance de Victoria Metrics, la version de sauvegarde spécifique et la dernière fois qu’une sauvegarde a été effectuée.

Restaurer une sauvegarde de Victoria Metrics

La fonctionnalité de restauration écrase toujours les données. Vous devez faire attention à éviter la perte inattendue de données existantes.

La fonctionnalité de restauration nécessite d’arrêter une instance de Victoria Metrics pendant le processus.

Toutes les nouvelles métriques seront mises en cache par vmagent pendant le processus de restauration, veuillez vous assurer que le vmagent dispose de suffisamment de mémoire pour mettre en cache les métriques.

Pour restaurer une sauvegarde de Victoria Metrics, sélectionnez un nom d’instance et une version de sauvegarde et passez-les comme paramètres dans la commande suivante :

./restore/restore-victoria-metrics-backup.sh victoria-metrics-0 victoria-metrics-0-20231128160000

Le résultat doit ressembler à ceci :

=== Scaling down the Victoria Metrics instance
statefulset.apps/suse-observability-victoria-metrics-0 scaled
=== Allowing pods to terminate
=== Starting restore job
job.batch/victoria-metrics-restore-backup-20231017t092607 created
=== Restore job started. Follow the logs with the following command:
kubectl logs --follow job/victoria-metrics-restore-backup-20231017t092607
=== After the job has completed clean up the job and scale up the Victoria Metrics instance pods again with the following commands:
kubectl delete job victoria-metrics-restore-backup-20231017t092607
kubectl scale statefulsets suse-observability-victoria-metrics-0 --replicas=1

Ensuite, suivez les journaux pour vérifier l’état de la tâche

2023-10-17T07:26:42.564Z    info    VictoriaMetrics/lib/backup/actions/restore.go:194    restored 53072307269 bytes from backup in 0.445 seconds; deleted 639118752 bytes; downloaded 1204539 bytes
2023-10-17T07:26:42.564Z    info    VictoriaMetrics/app/vmrestore/main.go:64    gracefully shutting down http server for metrics at ":8421"
2023-10-17T07:26:42.564Z    info    VictoriaMetrics/app/vmrestore/main.go:68    successfully shut down http server for metrics in 0.000 seconds

Après l’achèvement (assurez-vous que la sauvegarde a été restaurée avec succès), il est nécessaire de suivre les commandes imprimées par la commande précédente :

  • supprimer la tâche de restauration

  • augmenter l’instance de Victoria Metrics

Lister les sauvegardes de ClickHouse

Le script suivant nécessite une autorisation pour exécuter la commande kubectl exec.

Pour lister les sauvegardes de ClickHouse, exécutez la commande suivante :

./restore/list-clickhouse-backups.sh

Le résultat doit ressembler à ceci :

full_2024-06-17T18-50-00          34.41KiB   17/06/2024 18:50:00   remote                                      tar, regular
incremental_2024-06-17T18-51-00   7.29KiB    17/06/2024 18:51:00   remote   +full_2024-06-17T18-50-00          tar, regular
incremental_2024-06-17T18-54-00   7.29KiB    17/06/2024 18:54:00   remote   +incremental_2024-06-17T18-51-00   tar, regular
incremental_2024-06-17T18-57-00   7.29KiB    17/06/2024 18:57:00   remote   +incremental_2024-06-17T18-54-00   tar, regular
full_2024-06-17T19-00-00          26.41KiB   17/06/2024 19:00:00   remote                                      tar, regular
incremental_2024-06-17T19-00-00   6.52KiB    17/06/2024 19:00:00   remote   +incremental_2024-06-17T18-57-00   tar, regular
incremental_2024-06-17T19-03-00   25.37KiB   17/06/2024 19:03:00   remote   +incremental_2024-06-17T19-00-00   tar, regular
incremental_2024-06-17T19-06-00   7.29KiB    17/06/2024 19:06:00   remote   +incremental_2024-06-17T19-03-00   tar, regular

où il est imprimé :

  • nom, le nom commence par full_ - c’est une sauvegarde complète, incremental_ - c’est une sauvegarde incrémentielle

  • taille,

  • date de création,

  • remote - une sauvegarde est téléversée vers un stockage distant tel que S3

  • sauvegarde parente - utilisée par les sauvegardes incrémentielles

  • format et compression

Restaurer une sauvegarde ClickHouse

La fonctionnalité de restauration écrase les données. Toutes les tables de la base de données otel sont supprimées et restaurées à partir de la sauvegarde. Attention à éviter toute perte de données inattendue.

Le script suivant nécessite une autorisation pour exécuter la commande kubectl exec.

La fonctionnalité de restauration nécessite d’arrêter tous les producteurs (comme les exportateurs OpenTelemetry). Le script réduit les charges de travail avant la sauvegarde et les augmente après la fin de la sauvegarde.

Pour restaurer une sauvegarde ClickHouse, sélectionnez une version de sauvegarde et passez-la comme paramètre dans la commande suivante :

./restore/restore-clickhouse-backup.sh incremental_2024-06-17T18-57-00

Le résultat doit ressembler à ceci :

...
2024/06/17 19:14:19.509498  info download object_disks start backup=incremental_2024-06-17T19-06-00 operation=restore_data table=otel.otel_traces_trace_id_ts_mv
2024/06/17 19:14:19.509530  info download object_disks finish backup=incremental_2024-06-17T19-06-00 duration=0s operation=restore_data size=0B table=otel.otel_traces_trace_id_ts_mv
2024/06/17 19:14:19.509549  info done                      backup=incremental_2024-06-17T19-06-00 duration=0s operation=restore_data progress=12/12 table=otel.otel_traces_trace_id_ts_mv
2024/06/17 19:14:19.509574  info done                      backup=incremental_2024-06-17T19-06-00 duration=66ms operation=restore_data
2024/06/17 19:14:19.509591  info done                      backup=incremental_2024-06-17T19-06-00 duration=167ms operation=restore version=2.5.13
2024/06/17 19:14:19.509684  info clickhouse connection closed logger=clickhouse
Data restored

Lister les instantanés Elasticsearch

Pour lister les instantanés Elasticsearch, exécutez la commande suivante :

./restore/list-elasticsearch-snapshots.sh

Le résultat doit ressembler à ceci :

job.batch/elasticsearch-list-snapshots-20210224t133115 created
Waiting for job to start...
Waiting for job to start...
=== Listing Elasticsearch snapshots in snapshot repository "sts-backup" in bucket "sts-elasticsearch-backup"...
sts-backup-20210219-0300-mref7yrvrswxa02aqq213w
sts-backup-20210220-0300-yrn6qexkrdgh3pummsrj7e
sts-backup-20210221-0300-p481sih8s5jhre9zy4yw2o
sts-backup-20210222-0300-611kxendsvh4hhkoosr4b7
sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk
===
job.batch "elasticsearch-list-snapshots-20210224t133115" deleted

L’horodatage lorsque la sauvegarde a été effectuée fait partie du nom de la sauvegarde.

Supprimer les indices Elasticsearch

Vous pouvez utiliser l’option --delete-all-indices avec le script de restauration pour supprimer automatiquement tous les indices avant la restauration. Pour plus d’informations, voir restaurer un instantané Elasticsearch.

Pour supprimer manuellement les indices Elasticsearch existants et restaurer un instantané, suivez ces étapes :

  1. Arrêter l’indexation - réduire tous les déploiements utilisant Elasticsearch à 0 :

    kubectl scale --replicas=0 deployment -l observability.suse.com/scalable-during-es-restore="true"

  2. Ouvrir un port de transfert vers le maître Elasticsearch :

    kubectl port-forward service/suse-observability-elasticsearch-master 9200:9200

  3. Obtenir une liste de tous les indices :

    curl "http://localhost:9200/_cat/indices?v=true"

    Le résultat doit ressembler à ceci :

    health status index                              uuid                   pri rep docs.count docs.deleted store.size pri.store.size dataset.size
green  open   .ds-sts_k8s_logs-2025.09.28-004619 9p7RZwNCR-aQwInTMr5Bow   3   1   24511032            0        6gb            3gb          3gb
green  open   sts_topology_events-2025.10.01     86I2JZIeRzqWkK1dolHzhg   1   1    1576132            0    111.6mb         55.8mb       55.8mb
green  open   sts_topology_events-2025.10.02     T-bcrok_S1uVPLusQuCMxw   1   1     999748            0     75.2mb         37.6mb       37.6mb
green  open   .ds-sts_k8s_logs-2025.09.30-004653 rwlcAr0sTPe9NaImtJLIiw   3   1   24387607            0        6gb            3gb          3gb
green  open   sts_topology_events-2025.09.10     T0x-qvyUR2-dg4fyvdZIaQ   1   1    1746143            0    131.6mb         65.8mb       65.8mb

  4. Supprimer un index avec la commande suivante :

    curl -X DELETE "http://localhost:9200/INDEX_NAME?pretty"

    Remplacez INDEX_NAME par le nom de l’index à supprimer, par exemple :

    curl -X DELETE "http://localhost:9200/sts_internal_events-2021.02.19?pretty"

  5. La sortie doit être :

    {
"acknowledged" : true
}

Restaurer un instantané Elasticsearch

Lorsque un instantané est restauré, les indices existants ne seront pas écrasés.

Vous pouvez utiliser l’option --delete-all-indices pour supprimer automatiquement tous les indices par le script de restauration, ou les supprimer manuellement comme décrit dans supprimer les indices Elasticsearch.

Si le Elasticsearch PersistentVolumes a été recréé (par exemple, par suppression accidentelle et redémarrage du pod suivant), vous devez recréer la configuration de sauvegarde Elasticsearch en utilisant l’une des deux méthodes ci-dessous :

  • Réinstaller le graphique Helm de SUSE Observability avec la même configuration utilisée pour l’installation initiale (OU)

  • Déclencher manuellement le CronJob d’initialisation de la sauvegarde :

    kubectl create job --from=cronjob.batch/suse-observability-backup-init "suse-observability-backup-init-$(date +%s)"

Pour restaurer un instantané Elasticsearch, sélectionnez un nom d’instantané et passez-le comme premier paramètre. Vous pouvez spécifier en option :

  • Une liste d’indices à restaurer, séparée par des virgules. Si non spécifié, tous les indices correspondant à la valeur Helm backup.elasticsearch.scheduled.indices seront restaurés. La valeur par défaut est "sts*").

  • Introduit dans la version 2.6.1, vous pouvez utiliser l’option "--supprimer-tous-les-indices" pour supprimer automatiquement tous les indices existants avant de restaurer.

Restauration basique

./restore/restore-elasticsearch-snapshot.sh \
  sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk

Restaurer des indices spécifiques

./restore/restore-elasticsearch-snapshot.sh \
  sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk \
  "<INDEX_TO_RESTORE>,<INDEX_TO_RESTORE>"

Restaurer avec suppression automatique des indices

./restore/restore-elasticsearch-snapshot.sh \
  sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk \
  --delete-all-indices

Lors de l’utilisation de l’option --delete-all-indices, confirmez dans l’invite pour continuer l’action :

WARNING: All indices will be deleted before restore!
Are you sure you want to continue? (yes/no): yes
=== Starting restore job
job.batch/elasticsearch-restore-20251003t115746 created
=== Restore job started. Follow the logs and clean up the job with the following commands:
kubectl logs --follow job/elasticsearch-restore-20251003t115746
kubectl delete job/elasticsearch-restore-20251003t115746

Suivez les journaux pour voir la progression de la suppression et de la restauration :

kubectl logs --follow job/elasticsearch-restore-20251003t115746

=== Deleting all indices matching pattern "sts*"...
Found indices to delete:
.ds-sts_k8s_logs-2025.10.03-000007
.ds-sts_k8s_logs-2025.10.03-000004
sts_topology_events-2025.10.02
sts_topology_events-2025.10.03
...
=== All indices deleted successfully
=== Restoring ElasticSearch snapshot "sts-backup-20251003-0925-aby7d1tgs9whvbm6qj04ug" (indices = "sts*") from snapshot repository "sts-backup" in bucket "sts-elasticsearch-backup"...
{
  "snapshot" : {
    "snapshot" : "sts-backup-20251003-0925-aby7d1tgs9whvbm6qj04ug",
    "indices" : [
      ".ds-sts_k8s_logs-2025.10.02-000003",
      "sts_topology_events-2025.10.02",
      "sts_topology_events-2025.10.03"
    ],
    "shards" : {
      "total" : 15,
      "failed" : 0,
      "successful" : 15
    }
  }
}
===

Après que les indices ont été restaurés, augmentez tous les déploiements utilisant Elasticsearch :

kubectl scale --replicas=1 deployment -l observability.suse.com/scalable-during-es-restore="true"