Yedekleme kontrolü için en iyi yöntemler?

Yönetici otomatik yedekleme için sistem yaptığında ve unuttuğunda sık görülen bir durumdur. Sadece bir sistem yönetici bildirimlerinde başarısız olduktan sonra, yedekleme sisteminin daha önce kırıldığını veya bazı hatalardan dolayı yedeklerin geri alınamadığını ve geri yüklenecek güncel bir yedeğinin bulunmadığını ... Bu durumlardan kaçınmanın en iyi yöntemleri nelerdir?

Yangın tatbikatlarını çalıştırın ... birkaç ayda bir, XYZ sisteminin düştüğünü söylemek iyi bir fikirdir ... sonra aslında onu yeni bir VM vb. hatalar.

soapbox modu: AÇIK

Düzenli olarak test edilmeyen yedeklemelerin değersiz olduğu kadar basit olduğunu söyleyebilirim.

Önceki işimde, her sistemin (üretim, test, geliştirme izleme vb.) Her 6 ayda bir test yapılması gerektiği politikası vardı.

Bu aynı zamanda en genç yöneticinin işi idi, böylece belgeler günceldi. Junior, belirli bir sistemde ne kadar çalışma yaptığıyla tanımlanıyor, bazen (aslında oldukça sık) bunu yapan "grup yöneticisi" oldu.

Geri yüklenen ana bilgisayarda gerçek bir şey çalıştırmamıza gerek kalmamasına rağmen, her şey için düşük özellikli özel bir donanıma (bir Intel ve bir IBM / AIX kutusu) sahip olduk.

Oldukça fazla çalışma, ilk turda ancak yedeklemenin önemli bir parçası olan geri yükleme sürecini düzene sokmamıza neden oldu.

Yöneticinin, yedekleme işinin "kırıldığını" farketmediğini ve çalışan bir yedeklemenin işe yaramadığını çok fazla göremediğiniz anlaşılıyor gibi göründüğü için, yedeklemeler etrafında bir tür izleme komut dosyası oluşturmanızı öneririm.

Evde yetiştirilen bir yedekleme çözümü oluştururken şöyle bir şey yaparım:

• Verilerinizi yedeklemek için bir komut dosyası oluşturun.
• Komut dosyasının doğru çalıştığından emin olmak için test restorasyonu uygulayın.
• Komut dosyasında veya başka bir yolla, yedeklerin durumunu izlemek için bir yol uygulayın (başarı, başarısızlık, çalışmadı, çalışmadı).
• Bu izleme durumunu izlettirin (e-posta, veritabanı, bir şey)

Tüm bunlar bittiğinde, iyi olmalısın. Yapılacak ek bir şey düzenli test geri yükleme yapmak olacaktır. Eğer buna bağışta bulunmak için fazladan donanımınız varsa budur.

Çalıştığım yerde sıcak bir sitemiz var, ayda bir kez rasgele bir sistem veya veritabanı seçip sıcak sitemize gidip verilerimizi kurtarma yeteneğini sağlamak için çıplak metal üzerinde bir test restorasyon egzersizi yapıyoruz.

Dürüst olmak gerekirse, verileriniz sizin için çok önemliyse, yedeklerinizi sizin için yönetmek için bazı yazılımlara yatırım yapmak sizin yararınıza olacaktır. Bunun için ucuz ve basitten işletme sınıfına kadar yüzlerce ürün var.

Şirketlerinizin yedeklemesi için crontab'da çalışan bir dizi el yazısıyla yazılmış komut dosyalarına güveniyorsanız, er ya da geç yanacaksınız.

'Üretim' sistemlerimizin% 60 boyutunda 'Referans' sürümlerine sahibiz, değişikliklerin son testlerinde bunları kullanıyoruz, bu sistemlere 'Üretim' yedeklemelerini geri yüklüyoruz - yedeklemeyi test ediyor artı her iki ortamın da birbirleriyle adım adım olmasını sağlıyor .

Yaklaşımlardan biri, örneğin belirli bir metin dosyasını en yeni yedeklemeden alan ve içeriğini e-postayla gönderen, düzenli olarak çalıştırılacak bir "kurtarma" işi yazmaktır. Mümkünse, bu - en azından bazen - verileri oluşturan veya yedeklenenden farklı bir kutu kullanılarak yapılmalıdır, yalnızca yapmanız gerektiğinde çalışmasını sağlamak için. Bunun avantajı, şifreleme / şifre çözme, sıkıştırma ve depolama mekanizmalarınızın çalıştığından emin olmanızdır.

Bu, e-posta ve veritabanı sunucuları gibi özel yedeklemeler için biraz daha fazla olsa da, küçük bir DB veya tuğla düzeyindeki posta kutusu yedeklemesinden bir miktar küçük çaplı kurtarma işlemi gerçekleştirme ve içeriğin doğrulanmasının kesinlikle mümkün olduğunu doğrulamak, biraz da daha fazla söz konusu.

Bu yaklaşım aynı zamanda acil bir durumda verileri kurtarabilmenizi sağlamak için periyodik olarak yapılan bir tam geri yüklemenin yerini almamalı - günlük yedekleme işinizin bütünlüğü konusunda biraz daha güvende olmanızı sağlar.

Sınama geri yükleme işlemi gerçekleştirirken kendimi rahat hissetmiyorum "bu güzel görünüyor, dosyalar geri yüklendi, hiçbir dosya eksik değil, boyutlar bile uyuyor" veya "bu güzel görünüyor" noktasında uygulamama başladım. .. çökmez, bazı düzgün veriler görüntüler ".

Sunucu / kümeyi sıfırdan geri yüklemek ve ardından gerçekten üretim için kullanmak istiyorum . Bir dakika için değil, bir saat için değil, ama kalıcı olarak . Geri yüklemenizin başarılı olduğunu iddia ediyorsanız, bir üretime başlamamanızın kesin bir nedeni yoktur. Bu, unutulması gereken bazı "kirli" bir sistem değildir. Gerçek bir felaketten sonra karşılaşacağınız sistem budur. Yani, "güzel görünüyor" aşamasını geçerse, onunla yaşa. Gelecek gece yedekleyin. Orijinal olanı unut. Muhtemelen olacak bu yaklaşımı kullanarak bazı aksaklıklar da keşfetmek ve olacak zorla üzere hepsini düzeltmek . Aynı sistemin bir sonraki geri yüklemesinde% 100 başarılı olmak için iyi bir şans var.

Bu, yedekleme yazılımınızı ve sunucunuzu içerir. Evet, bunları da geri yüklemelisiniz.

Geri yükleme için özel donanım satın almak için bütçeniz yok mu?

• Kesinlikle bir bütçeye ihtiyacınız olduğuna dikkat edin. Her seferinde karar vericilere, geçerli bir geri yükleme testi boyunca henüz geçmediğini hatırlatır. (Ve evet, kıçını örtmek için kanıtları topla. Zor dünya.)
• Çoğu kuruluşta, bazen bir sistemi başka bir donanıma geçirmek için bir işletmenin ihtiyacı olabilir, bu yüzden fırsatı kullanın. Her zaman için orijinal donanımı kaybetmiş gibi davranarak, geçiş için her zaman "yedekten geri yükle" yöntemini seçin. Evet, daha fazla aksama süresi demek, bunun için üzgünüm. En azından yedeğinizin faydalı olduğuna güveneceksiniz.
• Göç yok mu? Belki iki hafta boyunca bir miktar donanım ödünç alabilir ve iki geri yükleme testi gerçekleştirebilirsiniz (ödünç alınan donanıma geri yükleme, bir haftadan fazla bekleme, ödünç alma işleminden orijinaline geri yükleme, onunla yaşama). Genellikle, bazı yeni sistemler için satın alınan yeni bir donanım varsa ve işleri doğru şekilde ayarlarsanız, iki hafta boyunca ayrıntılı bir şekilde test etmeyi teklif ederek kolayca ödünç alabilirsiniz. Yeni donanım eskisi ile% 100 aynı değilse, bu testinizi daha iyi hale getirecektir. Gerçek felaket durumunda aynı donanıma sahip olup olmadığını nasıl anlarsınız?
• Şu anda tarafınızdan herhangi bir yeni sistem uygulanıyor mu? Geri yüklemeyi şimdi test edebilir misiniz? Ek donanım kullanmayın, sadece yeni sistemin üzerine yazın. Bu henüz önemli bir veri içermiyorsa çalışır. Yine, yeni kurulan sürümde değil, restore edilmiş sürümde üretime gidin.

1. Yangın tatbikatları.
2. Her 6 ayda bir tüm yedeklemeleri test etme politikası çok iyi bir fikirdir
3. Teste gelince, her bir uygulamaya bakmanız veya yedeklediğiniz sisteme bakmanız gerekir. İdeal olarak, "başarılı" veya "kurtarılabilir" bir yedeği oluşturan şey, yedeklemeniz için Hizmet Tanımı veya SOP’da (operasyonel dokümantasyon) ve saklama süresi, bladibla gibi diğer ayrıntılarda listelenmelidir.

Bazı yedekleme türlerinin komut dosyaları (veritabanları gibi) tarafından kolayca geri test edilebileceğini ve bazılarının el ile giriş yapmasına (Active Directory geri yükleme) ihtiyaç duyduğunu göreceksiniz. Bunu yapabildiğiniz kadar otomatikleştirin, bir tür raporlama olduğundan emin olun ve "birinin" manuel testleri de düzenli aralıklarla gerçekleştirdiğinden emin olun. Yalıtılmış bir ortam (prod'un küçültülmüş kopyası) geri yükleme testi yapılmasını kolaylaştıracaktır.

Yedeklemeleri test etmemize rağmen, BackupRadar.com'u geliştirdiğimiz sistemde merkezi bir yedekleme kontrol ve raporlama bileşenine sahibiz. Bu bileşene yardımcı olup olmadığını görmek için kontrol etmekten çekinmeyin. Yedekleme politikasına başarı / başarısızlık e-postalarının bir kopyasını ekler ve ayrıca yedekleme yazılımınız bunları da gönderebiliyorsa ekran görüntülerini de ekler.

Teşekkürler Patrick

Yedekleme etkinliğinin günlüğe kaydedildiğinden emin olun, ardından başarısızlık arayan günlükleri ayrıştırıp, damıtıp bir günlük e-posta olarak göndermesini sağlayan (elbette perl) bir şey yazın.