Snapshots penting apakah Anda menjalankan mesin virtual sederhana di komputer rumah Anda atau jika itu adalah database perusahaan yang terus diperbarui dan dimodifikasi. Memiliki snapshot, yaitu, salinan seluruh sistem file seperti pada periode waktu tertentu adalah penting.

Orang sering kehilangan jejak di mana ada kesalahan, file dihapus dan tidak ada yang menyadari bahwa itu hilang. Beberapa cadangan telah berlalu dan sekarang Anda menyadari bahwa ada file penting yang hilang dari semua cadangan yang tersedia selama 5 minggu terakhir. Dalam tutorial ini, kita akan melihat bagaimana menggunakan snapshot ZFS dan menyentuh berbagai kebijakan snapshot yang akan bekerja secara optimal, baik dalam hal pemanfaatan sumber daya dan pemulihan.

Mekanisme Copy-On-Write

ZFS memiliki tinjauan file dan direktori tingkat tinggi dan memahami bagaimana data ditulis pada disk. Saat menulis data secara fisik ke disk, itu dilakukan dalam blok diskrit. Biasanya, ukuran blok bisa mencapai 1 MB tetapi standarnya biasanya 128 KB. Sekarang, ini berarti setiap modifikasi (baca, tulis, atau penghapusan) akan terjadi di blok diskrit.

Mekanisme copy-on-write memastikan bahwa setiap kali sebuah blok dimodifikasi, alih-alih memodifikasi blok secara langsung, itu membuat salinan blok dengan modifikasi yang diperlukan dilakukan pada blok baru.

Ini sangat membantu dalam kasus di mana, katakanlah, ada kegagalan daya dan sistem Anda mogok saat data baru sedang ditulis ke disk. Jika itu terjadi di sistem file tradisional, file Anda akan rusak atau dibiarkan berlubang. Tetapi jika Anda menggunakan ZFS, Anda mungkin kehilangan transaksi yang sedang berlangsung seperti yang terjadi, tetapi status valid terakhir file Anda akan tetap tidak tersentuh.

Snapshots juga bergantung pada fungsi ini, dan sebenarnya cukup berat. Saat Anda mengambil snapshot dari kumpulan data yang diberikan ('set data' adalah istilah ZFS untuk sistem file), ZFS hanya mencatat stempel waktu saat snapshot dibuat. Hanya itu saja! Tidak ada data yang disalin dan tidak ada penyimpanan tambahan yang digunakan.

Hanya ketika sistem file berubah, dan data di dalamnya menyimpang dari snapshot, snapshot mulai menggunakan penyimpanan ekstra. Apa yang terjadi di bawah tenda adalah ini - Alih-alih mendaur ulang blok lama dari waktu ke waktu, ZFS menyimpannya. Ini juga meningkatkan pemanfaatan penyimpanan. Jika Anda memotret kumpulan data 20GB dan memodifikasi hanya beberapa file teks di sana-sini, snapshot mungkin hanya membutuhkan beberapa MB ruang.

Membuat Snapshot

Untuk mendemonstrasikan penggunaan snapshot, mari kita mulai dengan kumpulan data yang memiliki banyak file teks, agar masalahnya tetap sederhana. Mesin virtual yang akan saya gunakan untuk demo menjalankan FreeBSD 11.1-RELEASE-p3 yang merupakan rilis stabil terbaru yang tersedia pada saat penulisan ini. Sistem file root dipasang di zroot pool secara default dan banyak direktori yang sudah dikenal seperti /usr/src, /home, /etc semua set data mereka sendiri terpasang mounted zroot. Jika Anda tidak tahu apa artinya pool (atau zpool), dalam bahasa ZFS, ada baiknya Anda membacanya sebelum melanjutkan.

Salah satu dari banyak sistem file, atau kumpulan data, yang datang secara default di FreeBSD adalah: zroot/usr/src

Untuk melihat propertinya, jalankan perintah berikut:.

[dilindungi email]:~$ daftar zfs zroot/usr/src

Seperti yang Anda lihat, itu menggunakan penyimpanan 633 MB. Ini berisi seluruh pohon sumber untuk sistem operasi.

Mari kita ambil cuplikannya zroot/usr/src

[dilindungi email]:~$ zfs snapshot zroot/usr/[dilindungi email]

Simbol @ bertindak sebagai pembatas antara dataset dan nama snapshot, yang dalam kasus kami adalah snapshot1.

Sekarang mari kita lihat status snapshot saat dibuat.

Dengan menjalankan perintah:

zfs list -rt all zroot/usr/src

Anda dapat melihat bahwa snapshot tidak menggunakan ruang ekstra saat lahir. Tidak ada ruang yang tersedia juga, karena ini adalah kumpulan data hanya baca yang ketat, snapshot itu sendiri tidak dapat tumbuh, dimodifikasi, atau menyusut. Terakhir, itu tidak dipasang di mana pun yang membuatnya benar-benar terisolasi dari hierarki sistem file yang diberikan.

Sekarang, mari kita hapus sbin direktori di /usr/src/

[dilindungi email]:$ rm /usr/src/sbin

Melihat snapshot Anda sekarang akan melihat bahwa itu telah berkembang,

Hal ini diharapkan karena mekanisme copy-on-write sedang bekerja di sini dan menghapus (atau memodifikasi) file telah menyebabkan lebih banyak data yang dikaitkan hanya dengan snapshot dan bukan dataset yang benar-benar digunakan.

Perhatikan kolom REFER pada output di atas. Ini memberi Anda jumlah data yang dapat diakses pada kumpulan data sedangkan kolom DIGUNAKAN hanya menunjukkan kepada Anda berapa banyak ruang yang ditempati pada disk fisik.

Mekanisme Copy-On-Write ZFS sering memberikan hasil kontra-intuitif ini di mana menghapus file akan membuatnya tampak seolah-olah lebih banyak ruang sekarang digunakan daripada sebelumnya. Namun, setelah membaca sejauh ini, Anda tahu apa yang sebenarnya terjadi!

Sebelum selesai, mari pulihkan sbin dari snapshot1. Untuk melakukan itu cukup jalankan:

[dilindungi email]:/usr/src$ zfs kembalikan zroot/usr/[dilindungi email]

Kebijakan Pengambilan Gambar

Pertanyaan berikutnya untuk ditanyakan adalah - Seberapa sering Anda ingin mengambil foto?? Meskipun mungkin berbeda dari satu perusahaan ke perusahaan lain, mari kita ambil contoh database yang sangat dinamis yang sering berubah.

Untuk memulainya, Anda akan mulai mengambil snapshot setiap 6 jam atau lebih, tetapi karena database berubah begitu banyak, akan segera menjadi tidak mungkin untuk menyimpan semua banyak snapshot yang dibuat. Jadi langkah selanjutnya adalah menghapus snapshot yang lebih lama dari, katakanlah, 48 jam.

Sekarang, masalahnya adalah memulihkan sesuatu yang telah hilang 49 jam yang lalu. Untuk menghindari masalah ini, Anda dapat menyimpan satu atau dua snapshot dari riwayat 48 jam itu dan menyimpannya selama seminggu. Bersihkan mereka ketika mereka bertambah tua dari itu.

Dan jika Anda dapat terus seperti ini, Anda dapat menjejalkan snapshot hingga ke asal-usul sistem, hanya dalam urutan frekuensi yang menurun. Terakhir, saya ingin menunjukkan bahwa snapshot ini adalah READ-ONLY yang berarti jika Anda terinfeksi oleh ransomware dan mendapatkan semua data Anda dienkripsi (dimodifikasi). Foto-foto ini, kemungkinan besar, akan tetap utuh.