Apa itu storage snapshot?

Storage snapshot adalah sekumpulan penanda referensi untuk data pada titik waktu tertentu (point in time/PIT). Lebih spesifik lagi, ini adalah kumpulan data aplikasi yang disimpan serta sebuah log lengkap yang mencatat perubahan data tersebut seiring waktu. Jika digabungkan, storage snapshot memungkinkan perusahaan untuk melindungi data aplikasi secara real-time. Ini membantu meminimalkan recovery point objective (RPO) sambil memberikan opsi bagi pengelola workload untuk memulihkan atau mengembalikan data aplikasi ke keadaan sebelumnya pada PIT yang tersedia.

Storage snapshot, atau biasa disebut snapshot saja, adalah salah satu bentuk backup data yang fleksibel dan responsif untuk perlindungan data aplikasi enterprise. Seiring perubahan data aplikasi, storage snapshot akan menangkap dan mencatat perubahan tersebut secara berkala, menghasilkan catatan perubahan dan data baru. Snapshot bisa diambil dengan frekuensi hampir kapan saja, mulai dari setiap 24 jam hingga setiap beberapa menit, tergantung kebutuhan replikasi dan pemulihan bisnis serta aplikasinya.

Ketika ada masalah pada data aplikasi, pemilik aplikasi dapat memulihkan snapshot terbaru untuk mengembalikan kondisi aplikasi ke keadaan terakhir. Ini sangat efektif untuk mengurangi RPO, downtime, dan kehilangan data. Selain itu, pemilik aplikasi bisa memilih untuk mengembalikan restore point sebelumnya, misalnya untuk mengatasi masalah akibat korupsi data atau aktivitas berbahaya, dengan mengembalikan aplikasi ke keadaan sebelum masalah tersebut terjadi.

Bagaimana Cara Kerja Storage Snapshot?

Storage snapshot biasanya berfokus pada konsep perubahan data, yang juga dikenal dengan istilah delta atau differencing. Snapshot sering menggunakan differencing disk, yaitu jenis khusus virtual hard disk yang terhubung ke parent disk aslinya.

Setiap storage snapshot dimulai dengan backup penuh terhadap data aplikasi saat itu. Ini seperti backup penuh biasa. Setelah full backup awal dibuat, perbedaan snapshot dibandingkan backup biasa adalah bagaimana snapshot menangani perubahan data seiring waktu. Setelah backup awal, sistem snapshot akan menangkap dan mencatat hanya perubahan (delta) yang terjadi pada data aplikasi. Karena hanya perubahan yang dicatat, snapshot selanjutnya menjadi sangat kecil dan cepat diambil, cocok untuk kebutuhan perlindungan data dengan RPO yang kecil.

Saat administrator membuat snapshot, sistem akan membuat differencing disk yang terikat ke virtual hard disk asli. Semua operasi tulis (write operations) akan diarahkan ke differencing disk ini, sehingga hard disk asli tetap tidak berubah. File system sendiri tidak menyadari keberadaan differencing disk ini, dan tetap beroperasi seperti biasa seolah-olah di mesin fisik.

Snapshot membentuk hubungan parent-child dan membangun struktur pohon. Setiap snapshot baru menciptakan cabang baru di pohon tersebut. Akibatnya, snapshot secara bertahap membangun indeks kompleks dari perubahan data aplikasi pada setiap PIT yang di-capture.

Snapshot umumnya dibuat untuk perlindungan data, tetapi juga bisa digunakan untuk pengujian aplikasi (testing) dan data mining. Snapshot juga sangat berguna untuk disaster recovery, misalnya ketika terjadi kehilangan data akibat kesalahan manusia atau insiden lain. Selain itu, snapshot memungkinkan sistem dikembalikan ke kondisi sebelumnya, misalnya jika ada patch yang bermasalah.

Storage snapshot memiliki siklus hidup yang terbatas. Setiap snapshot memiliki nilai kegunaan yang akan menurun seiring waktu. Misalnya, jika snapshot diambil setiap 30 menit, kemungkinan snapshot dari 24 atau 48 jam yang lalu sudah tidak lagi relevan. Oleh karena itu, snapshot lama biasanya diintegrasikan kembali menjadi satu backup penuh, lalu proses snapshot dimulai ulang dari awal. Ini bertujuan untuk menghemat ruang penyimpanan dan mencegah kerusakan differencing disk yang bisa menghambat proses restore di PIT yang dibutuhkan.

Jenis-jenis Teknologi Snapshot

Tidak semua snapshot berbasis pada differencing disk. Ada berbagai jenis snapshot penyimpanan yang menggunakan mekanisme atau pendekatan yang berbeda.

Snapshot Copy-on-Write

Snapshot copy-on-write menyimpan metadata tentang lokasi data asli tanpa menyalin data tersebut saat snapshot dibuat. Snapshot ini dapat dibuat hampir seketika, dengan dampak kinerja yang sangat kecil pada sistem yang mengambil snapshot. Ini memungkinkan pemulihan sistem dengan cepat jika terjadi kerusakan program atau serangan berbahaya.

Data dalam snapshot copy-on-write konsisten dengan kondisi tepat saat snapshot diambil, sesuai dengan namanya. Namun, jika ingin melakukan arsip penuh atau pemulihan semua data di jaringan atau media penyimpanan, semua snapshot sebelumnya harus tetap tersedia. Proses copy-on-write membutuhkan satu kali baca dan dua kali tulis; data harus dibaca dan ditulis ke lokasi berbeda sebelum ditimpa.

Snapshot Clone atau Split-Mirror

Snapshot clone atau split-mirror mereferensikan seluruh data pada sekumpulan drive yang di-mirror. Setiap kali utilitas dijalankan, ia membuat snapshot seluruh volume, bukan hanya data baru atau yang diperbarui. Ini memungkinkan akses data secara offline dan mempermudah proses pemulihan, duplikasi, serta arsip semua data dalam drive. Namun, proses ini lebih lambat dan setiap snapshot membutuhkan ruang penyimpanan sebesar ukuran data asli.

Copy-on-Write dengan Background Copy

Copy-on-write dengan background copy mengambil data snapshot dari operasi copy-on-write dan menggunakan proses latar belakang untuk menyalin data ke lokasi penyimpanan snapshot. Proses ini membuat salinan cermin dari data asli dan dianggap sebagai hibrida antara metode copy-on-write dan cloning.

Snapshot Redirect-on-Write

Snapshot redirect-on-write mirip dengan copy-on-write, tetapi operasi tulis dialihkan ke penyimpanan yang sudah disediakan khusus untuk snapshot, sehingga menghilangkan kebutuhan dua kali tulis. Snapshot jenis ini hanya mencatat data yang berubah, bukan menyalin seluruh data asli. Ketika snapshot dihapus, data harus disalin kembali dan disinkronkan ke volume aslinya. Pembuatan snapshot tambahan bisa membuat akses ke data asli menjadi lebih kompleks.

Snapshot Incremental

Snapshot incremental membuat cap waktu (timestamp) yang memungkinkan pengguna kembali ke titik waktu (PIT) tertentu. Snapshot incremental bisa dibuat lebih cepat dan lebih sering dibandingkan jenis snapshot lain. Karena penggunaan ruang penyimpanannya minimal, snapshot ini bisa disimpan lebih lama. Setiap kali snapshot incremental diambil, snapshot aslinya diperbarui.

Snapshot VMware

Snapshot VMware menyalin file disk virtual machine dan mengembalikan VM ke PIT tertentu jika terjadi kegagalan. Teknologi snapshot ini digunakan di lingkungan virtualisasi VMware, dan biasanya dihapus dalam waktu satu jam. Administrator bisa mengambil beberapa snapshot dari satu VM, menciptakan beberapa titik pemulihan (restore point). Saat snapshot diambil, semua data yang bisa ditulis menjadi read-only.

Cara Membuat Snapshot

Langkah-langkah untuk membuat storage snapshot dapat bervariasi tergantung pada platform dan jenis snapshot yang digunakan. Namun, umumnya ada beberapa fase umum yang akan dihadapi pengguna snapshot, termasuk persiapan dan eksekusi. Berikut ini pendekatan manual dalam membuat snapshot, yang biasanya dilakukan sebelum menerapkan patch atau upgrade perangkat lunak:

Buka Antarmuka Pengguna (UI) Snapshot. Sebagian besar platform snapshot menyediakan UI seperti konsol, yang memungkinkan pengelola workload untuk mengelola dan memantau lingkungan snapshot. UI ini juga menyediakan kemampuan penjadwalan dan otomatisasi snapshot.
Konfigurasi Snapshot. Snapshot biasanya memungkinkan tingkat persiapan atau konfigurasi tertentu. Di sini, pengguna menentukan bagaimana dan di mana snapshot akan disimpan serta bagaimana menangani dependensi file pendukung. Pengguna juga bisa menambahkan metadata seperti komentar atau judul, serta melakukan jeda (quiesce) aplikasi jika diperlukan agar datastore aplikasi tetap konsisten saat snapshot dibuat. Tidak semua aplikasi mendukung proses quiesce.
Tinjau Detail Snapshot. Platform biasanya menampilkan detail snapshot yang akan dibuat, termasuk estimasi ukuran file dan konfirmasi dependensi. Ini untuk memastikan semua file dan komponen yang dibutuhkan tersedia. Jika ada masalah, pembuatan snapshot bisa tertunda hingga masalah diselesaikan. Jika semua sudah siap, pengguna bisa langsung mengeksekusi snapshot. Proses tinjauan biasanya dilewati untuk snapshot yang sudah terjadwal otomatis, kecuali jika terjadi masalah.
Eksekusi Snapshot. Setelah dikonfirmasi, snapshot dieksekusi dan disimpan sesuai konfigurasi. Biasanya UI akan meng-update status snapshot baru, termasuk lokasi, ukuran, dan detail lainnya. Jika ada error, UI akan melaporkan dan mencatatnya untuk ditinjau.
Tutup UI. Setelah snapshot selesai dibuat, UI bisa ditutup. Platform snapshot biasanya tetap berjalan di latar belakang untuk tugas monitoring atau maintenance lanjutan.

Restorasi Snapshot

Melakukan restorasi snapshot pada dasarnya merupakan proses kebalikan dari pembuatan snapshot. Proses restorasi yang sebenarnya bisa berbeda-beda tergantung pada platform dan jenis snapshot yang digunakan. Berikut ini langkah-langkah restorasi sederhana yang biasanya dilakukan saat patch atau upgrade aplikasi gagal dan perlu dikembalikan ke kondisi sebelumnya:

Buka UI Snapshot. Sama seperti saat membuat snapshot, restorasi dimulai dengan membuka aplikasi UI atau konsol. Kemungkinan besar akan ada banyak snapshot yang tersedia untuk dipilih.
Pilih File Snapshot yang Diinginkan. Pilih snapshot yang diperlukan untuk proses restorasi. Biasanya, ini hanya melibatkan memilih file dari daftar yang tersedia, walaupun seringkali snapshot yang dibutuhkan adalah yang paling baru dibuat. Mungkin diperlukan konfigurasi tambahan seperti verifikasi integritas file snapshot dan dependensi yang diperlukan. Selain itu, aplikasi yang terkait harus dijeda (quiesce) atau dimatikan sepenuhnya.
Eksekusi Restorasi Snapshot. Setelah snapshot yang diinginkan dan detail lainnya dipilih, serta aplikasi dihentikan jika perlu, proses restorasi dapat dijalankan. Karena snapshot mungkin melibatkan banyak perubahan data, proses ini bisa memakan waktu beberapa menit. Seluruh detail proses restorasi biasanya dicatat untuk keperluan review. Jika restorasi gagal, alasannya juga akan tercatat, dan manajer workload akan memutuskan apakah ingin mencoba lagi, memilih snapshot lain, atau menggunakan backup tradisional.
Uji dan Validasi Restorasi. Setelah proses restorasi selesai, restart dan uji aplikasi yang terlibat untuk memastikan semuanya berjalan seperti yang diharapkan sebelum mengembalikannya ke lingkungan produksi.
Tutup UI. Setelah restorasi sukses, UI bisa ditutup. Platform snapshot biasanya tetap berjalan di latar belakang.

Retensi Snapshot

Retensi snapshot bisa menjadi topik yang cukup menantang karena snapshot adalah data. Mereka tunduk pada kebijakan retensi data organisasi dan kewajiban kepatuhan regulasi. Di sisi lain, snapshot bersifat sensitif terhadap waktu. Mereka menghabiskan ruang penyimpanan berharga namun dengan cepat kehilangan nilai bisnis seiring berjalannya waktu dan digantikan oleh snapshot yang lebih baru.

Sebagai contoh, apakah layak menyimpan file snapshot selama berbulan-bulan atau bertahun-tahun jika snapshot baru dibuat setiap jam? Pada titik tertentu, snapshot lama hanya membuang-buang ruang penyimpanan.

Jawaban terhadap masalah retensi ini bergantung pada persilangan antara nilai bisnis dan kebutuhan bisnis. Retensi snapshot didasarkan pada dua pertanyaan utama:

Berapa lama file snapshot masih berguna bagi bisnis?
Berapa lama bisnis wajib menyimpan file snapshot tersebut?

Dalam praktiknya, file snapshot biasanya diberi definisi unik atau periode retensi khusus dalam siklus hidup data dan kebijakan retensi data organisasi berdasarkan kebutuhan spesifik bisnis tersebut. Semua kebijakan retensi data sebaiknya melibatkan diskusi dengan pemimpin bisnis, pemilik workload, dan penasihat hukum yang memahami isu-isu kepatuhan dan regulasi yang berlaku.

Snapshot Penyimpanan vs. Continuous Data Protection

Continuous Data Protection (CDP) menggunakan pelacakan blok yang berubah (changed block tracking) dan snapshot untuk mencadangkan sistem dengan cara yang memungkinkan pengguna memulihkan data ke kondisi terbaru.

Perbedaan utama antara CDP dan snapshot biasa adalah pada RPO (Recovery Point Objective). Dengan snapshot, RPO bisa berkisar dari beberapa menit hingga beberapa jam, sehingga ada risiko kehilangan data ketika pemulihan diperlukan. Dengan CDP, RPO hampir selalu nol, sehingga data jarang sekali hilang saat terjadi pemulihan.

Perbedaan praktis ini bisa diibaratkan antara serangkaian foto terpisah (snapshot) dibandingkan dengan video yang berjalan terus-menerus (CDP).

CDP bekerja dengan memantau perangkat penyimpanan pada level blok. Setiap kali sebuah blok dibuat atau diubah, perubahan tersebut langsung dicadangkan secara otomatis. Ini memungkinkan pengguna untuk memulihkan data termasuk perubahan terbaru, yang mungkin akan hilang jika hanya mengandalkan snapshot biasa.

Selain itu, CDP juga menyimpan catatan dari setiap perubahan yang terjadi, sehingga selalu memungkinkan untuk memulihkan salinan data bersih yang paling baru.

Meskipun CDP memiliki keunggulan besar dibandingkan snapshot biasa, alasan CDP belum menjadi teknologi snapshot standar adalah karena beban berat yang ditimbulkannya. Pengawasan dan pencatatan perubahan penyimpanan secara terus-menerus membutuhkan sumber daya penyimpanan dan jaringan yang sangat besar. Oleh karena itu, CDP paling cocok digunakan untuk melindungi aplikasi-aplikasi enterprise yang paling kritikal, di mana kehilangan data sama sekali tidak dapat diterima.

Snapshot Penyimpanan vs. Backup

Meskipun snapshot menawarkan kemampuan yang mirip dengan backup, sebenarnya snapshot dan backup cukup berbeda. Snapshot tidak dimaksudkan untuk menggantikan backup, meskipun banyak sistem backup modern kini menggabungkan teknologi snapshot.

Ada beberapa manfaat menggunakan snapshot penyimpanan sebagai bagian dari strategi backup yang lebih besar. Snapshot memungkinkan pemulihan point-in-time (PIT) secara cepat dan mudah. Snapshot juga bisa digunakan oleh aplikasi backup untuk mengaktifkan fitur seperti instant recovery. Namun, meskipun teknologi snapshot sangat membantu dalam rencana backup, snapshot tetap bukan pengganti penuh untuk backup tradisional.

Sebagai perbandingan, backup tradisional dirancang untuk memberikan salinan lengkap dan rinci dari seluruh aplikasi dan kumpulan data, termasuk pengaturan dan konfigurasi. Selain itu, backup yang benar biasanya disimpan di lokasi sekunder atau off-site untuk melindungi data dari bencana atau kegagalan sistem.

Ada beberapa alasan mengapa snapshot tidak seharusnya digunakan sebagai pengganti backup. Pertama, snapshot dapat berdampak negatif terhadap performa sistem—khususnya pada sistem penyimpanan dan jaringan lokal yang digunakan untuk membawa data snapshot. Ini terutama berlaku untuk snapshot berbasis differencing disk. Setiap kali snapshot dibuat, satu differencing disk tambahan juga dibuat. Performa baca sistem akan menurun seiring bertambahnya jumlah differencing disk.

Alasan lain mengapa snapshot bukan pengganti backup yang ideal adalah karena snapshot bergantung pada data sumber yang berisi daftar atau indeks perubahan dari waktu ke waktu. Jika daftar perubahan ini hilang atau rusak, maka snapshot juga hilang. Tidak seperti backup, snapshot tidak menyimpan salinan data yang dilindungi dan tidak melindungi data sumber dari kehilangan akibat kerusakan perangkat keras atau korupsi penyimpanan.

	Backup	Snapshot
	Backup berisi salinan data yang dapat dipulihkan.	Snapshot memastikan data yang sudah ada tidak dapat diubah, namun tidak melindungi dari kehilangan akibat kerusakan perangkat keras atau faktor lainnya.
Pemulihan	Proses pemulihan melibatkan penyalinan data dari backup kembali ke penyimpanan utama. Waktu yang dibutuhkan tergantung pada banyaknya data yang dipulihkan.	Snapshot dapat digunakan untuk segera mengembalikan sistem ke kondisi sebelumnya. Restorasi snapshot berlangsung cepat karena tidak ada proses penyalinan data seperti pada backup.
Performa	Performa baca sistem bisa menurun saat backup berlangsung, tetapi akan kembali normal setelah backup selesai. Backup dengan CDP (Continuous Data Protection) bisa mempengaruhi performa saat backup awal, namun backup berikutnya biasanya berdampak minimal.	Snapshot berbasis differencing disk akan menurunkan performa baca selama snapshot tersebut masih ada. Penurunan performa bergantung pada jumlah snapshot yang ada. Setiap snapshot baru yang ditambahkan dalam struktur pohon snapshot akan semakin menurunkan performa.

Bagaimana Snapshot Penyimpanan dan Backup Bekerja Bersama

Saat ini, backup dan snapshot biasa digunakan bersama dalam lingkungan perusahaan untuk mengoptimalkan berbagai aspek perlindungan aplikasi dan data. Kedua teknologi ini interoperable dan saling melengkapi, bahkan bisa diterapkan secara bersamaan.

Sistem backup modern dalam lingkungan produksi sering menggunakan snapshot sebagai bagian dari proses backup. Ini terutama berlaku saat melakukan backup terhadap sebuah basis data aktif. Jika basis data aktif langsung disalin untuk backup, kemungkinan besar data akan berubah sebelum proses backup selesai. Hasilnya, backup tersebut bisa jadi korup atau tidak lengkap.

Sistem backup modern biasanya mengambil snapshot dari basis data sebelum memulai backup. Sistem kemudian melakukan backup terhadap basis data seperti kondisi saat snapshot diambil. Setelah proses backup selesai, snapshot dihapus dan perubahan data yang disimpan di snapshot digabungkan kembali ke basis data.

storage snapshot