Veeam Enterprise 9.5 ile Yedek Alma Operasyonları -KISIM I-

     4 Kısımdan oluşan Veeam 9.5 yedekleme altyapısı yazı dizimizde, veeam içerisinde kullanılan komponent ve servisleri incelemiştik. Şimdi elimizdeki araçları biliyoruz. Bu araçlarla veeam içerisindeki her türlü operasyonu yapabiliriz. İlk olarak yedek alma işleminden başlamak istiyorum. Belki yönetim konsolunu ayrıntılı incelemek  daha önce yazılmalı fakat kendi sistemimiz üzerindeki yapı üzerinde ana işlevleri kontrol etmek ve eksiklikleri gidermek için bir miktar acelem var. Dolayısı ile ilk işleyeceğim konular yedek alma ve geri dönüş işlemleri.Bu 2 ana konu üzerinden yayılarak diğer konulara daha sonra gireceğim.

BACKUP -I-

Veeam yedek alırken image seviyesinde ve blok olarak alır.Alınan bu yedek değişik yöntemlerle geri dönüş için kullanılabilir. Ben bu yazıda kendi sistemimizde kullandığımız yedekleme mekanizması üzerinden gideceğim. Örneğin shared folder repository'ye sahip bir yedekleme sistemine veya WAN üzerinden uzak lokasyonda çalışan bir yedekleme sistemine değinmeyeceğim.

Yedekleme temel olarak VMware tarafından snapshot'ın alınması olarak düşünülebilinir.Datastore dan blok seviyesinde alınır, onu sıkıştırır, tekilleştirir(deduplication) ve kendi formatında yedeklenmiş olarak repository de saklar.

Job(iş) parçacıklı bir yapıya sahiptir. Bir job tanımlarsınız; burada yedeğin nasıl , ne zaman, ne kadar süre ile alınacağı gibi bilgiler girilir ve job otomatik veya manuel şekilde çalıştırılır. Tam(Full) ve arttırımlı(incremental) yedek mekanizması bulunmaktadır. İlk yedek full alınıp sonrakiler aradaki değişenleri alarak devam eder.

Madde madde yedekleme işlemi:

• Job başlatıldığında; veeam, backup sunucusu içerisinde veeam backup managerı çalıştırır.Manager konfigürasyon veritabanından, çalıştırılan job ile ilgili ayarları okur.Sonra job'a dahil VM ler için görevler oluşturur. Her eklenen VM diski için bir görev oluşturulur.
• Manager, daha sonra backup servisine bağlanır.Backup servisi içerisinde bütün görev ve kaynakları planlayan bir komponent bulunmaktadır.Kaynaklar kontrol edilir, ilgili proxy ve repository alanları görevlere atanır.
• Manager sonraki işleminde, hedef noktada bulunan repositoryde ve proxyde bulunan Veeam Transport Servislerine bağlanır.Transport Servisleri, "Veeam Data Mover" ları çalıştırır. Proxy de işlem gören her bir görev için yeni data mover başlatılır.
• Manager artık hem repository de hemde proxy de bulunan data mover'lara bağlanır ve varsa diğer ayarları yapar(Network hızlandırma ayarları gibi).
• Sonra hem proxy de hem de repositoryde bulunan data mover'lar birbirleri ile bağlantı kurar.
• Manager, veeam backup broker servisi yardımıyla VM ler ve Host'lar ile ilgili sorgulamaları yapar.
• Eğer application-aware bir işlem yapılacak ise; veeami VM'in içine bağlanır ve işletim sistemi içerisinde app-aware ile ilgili işlemleri başlatır.
• Veeam daha sonra VMware'e snapshot alınması için istek gönderir.
• Kaynaktaki veeam data mover snaphot ile sadece okunabilir(read-only) hale gelen VM'i okumaya başlar ve repository'ye doğru gönderir.Incremental yedek alımlarında, veeam data mover, CBT(Changed Block Tracking)kullanarak sadece değişen parçaları okur. Eğer CBT kullanılmaz durumdaysa, veeam repositoryde bulunan bir önceki yedeğin metadatalarına bakarak, bir sonraki yedek için VM de oluşan değişiklikleri belirler.
• Verilerin transferi sırasında, kaynakta bulunan data mover ek işlemler uygular. zero veri bloklarını filtreler, swap ve yedek harici tutulmuş işletim sistemi dosyalarını bloklar.
• Backup proxy VM okuma işini bitirince; veeam vCenter'a snapshot'ı usulca yerine koymasını söyler :) ve işlem tamamlanır.

Yedekleme Mimarisi:

Veeam'in yedekleme işlemi için kullandığı komponenetler aşağıdadır.

• Bir veya daha fazla VMware host ve ilgili datastore'ları.
• Bir veya daha fazla backup proxy
• Backup repository
• Bir veya daha fazla interaction proxy
• Paylaşımlı(shared) backup repository var ise Gateaway server.

işte bunların hepsi bir job için tabir yerindeyse tek bir hat gibi çalışırlar. Kaynak host ve backup repository, hattın her iki ucunu oluşturur.

Veeam 2 servisli bir mimari kullanır. Bir data mover kaynak noktada diğeri repository noktasında birbirleri ile stabil bir bağlantı kurarak yedekleme işini yaparlar.

Yedekleme Zinciri(BAckup Chain):

Zinciri incelerken en başta dosya tiplerine bakmalıyız.

• VBK Dosyaları: VM lerin tam imajlarını saklayan dosyalar.
• VIB veya VRB: VM lerdeki arttırımlı(incremental) yedekleri saklayan dosya biçimi.
• VBM: Yedeklerin metadata larının saklandığı dosya(Kaç yedek var, yedekleme işi kapsamındaki VM ler, geri dönüş noktaları vb.)

Bunların dışında 2 tür dosya daha vardır.

• VSB(Virtual Synthetic Backups): Teyp ünitelerinde sanal tam yedekler için kullanılan dosya tipidir. İleride inceliyeceğiz.
• VLB: Transaction logları tutan yedek dosyaları. Microsoft SQL ve Oracle için kullanılır.

Bir iş(Job) için oluşturulan tüm dosyalar, hedef repository de, Job için ayrılmış bir alanda tutulur. Bu dsyaların tamamı yedekleme zincirini oluşturur(Backup Chain).

3 tür zincir oluşturabiliriz.

• Devamlı ilerleyen artırımlı yedekleme(Always Forward incremental backup)
• İlerleyen artırımlı yedekleme(Forward incremental backup)
• Ters artırımlı yedekleme(Reverse incremental backup)

Normalde veeam tüm VM leri o Job için oluşturulmuş yedekleme dosyasına atar. İsterseniz bu dosyaları her VM için ayrı olsun şeklinde tanımlıyabilirsiniz. Ama yaparken unutmayın. 2 yazı önce demiştik. Veeam deki deduplication yapısını kaybedersiniz. Her VM için dosya oluşturacaksanız, deduplication için deduplication yapan bir hedef repository sahibi olmanız gerekir. Zincir türlerini incelemeye başlayalım.

Devamlı İlerleyen Artırımlı Yedekleme(Forever Forward Incremental Backup):

Şekilden görüldüğü üzere 1 tane full gerisi incremental giden bir yapı var. Retention(geri dönüş noktası sayısı) a göre, veeam gerekli düzenlemeleri yaparak yapıyı devamlı güncel tutar. Retention kısmını(aşağıda inceleyeceğiz : ) ) incelediğimizde ayrıntısına gireceğiz.

Veeam konsol üzerinden bu Job oluşturulurken sadece incremental kısmı seçilir. Eğer synthetic veya active full backup kısmı seçilirse, bu zincir forever forward incremental değil forward incremental olur.

İlerleyen Artırımlı Yedekleme(Forward Incremental Backup):

Bir üsttekinden farkı, ara sıra full backup oluşmasıdır. Synthetic veya active full şeklinde olabilir. Örneğin haftada 1 full gerisi incremental şeklinde tanımlayabiliriz.

Normalde Job oluştururken hiç bir şeyi değiştirmezseniz veeam politikayı Forward incremental şeklinde tanımlıyor.

Ters artırımlı yedekleme(Reverse incremental backup):

Bu yöntem ilginç. Full olan yedek hep en güncel yedek oluyor. Şekile bakınca gözünüzde canlanabilir.

Veeam önce bir full oluşturur. Daha sonra değişimlere bakar, onları mevcut full yedeğe ekler ve dğeişim kısmını silmeden ilerler. Retention politikasına göre en gerideki yedekleri silerek zinciri devam ettirir.

Yedekleme zincirleri arası geçiş kolaydır. Veeam; herhangi bir zincirin türünün değişmesi sonrasında, mevcut zinciri koruyup yenisini başlatır. Mesela Job içerisinde reverse incremental dan forward incremental'e değişiklik yaptınız. O zaman kadar alınmış reverse incremental zinciri olduğu gibi kalıp yeni bir zincir başlatılır.

Herhangi bir zamanda aktif full yedek almak isterseniz, job'un üzerine sağtık yapıp, "active full backup" seçmeniz yeterlidir. Aktif full yedekleri belli bir plana görede çalıştırabilirsiniz(Ör: Haftada 2, Ayda 1 vb.)

Sentetik tam yedekler(synthetic full backups), aktif tam yedeklerin kullanılmasının dezavantaj getirdiği durumlar için iyi bir alternatiftir. Aktif tam yedekler network üzerine yük bindirir ve kaynakları aşırı tüketebilir.Aktif tam yedek dediğimizde; veeam, VM üzerinden tüm bilgileri çekerek onları sıkıştırıp tekilleştirir ve .VBK olarak repository'ye yazar.

Sentetik tam yedekte ise, VM den herhangi bir veri çekilmez. Zaten alınmış olan yedekleme dosyalarınında bulunan arttırım dosyalarını birleştirerek yeni tam yedeği oluşturur.Bazı avantajları vardır. Network üzerine yük bindirmez ve sistemlerin çalıştığı üretim ortamına yük bindirmez çünkü bütün işlemler repository içerisinde gerçekleşmektedir.

Veeam sentetik tam yedekleri de düzenli tam yedek olarak kabul eder. Dolayısı ile yedekleme zinciri resetlenmiş olur. Normal tam yedekler nasıl bir etki oluşturuyorsa aynı etkiler oluşur.Sentetik yedeklemeri job politikası içerisinde aktif hale getirebilirsiniz.

Sentetik yedeğin çalışması şu şekilde olur; 

• İlk olarak bir adet full yedeğimiz üretiliyor.
• Daha sonra arttırımlı yedekler alınıyor
• Sentetik tam yedekleme günügeldiğinde, bir arttırımlı daha alınıyor, 
• Önceki tam yedekten itibaren alınan tüm arttırımlar, önceki tam yedeğe işleniyor. 
• Bir önceki işlem sonucunda son ana ait sentetik tam yedek oluşuyor.
• Sentetik tam yedeğin oluştuğu andan önce oluşturulan arttırımlı yedek siliniyor ve işlem tamamlanmış oluyor.

Sentetik full yedeklerin planlanması ile ilgilide bir kaç bilgi verelim.

Bir tane Job tanımladınız. Bu job'a göre hergün saat 12:00 AM de bir adet yedek alınacak. Sentetik full olan gün de incremental yedek alınmaz ve sentetik full yedek hazırlanır. Sentetik yedekler günde 1 defa alınabilir. Daha sonra alınacak yedekler incremental olarak devam eder.

Gelelim güzel bir özelliğe. Özellikle disk miktarınız kısıtlı ise bu kullanılabilir. Sentetik yedek al dediğinizde, karşınıza bir seçenek çıkar.

Hemen yukarıdaki resimde görülen. "Transform previous backup..." diye giden seçenek. Bunu seçtiğinizde sentetik oluşturulurken o günden geriye doğru gidilip görülen ilk full yedekten itibaren "reverse incremental chain" yapısı oluşturulur(daha önceki full ve incremental yedekler olduğu gibi kalır). Böylece hem önceki hemde şimdi üretilen sentetik yedek yerine, şimdiki sentetik ve önceki incrementaller den oluşan bir zincir olur. Böylece 2 full yerine tek bir full olur ve kaplanılan alan miktarı ciddi şekilde düşer. 

Üstteki şekilde normalde pazar günü full vardı. Transform gerçekleşti ve hem pazar günü incremental oluştu hemde hepsi reverse oldu.

Geleceğiz dedik ve geldik. Retention politikasına bakalım şimdi.

Retention Politikası: (Çeviri iğrenç oluyor o yüzden böyle yazdım retention=saklama diyelim)
Retention politikası aslında bizim kaç yedek öncesine dönebileceğimizi belirlememizi sağlayan politikaya verilen isimdir. Veeam standart olarak 14 der ama biz ne kadar geriye gitmek istersek ona göre bir rakam belirleriz.

Şimdi her yedekleme zincirine göre retention politikalarına bakalım. Öncelikle unutmayalımki bu retention noktaları job içerisinde tanımlanıyor. Yani o job içerisinde 30 VM var ise ve siz 10 yedek saklayacak bir politika belirlerseniz 11. yedek alındığında tüm VM lere ait 1. yedek gider. VM leri ayırma şansınız yoktur.

Forever Forward Incremental Backup Policy:(1 full ve  devam eden arttırımlı yedek politikası)

Bu zincirde eğer retention politikasına ayrıkı bir durum oluşursa, veeam en güncel yedek için yer açacak şekilde davranır.Nasıl mı? Şöyle:

Mesela 30 noktalı bir zincirimiz olsun.1 full ve 29 incremental olduktan sonra, 30. incremental alınır. Veeam bakarki retention 30. O zaman ben bir tane eksiltmeliyim der. İlk incremental yedeği ilk full yedeğe yedirir(injection).Böylece full yedek bir gün ileri kaymış olur. Full yedeğe yedirilen incremental silinir ve yine 30 noktalı zincirimiz kalmış olur.

Forward Incremental Backup Policy:( Düzenli olarak full ve sonraki full'e kadar incremental yedek politikası)

Burada bir ince nokta var. Bu zincir nasıl bir zincir? Bir full alınıyor peşinden incrementaller geliyor, sonra yine full alınıp bu şekilde ilerliyor. Retentionda ise biz ne diyoruz?. Diyoruz ki "n" tane yedek devamlı kalsın. Mesela diyelimki bizim 3 tane geri dönüş noktamız olsun.Politikamız da pazar günü bir full ile başladık ve perşembede sentetik alınsın dedik. Şekilden de görüleceği üzere çarşamba günü retention şartı sağlandı ve normalde full silinmeli.Veeam diyorki, ben onu silersem yedekler kullanılmaz hale gelir. Ben bir sonraki full yedeğin alınmasını beklerim ve retention kadar ilerlerim. Yani full ve 2 incremental olsun. Böyle olunca önceki full ve ona bağlı incrementaller silinse bile retention sağlanmış olur. Şekile de bakarsanız tam anlaşılır.

Reverse Incremental Backup Policy:(Geriye yönelik incremental içeren yedekleme politikası)
İsmi gibi çok ters bir durumlar karşı karşıyayız :) Bu zincir de retention da belirtilen miktar kadar yedek oluşunca, her yedek alımında zincirdeki ilki silinir. Çok ters oldu en basit mantık burada ek bir işleme gerek yok :)

Yedekleme zincirlerine göre retention politiklarını inceledik. Başka retentionlar da var mı? Tabiki var, hemen bakalım.

Silinen VM ler için Retention Politikası:
Diyelimki sanal sisteminizde artık bazı VM lere ihtiyacınız kalmadı veya job içerisinden çıkardığınız VM ler var. Bunların verileri normal şartlarda varsayılan retention politikası gereği kalır. Ama disk üzerinde yer kaplamasın diyorsanız siz, bu verileri de belli bir süre sonra sildirebilirsiniz. Bu belli bir süre dediğim kısmı dikkatli düşünün. Örneğin 1 gün dediniz. VM i kaldırdınız ve ertesi gün de yedeği silindi. Siz pişman oldunuz ve VM i geri istiyorsunuz ama artık o yok.

Aslında bunun altyapısına bakmak bence çok önemli değil ama meraklı arkadaşlar için değinelim. Veeam VM lerin retention larını kontrol ederken 2 temek şarta bakar.

• VM için son "N" gündür hiç başarılı yedek alınmamıştır.
• VM için son "N" gündür hiç bozuk bir yedek bulunmamaktadır.

Eğer bu iki sorunun cevabı da doğru ise koşul sağlanmış olur ve retention işletilip VM yedekleri silinir.

Veeam yedeklemesinde bir iş içerisinde alınan tüm VM leri tek bir dosya parçası içerisinde saklandığını biliyorduk. Eğer hedef repository çoklu stream(akış) halinde verileri yazma yeteneğine sahip ise, bu tarz yedekleme çok verimli olmayabilir. O zaman VM leri ayrı ayrı dosyalar halinde repository'ye gönderebiliriz. Yine hatırlatıyorum (önceki yazılarda değinmiştim), eğer repository alınan yer deduplication yapmıyor ise bunu uygulamayın çünkü bu tarz ayrı VM dosya yedekleme sistemi, veeam tarafından yapılan deduplication işlemini iptal eder.

Tüm VM ler Tek Zincirde

Her VM İçin Ayrı Yedekleme Zinciri

Ayrı VM zincirleri tanımlıyorsanız bir kaç şeyden emin olun.

• Hedef deduplication yapıyor mu?
• Hedef paralel işleme yapabiliyor mu? (Aynı anda birden çok VM zinciri yedekelemesi)
• Hedef repository ve proxy sayısı bir çok VM için yeterli mi?. Aksi halde darboğaz olur.

Changed Block Tracing(CBT)(Değişen blok izleme):

Değişim yedeklerini almak için bir önceki yedek ile aradaki değişimleri bulmamız lazım. Veeam bu noktada VMFS deği değişiklikleri taramak yerine, VMware de 7.0 ve daha sonraki donanım veriyonlarına sahip VM lerde bulunan CBT teknolojisini kullanır.CBT de bu işi VADP(vStorage API for Data Protection) ile yapar.

CBT, veeam tarafından yedekleme, replikasyon, komple VM geri dönüşü ve disk dönüşlerinde kullanır.

Job ayarlarında CBT yi aktif edebilirsiniz. Gerekmesi durumunda daha sonra, aynı yerden kapatılabilir.

Özellikle thin disklerde de bu teknolojinin kullanıldığını belirtelim. Bu sayede thin disklerde normalde kullanılmayan alanların tespiti CBT ile yapılıyor.

CBT host seviyesinde kapatılmış ise veya VM versiyonu 7.0 dan önceki bir versiyonsa, veeam bu teknolojiyi kullanamaz. Bu durumda veeam değişmeyen data blokları üzerinden işlemi kendi yapar.

Çok ayrıntısına girmiycem ama CBT kullanılmaz ise veeam VM imajını tarayıp okuduğu bloklardan ürettiği checksum'ları metada olarak yazar ve sonraki yedekte bu mekanizmalarla karşılaştırma yaparak değişimleri alır.

Data Compression (Veri sıkıştırma):

5 adet sıkıştırma seviyesi vardır.

• Sıkıştırma olmayan işlem: Bu seçenek, hedefteki repository de sıkıştırma ve tekilleştirme gibi teknolojiler destekleniyorsa kullanılabilir.
• Dedupe-Friendly: Proxy üzerindeki işlemciyi fazla yormamak için kullanılacak seçenektir.
• Optimal: Bu seçenek normal şartlarda en idealidir. Yedekleme ve yedekleme için yapılacak işlemler arasındaki en uygun oranları belirler.
• High: Sıkıştırma için kullanılan CPU gücünün 10 katını kullanır ve yaklaşık olarak %10 daha fazla sıkıştırır.
• Extreme: Bu seviyede kullanacaksanız sağlam bir sunucunuz olması lazım. En az 6 çekirdekli CPU tavsiye ediliyor. Sizin sisteminizi bilmiyorum ama bu seçenek çoğumuz için saçma. Düşünsenize eğer çok sağlam CPU alacak bütçen var ise ek disk alırsın ve CPU yükünü arttırmazsın. Disk alamıyorsan ve CPU fazlaysa yap tabi :)

Data Deduplication(Veri Tekilleştirme):

Eğer birbirine benzeyen VM leriniz var ise(aynı template den üretilmiş veya disklerinde büyük miktarda boşluk olan VM ler), yüksek miktarda tekilleştirme oranına sahip olup alandan tasarruf sağlayabilirsiniz.

VM verileri hem kaynak hemde hedef te bulunan data mover lar tarafından tekilleştirilir.

Kaynak tarafındaki tekilleştirmede VM disklerinin seviyesinde tekilleştirilir. VM disk işlenmeye başlamadan önce hedeften önceki yedekle ilgili bilgi toplanır, önceki yedek ile şimdi alınacak yedek arasında aynı olan veriler ve boşluklar taşınmaz.

Hedefte ise durum biraz daha farklı. Tekilleştirme yedekleme dosyaları seviyesinde yapılır. Burada işlem Job ın içindeki tüm VM lerin tüm diskleri arasında yapılır.Yedekleme işlemi sırasında gelen verilere bakar ve aynı alanları yazmaz.

Storage Optimization:
Yine varsayılan ayarlara genelde dokunmaya gerek kalmayan bir kısma geldik.

• Local Target(16TB+Backup Files): Bu seçenekte, çok büyük yedekleme dosyalarınız var ise(16 TB dan fazla) 4069KB lık blok lar kullanılır. Blok ölçüsü böyle seçilince ne oluyor? Tekilleştirme blok seviyesinde yapıldığı için 4MB lık bloklar karşılaştırılıyor. 4MB lık blokların birbirininm aynı olma ihtimali az olduğu için tekillştirme performansı düşüyor. Peki o zaman blok miktarını düşürelim. O zaman ne olacak? Örneğin 1MB dedik. Bu defa o çok büyük yedek dosyası çok fazla parçalara ayrılacak. Eve tekilleştirme daha iyi olacak ama tekilleştirme için kullanılan CPU miktarı ve metadata dosyaları çok fazla artacak. O yüzden ellemeyin :)
• Local Target: Bu seçenek SAN, DAS veya lokal diske alınan yedekler de kullanılır. Blok parçaları 1MB olarak kullanılır.
• LAN: Bu seçenekte blok boyutları 512KB olarak belirlenir. Böylece tekilleştirme iyileşir ve LAN dan geçen veri miktarı fazlalaşır.
• WAN: Uzak lokasyona yedekleme istiyorsanız bu seçenek en güzeli. 256KB lık bloklar ile çok iyi bir tekilleştirme oranı yakalanır ve ağ üzerindeki trafik azalmış olur.

Sıkıştırma ve Tekilleştirme Ayarlarının Mevcut Job lar da değiştirilmesi:

Sıkıştırma ayarlarının değiştirilmesi için herhangi bir yeni job tanımlamanız gerekmez. Mevcut job içerisinde yaptığınız değişiklik anında geçerli olur. Ama reverse backup ve synthetic backup larda karma bir yapı oluşmuş olur. Eskiler eski sıkıştırma oranı, yeniler yeni sıkıştırma oranlarına sahip olur. Eğer siz 2 ayrı sıkıştırma oranı olsun istemiyorsanız, aktif bir tam yedek aldırarak yedekleme zincirini o andan itibaren yeni orana göre ayarlıyabilirsiniz.

Tekilleştirmede de karışık yapı oluşmaz. Blok boyutunu değiştirdiğiniz andan itibaren eskilerle ilgili bir bağımız kalmaz. Tekilleştirme işlemi yeni blok boyutuna göre baştan başlar. Tekilleştirmede, yedekleme(backup) ve yedek kopyalamada(backup copy) işlemler ayrı ayrı yapılır. Şöyle ki;

Backup Jobs: Burada tekilleştirme ayarını değiştirip bir tane aktif tam yedek(Active full backup) almamız gerekiyor.

Backup Copy Jobs: İlk backup job da blok boyutunu değiştiriyoruz, daha sonra bir tane aktif tam yedek aldırıyoruz. Son aşamada ise backup copy job içerisinde bir tane aktif tam yedek aldırıyoruz ve işlem bitiyor.

Data Exclusion(Veri HAriç Tutma):

Yedekleme ve replikasyon işlemlerinde, yedeğinin alınmasına gerek olmayan verileri belirleyebilirsek, yedekler alınırken bu verilerin alınmamasını ve dolayısı ile disk üzerinde gereksiz yer kaplamamasını sağlayabiliriz.

Peki bu istenmeyen verilerin hariç tutulması işlemini hangi seviyede yapabiliriz?

VM seviyesinde

• Eklenen VM ler
• VM diskleri
• VM template ler

VM işletim seviyesinde

• VM işletim sistemindeki swap dosyaları
• VM işletim sisteminde silinen dosyalar(BitLooker)
• VM işletim sistemi içerisindeki dosya ve klasörler.

* VM logları otomatik olarak veeam tarafından yedek dışında tutulmaktadır.

VM seviyesindeki işlemlerin hepsi job içerisinden oluyor. Exclude kısmından yapabilirsiniz. İsterseniz jobda bulunan VM ler içerisinden bazı VM lerin, isterseniz bir veya daha fazla VM in disklerinden bazılarının yedeklemeye dahil olmamasını sağlayabilirsiniz.

Vm templateler ise varsayılan olarak yedeklenir fakat sadece tam(full) yedekler içerisinde bulunur. İsterseniz aynı yerden bunuda iptal edebilirsiniz.

Kirli veri bloklarımız var. Nerede? VM içerisinde silinen ama dışarıdan görülen bloklar. Veeam de varsayılan olarak bu bloklar yedeklenmez. Ama yedeklenmesini istiyorsanız job içerisinde advanced sekmesinden ayarını yapıp bunları aldırabilirsiniz. 

*Varsayılan olarak veeam, pagefile.sys ve hiberfil.sys dosyalarını yedeklemez.

VM İçerisindeki Dosyalar:

Veeam ile bir VM içerisindeki bazı dosyaları yedekleyip bazılarını yedek dışında tutabilirsiniz. Bu kısıma girmek için o vm'in bulunduğu job içerisinde özel guest processing kısmından giriş yapıp, işlem yapacağınız VM i seçiyorsunuz. Daha sonra sekmelerden file processing kısmında wildcarlar kullanarak veya direk yolu belirtilerek işlem yapabilirsiniz.

Dosya bazında yedeklerin belirlenmesini yapıyorsak, bazı şeylere dikkat etmeliyiz.

• Dosya hariç tutma işlemi sadece Windows NTFS dosya sisteminde olur.
• Veeam enterprise veya Enterprise Plus versiyonu gereklidir.
• VM içerisine ip üzerinden gerekli yetkilendirmeyle ulaşabilmek gerekir. Sebebi ise Veeam'in VM içerisine "Run Time Process" çalıştırması gerekir.
• Veeam hem basic hemde dynamic disklerde bu işlemi yapabilir, fakat dinamik disklerin herhangi bir şekilde herhangi bir şekilde parçalanmamış(split) olmaması gerekir.
• Bu dosya hariç tutma işlerinin, Microsoft Windows Data Duplication çalışan yerlerde kullanılması önerilmez.Eğer yapacaksanız System Volume Information kısmını inclusions kısmına ekleyin.
• Exclusion işleminde maske kullanırsanız tüm VM taranacağı için disk incelemesi uzun sürebilir.
• Exclusion veya Inclusion da ki dosyaların sayısı bir kaç yüz den fazla sayıda olmamalıdır. Aksi halde işlem yorucu hale gelebilir.
• Sistem dosyalarının exclusion a alınması önerilmiyor.
• 2KB dan küçük boyutlu dosyalarında exclusion a alınması önerilmiyor. Yedek boyutunu ciddi etkilemiyorlar.

Ayrıca yukarıda saydığımız dosya hariç tutma işlerini disk bazında da exlusion yapabiliriz. Örneğin aynı VM içerisinde C:\ ve D:\ diskini al ama E:\ diskini alma diyebilirsiniz. Ayrıntısına girmiyorum.

Dosya seviyesinde exclusion yapılırken, bu işlem NTFS seviyesinde olduğu için CBT tarafından algılanmaz. Bir sonraki yedekleme işleminde CBT tarafından yeni olarak işaretlenen bu dosyalar incelenir. Özetle veeam yedeği alırken 3 şeyi göz önünde bulundurur.

• CBT tarafından yeni olrak işaretlenen dosyalar(exclude edilmiş dosyalarla karşılaştırır).
• Önceki yedekleme işleminde exclude edilmiş dosyalar.
• Mevcut yedekleme görevinde exclude edilmiş dosyalar.

Bu kısıma kadar yedekleme ile ilgili ilk kısmın sonuna geldik. Diğer yazıda SQL veritabanları, VSS, VM içerisinde yapılan işlemler gibi konulara girip biraz daha ayrıntıya gireceğiz. Sağlıcakla kalın.