Tahap Kapasiti (atau seperti yang kita panggil di dalam Vim - captir) muncul pada zaman Veeam Backup and Replication 9.5 Update 4 di bawah nama Archive Tier. Idea di sebaliknya adalah untuk membolehkan anda memindahkan sandaran yang telah jatuh daripada tetingkap pemulihan operasi yang dipanggil ke storan objek. Ini membantu mengosongkan ruang cakera untuk pengguna yang mempunyai sedikit ruang. Dan pilihan ini dipanggil Mod Alih.

Untuk melaksanakan tindakan mudah ini (seperti yang kelihatan), ia sudah cukup untuk memenuhi dua syarat: semua titik daripada sandaran yang dialihkan mestilah di luar sempadan tetingkap pemulihan operasi yang dinyatakan di atas, yang ditetapkan secara eksplisit dalam UI. Dan kedua: rantai mesti dalam apa yang dipanggil "bentuk tertutup" (rantai sandaran tertutup atau Rantai Sandaran Tidak Aktif). Iaitu, tiada perubahan berlaku dalam rantaian ini dari semasa ke semasa.

Tetapi dalam VBR v10, konsep itu telah ditambah dengan fungsi baharu - Mod Salin, Mod Dimeterai dan satu perkara dengan nama Ketidakbolehubah yang sukar disebut muncul.

Ini adalah perkara menarik yang akan kita bincangkan hari ini. Pertama, tentang cara ia berfungsi dalam VBR9.5u4, dan kemudian tentang perubahan dalam versi kesepuluh.

Dan semoga jaguh bahasa tulen memaafkan saya, tetapi terlalu banyak istilah yang tidak dapat diterjemahkan.
Jadi akan ada satu tan Anglicism di sini.
Dan banyak gif.
Dan gambar.

• Tanpa sedikit pun penyesalan. Pengarang artikel.

Seperti yang berlaku

Baiklah, mari kita mulakan dengan menganalisis tetingkap pemulihan operasi dan sandaran tertutup (atau seperti yang dipanggil dalam dokumentasi Rantaian Sandaran Tidak Aktif). Tanpa pemahaman mereka, penjelasan lanjut tidak akan dapat dilakukan.

Seperti yang kita lihat dalam gambar, kami mempunyai sejenis rantaian sandaran dengan blok data, yang terletak pada SOBR peringkat Prestasi repositori yang Tier Kapasiti disambungkan. Tetingkap sandaran operasi kami ialah tiga hari.

Sehubungan itu, .vbk yang dibuat pada hari Isnin mengelak rantai sebelumnya, yang tetingkapnya ditetapkan kepada tiga hari. Dan ini bermakna anda boleh mula mengangkut semua yang lebih lama daripada tiga hari ini ke tempat penangkapan dengan selamat.

Tetapi apakah sebenarnya yang dimaksudkan dengan rantaian tertutup dan apakah yang boleh dihantar ke julat penangkapan kapasiti dalam kemas kini 4?

Untuk Forward Incremental, tanda menutup rantai ialah penciptaan sandaran penuh baharu. Dan tidak kira bagaimana sandaran lengkap ini diperoleh: sandaran penuh sintetik dan aktif sepenuhnya dipertimbangkan.

Dalam kes Songsang, ini semua adalah fail yang tidak jatuh ke dalam tetingkap pengendalian.

Dalam kes kenaikan Forward dengan rollback, ini semua adalah rollback dan .vbk, jika terdapat .vbk lain pada tahap prestasi

Sekarang mari kita pertimbangkan pilihan untuk bekerja dengan rantaian Salinan Sandaran. Hanya item yang berada di bawah pengekalan GFS telah diangkut ke sini. Kerana semua yang disimpan dalam rantaian salinan sandaran yang lebih terkini boleh diubah dalam satu cara atau yang lain.

Sekarang mari kita lihat di bawah tudung. Di sana, proses yang dipanggil dehidrasi berlaku - meninggalkan fail sandaran kosong pada tahap dan menyeret blok dari fail ini ke julat penangkapan kapasiti. Untuk mengoptimumkan proses ini, indeks dehidrasi yang dipanggil digunakan, yang membolehkan anda mengelakkan menyalin blok yang telah disalin ke julat penangkapan kapasiti.

Mari lihat rupa perkara ini dengan contoh: Katakan kita mempunyai .vbk yang keluar daripada tetingkap transaksi dan tergolong dalam rantaian yang dimeterai. Ini bermakna kita mempunyai hak untuk mengalihkannya ke julat penangkapan kapasiti. Pada masa pemindahan, fail metadata dibuat dalam sempang kapasiti dan blok fail yang dipindahkan. Fail metadata peringkat pautan menerangkan perkara yang menghalang fail kami. Dalam kes dalam gambar, fail pertama kami terdiri daripada blok a, b, c dan metadata mengandungi pautan ke blok ini. Apabila kami mempunyai fail .vbk kedua, bersedia untuk bergerak dan terdiri daripada blok a, b dan d, kami, menganalisis indeks dehidrasi, memahami bahawa hanya blok d perlu dipindahkan. Dan fail metadatanya akan mengandungi pautan ke dua blok sebelumnya dan satu blok baharu.

Sehubungan itu, proses mengisi semula ruang kosong ini dengan data dipanggil rehidrasi. Ia sudah menggunakan indeks penghidratan semulanya sendiri, berdasarkan fail .vbk tertua pada tahap prestasi tempatan. Iaitu, jika pengguna ingin memulangkan fail daripada julat penangkapan kapasiti, kami mula-mula membuat indeks blok sandaran penuh tertua dan hanya memindahkan blok yang hilang daripada galeri penangkapan kapasiti. Dalam kes yang ditunjukkan dalam gambar, untuk menghidrat semula FullBackup1.vbk mengikut indeks rehidrasi, kita hanya memerlukan blok C, yang kita ambil dari julat penangkapan kapasiti. Jika objek awan storan berfungsi sebagai julat tangkapan kapasiti, ini membolehkan anda menjimatkan sejumlah besar wang.

Di sini nampaknya teknologi ini sama dengan yang digunakan dalam WAN Accelerators, tetapi nampaknya begitu sahaja. Dalam pemecut, penyahduplikasian adalah global; di sini, penyahduplikasian tempatan digunakan dalam setiap fail pada offset tertentu. Ini berlaku disebabkan perbezaan dalam tugas yang diselesaikan: di sini kita perlu menyalin fail sandaran penuh yang besar, dan menurut penyelidikan kami, walaupun tempoh masa yang lama berlalu di antara mereka, algoritma penyahduplikasian ini memberikan hasil yang terbaik.

Tetapi lebih banyak indeks untuk dewa indeks! Terdapat juga indeks untuk pemulihan data! Apabila kami mula memulihkan mesin yang terletak dalam sempang kapasiti, kami hanya akan membaca blok data unik yang tiada dalam sempang prestasi.

Bagaimana ia berlaku

Itu sahaja untuk bahagian pengenalan. Ia agak terperinci, tetapi seperti yang dinyatakan di atas, tanpa butiran ini tidak mungkin untuk menerangkan cara fungsi baru berfungsi. Oleh itu, tanpa berlengah lagi, mari kita beralih kepada yang pertama.

Mod salin

Ia sebahagian besarnya berdasarkan teknologi sedia ada, tetapi membawa logik penggunaan yang sama sekali berbeza. 

Tujuan mod ini adalah untuk memastikan semua data yang terletak pada tahap setempat mempunyai salinan dalam sempang kapasiti.

Jika anda membandingkan mod Alih dan Salin secara langsung, ia akan kelihatan seperti ini:

• Hanya rantai yang dimeterai boleh dialihkan. Dalam kes mod salin, benar-benar semuanya dipindahkan, tanpa mengira apa yang berlaku dalam kerja sandaran.
• Pergerakan dicetuskan apabila fail melangkaui sempadan tetingkap sandaran operasi, dan penyalinan dicetuskan sebaik sahaja fail sandaran muncul.
• Pemantauan data baharu untuk penyalinan berlaku secara berterusan, dan untuk mengalihkannya dicetuskan sekali setiap 4 jam.

Dalam mempertimbangkan mod baharu, saya mencadangkan untuk beralih daripada contoh mudah kepada yang rumit.

Dalam kes yang paling biasa, kami hanya mempunyai fail baharu dengan kenaikan, dan kami hanya menyalinnya ke julat penangkapan kapasiti. Tidak kira mod apa yang digunakan dalam kerja sandaran, tidak kira sama ada ia tergolong dalam bahagian rantaian yang dimeterai atau tidak, tidak kira sama ada tetingkap pengendalian kami telah tamat tempoh. Mereka hanya mengambilnya dan menyalinnya.

Proses di sebalik ini masih dehidrasi seperti yang diterangkan di atas. Dalam mod salin, ia juga memastikan kami tidak menyalin blok yang sudah ada pada storan kami. Satu-satunya perbezaan ialah jika dalam mod filem kami menggantikan fail sebenar dengan fail palsu, di sini kami tidak menyentuhnya dalam apa jua cara dan membiarkan segala-galanya seperti sedia ada. Jika tidak, ia adalah indeks dehidrasi yang sama, yang dengan teliti cuba menjimatkan wang dan masa anda.

Timbul persoalan - jika anda melihat UI, terdapat peluang untuk memilih kedua-dua pilihan pada masa yang sama. Bagaimanakah mod gabungan sedemikian akan berfungsi?

Katakanlah.

Permulaan adalah standard: fail sandaran dibuat dan disalin serta-merta. Kenaikan dibuat untuknya dan juga disalin. Ini berlaku sehingga saat apabila kami menyedari bahawa fail telah meninggalkan tetingkap pengendalian kami dan rantaian tertutup telah muncul. Pada ketika ini kami melakukan operasi dehidrasi dan menggantikan fail ini dengan fail palsu. Sudah tentu, kami tidak menyalin apa-apa lagi ke julat penangkapan kapasiti.

Semua logik yang menarik ini bertanggungjawab untuk hanya satu kotak pilihan dalam antara muka: Salin sandaran ke storan objek sebaik sahaja ia dibuat.

Mengapa kita memerlukan mod Salin ini?

Adalah lebih baik untuk menguraikan semula soalan dengan cara ini: apakah risiko yang kita dilindungi dengan bantuannya? Apakah masalah yang membantu kita menyelesaikannya?

Jawapannya jelas: sudah tentu, ini adalah pemulihan data. Jika kami mempunyai salinan lengkap data tempatan pada storan objek, maka tidak kira apa yang berlaku kepada produk kami, kami sentiasa boleh memulihkan data daripada fail yang terletak di Amazon bersyarat.

Jadi mari kita melalui senario yang mungkin, daripada yang paling mudah kepada yang lebih kompleks.

Nasib paling mudah yang boleh menimpa kepala kita ialah ketidakbolehcapaian salah satu fail dalam rantaian sandaran.

Kisah yang lebih menyedihkan ialah salah satu tahap repositori SOBR kami rosak.

Ia menjadi lebih teruk apabila keseluruhan repositori SOBR menjadi tidak boleh diakses, tetapi julat penangkapan kapasiti berfungsi.
Dan semuanya benar-benar buruk - ini adalah apabila pelayan sandaran mati dan keinginan pertama anda adalah untuk cuba berlari ke sempadan Kanada dalam masa sepuluh minit.

Sekarang mari kita lihat setiap situasi secara berasingan.

Apabila kita telah kehilangan satu (dan bahkan beberapa) fail sandaran, maka yang perlu kita lakukan ialah memulakan proses imbasan semula repositori, dan fail yang hilang akan digantikan dengan fail palsu. Dan menggunakan proses rehidrasi (yang dibincangkan pada awal artikel), pengguna akan dapat memuat turun data daripada julat penangkapan kapasiti ke storan tempatan.

Sekarang keadaan semakin rumit. Mari kita anggap bahawa SOBR kami terdiri daripada dua takat yang dijalankan dalam mod Prestasi, yang bermaksud bahawa .vbk dan .vib kami tersebar di atasnya dalam lapisan yang agak tidak rata. Dan pada satu ketika, salah satu takat menjadi tidak tersedia, dan pengguna perlu segera memulihkan mesin, sebahagian daripada datanya terletak tepat pada tahap ini.

Pengguna melancarkan wizard pemulihan, memilih titik yang ingin dipulihkan, dan wizard, semasa bekerja, menyedari bahawa dia tidak mempunyai semua data yang diperlukan untuk pemulihan secara setempat dan oleh itu perlu dimuat turun dari penangkapan kapasiti galeri. Pada masa yang sama, blok yang kekal pada storan tempatan tidak akan dimuat turun daripada awan. Kemuliaan kepada indeks pemulihan (ya, ia juga disebut pada permulaan artikel).

Subjenis kes ini ialah keseluruhan repositori SOBR menjadi tidak boleh diakses. Dalam kes ini, kami tidak mempunyai apa-apa untuk disalin daripada storan tempatan, dan semua blok dimuat turun daripada awan.

Dan situasi yang paling menarik ialah pelayan sandaran mati. Terdapat dua pilihan di sini: pentadbir hebat dan membuat sandaran konfigurasi, dan pentadbir ialah Pinocchio yang jahat sendiri dan tidak membuat sandaran konfigurasi.

Dalam kes pertama, sudah cukup untuk dia hanya menggunakan pemasangan bersih VBR di suatu tempat dan memulihkan pangkalan datanya dari sandaran menggunakan cara standard. Pada akhir proses ini, semuanya akan kembali normal. Atau ia akan dipulihkan mengikut salah satu senario di atas.

Tetapi jika pentadbir sama ada musuhnya sendiri, atau sandaran konfigurasi juga mengalami kegagalan epik, maka di sini pun kita tidak akan menyerahkannya kepada belas kasihan nasib. Untuk kes ini, kami telah memperkenalkan prosedur baharu yang dipanggil Import Object Storage. Ia membolehkan anda melangkau proses mencipta semula repositori SOBR secara manual dan melampirkan julat penangkapan kapasiti padanya dengan imbasan semula seterusnya, dan hanya menambah objek storan pada antara muka Vim dan menjalankan prosedur Repositori Storan Import. Satu-satunya perkara yang boleh menghalang antara anda dan sandaran anda ialah permintaan untuk memasukkan kata laluan jika sandaran anda disulitkan.

Ini mungkin semua tentang Mod Salin dan kita teruskan

Mod Termeterai

Idea utama ialah sandaran baharu tidak boleh muncul pada tahap SOBR yang dipilih bagi repositori. Sebelum v10, kami hanya mempunyai Mod Penyelenggaraan, apabila sebarang kerja dengan repositori dilarang sepenuhnya. Semacam mod tegar untuk menutup storan, di mana hanya butang Evacuate tersedia, yang mengangkut sandaran ke tahap yang lain sekali.

Dan mod Sealed adalah sejenis pilihan "lembut": kami melarang penciptaan sandaran baharu dan secara beransur-ansur memadamkan yang lama mengikut pengekalan yang dipilih, tetapi dalam proses itu kami tidak kehilangan keupayaan untuk memulihkan dari titik yang disimpan. Perkara yang sangat berguna apabila kita sama ada mempunyai sekeping perkakasan yang menghampiri penghujung hayatnya dan perlu menggantikannya, atau kita hanya perlu membebaskannya untuk sesuatu yang lebih penting, tetapi tiada tempat untuk mengambilnya dan mengalihkan semuanya sekaligus. Atau ia tidak boleh dipadamkan.

Sehubungan itu, prinsip operasi agak mudah: adalah perlu untuk melarang semua operasi tulis (kemunculan data baharu), meninggalkan bacaan (pemulihan) dan padam (pengekalan).

Kedua-dua mod boleh digunakan serentak, tetapi perlu diingat bahawa Penyelenggaraan mempunyai keutamaan yang lebih tinggi.

Sebagai contoh, pertimbangkan SOBR yang terdiri daripada dua tahap. Mari kita anggap bahawa untuk empat hari pertama kami mencipta sandaran dalam mod Penambahan Forward Forever, dan kemudian kami mengelak takat itu. Ini membawa kepada fakta bahawa kami memulakan penciptaan penuh aktif baharu pada tahap kedua yang tersedia. Jika pengekalan kita adalah empat, maka apabila seluruh rantai yang terletak pada tahap yang dimeteraikan melampaui batasnya, ia dihapuskan dengan hati nurani yang bersih.

Terdapat situasi apabila pemadaman berlaku lebih awal. Sebagai contoh, ini ialah penambahan ke hadapan dengan penuh berkala. Jika kami membuat sandaran penuh untuk dua hari pertama, dan pada hari Khamis kami memutuskan untuk menutup repositori, maka pada hari Jumaat, apabila sandaran baharu dibuat, fail untuk hari Isnin akan dipadamkan kerana tiada kebergantungan pada tahap ini. Dan perkara itu sendiri tidak bergantung pada sesiapa. Kemudian kita tunggu sehingga empat mata dicipta pada tahap yang tersedia dan padamkan baki tiga, yang tidak boleh dipadamkan secara berasingan antara satu sama lain.

Perkara lebih mudah dengan Reverse Incremental. Di dalamnya, mata tertua tidak bergantung pada apa-apa dan boleh dipadamkan dengan selamat. Oleh itu, sebaik sahaja .vbk baharu dicipta pada tahap baharu, .vrbs lama akan dipadamkan satu demi satu.

Ngomong-ngomong, mengapa kita mencipta .vbk baharu setiap kali: jika kita tidak menciptanya, tetapi meneruskan rantaian kenaikan lama, maka .vbk lama akan membeku untuk masa yang tidak terhingga dalam mana-mana mod, menghalang pemadamannya. Oleh itu, telah diputuskan bahawa sebaik sahaja tahap dimeterai, kami membuat sandaran penuh pada tahap percuma.

Perkara lebih rumit dengan julat penangkapan kapasiti.

Mari kita lihat mod salin dahulu. Katakan bahawa kami secara aktif membuat sandaran selama empat hari, dan kemudian julat penangkapan kapasiti telah dimeterai. Kami tidak memadamkan apa-apa, tetapi dengan rendah hati menahan pengekalan, selepas itu kami memadamkan data daripada julat penangkapan kapasiti.

Kira-kira perkara yang sama berlaku dalam mod bergerak - kami menunggu retouch, padam yang lama dalam storan tempatan, dan padam yang disimpan dalam storan objek.

Contoh yang menarik dengan penambahan ke hadapan Forever. Kami memasang pengekalan pada tiga titik dan mula membuat sandaran pada hari Isnin, yang kerap disalin ke awan. Selepas menutup storan, sandaran terus dibuat, mengekalkan tiga mata, tetapi data yang disimpan dalam sempang kapasiti tetap bergantung dan tidak boleh dipadamkan. Oleh itu, kami menunggu sehingga Khamis, apabila .vbk kami melampaui pengekalan, dan barulah kami memadamkan keseluruhan rantaian yang disimpan dengan tenang.

Dan penafian kecil: semua contoh di sini ditunjukkan dengan satu mesin. Jika anda mempunyai beberapa daripadanya dalam sandaran anda, maka ubah suai mereka akan berbeza bergantung pada sama ada Active Full telah dibuat atau tidak.

Itu pada dasarnya semua yang ada padanya. Jadi mari kita beralih kepada ciri yang paling tegar -

Ketidakkekalan

Seperti perkara sebelumnya, perkara pertama ialah masalah yang diselesaikan oleh fungsi ini. Sebaik sahaja kami memuat naik sandaran kami di suatu tempat untuk penyimpanan, terdapat keinginan yang kuat untuk menjamin keselamatan mereka, iaitu, untuk melarang pemadaman secara fizikal dan sebarang pengubahsuaian semasa pengekalan tertentu. Termasuk pentadbir, termasuk di bawah akaun akar mereka. Ini membolehkan anda melindungi mereka daripada kerosakan yang tidak disengajakan atau disengajakan. Sesiapa sahaja yang bekerja dengan AWS mungkin telah menemui ciri serupa yang dipanggil Object Lock.

Sekarang mari kita lihat mod secara umum, dan kemudian menyelidiki butirannya. Dalam contoh kami, Ketidakbolehubahan akan didayakan untuk julat penangkapan kapasiti kami dengan pengekalan selama empat hari. Dan mod Salin didayakan dalam sandaran.

Ketidakbolehubah tidak berinteraksi dengan pengekalan umum dalam apa jua cara. Sebagai contoh, ia tidak menambah mata tambahan atau apa-apa seperti itu. Cuma seseorang itu tidak boleh memadamkan fail sandaran dalam masa empat hari. Jika anda membuat sandaran pada hari Isnin, anda hanya akan dapat memadamkan failnya pada hari Jumaat.

Semua konsep dehidrasi, indeks dan metadata yang dijelaskan sebelum ini terus berfungsi dengan sama. Tetapi dengan satu syarat - blok ditetapkan bukan sahaja untuk data, tetapi juga untuk metadata. Ini dilakukan sekiranya penyerang licik memutuskan untuk memadam pangkalan data metadata kami dan untuk menghalang blok data daripada bertukar menjadi bubur binari yang tidak berguna.

Sekarang adalah masa yang sesuai untuk menerangkan teknologi penjanaan blok kami. Atau penjanaan blok. Untuk melakukan ini, pertimbangkan keadaan yang membawa kepada penampilannya.

Mari kita ambil skala masa enam hari dan ke bawah kita akan menandakan masa tamat tempoh ketakbolehubah yang dijangkakan. Pada hari pertama kami mengambil dan mencipta fail yang terdiri daripada blok data a dan metadatanya. Jika kebolehubahan ditetapkan kepada tiga hari, adalah logik untuk mengandaikan bahawa pada hari keempat data akan dibuka kunci dan dipadamkan. Pada hari kedua kami akan menambah fail2 baru, terdiri daripada blok b dengan tetapan yang sama. Sekat a masih perlu dialih keluar pada hari keempat. Tetapi pada hari ketiga sesuatu yang mengerikan berlaku - fail File3 dicipta, yang terdiri daripada blok baru d dan pautan ke blok lama a. Ini bermakna bahawa untuk blok dan bendera kebolehubahannya mesti ditetapkan semula kepada tarikh baharu, yang dialihkan ke hari keenam. Dan di sini masalah timbul - dalam sandaran sebenar terdapat sejumlah besar blok tersebut. Dan untuk memanjangkan tempoh kebolehubahannya, anda perlu membuat sejumlah besar permintaan setiap kali. Dan sebenarnya, ini akan menjadi proses harian yang hampir tidak berkesudahan, kerana dengan tahap kebarangkalian yang tinggi, kita akan menemui timbunan blok yang dinyahduplikasi yang besar dengan setiap salinan. Apakah maksud sejumlah besar permintaan daripada pembekal storan objek? Betul! Bil besar pada hujung bulan.

Dan untuk tidak secara tiba-tiba mendedahkan pelanggan kegemaran anda untuk wang yang banyak, mekanisme penjanaan blok telah dicipta. Ini adalah tempoh tambahan yang kami tambahkan pada tempoh kebolehubah yang ditetapkan. Dalam contoh di bawah, tempoh ini ialah dua hari. Tetapi ini hanya contoh. Pada hakikatnya, mereka menggunakan formula mereka sendiri, yang memberikan kira-kira sepuluh hari tambahan semasa kunci bulanan.

Mari kita terus mempertimbangkan situasi yang sama, tetapi dengan penjanaan blok. Pada hari pertama kami mencipta fail1 daripada blok a dan metadata. Kami menjumlahkan tempoh penjanaan dan kebolehubah - ini bermakna peluang untuk memadam fail adalah pada hari keenam. Jika pada hari kedua kami mencipta File2, yang terdiri daripada blok b dan pautan untuk menyekat a, maka tiada apa yang berlaku pada tarikh pemadaman yang dijangkakan. Dia berdiri seperti yang dia lakukan pada hari keenam. Dan dengan itu kami cuba menjimatkan wang pada bilangan permintaan. Satu-satunya keadaan apabila tarikh akhir boleh dialihkan ialah jika tempoh penjanaan telah tamat. Iaitu, jika pada hari ketiga File3 baharu mengandungi pautan untuk menyekat a, maka generasi 2 akan ditambah memandangkan Gen1 telah pun tamat tempoh. Dan tarikh jangkaan untuk memadamkan blok a akan beralih ke hari kelapan. Ini membolehkan kami mengurangkan secara mendadak bilangan permintaan untuk memanjangkan hayat blok nyahduplikasi, yang menjimatkan banyak wang pelanggan.

Teknologi itu sendiri tersedia untuk pengguna perkakasan serasi S3 dan S3, yang pengeluarnya menjamin bahawa pelaksanaannya tidak berbeza daripada Amazon. Oleh itu jawapan kepada soalan yang sah mengapa Azure tidak disokong - mereka mempunyai ciri yang sama, tetapi ia berfungsi pada tahap bekas, bukan objek individu. By the way, Amazon sendiri mempunyai kunci objek dalam dua mod: pematuhan dan tadbir urus. Dalam kes kedua, masih terdapat kemungkinan bahawa pentadbir terhebat di atas pentadbir dan akar di atas akar, walaupun dikunci objek, masih memadamkan data. Dalam kes pematuhan, segala-galanya dipaku dengan ketat dan tiada siapa boleh memadamkan sandaran. Malah pentadbir Amazon (mengikut kenyataan rasmi mereka). Ini adalah mod yang kami sokong.

Dan, seperti biasa, beberapa pautan berguna:

• pada Penjanaan Blok dalam setiap perincian.
• Semua maklumat tentang Sandaran & Replikasi Veeam 10 yang terbaik
• О Peringkat Kapasiti dalam butiran

Sumber: www.habr.com