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.
Son 20 yılı Promsvyazbank'ta olmak üzere neredeyse 2 yıldır bu konu üzerinde çalışıyorum. Uygulamamın en başında, dosyaları kopyalayan komut dosyalarını kullanarak neredeyse manuel olarak yedeklemeler yapıyordum. Daha sonra Windows'ta kullanışlı araçlar ortaya çıktı: Dosyaları hazırlamak için Robocopy yardımcı programı ve kopyalama için NT Yedekleme. Ve ancak o zaman özel yazılımların zamanı geldi, özellikle de şimdi Symantec Backup Exec olarak adlandırılan Veritas Backup Exec. Bu yüzden uzun zamandır yedeklemelere aşinayım.
Basitçe söylemek gerekirse, yedekleme, verilerin (sanal makineler, uygulamalar, veritabanları ve dosyalar) bir kopyasının her ihtimale karşı belirli bir düzenlilikle kaydedilmesidir. Her durum genellikle donanımsal veya mantıksal bir arıza şeklinde kendini gösterir ve veri kaybına yol açar. Yedekleme sisteminin amacı bilgi kaybından kaynaklanan kayıpları azaltmaktır. Donanım hatası, örneğin veritabanının bulunduğu sunucu veya depolama birimindeki bir arızadır. Mantıksal, insan faktörü nedeniyle verinin bir kısmının kaybı veya değişmesidir: bir tablo veya dosyanın yanlışlıkla silinmesi veya bir eğri topu yürütmek için bir komut dosyasının başlatılması. Belirli türdeki bilgilerin uzun bir süre, örneğin birkaç yıla kadar saklanmasına ilişkin düzenleyici gereksinimler 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
Şunu söylemek daha doğru: Her şey kilitlenirse, yöneticinin elleri oradan büyümüyor demektir. Genel olarak yedekleme performansı birçok faktöre bağlıdır. Örneğin, yedekleme sisteminin performansı: disk depolama ve teyp kitaplıklarının ne kadar hızlı olduğu. Yedekleme sistemi sunucularının performansından: verileri işlemek, sıkıştırma ve veri tekilleştirme işlemlerini gerçekleştirmek için zamanlarının olup olmadığı. Ve ayrıca istemci ile sunucu arasındaki iletişim hatlarının hızıyla ilgili.
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 hem Windows hem de Linux/Unix'teki veritabanları, posta sistemleri, sanal makine kümeleri ve dosya kaynakları da dahil olmak üzere geniş sunucu filosu nedeniyle hâlâ yapılması gereken çok iş var. Yedekleme sisteminin bakımını yapan çalışanlar boş durmuyor.
Tatilin şerefine, tüm yöneticilere güçlü sinirler, net hareketler ve yedekleri depolamak için sonsuz alan diliyorum!
Kaynak: habr.com