Felaket için planlama

Web tasarımı ve geliştirmesi de yapan küçük bir pazarlama şirketi için çalışıyorum. Tüm web tasarım ve geliştirme müşterilerimizi Hostgator'daki özel bir sunucuda ağırlıyoruz. RAID 1 yapılandırılmış sabit disklere sahip özel bir sunucumuz var. Ayrıca cPanel üzerinden otomatikleştirilmiş ve yerel olarak otomatik FTP yazılımı tarafından indirilen haftalık yedeklemeler de yapıyoruz.

Bugün Hostgator'ın bir tür yıkıcı başarısızlığı olsaydı ne yapacağımızı tartışıyorduk. Sunucu patlayabilir, Hostgator ciddi ağ sorunları vardı, FBI ünlü "gördüğümüz her sunucuyu al" baskınları, vb yaptı. Temelde genişletilmiş bir kesinti beklenen herhangi bir senaryo. Daha sonra bir sonraki seviyeye geçtik ve Hostgator'ın genişletilmiş bir kesintisi olsaydı ve yerel yedeklerimize erişemediğimizde ne yapacağımızı merak ettik. Bunun nedeni yangın, sel, vb. Olabilir. Sunucumuzun uzun bir süre kapalı kalması ve yerel dosyalarımıza aynı anda erişilemez olma ihtimalinin uzak olduğunu biliyorum, ancak tüm gereken sadece ikikötü şeyler olacak ve biz de orada duracağız. (Eğer hiç lastik patladıysanız ve yedek lastikinizin düz ya da eksik olduğunu öğrendiyseniz, iki kötü şeyin aynı anda gerçekleşmesinin ne kadar kolay olduğunu bilirsiniz).

Söylemeye gerek yok, "en kötü durum senaryosu" türü etkinliklere hazırlıklı olmak istiyoruz, çünkü bu bizi kesinlikle işten çıkaracaktır. Benim iki sorum:

1. Hostgator tarafından uzatılmış bir kesintiye hazırlanmak için ne yapabiliriz? İdeal bir senaryo, müşterilerimizin web sitelerine sahip olacak ve umarım e-postalar, hızlı bir şekilde tekrar çalışır hale gelir.

2. Sağlam bir yedekleme planı neyi içerir, bu nedenle önemli veriler asla kaybolmaz? İdeal bir çözüm otomatikleştirilecektir.

Maliyetin cevaplarınızda bir sorun olmadığını varsayabilirsiniz, ancak çözümler ne kadar uygunsa o kadar iyidir.

Size şunu öneririm:

1. Ana sunucunuzun tüm içeriğini ve yapılandırmasını, farklı bir veri merkezinde tamamen ayrı bir ağdaki ikincil bir yedekleme sunucusuna otomatik olarak yansıtın. RSync, FXP, cPanel voodoo veya senkronizasyonu otomatikleştirmek istediğiniz herhangi bir yöntemi kullanın.

2. Hostgator sunucusu yanıt vermiyorsa trafiği yedekleme sunucusuna otomatik olarak yönlendirmek için DNS yük devretme anahtarını kullanın .

Bu, manuel müdahale ve etrafta çok fazla karıştırma ve panikleme gerektiren bir 'soğuk' yedek yerine, en kötü durumda gitmeyi bekleyen bir 'sıcak' yedeklemeye sahip olduğunuz anlamına gelir. Ayrıca, müşterilerinizin sitelerinin sizden önce düştüğünü asla bilemeyeceği anlamına gelir, bu da herkes için üzücü olabilir.

Yük Devretme DNS'sini DNS Made Easy gibi bir sağlayıcı kullanarak ayarlayabilirsiniz . Barındırdığınız her etki alanı için, her bir yedekleme sunucunuz için bir tane olmak üzere en fazla beş yedek IP adresi ayarlarsınız. Bir kez bitti ...

1. DNS Made Easy birincil sunucunuzu iki ila dört dakika arasında kontrol eder ve bir yanıt algılamazsa trafiği ikincil IP adresine yönlendirir.

2. DNS Made Easy birincil sunucuyu kontrol etmeye devam eder. Geldiğinde trafiği ilk sunucuya yönlendirir veya neyin yanlış gittiğini teşhis edip birincil sunucuyu düzeltirken yedeklemeyi sürdürür.

Tabii ki, bu çözüm işletme maliyetlerinizi artıracak, bu da bir şekilde müşterilere iletmeniz gerekecek, ancak - kesinti süresinin sizi işten çıkaracağı bir sektördeyseniz - büyük ölçüde gereksiz bir sunucu için ödeme yapmak muhtemelen değerlidir o bir zamanlar şirketi kurtarır.

Onun ötesinde:

Çoğalt, çoğalt, çoğalt

Ne kadar bağımsız yedeklemeniz varsa o kadar iyidir. Uzaktan yedeklemeleri harici bir sabit sürücüye, Dropbox'a, bir git deposuna ve uzak bir FTP hesabına yansıtılmış yerel bir sabit diskte saklıyorum. Hiç şansın yok. Mümkün olduğunca çoğaltın. Manuel bir yedeklemeden geri yüklemeniz gerekiyorsa, beş taneden bir seçeneğe sahip olmak daha iyidir. Paranoya küçümsenir.

Yedekleri manuel olarak geri yükleme alıştırması

Yedeklemelerinizden birinden kurtarmayı hiç denemediyseniz, bunların çalıştığını nasıl anlarsınız? Otomatik prosedürleriniz başarısız olursa ne olacağını görmek için acil durum tatbikatları yapmaya değer.

• Sunucunuz çöktüğünde siteleri yüksek tutmak için güvenlik ve önbellek özellikleri sağlayan Cloudflare . (Sitenizi yansıtır ve doğrudan sunucunuz yerine global olarak dağıtılmış önbelleklerinden sunarlar.)
• Otomatik yedekleme ve web sitesi kodunun geri alınmasını sağlayan Codeguard (yalnızca FTP).
• CPanel yedeklemeleri aracılığıyla otomatik yedeklemeler ve web sitesi kodu, e-posta verileri ve MySQL bilgilerinin geri alınmasını sağlayan Site Otomatik Yedekleme . Bunun Hostgator tarafından çalıştırıldığını unutmayın, bu nedenle sitenizi onlarla birlikte barındırmanız da uygun olmayabilir, ancak başkalarına yardımcı olabilir.

Özellikle bulut parlaması, çalışmama süresinden kaçınmanın ve genellikle site yanıt hızını artırmanın faydalı olacağı anlaşılıyor.

Olağanüstü durum kurtarma, özellikle birden çok sunucu, site ve veritabanıyla uğraşırken büyük bir görev olabilir. Seçtiğiniz çözümle dikkate alınması gereken iki temel öğe, kurtarma zamanı hedefleri (RTO'lar) ve kurtarma noktası hedefleridir (RPO'lar).

RTO aslında siteler yedeklenene kadar ne kadar sürmesi gerektiği beklentisidir. Bir veya iki dakika (veya daha az) RTO'nuz varsa, Nick'in önerdiği gibi, dosyalarınızın ve verilerinizin ikincil bir veri merkezine gerçek zamanlı olarak kopyalanmasını ve DNS'nin otomatik olarak yerine getirilmesini içeren bir çözüm düşünmelisiniz. her iki veri merkezindeki ücretli bir hizmetle veya donanımla ( BIG-IP Global Traffic Manager gibi)F5 Ağlarından. Bu maliyetli olabilir, ancak büyük ölçüde "Duruş süresinin maliyeti nedir?" Sorusunu yanıtlamaya bağlıdır. RTO'nuz birkaç saat hatta birkaç gün ise, sunucuları çevrimiçi duruma getirme, DNS'yi değiştirme vb. Gibi daha manuel katılımı içerebilecek felaket kurtarma prosedürlerini düşünebilirsiniz.

RPO temel olarak yedeklemelerin ne sıklıkta yapıldığı ve bir felaket durumunda ne kadar veri kaybetmek istediğinizdir. İçerik ve / veya verilerdeki değişiklikler sık ​​sık gerçekleşiyorsa, muhtemelen dakikalar veya saatler süren bir RPO'ya sahip olabilirsiniz ve gerçek zamanlı çoğaltma veya yüksek frekanslı yedeklemelerle uğraşıyor olabilirsiniz. İçerik sık sık değişmezse veya birkaç gün boyunca veri kaybetmelerini umursamayan müşterileriniz varsa, yedeklemeleriniz daha az gerçekleşebilir.

Bahsettiğim gibi, Nick'in söylediklerinin çoğuna katılıyorum. Dikkate almak isteyebileceğiniz diğer bir alternatif, Rackspace veya Amazon gibi daha büyük bulut tabanlı sağlayıcılardan birinden bulut tabanlı hizmetleri kullanmaktır. Özellikle bu sağlayıcıların her ikisi de, onlara atılan felaketlerin üstesinden gelebilmek için büyük bir altyapıya sahiptir. Bir bulut sitesi veya bulut sunucusu (Rackspace tarafından kullanılan terimler) gibi bir şeyle, ölçekleme avantajına da sahip olursunuz ve bunun fiziksel donanım yönü hakkında endişelenmenize gerek yoktur.

Rackspace ayrıca, çözümünüzün bir parçası olarak bulut sunucuları, fiziksel sunucular ve bulut dosyalarının bir kombinasyonuna sahip olan altyapınızı karıştırabileceğiniz özel seçeneklere de sahiptir. Hibrit bir yaklaşım, tüm yaklaşımlara uyan tek bir boyut almak istemiyorsanız müşteri ihtiyaçlarınıza bağlı olarak düşünülmesi gereken bir şey olabilir.

Yardımcı olursa, Rackspace sitesinde olağanüstü durum kurtarmaya adanmış bir sayfa var . (Ayrıca kayıt için, Rackspace ile ilişkili değilim, geçmişte hizmetlerini kullandım).

Umarım bu yardımcı olmuştur.

EDIT : Bulut çözümlerini değerlendiriyorsanız bunun yardımcı olabileceğini düşündüm. Altyapı ve Servis ve Web Hosting olarak Gartner Magic Quadrant Raporu size diğer çözüm sağlayıcıları içine bazı bilgiler verebilir.

Sunucunun başka bir hosting şirketinin başka bir tesisinde tam olarak çoğaltılması en bariz çözüm gibi görünüyor.

Dosyalar rsync ve unison gibi araçlarla senkronize tutulabilir. SQL yedeklemeleri de yeniden senkronize edilebilir ve daha sonra komut dosyaları tarafından slave db'ye yüklenebilir.

Tüm kodunuzun sürüm kontrolünü bir kaynak kodu deposuyla (SVN veya GIT) çalıştırdığınızdan emin olun. SVN veya GIT mi kullanıyorsunuz?

Project Locker gibi bir üçüncü taraf veri havuzunda bir hesap (ücretsiz veya ücretli) alabilirsiniz ve çalışırken tüm kodunuzu sürümlendirirseniz, temelde tüm bunları üçüncü bir konumda bulunan veri havuzunuza yedeklediniz . Böylece, tüm işi bir kerede kaybetme şansınızı (neredeyse sıfır olarak) daha da azaltır.

SVN işlemlerinizi / ödünç alma işlemlerinizi komut satırı veya Sürümler (Mac için) veya TortoiseSVN (Windows için) gibi bir istemci aracılığıyla gerçekleştirebilirsiniz.