Support creating an alloydb cluster from backup. Data call to fetch backup ids with filters.

[fishpen0]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

Alloydb has backup recovery features eerily similar to rds snapshots. You can create a new cluster using an existing backup as documented here. As far as I can tell this is not supported in the current provider and there is no terraform-native way to create a new alloydb cluster from an alloydb backup.

rds_cluster supports the snapshot_identifier argument which allows you to provide the snapshot ID to the rds_cluster resource and it will launch the cluster from that backup.

I think it is valuable to be able to replicate this functionality by providing an optional backup_identifier argument to the google_alloydb_cluster resource. In order for this to work there would also need to be a new data source google_alloydb_backup_version or something to be able to fetch and filter the backups to select which one to recover from. modeling it from db_snapshot may be a valuable starting point.

This would allow us to create recovery clusters from terraform and is valuable for DR simulations and any other use case we might have for creating clusters from backups, like copying lost data back to the main cluster after a botched migration or creating an exceptionally large sibling cluster for nightly processing .

New or Affected Resource(s)

• google_alloydb_cluster
• data google_alloydb_backup_version

Potential Terraform Configuration

resource "google_alloydb_cluster" "default" {
  cluster_id = "alloydb-cluster"
  location   = "us-central1"
  network    = data.google_compute_network.default.id

  automated_backup_policy {
    location      = "us-central1"
    backup_window = "1800s"
    enabled       = true

    weekly_schedule {
      days_of_week = ["MONDAY"]

      start_times {
        hours   = 23
        minutes = 0
        seconds = 0
        nanos   = 0
      }
    }
  }
}

data "google_alloydb_backup_version" "latest" {
  cluster_id  = google_alloydb_cluster.default.id
  most_recent = true
}

resource "google_alloydb_cluster" "recovery_cluster" {
  cluster_id        = google_alloydb_cluster.default.id
  location          = "us-central1"
  network           = data.google_compute_network.default.id
  backup_identifier = data.google_alloydb_backup_version.latest
}

References

• Add support AlloyDB for PostgreSQL #11754
• AlloyDB for PostgreSQL - Documentation - Guides - Restore a backup
• rds_cluster
• snapshot_identifier
• db_snapshot

b/284523617

[jdub55]

Do we have any updates on when this will be implemented? It is blocking our deployment of AlloyDB to our Customers.

[rileykarson]

This was marked "Backlog" which indicates we're not certain this is a feature the provider should support. Not sure I didn't comment with context at the time, sorry! That would have been:

As an imperative action, backup restores are probably better performed with an imperative tool like gcloud than with Terraform and then imported into Terraform as fully-fledged resources. The problem is that the configuration of the restore is baked in to the representation of the resource in Terraform, such as with https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/sql_database_instance#restore_backup_context, requiring state surgery if a user ever wants to remove the original restore information.

However, probably better doesn't mean there aren't valid reasons to do so. Based on that SQL resource as a precedent I'll move this to goals and tag it for the appropriate service team at Google to review. That doesn't mean there is a direct assignee at the moment, and scheduling will be up to them.

[GoogleMarcfont]

FYI I am working on this at the moment. No ETA yet, but starting to make progress.

[teadur]

FYI I am working on this at the moment. No ETA yet, but starting to make progress.

@GoogleMarcfont is this solved now ?