Ringkasan pencadangan

Halaman ini menjelaskan tentang pencadangan, cara kerjanya, beberapa kasus penggunaan umum, dan praktik terbaik saat membuat dan menggunakan cadangan. Untuk mempelajari cara membuat dan mengelola cadangan, serta cara memulihkan instance Filestore dari cadangan, lihat Mencadangkan data untuk pemulihan dari bencana.

Apa itu cadangan?

Cadangan Filestore adalah salinan dari berbagi file yang mencakup semua data file dan metadata dari berbagi file dari waktu saat cadangan dibuat.

Setelah membuat cadangan berbagi file, Anda dapat mengubah atau menghapus berbagi file asli tanpa memengaruhi cadangan tersebut.

Anda dapat menggunakan cadangan untuk memulihkan berbagi file ke instance Filestore baru atau, untuk instance tingkat dasar, ke sumber atau ke berbagi file yang sudah ada.

Cadangan adalah resource regional yang tetap berada dalam region yang Anda tentukan pada saat pembuatan. Anda dapat membuat cadangan di region yang sama dengan instance Filestore atau ke region lain untuk membantu mengurangi risiko kehilangan data.

Cadangan dapat ditangani secara global dan dapat digunakan untuk memulihkan berbagi file ke region mana pun, tetapi tidak dapat dibagikan antar-project.

Pembuatan cadangan

Cadangan pertama yang Anda buat adalah salinan lengkap dari semua data dan metadata file pada suatu fitur berbagi file. Setiap pencadangan berikutnya akan menyalin setiap perubahan berturut-turut yang dilakukan pada data sejak pencadangan sebelumnya.

Sekelompok cadangan yang terkait dengan instance, region, dan CMEK yang sama (jika digunakan) disebut rantai cadangan.

Rantai cadangan berada di satu bucket dan region Cloud Storage dan dapat ditempatkan di luar region yang digunakan untuk menyimpan instance sumber.

Semua tingkat layanan mendukung beberapa rantai pencadangan yang memungkinkan Anda menyimpan cadangan instance di beberapa region.

Setiap kali pencadangan dibuat, cadangan sebelumnya akan dipindai untuk mendeteksi perubahan diferensial dan inkremental:

  • Perubahan diferensial: mencakup perubahan yang dibuat pada file yang dibagikan seperti pengeditan, penambahan, atau penghapusan file.

  • Perubahan inkremental: mencakup perubahan pada penyimpanan di bucket tempat data cadangan berada. Hal ini mungkin mencakup penghapusan duplikat data yang sebelumnya dirujuk dalam rantai.

Setiap kali Anda menyimpan cadangan ke rantai cadangan yang sama, cadangan sebelumnya dipindai untuk menemukan perubahan diferensial dan inkremental. Dalam kasus seperti itu, salinan lengkap tidak diperlukan.

Namun, menyimpan data instance ke beberapa rantai cadangan menyiratkan bahwa Anda menyimpan dan menyimpan cadangan ke lokasi alternatif.

Setiap kali Anda membuat cadangan baru ke lokasi alternatif, salinan lengkap cadangan akan dibuat lagi. Perkirakan latensi yang lebih tinggi pada operasi create pencadangan saat beralih antar-rantai pencadangan.

Data yang tidak berubah yang terdapat dalam cadangan sebelumnya dirujuk dalam, tetapi tidak disalin ke, cadangan yang lebih baru. Jika cadangan yang lebih lama dihapus, data uniknya akan disalin ke cadangan terbaru berikutnya dan semua referensi data internal akan diperbarui secara otomatis.

Pembuatan cadangan berlangsung secara instan, tetapi memerlukan periode yang sebanding dengan jumlah data yang disalin sebelum cadangan tersedia untuk digunakan. Selama periode ini, pencadangan bertransisi melalui tiga status:

Negara bagian/Provinsi Durasi Deskripsi
Membuat Beberapa detik Menangkap status berbagi file saat ini. Perubahan baru apa pun pada data berbagi file mungkin disertakan atau tidak disertakan dalam cadangan. Penulisan stabil yang dikonfirmasi oleh instance sebelum pencadangan dimulai akan disertakan.
Menyelesaikan Tergantung ukuran Mengupload data ke cadangan. Perubahan baru apa pun pada data berbagi file tidak disertakan dalam cadangan.
Ready Sampai cadangan dihapus Cadangan siap digunakan.

Setelah dibuat, cadangan tingkat dasar dikompresi secara otomatis untuk mengurangi biaya. Performa instance dapat berkurang saat membuat cadangan untuk instance di tingkat zona (sebelumnya SSD skala tinggi) dan tingkat layanan perusahaan. Pembuatan cadangan tidak memengaruhi ketersediaan atau performa instance paket dasar.

Penghapusan cadangan

Cadangan adalah resource level project, bukan sub-resource dari instance sumber, dan memerlukan penyimpanan tersendiri yang terpisah. Akibatnya, siklus proses pencadangan tidak terikat dengan instance sumber. Menghapus sumber tidak akan menghapus cadangannya yang terkait. Jika ingin menghapus cadangan, Anda harus secara eksplisit melakukan operasi penghapusan pada cadangan, bukan instance.

Pastikan untuk menghapus cadangan yang tidak diinginkan. Jika instance sumber dihapus, cadangan yang tersisa akan terus dikenai biaya.

Penghapusan cadangan bersifat permanen dan tidak dapat diurungkan.

Konsistensi pencadangan

Cadangan Filestore memiliki semantik konsistensi NFSv3. Sebelum pencadangan dimulai, setiap penulisan yang diakui instance Filestore sebagai ditulis ke penyimpanan stabil atau yang diikuti dengan COMMIT yang dikonfirmasi akan disertakan dalam cadangan. Untuk mengetahui detailnya, lihat NFSv3 RFC-1813 bagian 3.3.7.

Kasus penggunaan umum

Bagian berikut menjelaskan kasus penggunaan umum pencadangan.

Mencadangkan data untuk pemulihan dari bencana (disaster recovery)

Bayangkan Anda memiliki instance Filestore di us-west1-c, dan Anda ingin melindungi data dari bencana yang memengaruhi region ini. Anda dapat menjadwalkan tugas yang secara rutin membuat cadangan instance ini ke region jarak jauh, misalnya us- east1. Jika terjadi bencana yang melibatkan us-west1-c, Anda dapat membuat instance baru di lokasi lain dari pencadangan sebelumnya.

Mencadangkan data untuk menghindari perubahan yang tidak disengaja

Jika ingin melindungi data Filestore dari perubahan yang tidak diinginkan, Anda dapat menjadwalkan tugas yang secara rutin membuat cadangan instance. Jika kehilangan data, Anda dapat melihat daftar cadangan untuk mengidentifikasi cadangan dengan versi file yang diperlukan. Kemudian, Anda dapat membuat instance Filestore baru dari cadangan, memasangnya ke klien yang sama dengan instance asli, lalu menyalin file tersebut.

Sebelum menyalin file, Anda dapat menggunakan perintah diff Linux di kedua direktori pemasangan untuk memeriksa perbedaan antara data pada instance asli dan data yang dipulihkan dari cadangan. Setelah data dipulihkan, Anda dapat menghapus instance yang dipulihkan dan membuat cadangan baru guna mempertahankan status data saat ini agar dapat digunakan di lain waktu.

Atau, Anda dapat melakukan pemulihan langsung di mana data cadangan langsung dipulihkan ke instance Filestore asli, yang mengganti semua data di dalamnya dengan data dari cadangan. Sebaiknya Anda membuat cadangan data terbaru sebelum melakukan pemulihan secara langsung karena data yang tidak dicadangkan akan hilang.

Membuat clone untuk pengembangan dan pengujian

Bayangkan Anda memiliki database yang disiapkan pada instance Filestore yang menyalurkan traffic produksi. Jika ingin menjalankan pengujian dengan database sebagai input, Anda dapat membuat instance Filestore baru dari cadangan instance produksi untuk pengujian. Dengan cara ini, penggunaan pengujian tidak mengganggu produksi.

Demikian pula, Anda dapat menggunakan cadangan untuk analisis dan penyelidikan offline tanpa memengaruhi produksi.

Memigrasikan Data

Setelah membuat instance Filestore, Anda tidak dapat mengubah lokasi atau tingkat layanannya. Untuk memigrasikan data ke region lain, Anda dapat membuat cadangannya dan menggunakan cadangan tersebut untuk membuat instance Filestore baru atau memulihkannya ke instance yang ada.

Selain itu, saat membuat instance Filestore baru dari cadangan, Anda dapat memilih antara tingkat HDD dasar dan SSD dasar, terlepas dari tingkat instance sumber.

Batasan fitur

Cadangan Filestore tersedia secara umum (GA) untuk semua tingkat layanan.

Batasan berikut berlaku:

  • Cadangan Filestore tidak dapat digabungkan dengan fitur multishares Filestore.

  • Setelah harga diterapkan, biaya yang relevan akan berlaku.

  • Pengguna harus membuat cadangan atau cadangan baru untuk menggantikan cadangan atau cadangan yang dibuat di Pratinjau. Cadangan yang dibuat dalam Pratinjau dapat dihapus. Cadangan yang dibuat di Pratinjau mencerminkan perilaku fitur yang tersedia pada saat pembuatan. Cadangan yang ada tidak diperbarui saat kemampuan baru dirilis.

Bagian berikut membahas batasan fitur lain yang terkait dengan performa, penyimpanan, kapasitas, dan enkripsi secara mendetail:

Performa

  • Banyak perubahan yang dilakukan melalui banyak hard link pada file yang sama (misalnya, puluhan atau ratusan ribu) dapat berdampak terhadap performa.

  • Untuk instance yang sangat sering digunakan, performa dapat berkurang hingga 15% saat cadangan diupload. Performa instance tingkat dasar tidak terpengaruh oleh operasi create pencadangan.

  • Menyimpan data instance ke beberapa rantai pencadangan dapat memengaruhi performa pencadangan. Perkirakan latensi yang lebih tinggi pada operasi create pencadangan ketika berganti-ganti rantai pencadangan.

  • Operasi instance seperti instance restore atau instance delete dapat tertunda hingga operasi create cadangan selesai.

  • Dalam beberapa kasus, operasi delete mungkin memerlukan waktu hingga 24 jam untuk diselesaikan.

Serentak operasi

  • Operasi delete pencadangan yang terkait dengan instance sumber yang sama harus dilakukan satu per satu.

    Operasi delete pencadangan massal dalam rantai pencadangan tidak didukung. Saat operasi delete tertunda, setiap operasi delete baru dalam rantai cadangan yang sama akan menampilkan error RESOURCE_EXHAUSTED. Hal ini terlepas dari apakah instance sumber sudah dihapus atau belum.

    • Jika instance sumber telah dihapus, pengguna akan menerima error FAILED_PRECONDITION yang serupa.

    • Batasan ini berlaku untuk setiap tingkat layanan, kecuali SSD dasar dan HDD biasa.

    • Perlu diperhatikan bahwa Filestore mendukung operasi delete pencadangan serentak jika pencadangan mereferensikan instance sumber terpisah.

      Misalnya, instance berlabel Source1 memiliki data cadangan yang dirujuk dalam Backup1 dan Backup2. Source2 memiliki data cadangan yang direferensikan di Backup3 dan Backup4. Backup1 dan Backup2 tidak dapat dihapus secara paralel, tetapi Backup2 dan Backup3 dapat dihapus.

  • Operasi create pencadangan dan delete pencadangan yang dimulai dalam rantai cadangan yang sama dapat berjalan serentak. Namun, pengguna tidak dapat menyelesaikan operasi create pencadangan saat cadangan terbaru sedang dihapus.

    • Jika pengguna mencoba membuat cadangan baru dari instance tersebut sementara cadangan terbaru sedang dihapus, mereka akan menerima error FAILED_PRECONDITION. Misalnya, jika Source1 memiliki rantai cadangan yang terdiri dari Backup1 dan Backup2, dan pengguna memulai operasi create untuk Backup3, mereka tidak akan dapat menghapus Backup2 sampai operasi create selesai. Hal ini karena pencadangan terbaru berisi data paling penting yang diperlukan agar berhasil menyelesaikan operasi create pencadangan.

  • Untuk informasi selengkapnya terkait batas kapasitas operasi, lihat Batas kapasitas operasi untuk pencadangan.

Penyimpanan

  • Mencadangkan operasi restore ke instance sumber, atau ke instance yang ada, tidak didukung untuk instance tingkat zona dan perusahaan. Jika ingin memulihkan cadangan instance di salah satu tingkat layanan ini, Anda harus membuat instance baru.

  • Operasi pencadangan, seperti restore, edit, atau delete, mungkin tidak tersedia untuk cadangan tertentu yang dibuat dalam Pratinjau.

  • Setelah operasi RestoreInstance diterapkan ke instance perusahaan, Anda tidak akan dapat membuat snapshot dengan nama yang sama seperti snapshot sebelumnya sebelum operasi tersebut.

  • Upaya memulihkan instance dari cadangan saat penghapusan cadangan atau penghapusan snapshot akan gagal.

  • Jika cadangan gagal dihapus, statusnya akan ditandai sebagai invalid. Dalam kasus tersebut, Anda harus mencoba kembali operasi delete.

Capacity

Setiap cadangan akan menempati kapasitas instance. Kapasitas ini bervariasi relatif terhadap cakupan perubahan yang dilakukan pada data sejak pencadangan terakhir dibuat.

Lebih khusus lagi, saat cadangan dibuat, Filestore membuat snapshot internal dari sistem file yang juga menempati sebagian kapasitas instance yang tersedia.

Ukuran snapshot juga relatif terhadap cakupan perubahan yang dilakukan pada data dalam berbagi sejak pencadangan terakhir dibuat. Snapshot ini akan terus ada hingga cadangan berikutnya dibuat dan diupload.

Semua data yang dirujuk oleh cadangan akan tetap dalam status seperti saat diambil dan terus mengambil kapasitas dari sistem file. Jadi misalnya, jika Anda ingin menghapus data dari sistem file yang terpasang, tindakan tersebut tidak akan mengosongkan kapasitas. Untuk melakukannya, Anda harus membuat cadangan baru setelah menghapus atau menimpa data dalam jumlah besar.

Untuk deskripsi mendetail tentang perubahan diferensial dan inkremental serta cara penanganannya, lihat Pembuatan cadangan.

Guna mengantisipasi kapasitas yang memadai untuk beban kerja Anda, pertimbangkan untuk menerapkan salah satu hal berikut:

  • Tingkatkan kapasitas instance untuk workload dengan perubahan data yang signifikan dan sering atau tingkat perubahan yang tinggi.

Enkripsi

Saat menggunakan CMEK untuk mengenkripsi rantai cadangan, batasan berikut berlaku:

  • Seluruh rantai cadangan dienkripsi menggunakan CMEK yang sama.

  • CMEK harus berada di region yang sama dengan resource yang dienkripsinya.

  • Jika menyimpan rantai cadangan di region yang terpisah dari instance sumber, Anda mungkin perlu menerapkan kunci terpisah, satu untuk sumber dan satu untuk rantai cadangan.

    • Semua tingkat layanan mendukung beberapa rantai pencadangan, atau kemampuan untuk menyimpan cadangan instance di beberapa region. Jika memilih menggunakan CMEK untuk enkripsi, kunci CMEK harus berada di region yang sama dengan resource yang dienkripsi. Jika Anda menyimpan cadangan di region yang terpisah dari sumber, dan CMEK bukan kunci multiregion, Anda harus menggunakan kunci CMEK terpisah. Untuk mengetahui informasi selengkapnya, lihat Pembatasan CMEK dan Memilih lokasi CMEK terbaik.

  • Satu CMEK diterapkan ke bucket Cloud Storage tempat rantai cadangan disimpan dan tidak dapat digabungkan atau diganti.

  • Dukungan CMEK tidak tersedia untuk pencadangan tingkat dasar.

Untuk mengetahui informasi selengkapnya, lihat Dukungan CMEK untuk rantai cadangan.

Praktik terbaik

Bagian berikut membahas praktik terbaik yang direkomendasikan.

Menyiapkan layanan berbagi file Anda untuk konsistensi pencadangan terbaik

Kualitas cadangan bergantung pada kemampuan aplikasi Anda untuk melakukan pemulihan dari cadangan yang dibuat selama beban kerja penulisan yang berat. Pada umumnya, Anda dapat membuat cadangan yang memiliki konsistensi baik, meskipun aplikasi menulis data ke berbagi file. Namun, jika aplikasi Anda memerlukan konsistensi yang ketat, sebaiknya lakukan satu atau beberapa hal berikut:

  • Gunakan dudukan sync. Untuk mengetahui informasi selengkapnya, lihat bagian "Opsi pemasangan sinkronisasi" di nfs(5). Atau, Anda dapat membuka file dengan tanda O_DIRECT|O_SYNC. Untuk informasi selengkapnya, lihat open(2).
  • Jeda proses aplikasi atau sistem operasi yang menulis data ke berbagi file dan menyebabkan aplikasi menghapus perubahannya ke berbagi file sebelum memulai pencadangan. Untuk mengetahui informasi selengkapnya, lihat fsync(2).
  • Jika aplikasi Anda memerlukan konsistensi antara beberapa kali berbagi, jeda semua aplikasi pada semua instance yang menulis untuk semua pembagian file dan buat cadangan dari semua berbagi file sebelum melanjutkan aplikasi Anda.
  • Jika Anda memerlukan konsistensi tingkat aplikasi, hentikan aplikasi dan lepaskan fitur berbagi file sebelum membuat cadangan.

Menggunakan cadangan yang ada sebagai dasar cadangan baru untuk mengurangi waktu pembuatan cadangan

Cadangan berbagi file yang ada dalam suatu region digunakan sebagai dasar pengukuran untuk membuat cadangan baru untuk berbagi file, sehingga mengurangi waktu pembuatan cadangan. Oleh karena itu, sebaiknya Anda melakukan hal berikut:

  • Mengambil cadangan baru dari berbagi file sebelum menghapus cadangan sebelumnya dari berbagi file tersebut.

  • Tunggu hingga pencadangan baru berada dalam status Ready sebelum membuat cadangan berikutnya dari berbagi file yang sama.

Menjadwalkan pencadangan di luar jam sibuk untuk mengurangi waktu pembuatan cadangan

Membuat pencadangan di luar jam sibuk akan mengurangi waktu yang diperlukan untuk membuat cadangan. Jika Anda menjadwalkan pencadangan rutin untuk berbagi file, sebaiknya jadwalkan pencadangan di luar jam sibuk jika memungkinkan.

Jam puncak untuk pembuatan cadangan adalah akhir dari setiap hari kerja dan tengah malam di region tempat instance Filestore berada. Sebaiknya buat cadangan di pagi hari atau sepanjang hari kerja.

Mengatur data Anda pada instance Filestore terpisah untuk memaksimalkan efisiensi

Semakin banyak data yang digunakan untuk berbagi file, semakin besar cadangannya dan semakin besar biayanya. Untuk mencadangkan data yang hanya perlu dicadangkan, sebaiknya kelola data Anda pada berbagi file terpisah, yaitu:

  • Menyimpan data penting dengan pola penulisan yang berbeda atau dengan persyaratan pencadangan berbeda pada berbagi file yang berbeda.
  • Mengurangi jumlah cadangan yang perlu Anda buat dengan menyimpan data yang serupa dalam satu file yang dibagikan.

Kuota

Terdapat batas kuota terkait jumlah cadangan per region untuk tingkat layanan SSD dasar dan HDD dasar.

Batas kuota cadangan tidak berlaku untuk tingkat layanan zona dan perusahaan.

Untuk mengetahui informasi selengkapnya, lihat Tingkat dan kuota layanan.

Mulai menggunakan cadangan Filestore

Untuk mulai menggunakan fitur ini, lihat Mencadangkan data untuk pemulihan dari bencana (disaster recovery).

Langkah selanjutnya