Data Domain: Data Domain Restorer'larda (DDR'ler) fazla alan kullanımı veya kullanılabilir kapasite eksikliği sorunlarını giderme

 

• Bu, yeni gelen dosyaların/verilerin bulunduğu disk alanıdır ve çoğu DDR dosyası, bir istemci yedekleme uygulaması tarafından silinene veya süresi dolana kadar burada kalır
• Uzatılmış Saklama (ER) veya Uzun Süreli Saklama (LTR) ile yapılandırılmış DDR'lerde, eski dosyaları aktif katmandan arşiv ya da bulut katmanlarına taşımak için veri taşıma işlemi düzenli aralıklarla çalıştırılabilir
• Aktif katmanda silinmiş/taşınmış dosyalar tarafından kullanılan alanı geri kazanmanın tek yolu, çöp toplama/temizleme işlemlerinin (GC) çalıştırılmasıdır

• Aktif katmanın kullanılabilir alanı azalmaya başlayarak aşağıdaki gibi uyarıların/mesajların görüntülenmesine neden olabilir:

• Aktif katman %100 doluluğa ulaşırsa DDR'ye hiçbir yeni veri yazılamaz ve bu da yedekleme/çoğaltma işlemlerinin başarısız olmasına neden olabilir. Bu durumda, aşağıdaki gibi uyarılar/mesajlar görüntülenebilir:

• Bazı durumlarda, dolu hale gelen aktif katman Data Domain Dosya Sistemi'nin (DDFS) salt okunur olmasına neden olabilir ve bu durumda mevcut dosyalar silinemez

• Aktif katmanın neden dolabileceğini açıklamak
• Aktif katmanın fazla kullanılmasının nedenini belirlemek için gerçekleştirilebilecek bir dizi basit denetimi ve ilgili düzeltme adımlarını açıklamak

• Bu makale eksiksiz değildir (yani, bir DDR'nin aktif katmanının bu belgede ele alınmayan bir nedenle fazla kullanıldığı/dolduğu az sayıda durum olabilir) ancak en sık görülen nedenleri/sorunları kapsaması amaçlanmıştır
• Arşiv veya bulut katmanlarının fazla kullanımı, bu makale kapsamında ele alınmamıştır

  Bir DDR'nin aktif katmanı, birkaç nedenle beklenenden daha yüksek düzeyde kullanılıyor olabilir:

• Yedekleme dosyaları/kaydetme kümeleri, yanlış saklama ilkesi veya yedekleme uygulama yapılandırması nedeniyle istemci yedekleme uygulamaları tarafından doğru şekilde silinmemiştir ya da bunların süreleri dolmamıştır
• Çoğaltma gecikmesi, büyük miktarda eski verinin replikalara çoğaltma işlemini beklediğinden aktif katmanda tutulmasına neden oluyordur
• Aktif katmana yazılan verilerin sıkıştırma oranı, beklenen genel orandan düşüktür
• Sistem doğru şekilde boyutlandırılmamıştır; yani sistemde depolamaya çalışılan veri miktarı için çok küçüktür
• Yedekler çok sayıda küçük dosyadan oluşuyordur; bu dosyalar başlangıçta yazıldığında beklenenden çok daha fazla alan tüketir ancak bu alan, temizleme/çöp toplama sırasında geri kazanılacaktır
• ER/LTR ile yapılandırılan sistemlerde veri taşıma işlemi, düzenli aralıklarla çalıştırılmadığından arşiv/bulut katmanlarına taşınması gereken dosyalar aktif katmanda kalıyordur
• Temizleme/çöp toplama işlemi düzenli aralıklarla çalıştırılmıyordur
• DDR'deki fazla veya eski mtree anlık görüntüleri, temizleme işleminin silinen dosyalardan/verilerden alan kazanmasını önlüyordur

1. Adım: Aktif katmanı temizleme işleminin çalıştırılıp çalıştırılmayacağına karar verin

Data Domain İşletim Sistemi (DDOS), aktif katman için "Cleanable GiB" adlı bir sayaç çalıştırır. Bu, temizleme/çöp toplama işlemini çalıştırarak aktif katmanda ne kadar fiziksel alanın (post-comp) geri kazanılabileceğini tahmin eder. Bu sayaç, "filesys show space"/"df" komutlarıyla gösterilir:
 
Aşağıdakilerden biri söz konusuysa:

• "Cleanable GiB" değeri büyükse
• DDFS %100 doluysa (ve bu nedenle salt okunursa)

Bu belgedeki diğer adımlara geçmeden önce temizleme işleminin yürütülmesi ve tamamlanmasının beklenmesi gerekir. Temizleme işlemini başlatmak için "filesys clean start" komutu kullanılmalıdır; örneğin:
 
Temizleme işleminin beklendiği gibi başlatıldığını onaylamak için "filesys status" komutu kullanılabilir; örneğin:
 
Unutmayın:

• Temizleme işlemi başlatılamıyorsa lütfen daha fazla yardım için sözleşmeli destek sağlayıcınıza başvurun çünkü bu, sistemin temizleme işlemini devre dışı bırakmasına neden olan "eksik segment hatası" ile karşılaşmış olabileceğini gösterir
• Temizleme işlemi zaten çalıştırılıyorsa bunu çalıştırmayı denediğinizde aşağıdaki mesaj görüntülenir:

• Temizleme işlemi kopyalama aşamasına (varsayılan olarak DDOS 5.4.x ve önceki sürümlerde 9. aşama, DDOS 5.5.x ve sonraki sürümlerde 11. aşamadır) gelmeden aktif katmanda hiçbir alan serbest bırakılmaz/geri kazanılmaz. Temizleme işlemi tarafından kullanılan aşamalara ilişkin daha fazla bilgi için bkz. https://support.emc.com/kb/446734
• Temizleme işlemi, "Cleanable GiB'" tarafından belirtilen değer aslında bir tahmin olduğu için bu miktardaki alanın geri kazanılmasını sağlayamayabilir. Bu konu hakkında daha fazla bilgi için bkz. https://support.emc.com/kb/485637
• Temizleme işlemi tek bir çalıştırmada tüm olası alanın geri kazanılmasını sağlayamayabilir. Bunun nedeni, büyük veri kümeleri içeren DDR'lerde temizleme işleminin, dosya sisteminin en gereksiz verileri içeren bölümünde (temizleme işleminin en kısa sürede en çok alan kazanabileceği şekilde) çalışmasıdır. Bazı senaryolarda temizleme işleminin, tüm olası alanın geri kazanılmasını sağlamak için birden fazla kez çalıştırılması gerekebilir
• "Cleanable GiB" değeri çok büyükse bu, temizleme işleminin düzenli aralıklarla çalışmadığını gösteriyor olabilir. Bir temizleme işleminin planlandığından emin olun:

Temizleme işlemi tamamlandıktan sonra kullanım sorunlarının çözülüp çözülmediğini belirlemek için "filesys show space"/"df" komutlarını kullanın. Kullanım oranı hâlâ yüksekse bu makaledeki diğer adımları uygulayın.

2. Adım: Kaynak çoğaltma bağlamlarında büyük miktarda çoğaltma gecikmesi olup olmadığını kontrol edin

Yerel Data Domain çoğaltma işlemi, "çoğaltma bağlamları" kavramı etrafında tasarlanmıştır. Örneğin, sistemler arasında veri çoğaltılmasına ihtiyaç duyulduğunda:

• Kaynak ve hedef DDR'lerde çoğaltma bağlamları oluşturulur
• Bağlamlar başlatılır
• Başlatma işlemi tamamlandıktan sonra sistemdeki verilerin senkronize halde kalması için çoğaltma işlemi düzenli aralıklarla kaynaktan hedefe güncellemeler/deltalar gönderir

Kaynak çoğaltma bağlamının gecikmesi, eski verilerin kaynak sistemdeki disk üzerinde tutulmasına neden olur (geciken çoğaltma bağlamlarının hedef sistemde aşırı kullanıma neden olmayacağını unutmayın):

• Dizin çoğaltma bağlamları (sistemler arasında /data/col1/backup altında tek bir dizin ağacı çoğaltılırken kullanılır):

•  Mtree çoğaltma bağlamları (sistemler arasında /data/col1/backup dışındaki bir mtree çoğaltılırken kullanılır):

• Toplama çoğaltma bağlamları (bir DDR'nin tüm içeriği başka bir sisteme çoğaltılırken kullanılır):

 Çoğaltma bağlamlarının gecikip gecikmediğini belirlemek için aşağıdaki adımlar gerçekleştirilmelidir:

• Geçerli sistemin ana bilgisayar adını belirleyin:

• Geçerli sistemdeki tarihi/saati belirleyin:

• Sistemde yapılandırılmış olan çoğaltma bağlamlarını "synced as of time" (şu saat itibarıyla senkronize) bilgisiyle birlikte listeleyin. İlgili bağlamların, "destination" (hedef) bilgilerinde geçerli sistemin ana bilgisayar adının BULUNMADIĞINI (geçerli sistemin kaynak olduğu anlamına gelir) ve "synced as of time" (şu saat itibarıyla senkronize) bilgisinin oldukça eski olan bağlamlar olduğunu unutmayın:

Geçerli sistemin kaynak olduğu ve büyük ölçüde gecikme gösteren bağlamlar veya artık gerekli olmayan bağlamlar kaldırılmalıdır. Bu, kaynak ve hedef sistemde aşağıdaki komut çalıştırılarak gerçekleştirilebilir:
 
Örneğin, yukarıda gösterilen "interesting" (ilgili) bilgisi bulunan bağlamları kaldırmak için kaynak ve hedefte aşağıdaki komutlar çalıştırılır:
 
Unutmayın:

• Bağlamlar kaldırıldığında aktif katmanda olası alanı geri kazanmak için aktif katman temizleme işleminin çalıştırılması gerekir
• Mtree çoğaltma işlemi kullanılıyorsa bağlamlar kaldırıldığında mtree çoğaltma anlık görüntüleri diskte kalabilir. Temizleme işlemini çalıştırmadan önce gereksiz anlık görüntülerin süresinin dolması için 5. adımın uygulandığından emin olun
• Kaynak/hedef mtree verileri arşiv veya bulut katmanlarına taşıyacak şekilde yapılandırıldıysa ilgili mtree çoğaltma bağlamları dikkatli şekilde kaldırılmalıdır çünkü bu bağlamları, ileride yeniden oluşturmak/başlatmak mümkün olmayabilir. Bunun nedeni, bir mtree çoğaltma bağlamı başlatıldığında kaynak sistemde bir mtree anlık görüntüsünün oluşturulması ve söz konusu anlık görüntünün mtree'deki tüm dosyaların ayrıntılarını (katmana bakılmaksızın) içermesidir. Bu anlık görüntü, daha sonra hedefin aktif katmanına tam olarak çoğaltılır. Sonuç olarak, hedefin aktif katmanının tüm mtree verilerini kaynaktan almak için yeterli boş alanı yoksa başlatma işlemi tamamlanamaz. Bu sorunla ilgili daha fazla bilgi için lütfen sözleşmeli destek sağlayıcınıza başvurun
• Bir toplama çoğaltma bağlamı kaldırıldığında bağlam, öncelikle hedef DDR'de DDFS örneği yok edilmeden (ve bu sistemdeki tüm veriler kaybolmadan) yeniden oluşturulamaz/başlatılamaz. Sonuç olarak, kaynaktan gelen tüm veriler hedefe fiziksel olarak tekrar çoğaltılması gerektiğinden, sonraki başlatma işlemi çok uzun sürebilir/çok fazla ağ bant genişliği kullanabilir

3. Adım: Artık gerekli olmayan mtree'leri kontrol edin

DDFS'nin içerikleri mantıksal olarak mtree'lere bölünür. Ayrı yedekleme uygulamalarının/istemcilerin ayrı mtree'lere yazıması sık görülen bir durumdur. Bir yedekleme uygulaması kullanımdan kaldırılırsa artık DDR'ye veri yazamaz veya DDR'den veri silemez. Bu da eski/gereksiz mtree'lerin sistemde kalmasına neden olabilir. Bu mtree'lerdeki veriler, sonsuza kadar var olmaya devam ederek DDR'deki disk alanını kullanır. Sonuç olarak, bu tür gereksiz mtree'lerin silinmesi gerekir. Örneğin:

• Sistemdeki mtree'lerin listesini edinin:

• Artık ihtiyaç duyulmayan mtree'ler "mtree delete" komutuyla silinmelidir; örneğin:

• Silinen mtree tarafından diskte kullanılan alan, aktif katmanın temizleme/çöp toplama işlemini bir sonraki çalıştırmasında geri kazanılır.

Unutmayın:

• Mtree çoğaltma işleminin hedefleri olan mtree'lerin (yani mtree listesinin çıktısında RO/RD durumuna sahip olanlar) ilgili çoğaltma bağlamı, mtree silinmeden önce kaldırılmalıdır
• DDBoost mantıksal depolama birimleri (LSU'lar) veya sanal bant kitaplığı (VTL) havuzları olarak kullanılan mtree'ler, "mtree delete" komutuyla silinemeyebilir. Bu tür mtree'leri silme konusunda daha fazla ayrıntı için Data Domain Yönetici Rehberine bakın
• Saklama kilidi için yapılandırılan mtree'ler (ör. RLCE veya RLGER durumuna sahip) silinemez. Mtree'deki her bir dosyanın saklama kilidi geri alınmalı ve bunlar ayrı ayrı silinmelidir. Konuyla ilgili daha fazla ayrıntı için Data Domain Yönetici Rehberine bakın

4. Adım: Eski/gereksiz mtree anlık görüntülerini kontrol edin

Data Domain anlık görüntüsü, ilgili mtree'nin belirli bir noktadaki anlık görüntüsünü temsil eder. Sonuç olarak:

• Anlık görüntü oluşturulduğunda mtree'de mevcut olan dosyalar, anlık görüntü tarafından referans alınır
• Bu dosyalar kaldırılmış/silinmiş olsa bile anlık görüntü var olmaya devam ederken temizleme işlemi bunların diskte kullandığı alanı geri kazanamaz çünkü anlık görüntüdeki dosyanın kopyasına daha sonra erişilme ihtimali nedeniyle verilerin sistemde kalması gerekir

Herhangi bir mtree'nin eski/gereksiz anlık görüntülere sahip olup olmadığını belirlemek için aşağıdaki adımlar gerçekleştirilmelidir:

• 3. adımda gösterilen "mtree list" komutunu kullanarak sistemdeki mtree'lerin listesini edinin
• Her mtree için mevcut olan anlık görüntülerin listesini "snapshot list" komutuyla edinin:

• Anlık görüntüler mevcut olduğunda aşağıdaki anlık görüntüleri belirlemek için "'snapshot list mtree [mtree name]" komutunun çıktısını kullanın:

• Anlık görüntü listesi komutu tekrar çalıştırılırsa bu anlık görüntüler artık expired (süresi geçmiş) olarak listelenir:

Unutmayın:

• Tek bir anlık görüntünün veya bir anlık görüntüler kümesinin diskte ne kadar fiziksel veri tuttuğunu belirlemek mümkün değildir. Bir anlık görüntüyle ilişkili "alan" için tek değer, anlık görüntü oluşturulduğunda mtree'nin sıkıştırılmadan önceki (mantıksal) boyutunun göstergesidir (yukarıdaki çıktıda gösterildiği gibi)
• "REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS" olarak adlandırılan anlık görüntüler mtree çoğaltma işlemi tarafından yönetilir ve normal koşullarda, sürelerinin manuel olarak doldurulmaması gerekir (çoğaltma işlemi, söz konusu anlık görüntüler artık gerekli olmadığında bunların süresini otomatik olarak sona erdirir). Bu tür anlık görüntülerin çok eski olması, ilgili çoğaltma bağlamının büyük olasılıkla büyük bir gecikme yaşadığını (2. adımda anlatıldığı gibi) göstermektedir
• "REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS" adlı anlık görüntüler, mtree çoğaltma bağlamı kaldırıldığı zaman mtree çoğaltma işlemi tarafından oluşturulur. Bunların amacı, kaldırılan bağlamın daha sonra yeniden oluşturulması durumunda (örneğin bağlam yanlışlıkla kaldırılırsa) çoğaltma verilerinin tamamen yeniden senkronize edilmesini önlemek üzere kullanılabilmesidir. Çoğaltma işlemi yeniden oluşturulmazsa bu bağlamların süresi, yukarıda açıklandığı gibi manuel olarak doldurulabilir
• Süresi dolan anlık görüntüler, temizleme/çöp toplama işlemi bir daha çalıştırılana kadar sistemde var olmaya devam eder. Bu noktada fiziksel olarak silinirler ve "snapshot list mtree [mtree name]" çıktısından kaldırılırlar. Daha sonra temizleme işlemi, bu anlık görüntülerin diskte kullandığı alanların geri kazanılmasını sağlayabilir

5. Adım: Sistemde beklenmeyen sayıda eski dosya olup olmadığını kontrol edin

DDR'den gelen otomatik destekler, DDR'deki dosyaların yaşa göre dökümünü gösteren histogramlar içerir:
 
Bu, sistemde istemci yedekleme uygulaması tarafından beklendiği gibi silinmemiş veya süresi dolmamış dosyalar olup olmadığını belirlemek için faydalı olabilir. Örneğin yukarıdaki sistem, herhangi bir dosya için maksimum saklama süresinin 6 ay olduğu bir yedekleme uygulaması tarafından yazıldıysa DDR'de 6 aydan daha eski yaklaşık 80.000 dosya olduğundan yedek uygulamasının dosyaları beklendiği şekilde süre silmediği ya da bunların sürelerini doldurmadığı hemen anlaşılmaktadır.

Unutmayın:

• Tüm dosya süre sonu/silme işlemlerini yapmak yedekleme uygulamasının sorumluluğundadır
• DDR otomatik olarak asla dosyaların süresini doldurmaz veya dosyaları silmez. Yedekleme uygulaması açıkça bir dosyanın silinmesi talimatını vermediği sürece dosya sonsuza kadar DDR'de kalarak alan kaplamaya devam eder

Sonuç olarak, bu tür sorunlar öncelikle yedekleme uygulaması tedarikçisinin destek ekibi tarafından araştırılmalıdır.

Gerekirse Data Domain desteği aşağıdaki amaçlarla ilave rapor sunabilir:

• DDR'deki tüm dosyaların yaşa göre sıralanmış şekilde adını/değişiklik tarihini vermek (böylece eski verilerin adı/konumu belirlenebilir)
• Dosya yaşı histogramlarını, aktif/arşiv/bulut katmanı için ayrı raporlara bölmek (ER/LTR özellikleri etkin olduğunda)

Bunu gerçekleştirmek için:

• Bu belgenin notlar bölümünün "Collecting sfs_dump" (sfs_dump toplama) paragrafında anlatıldığı şekilde kanıt toplayın
• Sözleşmeli destek sağlayıcınızdan bir servis isteği açın

Eski/gereksiz dosyalar silindiğinde aktif katmandaki alanı fiziksel olarak geri kazanmak için aktif katman temizleme/çöp toplama işleminin çalıştırılması gerekir

6. Adım: Çok sayıda küçük dosya içeren yedeklemeleri denetleyin

DDFS küçük dosyaları, (aslında boyutu yaklaşık 10 MB'den küçük olan dosyalardır) tasarımları gereği DDR'ye ilk yazıldıklarında çok fazla alan tüketebilir. Bunun nedeni, küçük dosyaların disk üzerinde birden çok 4,5 MB boyutunda bloklar halinde ayrı ayrı yer kaplamasına neden olan "SISL" (Stream Informed Segment Layout) mimarisidir. Örneğin 4 KB boyutunda bir dosya, ilk yazıldığında 9 MB'ye kadar fiziksel disk alanı tüketebilir.

Bu yüksek alan daha sonra (küçük dosyalardaki veriler daha az sayıda 4,5 MB boyutunda bloklara toplandığı için) temizleme/çöp toplama işlemi çalıştırıldığında geri kazanılır ancak bu tür yedeklemelerin çalıştırılması, daha küçük DDR modellerinin fazla kullanılmasına veya dolmasına neden olabilir.

Otomatik destekler, dosyaların boyutlarına göre düzenlenmiş histogramlarını içerir; örneğin:
 
Çok fazla sayıda küçük dosya yazan yedeklemeler olduğuna dair kanıt varsa sistem, her temizleme/çöp toplama işlemi başlangıcının arasında kullanımın büyük ölçüde artmasından etkileniyor olabilir. Bu senaryoda, yedekleme yönteminin küçük dosyalar DDR'ye yazılmadan önce hepsinin tek bir büyük arşive (ör. tar dosyası) eklendiği bir yöntemle değiştirilmesi tercih edilir. Böyle bir arşivin sıkıştırılmaması veya şifrelenmemesi gerektiğini unutmayın (aksi takdirde, ilgili verilerin sıkıştırma oranı/tekilleştirme oranı zarar görür).

7. Adım: Tekilleştirme oranının beklenenden düşük olmadığından emin olun

Bir DDR'nin temel amacı, aygıt tarafından alınan verileri tekilleştirmek ve sıkıştırmaktır. Tekilleştirme/sıkıştırma oranı, büyük oranda sistemin kullanım durumuna ve sahip olduğu verilerin türüne bağlıdır ancak birçok durumda, kavram testi veya benzerinin kanıtı üzerinden elde edilen sonuçlara göre "beklenen" genel bir sıkıştırma oranı vardır. Sistemin geçerli genel sıkıştırma oranını belirlemek (ve böylece beklentileri karşıladığından emin olmak) için "filesys show compression" komutu kullanılabilir. Örneğin:
 
Yukarıdaki örnekte, sistem aktif katman için 65,3 kat genel sıkıştırma oranı sağlıyor (bu, son derece iyi bir orandır). Ancak bu değer, genel sıkıştırma oranının beklentileri karşılamadığını gösterirse daha fazla inceleme gerekli olabilir. Beklenenden düşük sıkıştırma oranını araştırmanın, birçok temel nedenden kaynaklanabilecek karmaşık bir konu olduğunu unutmayın. Detaylı araştırma hakkında daha fazla bilgi için lütfen şu makaleye bakın: https://support.emc.com/kb/487055

8. Adım: Sistemin toplama çoğaltma işleminin kaynağı olup olmadığını kontrol edin

Toplama çoğaltma işlemini kullanırken kaynak sistem, hedeften fiziksel olarak büyükse kaynak sistemin boyutu, hedefin boyutuyla eşleşecek şekilde yapay olarak sınırlandırılır (yani, kaynaktaki diskte kullanılamaz olarak işaretlenen bir alan olur). Bunun nedeni, toplama çoğaltma işlemini kullanırken hedefin, kaynağın blok düzeyinde bir kopyası olması gerekmesidir. Diğer yandan kaynak, hedeften fiziksel olarak daha büyükse kaynağa fazla veri yazılması ve (zaten dolu olduğundan) bunların hedefe çoğaltılamaması ihtimali vardır. Bu senaryo, kaynağın boyutu hedef ile eşleşecek şekilde sınırlandırılarak önlenir.

• 2. adımdaki komutları kullanarak sistemin toplama çoğaltma işlemi için bir kaynak olup olmadığını belirleyin. Bunu yapmak için "replication status" komutunu çalıştırın ve "col://" (toplama çoğaltma işlemini belirtir) ile başlayan ve hedefte yerel sistemin ana bilgisayar adını İÇERMEYEN (bu sistemin, çoğaltma bağlamı için bir kaynak olabileceğini belirtir) bir çoğaltma bağlamı olup olmadığını belirleyin
• Sistem, toplama çoğaltma işleminin kaynağıysa iki sistemde de oturum açarak ve "filesys show space" komutunu çalıştırarak her bir sistemin aktif katmanının boyutunu kontrol edin ve ikisinde de aktif katman "post-comp" değerini karşılaştırın
• Kaynak, hedeften dikkate değer bir oranda daha büyükse aktif katmanının boyutu yapay olarak sınırlandırılır
• Kaynaktaki tüm alanın veriler için kullanılabilmesini sağlamak amacıyla aşağıdakiler gerçekleştirilmelidir:

9. Adım: Veri taşıma işleminin düzenli olarak yapıldığından emin olun

DDR, Uzatılmış Saklama (ER) veya Uzun Süreli Saklama (LTR) ile yapılandırıldıysa ikinci bir depolama katmanına (ER için arşiv katmanı ya da LTR için bulut katmanı) sahip olacaktır. Bu senaryoda büyük olasılıkla veri taşıma ilkeleri, mtree'ler için uzun süreli saklama gerektiren daha eski/değiştirilmeyen veriler, aktif katmandan alternatif bir depolama katmanına taşınacak şekilde yapılandırılmıştır. Böylece, aktif katmanda bu dosyalar tarafından kullanılan alan, temizleme/çöp toplama işlemiyle fiziksel olarak geri kazanılabilir. Veri taşıma ilkeleri yanlış yapılandırılırsa veya veri taşıma işlemi düzenli olarak çalıştırılmıyorsa eski veriler aktif katmanda beklenenden daha uzun süre kalır ve diskte fiziksel alan kullanmaya devam eder.

• Öncelikle "filesys show space" komutunu çalıştırarak ve arşiv veya bulut katmanının olup olmadığını kontrol ederek sistemin ER ya da LTR için yapılandırıldığından emin olun. Bu alternatif depolama katmanlarının kullanılabilir hale gelmesi için "post-comp" boyutları > 0 GB olmalıdır:

• Sistem, ER/LTR ile yapılandırılırsa mtree'ler için veri taşıma ilkelerini denetleyerek bunların uygun olduğundan ve eski verilerin alternatif depolama katmanına gönderileceği şekilde ayarlandığından emin olun:

• Sistem, ER/LTR ile yapılandırıldıysa veri taşıma işleminin, dosyaların/verilerin aktif katmandan alternatif depolama alanına fiziksel olarak taşınması için düzenli aralıklarla çalıştırılacak şekilde planlandığından emin olun:

• Sistem, ER/LTR için yapılandırıldıysa veri taşıma işleminin en son çalıştırıldığı zamanı denetleyin:

• Veri taşıma işlemi tamamlandığında, aktif katmanda taşınan dosyaların kullandığı alanın boşaltıldığından emin olmak için aktif katman temizleme işlemi (veri taşıma işlemi tamamlandığında otomatik olarak başlayacak şekilde de yapılandırılabilir) çalıştırılmalıdır:

10. Adım: Etkin katmana ilave depolama alanı ekleme

Önceki tüm adımlar gerçekleştirilip aktif katman temizleme işlemi tamamlandıysa ancak aktif katmanda hâlâ yeterli alan yoksa sistem, aldığı iş yüküne göre doğru şekilde boyutlandırılmamış olabilir. Bu durumda aşağıdakilerden biri gerçekleştirilmelidir:

• Sisteme gelen iş yükünü azaltın. Örneğin:

• Sistemin aktif katmanına ilave depolama alanı ekleyin ve boyutunu genişletin:

Data Domain desteği, aşağıdaki gibi bilgileri gösteren çeşitli raporlar oluşturabilir:

• Belirli bir katmandaki (ör. aktif/arşiv/bulut) tüm dosyaların yaşa göre sıralanmış listesi
• Mtree/ana dizin ağacına göre tahmini boyut ve sıkıştırma oranı
• Belirli bir mtree'deki tüm dosyaların yaşa göre sıralanmış listesi
• vb.

Buna izin vermek için aşağıdaki bilgiler toplanmalıdır:

• DDR'den yeni bir destek paketi: Daha fazla bilgi için şu makaleye bakın: https://support.emc.com/kb/323283
• "sfs_dump" veya "sfs_dump -c" çıktısı:

• Bir dosya konumu raporu (sistem, ER veya LTR için yapılandırılmışsa gereklidir):

Yukarıdaki bilgileri toplama konusunda veya bu arşivdeki adımlardan biriyle ilgili yardım almak için sözleşmeli destek sağlayıcınıza başvurun.