opentelekomcloud_rds_instance_v3 - restoring to original instance deletes instance incl. backups and ends in instance creation loop

[reiSh6phoo9o]

Terraform provider version

provider registry.terraform.io/opentelekomcloud/opentelekomcloud v1.35.3

Affected Resource(s)

• opentelekomcloud_rds_instance_v3

Terraform Configuration Files

resource "opentelekomcloud_rds_instance_v3" "main" {
  name                   = "test-rds"
  availability_zone = var.availability_zone

  db {
    password = random_password.main.result
    type         = var.db_type
    version    = var.db_version
    port         = local.db_port
  }

  security_group_id = opentelekomcloud_networking_secgroup_v2.main.id
  subnet_id              = data.opentelekomcloud_vpc_subnet_v1.private.id
  vpc_id                   = data.opentelekomcloud_vpc_v1.default.id
  flavor                     = var.flavor

  volume {
    type              = var.volume_type
    size               = var.volume_size_gb
  }
 
  # add this only after the instance has been created:
  restore_point {
    instance_id = "<id of this instance>"
    backup_id   = "<id of automated backup of this instance>"
  }
}

Steps to Reproduce

1. terraform apply without restore_point block -> creates the instance
2. terraform apply with additional restore_point block

Expected Behavior

From docs here: https://docs.otc.t-systems.com/relational-database-service/umn/working_with_rds_for_mysql/backups_and_restorations/restoring_from_backup_files_to_db_instances.html#procedure , I assume that I can restore to the original instance.
From docs here: https://registry.terraform.io/providers/opentelekomcloud/opentelekomcloud/latest/docs/resources/rds_instance_v3#restore_point , I can not see any constraints.

When adding a restore_point block to an existing opentelekomcloud_rds_instance_v3, I expect this to trigger a "Restore to Original". That is, it should not destroy the original instance, nor delete all automated backups.

Alternativly, the provider docs should clearly document, that:

• adding a restore_point block triggers instance replacment, thus deleting automated backups
• thus its not possible to restore to original instance using terraform
• thus this block basically is only useful on instance creation

Actual Behavior

tf apply triggers an instance replacement, thus:

• deletes the original instance
• deletes all automated backups associated with that instance
• provisions a new instance and tries to apply the backup on it
• this leads to a loop, the web console shows: "Single task exception. The system is trying again."
• propably because the backup it tries to apply is deleted in the previous step
• so finally, my original database and all associated backus are gone, and I'm stuck in an instance creation loop

[anton-sidelnikov]

Hello @reiSh6phoo9o, no, you do all procedure wrong, please read documentation carefully. Yes you can restore RDS but it must be another RDS instance.
If you apply

  restore_point {
    instance_id = "<id of this instance>"
    backup_id   = "<id of automated backup of this instance>"
  }

to existing one, so now you know the result.

From documentation:

If you point existing instance it will become unavailable

Never use terraform with auto-approve key, terraform always informs you about force recreation, it always means that resource will be destroyed.

[reiSh6phoo9o]

Hi @anton-sidelnikov ,

thanks for looking into this.

From what you tell, and what I found out myself, I agree, that it is not possible to restore to the same instance (aka "restore to original", as it is called in otc docs) using terraform.

I disagree, that the documentation tells anything about it. Docs list three methods for restoration: restore to original, restore to existing, restore to new. The screenshot you took documents the "restore to existing", which refers to : restoring to another, already existing rds.

The method "restore to original" is documented like that:

From this, and from my experience using OTC webconsole, it is clearly possible and supported to restore a running RDS to an earlier point in time, without replacing the instance.

The thing I ask, is two things:

First, feature request: would love to see, that I can restore a RDS to a earlier point in time, as I can do using the webconsole.

Second: if that's not possible: would love to see some hints in the provider documentation, that the method "restore to original" is not possible using terraform.

Thanks!

[anton-sidelnikov]

Hi @reiSh6phoo9o, yes I agree, we will update documentation first, then will think how to implement another options for restoration, currently from provider you can only restore to another instance.

[artem-lifshits]

@reiSh6phoo9o feature added and documentation updated.

[deem1978]

Hi @artem-lifshits , I am using provider version 1.36.23 and I am facing a similar problem. When I try to "restore to original" by using the block

  restore_point {
    instance_id = "<id of this instance>"
    backup_id   = "<id of automated backup of this instance>"
  }
}

in the same terraform project (state) where the instance that has to be restored lives, than I simply get
No changes. Your infrastructure matches the configuration.
As additional test, I have also a terraform project dedicated to the automation of RDS Instance´s restore, and if I use the block in this project than it would simply create a new instance.
I have to say that terraform documentation states that:

"By selecting this option (restore_point) a new RDS instance will be created". If I understand well it is not about restoring to the original instance, but about creating a new one.
It would be possible to know if the implementation has been successful added and how to use it? Or if with terraform it is simply not possible to restore to original?
Thank you very much.

[deem1978]

@anton-sidelnikov , @artem-lifshits any news about the topic?
Thank you for feedback.

[artem-lifshits]

Hello @deem1978 could you provide your TF config with both instances?

[artem-lifshits]

I've tested instance creation using restore point and everything worked fine for me.
Here's the config:

resource "opentelekomcloud_rds_instance_v3" "instance" {
  name              = "terraform_test_rds_instance"
  availability_zone = ["eu-de-03"]

  db {
    password = var.password
    type     = "PostgreSQL"
    version  = "16"
    port     = "5432"
  }

  security_group_id = var.security_group_id
  subnet_id         = var.network_id
  vpc_id            = var.vpc_id
  flavor            = "rds.pg.c2.medium"

  volume {
    type = "COMMON"
    size = 100
  }
}

resource "opentelekomcloud_rds_backup_v3" "backup" {
  instance_id = opentelekomcloud_rds_instance_v3.instance.id
  name        = "rds-backup-test-01"
}

resource "opentelekomcloud_rds_instance_v3" "from_backup" {
  name              = "instance-restored"
  availability_zone = ["eu-de-01"]
  flavor            = "rds.pg.c2.medium"

  restore_point {
    instance_id = opentelekomcloud_rds_instance_v3.instance.id
    backup_id   = opentelekomcloud_rds_backup_v3.backup.id
  }

  db {
    password = var.password
    type     = "PostgreSQL"
    version  = "16"
    port     = "5432"
  }

  security_group_id = var.security_group_id
  subnet_id         = var.network_id
  vpc_id            = var.vpc_id
  volume {
    type = "COMMON"
    size = 150
  }
}

[deem1978]

Hi @artem-lifshits and thank you very much for you feedback.
Just to be sure:

• resource "opentelekomcloud_rds_instance_v3" "instance" is an already running instance that has to be restored to a certain point
• resource "opentelekomcloud_rds_backup_v3" "backup": you create a backup of the running instance
• resource "opentelekomcloud_rds_instance_v3" "from_backup" : you create a new instance from the previously created backup

So if am right you just create a new instance from a backup, and that means that it is not possible to restore to the same instance (aka "restore to original"), instead you create a new one from backup. Or do I have misunderstood something?

[artem-lifshits]

@deem1978 you are right, new instance will be created from a backup.
I see the whole picture now, I have opened a new ticket to implement this feature for RDS v3 instances: #2776

[deem1978]

Thank you :)