☰

Der Snapshot-Zeitplan für persistente Datenträger von Google Cloud Compute Engine funktioniert nicht

tag-icon • tag-icon google-cloud-platform google-compute-engine terraform
Der Snapshot-Zeitplan für persistente Datenträger von Google Cloud Compute Engine funktioniert nicht

Ich habe eine VM mit Terraform auf GCP erstellt und auch eine persistente Festplatte separat mit den Ressourcen google_compute_disk , google_compute_resource_policy, google_compute_disk_resource_policy_attachment, um auch einen Snapshot-Zeitplan an die Festplatte anzuhängen

Das war vor zwei Tagen und es wurde kein Snapshot erstellt.
Hatte jemand ähnliche Probleme?

Der Zeitplan ist auf täglich eingestellt.

Dies ist die Terraform-Konfiguration, die ich verwendet habe


resource "google_compute_disk" "fast_storage" {
  name = "${var.env}-fast-disk"
  type = "pd-ssd"
  size = 50 #GiB
  zone = var.zone
  labels = {
    environment = var.env
    type        = "ssd"

  }
  physical_block_size_bytes = 4096
}


resource "google_compute_resource_policy" "backup_policy" {
  name   = "${var.env}-backup-policy"
  region = var.region
  snapshot_schedule_policy {
    schedule {
      daily_schedule {
        days_in_cycle = 1
        start_time    = "04:00"
      }
    }
    retention_policy {
      max_retention_days    = 5
      on_source_disk_delete = "KEEP_AUTO_SNAPSHOTS"
    }
    snapshot_properties {
      labels = {
        environment = var.env
        type        = "ssd"
      }
      storage_locations = ["eu"]
      guest_flush       = true
    }
  }

}


resource "google_compute_disk_resource_policy_attachment" "backup_policy_attachment" {
  name = google_compute_resource_policy.backup_policy.name
  disk = google_compute_disk.fast_storage.name
  zone = var.zone
}


resource "google_compute_instance" "main" {
  name                      = "${var.env}-main-server"
  machine_type              = "custom-2-4096"
  zone                      = var.zone
  allow_stopping_for_update = true
  desired_status            = "RUNNING"
  deletion_protection       = true
  tags                      = ["${var.env}-main-server"]

  boot_disk {
    auto_delete = false

    mode = "READ_WRITE"
    initialize_params {
      image = "debian-cloud/debian-10"
      type  = "pd-ssd"
      size  = 20
    }
  }

  network_interface {
    network    = var.network_id
    subnetwork = var.subnetwork_id
    network_ip = google_compute_address.main_server_internal.address

    access_config {
      nat_ip = google_compute_address.main_server_external.address
    }
  }
  scheduling {
    on_host_maintenance = "MIGRATE"
    automatic_restart   = true
  }

  lifecycle {
    ignore_changes = [attached_disk]
  }
}


resource "google_compute_attached_disk" "fast_storage" {
  disk        = google_compute_disk.fast_storage.id
  instance    = google_compute_instance.main.id
  device_name = "fast"
  mode        = "READ_WRITE"
}

Antwort1

Festlegen guest_flush = false(dies funktioniert nur unter Windows und scheint mit GCP nicht verhandelbar zu sein).

Überprüfen Sie die Stackdriver-Protokolle – Datenträger

Antwort2

das funktioniert nur unter Windows und scheint mit gcp nicht verhandelbar zu sein

Das istnicht wahrBitte folgen Sie dem ArtikelErstellen eines Linux-Anwendungskonsistenten persistenten Datenträger-SnapshotsDort wird erklärt, was notwendig ist. Im Wesentlichen ist dies:

  1. Fügen Sie mit [Snapshots]den Abschnitt hinzu und starten Sie den Agenten mit neu . Der letzte Befehl erstellt ein Verzeichnis, falls es noch nicht existiert./etc/default/instance_configs.cfgenabled = truesudo systemctl restart google-guest-agent.service/etc/google/snapshots
  2. ErstellenVorUndPostSnapshot-Skripte bei /etc/google/snapshots/pre.shbzw. /etc/google/snapshots/post.shStellen Sie sicher, dass die Skripteausführbarals Root (das steht nicht explizit in der Dokumentation, ist aber leicht herauszufinden); und
  3. Erstellen Sie einen Snapshot (oder einen Snapshot-Zeitplan) mit aktiviertem Guest-Flush.

Habe gerade überprüft, dass es in GCP funktioniert.

Wenn Sie Ihre VM-Instanz(en) nicht wie oben beschrieben vorbereitet haben, würden beim Versuch, anwendungskonsistente Snapshots zu erstellen, wie unten beschrieben, Fehler auftreten:

  • Wenn 1. oben nicht durchgeführt wird: Operation type [createSnapshot] failed with message "You can only use guest-flush on disks attached to instances with supported operating systems. Make sure you have the latest image version and agent installed with required services (e.g. VSS for Windows).";
  • Wenn 2. oben nicht durchgeführt wird: Operation type [createSnapshot] failed with message "Guest Consistent Snapshot failed (Detail: pre_snapshot_script or post_snapshot_script not found). Verify you are running the latest image version and agent. For non-Windows, review settings in /etc/default/instance_configs.cfg on the instance. For more information, see the Guest Consistent Snapshot documentation."oder Folgendes, wenn Skripte nicht ausführbar gemacht werden: Operation type [createSnapshot] failed with message "Guest Consistent Snapshot failed (Detail: unhandled script return code -1). Verify you are running the latest image version and agent. For non-Windows, review settings in /etc/default/instance_configs.cfg on the instance. For more information, see the Guest Consistent Snapshot documentation.".

Und wenn Sie Snapshot-Zeitpläne haben, die keine Snapshots erstellen, suchen Sie bitte nach Fehlern wie You can only use guest-flush on disks attached to instances with supported operating systems. Make sure you have the latest image version and agent installed with required services (e.g. VSS for Windows).im Logs Explorer, die leicht mit einer Abfrage wie gefunden werden können

severity=ERROR`
resource.type="gce_disk"
protoPayload.methodName="ScheduledSnapshots"

Ich meine, Sie haben Ihre VMs nicht wie oben erklärt vorbereitet.

verwandte Informationen