Kapasite Katmanı (veya Vim'de adlandırdığımız şekliyle - captir), Veeam Backup and Replication 9.5 Güncelleme 4 zamanında Archive Tier adı altında ortaya çıktı. Bunun arkasındaki fikir, operasyonel geri yükleme penceresi adı verilen pencerenin dışında kalan yedeklerin nesne depolama alanına taşınmasını mümkün kılmaktır. Bu, çok az disk alanına sahip olan kullanıcılar için disk alanının temizlenmesine yardımcı oldu. Ve bu seçeneğe Hareket Modu adı verildi.

Bu basit (göründüğü gibi) eylemi gerçekleştirmek için iki koşulun karşılanması yeterliydi: Taşınan yedeklemedeki tüm noktalar, kullanıcı arayüzünde açıkça ayarlanan yukarıda belirtilen operasyonel geri yükleme penceresinin sınırlarının dışında olmalıdır. İkincisi: Zincir "mühürlü formda" (mühürlü yedekleme zinciri veya Etkin Olmayan Yedekleme Zinciri) olmalıdır. Yani zaman içerisinde bu zincirde herhangi bir değişiklik meydana gelmez.

Ancak VBR v10'da konsept yeni işlevlerle desteklendi - Kopyalama Modu, Mühürlü Mod ve telaffuz edilmesi zor olan Değişmezlik adı verilen bir şey ortaya çıktı.

Bunlar bugün konuşacağımız büyüleyici şeyler. Öncelikle VBR9.5u4'te nasıl çalıştığı ve ardından onuncu versiyondaki değişiklikler hakkında.

Saf dilin savunucuları beni bağışlasın ama çevrilemeyen çok fazla terim var.
Yani burada bir ton İngilizizm olacak.
Ve bir sürü gif.
Ve resimler.

• En ufak bir pişmanlık duymadan. Makalenin yazarı.

Olduğu gibi

Peki, operasyonel geri yükleme penceresini ve mühürlü yedeklemeyi (veya Etkin Olmayan Yedekleme Zinciri belgelerinde adlandırıldığı şekliyle) analiz ederek başlayalım. Onların anlayışı olmadan daha fazla açıklama mümkün olmayacaktır.

Resimde gördüğümüz gibi Kapasite Tier'in bağlı olduğu repository'nin Performance Tier SOBR'sinde yer alan veri bloklu bir çeşit yedekleme zincirimiz var. Operasyonel yedekleme penceremiz üç gündür.

Buna göre Pazartesi günü oluşturulan .vbk, penceresi üç güne ayarlanan önceki zinciri mühürliyor. Bu da, bu üç günden daha eski olan her şeyi atış poligonuna güvenle taşımaya başlayabileceğiniz anlamına gelir.

Peki mühürlü zincirle tam olarak ne kastedildi ve 4. güncellemede kapasiteli atış poligonuna ne gönderilebilir?

İleri Artımlı için zinciri mühürlemenin bir işareti, yeni bir tam yedeklemenin oluşturulmasıdır. Ve bu tam yedeklemenin nasıl elde edildiği önemli değildir: hem sentetik tam hem de aktif tam yedeklemeler dikkate alınır.

Tersine çevirme durumunda, bunların tümü işletim penceresine girmeyen dosyalardır.

Geri almalarla ileriye doğru artış durumunda, bunların tümü geri almalar ve performans kapsamında başka bir .vbk varsa .vbk'dir.

Şimdi Yedek Kopya zincirleriyle çalışma seçeneğini ele alalım. Buraya yalnızca GFS saklama kapsamına giren öğeler taşındı. Çünkü daha yeni yedek kopya zincirlerinde saklanan her şey bir şekilde değiştirilebilir.

Şimdi kaputun altına bakalım. Orada, dehidrasyon adı verilen bir işlem meydana gelir - kapsamda boş yedekleme dosyaları bırakılır ve bu dosyalardan bloklar kapasite çekim aralığına sürüklenir. Bu süreci optimize etmek için, kapasite atış poligonuna önceden kopyalanmış blokların kopyalanmasını önlemenizi sağlayan dehidrasyon indeksi kullanılır.

Bir örnekle bunun neye benzediğine bakalım: Diyelim ki, işlem penceresinden çıkan ve mühürlü bir zincire ait olan bir .vbk'miz var. Bu, onu kapasite atış poligonuna taşıma hakkına sahip olduğumuz anlamına gelir. Taşıma sırasında, aktarılan dosyanın kapasite çizgisinde ve bloklarında bir meta veri dosyası oluşturulur. Bağlantı düzeyindeki meta veri dosyası, dosyamızın hangi bloklardan oluştuğunu açıklar. Resimdeki durumda ilk dosyamız a, b, c bloklarından oluşuyor ve metadata bu bloklara bağlantılar içeriyor. Taşımaya hazır ve a, b ve d bloklarından oluşan ikinci bir .vbk dosyamız olduğunda, dehidrasyon endeksini analiz ederek yalnızca d bloğunun aktarılması gerektiğini anlıyoruz. Ve meta veri dosyası, önceki iki bloğa ve bir yeni bloğa bağlantılar içerecektir.

Buna göre bu boş alanların tekrar verilerle doldurulması işlemine rehidrasyon adı verilmektedir. Zaten yerel performans kapsamındaki en eski .vbk dosyasını temel alan kendi rehidrasyon indeksini kullanıyor. Yani kullanıcı kapasite çekim aralığından bir dosya döndürmek isterse öncelikle en eski tam yedeğe ait blokların indeksini oluşturuyoruz ve kapasite çekim galerisinden sadece eksik olan blokları aktarıyoruz. Resimde sunulan durumda FullBackup1.vbk'yi rehidrasyon indeksine göre rehidre etmek için sadece kapasite atış poligonundan aldığımız C bloğuna ihtiyacımız var. Bir depolama bulutu nesnesi, kapasiteli bir atış poligonu olarak hizmet veriyorsa, bu, çok büyük miktarda para tasarrufu yapmanıza olanak tanır.

Burada bu teknolojinin WAN Hızlandırıcılarında kullanılan teknolojiyle aynı olduğu görünebilir, ancak sadece öyle görünüyor. Hızlandırıcılarda tekilleştirme globaldir; burada yerel tekilleştirme her dosyada belirli bir ofsetle kullanılır. Bu, çözülen görevlerin farklılığından kaynaklanmaktadır: Burada büyük tam yedekleme dosyalarını kopyalamamız gerekiyor ve araştırmamıza göre, aralarında uzun bir süre geçse bile bu tekilleştirme algoritması en iyi sonucu veriyor.

Ama indekslerin tanrısı için daha fazla indeks! Veri kurtarma için bir dizin de var! Kapasite panosundaki bir makineyi geri yüklemeye başladığımızda, yalnızca performans panosunda olmayan benzersiz veri bloklarını okuyacağız.

Olduğu gibi

Giriş kısmı bu kadar. Oldukça detaylı ama yukarıda da belirttiğimiz gibi bu detaylar olmadan yeni fonksiyonların nasıl çalıştığını anlatmak mümkün olmayacak. Bu nedenle lafı daha fazla uzatmadan ilkine geçelim.

Kopyalama modu

Büyük ölçüde mevcut teknolojilere dayanıyor ancak tamamen farklı bir kullanım mantığı taşıyor. 

Bu modun amacı, yerel kapsamda yer alan tüm verilerin kapasite çizgisinde bir kopyasının bulunmasını sağlamaktır.

Taşıma ve Kopyalama modlarını doğrudan karşılaştırırsanız şöyle görünecektir:

• Yalnızca kapalı zincir hareket ettirilebilir. Kopyalama modunda, yedekleme işinde ne olursa olsun kesinlikle her şey aktarılır.
• Dosyalar operasyonel yedekleme penceresinin sınırlarını aştığında taşıma tetiklenir ve yedekleme dosyası göründüğü anda kopyalama tetiklenir.
• Yeni verilerin kopyalanması için izlenmesi sürekli olarak gerçekleşir ve taşıma için her 4 saatte bir tetiklenir.

Yeni tarzı değerlendirirken basit örneklerden karmaşık örneklere geçmeyi öneriyorum.

En yaygın durumda, elimizde sadece artışlı yeni dosyalar bulunur ve bunları basitçe kapasite atış poligonuna kopyalarız. Yedekleme işinde hangi modun kullanıldığına bakılmaksızın, zincirin mühürlü kısmına ait olup olmadığına bakılmaksızın, çalışma penceremizin süresinin dolup dolmadığına bakılmaksızın. Sadece alıp kopyaladılar.

Bunun arkasındaki süreç yukarıda açıklandığı gibi hala dehidrasyondur. Kopyalama modunda, halihazırda depomuzda bulunan blokları kopyalamamamızı da sağlar. Tek fark, film modunda gerçek dosyaları sahte dosyalarla değiştirdiğimizde, onlara hiçbir şekilde dokunmuyoruz ve her şeyi olduğu gibi bırakıyoruz. Aksi takdirde, dikkatli bir şekilde paranızdan ve zamanınızdan tasarruf etmeye çalışan tamamen aynı dehidrasyon indeksidir.

Şu soru ortaya çıkıyor: Kullanıcı arayüzüne bakarsanız, her iki seçeneği de aynı anda seçme fırsatı var. Böyle bir birleşik mod nasıl çalışacak?

Anlaşma yapalım.

Başlangıç ​​standarttır: Bir yedekleme dosyası hemen oluşturulur ve kopyalanır. Ona bir artış oluşturulur ve ayrıca kopyalanır. Bu, dosyaların işletim penceremizden çıktığını ve mühürlü bir zincirin ortaya çıktığını anladığımız ana kadar olur. Bu noktada dehidrasyon işlemi gerçekleştiriyoruz ve bu dosyaları sahte dosyalar ile değiştiriyoruz. Elbette kapasite atış poligonuna bir daha hiçbir şey kopyalamıyoruz.

Tüm bu büyüleyici mantık, arayüzdeki tek bir onay kutusundan sorumludur: Yedeklemeleri, oluşturuldukları anda nesne depolama alanına kopyalayın.

Neden bu Kopyalama moduna ihtiyacımız var?

Soruyu şu şekilde yeniden ifade etmek daha da iyi: Onun yardımıyla hangi risklerden korunuyoruz? Hangi sorunu çözmemize yardımcı oluyor?

Cevap açık: elbette bu veri kurtarmadır. Nesne depolama alanında yerel verilerin tam bir kopyasına sahipsek, ürünümüze ne olursa olsun, verileri her zaman koşullu Amazon'da bulunan dosyalardan geri yükleyebiliriz.

Öyleyse en basitinden en karmaşıkına kadar olası senaryoları inceleyelim.

Başımıza gelebilecek en basit talihsizlik, yedekleme zincirindeki dosyalardan birine erişilememesidir.

Daha üzücü bir hikaye ise SOBR depomuzun kapsamlarından birinin bozulmasıydı.

SOBR deposunun tamamı erişilemez hale geldiğinde, ancak atış poligonu kapasitesi çalışıyorsa durum daha da kötüleşiyor.
Ve her şey gerçekten kötü - bu, yedekleme sunucusunun öldüğü ve ilk arzunuzun on dakika içinde Kanada sınırına koşmaya çalışmak olduğu zamandır.

Şimdi her duruma ayrı ayrı bakalım.

Bir (ve hatta birkaç) yedekleme dosyasını kaybettiğimizde tek yapmamız gereken, depoyu yeniden tarama işlemini başlatmaktır ve kayıp dosya, sahte bir dosyayla değiştirilecektir. Ve (makalenin başında tartışılan) rehidrasyon sürecini kullanarak kullanıcı, kapasite atış poligonundan yerel depolamaya veri indirebilecek.

Şimdi durum daha da karmaşık. SOBR'umuzun Performans modunda çalışan iki uzantıdan oluştuğunu varsayalım; bu, .vbk ve .vib dosyalarımızın bunların üzerine oldukça düzensiz bir katman halinde yayıldığı anlamına gelir. Ve zamanın bir noktasında, kapsamlardan biri kullanılamaz hale gelir ve kullanıcının, verilerinin bir kısmı tam olarak bu kapsamda bulunan makineyi acilen geri yüklemesi gerekir.

Kullanıcı kurtarma sihirbazını başlatır, geri yüklemek istediği noktayı seçer ve sihirbaz çalışırken yerel olarak kurtarma için gerekli tüm verilere sahip olmadığını ve bu nedenle kapasite çekiminden indirilmesi gerektiğini fark eder. galeri. Aynı zamanda yerel depolamada kalan bloklar buluttan indirilmeyecektir. Geri yükleme dizinine şükürler olsun (evet, makalenin başında da bahsedilmişti).

Bu durumun bir alt türü de SOBR deposunun tamamının erişilemez hale gelmesidir. Bu durumda yerel depolamadan kopyalayacak hiçbir şeyimiz kalmaz ve tüm bloklar buluttan indirilir.

Ve en ilginç durum ise yedekleme sunucusunun ölmesi. Burada iki seçenek var: Yönetici harikadır ve yapılandırma yedeklemeleri yapmıştır ve yöneticinin kendisi kötü bir Pinokyo'dur ve yapılandırma yedeklemeleri yapmamıştır.

İlk durumda, VBR'nin temiz kurulumunu bir yere dağıtması ve standart araçları kullanarak veritabanını bir yedekten geri yüklemesi yeterli olacaktır. Bu sürecin sonunda her şey normale dönecektir. Veya yukarıdaki senaryolardan birine göre geri yüklenecektir.

Ancak yönetici ya kendi düşmanıysa ya da yapılandırma yedeği de epik bir başarısızlığa uğradıysa, o zaman burada bile onu kaderin insafına bırakmayacağız. Bu durum için, Nesne Depolamayı İçe Aktarma adı verilen yeni bir prosedür başlattık. Bir SOBR deposunu manuel olarak yeniden oluşturma ve daha sonra yeniden tarama ile buna bir kapasite çekim aralığı ekleme sürecini atlamanıza ve Vim arayüzüne bir depolama nesnesi eklemenize ve Depolama Deposunu İçe Aktarma prosedürünü çalıştırmanıza olanak tanır. Yedeklemelerinizle aranızda durabilecek tek şey, yedeklemeleriniz şifrelenmişse şifre girme isteğidir.

Bu muhtemelen tamamen Kopyalama Modu ile ilgilidir ve biz de şuna geçiyoruz:

Mühürlü Mod

Ana fikir, deponun seçilen SOBR boyutunda yeni yedeklemelerin görünememesidir. V10'dan önce, yalnızca depoyla herhangi bir çalışmanın tamamen yasak olduğu Bakım Modumuz vardı. Yedeklemeleri tek seferlik başka bir boyuta taşıyan, yalnızca Tahliye düğmesinin bulunduğu, depolamayı kapatmak için kullanılan bir tür zorlu mod.

Ve Mühürlü mod bir tür "yumuşak" seçenektir: yeni yedeklemelerin oluşturulmasını yasaklıyoruz ve eskileri seçilen saklama süresine göre kademeli olarak siliyoruz, ancak bu süreçte depolanan noktalardan geri yükleme yeteneğimizi kaybetmiyoruz. Kullanım ömrünün sonuna yaklaşan bir donanımımız olduğunda ve onu değiştirmemiz gerektiğinde ya da onu daha önemli bir şey için boşaltmamız gerektiğinde, ancak onu alıp her şeyi aynı anda taşıyacak hiçbir yer olmadığında çok yararlı bir şey. Veya silinemez.

Buna göre, çalışma prensibi oldukça basittir: tüm yazma işlemlerini (yeni verilerin ortaya çıkması) yasaklamak, okumayı (geri yüklemeler) ve silmeyi (saklama) bırakmak gerekir.

Her iki mod da aynı anda kullanılabilir ancak Bakımın daha yüksek önceliğe sahip olduğunu unutmayın.

Örnek olarak iki kapsamdan oluşan bir SOBR'yi düşünün. İlk dört gün boyunca Forward Forever Incremental modunda yedekler oluşturduğumuzu ve ardından kapsamı mühürlediğimizi varsayalım, bu, mevcut ikinci kapsamda yeni bir aktif tam oluşturmayı başlatmamıza neden olur. Tutma oranımız dört ise, mühürlü kapsamda bulunan zincirin tamamı sınırlarını aştığında, vicdan rahatlığıyla silinir.

Silme işleminin daha erken gerçekleştiği durumlar vardır. Örneğin, bu periyodik dolumlarla İleriye doğru artımlıdır. İlk iki gün için tam yedeklemeler oluşturduysak ve Perşembe günü depoyu kapatmaya karar verirsek, Cuma günü yeni bir yedekleme oluşturulduğunda Pazartesi gününe ait dosya silinecektir çünkü bu noktada herhangi bir bağımlılık yoktur. Ve meselenin kendisi kimseye bağlı değil. Daha sonra mevcut kapsamda dört nokta oluşana kadar bekleyip, birbirinden bağımsız olarak silinemeyen kalan üç noktayı siliyoruz.

Ters Artımlı ile işler daha basittir. İçinde en eski noktalar hiçbir şeye bağlı değildir ve güvenle silinebilir. Bu nedenle yeni bir kapsamda yeni bir .vbk oluşturulduğunda eski .vrbs birer birer silinecektir.

Bu arada, neden her seferinde yeni bir .vbk oluşturuyoruz: eğer onu oluşturmasaydık ve eski artış zincirine devam etseydik, o zaman eski .vbk herhangi bir modda sonsuz uzunlukta bir süre donarak silinmesini engellerdi. Bu nedenle, kapsam mühürlenir mühürlenmez serbest alanın tam bir yedeğini oluşturmamıza karar verildi.

Kapasiteli atış poligonunda işler daha karmaşıktır.

Öncelikle kopyalama moduna bakalım. Dört gün boyunca aktif olarak yedekleme oluşturduğumuzu ve ardından kapasite atış poligonunun kapatıldığını varsayalım. Hiçbir şeyi silmiyoruz, ancak alçakgönüllülükle saklamaya katlanıyoruz, ardından verileri kapasite atış poligonundan siliyoruz.

Taşıma modunda da yaklaşık olarak aynı şey olur - rötuşu bekleriz, yerel depolamadaki eskisini sileriz ve nesne deposunda depolananı sileriz.

Forever forward artımlı ile ilginç bir örnek. Saklamayı üç noktaya kuruyoruz ve Pazartesi günü düzenli olarak buluta kopyalanan yedeklemeler yapmaya başlıyoruz. Depolama alanı mühürlendikten sonra, üç nokta korunarak yedekler oluşturulmaya devam edilir, ancak kapasite panosunda saklanan veriler bağımlı kalır ve silinemez. Bu nedenle, .vbk'mizin saklamanın ötesine geçtiği Perşembe gününe kadar bekleriz ve ancak o zaman kaydedilen zincirin tamamını sakin bir şekilde sileriz.

Ve küçük bir sorumluluk reddi beyanı: Buradaki tüm örnekler tek bir makineyle gösterilmektedir. Yedeklemenizde bunlardan birkaçı varsa, bunların rötuşları Active Full'ün yapılıp yapılmamasına bağlı olarak farklılık gösterecektir.

Temelde hepsi bu. O halde en zorlu özelliğe geçelim -

değişmezlik

Önceki noktalarda olduğu gibi, ilk şey bu işlevin hangi sorunu çözdüğüdür. Yedeklerimizi depolama için bir yere yüklediğimizde, bunların güvenliğini garanti altına almak, yani belirli bir saklama süresi boyunca bunların silinmesini ve herhangi bir şekilde değiştirilmesini fiziksel olarak yasaklamak konusunda güçlü bir istek doğar. Kök hesapları da dahil olmak üzere yöneticiler dahil. Bu, onları kazara veya kasıtlı hasarlardan korumanıza olanak tanır. AWS ile çalışan herkes Nesne Kilidi adı verilen benzer bir özellikle karşılaşmış olabilir.

Şimdi moda genel hatlarıyla bakalım ve ardından ayrıntılara girelim. Örneğimizde, dört günlük bir tutma ile kapasite atış poligonumuz için Değişmezlik etkinleştirilecektir. Ve yedeklemede Kopyalama modu etkindir.

Değişmezlik, genel saklamayla hiçbir şekilde etkileşime girmez. Örneğin ekstra puan falan eklemiyor. Sadece bir kişi yedekleme dosyalarını dört gün içinde silemez. Pazartesi günü yedekleme yaparsanız, dosyayı ancak Cuma günü silebilirsiniz.

Daha önce açıklanan tüm dehidrasyon, indeksler ve meta veriler kavramları tamamen aynı şekilde çalışmaya devam ediyor. Ancak bir koşulla - blok yalnızca veriler için değil aynı zamanda meta veriler için de ayarlanır. Bu, kurnaz bir saldırganın meta veri veritabanımızı silmeye karar vermesi ve veri bloklarının işe yaramaz ikili lapaya dönüşmesini engellemesi durumunda yapılır.

Şimdi blok oluşturma teknolojimizi açıklamanın tam zamanı. Veya üretimi engelle. Bunu yapmak için ortaya çıkmasına neden olan durumu düşünün.

Altı günlük bir zaman ölçeğini ele alalım ve bunun altında, değişmezliğin beklenen sona erme zamanını işaretleyeceğiz. İlk gün veri bloğu a ve onun meta verilerinden oluşan bir dosya alıp oluşturuyoruz. Değişmezlik üç güne ayarlanmışsa, dördüncü günde verilerin kilidinin açılacağını ve silineceğini varsaymak mantıklı olacaktır. İkinci gün aynı ayarlara sahip b bloğundan oluşan yeni bir dosya2 ekleyeceğiz. Blokajın dördüncü günde kaldırılması gerekiyor. Ancak üçüncü gün korkunç bir şey olur - yeni bir d bloğu ve eski a bloğuna bir bağlantıdan oluşan bir Dosya3 dosyası oluşturulur. Bu, bir blok için ve onun değişmezlik bayrağının altıncı güne kaydırılan yeni bir tarihe sıfırlanması gerektiği anlamına gelir. Ve burada bir sorun ortaya çıkıyor - gerçek yedeklemelerde bu tür çok sayıda blok var. Değişmezlik sürelerini uzatmak için her seferinde çok sayıda istekte bulunmanız gerekir. Ve aslında, bu neredeyse sonsuz bir günlük süreç olacak, çünkü yüksek olasılıkla her kopyada tekilleştirilmiş bloklardan oluşan büyük yığınlar bulacağız. Nesne depolama sağlayıcılarından gelen çok sayıda istek ne anlama geliyor? Sağ! Ay sonunda büyük fatura.

Ve favori müşterilerinizi birdenbire önemli miktarda para karşılığında ifşa etmemek için, blok oluşturma mekanizması icat edildi. Bu, belirlenen değişmezlik süresine eklediğimiz ek bir dönemdir. Aşağıdaki örnekte bu süre iki gündür. Ama bu sadece bir örnek. Gerçekte, aylık kilitlenme sırasında yaklaşık on gün daha veren kendi formüllerini kullanıyorlar.

Aynı durumu düşünmeye devam edelim, ancak blok oluşturma ile. İlk gün a bloğundan ve meta verilerden dosya1'i oluşturuyoruz. Oluşturma süresini ve değişmezliği topluyoruz - bu, dosyayı silme fırsatının altıncı günde olacağı anlamına gelir. İkinci gün b bloğu ve a bloğuna bağlantıdan oluşan Dosya2'yi oluşturursak, beklenen silme tarihine hiçbir şey olmaz. Altıncı günde olduğu gibi ayağa kalktı. Ve böylece talep sayısından tasarruf etmeye çalışıyoruz. Son teslim tarihinin kaydırılabileceği tek durum, üretim süresinin sona ermesidir. Yani, üçüncü günde yeni Dosya3 a'yı bloke edecek bir bağlantı içeriyorsa, Gen2'in süresi dolduğu için 1. nesil eklenecektir. A bloğunun silinmesi için beklenen tarih ise sekizinci güne kayacak. Bu, tekilleştirilmiş blokların ömrünü uzatmaya yönelik taleplerin sayısını önemli ölçüde azaltmamıza olanak tanır ve bu da müşterilerimize büyük miktarda para tasarrufu sağlar.

Teknolojinin kendisi, üreticilerinin uygulamalarının Amazon'unkinden farklı olmadığını garanti ettiği S3 ve S3 uyumlu donanım kullanıcıları tarafından kullanılabilir. Azure'un neden desteklenmediği meşru sorusunun cevabı da buradan geliyor; benzer bir özelliğe sahipler, ancak tek tek nesneler değil, konteynerler düzeyinde çalışıyor. Bu arada, Amazon'un kendisinde iki modda nesne kilidi var: uyumluluk ve yönetişim. İkinci durumda, nesne kilidine rağmen, adminlerin üzerindeki en büyük yöneticinin ve köklerin üzerindeki kökün yine de verileri silme olasılığı vardır. Uyumluluk durumunda her şey sıkı bir şekilde çivilenir ve hiç kimse yedekleri silemez. Amazon yöneticileri bile (resmi açıklamalarına göre). Bu bizim desteklediğimiz moddur.

Ve her zamanki gibi bazı yararlı bağlantılar:

• Hakkında Blok Oluşturma her ayrıntıda.
• Hakkında tüm bilgiler Veeam Yedekleme ve Çoğaltma 10 en iyi şekilde
• О Kapasite Katmanı detayda

Kaynak: habr.com