Bagi insinyur DevOps dan administrator sistem, snapshot mesin virtual (VM) adalah alat yang mendasar. Snapshot menyediakan cara yang cepat dan mudah untuk menangkap status server sebelum melakukan patch yang berisiko, perubahan konfigurasi besar, atau penerapan aplikasi. Jika terjadi kesalahan, pemulihan (rollback) hanya membutuhkan waktu beberapa detik.
Namun, ketika metodologi yang sama diterapkan pada basis data transaksional—seperti PostgreSQL, MySQL, Oracle, atau Microsoft SQL Server—snapshot VM berubah dari jaring pengaman menjadi bom waktu yang siap meledak.
Mengandalkan snapshot hypervisor standar untuk cadangan basis data adalah salah satu penyebab paling umum dari kerusakan data (data corruption), halaman yang rusak (torn pages), dan gangguan produksi yang tidak dapat dipulihkan. Dalam artikel ini, kita akan mengeksplorasi benturan arsitektur antara hypervisor dan mesin basis data, mekanisme kerusakan data selama snapshot, serta praktik terbaik rekayasa yang diperlukan untuk mencadangkan basis data tervirtualisasi dengan aman.
Benturan Arsitektur: Hypervisor vs. Mesin Basis Data
Untuk memahami mengapa snapshot VM membahayakan basis data, kita harus terlebih dahulu memeriksa bagaimana kedua sistem mengelola status dan operasi I/O.
Bagaimana Hypervisor Menjalankan Snapshot
Ketika hypervisor (seperti VMware ESXi, Microsoft Hyper-V, atau KVM) mengambil snapshot, ia tidak menyalin disk. Sebaliknya, ia membekukan file disk virtual saat ini (misalnya, .vmdk atau .vhdx) ke dalam status baca-saja (read-only) dan membuat disk delta baru (differencing disk). Semua penulisan berikutnya diarahkan ke disk delta ini.
Ketika snapshot dihapus, hypervisor harus melakukan commit (konsolidasi) data dari disk delta kembali ke disk dasar. Snapshot standar sama sekali tidak mengetahui aplikasi yang berjalan di dalam sistem operasi tamu. Mereka menangkap status disk tepat seperti yang ada pada mikrodetik tersebut.
Bagaimana Basis Data Transaksional Mengelola Status
Basis data transaksional dirancang berdasarkan properti ACID (Atomicity, Consistency, Isolation, Durability). Untuk mencapai kinerja tinggi sambil tetap menjaga kepatuhan ACID, basis data tidak menulis setiap transaksi langsung ke file data utama di disk secara instan. Sebaliknya, mereka menggunakan arsitektur multi-tingkat yang kompleks:
- Buffer Pool / Shared Buffers: Data dibaca ke dalam dan dimodifikasi di dalam memori sistem.
- Write-Ahead Log (WAL) / Redo Logs: Perubahan ditulis secara berurutan ke file log yang sangat dioptimalkan di disk untuk memastikan daya tahan (durability).
- Checkpoints / Lazy Writers: Secara berkala, basis data mengosongkan halaman yang dimodifikasi (dirty pages) dari memori ke file data aktual di disk.
Karena arsitektur ini, file data fisik di disk hampir selalu tidak sinkron dengan status aktual basis data. Status sebenarnya dari basis data hanya ada sebagai kombinasi dari file data di disk, log WAL/Redo, dan data yang saat ini berada di memori.
Zona Bahaya: Apa yang Terjadi Selama Snapshot VM
Saat Anda mengambil snapshot VM standar dari server basis data, Anda menangkap status yang konsisten saat crash (crash-consistent).
Konsistensi Crash vs. Konsistensi Aplikasi
Snapshot yang konsisten saat crash setara dengan mencabut kabel daya dari server fisik. Status disk tertangkap, tetapi apa pun yang ada di memori hilang, dan apa pun yang sedang dalam proses menuju pengontrol penyimpanan terputus secara tiba-tiba.
Meskipun basis data modern dirancang untuk pulih dari kehilangan daya yang tidak terduga dengan memutar ulang Write-Ahead Log, mengandalkan pemulihan crash sebagai strategi cadangan utama Anda sangat berbahaya. Jika basis data Anda mencakup beberapa disk virtual (misalnya, file data di Drive D: dan WAL di Drive E:), hypervisor mungkin tidak melakukan snapshot pada kedua disk pada mikrodetik yang sama persis. Jika snapshot disk WAL diambil bahkan sepersekian detik setelah snapshot disk data, basis data tidak dapat merekonsiliasi nomor urut saat pemulihan, yang mengakibatkan kerusakan fatal.
Efek “VM Stun” pada Sistem Transaksi Tinggi
Proses pembuatan snapshot—dan yang lebih penting, proses konsolidasi snapshot—menyebabkan fenomena yang dikenal sebagai “VM Stun.”
Untuk mengalihkan I/O dengan aman dari disk dasar ke disk delta, hypervisor harus menjeda (stun) mesin virtual secara singkat. Untuk server web dengan beban ringan, stun ini mungkin berlangsung 10-50 milidetik dan tidak disadari. Namun, untuk basis data dengan throughput tinggi dan I/O masif, mengonsolidasikan disk delta yang besar dapat membuat VM terhenti (stun) selama beberapa detik.
Selama VM stun:
* Koneksi jaringan terputus, menyebabkan timeout aplikasi.
* Klaster ketersediaan tinggi (seperti SQL Server Always On, PostgreSQL Patroni, atau MySQL Galera) melewatkan pemeriksaan detak jantung (heartbeat).
* Klaster mungkin menganggap node yang ter-stun sudah mati, memicu failover yang tidak perlu dan mengganggu (skenario split-brain).
Halaman yang Rusak (Torn Pages) dan Ketidakselarasan I/O
Mesin basis data biasanya menulis data dalam ukuran halaman tertentu (misalnya, 8KB untuk PostgreSQL dan SQL Server, 16KB untuk InnoDB). Namun, sistem operasi dan array penyimpanan yang mendasarinya memproses I/O dalam blok yang lebih kecil (misalnya, 4KB atau 512 byte).
Jika hypervisor mengambil snapshot tepat saat basis data sedang menulis halaman 8KB, snapshot mungkin menangkap 4KB pertama dari data baru dan 4KB terakhir dari data lama. Ini menciptakan halaman yang rusak (torn page). Saat Anda mencoba memulihkan snapshot, basis data akan membaca halaman tersebut, gagal dalam validasi checksum, dan menandai basis data sebagai rusak.
Konsekuensi Dunia Nyata untuk Mesin Basis Data Spesifik
Mesin basis data yang berbeda bereaksi terhadap snapshot yang konsisten saat crash dengan berbagai cara, tetapi tidak ada yang menanganinya dengan baik di lingkungan produksi.
- PostgreSQL: PostgreSQL sangat bergantung pada direktori
pg_wal. Jika snapshot menangkap direktori data ($PGDATA) dan WAL secara tidak sinkron, PostgreSQL akan gagal dimulai, memunculkan kesalahanPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB menggunakan doublewrite buffer untuk mencegah halaman yang rusak, yang menawarkan perlindungan terhadap status konsisten saat crash. Namun, jika file
ibdata1danib_logfileditangkap secara tidak sinkron, mesin InnoDB akan crash saat pemulihan. - Microsoft SQL Server: SQL Server sangat sensitif terhadap pembekuan I/O. Tanpa integrasi VSS (Volume Shadow Copy Service) yang tepat, memulihkan SQL Server dari snapshot VM standar sering kali mengakibatkan basis data dalam status suspect dan rantai log yang rusak, menghancurkan kemampuan Point-in-Time Recovery (PITR) Anda.
Praktik Terbaik untuk Mencadangkan Basis Data Tervirtualisasi dengan Aman
Untuk melindungi basis data transaksional, Anda harus beralih dari cadangan yang konsisten saat crash ke cadangan yang konsisten secara aplikasi (application-consistent). Ini mengharuskan mekanisme cadangan untuk berkomunikasi dengan mesin basis data, memaksanya untuk mengosongkan memori ke disk dan menjeda operasi I/O sejenak saat snapshot diambil.
1. Manfaatkan Quiescing yang Sadar Aplikasi (VSS dan fsfreeze)
Untuk Windows (SQL Server):
Selalu pastikan solusi cadangan Anda menggunakan Microsoft Volume Shadow Copy Service (VSS). Ketika cadangan yang sadar VSS dipicu, SQL Server VSS Writer membekukan I/O basis data, mengosongkan transaksi yang tertunda ke disk, dan memastikan snapshot benar-benar konsisten secara aplikasi.
Untuk Linux (PostgreSQL / MySQL):
Linux tidak memiliki padanan asli untuk VSS. Untuk mencapai konsistensi aplikasi, Anda harus menggunakan skrip pre-freeze dan post-thaw yang dikombinasikan dengan alat tamu hypervisor (misalnya, VMware Tools).
Berikut adalah contoh pre-freeze-script VMware untuk PostgreSQL 15+ yang menyiapkan basis data dengan aman untuk snapshot:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Pastikan skrip ini dapat dieksekusi (chmod +x)
# 1. Perintahkan PostgreSQL untuk bersiap melakukan cadangan
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Kosongkan buffer sistem file ke disk
sync
# 3. Bekukan sistem file (asumsi data ada di /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
Dan post-thaw-script yang sesuai untuk melanjutkan operasi:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Cairkan sistem file
fsfreeze -u /var/lib/pgsql
# 2. Beritahu PostgreSQL bahwa cadangan selesai
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Gunakan Utilitas Cadangan Basis Data Asli
Meskipun snapshot yang konsisten secara aplikasi lebih baik daripada snapshot standar, mereka masih membawa risiko VM stun. Pendekatan teraman untuk cadangan basis data adalah menggunakan utilitas cadangan streaming asli yang beroperasi secara independen dari hypervisor.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Alat-alat ini mengambil cadangan panas (hot backup) tanpa memblokir dengan menyalin file data dan secara bersamaan melacak perubahan di redo log.
mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass
SQL Server (T-SQL):
BACKUP DATABASE [ProductionDB]
TO DISK = N'Z:BackupsProductionDB.bak'
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO
3. Terapkan Point-in-Time Recovery (PITR) melalui Pengarsipan Log
Snapshot harian atau cadangan penuh hanya melindungi Anda hingga menit saat cadangan tersebut diambil. Jika basis data Anda crash pada pukul 16:00 dan snapshot terakhir Anda pada pukul 02:00, Anda kehilangan 14 jam data transaksi.
Untuk mencapai ketahanan perusahaan yang sejati, Anda harus menggabungkan cadangan penuh yang konsisten secara aplikasi dengan pengarsipan log berkelanjutan (mencadangkan WAL, Redo Logs, atau Transaction Logs setiap beberapa menit). Ini memungkinkan DBA untuk memulihkan basis data ke menit tertentu atau bahkan ID transaksi tertentu sebelum bencana terjadi.
Strategi Cadangan Perusahaan dengan CloudSave
Mengelola skrip pre-freeze kustom, cron job untuk dump asli, dan pengiriman log di puluhan server basis data adalah mimpi buruk operasional bagi tim DevOps. Di sinilah platform tingkat perusahaan seperti CloudSave menjadi sangat penting.
CloudSave menjembatani kesenjangan antara virtualisasi dan arsitektur basis data. Alih-alih mengandalkan snapshot hypervisor yang buta, CloudSave menggunakan agen sadar aplikasi yang terintegrasi secara asli dengan SQL Server, PostgreSQL, MySQL, dan Oracle.
Ketika CloudSave memulai cadangan:
1. Ia berkomunikasi langsung dengan mesin basis data melalui API asli (seperti VSS untuk Windows atau streaming WAL asli untuk Linux).
2. Ia mengatur pengosongan buffer memori ke disk tanpa menyebabkan VM stun yang mengganggu.
3. Ia menangkap file data dengan aman dan secara otomatis mengelola pemotongan log transaksi.
4. Ia mencadangkan log transaksi secara berkelanjutan, memungkinkan Point-in-Time Recovery (PITR) yang terperinci dengan beberapa klik.
Dengan mengalihkan kompleksitas konsistensi aplikasi ke CloudSave, DBA dan sysadmin dapat menjamin integritas data tanpa mengorbankan kinerja atau ketersediaan klaster produksi mereka.
Kesimpulan
Snapshot mesin virtual adalah alat yang luar biasa untuk manajemen infrastruktur, tetapi pada dasarnya tidak kompatibel dengan persyaratan ACID dari basis data transaksional. Mengandalkan snapshot hypervisor yang konsisten saat crash mengekspos organisasi Anda pada halaman yang rusak, rantai replikasi yang terputus, dan kehilangan data yang katastrofik.
Untuk melindungi data misi-kritis Anda, Anda harus menerapkan quiescing yang sadar aplikasi, menggunakan metodologi cadangan basis data asli, dan memelihara arsip log transaksi yang berkelanjutan. Dengan mengadopsi solusi cadangan perusahaan yang dibuat khusus, Anda dapat memastikan bahwa basis data Anda tetap tersedia, dapat dipulihkan sepenuhnya, dan benar-benar aman.
