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

Yazı serimizin 2. kısmında transaction consistency(İşlem tutarlılığı), Guest Processin(VM lerin içerisindeki işlemler), MS SQL Log yedeklemesi, Yedekleme zaman planı ve yedek dosyalarının sağlık durumları ile ilgili konulara değineceğiz.

BACKUP -II-

Transaction Consistency(İşlem Tutarlılığı):

Çalışan bir VM i yedeklerken onu durdurmadan alınan bir yedek çakılmaya meyilli bir yedektir. Sunucu çalışırken birden elektriğini keserseniz nasıl bir etki olursa, burada da aynı durum oluşur. Eğer sunucunuzda fazla işlem yapılmıyorsa bu durum çok problem çıkarmaz ama eğer iş yükü olarak yoğun bir sunucunuz var ise risk altında olursunuz.

Yedeklerin tutarlı alınması için veeam tarafından 2 tane yöntem öneriliyor.

• Application-Aware Processing(VSS kullanılarak): Microsoft VSS kullanan uygulamalar için önerilir.
• VMware Tools Quiescence:VSS kullanmayan uygulamalar için önerilir. Örneğin linux sunucular.

VMware Tools Quiescence: VSS den önce bu kısmı inceliyelim.Nedir bu ismini zor okuduğumuz olay :)

Bunu VMware in VSS kullanılmayan sunucular için hazırlamış olduğu, VMware'e ait bir VSS gibi düşünebiliriz. Özetle VM i yedeklemeden önce kısa bir süreliğine dondurur. Varsayılan olarak seçenek kapalı halde gelir. Yani, gerekiyorsa sizin aktif etmeniz lazım. Her Job içerisinde advanced bölümünden aktif edebilirsiniz.Ama etmeden önce yazıyı okumaya devam edelim.

VMware quiescence yapmak için VMware Tools içerisindeki kendi VSS mekanizmasını kullanır. Windows VSS ile tamamen uyumludur. VMware VSS kullanılması için bazı şartların sağlanması gerekir. Örneğin sunucu içerisinde windows işletim sistemine sahip olmalısınız.

Bazı küçük dikkat edilmesi gereken durumlarda var.

• Windows 7 içerisinde VMware VSS uygulama yazıcılarını kullanmaz. Dosya tutarlı bir snapshot alır.
• Server 2013 içerisinde uygulama VSS yazıcılarını kullanır. Uygulama tutarlı bir yapı çalışır.
• Server 2008 ve sonrası için VM in durumuna göre uygulama bazlı yazıcıları kullanır veya kullanmaz. Oluşturulan snapshotlar dosya veya uygulama tutarlı oluşturulabilir.

VM Quiescence seçim metodları:

Öncelikle kenara bir notumuzu koyalım. Eğer sunucuda Microsoft VSS destekli yazılım var ise application-aware seçeneği bizim ilk seçeneğimiz oluyor. Eğer bir şekilde Microsoft VSS kullanamıyorsak, o zaman quiescence seçeneğine odaklanıyoruz. Quiescence, snapshot öncesi VM i tutarlı bir hale getiriyor. Bu hazır getirme sırasında ise transaction'ların gerçekleştiği uygulamalarla ilgili herhangi bir hazırlık yapmıyor. Hazırlıktan kasıt nedir?

• O uygulamaya özel, yedekten dönüş sırasında sorunsuz bir şekilde uygulamanın açılmasını sağlayacak hazırlama süreci
• Transaction logların, yedek veya replikasyondan sonra truncate(optimize edilmesi mi desek, parçalara mı ayrılması desek bilemedim :) ) edilmesi.

Şimdi ilk senaryo bazlı inceleme yapalım. 

1- Senaryo: Hem App-sware hemde VM Quiescence nin aktif edilmesi:

Bu senaryoda işler aşağıdaki gibi ilerler.

• Veeam önce app-aware şeklinde yedeği alabiliyormuyum diye bakar.Eğer yapabiliyor ise, VM qiescence hiç bir şekilde devreye girmez.
• Eğer bir şekilde app-aware çalışmaz ise veya job un içerisinde bazı(veya tamamı için) VM lerde pasif edilmiş ise, o zaman VM quiescence devereye girer.

Hemen üstteki ekran görüntüsünde görüldüğü üzere şöyle bir ayar yapabilirsiniz:

"App-aware almayı dene, eğer başarısız olursan VM quiescence ile yoluna devam et."

Eğer "Require successful processin(recommended)" seçeneğini seçerseniz, VM quiescence hiç aktif olmaz ve sadece app-aware ile yedek alınmaya çalışılır.

Guest Processing(VM işleme):

Geldik önemli bir kısma. Bu kısımda sanal sunucunun içerisinde yapılacak işlemlere bakacağız. Bakalım Veeam bu konuda bize neler vaadediyor.

• Application Aware Processsig: Bu konuyu yukarıda az çok inceledik ama ayrıntılarına girmemiştik. Microsoft VSS kullanılarak alınan bu yedekleme özelliği sonucunda, transaction olarak tutarlı ve veri kaybının olmadığı yedekler Veeam tarafından garanti ediliyor.
• Pre-freeze and Post-thaw scripts: Sunucu içerisinde Microsoft VSS i kullanmayan uygulamalar var ise, o uygulamalara özel scriptler yabiliyoruz.
• Transaction Log Truncation: Yedeklemeden sonra Job'a, transaction logları da bizim istediğimiz şekilde bir düzenle diyebiliyoruz. Ayrıntısına gireceğiz.
• Transaction Log Backup for Microsoft SQL Server and Oracle: Microsoft SQL ve oracle veritabanlarındaki logların yedeklerinin alınması için job içerisinde ayar yapabiliyoruz.
• VM Guest File System Indexing: VM içerisindeki dosya ve klasörler için bir katalog oluşturup daha sonra bunu "1 click restore"(tek dokunuşla geri dönüş" işlemlerinde kullanabiliriz.Kullanmasak olur mu? evet olur. Opsiyonel bir durum var burada. Ayrıntısına ileride gireceğiz.
• VM Guest File Exclusion: Sevdiğim ama şimdilik default ayarlar dışında çok kullanmadığım bir özellik. Bu özellik ile yedeği alınacak sunucudaki bazı dosya ve klasörleri yedek içerisine dahil etme diyebiliyoruz.

Tüm guest processing işlemleri için VM'e erişebilecek ve o VM de yetkili bir kullanıcı olması gerektiğini yazmama gerek yok herhalde diyecektim ama cümleyi yazmış bulundum :) Eğer MS SQL server ve Oracle gibi veritabanları var ise, yeterli yetkiye sahip database kullanıcıları da ayrıca bulunmalı. Tavisyem bu kullanıcların veeam için ilgili sunucuda oluşturulmaları(log bakarken kolaylık olması ve güvenlik nedeniyle, ama mevcut kullanıcılardan da gidebilirsiniz).

Hemen desteklenen uygulamalara bakalım

• MS Active Directory
• MS SQL Server
• MS Exchange
• MS Sharepoint
• Oracle

Bu noktada bir açıklama yapmalıyım. Bundan sonra ayrıntılarına gireceğim konularda sadece sistemimizde kullandığımız yapılara gireceğim. Mesela Oracle olmayacak.

Runtime Coordination Process(Nasıl çevirebilirim bilmiyorum aşağıyı okuyun :) )

Guest processing işlemleri sırasında Veeam kalıcı ajanlar göndermez. İşi yapmak için "runtime process" denilen bir işlemi geçici olarak çalıştırır.Job başladığı zaman sunucuya gönderilir, iş bitince kaldırılır.Bunu iki yolla yapar.

• Windows bulunan VM lere proxy üzerinden(guest ineraction proxy) üzerinden gönderir.Eğer bu proxy mekanizması çalışmaz ise o zaman backup server dan gönderilir.
• Windows dışındaki makinelere ise backup server üzerinden gönderir.

gönderme işinin ayrıntısına girmiycem ama içerideki VMtools ile haberleşip ip üzerinden basar diyebiliriz.

Application Aware Processing:
Şimdi bu işin bir ayrıntısına girelim. Uygulama bazlı yedekleme nasıl oluyor görelim.Microsoft VSS mekanizmasını kullandığını daha önce söylemiştik. VSS mekanizması veritabanının durduğundan emin olmamızı sağlar, yedekleme için hazır hale getirir.Veeam bu işi yaparken aşağıdaki basamakları takip eder.

• VM içerisine runtime process basar ve içeride VSS ile kontrol edilebilen yapıların olup olmadığına bakar.
• VM e yüklenen uygulamalar hakkında bilgileri toplar.
• Uygulamaları VSS restore için hazırlar. Nedir bu restore? Eğer biz ileride bir geri dönüş yapacaksak, işte bu VSS uygulamaları yedekleri alınırken geri dönecek şekilde hazırlanır.Buna VSS-sware restore denir.
• VSS uygulamalarla konuşur ve zamanda bir nokta üzerinde I/O ları quiescence durumuna getirir.
• Veeam VSS Snaphot alınması için istek gönderir.
• Veeam vSphere'e snapshot alması için istek gönderir.
• Daha sonra Microsoft VSS uygulamaların snapshottan sonra işlerine devam etmesi için gerekli işlemleri yapar.
• Job normal şekilde devam eder.
• Son aşamada ise eğer Log larla ilgili herhangi bir truncate işlemi var ise, veeam bu konudaki işlemleri yapar. Bu log işlemi backup işleminden sonra gerçekleşir.

Pre-Freeze and Post-Thaw  Scripts:
Bu noktaya yukarıda çok kısa değinmiştik. Burada da uzun uzadıya değinmiycem ama bir kaç kritik noktayı belirtmek istedim.

• Bu scriptleri backup,restore ve VM kopyalama joblarına tanımlayabilirsiniz.
• Hem windows hem de linux sistemler için kullanabilirsiniz.Windows için EXE,BAT, CMD,WSF,JS,PS1 desteklenirken, Linux için SH formatı desteklenmektedir.
• Scriptler inceden bir dosyaya yazılmalıdır. Daha sonra bunların yollarını job içerisinden tanımlayabiliriz. Çalışma ayarları(execution configuration) ise her VM veya her JOB için ayarlanabilir.
• Scriptler windows VM lere network üzerinden veya oradan gönderilemiyorsa VIX(virtual infrastructure extension) üzerinden gönderilir. Linux ta ise SSH bağlantısı ile gönderilir.

bazı noktaları özetledim. Eğer kullanacaksanız bu doğrultuda dokümanları biraz daha karıştırmak lazım.

Transaction Log Truncation:

Temel olarak loglarımızın birikerek disk üzerinde yer kaplamasını engellemek için kullanacağımız bir kısma geldik. Üç seçeneğimiz var.

Truncate Logs: Backup sonrası loglarıda alır ve orjinal yerdeki loglar truncate olur(alınan kısımlar kesilir ve temizlenir)
Do Not Truncate Logs: Bu seçenekte loglar sunucu üzerinde kaldır. Böylece başka bir backup yazılımı daha kullanıyorsanız, o yazılımda sağlıklı bir şekilde yedekleri alır. Aksi halde logları eksik alacaktır.
Backup Logs Periodically: Bu seçenekte logları yedekleme durumu vardır. SQL server veya Oracle var ise bu tavsiye edilen yöntem. Ayrıntılı şekilde ileride gireceğim(unutmazsam :) ).

Copy Only Backup:

Bazı yerlerde MS SQL veritabanlarının yedeğinin SQL üzerinden veya 3. parti programlarla alınması gerekir. Bu durumda veeam copy-only backup seçeneği devreye girer. Veeam VSS_BS_COPY metodu ile snapshot alır. Bu yolla alınan yedek normal veritabanı yedekleme mekanizmasından bağımsız çalışır. Orada alınan yedekleme geçmişinde görünmez veya müdahale etmemiş olur.

Veeam Backup Catalog:

Daha önce file indeks özelliğinden bahsetmiştik. Bir sunucunun yedeğini alırken indekslemeyi aktif edersek, veeam o sunucudaki dosyaların symlink(dosya yollarını)'lerini bir katalog dosyası içerinde saklar. Bu katalog dosyası C:\VBRCatalog klasörü içerisinde bulunur.  Katalog servisi 2 noktada bulunabilir

Backup Enterprise Manager Server: Global bir katalog servisi bulunur tüm backup server larda bulunan kataloglar burada toplanır.
Backup server: Lokal bir katalog servisidir.

Yine yazalım. Bu indeksleme işi mecburi değildir. Sunucudaki dosyaları gezinmek içiğn kullanılır. Aktif edilmese bile yedek dosyasının içerisinde yine gezinti yapabilirsiniz. Zaten her önünüze gelen sunucuda açmayın. Sonuçta sunucuya bağlanıp tüm dosyaların indeksini çıkarma işlemi yapılıyor. Sunucunuzda milyonlarca dosya varsa nasıl bir etkisi olur ben pek bilemedim. İşinizi çok rahatlatacaksa kullanın.

• İndeksleme işi backup sırasında tamamlanmaz ise, veeam yedeği alır ama indeks işlemi içerde devam eder.
• İndeksleme yapılan sunucuda app-aware da seçiliyse, indeksleme alınan snapshot üzerinde gerçekleşir. Böylece asıl çalışan sunucuda herhangi bir yük oluşmaz. İndeks dosyası da yedeği alınan haline göre olur.

Persistent VM Snapshots:

App-aware işlemleri sırasında Veeam'in VSS kullanarak yedekleme işlemini tutarlı hale getirdiğini biliyorduk ama Microsoft tarafından koyulan bazı sınırlar var.Exchane için 20sn diğer uygulamalar için 60Sn olan bu durdurma sınırı yüzünden, işlemleri uzun süren uygulamalarımız olursa bir yol bulmak gerekli. İşte bu noktada persistent VM snapshot mekanizması devreye giriyor.

• Normal VSS ile yedekleme yapılırken, diyelimki exchange de 20sn lik süre aşıldı. Bu noktada Veeam VSS writer devreye giriyor ve işlem bitene kadar kontrolü elinde tutuyor. Veeam VSS writer, gerekli süre kadar dondurma operasyonunu uzatıyor.Exchange verisi tutarlı hale geldiğinde kontrol tekrar Microsoft VSS'e geçiyor ve sistem diski hariç diğer diskleri persistent VSS snapshot şeklinde oluşturuyor.
• Job normal şekilde işliyor.İşlem bittiğinde, Veeam, Microsoft VSS e diyorki; "Bu persistent snapshot'ı production ortamından kaldır". Ama bu persistens snapshot backup içerisnde kalıyor.
• Yedekten dönüş işlemi sırasında Veeam, yedeğin içerisinde bulunan persistent snapshot dan dönüşüşü tutarlı şekilde gerçekleştiriyor.

Persistent VSS işleminde bazı sınırlamalar bulunmaktadır.

• Exchange 2010, 2013 veya 2016 olmalıdır.
• VM domain controller rolüne sahip olmamalıdır.
• Exchange veritabanı ve logları, sistem diski dışında bir disk üzerinde bulunmalıdır. Sistem diski çökmeye karşı tutarlı yedeklenmektedir. Transaction olarak tutarlı yedekleme ise veritabanının olduğu diskte gerçekleşmektedir.

Microsoft SQL Log yedeklemesi ve geri dönüşü:

Yazının önceki bölümlerinde bahsetmiştik. Loglar, yedekleme bittikten sonra ayrıca işlenmektedir diye.SQL sunucularını imaj seviyesinde yedekleyip, periyodik olarak logları alabilirsiniz. Böylece imajdan dönüş sonrası Veeam SQL Explorer yardımıyla veritabanı dönüşü gerçekleşebilir.

• Parent Backup Job: Parent backup da imaj seviyesinde yedek alınır.Burada yedeğe bir isim verilir. Örneğin "DB_Backup"
• Child Backup Job: Transaction log yedeklemesi.Burada isimlendirme, ana isme ek yapılarak oluşturulur. Örneğin "DB_Backup_Transaction_Log_Backup". Eğer bir yedekleme işleminde SQL var ise ve transaction log yedeklemesi aktif edilmiş ise, Veeam otomatik olrak bu child backup job'u oluşturur. Bu yedeğin session durumu Veeam konfigürasyon veritabanında tutulut ve oradan görülebilir.
• Parent Job normal yedeklemelerdeki gibi çalıştırılır. Child ise parant çalıştıktan sonra otomatik tetiklenir.
• Transaction yedekleme arka planda kalıcı olrak devam eder ve varsayılan olarak 15 dakika da bir alınır. Her bir session ise, iki parent job arasında oluşan kısımdır.
• Her session, parent job başladıktan sonra başlar ve parent job'un diğer başlangıcından önce sona erdirilir.
• Her session sona erdiğinde sunucudaki runtime process dosyaları kaldırılır ve yeni session ile tekrar yüklenir.
• Trensaction loglar VLB formatında saklanır ve imaj seviyesindeki yedeklerle yanyana tutulur.
• Logların retentionlarını imajlarla beraber veya ayrı(gün belirterek) ayarlayabilirsiniz. Gün belirtilerek nerede kullanılabilir? Storage üzerinde tasarruf yapmak istediğinizde. Geçmişe yönelik daha fazla log olacaktır ama imaj yedek az olduğu için daha az yer kaplayacaktır. 

Aslında çalışma mekanizması ve ayrıntılı menü ayarları da var ama kendi sistemimizde bu kadar detaylı ince ayar çekmeye gerek olmayan büyüklükte bir veritabanımız olduğu için bu kısımları atlıyorum. Belki ileride kullanırsak, bu kısmı düzenleyebilirim.

Backup Job Scheduling:

Schedule yani yedeklerin veya replikasyounun zaman içerisinde çalışma planının yapılmasında bir çok seçeneğimiz mevcut. Bunları sırayla inceleyelim.

• Schedule da job'ın günlük, haftanın belli günlerinde veya ayın belli günlerinde çalışmasını ayarlayabilirsiniz. Saat bilgisi de vermeniz gerekiyor.
• Belli bir zaman aralığını ayarlayabilirsiniz. Örneğin 4 saatte bir gibi. Bu durumda referans nokta gece 12:00 A.M olacaktır. Bu örnekteki yedekler 00:00 04:00 08:00 şeklinde ilerleyecektir. Offset girebilirsiniz. Örneğin 10dk offset ayarladık. 00:15 04:15 08:15 şekline dönüşür.Eğer bir Job bitmeden sonraki yedekleme saati gelirse, Job bittikten sonra aralığa göre devam eder. Şöyleki, 00:10 da yedek alındı ve 5 saat sürdü, sonraki, yedek 08:15 de olur.
• Job'ın devamlı çalışması şeklinde ayarlama var ki bu bana ilginç geldi. Job biter bitmez tekrar başlıyor. Kritik uygulamalarda kullanılabilir ama etkisine bakmak lazım. Proxy devamlı meşgul olacak mesela. Bizim gibi tek proxy li sistemlerde nasıl bir etki olur, vSphere de nasıl bir etki olur gibi kısımları görmek lazım.
• Zincir Job şeklindeki yöntemde ise bir job bitince diğeri başlar. İleride anlatacağımız SureBackup job'ını normal yedekleme Job'ından sonraya koyup, yedeğin doğru olup olmadığını kontrol ettirebiliriz.Bu zincir işleminde belli bir Job'ı manuel çalıştırmak isterseniz Veeam zincirleme başlatayım mı? yoksa sadece bu Job mı olsun? diye soracaktır. Duruma göre sadece bir Job yedeğini alabilirsiniz.
• Zincir schedule de bazı durumlara dikkat etmek lazım. Joblardan biri uzun sürerse diğer jobların tahmin edilen alınma zamanları sarkabilir.Yine bir job da hata çıkarsa, o job daki retry süresi yüzünden sarkma yaşanabilir. Örneğin haftasonuna syntetic backup ayarladınız ama zincirin çalışması devam ediyorsa alınmayabilir. Job'lar sırayla çalışacağı için proxy ve diğer kaynaklar efektif kullanılmayabilir.Dikkatli yapmak lazım :)
• Zincirleme schedule dışında tüm jobların aynı anda başlaması gibi bir seçenek de kullanabilirsiniz.Bunun için "paralel data processing" özelliğini açmalı ve backup proxy ve repository lerdeki aynı anda yapılacak iş sayısını sınırlamalısınız.

Job Retry:

• Normalde bir Job bir şekilde başlayamıyorsa varsayılan olarak 3 defa denenir. Bu sayıyı değiştirebilirsiniz.
• Veeam retry işlemini, eğer bir job içerisinde yedek alamadığı sunucular varsa gerçekleştirir. Uyarı vermiş ve yedeği de alınmış sunucular için bu işleme girmez. Retry sırasında sadece yedeği alınmayan VM ler denenir.
• Manuel başlatılan Job lerda retry kuralları uygulanmaz.
• Retry işlemlerinde bir noktaya daha dikkat etmek lazım. Mesala 2 tane VM olsun. Vm1 ve Vm2. Vm1 full yedeklendi ama Vm2 yedek alınamadı.3 defa retry oldu yine alınamadı. Daha sonra sonraki yedek zamanı geldi. Yine Vm1 alındı. Vm2 denen di ve başarılı oldu. Durum ne olur? Hemen açıklayalım

          VBK da yani fullerin olduğu yedek dosyasında Vm1 olur ve Vm2 ye ait bir veri bulunmaz. Bir sonraki incremental backup dosyasının içinde Vm1 in incremental verileri ile Vm2 nin full yedeği bulunur. 

Backup Windows:

Adından da anlaşılacağı üzere bir çeşit pencere. Bu pencerenin yatay çizgisi gün içerisindeki saatleri, dikey olanı ise haftanın günlerini gösteriyor. Sinemada koltuk seçer gibi alanları mouse ile seçiyorsunuz. Mor ile işaretli alanlar schedule'un çalışacağı zamanları, beyaz olanlar ise çalışmaması gereken zamanları gösteriyor.

Backup windows sadece iletim proseslerini ve sağlık kontrol operasyonlarını etkiler. Diğer operasyonlar hedef noktada olacağı için backup window dan etkilenmezler.

Manuel İşlemler:

Manuel yedek almada, Veeam, normal yedekleme zincirine göre bir yedek alır.
Manuel durdurma kısmında ise 2 seçenek var.

• İmmediatelly ve gracefully. Immediatelly de, yeni bir restore noktası oluşturulmadan işlem hemen durdurulur. Alınmış bir snapshot varsa silinir ama alınmış bir yedek var ise, ona işlem yapılmaz.
• Gracefully de ise başlanılan yedekleme işlemi tamamlanır ve öyle durdurulur.Gracefully'nin uygulanmadığı yerler vardır.
• File copy jobs
• Backup copy jobs
• Quick Migration Job(Quick migration sırasında; Veeam, bütün VM leri aynı task içerisinde işler)
• Restore işlemleri.

Eğer Job başlamadan gracefully durdurma tetiklenirse, job failed şeklinde hata verir ve başlamaz.

Backup Dosyaları için Healt Check(Sağlık kontrolü):

Veeam'e "yedeklenen son kısım için health check yap" gibi bir komut verebilirsiniz.Bu health check sırasında metadatalarda CRC ve data blocklarında hash testleri yapılır. Periyodik olarak health check yaptırmak istiyorsanız, backup job içerisinde ilgili seçeneği seçip schedule girmeniz gerekir. Schedule girmez iseniz, varsayılan olarak her ayın son cuma günü health check yapılır.

Health check de değişik bir durum var. Health check schedule de haftann günlerini seçebiliyorsunuz. Seçili günlerde job a ait bir yedekleme var ise ilkinden sonra health check yapıp diğerlerine işlem yapmıyor.

Health check, yedekleme zincirindeki en son geri dönüş noktası(restore point) üzerinden health check yapar. Bu nedenle, son dosyada yedekle tamamlanmamış ise, bir önceki restore noktasına bakılır. Böyle bir durum oluşursa health check uzayabilir, çünkü onu test etmesi için önceki tüm yedeklere bakıp zinciri sağlaması gerekir.

Health check aktif full yedekleme yapılırken çalışmaz.Bu yedeklemenin manuel veya otomatik olması bir şeyi değiştirmez.

Herhangi bir VM i yedeklemeye dahil ettiyseniz, Veeam ilk full yedeği alır. Daha sonra ilk incremental yedek sırasında health check yapar.

Compact of Full Backup File:

Forever forward veya reverse zincir kullanıyorsanız, full backup dosyası devamlı işleme maruz kalıyor. Neden? çünkü retention politikasına göre devamlı modifiye edilerek zamanı ayarlanıyor(haftalık full, aylık full senelik full vs). Dolayısı ile veri bloklarında disk üzerinde dağınıklık(fragmentation) oluşuyor. Bunu engellemek için arada compact işlemi yapmak iyi olur. Verilere ulaşım hızlanır. Bu işlem bazı durumlarda yapılamaz. Hemen inceliyelim

• Eğer aktif full yedek veya sentetik full yedekler belli bir zaman çizelgesine göre yapılıyorsa bu işlemi yapamazsınız.
• Aktif full yedekler alınırken yapılamıyor. Aynı şekilde aktif full ile aynı gün alınan yedeklerde de de yapılmıyor çünkü veeam aktfi full yeni oluştu, fragmentation olamaz diye düşünüyor.o Günden sonraki yedek gününde yapıyor işlemini.
• Bu işlem için full yedek dosyası kadar yerin repository de olması lazım. Yardımcı alan olrak kullanılan bu alan yoksa yine yapılamıyor.
• Eğer bir Job içerisine yeni bir VM eklediyseniz. Yeni eklenen VM in ilk incremental işleminde, compact işlemi yapılıyor.
• Eğer bir Job içerisindeki blok ayarlarını değiştirdiyseniz, sonraki full yedeğe kadar herhangi bir compact işlemi yapılmıyor.Sıkıştırma ayarlarını değiştirirseniz, sonraki ilk compact işleminde sıkıştırma seviyesi değiştiriliyor.

NOT: Bir job var ve içerisinden zaman içerisinde çıkartılan VM ler olmuş diyelim. Sonraki compact işleminde bu çıkartılan VM lerin verileri yeni dosyada bulunmaz ve alan kazanılır.

NOT2: Eğer full yedek dosyasında, sadece 1 restore noktasına sahip bir VM var ise ve bu restore noktasıda 7 günden eskiyse, compact işleminde bu VM dışarı çıkartılıp ayrı bir yedek dosyasında tutulur. 2 İstisnası vardır.

• Backup ayarlarında "Remove deleted VM Data" seçili değilse
• Her VM için ayrı dosya kullan seçeneği seçili değilse.

Resume on Disconnect:(Bağlantı koptuktan sonra devam et)

• Yedekleme sırasında ağda meydana gelebilecek bir sıkıntı sonrası bağlantı koparsa, Veeam 15 saniye ile 30 dk aralığındaki kesintiler için bu mekanizmayı çalıştırır.Yedekleme ağ sorunu giderildikten sonra, kaldığı yerden devam eder.
• Yedek devam ederken mevcut restore point e yazmaya devam eder. Yeni bir restore point oluşmaz.
• Devam işleminde disk bazlı düşünülür. Mesala bir VM de 2 disk olsun. 1. diskin 20GB lık kısmı kopyalanınca ağ gitsin. Ağ geri geldiğinde 1. disk devam eder. 2. disk zaten işlem yapılmadığı için normal şekilde yedeklenir.

Snapshot Hunter:

Veeam bilindiği üzere vSphere deki snapshot mekanizmasını sıklıkla kullanıyor. İşte bu kullanım sırasında snapshot kalma olasılığını yoketmek için böyle bir kontrol yapıyor. Aksi halde snapshot'dan dolayı VM lerin performansı düşüp storage dolabilir.

Bu sebepten dolayı her yedekleme veya replikasyon job'ı ile birlikte bu mekanizma çalıştırılır.Bu mekanizma çalışırken 3 ayrı aşamaya kadar uzayabilir.

1.VMware de bulunan normal konsolidasyon komutu çalıştırılır.VMware de bulunan "VMs with the Needs Consolidation" statüsünde olan sunuculardır.
2.Eğer ilk seçenekteki işlemler gerçekleşmez ise Veeam yeni bir snapshot oluşturur ve VMware'e tüm snapshotları sil komutunu gönderir. Burada alınan snapshot quiescence kullanılmadan alınan bir snapshot dır.
3.Yine olmaz ise, bu sefer Quiescen snapshot oluşturup sil komutu gönderir.

Not: Snapshot silmeyi gerektiren 2. ve 3. seçenekler, VMware içerisinde kullanıcı tarafından alınmış bir snapshot var ise uygulanmaz.

Yukarıdaki prosedürler 4 saatte bir toplam 4 defa çalıştırılır.Yine bir düzelme olmaz ise Veeam uyarı e-postası atar.

Snapshot hunter mekazniması ile ilgili bilgileri Veeam konsolu içerisinde History>System kısmında görebilirsiniz.