Saat File State Terraform Hilang: Strategi Pemulihan yang Benar-Benar Berhasil

Anda menjalankan terraform plan dan alih-alih output biasa, Anda malah mendapat error. File state hilang. Atau rusak. Atau terkunci oleh proses yang mati berjam-jam lalu. Insting pertama Anda mungkin panik, tapi inilah yang perlu Anda ketahui: infrastruktur Anda kemungkinan besar masih berjalan dengan baik. Server, database, dan load balancer masih ada di sana. Yang rusak adalah catatan tentang apa yang Terraform pikir ada.

Situasi ini jarang terjadi, tapi ketika terjadi, tim biasanya langsung macet. Anda tidak bisa melakukan perubahan melalui kode sampai state dipulihkan. Kabar baiknya, pemulihan itu mungkin dilakukan, dan memiliki rencana adalah perbedaan antara perbaikan cepat dan krisis berjam-jam.

Mengapa File State Bisa Rusak

File state gagal dalam beberapa cara yang bisa diprediksi. Yang paling umum adalah penghapusan tidak sengaja. Seseorang membersihkan bucket S3 dan tidak menyadari bahwa file state ada di dalamnya. Skenario lain adalah kerusakan akibat operasi tulis yang terputus di tengah proses. Masalah jaringan, pemadaman listrik, atau penghentian proses secara tiba-tiba bisa meninggalkan file state yang setengah tertulis dan tidak bisa dibaca.

Lalu ada masalah kunci (lock). Terraform mengunci file state untuk mencegah banyak proses menulis secara bersamaan. Jika sebuah proses mati tanpa melepaskan kuncinya, kunci itu akan tetap ada. Setiap plan atau apply berikutnya gagal karena Terraform mengira ada orang lain yang masih bekerja.

Tingkat keparahannya bervariasi, tapi inti masalahnya sama: Anda kehilangan koneksi antara kode dan infrastruktur yang sedang berjalan.

Pertama: Jangan Bangun Ulang Semuanya

Aturan terpenting adalah menahan keinginan untuk membongkar semuanya dan memulai dari awal. Infrastruktur Anda masih beroperasi. Penyedia cloud masih tahu tentang setiap resource yang Anda buat. Yang hilang adalah catatan lokal Terraform tentang resource tersebut.

Jika Anda menjalankan terraform destroy dan membuat ulang semuanya, Anda akan menyebabkan downtime yang tidak perlu dan berisiko kehilangan data. Database terhapus. Persistent volume terhapus. Rekaman DNS berubah. Jalur pemulihan adalah tentang mengembalikan state, bukan membangun ulang infrastruktur.

Pemulihan Berdasarkan Tingkat Keparahan

State Terkunci: Perbaikan Sederhana

Berikut adalah diagram keputusan untuk membantu Anda mengidentifikasi jalur pemulihan berdasarkan jenis masalah file state:

flowchart TD A[Masalah file state] --> B{Terkunci?} A --> C{Terhapus dengan backup?} A --> D{Rusak atau hilang tanpa backup?} A --> E{Kehilangan total?} B --> F[Force-unlock jika tidak ada proses lain yang aktif] C --> G[Pulihkan dari backup] D --> H[Import resource satu per satu] E --> I[Bangun ulang dari awal] F --> J[Verifikasi dengan terraform plan] G --> J H --> J I --> J

Jika file state ada tapi terkunci, ini adalah skenario termudah. Cari tahu proses mana yang memegang kunci. Jika proses itu masih berjalan, biarkan selesai. Jika mati secara tidak terduga, gunakan perintah force-unlock:

terraform force-unlock <lock_id>

Tapi hati-hati. Force-unlock hanya aman jika Anda benar-benar yakin tidak ada proses lain yang menulis ke state. Jika dua proses menulis secara bersamaan, Anda akan berakhir dengan state yang rusak dan lebih sulit diperbaiki daripada sekadar kunci.

State Terhapus dengan Backup: Skenario Ideal

Jika file state terhapus tapi Anda punya backup, Anda dalam posisi bagus. Pemulihannya mudah: kembalikan backup ke lokasi aslinya.

Inilah mengapa versioning pada backend state Anda sangat penting. Jika Anda menggunakan S3, aktifkan bucket versioning. Ketika file dihapus, Anda bisa mengembalikan versi sebelumnya langsung dari konsol S3 atau CLI. Tidak perlu manajemen file backup terpisah.

Jika Anda tidak memiliki versioning, backup manual ke lokasi terpisah juga berfungsi. Kuncinya adalah memiliki salinan yang disimpan di tempat selain lokasi state utama.

State Rusak atau Hilang Tanpa Backup: Jalur Sulit

Di sinilah segalanya menjadi menyakitkan. Anda tidak punya backup, dan file state tidak bisa dibaca atau hilang. Tapi infrastruktur Anda masih berjalan. Solusinya adalah membangun ulang state dengan mengimpor setiap resource satu per satu.

Terraform memiliki perintah import yang membaca infrastruktur yang ada dan menambahkannya ke file state Anda. Untuk setiap resource yang didefinisikan dalam kode Anda, jalankan:

Sebagai contoh, untuk mengimpor instance EC2 yang didefinisikan dalam konfigurasi Anda sebagai aws_instance.web, jalankan:

terraform import aws_instance.web i-1234567890abcdef0

Alamat resource (aws_instance.web) harus cocok persis dengan apa yang ada di file .tf Anda. Jika resource berada dalam modul, gunakan jalur modul, seperti module.my_module.aws_instance.web. Setelah mengimpor, jalankan terraform plan untuk memastikan state cocok dengan konfigurasi Anda.

Format ID resource tergantung pada penyedia. Untuk AWS, bisa berupa ID instance atau ARN. Untuk GCP, biasanya berupa nama resource atau URL lengkap.

Proses ini melelahkan untuk infrastruktur besar. Jika Anda memiliki puluhan instance EC2, database RDS, load balancer, dan security group, Anda akan menjalankan perintah import untuk sementara waktu. Tapi ini satu-satunya cara untuk menyelaraskan kode Anda dengan kenyataan tanpa menghancurkan apa pun.

Kehilangan Total Tanpa Jalur Pemulihan: Opsi Nuklir

Terkadang state hilang, backup tidak ada, dan infrastruktur terlalu kompleks atau tidak terdokumentasi dengan baik untuk diimpor satu per satu. Dalam kasus ini, Anda punya satu opsi: bangun ulang dari awal.

Ini berarti menghancurkan semua resource yang ada dan membuatnya kembali dari kode Terraform Anda. Ini bukan keputusan yang bisa dianggap enteng, terutama untuk lingkungan produksi. Tapi jika pemulihan melalui import tidak memungkinkan, membangun ulang seringkali lebih cepat daripada mencoba merekonstruksi state secara manual untuk ratusan resource.

Sebelum mengambil jalur ini, pastikan Anda memiliki:

  • Kode Terraform lengkap yang cocok dengan apa yang berjalan
  • Backup data untuk database dan penyimpanan persisten
  • Window pemeliharaan dengan persetujuan pemangku kepentingan
  • Rencana rollback jika pembangunan ulang gagal

Checklist Praktis untuk Pemulihan State

Ketika state rusak, kerjakan checklist ini secara berurutan:

  1. Konfirmasi kerusakan - Apakah state terkunci, terhapus, atau rusak? Periksa pesan error dengan cermat.
  2. Periksa backup - Lihat versioning di backend Anda. Periksa lokasi backup manual.
  3. Pulihkan jika memungkinkan - Jika Anda punya backup, pulihkan dan verifikasi dengan terraform plan.
  4. Force-unlock jika terkunci - Hanya jika Anda yakin tidak ada proses lain yang aktif.
  5. Import resource - Jika tidak ada backup, mulai impor resource satu per satu.
  6. Pertimbangkan pembangunan ulang - Hanya jika import tidak praktis dan Anda memiliki cakupan kode yang lengkap.

Pencegahan Lebih Baik Daripada Pemulihan

Waktu terbaik untuk bersiap menghadapi kegagalan state adalah sebelum itu terjadi. Tiga praktik membuat pemulihan jauh lebih mudah:

Pertama, aktifkan versioning pada backend state Anda. Baik itu S3, Azure Storage, atau GCS, versioning memberi Anda jaring pengaman untuk penghapusan atau kerusakan yang tidak disengaja.

Kedua, otomatiskan backup. Bahkan dengan versioning, simpan salinan file state Anda di lokasi terpisah. Cukup cron job sederhana atau langkah pipeline yang menyalin file state ke bucket atau akun penyimpanan lain, butuh waktu lima menit untuk menyiapkannya.

Ketiga, dokumentasikan infrastruktur Anda. Ketika Anda perlu mengimpor resource, Anda perlu tahu apa yang ada dan ID apa yang mereka miliki. Inventaris resource terkini, baik di README atau yang dihasilkan dari API penyedia cloud Anda, menghemat waktu berjam-jam selama pemulihan.

Apa yang Selanjutnya

Setelah state dipulihkan dan Anda bisa menjalankan terraform plan lagi, pekerjaan belum selesai. Insiden tersebut harus memicu tinjauan tentang bagaimana state Anda dikelola. Apakah ada celah dalam strategi backup Anda? Haruskah Anda menambahkan kontrol akses lebih untuk mencegah penghapusan tidak sengaja? Apakah Anda perlu runbook untuk pemulihan state?

Pemulihan state bukan tentang menghindari kesalahan. Ini tentang memiliki rencana ketika kesalahan terjadi. Tim yang bersiap menghadapi kegagalan state pulih dalam hitungan menit. Tim yang tidak bersiap menghabiskan waktu berjam-jam panik, lalu berhari-hari merekonstruksi secara manual apa yang hilang.

Infrastruktur yang Anda bangun masih ada di sana. State hanyalah peta. Ketika peta hilang, Anda tidak membakar kota. Anda menggambar peta baru.