Yedəkləmə hər ütüdən qışqıran moda texnologiyalarından biri deyil. Sadəcə hər hansı ciddi şirkətdə olmalıdır, o qədər. Biz bankımızda bir neçə min serverin ehtiyat nüsxəsini çıxarırıq - bu, mürəkkəb, maraqlı işdir, onun bəzi incəlikləri, eləcə də ehtiyat nüsxələri haqqında tipik yanlış təsəvvürlər, sadəcə izah etmək istəyirik.
Mən 20 ilə yaxındır ki, bu mövzu üzərində işləyirəm, onun son 2 ili Promsvyazbank-dadır. Təcrübənin ən əvvəlində mən ehtiyat nüsxələrini demək olar ki, əl ilə, sadəcə olaraq faylları kopyalayan skriptlərlə etdim. Sonra Windows-da rahat alətlər peyda oldu: faylları hazırlamaq üçün Robocopy yardım proqramı və kopyalamaq üçün NT Backup. Və yalnız bundan sonra xüsusi proqram təminatının, ilk növbədə, indi Symantec Backup Exec adlanan Veritas Backup Exec üçün vaxt gəldi. Beləliklə, mən uzun müddətdir ki, ehtiyat nüsxələri ilə tanışam.
Sadə dillə desək, ehtiyat nüsxə məlumatların (virtual maşınlar, proqramlar, verilənlər bazası və fayllar) bir nüsxəsini yalnız müəyyən qanunauyğunluq şəraitində saxlamaqdır. Hər bir hal adətən özünü hardware və ya məntiqi nasazlıq kimi göstərir və məlumat itkisi ilə nəticələnir. Ehtiyat sisteminin məqsədi məlumat itkisini azaltmaqdır. Aparat çatışmazlığı, məsələn, verilənlər bazasının yerləşdiyi server və ya yaddaşın nasazlığıdır. Məntiqi - bu, insan faktoru da daxil olmaqla, məlumatların bir hissəsinin itirilməsi və ya dəyişdirilməsidir: təsadüfən bir cədvəli, faylı sildilər, icra üçün əyri skripti işə saldılar. Müəyyən bir məlumat növünün uzun müddət, məsələn, bir neçə ilə qədər saxlanması üçün tənzimləyici tələblər də var.
Ehtiyat nüsxələrin ən tipik istifadəsi müxtəlif test sistemlərinin, tərtibatçılar üçün klonların yerləşdirilməsi üçün verilənlər bazalarının saxlanmış nüsxəsinin bərpasıdır.
Ehtiyatla bağlı bir neçə tipik mif var ki, onları çoxdan aradan qaldırmaq lazımdır. Budur onlardan ən məşhurları.
Mif 1. Ehtiyat nüsxə uzun müddət təhlükəsizlik və ya saxlama sistemlərində kiçik bir funksiya olmuşdur
Yedək sistemləri hələ də ayrı bir həll sinfi olaraq qalır və çox müstəqildir. Onların görəcəkləri çox iş var. Əslində, məlumatların bütövlüyünə gəldikdə, onlar son müdafiə xəttidir. Beləliklə, ehtiyat nüsxə öz sürəti ilə, öz cədvəli üzrə işləyir. Serverlər üçün gündəlik hesabat yaradılır, monitorinq sistemi üçün tetikleyici rolunu oynayan hadisələr var.
Üstəlik, ehtiyat nüsxə sisteminə çıxışın rol modeli, ehtiyat nüsxələrini idarə etmək üçün səlahiyyətin bir hissəsini hədəf sistemlərin administratorlarına həvalə etməyə imkan verir.
Mif 2. RAID olduqda, artıq ehtiyat nüsxəyə ehtiyac qalmır.
Şübhəsiz ki, RAID massivləri və məlumatların təkrarlanması informasiya sistemlərini aparat xətalarından qorumaq üçün yaxşı bir yoldur və gözləmə serveriniz varsa, əsas maşın uğursuz olarsa, ona keçidi tez təşkil edə bilərsiniz.
Sistemin istifadəçiləri tərəfindən edilən məntiqi səhvlərdən artıqlıq və təkrarlama qənaət etmir. Budur, geri yazan gözləmə serveri - bəli, o, sinxronizasiya edilməmişdən əvvəl xətanın aşkar edildiyi halda kömək edə bilər. Və an buraxılıbsa? Burada yalnız vaxtında ehtiyat nüsxə kömək edəcək. Məlumatların dünən dəyişdiyini bilirsinizsə, sistemi dünənki günə bərpa edə və ondan lazımi məlumatları çıxara bilərsiniz. Məntiqi səhvlərin ən çox yayıldığını nəzərə alsaq, köhnə yaxşı ehtiyat nüsxəsi sübut edilmiş və zəruri bir vasitə olaraq qalır.
Mif 3. Ehtiyat nüsxə ayda bir dəfə edilən bir şeydir.
Yedəkləmə tezliyi konfiqurasiya edilə bilən parametrdir və ilk növbədə ehtiyat sistem tələblərinizdən asılıdır. Demək olar ki, heç vaxt dəyişməyən və xüsusilə vacib olmayan məlumatları tapmaq olduqca mümkündür, onların itkisi şirkət üçün kritik olmayacaqdır.
Onlar, həqiqətən, ayda bir dəfə və hətta daha az ehtiyat nüsxəsini çıxara bilər. Lakin icazə verilən məlumat itkisini təyin edən RPO (Recovery point objrective) göstəricisindən asılı olaraq daha kritik məlumatlar daha tez-tez saxlanılır. Bu həftədə bir dəfə, gündə bir dəfə və ya hətta saatda bir neçə dəfə ola bilər. Bizdə DBMS-dən bu əməliyyat qeydləri var.
Sistemlər kommersiya istismarına verildikdə, əsas məqamları, yeniləmə prosedurunu, sistemin bərpası prosedurunu, ehtiyat nüsxələrin saxlanması prosedurunu və s. əks etdirən ehtiyat sənədləri təsdiq edilməlidir.
Mif 4. Nüsxələrin həcmi durmadan artır və hər hansı ayrılmış yeri tamamilə tutur.
Yedəkləmələrin məhdud saxlama müddəti var. Məsələn, il ərzində bütün 365 gündəlik ehtiyat nüsxəsini saxlamağın mənası yoxdur. Bir qayda olaraq, gündəlik nüsxələri 2 həftə saxlamaq məqbuldur, bundan sonra onlar təzələri ilə əvəz olunur və ayda ilk dəfə hazırlanmış versiya uzunmüddətli saxlamada qalır. O da öz növbəsində müəyyən müddətə saxlanılır - hər bir nüsxənin ömrü var.
Məlumat itkisindən qorunma var. Qayda tətbiq olunur: ehtiyat nüsxəsi silinməzdən əvvəl növbətisi yaradılmalıdır. Buna görə də, ehtiyat nüsxəsi tamamlanmadıqda, məsələn, serverin olmaması səbəbindən məlumatlar silinməyəcək. Yalnız vaxt çərçivələrinə riayət olunmur, həm də dəstdəki nüsxələrin sayına da nəzarət edilir. Sistem iki tam ehtiyat nüsxəsinə malik olmaq üçün nəzərdə tutulubsa, həmişə onlardan ikisi olacaq və köhnəsi yalnız yeni üçüncüsü uğurla yazıldıqda silinəcək. Beləliklə, ehtiyat arxivin tutduğu həcmin artması yalnız qorunan məlumatların miqdarının artması ilə əlaqələndirilir və zamandan asılı deyil.
Mif 5. Yedəkləmə başladı - hər şey asıldı
Bunu demək daha yaxşıdır: əgər hər şey asılıbsa, idarəçinin əlləri oradan böyüməz. Ümumiyyətlə, ehtiyat nüsxənin fəaliyyəti bir çox amillərdən asılıdır. Məsələn, ehtiyat nüsxə sisteminin sürəti haqqında: disk anbarları, lent kitabxanaları nə qədər sürətlidir. Ehtiyat sisteminin serverlərinin sürətindən: onların məlumatları emal etməyə, sıxılma və təkmilləşdirməyə vaxtları olub-olmaması. Həm də müştəri ilə server arasındakı əlaqə xətlərinin sürəti.
Yedəklənən sistemin çox iş parçacığını dəstəkləyib-dəstəkləməməsindən asılı olaraq ehtiyat nüsxə bir və ya bir neçə axına gedə bilər. Məsələn, Oracle DBMS, ötürülmə sürəti şəbəkənin bant genişliyi həddinə çatana qədər mövcud prosessorların sayına uyğun olaraq çoxlu mövzular verməyə imkan verir.
Çox sayda mövzunun ehtiyat nüsxəsini çıxarmağa cəhd etsəniz, işləyən bir sistemi həddindən artıq yükləmək şansı var, həqiqətən yavaşlamağa başlayacaq. Buna görə, kifayət qədər performans təmin etmək üçün optimal sayda iplər seçilir. Performansda ən kiçik bir azalma belə kritikdirsə, ehtiyat nüsxə döyüş serverindən deyil, onun klonundan həyata keçirildikdə əla seçim var - verilənlər bazası terminologiyasında gözləmə. Bu proses əsas iş sistemini işə salmır. Server texniki xidmət üçün istifadə edilmədiyi üçün verilənlər daha çox axın vasitəsilə əldə edilə bilər.
Böyük təşkilatlarda ehtiyat sistem üçün ayrıca şəbəkə yaradılır ki, ehtiyat nüsxə istehsala təsir göstərməsin. Bundan əlavə, trafik şəbəkə vasitəsilə deyil, SAN vasitəsilə ötürülə bilər.
Biz də yükü zamanla yaymağa çalışırıq. Yedəkləmələr əsasən qeyri-iş saatlarında aparılır: gecə, həftə sonları. Üstəlik, hamısı eyni vaxtda qaçmır. Virtual maşınların ehtiyat nüsxələri xüsusi bir haldır. Proses maşının özünün işinə praktiki olaraq heç bir təsir göstərmir, buna görə ehtiyat nüsxə gündüzə yayıla bilər və gecə hər şeyi təxirə sala bilməz. Bir çox incəlik var, hər şeyi nəzərə alsanız, ehtiyat nüsxə sistemlərin işinə təsir etməyəcək.
Mif 6. Yedəkləmə sistemini işə saldı - bu, sizin üçün səhvlərə dözümlülükdür
Heç vaxt unutmayın ki, ehtiyat sistem müdafiənin son xəttidir, yəni onun qarşısında İT infrastrukturunun və müəssisə informasiya sistemlərinin davamlılığını, yüksək əlçatanlığını və fəlakətlərə dözümlülüyünü təmin edən daha beş sistem olmalıdır.
Yedəkləmənin bütün məlumatları bərpa edəcəyinə və düşmüş xidməti tez bir zamanda qaldıracağına ümid etmək buna dəyməz. Yedekləmə anından uğursuzluq anına qədər məlumatların itirilməsinə zəmanət verilir və məlumatlar bir neçə saat (və ya şanslı olduğunuz üçün günlər) üçün yeni serverə yüklənə bilər. Buna görə də, hər şeyi ehtiyat nüsxəyə keçirmədən tam hüquqlu nasazlığa dözümlü sistemlər yaratmaq məntiqlidir.
Mif 7. Mən bir dəfə ehtiyat nüsxəsini qurdum, onun işlədiyini yoxladım. Yalnız loglara baxmaq qalır
Bu, ən zərərli miflərdən biridir, saxtalığını yalnız hadisə zamanı dərk edirsiniz. Uğurlu ehtiyat nüsxə qeydləri hər şeyin həqiqətən lazım olduğu kimi getdiyinə zəmanət vermir. Saxlanılan nüsxənin yerləşdirilə biləcəyini əvvəlcədən yoxlamaq vacibdir. Yəni test mühitində bərpa prosesinə başlayın və nəticəyə baxın.
Və sistem administratorunun işi haqqında bir az
Əl rejimində uzun müddətdir heç kim məlumatları kopyalamır. Müasir SRK-lar demək olar ki, hər şeyin ehtiyat nüsxəsini çıxara bilər, sadəcə onu düzgün qurmaq lazımdır. Yeni server əlavə edilibsə, siyasətləri təyin edin: ehtiyat nüsxəsi çıxarılacaq məzmunu seçin, yaddaş seçimlərini göstərin və cədvəli tətbiq edin.
Eyni zamanda, verilənlər bazası, poçt sistemləri, virtual maşın klasterləri və həm Windows, həm də Linux / Unix-də fayl paylaşımları daxil olmaqla, geniş server parkı sayəsində hələ də çox iş var. Ehtiyat sistemini işlək vəziyyətdə saxlayan işçilər boş oturmurlar.
Bayram şərəfinə bütün adminlərə güclü əsəblər, hərəkətlərin aydınlığı və ehtiyat nüsxələri saxlamaq üçün sonsuz yer arzulayıram!
Mənbə: www.habr.com