Dalam artikel sebelumnya, kami memberi tahu Anda tentang fitur baru dalam rilis Pembaruan 4 untuk Veeam Backup & Replication 9.5 (VBR), dirilis pada Januari, di mana cadangan pada pita magnetik tidak disebutkan secara sadar. Kisah tentang daerah ini layak mendapat artikel terpisah, karena sebenarnya ada banyak fitur baru.

- QA guys, menulis artikel?
- Kenapa tidak!

Tape Drives di Abad ke-21

Penyimpanan data pada pita magnetik (kaset, jepit , seperti yang kita sebut dalam R&D) tidak terbatas pada komputer ZX-Spectrum, yang merupakan sesuatu dari masa lalu, satu permainan yang dapat dimuat ke dalam RAM 48 kb dari kaset kaset selama beberapa menit. Selama seperempat abad, kecepatan dan kapasitas kaset meningkat sebesar 6-7 kali lipat. Perbandingan ini tidak sepenuhnya benar, dan standar KPP tidak sejalan dengan hukum Moore . Namun demikian, teknologi modern memungkinkan perekaman 12 terabyte data pada pita kilometer rekaman (hingga 30 terabyte dalam mode kompresi), sehingga drive 160-dolar membuat pesaing tertinggal dalam biaya penyimpanan jangka panjang dari sejumlah besar data, bahkan dengan mempertimbangkan investasi dalam peralatan rekaman / baca. Data pada kaset semacam itu disimpan dengan andal selama 15-30 tahun.

Saya akan datang dari sisi lain. Virus Ransomware telah mencapai tingkat baru baru-baru ini. Mereka dapat menunggu waktu di infrastruktur perusahaan besar selama berminggu-minggu dan berbulan-bulan, dan dengan munculnya kerentanan nol hari, mereka dapat menghancurkan (bukan tanpa bantuan manusia, karena banyak uang dipertaruhkan) tidak hanya semua data, tetapi juga semua cadangan yang dapat dihubungi . Berikut adalah contoh baru ketika perusahaan harus membayar ransomware. Celah udara yang disebut, yaitu cadangan yang secara fisik terisolasi dari infrastruktur, menjadi, pada kenyataannya, satu-satunya penyelamatan yang dapat diandalkan dari cerita-cerita semacam itu. Pita magnetik di sini adalah salah satu solusi abadi.



Tapi satu spesifikasi dan teknologi hal baru besi dan barium-ferit dari produsen terkemuka (IBM, HPE, Oracle, Dell) untuk perlindungan data yang dapat diandalkan tidak cukup, Anda memerlukan perangkat lunak yang baik. Di Veeam, seluruh tim kami terlibat dalam backup tape, sekitar 10 orang menganalisis, merencanakan, meneliti, mengembangkan, dan menguji setiap hari. Anda bisa melihat hasil karya ini di artikel sebelumnya ( satu , dua ). Apa yang telah dilakukan selama setahun terakhir?

Glosarium

Ada pilihan antara kebebasan dalam kaitannya dengan bahasa asli dan memperumit keterbacaan klerikalisme. Saya lebih suka yang pertama, jadi saya minta maaf sebelumnya jika seseorang mengucapkan kata-kata dari daftar di bawah ini akan menyakiti mata. Di sini saya akan mengingat secara singkat apa arti istilah tertentu.

Penyewa untuk rekaman. Penyedia Terlindungi - Klien Dilindungi

Segera kartu truf di atas meja. Fitur paling ambisius dari pembaruan kami, yang dirancang untuk penyedia cloud yang menggunakan VBR dalam infrastruktur mereka. Pembangunan dimulai dua tahun lalu. Segera kami menyadari bahwa kami tidak akan punya waktu untuk menangani tugas serius untuk rilis berikutnya, mengambil jeda singkat, dan akhirnya merilis fitur di 9.5 Update 4.

Singkatnya, sekarang penyedia memiliki kesempatan untuk menyalin cadangan pelanggan mereka ke kaset menggunakan pekerjaan pita di kumpulan GFS. Ini memberi penyedia - dan ini adalah orang-orang yang sangat besar yang kami sayangi dan departemen komersial - dua kemungkinan:

• melindungi klien Anda (penyewa, penyewa - penyewa) dari kehilangan data sebagai akibat dari penghapusan yang tidak disengaja atau masalah infrastruktur ("banjir di ruang server");
• memberikan penyewa dengan layanan tambahan untuk mengembalikan data dari cadangan lama, yang telah lama dihapus dari penyimpanan cloud sesuai dengan kebijakan penyimpanan data, tetapi tetap pada kaset.

Dari sudut pandang pemasaran, fungsinya sangat "enak", dari kita - tidak kalah sulit untuk diimplementasikan.

Pengembangan

Masalah utama yang dihadapi adalah enkripsi data. Sebagian besar cadangan cloud dienkripsi, statistik mengatakan tentang ⅔ dari total. Bagi kami, angka ini mengejutkan, diasumsikan bahwa hampir semuanya terenkripsi, tetapi tidak - banyak pelanggan yang tampaknya percaya diri tanpa syarat dalam penyedia mereka.

Paradigma ini sederhana: penyedia tidak harus dapat mendekripsi data penyewa. Pada saat yang sama, dalam kerangka fitur baru, diperlukan di sisi penyedia untuk membuka penyimpanan dengan cadangan. Ini diperlukan untuk mentransfer blok data, misalnya, untuk membuat cadangan penuh virtual . Hal utama adalah melakukan ini terlepas dari penyewa, ketika kunci yang diperlukan tidak dikirimkan ke penyedia selama pelaksanaan pekerjaan.

Solusi untuk masalah ini, digunakan, secara tidak sengaja, dalam fitur utama lain dari add-on yang dirilis - Kapasitas Tingkat - terdiri dalam menambahkan kunci enkripsi tambahan. Kunci arsip (kunci arsip) disimpan dalam database penyedia dalam bentuk terenkripsi. Menurut skema rumit di sisi penyedia, ini dapat digunakan untuk membuka toko, memindahkan, dan mengenkripsi ulang blok data di antara toko-toko (setelah semua, masing-masing memiliki kunci sendiri), tetapi data itu sendiri tidak dapat didekripsi.


^{Skema rumit (versi kerja)}

Saya menambahkan bahwa semua insinyur di R&D sangat menyukai enkripsi dalam produk kami, namun, tidak ada yang tahu secara detail cara kerjanya. (Masih ada lelucon "dan mengapa itu bekerja sama sekali," tetapi editor tidak melewatkannya.)

Pengujian

Ratusan bug dicatat pada fitur ini. Area yang paling sulit adalah enkripsi, antarmuka pengguna, masalah dengan pemulihan.

Dari sudut pandang pengujian, variabilitas besar mewakili "kombinatorik" dari jenis dan jenis pekerjaan penyewa dan repositori - maksud saya baik sumber dan target ketika mengembalikan cadangan ke infrastruktur. Semua ini tergantung pada logika dalam kerangka model GFS (termasuk yang baru - paralelisme dan set media harian, lebih lanjut tentang ini di bawah), dan, secara keseluruhan, pada cloud spesifik yang tidak biasa untuk teip. Ingatlah untuk membumbui dengan banyak enkripsi. Untuk melanjutkan metafora, kami makan banyak hidangan ini - tetapi juga mencicipinya dari semua sisi.


^{Fragmen dari rencana pengujian}

Hasilnya

Penjelasan terperinci dapat ditemukan di manual user (sejauh ini dalam bahasa Inggris): cadangan , pemulihan . Saya akan membahas poin-poin utama.

Cadangkan

Penyedia menambahkan penyewa ke pekerjaan teip dengan kolam GFS sebagai target. Jika ada lisensi cloud di langkah kedua wizard, opsi Penyewa tersedia. Anda dapat menambahkan semua penyewa sekaligus atau secara terpisah, atau Anda hanya dapat memilih kuota yang terpisah (tetapi bukan subquot) dari penyewa individu. Anda tidak dapat mencampur cadangan penyewa dan cadangan lokal biasa dalam pekerjaan yang sama.



Sisa tincture hampir sepenuhnya identik dengan pekerjaan biasa di kumpulan GFS.

Pemulihan data dimungkinkan baik di sisi penyedia, dan di sisi penyewa sendiri.

Pemulihan sisi penyedia

Dilakukan melalui penyihir baru. Di sini Anda sudah dapat pergi ke pekerjaan yang terpisah, seluruh rantai yang ada di repositori pada hari tertentu dipulihkan.



Ada tiga pilihan restoran:

1. Di lokasi asli. Dalam hal ini, cadangan asli, jika ada, dihapus; pekerjaan penyewa secara otomatis dikonfigurasi ulang ke rantai yang dipulihkan. Dipahami bahwa pemulihan seperti itu umumnya tidak akan terlihat oleh klien, hanya untuk waktu yang singkat akan diputuskan dari repositori cloud.
2. Ke dalam kuota / repositori baru. Penyedia dapat, misalnya, membuat akun sementara yang terpisah untuk tujuan ini, yang kemudian akan dihapus. Cadangan muncul di infrastruktur penyewa setelah sinkronisasi dengan database penyedia.
3. Tepat di drive server Linux atau Windows yang terdaftar di infrastruktur penyedia. Selanjutnya, rantai ini dapat direkam pada flash drive dan mengirim penyewa.

Pemulihan Tenant

Opsi ini menyiratkan bahwa klien memiliki infrastruktur jaringan sendiri dan sejumlah besar data untuk restoran. Penyedia secara fisik dapat mengirim rekaman dengan backup yang direkam kepada pelanggan dengan layanan pengiriman, ia katalog di peralatannya, mendekripsi kaset dan backup dan bekerja dengan backup seolah-olah dia sendiri yang menulisnya di kaset. Ini adalah hack kehidupan untuk tidak mengunduh terabyte di WAN.

Peningkatan skala besar ke kumpulan GFS

Kelompok media GFS muncul di VBR dua tahun lalu, dalam versi 9.5. Dalam pembaruan terbaru, baik sehubungan dengan penampilan fitur Tenant to tape, dan atas permintaan pengguna, kami memompa fungsi ini dengan baik.

Set Media Harian

Satu set media harian baru telah muncul. Sekarang di kumpulan GFS Anda dapat menyimpan cadangan untuk setiap hari, dan tidak hanya lengkap, tetapi juga inkremental. Yang terakhir mengambil ruang jauh lebih sedikit, dan ini dilakukan untuk menghemat rekaman. Dipahami bahwa kaset-kaset ini terus diputar di perpustakaan, tidak diangkut ke penyimpanan jarak jauh. Pada saat yang sama, untuk restoran dari titik tambahan, Anda perlu kaset dari salah satu set media senior (mingguan, bulanan, triwulanan, atau tahunan). Tidak mungkin untuk menghidupkan set media harian tanpa memasukkan yang mingguan sehingga dalam kebanyakan kasus akan mengambil kaset mingguan untuk memulihkan dari salinan tambahan. Mereka selalu berada di perpustakaan, atau disimpan di gudang yang tidak terlalu jauh.



Logika untuk bekerja dengan pekerjaan rekaman di kumpulan media GFS bukanlah yang termudah , penulis teknis tidak akan membiarkan Anda berbohong. Jika singkatnya, mengabaikan detail, hanya cadangan lengkap (termasuk cadangan lengkap virtual) yang disalin ke perangkat media mingguan dan senior, satu untuk setiap tanggal, dan ke cadangan harian semua cadangan yang ada di dalam repositori untuk hari ini, karena cadangan - Pekerjaan dapat dimulai lebih dari sekali sehari.

Konkurensi, mulai waktu, dan tunggu di kumpulan GFS

Sekarang perekaman paralel dari beberapa rantai atau bekerja pada beberapa drive perpustakaan juga dimungkinkan dalam kumpulan media GFS (sebelumnya - hanya dalam biasa). Ini termasuk dalam langkah Opsi pada kumpulan media.



Klarifikasi penting : file yang sama selalu ditulis ke aliran yang sama, oleh karena itu, dalam kasus beberapa mesin virtual besar, disarankan untuk mengaktifkan konfigurasi per-VM pada repositori sehingga cadangan terdiri dari beberapa rantai.

Selain itu, menjadi mungkin untuk memilih waktu mulai pekerjaan GFS itu sendiri . Banyak pengguna tidak suka memulai pada tengah malam dan kemudian menunggu hampir sepanjang hari sampai pekerjaan sumber berakhir. Sekarang waktu ini dapat diatur, misalnya, pada sore hari, ketika sudah ada sesuatu untuk disalin ke kaset. Selain itu, atas permintaan pengguna, kami menempatkan dalam pengaturan lanjutan opsi yang sebelumnya hanya dapat diaktifkan menggunakan kunci registri. Cukup dengan memilih Memproses titik pemulihan terbaru alih-alih menunggu - dan apa yang ada dalam repositori pada saat dimulainya pekerjaan rekaman (titik untuk kemarin, misalnya) disalin ke kaset, tidak ada menunggu sama sekali.

Pekerjaan yang ditingkatkan dengan banyak perpustakaan

Ini akan menjadi situasi ketika lebih dari satu perpustakaan ditambahkan ke satu kumpulan media. Kami mendukung ini sebelumnya, tetapi dari waktu ke waktu klien datang dengan keluhan tentang perilaku yang tidak dapat diprediksi.

Apakah

Misalnya, pekerjaan rekaman dimulai, butuh dua drive di perpustakaan pertama, tetapi pengaturan konkurensi memungkinkannya untuk menggunakan 4 drive sekaligus. Haruskah pekerjaan ini beralih ke perpustakaan kedua dari kumpulan media dan menggunakannya juga, atau akankah ini menjadi pemborosan sumber daya?

Kasus lain. Pilihan dipilih untuk beralih dengan syarat "tidak ada kaset yang tersedia", di perpustakaan pertama hanya ada satu kaset, tetapi semua data berpotensi ditempatkan di dalamnya. Namun, pengaturan ini memungkinkan Anda untuk menulis secara paralel pada dua kaset. Haruskah perpustakaan kedua terlibat dalam kasus ini?

Kami memutuskan untuk menertibkan area ini, sehingga memungkinkan untuk menyesuaikan perilaku secara eksplisit.

Telah menjadi

Perpustakaan di kumpulan media muncul peran - aktif dan pasif . Dan kumpulan media itu sendiri memiliki dua mode: gagal-aman, atau gagal dan paralel . Sekarang, tergantung pada persyaratannya, Anda dapat mengonfigurasi kumpulan media dengan berbagai cara.

• Jika Anda memiliki beberapa pustaka peer dan Anda perlu memparalelkan rekaman di dalamnya, nyalakan mode perekaman paralel, untuk ini semua pustaka perlu diberi peran aktif. Dalam hal ini, kaset dan drive baru akan segera diaktifkan, segera setelah kebutuhan muncul, terlepas dari perpustakaan mana mereka berada. Masih ada prioritas - pertama, kami akan mencoba mencari sumber daya di perpustakaan yang terletak lebih tinggi dalam daftar.
• Jika ada satu perpustakaan utama dan satu drive tua atau standar dalam cadangan, aktifkan mode feylover dengan menempatkan perpustakaan utama di bagian atas daftar dan memilih peran pasif untuk perangkat cadangan. Beralih ke perangkat semacam itu hanya akan terjadi jika pekerjaan itu benar-benar diperlukan, setidaknya entah bagaimana caranya. Situasi ini akan dianggap abnormal, yang akan dikirimi pemberitahuan melalui surat.

Ada situasi yang lebih rumit yang belum kami dukung - beberapa perpustakaan aktif dengan yang pasif. Umpan balik akan menunjukkan apakah ada kebutuhan untuk konfigurasi seperti itu dan apakah perlu untuk "menyelesaikan" fitur di masa depan. Praktik standar.

Dukungan WORM

WORM - Write Once Read Many - kaset yang tidak dapat dihapus atau ditimpa pada tingkat besi hanya dapat menambahkan data. Penggunaan wajib mereka diatur oleh aturan beberapa organisasi, misalnya, mereka yang bekerja di bidang kedokteran. Masalah utama dengan kaset seperti itu adalah bahwa VBR, ketika mengambil inventaris atau membuat katalog, mencatat judul yang tidak bisa lagi dihapus, dan pekerjaan kaset jatuh dengan kesalahan selama upaya tersebut.

Di 9,5 Pembaruan 4, dukungan penuh untuk kaset tersebut diimplementasikan. Menambahkan kumpulan media-WORM, reguler dan GFS, di mana Anda hanya dapat menempatkan kaset jenis ini.



Kaset baru memiliki ikon biru, "beku". Dari sudut pandang pengguna, bekerja dengan kaset WORM tidak berbeda dengan bekerja dengan yang biasa.

"Umpan" kaset pada awalnya ditentukan oleh akhiran kode batang , jika kode batangnya teratur atau tidak dapat dibaca, drive memberikan informasi saat kartrid dimasukkan pertama kali. Tempatkan kaset WORM di kolam media biasa dan tulis padanya tidak akan berfungsi. Dari lucu: sudah ada pengguna yang menempelkan barcode-WORM pada kaset biasa dan terkejut dengan perubahan infrastruktur mereka setelah pembaruan.

Chip cartridge

Seiring dengan diperkenalkannya kaset yang tidak dapat ditulis ulang, mereka mulai bekerja dengan chip tersebut . Kami tidak menggunakan atribut standar dalam chip sebelumnya, sekarang kami menulis dan membaca beberapa di antaranya, tetapi kami tidak menganggapnya sebagai sumber data utama. Pedoman utama masih judul kaset. Keputusan ini ternyata benar: setelah sebulan setelah rilis kami melihat bagaimana "kebun binatang" besi pengguna membawa kejutan dalam hal bekerja dengan chip.

Rekam cadangan volume NDMP

Kesimpulannya, tentang fitur yang paling diminta oleh jumlah ulasan dari Pembaruan ini. Cadangan volume NDMP ke kaset tersedia. Penting untuk menambahkan server NDMP ke infrastruktur VBR, setelah itu dimungkinkan untuk memilih volume dari host ini dalam pekerjaan file teip. Mereka jatuh pada kaset dalam bentuk file dengan atribut khusus untuk membedakan mereka dari katalog yang biasa.



Dalam implementasi pertama, ada batasan-batasan tertentu: ekstensi tidak didukung, ditambah cadangan dan pengembalian hanya volume penuh, tetapi bukan file individual, dimungkinkan. Pencadangan bekerja melalui dump (dalam hal NetApp - ufsdump ), ada beberapa kekhasan: jumlah maksimum poin tambahan adalah 9, setelah itu pencadangan penuh dipaksakan.

Kesimpulannya

Ini hanya inovasi terbesar di bidang backup ke tape di VBR 9.5 Update 4. Perubahan lain tercantum di bawah ini:

• kemampuan untuk mengatur urutan sumber pekerjaan dan file dalam pekerjaan rekaman;
• peran Operator Pita telah ditambahkan (pengguna dapat melakukan segalanya kecuali memulihkan dari pita - ada Operator Pemulihan untuk ini);
• Menambahkan topeng sertakan / kecualikan lengkap dalam pekerjaan rekaman file (kecuali untuk NDMP);
• pemulihan dalam pekerjaan file teip ditingkatkan (folder dipulihkan dengan file-file yang ada di sana pada saat cadangan, dan tidak dengan semua yang ada di dalamnya dalam sejarah cadangannya - omong-omong, fitur yang sangat populer);
• meningkatkan kecepatan pemulihan sejumlah besar file dari kaset;
• algoritma untuk memilih rekaman berikutnya untuk rekaman telah ditingkatkan, khususnya, ceteris paribus kami memperhitungkan jumlah data yang ditulis / dibaca sepanjang hidupnya, kami ambil yang terbaru;
• peningkatan stabilitas produk.

Tautan yang bermanfaat

Untuk perubahan, saya akan memberikan beberapa tautan ke sumber daya berbahasa Rusia:

• Unduh Percobaan untuk Pembaruan VBR 9.5 4
• Artikel tentang Habr "Kiat berguna untuk mengarsipkan cadangan Veeam ke pita magnetik"
• Artikel tentang Habr "7 tips berguna untuk melindungi cadangan dari virus kriptografi"
• Bagian utama panduan pengguna (dalam bahasa Inggris)
• Nah, video ulasan “Cara kerjanya” (meskipun dalam bahasa Inggris sejauh ini) telah kembali ke tempat asalnya - Anda dapat menontonnya di sini . Teiping dijelaskan pada slide 95 - 102.