Restaurar RDS desde un Snapshot: ¿Sobreescribe la instancia existente o crea una nueva?

Cuando un ambiente de producción empieza a comportarse mal y la única salida es un snapshot, la primera pregunta que aparece es si restaurar va a pisar la instancia actual o va a crear algo nuevo. La respuesta tiene implicaciones directas en el endpoint de conexión, en los grupos de seguridad y en cuánto tiempo va a estar caído el servicio — y si no se entiende el modelo antes de ejecutar, el incidente se puede complicar más.

TL;DR: Restaurar un snapshot de RDS siempre crea una instancia nueva

Restaurar desde un snapshot en RDS nunca sobreescribe la instancia de origen. El proceso crea una instancia completamente nueva con un endpoint distinto. La instancia original permanece intacta y en ejecución. Para apuntar las aplicaciones a la instancia restaurada, se debe actualizar el string de conexión o redirigir el DNS manualmente.

AspectoComportamiento real
Instancia originalPermanece intacta, sin modificaciones
Instancia restauradaNueva instancia con nuevo endpoint
EndpointDiferente al de la instancia original
Grupos de seguridadSe asignan los del VPC por defecto, no los de la original
Parameter groupSe asigna el grupo por defecto, no el de la original
Tiempo de corteDepende de cuándo se redirige el tráfico

Cómo funciona la restauración de snapshots en RDS

Un snapshot de RDS es una copia del volumen de almacenamiento de la instancia en un punto en el tiempo. Internamente, RDS usa Amazon EBS snapshots como mecanismo de respaldo. Cuando se restaura, AWS provisiona nuevo cómputo, nuevo almacenamiento y una nueva entrada DNS — no reutiliza nada de la instancia original.

Este diseño es intencional. Permite validar la restauración sin interrumpir el servicio en producción. La instancia restaurada arranca en estado available solo después de que el volumen de almacenamiento está completamente inicializado, aunque en instancias grandes el primer acceso a bloques no cargados puede ser más lento hasta que el proceso de restauración en segundo plano completa la hidratación del volumen.

graph TD S["Snapshot RDS
estado: available"] --> R["Proceso de Restauración
restore-db-instance-from-db-snapshot"] R --> NI["Nueva Instancia RDS
endpoint diferente"] R --> OI["Instancia Original
sin modificaciones"] NI --> SG["Security Group
por defecto del VPC"] NI --> PG["Parameter Group
por defecto del motor"] NI --> EP["Nuevo Endpoint DNS
actualizar en aplicaciones"] EP --> RT["Redirección de tráfico
Route 53 CNAME o app config"]
  1. Snapshot existente: copia del volumen EBS de la instancia original en un punto en el tiempo.
  2. Proceso de restauración: AWS provisiona nuevo cómputo y almacenamiento independiente.
  3. Instancia restaurada: nueva instancia con endpoint propio, parameter group por defecto y security groups del VPC por defecto.
  4. Instancia original: permanece en ejecución sin ninguna modificación.
  5. Redirección de tráfico: paso manual — actualizar string de conexión o redirigir el CNAME en Route 53.

Qué configuración NO se hereda del snapshot

Este es el punto donde más se cometen errores en producción. El snapshot preserva los datos, pero varios parámetros de configuración de la instancia original no se transfieren automáticamente a la instancia restaurada.

  • Security groups: la instancia restaurada recibe el security group por defecto del VPC. Si la instancia original tenía reglas de acceso específicas, hay que reasignarlas manualmente.
  • Parameter group: se asigna el parameter group por defecto del motor. Si la instancia original usaba un parameter group personalizado, hay que asociarlo explícitamente durante o después de la restauración.
  • Option group: similar al parameter group — se asigna el grupo por defecto a menos que se especifique uno durante la restauración.
  • Multi-AZ: la instancia restaurada es Single-AZ por defecto. Multi-AZ debe habilitarse explícitamente después de la restauración si se requiere.
  • Configuración de mantenimiento y backup: ventanas de mantenimiento y retención de backups vuelven a los valores por defecto.
Es como restaurar una imagen de servidor en hardware nuevo: los datos están ahí, pero el servidor nuevo no sabe nada de las reglas de firewall ni de la configuración de red del servidor original. Hay que recablearla.

Restaurar un snapshot de RDS paso a paso

Paso 1: Identificar el snapshot a restaurar

Antes de ejecutar cualquier cosa, confirmar que el snapshot existe, que está en estado available y que corresponde al punto en el tiempo correcto. Un snapshot en estado creating o copying no puede usarse para restaurar.

aws rds describe-db-snapshots \
  --db-instance-identifier mi-instancia-produccion \
  --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Estado:Status,Fecha:SnapshotCreateTime}' \
  --output table \
  --region us-east-1

Paso 2: Restaurar la instancia desde el snapshot

El comando restore-db-instance-from-db-snapshot crea la nueva instancia. El parámetro --db-instance-identifier define el nombre de la instancia nueva — debe ser diferente al de la instancia original si ambas van a coexistir. Especificar explícitamente el DB subnet group y el parameter group para no depender de los valores por defecto.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier mi-instancia-restaurada \
  --db-snapshot-identifier rds:mi-instancia-produccion-2024-01-15-03-00 \
  --db-instance-class db.r6g.large \
  --db-subnet-group-name mi-subnet-group \
  --no-publicly-accessible \
  --region us-east-1

Si se necesita asociar un parameter group personalizado durante la restauración, agregar el parámetro --db-parameter-group-name nombre-del-parameter-group.

Paso 3: Esperar a que la instancia esté disponible

La restauración puede tomar varios minutos dependiendo del tamaño del snapshot. El waiter de la CLI bloquea la ejecución hasta que la instancia alcanza el estado available, lo cual es útil en scripts de automatización.

aws rds wait db-instance-available \
  --db-instance-identifier mi-instancia-restaurada \
  --region us-east-1

Paso 4: Verificar el endpoint de la nueva instancia

Una vez disponible, obtener el endpoint para confirmar que es diferente al de la instancia original. Este es el valor que hay que actualizar en las aplicaciones o en el CNAME de Route 53.

aws rds describe-db-instances \
  --db-instance-identifier mi-instancia-restaurada \
  --query 'DBInstances[0].Endpoint.{Host:Address,Puerto:Port}' \
  --output table \
  --region us-east-1

Paso 5: Reasignar security groups

La instancia restaurada tiene el security group por defecto del VPC. Reasignar los grupos correctos antes de redirigir tráfico — de lo contrario las aplicaciones no podrán conectarse aunque el endpoint sea correcto.

aws rds modify-db-instance \
  --db-instance-identifier mi-instancia-restaurada \
  --vpc-security-group-ids sg-0abc123def456 sg-0xyz789ghi012 \
  --apply-immediately \
  --region us-east-1

Paso 6: Redirigir el tráfico

Con la instancia validada y los security groups correctos, actualizar el CNAME en Route 53 para apuntar al nuevo endpoint. Este es el momento de corte real — hasta este paso, la instancia original sigue recibiendo tráfico.

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "db.midominio.com",
        "Type": "CNAME",
        "TTL": 60,
        "ResourceRecords": [{
          "Value": "mi-instancia-restaurada.c9hakodmel7d.us-east-1.rds.amazonaws.com"
        }]
      }
    }]
  }' \
  --region us-east-1

Política IAM mínima para ejecutar la restauración

Las acciones de restauración y modificación de RDS requieren permisos específicos. Las acciones Describe* de RDS soportan restricción a nivel de recurso individual según la Service Authorization Reference, aunque en ejemplos operativos es común usar Resource: "*" por simplicidad. Para ambientes de producción, se recomienda restringir al ARN del snapshot y de la instancia cuando sea posible.

🔽 Ver política IAM mínima 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeRDSResources",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSnapshots",
        "rds:DescribeDBInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RestoreFromSnapshot",
      "Effect": "Allow",
      "Action": [
        "rds:RestoreDBInstanceFromDBSnapshot"
      ],
      "Resource": [
        "arn:aws:rds:us-east-1:123456789012:snapshot:rds:mi-instancia-produccion-2024-01-15-03-00",
        "arn:aws:rds:us-east-1:123456789012:db:mi-instancia-restaurada"
      ]
    },
    {
      "Sid": "ModifyRestoredInstance",
      "Effect": "Allow",
      "Action": [
        "rds:ModifyDBInstance"
      ],
      "Resource": "arn:aws:rds:us-east-1:123456789012:db:mi-instancia-restaurada"
    }
  ]
}

Caso real: el error que todos cometen al menos una vez

La instancia restaurada aparece como available en la consola. Se actualiza el string de conexión en la aplicación. Las conexiones fallan con 'timeout'. El equipo asume que la restauración está corrupta y empieza a buscar otro snapshot.

El problema real: los security groups. La instancia restaurada tiene el SG por defecto del VPC, que no tiene reglas de entrada para el puerto 5432 (o 3306). La instancia original tenía un SG personalizado con esas reglas. La restauración no lo hereda.

El diagnóstico correcto tarda menos de un minuto:

aws rds describe-db-instances \
  --db-instance-identifier mi-instancia-restaurada \
  --query 'DBInstances[0].VpcSecurityGroups' \
  --output table \
  --region us-east-1

Si el resultado muestra solo el SG por defecto, ese es el problema. Reasignar los grupos correctos con modify-db-instance y las conexiones se establecen en segundos.

El timeout no era la instancia — era el firewall.

Diferencia entre restaurar desde snapshot y Point-in-Time Recovery

RDS ofrece dos mecanismos de restauración que se confunden frecuentemente. Ambos crean una instancia nueva — ninguno sobreescribe la original.

MecanismoGranularidadComando CLICaso de uso
Snapshot restorePunto exacto del snapshotrestore-db-instance-from-db-snapshotRestaurar a un backup manual o automático específico
Point-in-Time Recovery (PITR)Cualquier segundo dentro del período de retenciónrestore-db-instance-to-point-in-timeRecuperar datos borrados accidentalmente con precisión de segundos

Próximos pasos y recursos adicionales

Restaurar desde un snapshot de RDS es una operación segura precisamente porque no toca la instancia original. El riesgo está en la configuración post-restauración: security groups incorrectos, parameter groups por defecto y endpoints que las aplicaciones no conocen. Validar esos tres puntos antes de redirigir tráfico elimina la mayoría de los incidentes post-restauración.

Glosario

TérminoDefinición
DB SnapshotCopia del volumen de almacenamiento de una instancia RDS en un punto en el tiempo. Puede ser manual o automático.
EndpointDirección DNS asignada a una instancia RDS. Cada instancia tiene un endpoint único e independiente.
Parameter GroupConjunto de parámetros de configuración del motor de base de datos aplicados a una instancia RDS.
Point-in-Time Recovery (PITR)Mecanismo de restauración que permite recuperar una instancia a cualquier segundo dentro del período de retención de backups.
Security GroupFirewall a nivel de instancia que controla el tráfico de entrada y salida. No se hereda automáticamente durante una restauración desde snapshot.

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más