Restore RDS dari Snapshot: Instance Baru atau Overwrite Instance Lama?

Saat database produksi mengalami korupsi data atau kesalahan migrasi yang fatal, pertanyaan pertama yang muncul adalah: 'kalau aku restore dari snapshot, apakah instance yang sekarang akan tertimpa, atau AWS akan membuat instance baru dengan endpoint berbeda?' Jawaban atas pertanyaan ini menentukan strategi downtime, perubahan konfigurasi aplikasi, dan urutan langkah recovery yang harus dieksekusi dengan benar.

TL;DR — Restore RDS dari Snapshot

Aspek	Perilaku AWS RDS
Apakah instance lama tertimpa?	Tidak. Instance lama tetap berjalan, tidak dimodifikasi.
Hasil restore	Instance RDS baru dengan endpoint berbeda.
Endpoint aplikasi	Harus diperbarui secara manual untuk mengarah ke instance baru.
Parameter Group & Security Group	Tidak otomatis diwarisi — harus dikonfigurasi ulang.
Multi-AZ & Read Replica	Tidak direstorasi secara otomatis dari snapshot.
Data setelah snapshot	Tidak termasuk — hanya data pada titik waktu snapshot dibuat.

Cara Kerja Restore RDS dari Snapshot

RDS snapshot adalah salinan storage volume dari instance pada titik waktu tertentu. Ketika kamu menjalankan restore, AWS melakukan provisioning instance baru dari awal menggunakan data snapshot tersebut sebagai volume awal. Proses ini tidak menyentuh instance yang sudah ada — analoginya seperti mencetak foto dari negatif film: kamu mendapatkan cetakan baru, negatif aslinya tidak berubah.

Konsekuensi langsung dari mekanisme ini: instance hasil restore memiliki DNS endpoint yang sama sekali berbeda. Aplikasi yang masih terhubung ke instance lama tidak akan terputus, tetapi juga tidak otomatis beralih ke instance baru.

graph LR SNAP["DB Snapshot
Titik Waktu T"] RESTORE["Proses Restore
AWS Provisioning"] OLD["Instance Lama
Tetap Berjalan"] NEW["Instance Baru
Endpoint Berbeda"] APP["Aplikasi"] CUTOVER["Cutover Manual
Update Connection String"] SNAP --> RESTORE RESTORE --> NEW OLD -->|Tidak terpengaruh| OLD APP -->|Sebelum cutover| OLD NEW --> CUTOVER CUTOVER -->|Setelah cutover| APP

Snapshot Sumber — Titik waktu data yang akan dipulihkan. Bisa manual snapshot atau automated backup.
Proses Restore — AWS memprovisi instance RDS baru dengan storage yang diinisialisasi dari snapshot.
Instance Lama — Tetap berjalan tanpa perubahan apapun selama dan setelah proses restore.
Instance Baru — Endpoint berbeda, konfigurasi default. Parameter Group, Security Group, dan opsi lain harus dikonfigurasi ulang.
Cutover Aplikasi — Langkah manual yang harus dilakukan: update connection string aplikasi ke endpoint baru.

Langkah-Langkah Restore RDS dari Snapshot via AWS CLI

Sebelum menjalankan restore, identifikasi snapshot yang akan digunakan. Proses ini juga membutuhkan pemahaman tentang parameter apa saja yang harus ditentukan secara eksplisit karena tidak semua konfigurasi diwarisi dari instance asal.

Langkah 1: Identifikasi Snapshot yang Tersedia

Karena restore dimulai dari snapshot identifier yang spesifik, verifikasi dulu snapshot mana yang tersedia dan pada titik waktu apa snapshot itu dibuat — ini menentukan seberapa banyak data yang hilang setelah restore.

aws rds describe-db-snapshots \
  --db-instance-identifier nama-instance-lama \
  --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Status:Status,CreatedAt:SnapshotCreateTime,AllocatedStorage:AllocatedStorage}' \
  --output table \
  --region us-east-1

Langkah 2: Jalankan Restore ke Instance Baru

Parameter --db-instance-identifier di sini adalah nama untuk instance baru yang akan dibuat — bukan nama instance lama. Jika kamu menggunakan nama yang sama dengan instance yang sudah ada, perintah ini akan gagal karena identifier sudah terpakai.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier nama-instance-restored \
  --db-snapshot-identifier rds:nama-instance-lama-2024-01-15-08-00 \
  --db-instance-class db.t3.medium \
  --no-multi-az \
  --publicly-accessible \
  --region us-east-1

Beberapa parameter penting yang tidak diwarisi otomatis dari snapshot dan harus ditentukan secara eksplisit:

--db-instance-class — Tipe instance. Bisa berbeda dari instance asal.
--vpc-security-group-ids — Security Group tidak otomatis diwarisi.
--db-subnet-group-name — Jika instance perlu berada di subnet group tertentu.
--db-parameter-group-name — Default parameter group digunakan jika tidak ditentukan.

Langkah 3: Monitor Status Instance Baru

Proses restore bisa memakan waktu beberapa menit hingga lebih dari satu jam tergantung ukuran storage. Instance belum bisa digunakan sampai statusnya available.

aws rds describe-db-instances \
  --db-instance-identifier nama-instance-restored \
  --query 'DBInstances[0].{Status:DBInstanceStatus,Endpoint:Endpoint.Address,Port:Endpoint.Port}' \
  --output table \
  --region us-east-1

Langkah 4: Update Security Group pada Instance Baru

Instance hasil restore menggunakan default VPC Security Group. Jika aplikasi kamu memerlukan Security Group spesifik agar bisa terhubung, update sekarang sebelum melakukan cutover — jangan sampai kamu sudah mengarahkan traffic ke instance baru tapi koneksi diblokir di layer Security Group.

aws rds modify-db-instance \
  --db-instance-identifier nama-instance-restored \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --apply-immediately \
  --region us-east-1

Langkah 5: Ambil Endpoint Instance Baru untuk Cutover

Setelah status available, ambil endpoint yang akan digunakan untuk memperbarui konfigurasi aplikasi.

aws rds describe-db-instances \
  --db-instance-identifier nama-instance-restored \
  --query 'DBInstances[0].Endpoint' \
  --output json \
  --region us-east-1

graph TD A["1. Describe Snapshots
Pilih snapshot identifier"] --> B["2. Restore DB Instance
Instance baru dibuat"] B --> C{"Status Instance Baru?"} C -->|creating / modifying| C C -->|available| D["3. Modify Security Group
Assign SG yang tepat"] D --> E["4. Verifikasi Koneksi
Test ke endpoint baru"] E --> F["5. Cutover Aplikasi
Update connection string"] F --> G["6. Monitor Instance Lama
Cek DatabaseConnections = 0"] G --> H["7. Hapus Instance Lama
Setelah verifikasi selesai"]

Describe Snapshots — Verifikasi snapshot identifier dan waktu pembuatan sebelum restore.
Restore DB Instance — Provisioning instance baru. Instance lama tidak terpengaruh.
Status: Creating → Modifying → Available — Tunggu sampai status available sebelum melanjutkan.
Modify Security Group — Pastikan instance baru bisa diakses oleh aplikasi.
Verifikasi Koneksi — Test koneksi ke endpoint baru sebelum cutover penuh.
Update Aplikasi — Arahkan connection string ke endpoint baru.
Hapus Instance Lama (Opsional) — Setelah cutover berhasil dan data diverifikasi.

Konfigurasi yang Tidak Diwarisi Otomatis dari Snapshot

Ini adalah area yang paling sering menyebabkan masalah setelah restore. Banyak engineer mengasumsikan bahwa instance baru akan identik dengan instance asal, tapi kenyataannya tidak.

Konfigurasi	Diwarisi dari Snapshot?	Tindakan yang Diperlukan
Data di storage	Ya	Tidak ada
Engine version	Ya	Tidak ada (bisa di-upgrade saat restore)
DB Parameter Group	Tidak — default group digunakan	Assign parameter group yang sesuai lalu reboot
DB Option Group	Tidak — default group digunakan	Assign option group yang sesuai
VPC Security Groups	Tidak	Assign Security Group yang tepat
Multi-AZ	Tidak — single-AZ by default	Enable Multi-AZ jika diperlukan
Read Replicas	Tidak	Buat ulang Read Replica secara manual
Enhanced Monitoring	Tidak	Aktifkan kembali jika diperlukan
Performance Insights	Tidak	Aktifkan kembali jika diperlukan
Maintenance Window	Tidak	Set ulang sesuai kebutuhan operasional

Skenario Nyata: Salah Diagnosis yang Hampir Menyebabkan Data Loss Ganda

Berikut skenario yang cukup umum terjadi di production: engineer menjalankan restore dari snapshot, menunggu instance baru siap, lalu langsung menghapus instance lama karena mengira data sudah aman di instance baru. Masalahnya, instance lama ternyata masih menerima write dari beberapa service background job yang belum diupdate connection string-nya.

Gejalanya: setelah cutover, ada data transaksi yang 'hilang' — padahal data itu ditulis ke instance lama setelah snapshot dibuat, dan tidak pernah ada di instance baru. Snapshot hanya menangkap data pada titik waktu pembuatannya.

Pola yang benar:

Restore ke instance baru.
Verifikasi data di instance baru.
Hentikan semua write ke instance lama (maintenance mode aplikasi).
Identifikasi gap data antara waktu snapshot dan waktu maintenance.
Jika menggunakan automated backup dengan Point-in-Time Recovery, pertimbangkan restore ke waktu yang lebih dekat dengan maintenance window.
Baru lakukan cutover dan hapus instance lama setelah semua service diverifikasi terhubung ke instance baru.

Snapshot adalah foto, bukan video. Semua yang terjadi setelah tombol shutter ditekan tidak terekam. Jika ada write yang masuk ke instance lama setelah snapshot dibuat, data itu tidak akan ada di instance hasil restore.

Strategi Cutover dengan Minimal Downtime

Karena endpoint berubah, cutover adalah langkah yang paling kritis. Ada beberapa pendekatan tergantung arsitektur aplikasi:

Opsi A: Update Connection String Langsung

Pendekatan paling sederhana. Cocok untuk aplikasi dengan connection pooler atau yang bisa di-restart dengan cepat. Downtime terjadi selama restart aplikasi.

Opsi B: Gunakan CNAME atau Route 53 CNAME Record

Jika aplikasi menggunakan custom DNS alias (bukan endpoint RDS langsung), kamu bisa update CNAME record untuk mengarahkan ke endpoint instance baru tanpa mengubah konfigurasi aplikasi. Perhatikan TTL DNS — set TTL rendah sebelum cutover untuk mempercepat propagasi.

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "db.internal.example.com",
        "Type": "CNAME",
        "TTL": 60,
        "ResourceRecords": [{
          "Value": "nama-instance-restored.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com"
        }]
      }
    }]
  }' \
  --region us-east-1

Opsi C: RDS Rename (Rename Instance Lama, Rename Instance Baru)

Teknik ini memanfaatkan fakta bahwa endpoint RDS mengikuti nama DB instance identifier. Dengan mengganti nama instance lama ke nama lain, lalu mengganti nama instance baru ke nama instance lama, endpoint efektif 'berpindah' ke instance baru. Namun perlu diperhatikan: proses rename menyebabkan brief downtime dan endpoint akan berubah sementara selama proses rename berlangsung.

# Langkah 1: Rename instance lama
aws rds modify-db-instance \
  --db-instance-identifier nama-instance-lama \
  --new-db-instance-identifier nama-instance-lama-deprecated \
  --apply-immediately \
  --region us-east-1

# Tunggu sampai rename selesai, lalu:
# Langkah 2: Rename instance baru ke nama instance lama
aws rds modify-db-instance \
  --db-instance-identifier nama-instance-restored \
  --new-db-instance-identifier nama-instance-lama \
  --apply-immediately \
  --region us-east-1

IAM Policy Minimal untuk Operasi Restore RDS

Jika restore dijalankan oleh automation pipeline atau IAM role khusus (bukan admin), berikut policy minimal yang diperlukan:

🔽 Klik untuk melihat IAM Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRDSSnapshotDescribe",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSnapshots",
        "rds:DescribeDBInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowRDSRestore",
      "Effect": "Allow",
      "Action": [
        "rds:RestoreDBInstanceFromDBSnapshot",
        "rds:ModifyDBInstance",
        "rds:AddTagsToResource"
      ],
      "Resource": [
        "arn:aws:rds:us-east-1:123456789012:snapshot:*",
        "arn:aws:rds:us-east-1:123456789012:db:*"
      ]
    }
  ]
}

Perlu dicatat: DescribeDBSnapshots dan DescribeDBInstances memerlukan "Resource": "*" karena aksi Read/List/Describe pada RDS umumnya tidak mendukung pembatasan resource-level. Selalu verifikasi di AWS Service Authorization Reference sebelum menerapkan pembatasan ARN pada aksi Describe.

Restore RDS dari Snapshot: Wrap-Up dan Langkah Selanjutnya

Restore RDS dari snapshot selalu menghasilkan instance baru dengan endpoint berbeda — instance lama tidak pernah tertimpa. Ini adalah perilaku yang by design dan memberikan keamanan bahwa operasi restore tidak merusak data yang sedang berjalan. Konsekuensinya, cutover ke instance baru adalah tanggung jawab operator, bukan AWS.

Checklist sebelum menghapus instance lama:

Semua service dan aplikasi sudah terhubung ke endpoint baru.
Tidak ada connection aktif ke instance lama (verifikasi via CloudWatch metric DatabaseConnections pada instance lama).
Data di instance baru sudah diverifikasi.
Parameter Group dan Security Group sudah dikonfigurasi dengan benar di instance baru.
Multi-AZ dan monitoring sudah diaktifkan kembali jika diperlukan.

Untuk skenario recovery yang membutuhkan data lebih dekat ke titik kegagalan, pertimbangkan Point-in-Time Recovery (PITR) yang menggunakan automated backup dan transaction log untuk restore ke waktu spesifik, bukan hanya ke titik snapshot manual.

Referensi resmi: AWS Documentation — Restoring from a DB Snapshot

Glosarium

Istilah	Definisi
DB Snapshot	Salinan storage volume instance RDS pada titik waktu tertentu. Bisa dibuat manual atau otomatis oleh RDS.
DB Instance Identifier	Nama unik yang mengidentifikasi instance RDS dalam satu region dan akun AWS. Endpoint DNS instance mengikuti identifier ini.
Point-in-Time Recovery (PITR)	Kemampuan restore database ke titik waktu spesifik menggunakan automated backup dan transaction log, bukan hanya snapshot manual.
Parameter Group	Kumpulan parameter konfigurasi engine database (seperti `max_connections`) yang diterapkan ke instance RDS.
Cutover	Proses memindahkan traffic atau koneksi aplikasi dari instance lama ke instance baru setelah restore selesai.

Cari Blog Ini

SW BBANG I