Tingkat Kapasitas (atau sebagaimana kami menyebutnya di dalam Vim - captir) muncul kembali pada masa Veeam Backup dan Replikasi 9.5 Pembaruan 4 dengan nama Tingkat Arsip. Ide di baliknya adalah untuk memungkinkan pemindahan cadangan yang keluar dari jendela pemulihan operasional ke penyimpanan objek. Ini membantu mengosongkan ruang disk bagi pengguna yang memiliki sedikit ruang. Dan opsi ini disebut Move Mode.

Untuk melakukan tindakan sederhana ini (sepertinya), cukup memenuhi dua kondisi: semua titik dari cadangan yang dipindahkan harus berada di luar batas jendela pemulihan operasional yang disebutkan di atas, yang diatur secara eksplisit di UI. Dan kedua: rantai tersebut harus dalam apa yang disebut “bentuk tersegel” (rantai cadangan tersegel atau Rantai Cadangan Tidak Aktif). Artinya, tidak ada perubahan yang terjadi pada rantai ini seiring berjalannya waktu.

Namun di VBR v10, konsep tersebut dilengkapi dengan fungsi baru - Mode Salin, Mode Tertutup, dan sesuatu dengan nama Immutability yang sulit diucapkan muncul.

Inilah hal-hal menarik yang akan kita bicarakan hari ini. Pertama, tentang cara kerjanya di VBR9.5u4, dan kemudian tentang perubahan di versi kesepuluh.

Dan semoga para pembela bahasa murni memaafkan saya, tetapi terlalu banyak istilah yang tidak dapat diterjemahkan.
Jadi akan ada banyak sekali Anglicisme di sini.
Dan banyak GIF.
Dan gambar.

• Tanpa penyesalan sedikitpun. Penulis artikel.

Seperti itu

Baiklah, mari kita mulai dengan menganalisis jendela pemulihan operasional dan cadangan tersegel (atau sebagaimana disebut dalam dokumentasi Rantai Cadangan Tidak Aktif). Tanpa pemahaman mereka, penjelasan lebih lanjut tidak akan mungkin terjadi.

Seperti yang kita lihat pada gambar, kita memiliki semacam rantai cadangan dengan blok data, yang terletak di SOBR tingkat Kinerja dari repositori yang terhubung dengan Tingkat Kapasitas. Jangka waktu pencadangan operasional kami adalah tiga hari.

Oleh karena itu, .vbk yang dibuat pada hari Senin menyegel rantai sebelumnya, yang jangka waktunya disetel ke tiga hari. Dan itu berarti Anda dapat dengan aman mulai mengangkut segala sesuatu yang lebih tua dari tiga hari ini ke lapangan tembak.

Namun apa sebenarnya yang dimaksud dengan rantai tersegel dan apa yang bisa dikirim ke kapasitas lapangan tembak di update 4?

Untuk Forward Inkremental, tanda penyegelan rantai adalah pembuatan cadangan penuh baru. Dan tidak masalah bagaimana pencadangan penuh ini diperoleh: baik pencadangan penuh sintetik maupun pencadangan penuh aktif akan dipertimbangkan.

Dalam kasus Reverse, ini semua adalah file yang tidak masuk ke jendela operasi.

Dalam kasus kenaikan Maju dengan rollback, ini semua adalah rollback dan .vbk, jika ada .vbk lain pada tingkat kinerja

Sekarang mari pertimbangkan opsi untuk bekerja dengan rantai Salinan Cadangan. Hanya barang yang termasuk dalam retensi GFS yang diangkut ke sini. Karena semua yang disimpan dalam rantai salinan cadangan yang lebih baru dapat diubah dengan satu atau lain cara.

Sekarang mari kita lihat di balik terpal. Di sana, proses yang disebut dehidrasi terjadi - meninggalkan file cadangan kosong pada luasnya dan menyeret blok dari file-file ini ke jangkauan pengambilan gambar kapasitas. Untuk mengoptimalkan proses ini, apa yang disebut indeks dehidrasi digunakan, yang memungkinkan Anda menghindari penyalinan blok yang telah disalin ke jarak tembak kapasitas.

Mari kita lihat tampilannya dengan sebuah contoh: Katakanlah kita memiliki .vbk yang keluar dari jendela transaksi dan termasuk dalam rantai tersegel. Artinya, kami berhak memindahkannya ke kapasitas lapangan tembak. Pada saat pemindahan, file metadata dibuat dalam kapasitas dasbor dan blok file yang ditransfer. File metadata tingkat tautan menjelaskan blok apa yang terdiri dari file kita. Dalam kasus pada gambar, file pertama kita terdiri dari blok a, b, c dan metadatanya berisi link ke blok ini. Ketika kita memiliki file .vbk kedua, siap dipindahkan dan terdiri dari blok a, b dan d, kita menganalisis indeks dehidrasi dan memahami bahwa hanya blok d yang perlu dipindahkan. Dan file metadatanya akan berisi link ke dua blok sebelumnya dan satu blok baru.

Oleh karena itu, proses mengisi kembali ruang kosong ini dengan data disebut rehidrasi. Ia sudah menggunakan indeks rehidrasinya sendiri, berdasarkan file .vbk terlama pada tingkat kinerja lokal. Artinya, jika pengguna ingin mengembalikan file dari jarak tembak kapasitas, pertama-tama kita membuat indeks blok dari cadangan penuh terlama dan hanya mentransfer blok yang hilang dari galeri menembak kapasitas. Pada kasus pada gambar, untuk melakukan rehidrasi FullBackup1.vbk sesuai indeks rehidrasi, kita hanya membutuhkan blok C yang kita ambil dari kapasitas lapangan tembak. Jika objek cloud penyimpanan berfungsi sebagai tempat menembak berkapasitas, ini memungkinkan Anda menghemat banyak uang.

Di sini mungkin tampak bahwa teknologi ini identik dengan yang digunakan dalam WAN Accelerators, namun tampaknya hanya itu saja. Dalam akselerator, deduplikasi bersifat global; di sini, deduplikasi lokal digunakan dalam setiap file pada offset tertentu. Hal ini terjadi karena perbedaan dalam tugas yang diselesaikan: di sini kita perlu menyalin file cadangan lengkap yang besar, dan menurut penelitian kami, meskipun ada jangka waktu yang lama di antara keduanya, algoritma deduplikasi ini memberikan hasil terbaik.

Tapi lebih banyak indeks untuk dewa indeks! Ada juga indeks untuk pemulihan data! Saat kami mulai memulihkan mesin yang terletak di dasbor kapasitas, kami hanya akan membaca blok data unik yang tidak ada di dasbor kinerja.

Bagaimana jadinya?

Itu saja untuk bagian pendahuluan. Ini cukup detail, tetapi seperti disebutkan di atas, tanpa detail ini tidak mungkin menjelaskan cara kerja fungsi-fungsi baru. Oleh karena itu, tanpa basa-basi lagi, mari kita lanjutkan ke yang pertama.

Modus salin

Ini sebagian besar didasarkan pada teknologi yang ada, tetapi memiliki logika penggunaan yang sangat berbeda. 

Tujuan dari mode ini adalah untuk memastikan bahwa semua data yang terletak di tingkat lokal memiliki salinan di dasbor kapasitas.

Jika Anda membandingkan mode Pindahkan dan Salin secara langsung, tampilannya akan seperti ini:

• Hanya rantai tersegel yang dapat dipindahkan. Dalam kasus mode penyalinan, semuanya benar-benar ditransfer, apa pun yang terjadi dalam pekerjaan pencadangan.
• Pemindahan dipicu ketika file melampaui batas jendela pencadangan operasional, dan penyalinan dipicu segera setelah file cadangan muncul.
• Pemantauan data baru untuk penyalinan terjadi terus-menerus, dan untuk pemindahannya dipicu setiap 4 jam sekali.

Saat mempertimbangkan mode baru, saya mengusulkan untuk beralih dari contoh sederhana ke contoh kompleks.

Dalam kasus yang paling umum, kami hanya memiliki file baru dengan penambahan, dan kami cukup menyalinnya ke rentang pengambilan gambar kapasitas. Terlepas dari mode apa yang digunakan dalam pekerjaan pencadangan, terlepas dari apakah itu milik bagian rantai yang tersegel atau tidak, terlepas dari apakah jendela operasi kita telah kedaluwarsa. Mereka hanya mengambilnya dan menyalinnya.

Proses di baliknya masih dehidrasi seperti dijelaskan di atas. Dalam mode salin, ini juga memastikan bahwa kita tidak menyalin blok yang sudah ada di penyimpanan kita. Satu-satunya perbedaan adalah jika dalam mode film kami mengganti file asli dengan file tiruan, di sini kami tidak menyentuhnya dengan cara apa pun dan membiarkan semuanya apa adanya. Jika tidak, indeks dehidrasinya persis sama, yang dengan hati-hati mencoba menghemat uang dan waktu Anda.

Timbul pertanyaan - jika Anda melihat UI, ada peluang untuk memilih kedua opsi secara bersamaan. Bagaimana cara kerja mode gabungan tersebut?

Mari kita cari tahu.

Permulaannya standar: file cadangan segera dibuat dan disalin. Peningkatan dibuat untuk itu dan juga disalin. Ini terjadi sampai kita menyadari bahwa file telah meninggalkan jendela operasi kita dan rantai tersegel telah muncul. Pada titik ini kami melakukan operasi dehidrasi dan mengganti file-file ini dengan file dummy. Tentu saja, kami tidak menyalin apa pun lagi ke kapasitas lapangan tembak.

Semua logika menarik ini hanya bertanggung jawab atas satu kotak centang di antarmuka: Salin cadangan ke penyimpanan objek segera setelah dibuat.

Mengapa kita memerlukan mode Salin ini?

Lebih baik lagi jika kita ulangi pertanyaannya seperti ini: risiko apa yang bisa kita lindungi dengan bantuannya? Masalah apa yang dapat kita selesaikan dengan bantuan ini?

Jawabannya jelas: tentu saja, ini adalah pemulihan data. Jika kami memiliki salinan lengkap data lokal di objek penyimpanan, apa pun yang terjadi pada produk kami, kami selalu dapat memulihkan data dari file yang terletak di Amazon bersyarat.

Jadi, mari kita lihat skenario yang mungkin terjadi, dari yang paling sederhana hingga yang lebih rumit.

Kemalangan paling sederhana yang dapat menimpa kepala kita adalah tidak dapat diaksesnya salah satu file dalam rantai cadangan.

Kisah yang lebih menyedihkan adalah salah satu bagian dari repositori SOBR kami rusak.

Lebih buruk lagi ketika seluruh repositori SOBR menjadi tidak dapat diakses, namun rentang pengambilan gambar kapasitas berfungsi.
Dan semuanya benar-benar buruk - ini adalah saat server cadangan mati dan keinginan pertama Anda adalah mencoba lari ke perbatasan Kanada dalam sepuluh menit.

Sekarang mari kita lihat setiap situasi secara terpisah.

Ketika kita kehilangan satu (bahkan beberapa) file cadangan, maka yang perlu kita lakukan hanyalah memulai proses pemindaian ulang repositori, dan file yang hilang tersebut akan diganti dengan file dummy. Dan dengan menggunakan proses rehidrasi (yang telah dibahas di awal artikel), pengguna akan dapat mengunduh data dari kapasitas lapangan tembak ke penyimpanan lokal.

Kini situasinya menjadi lebih rumit. Mari kita asumsikan bahwa SOBR kita terdiri dari dua luasan yang berjalan dalam mode Kinerja, yang berarti bahwa .vbk dan .vib kita tersebar di keduanya dalam lapisan yang agak tidak rata. Dan pada titik waktu tertentu, salah satu tingkatan menjadi tidak tersedia, dan pengguna perlu segera memulihkan mesin, yang sebagian datanya terletak tepat pada tingkat ini.

Pengguna meluncurkan wizard pemulihan, memilih titik di mana ia ingin memulihkan, dan wizard, saat bekerja, menyadari bahwa ia tidak memiliki semua data yang diperlukan untuk pemulihan secara lokal dan oleh karena itu perlu diunduh dari pengambilan gambar kapasitas galeri. Pada saat yang sama, blok yang tersisa di penyimpanan lokal tidak akan diunduh dari cloud. Kemuliaan bagi indeks pemulihan (ya, itu juga disebutkan di awal artikel).

Subtipe dari kasus ini adalah seluruh repositori SOBR menjadi tidak dapat diakses. Dalam hal ini, kami tidak perlu menyalin apa pun dari penyimpanan lokal, dan semua blok diunduh dari cloud.

Dan situasi yang paling menarik adalah server cadangan mati. Ada dua opsi di sini: admin hebat dan membuat cadangan konfigurasi, dan admin sendiri adalah Pinokio yang jahat dan tidak membuat cadangan konfigurasi.

Dalam kasus pertama, cukup baginya untuk menyebarkan instalasi VBR yang bersih di suatu tempat dan memulihkan database-nya dari cadangan menggunakan cara standar. Di akhir proses ini, semuanya akan kembali normal. Atau akan dipulihkan berdasarkan salah satu skenario di atas.

Tetapi jika admin adalah musuhnya sendiri, atau pencadangan konfigurasi juga mengalami kegagalan besar, bahkan di sini kami tidak akan membiarkan dia menyerah begitu saja. Untuk kasus ini, kami telah memperkenalkan prosedur baru yang disebut Impor Penyimpanan Objek. Ini memungkinkan Anda untuk melewati proses pembuatan ulang repositori SOBR secara manual dan melampirkan rentang pengambilan kapasitas ke dalamnya dengan pemindaian ulang berikutnya, dan cukup menambahkan objek penyimpanan ke antarmuka Vim dan menjalankan prosedur Impor Repositori Penyimpanan. Satu-satunya hal yang menghalangi Anda dan cadangan Anda adalah permintaan untuk memasukkan kata sandi jika cadangan Anda dienkripsi.

Ini mungkin semua tentang Mode Salin dan kita lanjutkan ke

Mode Tersegel

Ide utamanya adalah bahwa cadangan baru tidak dapat muncul pada tingkat SOBR repositori yang dipilih. Sebelum v10, kami hanya memiliki Mode Pemeliharaan, ketika pekerjaan apa pun dengan repositori dilarang sepenuhnya. Semacam mode hardcore untuk mematikan penyimpanan, di mana hanya tombol Evakuasi yang tersedia, yang memindahkan cadangan ke tingkat lain satu kali.

Dan mode Tertutup adalah semacam opsi "lunak": kami melarang pembuatan cadangan baru dan secara bertahap menghapus cadangan lama sesuai dengan retensi yang dipilih, namun dalam prosesnya kami tidak kehilangan kemampuan untuk memulihkan dari titik yang disimpan. Hal yang sangat berguna ketika kita memiliki perangkat keras yang mendekati akhir masa pakainya dan perlu menggantinya, atau kita hanya perlu mengosongkannya untuk sesuatu yang lebih penting, tetapi tidak ada tempat untuk mengambilnya dan memindahkan semuanya sekaligus. Atau tidak bisa dihapus.

Oleh karena itu, prinsip operasinya cukup sederhana: perlu untuk melarang semua operasi tulis (penampilan data baru), membiarkan operasi baca (restorasi) dan penghapusan (retensi).

Kedua mode tersebut dapat digunakan secara bersamaan, namun perlu diingat bahwa Maintenance memiliki prioritas lebih tinggi.

Sebagai contoh, perhatikan SOBR yang terdiri dari dua luasan. Mari kita asumsikan bahwa selama empat hari pertama kita membuat cadangan dalam mode Teruskan Selamanya Inkremental, dan kemudian kita menutup jangkauannya, sehingga kita memulai pembuatan cadangan aktif baru pada tingkat kedua yang tersedia. Jika retensi kita adalah empat, maka ketika seluruh rantai yang terletak pada tingkat yang tersegel melampaui batasnya, maka rantai itu akan dihapus dengan hati nurani yang bersih.

Ada situasi ketika penghapusan terjadi lebih awal. Misalnya, ini adalah Maju tambahan dengan pengisian penuh secara berkala. Jika kita membuat full backup untuk dua hari pertama, dan pada hari Kamis kita memutuskan untuk menyegel repositori, maka pada hari Jumat, ketika backup baru dibuat, file untuk hari Senin akan dihapus karena tidak ada ketergantungan sampai saat ini. Dan intinya sendiri tidak bergantung pada siapapun. Kemudian kita menunggu hingga empat titik dibuat pada jangkauan yang tersedia dan menghapus tiga titik sisanya, yang tidak dapat dihapus secara independen satu sama lain.

Segalanya menjadi lebih sederhana dengan Reverse Inkremental. Di dalamnya, poin terlama tidak bergantung pada apa pun dan dapat dihapus dengan aman. Oleh karena itu, segera setelah .vbk baru dibuat pada tingkat yang baru, .vrbs lama akan dihapus satu per satu.

Ngomong-ngomong, mengapa kita membuat .vbk baru setiap saat: jika kita tidak membuatnya, tetapi melanjutkan rantai kenaikan yang lama, maka .vbk yang lama akan membeku untuk waktu yang sangat lama dalam mode apa pun, mencegah penghapusannya. Oleh karena itu, diputuskan bahwa segera setelah cakupannya disegel, kami membuat cadangan penuh pada cakupan gratis.

Segalanya menjadi lebih rumit dengan kapasitas jarak tembak.

Mari kita lihat mode salin terlebih dahulu. Mari kita asumsikan bahwa kita secara aktif membuat cadangan selama empat hari, dan kemudian kapasitas jarak tembak ditutup. Kami tidak menghapus apa pun, tetapi dengan rendah hati menanggung retensi, setelah itu kami menghapus data dari kapasitas jangkauan pemotretan.

Kira-kira hal yang sama terjadi dalam mode pemindahan - kita menunggu retouch, menghapus yang lama di penyimpanan lokal, dan menghapus yang disimpan di penyimpanan objek.

Contoh menarik dengan Forever forward inkremental. Kami memasang retensi di tiga titik dan mulai membuat cadangan pada hari Senin, yang secara rutin disalin ke cloud. Setelah menyegel penyimpanan, cadangan terus dibuat, mempertahankan tiga poin, namun data yang disimpan di dasbor kapasitas tetap bergantung dan tidak dapat dihapus. Oleh karena itu, kami menunggu hingga hari Kamis, ketika .vbk kami melampaui retensi, dan baru kemudian kami dengan tenang menghapus seluruh rantai yang disimpan.

Dan penafian kecil: semua contoh di sini ditampilkan dengan satu mesin. Jika Anda memiliki beberapa di antaranya di cadangan, maka retouchnya akan berbeda tergantung apakah Active Full dibuat atau tidak.

Pada dasarnya hanya itu saja. Jadi mari kita beralih ke fitur paling hardcore -

Kekekalan

Seperti poin sebelumnya, hal pertama adalah masalah apa yang dipecahkan oleh fungsi ini. Segera setelah kami mengunggah cadangan kami di suatu tempat untuk disimpan, ada keinginan kuat untuk menjamin keamanannya, yaitu, secara fisik melarang penghapusan dan modifikasi apa pun selama penyimpanan tertentu. Termasuk admin, termasuk di bawah akun root mereka. Hal ini memungkinkan Anda untuk melindunginya dari kerusakan yang tidak disengaja atau disengaja. Siapa pun yang bekerja dengan AWS mungkin pernah menemukan fitur serupa yang disebut Object Lock.

Sekarang mari kita lihat mode secara umum, lalu pelajari detailnya. Dalam contoh kita, Kekekalan akan diaktifkan untuk jarak tembak kapasitas kita dengan retensi empat hari. Dan mode Salin diaktifkan di cadangan.

Kekekalan tidak berinteraksi dengan retensi umum dengan cara apa pun. Misalnya tidak menambah poin tambahan atau semacamnya. Hanya saja seseorang tidak bisa menghapus file cadangan dalam waktu empat hari. Jika Anda membuat cadangan pada hari Senin, Anda hanya dapat menghapus filenya pada hari Jumat.

Semua konsep dehidrasi, indeks, dan metadata yang dijelaskan sebelumnya terus bekerja dengan cara yang persis sama. Tetapi dengan satu syarat - blok disetel tidak hanya untuk data, tetapi juga untuk metadata. Hal ini dilakukan jika penyerang licik memutuskan untuk menghapus database metadata kami dan mencegah blok data berubah menjadi biner yang tidak berguna.

Sekarang adalah saat yang tepat untuk menjelaskan teknologi pembuatan blok kami. Atau blokir generasi. Untuk melakukan ini, pertimbangkan situasi yang menyebabkan kemunculannya.

Mari kita ambil skala waktu enam hari dan di bawahnya kita akan menandai waktu perkiraan berakhirnya kekekalan. Pada hari pertama kita mengambil dan membuat file yang terdiri dari blok data a dan metadatanya. Jika kekekalan diatur ke tiga hari, masuk akal untuk mengasumsikan bahwa pada hari keempat data akan dibuka kuncinya dan dihapus. Pada hari kedua kita akan menambahkan file2 baru yang terdiri dari blok b dengan setting yang sama. Blok a masih perlu dihilangkan pada hari keempat. Tetapi pada hari ketiga sesuatu yang buruk terjadi - file File3 dibuat, terdiri dari blok baru d dan link ke blok lama a. Artinya untuk suatu blok dan bendera kekekalannya harus direset ke tanggal baru, yaitu digeser ke hari keenam. Dan di sini muncul masalah - dalam cadangan nyata ada sejumlah besar blok seperti itu. Dan untuk memperpanjang periode kekekalannya, Anda perlu membuat banyak permintaan setiap saat. Faktanya, ini akan menjadi proses harian yang hampir tidak ada habisnya, karena dengan tingkat kemungkinan yang tinggi kita akan menemukan tumpukan besar blok-blok terdeduplikasi pada setiap salinan. Apa arti dari banyaknya permintaan dari penyedia penyimpanan objek? Benar! Tagihan besar di akhir bulan.

Dan agar tidak mengekspos klien favorit Anda untuk mendapatkan banyak uang, mekanisme pembuatan blok diciptakan. Ini adalah periode tambahan yang kami tambahkan ke periode kekekalan yang ditetapkan. Pada contoh di bawah, periode ini adalah dua hari. Tapi ini hanyalah sebuah contoh. Pada kenyataannya, mereka menggunakan formula mereka sendiri, yang memberikan sekitar sepuluh hari tambahan selama penguncian bulanan.

Mari kita terus mempertimbangkan situasi yang sama, tetapi dengan pembuatan blok. Pada hari pertama kami membuat file1 dari blok a dan metadata. Kami menjumlahkan periode pembuatan dan kekekalan - ini berarti peluang untuk menghapus file akan ada pada hari keenam. Jika pada hari kedua kita membuat File2 yang terdiri dari blok b dan link ke blok a, maka tidak terjadi apa-apa pada tanggal penghapusan yang diharapkan. Dia berdiri seperti yang dia lakukan pada hari keenam. Dan dengan demikian kami mencoba menghemat uang pada jumlah permintaan. Satu-satunya situasi di mana batas waktu dapat digeser adalah jika masa pembangkitan telah berakhir. Artinya, jika pada hari ketiga File3 baru berisi link untuk memblokir a, maka akan ditambahkan generasi 2 karena Gen1 sudah habis masa berlakunya. Dan perkiraan tanggal penghapusan blok a akan bergeser ke hari kedelapan. Hal ini memungkinkan kami mengurangi secara signifikan jumlah permintaan untuk memperpanjang masa pakai blok yang terdeduplikasi, sehingga menghemat banyak uang bagi klien.

Teknologi itu sendiri tersedia untuk pengguna perangkat keras yang kompatibel dengan S3 dan S3, yang produsennya menjamin bahwa penerapannya tidak berbeda dengan yang diterapkan Amazon. Oleh karena itu jawaban atas pertanyaan sah mengapa Azure tidak didukung - mereka memiliki fitur serupa, tetapi berfungsi pada tingkat kontainer, bukan objek individual. Omong-omong, Amazon sendiri memiliki kunci objek dalam dua mode: kepatuhan dan tata kelola. Dalam kasus kedua, masih ada kemungkinan bahwa admin terbesar di atas admin dan root di atas root, meskipun objek terkunci, masih menghapus data. Dalam hal kepatuhan, semuanya sudah terpasang erat dan tidak ada yang bisa menghapus cadangannya. Bahkan admin Amazon (menurut pernyataan resmi mereka). Ini adalah mode yang kami dukung.

Dan, seperti biasa, beberapa tautan bermanfaat:

• Tentang Blok Generasi dalam setiap detail.
• Semua informasi tentang Pencadangan & Replikasi Veeam 10 yang terbaik
• О Tingkat Kapasitas secara terperinci

Sumber: www.habr.com