Bir depolama sunucusunu nasıl yedeklersiniz?

Diğer tüm sunucular (tüm Linux tabanlı) için canlı NAS olarak kullanılacak çok büyük bir depolama sunucusu uygulamaya bakıyorum.

Çok büyük bir ifadeyle, 4 TB ile 20 TB arasında kullanılabilir alan (yani, aslında 20 TB olacak).

Depolama sunucusu veri güvenliği ve performansı için RAID 10 olacaktır, ancak yine de tesis dışı yedekleme de dahil olmak üzere bir yedekleme çözümüne ihtiyacımız olacaktır.

Sorum şu: Bu kadar veriyi nasıl yedekliyorsunuz?

Sadece taşınabilir bir sabit sürücüyü bağlayıp dosyaları aktarabileceğim gibi değil. Şu anda bu kadar depolama alanına sahip başka cihazımız yok.

İkinci bir site dışı depolama sunucusu için bütçe ayırmam gerekiyor mu yoksa daha iyi bir çözüm var mı?

Bu boyuttaki verileri işlemenin birçok yolu vardır. Bunların çoğu çevrenize ve ne kadar para harcamak istediğinize bağlıdır. Genel olarak birkaç 'veriyi sunucudan çıkar' stratejileri vardır:

• Ethernet Üzerinden Kutunun üzerinde dediği gibi, veriler işlemek için Bazı Diğerleri'ne aktarılır. 20 TB'ın 1 GbE'nin üzerine kopyalanması uzun zaman alacaktır, ancak yapılabilir. Donanım yardımcı olabilir (10GbE bağlantıları veya bazı durumlarda NIC bağları gibi).
• Depolama altsistemi üzerinden Fiber Kanal'daysanız, FC ağındaki başka bir aygıta gönderin. SAS'ınız varsa, SAS'a bağlı bir cihaza gönderin. Genellikle Ethernet'ten daha hızlıdır.
• Başka bir disk dizisine gönderme Aynı sunucuya bağlı başka bir depolama yığınına gönderin.

Bu 100 km'lik bir görüş. Bir şeyleri yakınlaştırmaya başladığınızda çok daha parçalı hale gelir. Daha önce de belirtildiği gibi, LTO5 bu tür yüksek yoğunluklu yükler için tasarlanmış özel bir bant teknolojisidir. Başka bir özdeş depolama dizisi iyi bir hedeftir, özellikle de verileri oraya almak için GlusterFS veya DRBD gibi bir şey kullanabiliyorsanız. Ayrıca, bir yedek döndürmeye veya dizinin başarısız olması durumunda çalışmaya devam etme yeteneğine ihtiyacınız varsa , yerine koyduğunuz şeyi etkiler.

100 km'lik bir görüntüleme yöntemine karar verdikten sonra, yazılıma geçmek bir sonraki büyük görev olacaktır. Bunu etkileyen faktörler öncelikle depolama sunucunuza yükleyebileceğiniz şeydir (eğer bir NetApp ise, bu bir şeydir, bir sürü depolama alanına sahip bir Linux sunucusu, bir sürü depolama alanına sahip bir Windows sunucusu gibi) , hangi donanımı seçtiğinizi (örneğin, tüm FOSS yedekleme paketleri teyp kitaplıklarını iyi işlemez) ve ne tür bir yedek tutma gereksiniminiz vardır.

Gerçekten ne tür bir Olağanüstü Durum Kurtarma istediğinizi bulmanız gerekir. Basit canlı çoğaltma daha kolaydır, ancak geçen haftadan sadece şimdi geri yüklemenize izin vermez. Geçen haftadan geri yükleme yeteneği sizin için önemliyse, bu tür şeyler için tasarlamanız gerekir. Yasalara göre (ABD'de ve başka yerlerde) bazı verilerin 7+ yıl boyunca saklanması gerekir.

Basit çoğaltma yapmak en kolayıdır. DRBD bunu yapmak için tasarlanmıştır. İlk kopya yapıldıktan sonra, sadece değişiklikler gönderir. 2. diziniz birincil DRBD'ye yakın değilse, buradaki karmaşık faktörler ağ konumudur. En az birincisi kadar depolama alanına sahip bir 2. depolama sunucusuna ihtiyacınız olacaktır.

Teyp yedekleme hakkında ...

LTO5, sıkıştırma olmadan 1,5 TB veri tutabilir. Bu canavarları beslemek için Fiber Kanal veya 6Gb SAS olan çok hızlı bir ağ gerekir. Bir yükte 1,5 TB'tan fazla yedeklemeniz gerektiğinden, otomatik yükleyicilere bakmanız gerekir (burada bir örnek: bağlantı , HP'den 24 yuvalı 1 sürücülü otomatik yükleyici). Bunları destekleyen yazılımlarla, değişen bantları sizin için yedeklemenin ortasında tutacaklar. Onlar harika. Site dışına göndermek için yine de bantları çekmeniz gerekecek, ancak bu, yedekleme onları çağırdığında bantları kendiniz yüklemek için bütün gece asılı kalmaktan daha iyi bir manzara.

Bant size verirse ' miras, ew ' heebiegeebies, Sanal Teyp Kütüphanesi daha fazla hız (: Quantum bu biri olarak olabilir bağlantı ). Bunlar, aslında (umarım) tekilleştirme teknikleri ile şeyleri diske depolarken yedekleme yazılımı için teyp kütüphaneleri gibi davranıyor. Daha meraklı olanlar, sanal bantları sizin için gerçek bantlara bile kopyalar, eğer bu tür şeyleri seviyorsanız, site dışı rotasyonlar için çok kullanışlı olabilir.

Sanal bantlarla bile uğraşmak istemiyorsanız, ancak yine de doğrudan diske yedekleme yapmak istiyorsanız, bu 20 TB'ı işleyecek kadar büyük boyutta bir depolama dizisine ve ayrıca istediğiniz kadar net değişiklik verisine ihtiyacınız olacaktır. tutmak için. Farklı yedekleme paketleri bunu farklı şekilde ele alır. Bazı tekilleştirme teknolojileri gerçekten güzel, diğerleri hacky kludges. Şahsen bu alanda FOSS yedekleme yazılım paketlerinin durumunu bilmiyorum (Bacula'yı duydum), ancak yeterli olabilirler. Birçok ticari yedekleme paketi, verimi artırmak için yedeklenecek sunuculara yüklediğiniz yerel ajanlara sahiptir, bu da çok fazla değere sahiptir.

LTO-5 müzik kutusu? bu diziyi yedeklemek için üç ila 15 bant arasında bir yere ihtiyacınız olacak, bu da çok büyük bir sayı değil. Müzik kutusu sizin için bantları değiştirmeye özen gösterir ve iyi yedekleme yazılımı (örn. Bacula) hangi dosyaların hangi bantta olduğunu izler.

Ayrıca, FS'nin bu dönemde değişmesi muhtemel olduğu kadar büyük bir dosya sistemini yedeklemek için gereken süreyi de değerlendirmek isteyeceksiniz. En iyi sonuçlar için, anlık görüntüleri destekleyen bir dosya sistemi çok yardımcı olacaktır, böylece anlık bir anlık görüntü alabilir ve canlı dosya sistemine karşı buna karşı tam veya artımlı yedeklemeler yapabilirsiniz.

Muhtemelen diske yedekleme yapmalısınız , çünkü bant uzun zaman alacak ve sıralı erişim olduğundan, geri yüklemeler sonsuza kadar sürecektir.

Kesinlikle diferansiyel veya artımlı yedeklemelerden yararlanın - yalnızca değişiklikleri, sizin için anlamlı olan her ne olursa olsun yedekleyin.

Muhtemelen ideal çözüm , artımlı yedeklemelerin düzenli olarak gönderildiği başka bir yerde benzer boyutta 2. bir sunucuya sahip olacaktır ve ana sunucu ölürse bu hızlı bir şekilde değiştirilebilir. Bununla birlikte başka bir seçenek , daha sonra depolama için saha dışına çıkarılan yerinde çıkarılabilir sürücüler kullanmak olacaktır .

Bu kadar veriyle uğraşırken , yedeklemelerinizi daha küçük yedekleme işlerine ayırmak da mantıklıdır ve her gün yedeklenemezlerse, yedeklemelerinizi kademelendirin, böylece A kümesi bir gün yedeklenir ve B'yi bir sonraki olarak ayarlayın.

Her zaman geri yükleme prosedürünü düşünün . Yedekleme dizinini yeniden oluşturmak ve geri yüklemek için çok fazla bellek ve çok zaman alan birkaç yüz gig yedekleme işinden bir dosyayı geri yüklemek zorunda kaldığımızda bir kez sokulduk. Sonunda bir gün içinde tamamlayamadık ve ana yedekleme sunucumuzun gece işlerine devam etmesine izin vermek için özel bir geri yükleme sunucusu oluşturmak zorunda kaldık!

--katma--

Ayrıca , aynı bilgileri birden çok kullanıcı için birden çok kez yedeklemeyerek büyük miktarda alan tasarrufu sağlayabilecek veri tekilleştirme teknolojilerini de düşünmek istersiniz . Birçok yedekleme çözümü veya dosya sistemi, işlevlerinin bir parçası olarak veri tekilleştirme sunar.

İlk olarak, koruduğunuz riskleri sıralayın. Bazı yaygın riskler:

• Felaket: Sitenizin tamamında çok talihsiz bir şey olur.
• İnsan hataları (bu _all_the_time_ olan):
  • Birisi, depolama sunucunuzun "çalışırken değiştirilebilir" özelliğini, üretici tarafından amaçlanmayan bir şekilde kullanmaya karar verir.
  • Birisi, sorunu fark etmeden önce birkaç ay boyunca güvenilir bir şekilde yedeklenen verileri sessizce bozan bir süreç yürütür.
  • Birisi bir saat içinde olan ve binlerce dolar değerinde olan önemli raporu siler.

Ardından, çeşitli risk önleme çözümlerinin maliyetini değerlendirin, örneğin:

• Site dışı, çevrimiçi yedekleme (uzak ayna): Felaketten korunur, bazı (ancak hepsi değil) insan hatası (hala çevrimiçi).
• Site dışı çevrimdışı depolama (bantlar): Felaketten korunur, verileri hızlı bir şekilde kurtarmak zordur.
• Yerinde çevrimiçi yedekleme (ayna): Bazı insan hatalarından, bazı donanım arızalarından, felakete karşı korunmasız.
• Yerinde çevrimdışı yedekleme (teyp değiştiricideki bantlar): Çoğu insan hatasından korunur, çoğu donanım hatası.

Ardından rotasyon stratejilerini değerlendirin (ne kadar geri kurtarmak istersiniz, ne kadar veri kaybetmeyi göze alabilirsiniz).

Ardından verilerinizin değerini belirleyin.

İki farklı binada 1 GB'a bağlı iki benzer 12 TB sistemine sahip bir müşterim var. Birincisi üretim sistemidir; büyük rdiff yedekleme yardımcı programı ile diğerlerine (günlük anlık görüntülerle) kademeli olarak yedeklenir . rdiff-backup standart dağıtım havuzunuzda bulunmalıdır.

Site dışı, çevrimiçi yedekleme (uzak ayna)

ss olsa da rsync kullanın (yalnızca değişiklikler) - ilk yedekleme yerel olarak yapılmalıdır, ancak bundan sonra değişikliklere bağlı olarak bir esinti olacaktır

sürümleri değişikliklerle tutmanız gerekiyorsa - rdiff-backup

http://www.nongnu.org/rdiff-backup/

Linux'ta btrfs dosya sistemi umut verici geliyor, ancak yine de ağır geliştirme aşamasında

Gerçek "içeriğinize" ve stratejinizi planlamadan önce ne sıklıkta değiştiğine bakın. Çoğu zaman insanlar sadece aynı verileri, iyi bir sebep olmadan haftalık olarak tekrar tekrar bantlamak için çalkalar.

Bazı satıcıların veri tekilleştirme teknolojileri, anlık görüntülemenin sizi tek tek dosya geri yüklemelerinden kurtarmasına izin verebilir, ancak koruma için her zaman tesis dışında olmanız gerekir.