NetApp Anlık Görüntüleri Yedek olarak kullanılabilir mi?

Mağazamız, yedeklemeler için NetApp Volume Anlık Görüntülerine çok güveniyor. Verilerimizden bazıları için geleneksel aracı tabanlı teyp yedekleri kullanıyoruz, ancak genel olarak sistemlerimizin çoğu için Anlık Görüntülere güveniyoruz. Ayrıca biz çok titiz bir değişim kontrol politikasını ya da herhangi bir merkezi konfigürasyon yönetimi yok hepsihizmetlerinin sağladığı verilerin yedeklenip yedeklenmediğine bakılmaksızın, çıplak metalden (ve gerçek belgeler olmadan) yeniden oluşturulması gerekir. Doğal olarak, bu, anlık görüntüleri yönetim için çok çekici bir teklif haline getirir, çünkü sadece tüm sunucuyu, kullanıcı verilerini ve yapılandırmayı kurtarabiliriz. NFS tabanlı VMware veri depolarımızın anlık görüntülerini yapmak için NetApp'ın Sanal Depolama Konsolu'nu ve doğrudan misafirlere sunulan ham cihaz eşlemeli (fiziksel) LUN'lar için NetApp'ın SnapDrive'ını kullanıyoruz. Kritik anlık görüntüleri başka bir Filer'e ekliyoruz. Doğal olarak geri yükleme sürecimizi düzenli olarak test ediyoruz.

Yedeklemelerdeki anlık görüntülere güvenmekten rahatsızlık duymuyorum ama rahatsız hissediyorum. Bana göre, bir teknolojinin bir yedekleme stratejisi olarak yeterli görülmesi için aşağıdaki kriterleri karşılaması gerekir:

• Yedek atomik olmalıdır. Yani yedekleme, kurtarılması için başka hiçbir şeye güvenemez.
• Yedeklemenin yedek olduğu sistemden ayrılması gerekir (bant dışı).
• Yedeklemenin kopyalanması veya uzak siteye (site dışı) taşınması gerekir

Anladığım kadarıyla NetApp Anlık Görüntüleri Yazma Yönlendirme (RoW) metodolojisi altında çalışıyor. WAFL dosya düzeni aslında bu olabilir hiç depolama her bloğa referans göstergelerinden bir set (meta?) Kullanır. Anlık görüntü oluşturmak için, sistem bir birimin meta verilerinin bir kopyasını alır ve o birimin ayrılmış alanında saklar. Tüm yazma işlemleri (kreasyonlar / değişiklikler / silme işlemleri) yeni bloklara yönlendirilir. NetApp'ın WAFL'ı bu kadar harika yapan özel sos olması gerekiyordu çünkü okuma ve sonra eski verileri ayrılmış alana yazma ve sonra yeni verilerinizi Eski Kopyala anlık görüntüleri gibi eski üzerine yazmıyorsunuz.

NetApp Birim Anlık Görüntülerinin tam olarak nasıl çalıştığını tam olarak anlayamayacağımı itiraf ediyorum, ancak anlayışım az ya da çok doğru ise NetApp Anlık Görüntüleri yedekleme kriterlerimi karşılayamıyor.

• Bunlar değil atomik. "Anlık görüntü" gerçekten sadece orijinal verilere işaretçi kümesidir. Orijinal veriler artık orada değilse, meta veriler işe yaramaz.
• Anlık görüntü sistemden ayrılmamış. Birisi yanlış birimi silerse, anlık görüntüyü kaybederim. NetApp Filer küçük yavru kedilere patlarsa yedeklemeyi kaybederim. Anlık görüntülerimi başka bir Filer'e taşımak için SnapMirror'u kullanabilirim ama yine de, sadece gerçek verileri değil meta verileri taşıyor. Orijinal birimi kaybedersem, başka bir Filer'a kopyalanan bir anlık görüntünün nasıl yardımcı olacağını göremiyorum.

Birisi NetApp Anlık Görüntülerinin nasıl yedek olarak kabul edileceğini açıklayabilir mi? İyi Öznel cevaplar arıyorum, bu yüzden lütfen durumunuzu gerçekler, referanslar ve deneyimlerle destekleyin. Temel teknolojiyi anlamam yanlışsa, lütfen bunun sonucumu nerede ve neden değiştirdiğini açıklayın. Mağazanız yedek olarak NetApp Anlık Görüntülerine güveniyorsa, lütfen insanların ne tür bir kurtarma politikasını karşılamanız gerektiğini anlayabilmeleri için yeterli bağlamsal bilgileri ekleyin.

Yedeklemeler iki işleve sahiptir.

• Her şeyden önce, kullanılamaz hale gelirse verilerinizi kurtarmanıza izin vermek için oradalar. Bu anlamda, anlık görüntüler yedek değildir. Dosyalayıcıdaki verileri kaybederseniz (birim silme, depolama bozulması, bellenim hatası vb.), Bu verilerin tüm anlık görüntüleri de kaybolur.
• İkincisi ve çok daha yaygın olarak, yedeklemeler, yanlışlıkla silinme gibi rutin şeyleri düzeltmek için kullanılır. Bu kullanım durumunda, anlık olan yedekleri. Bu tür kurtarmayı sağlamanın tartışmasız en iyi yollarından biridir, çünkü verilerin önceki sürümlerini doğrudan kullanıcılarına veya işletim sistemlerine doğrudan dosyalarını okuyabilecekleri bir .snapshot gizli dizini olarak sunarlar.

Saklama politikası yok

Bununla birlikte, anlık görüntülerimiz var ve bunları kapsamlı bir şekilde kullanmamıza rağmen, Netbackup'ta teyp veya veri alanına gecelik artışlar yapıyoruz. Bunun nedeni, anlık görüntülerin bir saklama politikasını güvenilir bir şekilde destekleyememesidir. Kullanıcılara bir hafta boyunca günlük bir ayrıntıdan sonra bir ay boyunca haftalık bir ayrıntıdan destekleyebileceklerini söylerseniz, bu sözleri anlık görüntülerle tutamazsınız.

Anlık görüntülere sahip bir Netapp biriminde, anlık görüntüde bulunan silinen veriler "anlık rezerv" alanı kaplar. Birim doluysa ve bu şekilde yapılandırdıysanız, o anlık görüntü rezervini geçebilir ve kullanılmayan veri alanlarından bazılarını kaplayan anlık görüntülere sahip olabilirsiniz. Birim dolarsa, ayrılmış alandaki verilerle desteklenen tüm anlık görüntüler silinir. Anlık görüntülerin silinmesi yalnızca kullanılabilir anlık görüntü alanı tarafından belirlenir ve saklama politikanız için gerekli olan anlık görüntüleri silmesi gerekiyorsa, bu geçerli olacaktır.

Bu durumu düşünün:

• Düzenli anlık görüntüler ve 2 haftalık saklama gereksinimi içeren tam hacim.
• Anlık görüntüler için kullanılan rezervin yarısının normal değişim oranına göre olduğunu varsayın.
• Birisi çok fazla veri siler (anlık görüntü rezervinden daha fazla), değişim oranını geçici olarak artırır.

Bu noktada, anlık görüntü rezerviniz, OnTap'in anlık görüntüler için kullanmasına izin verdiğiniz veri boş alanının tamamı gibi tamamen kullanılır, ancak henüz anlık görüntüyü kaybetmediniz. Birisi birimi veriyle doldurur doldurmaz, veri bölümünde bulunan tüm anlık görüntüleri kaybedersiniz, bu da kurtarma noktanızı büyük silme işleminden hemen sonra geri iter.

özet

Netapp anlık görüntüleri sizi gerçek veri kaybına karşı korumaz. Hatalı bir silme birimi veya disk denetleyicisindeki veri kaybı, verileri yeniden oluşturmanızı gerektirir.

Basit rutin geri yüklemelere izin vermenin çok basit ve zarif bir yoludur, ancak gerçek bir yedekleme çözümünün yerini alacak kadar güvenilir değildirler. Çoğu zaman, rutin restorasyonları basit ve ağrısız hale getirirler, ancak mevcut olmadıklarında maruz kalırsınız.

Onlar bir yedek, evet. Onları daha önce günlük artımların yerine kullandım, ama hala teyp için haftalık dolular yaptık.

Netapp olmayan (birimlere erişen sistemler) kullanıcı veya yönetici hatalarından veya sorunlarından oldukça iyi korurlar.

Netapp'ın kendisinin yıkıcı donanım arızalarından korunmazlar. Anladığım kadarıyla, SnapMirror tüm verileri (anlık görüntüde) diğer dosyalayıcıya [1] kopyalar, bu nedenle SnapMirroring'in başka bir dosyalayıcıya tek bir dosyalayıcıdaki felaket başarısızlığından korunması gerekir.

Tek büyük sorun, elbette, netapp'ı yöneten biri hacmi silerse, o zaman tüm anlık görüntüler onunla gider. SnapMirror başka bir dosyalayıcıya karşı yeterince koruma sağlamalıdır.

Tüm NetApp dosyalarınız aynı veri merkezinde bulunuyorsa, büyük bir felaketi kapsayan hiçbir şeyiniz yoktur, bant yedeklerinin site dışına gönderilme şekli size verir.

Anlık görüntü çekilirken verilerin kısa bir süre için sessizleştirilmesini koordine edecek uygun SnapManager aracısını kullanırsanız VM'lerinizin ve veritabanlarınızın (veya veritabanına benzer şeylerin) daha iyi yedeklerini alırsınız. Belirli bir VM ve verileri tamamen tek bir NetApp biriminde bulunuyorsa, söz konusu VM'nin anlık görüntüsü çökmeyle tutarlı olmalıdır. Yani, tıpkı bir sunucudaki fişi çekip sürücüyü görüntülediğiniz gibi iyi olmalıdır, bu da genellikle dosya sistemi kontrolleri ve veritabanı eşdeğerleri anlamına gelir. Bir veritabanının verileri LUN'lar arasında bölünmüşse, verilerin bozulması konusunda önemli bir risk var gibi görünüyor.

Ben olsaydım, tüm veritabanlarını yerel diske düzenli yedeklemeler yapacak ve bu işleri bir ya da iki kopya olacak şekilde ayarlardım. Bu size kurtarılabilirlik konusunda çok daha iyi bir garanti verir.

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

@Basil'in mükemmel cevabını şu anda okumalısınız ama işte iki sentim :

Anlık görüntüler uygulama farkında değil

Temeldeki depolama biriminin anlık görüntüsünü almanız, bu birimdeki verilerin kurtarılabileceği anlamına gelmez. MS SQL bunun harika bir örneğidir - @freiheit tarafından kullanılan depolamayı anlık olarak görüntülemeden önce veritabanınızın işlem tutarlı olduğundan emin olmanız gerekir . DBA'lar, depolama sistemini, hızlı depolamadaki geçici veritabanlarını, yavaş depolamadaki sistem veritabanlarını, toplu depolamadaki salt okunur veya arşivlenmiş verileri ve aradaki bir yerde çalışan verileri daha iyi kullanmak için farklı SQL parçaları için farklı LUN'ları kullanmayı sever. Sadece o bu ciltleri anlık görüntü varsa yüksek ihtimal size veritabanını kurtarmak mümkün olacak.

NetApp, anlık görüntü uygulamasını farkında hale getirmek için bir dizi Snap aracı sağlar. SQL için SnapManager bu farkındalığı sağlar. Microsoft ekosisteminde Exchange ve SharePoint için de SnapManager araçları olduğuna inanıyorum. SnapDrive bu uygulama bilincine sahip değil. Yalnızca konuk içindeki depolamayı yönetmek için uygun bir yöntem sağlar.

Tüm IIS verilerinizi ve yapılandırmanızı LUN'larda saklıyorsanız ve bu LUN'ları doğrudan görüntülüyorsanız, verilerin kurtarılabilir olduğunu garanti edemezsiniz. Bana nasıl bildiğimi sor ...

Birden çok depolama türünün farklı anlık görüntü programları olabilir

Sunucularınıza farklı yollarla depolama alanı sunuyorsanız, bu durum anlık görüntünüzü ve kurtarma resminizi zorlaştırabilir. NetApp'ın ONTAP çok protokollü bir teklifidir ve belirli bir sunucu için birden fazla yöntem veya depolama türü kullanmanız çok olasıdır. Mağazamızda bazı sunucularımız NFS tabanlı bir veri deposu üzerinden C: \ sürücüsünü ve Raw Device Mapled LUN'lar üzerinden "depolama" sürücülerini alır. RDM LUN'larının anlık görüntülerini alıyorduk, ancak NFS tabanlı veri depolarını almıyorduk. Bu, sunucuyu kurtarmayı zorlaştırdı.

Anlık görüntülerin garantili bir saklama politikası yoktur

Yine, @Basil bunu gerçekten iyi bir şekilde kapsıyor ama tekrarlamaya değer. Snap Reserve'nizi, Snpashot Autodelete'in doğal olarak silinmek üzere yaşlanmayan anlık görüntüleri kaldıracağı şekilde doldurmanız mümkündür. Tekrar. Siz veya müşterileriniz üç haftalık anlık görüntülerin kullanılabilir olmasını bekliyorsanız bu gerçekten kötü olabilir.

Anlık görüntüler satıriçi

Entegre depolamanın dezavantajı bu ... iyi ... entegre. Anlık görüntüleriniz yedeklediğiniz platformda bulunur. Üzerinde bulunan birim veya Filer kaybolursa, yedeklemeniz de kaybolur. SnapMirror kopyasının tam bir kopya olmadığını hatalı olarak belirttiğim gibi SnapMirror kullanarak anlık görüntüleri başka bir Filer'e kopyalayarak bunu hafifçe azaltabilirsiniz.

Anlık görüntüler kötü operasyonel uygulamaların devam etmesini sağlar

Fark ettiğim bir şey, anlık görüntülerin yöneticilerin ve müşterilerin korkunç operasyon davranışlarına devam etmesini sağlamasıdır. Ortamımızda çok zayıf dokümantasyon ve konfigürasyon yönetimi uygulamalarımız var. Bu, çoğu sunucunun aynı tabanla (şablon veya görüntü) başladığı, ancak daha sonra farklı kişi grupları tarafından manuel olarak yapılandırıldığı anlamına gelir. Yaşamlarına devam ettikçe, sunucular, yapılandırma yönetimi ile genellikle belgelenmeyen veya uygulanmayan yollarla şablondan daha da uzaklaşırlar.

Ve sonra anlık görüntüler gel! Geri adım atmaya ve temel operasyonel uygulamalarımızdan bazılarına değinmemize gerek yok çünkü tüm sunucularımızı anlık olarak görüntüleyebiliriz! Ve bu anlık görüntüleri site dışına taşımak için SnapMirror'u kullanabiliriz, böylece onları yedek olarak kullanabiliriz!

Bence bu burada öğrenmek için yanlış bir ders. Öğrenilmesi gereken daha iyi bir ders, konfigürasyon yönetimi çerçevesinin, bir değişiklik günlüğü kadar basit olsa bile, çıplak metal geri yükleme amacıyla yedeklenmesi gerektiğidir. Anlık görüntüler harika bir araçtır, ancak önemli temellerin caydırılmasına aşırı derecede bağımlı olma cazibesi olabilir.