15

I am creating new RDS MySQL instances from snapshots and updating their configurations both via the API and through the UI. Regardless of how I create or update instances, these actions automatically trigger new snapshots to be created through some kind of automatic backup process. Is there a way to disable snapshot creation when performing these actions since I do not need the additional snapshots and their creation is causing an unnecessary delay?

jmsb
  • 4,846
  • 5
  • 29
  • 38
  • Check if `automation backup` enabled or not http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html – BMW Feb 29 '16 at 21:36
  • @BMW I'll look into it, but from the API side this appears to only work with modifications, not at creation time. – jmsb Feb 29 '16 at 22:10

2 Answers2

39

I spoke with AWS support and it looks like there is no way to prevent the backup being generated at instance creation time. This is due to how the backup creation on create/update is triggered (it is part of the automated backup process) and limited ability to control this feature (toggle it on and off, but only for existing instances).

Here are some more details in case anyone else runs into the same problems that I did.

I am interested in two scenarios:

  1. Do not create a backup on a RestoreDBInstanceFromDBSnapshot request
  2. Do not create a backup on a ModifyDBInstance request

The backups are controlled by this flag:

BackupRetentionPeriod = 0

Unfortunately this flag is part of an instance and of a snapshot, but can only be set on an instance. Therefore, in order to create an instance with this flag set (and thus no backup generated), the snapshot would have to have this flag disabled. This can only happen if the source instance had this flag disabled. At this point we could consider toggling the flag on the original instance when taking a snapshot, however disabling and re-enabling this flag has negative side effects, including:

There is a way to disable automatic backups for existing instances 
however we highly discourage against this because it disables point-in-time
recovery. Once disabled, re-enabling them will only restore the backups
starting from the time you re-enable automatic backups.

We would lose all existing backups on the original instance. The end result is that there is not an effective way to avoid creating the first backup when an instance is created from a snapshot.

There is better news when updating an existing instance, since we can disable backups as part of the ModifyDBInstance request:

https://rds.amazonaws.com/
  ?Action=ModifyDBInstance
  &DBInstanceIdentifier=mydbinstance
  &BackupRetentionPeriod=0

Of course this still suffers from the loss of backups; however, my original purpose was to be able to create and modify snapshots of production databases, use them for a short period of time (hours), and then throw them away. Avoiding extraneous backup creation reduces overhead in this process.

Hopefully this information is useful to someone else!

jmsb
  • 4,846
  • 5
  • 29
  • 38
  • 2
    nice feedback. I think you can accept your answer as well. – BMW Mar 01 '16 at 20:35
  • You can do it with `awscli` https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Disabling (but not for clusters where the min retention day is 1) – Jorge Orpinel Pérez Oct 19 '18 at 10:53
  • @Jorge that still only works for instances not snapshots, as stated in the original answer. – Tim Crone Mar 06 '20 at 20:41
-1

If you create your RDS instance with Terraform using,

source = "github.com/terraform-aws-modules/terraform-aws-rds.git"

Although you must still set for example,

maintenance_window = "Mon:00:00-Mon:03:00"
backup_window      = "03:00-06:00"

You can set

skip_final_snapshot= true

And the snapshot won't be created.

Shlomi

Shlomi
  • 33
  • 7
  • `skip_final_snapshot` refers to the snapshot created when the DB is destroyed. I think the question refers to the creation of a Backup on DB create/update instead – Andres Decastro Nov 02 '22 at 09:38