Yedekleme herkesin bağırıp çağırdığı moda teknolojilerden biri değil. Herhangi bir ciddi şirkette olması gerekir, hepsi bu. Bankamız birkaç bin sunucuyu desteklemektedir; bu karmaşık ve ilginç bir iştir ve yedeklemeyle ilgili tipik yanılgıların yanı sıra bu işin bazı karmaşıklıklarından da bahsetmek istiyorum.
Bu alanda neredeyse 20 yıldır çalışıyorum, son iki yılını Promsvyazbank'ta geçirdim. İlk başladığımda, yedeklemeleri neredeyse tamamen manuel olarak, sadece dosyaları kopyalayan komut dosyaları kullanarak yapıyordum. Sonra, Windows Kullanışlı araçlar ortaya çıktı: Dosya hazırlama için Robocopy yardımcı programı ve kopyalama için NT Backup. Ardından, öncelikle Veritas Backup Exec (şimdi Symantec Backup Exec olarak adlandırılıyor) olmak üzere özel yazılımlar geldi. Dolayısıyla yedeklemelerle uzun zamandır iç içeyim.
Basitçe ifade etmek gerekirse, yedekleme verilerin bir kopyasını kaydetmektir (Sanal makinelerUygulamalar, veritabanları ve dosyalar gibi veriler, olası arızalara karşı düzenli olarak yedeklenir. Herhangi bir arıza genellikle donanım veya mantıksal bir arıza olarak kendini gösterir ve veri kaybına neden olur. Yedekleme sisteminin amacı, veri kaybının neden olduğu hasarı azaltmaktır. Örneğin, donanım arızası, veritabanının depolandığı sunucunun veya depolama biriminin arızalanmasıdır. Mantıksal arıza ise, insan hatası da dahil olmak üzere bazı verilerin kaybolması veya değiştirilmesidir: yanlışlıkla bir tablo veya dosyanın silinmesi veya hatalı bir komut dosyasının çalıştırılması. Ayrıca, belirli bilgi türlerinin uzun bir süre, örneğin birkaç yıla kadar saklanması için yasal gereklilikler de vardır.
Yedeklemelerin en tipik kullanımı, geliştiriciler için çeşitli test sistemlerini ve klonları dağıtmak amacıyla veritabanlarının kaydedilmiş bir kopyasını geri yüklemektir.
Yedeklemeyle ilgili, artık ortadan kaldırılması gecikmiş olan birçok yaygın efsane vardır. İşte bunlardan en ünlüleri.
Efsane 1. Yedekleme, uzun süredir güvenlik veya depolama sistemlerinde yalnızca küçük bir işlev olarak görülüyor
Yedekleme sistemleri hala ayrı bir çözüm sınıfı olmaya devam ediyor ve oldukça bağımsız. Onlara çok önemli bir görev verildi. Esasen, veri güvenliği söz konusu olduğunda son savunma hattıdırlar. Böylece yedekleme kendi hızında, kendi zamanlamasına göre çalışır. Sunucularda günlük bir rapor oluşturulur; izleme sistemi için tetikleyici görevi gören olaylar vardır.
Ayrıca, yedekleme sistemine erişim rol modeli, yedeklemeleri yönetmek için bazı yetkileri hedef sistemlerin yöneticilerine devretmenize olanak tanır.
Efsane 2. RAID olduğunda yedeklemeye artık gerek yoktur
Şüphesiz, RAID dizileri ve veri çoğaltma, bilgi sistemlerini donanım arızalarından korumanın iyi bir yoludur ve yedek bir sunucunuz varsa, ana makinenin arızalanması durumunda ona geçişi hızlı bir şekilde organize edin.
Artıklık ve çoğaltma sizi sistem kullanıcılarının yaptığı mantıksal hatalardan kurtarmaz. İşte gecikmeli kayda sahip bir bekleme sunucusu - evet, senkronize edilmeden önce bir hatanın tespit edilmesi yardımcı olabilir. Peki ya o an kaçırılırsa? Burada yalnızca zamanında bir yedekleme yardımcı olacaktır. Verilerin dün değiştiğini biliyorsanız, sistemi önceki gün itibarıyla geri yükleyebilir ve buradan gerekli verileri çıkarabilirsiniz. Mantıksal hataların en yaygın olduğu göz önüne alındığında, eski güzel yedekleme kanıtlanmış ve gerekli bir araç olmaya devam ediyor.
Efsane 3. Yedekleme ayda bir kez yapılan bir şeydir.
Yedekleme sıklığı, öncelikle yedekleme sisteminin gereksinimlerine bağlı olan, yapılandırılabilir bir parametredir. Neredeyse hiç değişmeyen ve çok da önemli olmayan verileri bulmak oldukça mümkün, bunların kaybı şirket için kritik olmayacak.
Aslında ayda bir veya daha az sıklıkta yedeklenebilirler. Ancak kabul edilebilir veri kaybını ayarlayan RPO (Kurtarma noktası hedefi) göstergesine bağlı olarak daha kritik veriler daha sık kaydedilir. Bu haftada bir, günde bir, hatta saatte birkaç kez olabilir. Bizim için bunlar DBMS'deki işlem günlükleridir.
Sistemleri ticari işletmeye alırken, ana noktaları, güncelleme düzenlemelerini, sistem kurtarma prosedürlerini, yedek depolama prosedürlerini ve benzerlerini yansıtan yedekleme belgelerinin onaylanması gerekir.
Efsane 4. Kopyaların hacmi sürekli artıyor ve tahsis edilen alanı tamamen kaplıyor
Yedeklemelerin raf ömrü sınırlıdır. Örneğin yıl boyunca 365 günlük yedeğin tamamını depolamanın bir anlamı yok. Kural olarak, günlük kopyaların 2 hafta süreyle saklanmasına izin verilir, ardından yenileriyle değiştirilir ve uzun süreli depolama için ayda ilk kez yapılan sürüm kalır. Ayrıca belirli bir süre boyunca saklanır - her kopyanın bir ömrü vardır.
Veri kaybına karşı koruma var. Kural geçerlidir: Bir yedekleme silinmeden önce bir sonrakinin oluşturulması gerekir. Bu nedenle, örneğin sunucunun kullanılamaması nedeniyle yedekleme başarısız olursa veriler silinmeyecektir. Yalnızca zaman sınırlarına uyulmakla kalmaz, aynı zamanda bir setteki kopya sayısı da kontrol edilir. Sistem iki tam yedeğin olmasını gerektiriyorsa, her zaman iki tane olacaktır ve eskisi ancak yeni bir üçüncüsü başarıyla yazıldığında silinecektir. Yani yedekleme arşivinin kapladığı hacimdeki artış yalnızca korunan veri miktarındaki artışla ilişkilidir ve zamana bağlı değildir.
Efsane 5: Yedekleme başladığında her şey donar
Şöyle söylemek daha doğru olur: Her şey donuyorsa, bu yöneticinin yanlış yerde olduğu anlamına gelir. Genel olarak, yedekleme performansı birçok faktöre bağlıdır. Örneğin, yedekleme sisteminin kendi hızına: disk depolama ve teyp kütüphanelerinin hızına. Performansa gelince... sunucular Yedekleme sistemleri: Veri işleme, sıkıştırma ve tekilleştirme işlemlerini gerçekleştirebilme yetenekleri. Ayrıca istemci ve sunucu arasındaki bağlantı hızı da önemlidir.
Yedekleme sisteminin çoklu iş parçacığını destekleyip desteklemediğine bağlı olarak yedekleme bir veya daha fazla iş parçacığına gidebilir. Örneğin, Oracle DBMS, mevcut işlemci sayısına göre, aktarım hızı ağ bant genişliği sınırına ulaşana kadar birkaç iş parçacığı göndermenize olanak tanır.
Çok sayıda iş parçacığını yedeklemeye çalışırsanız, çalışan sistemi aşırı yükleme şansı vardır, gerçekten yavaşlamaya başlayacaktır. Bu nedenle, yeterli performansı sağlamak için en uygun iş parçacığı sayısı seçilir. Performanstaki en ufak bir düşüş bile kritikse, yedeklemenin üretim sunucusundan değil, veritabanı terminolojisinde yedek kopyasından gerçekleştirilmesi durumunda mükemmel bir seçenek vardır. Bu işlem ana çalışma sistemini yüklemez. Sunucu bakım amaçlı kullanılmadığından veriler daha fazla iş parçacığı aracılığıyla alınabilir.
Büyük organizasyonlarda yedeklemenin üretimi etkilememesi için yedekleme sistemi için ayrı bir ağ oluşturulur. Ayrıca trafik ağ üzerinden değil SAN üzerinden iletilebilir.
Ayrıca yükü zamana dağıtmaya çalışıyoruz. Yedeklemeler çoğunlukla mesai saatleri dışında gerçekleştirilir: geceleri, hafta sonları. Ayrıca hepsi aynı anda başlamıyor. Sanal makine yedeklemeleri özel bir durumdur. Sürecin makinenin performansı üzerinde neredeyse hiçbir etkisi yoktur, bu nedenle yedekleme her şeyi geceye ertelemek yerine gün içine yayılabilir. Pek çok incelik var, her şeyi hesaba katarsanız yedekleme sistem performansını etkilemeyecektir.
Efsane 6. Bir yedekleme sistemi başlattık; bu sizin için hata toleransıdır
Yedekleme sisteminin son savunma hattı olduğunu asla unutmayın; bu da kurumun BT altyapısının ve bilgi sistemlerinin sürekliliğini, yüksek kullanılabilirliğini ve felaketlere karşı dayanıklılığını sağlayan beş sistemin daha olması gerektiği anlamına gelir.
Bir yedeklemenin tüm verileri geri yükleyeceğini ve düşen hizmeti hızlı bir şekilde geri yükleyeceğini ummanın bir anlamı yoktur. Yedekleme anından arıza anına kadar veri kaybı garanti edilir ve veriler birkaç saat (veya şansınıza bağlı olarak günler) boyunca yeni bir sunucuya yüklenebilir. Bu nedenle, her şeyi yedeklemeye kaydırmadan tam teşekküllü, hataya dayanıklı sistemler oluşturmak mantıklıdır.
Efsane 7: Bir keresinde bir yedekleme ayarladım ve çalışıp çalışmadığını kontrol ettim. Geriye kalan tek şey günlüklere bakmak
Bu, sahteliğini ancak olay sırasında fark ettiğiniz en zararlı efsanelerden biridir. Başarılı bir yedeklemeyle ilgili günlükler, her şeyin aslında beklendiği gibi gittiğinin garantisi değildir. Dağıtım için kaydedilen kopyanın önceden kontrol edilmesi önemlidir. Yani kurtarma işlemini bir test ortamında çalıştırın ve sonuca bakın.
Ve bir sistem yöneticisinin çalışmaları hakkında biraz
Hiç kimse verileri uzun süre manuel olarak kopyalamaz. Modern SRC'ler hemen hemen her şeyi yedekleyebilir; yalnızca onu doğru şekilde yapılandırmanız yeterlidir. Yeni bir sunucu eklendiyse politikaları ayarlayın: yedeklenecek içeriği seçin, depolama parametrelerini belirtin ve bir zamanlama uygulayın.
Aynı zamanda, veritabanları, posta sistemleri, sanal makine kümeleri ve dosya kaynakları da dahil olmak üzere kapsamlı sunucu filosu nedeniyle hâlâ yapılacak çok iş var. Windows, yakında Linux/Unix. Yedekleme sistemini yöneten personel sürekli meşgul.
Tatilin şerefine, tüm yöneticilere güçlü sinirler, net hareketler ve yedekleri depolamak için sonsuz alan diliyorum!
Kaynak: habr.com
