თავი 7. მონაცემთა სარეზერვო ასლის შექმნა და აღდგენა Acronis True Image Home-ის გამოყენებით დღეს ბაზარზე ბევრი სხვადასხვა პროდუქტია მონაცემთა სარეზერვო ასლის შესაქმნელად და აღდგენისთვის და ჩვენ უკვე შევხვდით ზოგიერთ მათგანს

მონაცემთა სარეზერვო ასლის შექმნა აუცილებელი ფუნქციაა კომპიუტერის ყველა პასუხისმგებელი მომხმარებლისთვის. არაფერია იმაზე უარესი, ვიდრე კომპიუტერთან ჯდომისას იცოდე, რომ შენი ყოველთვიური მუშაობის შედეგი ან მნიშვნელოვანი ფაილები, რომელთა აღდგენა შეუძლებელია, ახლახან დაიკარგა.

მონაცემებს ძალიან ხშირად აქვთ მაღალი ფასი. და არ აქვს მნიშვნელობა ეს არის პერსონალური ფაილები თუ ინფორმაცია, რომელიც გამოიყენება სამუშაოდ. მოდით გაერკვნენ, რა ფუნქციები აქვთ მონაცემთა სარეზერვო და აღდგენისთვის, Microsoft-ის დეველოპერებმა აღჭურვეს თავიანთი ოპერაციული სისტემის უახლესი ვერსია - Windows 10 და ასევე განიხილონ მონაცემთა აღდგენის სარეზერვო ასლის შესაძლებლობა. მესამე მხარის პროგრამები.

მონაცემთა სარეზერვო ასლი: რა არის ეს?

ფაილის სარეზერვო ასლი

ზოგჯერ გვესმის "კომპიუტერის სარეზერვო ასლის შექმნის" აუცილებლობის შესახებ. მაგრამ ამის თქმა არ არის მთლად სწორი, რადგან მონაცემთა სარეზერვო ასლის ორი გზა არსებობს. პირველი, ფაილების სარეზერვო ასლის შექმნა, რომლითაც შეგიძლიათ შექმნათ კომპიუტერში ან ნებისმიერ სხვა შესანახ საშუალებას შენახული ცალკეული ფაილებისა და საქაღალდეების ასლები. ყველა მომხმარებელმა, რომელსაც აქვს მნიშვნელოვანი მონაცემები კომპიუტერზე, უნდა შექმნას მათი სარეზერვო ასლი გარე მყარ დისკზე, თუ ორიგინალური წყარო დაიკარგება ან წაიშლება.

სისტემის სარეზერვო

თქვენი მონაცემების სარეზერვო ასლის შექმნის კიდევ ერთი გზა ცნობილია, როგორც სისტემის სარეზერვო ან სისტემის სურათი. ეს არის მონაცემთა სარეზერვო ასლის უფრო რთული გზა, რადგან ამ შემთხვევაში ჩვენ ვსაუბრობთ კონკრეტული კომპიუტერის მთელი ოპერაციული სისტემის ასლის შექმნაზე, პროგრამებთან, ფაილებთან და ინსტალაციასთან ერთად. სისტემის სარეზერვო ასლი გამოიყენება მის აღსადგენად, თუ Windows დაიწყებს არასტაბილურად მუშაობას ან საერთოდ შეწყვეტს მუშაობას.

Windows-ის სარეზერვო ასლს შეუძლია დაიკავოს ასობით გიგაბაიტი მეხსიერება. მაგრამ მონაცემთა სარეზერვო ასლისთვის სპეციალური პროგრამული უზრუნველყოფის გამოყენებით, შეგიძლიათ დააკონფიგურიროთ ფუნქცია მხოლოდ იმ ცვლილებების შესანახად, რომლებიც განხორციელდა სისტემის ბოლო სარეზერვო ასლის შემდეგ.

Windows-ის გამოყენებით მონაცემთა სარეზერვო ასლის შექმნა და აღდგენა

Windows 10-ს აქვს ჩაშენებული ხელსაწყოები, რომლებიც შექმნილია ფაილებისა და სისტემის სარეზერვო ასლების შესაქმნელად, ასევე ინფორმაციის აღდგენისთვის მათი დახმარებით. ბევრი მომხმარებელი არ იყენებს მათ, არ იცის მათი არსებობის ან სწორად კონფიგურაციის შესახებ. ისინი უფრო ხშირად იყენებენ მესამე მხარის პროგრამებს, ვიდრე ოპერაციულ სისტემაში ჩაშენებულ ინსტრუმენტებს.

ფაილის ისტორია

Ყველაზე მარტივი გზითფაილების და საქაღალდეების სარეზერვო ასლის შექმნა და მათგან აღდგენა არის ფაილის ისტორია. ამ ფუნქციით თქვენ შეგიძლიათ რეგულარულად დააკოპიროთ მონაცემები მომხმარებლის მიერ დადგენილი გრაფიკის მიხედვით და შეინახოთ ისინი გარე მძიმედისკი ან სხვა გარე შესანახი საშუალება. ფაილების ასლები ასევე შეიძლება შენახული იყოს თქვენი კომპიუტერის მყარ დისკზე (თუმცა ეს ეწინააღმდეგება სარეზერვო ასლის ძირითად წესს).

ფაილის ისტორიის მოსარგებად გადადით Start მენიუში და აირჩიეთ პარამეტრები. პარამეტრების მენიუში, რომელიც იხსნება, შეიყვანეთ განახლება და უსაფრთხოება / სარეზერვო სერვისის მენიუ.

პანელის მარჯვენა მხარეს, ფაილის ისტორიის სარეზერვო განყოფილებაში, დააჭირეთ დისკის დამატებას. თქვენ მოგეთხოვებათ აირჩიოთ თქვენს კომპიუტერთან დაკავშირებული ერთ-ერთი გარე მეხსიერების მედია. აირჩიეთ ის, რომელზეც გსურთ მონაცემთა სარეზერვო ასლის შექმნა და დააყენეთ სარეზერვო პარამეტრები: ფაილების ასლების შენახვის ინტერვალი და მათი შენახვის ხანგრძლივობა, საჭიროების შემთხვევაში, შეგიძლიათ მიუთითოთ კონკრეტული საქაღალდე იმ ფაილების ასლისთვის, საიდანაც გსურთ. არასაჭიროების შექმნა ან ამოღება.

სარეზერვო ასლის შექმნისას, File History ასევე ავტომატურად აკოპირებს მომხმარებლის ანგარიშის ყველა საქაღალდეს: სურათები, დოკუმენტები, ჩამოტვირთვები და ა.შ.

ამ ფუნქციის გამორთვა შესაძლებელია ნებისმიერ დროს, მაგრამ იმისათვის, რომ მომხმარებლის მიერ მითითებული მონაცემების კოპირება მოხდეს განსაზღვრულ დროში, ჩართული უნდა იყოს ფაილის ავტომატური სარეზერვო ასლი.

ნაგულისხმევად, ფაილების სარეზერვო ასლები ყოველ საათში ხდება. მინიმალური დრო, რომლის დაყენებაც შესაძლებელია არის 10 წუთი, მაქსიმალური არის ყოველდღიური. თქვენ ასევე შეგიძლიათ დააყენოთ შენახვის ხანგრძლივობა სარეზერვო ასლისთვის: ერთი თვიდან, სანამ თავისუფალი ადგილი არ დაგჭირდებათ (ამ შემთხვევაში, ძველი სარეზერვო ასლები ავტომატურად წაიშლება, რათა ადგილი გაათავისუფლოს ახალი სარეზერვო ასლისთვის).

ფაილების აღდგენა სარეზერვო ასლიდან

ფაილების დისკიდან მონაცემთა სარეზერვო ასლის აღდგენისთვის გადადით საკონტროლო პანელზე და აირჩიეთ მენიუ ფაილების ისტორია.

ფანჯრის მარცხენა სვეტში, რომელიც იხსნება, აირჩიეთ პერსონალური ფაილების აღდგენა, გადადით საქაღალდეში და იპოვეთ ფაილი, რომლის აღდგენა გსურთ. ფაილის აღსადგენად დააჭირეთ მწვანე ღილაკს ქვემოთ და მიუთითეთ მისი აღდგენის გზა. თქვენ შეგიძლიათ აირჩიოთ ფაილების სარეზერვო ვერსიები თარიღისა და დროის მიხედვით მარცხენა და მარჯვენა ისრის ღილაკების დაჭერით.

OneDrive ღრუბლოვანი სერვისი

მნიშვნელოვანი ფაილების დაკარგვისგან თავის დასაცავად კიდევ ერთი გზაა მათი ღრუბლოვან საცავში გადატანა და თქვენს კომპიუტერთან სინქრონიზაცია. ასეთი საცავი ბევრია: Dropbox, Გუგლ დრაივიდა ა.შ. მაგრამ Windows-ის უახლესი ვერსიების (10, 8, 8.1) მახასიათებელია Microsoft-ის საკუთარი ღრუბლოვანი სერვისის არსებობა, რომელიც ჩაშენებულია ოპერაციულ სისტემაში, რომელსაც ეწოდება OneDrive.

ერთ-ერთი ღრუბლოვანი სერვისის გამოყენებისას, ისინი ჩვეულებრივ ქმნიან საქაღალდეს კომპიუტერის დისკზე საკუთარი სახელით, ფაილებს, საიდანაც სინქრონიზდება. ვ უახლესი ვერსიები Windows საქაღალდე OneDrive ნაგულისხმევად არსებობს, ე.ი. სერვისი ხელმისაწვდომია ყველა მომხმარებლისთვის ოპერაციული სისტემის დაყენებისთანავე.

ნებისმიერი ფაილი. რომელიც შეინახება ამ საქაღალდეში, დაუყოვნებლივ დაკოპირდება ღრუბლოვან საცავში და სინქრონიზდება მასთან. მომხმარებელს ასევე შეუძლია წვდომა ამ საქაღალდეში არსებულ ფაილებზე ნებისმიერი სხვა მოწყობილობიდან, უბრალოდ გადადით მისგან თქვენს OneDrive ანგარიშზე.

აღდგენის წერტილი

სარეზერვო და აღდგენის კიდევ ერთი მხარე Windows მონაცემები 10, არის აღდგენა სისტემის ფაილებიდა ოპერაციული სისტემის ჯანმრთელობა. ოპერაციული სისტემის სარეზერვო ასლის შექმნა და აღდგენა უფრო რთული პროცესია, ვიდრე პირადი ფაილებითა და მომხმარებლის საქაღალდეებით. მაგრამ ამისათვის Windows 10 უზრუნველყოფს სპეციალურ ფუნქციას - სისტემის აღდგენა. მისი დახმარებით მომხმარებელს შეუძლია აღადგინოს ოპერაციული სისტემა მუშაობაში, "დაბრუნდეს" შენახულ ადრეულ მდგომარეობაში - Recovery Point.

სტანდარტულად, ოპერაციულ სისტემაში აღდგენის ფუნქცია არ არის გააქტიურებული. იმისათვის, რომ შეძლოთ მისი გამოყენება, ის უნდა იყოს კონფიგურირებული. სისტემის აღდგენა მუშაობს აღდგენის წერტილების შექმნით, რომელთა დახმარებითაც Windows-ის მდგომარეობა ინახება დროის კონკრეტულ მომენტში. ოპერაციული სისტემის პარამეტრებთან და მდგომარეობასთან ერთად, აღდგენის წერტილი მოიცავს დაინსტალირებული აპლიკაციები(მაგალითად, Microsoft Office) და მოწყობილობის დრაივერები (მაგალითად, ვიდეო ბარათი).

მომხმარებელს შეუძლია შექმნას აღდგენის წერტილი ნებისმიერ მოსახერხებელ მომენტში. ის ასევე ავტომატურად იქმნება, თუ კომპიუტერზე დაინსტალირებულია აპლიკაცია ან ჩამოიტვირთება სისტემის განახლებები და ა.შ. მაგრამ გახსოვდეთ, რომ სისტემის აღდგენა არ აღადგენს მომხმარებლის პირად ფაილებს.

თუ შეამჩნევთ, რომ ოპერაციული სისტემა გაუმართავია ან აქვს გაუმართაობა და შეცდომები, მაშინ შეგიძლიათ გაუშვათ ადრე შენახული აღდგენის ერთ-ერთი წერტილი და Windows დაუბრუნდება მდგომარეობას მისი შექმნის მომენტში.

ამისათვის გადადით Control Panel-ზე და აირჩიეთ Restore / System Restore Settings / Configure მენიუ, რომლითაც შეგიძლიათ გაააქტიუროთ და დააკონფიგურიროთ ფუნქცია.

Windows-ის აღდგენის წერტილიდან აღსადგენად გადადით Control Panel-ზე და აირჩიეთ Restore/Run System Restore მენიუ, აირჩიეთ სასურველი Restore Point და დააჭირეთ Next.

სისტემის სურათი

Windows-ის სარეზერვო ასლის, ალბათ, ყველაზე ძირითადი და რთული ფუნქცია არის ფუნქცია სახელწოდებით System Image.

ამ პარამეტრის გამოყენებით შეგიძლიათ შექმნათ მთელი კომპიუტერის დისკის „დუბლიკატი“, მათ შორის Windows 10, ასევე ყველა პროგრამა და მომხმარებლის პირადი მონაცემები. სისტემის სურათი ინახება გარე მყარ დისკზე, საიდანაც საჭიროების შემთხვევაში ან თუ კომპიუტერი ვერ ხერხდება, ის კვლავ განლაგდება კომპიუტერის მყარ დისკზე. შედეგად, მომხმარებელი იღებს ოპერაციული სისტემის სამუშაო ვერსიას პროგრამებთან და ფაილებთან ერთად.

ეს ძალიან სასარგებლო ფუნქცია, მაგრამ მისი მინუსი არის ის, რომ მომხმარებელს არ აქვს შესაძლებლობა აღადგინოს ცალკეული ფაილები სისტემის სურათიდან, როგორც ფაილის ისტორიიდან. თქვენ შეგიძლიათ მხოლოდ მთლიანად გააფართოვოთ მთელი სურათი. ამიტომ, მომხმარებლები ხშირად იყენებენ ამ ფუნქციებს პარალელურად.

სისტემის სურათის შესაქმნელად გადადით საკონტროლო პანელზე და აირჩიეთ მენიუ ფაილების სარეზერვო და აღდგენა. მარცხენა სვეტში დააწკაპუნეთ სისტემის სურათის შექმნაზე და აირჩიეთ დისკი, რომელშიც გსურთ მისი შენახვა. გთხოვთ გაითვალისწინოთ, რომ სისტემის სურათი ჩვეულებრივ დიდია.

სისტემის გამოსახულების აღსადგენად, გადადით სისტემის პარამეტრებზე / განახლებაზე და უსაფრთხოებაზე / აღდგენაზე და აირჩიეთ პერსონალური ჩატვირთვის პარამეტრები. Windows 10-ის გადატვირთვის შემდეგ აირჩიეთ სისტემის აღდგენა მოცემული მენიუდან.

სხვა სარეზერვო და აღდგენის პროგრამული უზრუნველყოფა Windows ფაილები 10

ალექსეი ბერეჟნოი,Სისტემის ადმინისტრატორი. საქმიანობის ძირითადი მიმართულებები: ვირტუალიზაცია და ჰეტეროგენული ქსელები. სტატიების წერის გარდა კიდევ ერთი ჰობია უფასო პროგრამული უზრუნველყოფის პოპულარიზაცია.

სარეზერვო
თეორია და პრაქტიკა. Შემაჯამებელი

სარეზერვო სისტემის ყველაზე ეფექტურად ორგანიზებისთვის, თქვენ უნდა შექმნათ რეალური სტრატეგია ინფორმაციის შენახვისა და აღდგენისთვის.

სარეზერვო ასლი (ან, როგორც მას ასევე უწოდებენ, სარეზერვო - ინგლისური სიტყვიდან "სარეზერვო") მნიშვნელოვანი პროცესია ნებისმიერი IT სტრუქტურის ცხოვრებაში. ეს არის სამაშველო პარაშუტი გაუთვალისწინებელი კატასტროფის შემთხვევაში. ამავდროულად, სარეზერვო საშუალება გამოიყენება კომპანიის საქმიანობის გარკვეული პერიოდის განმავლობაში ერთგვარი ისტორიული არქივის შესაქმნელად. სარეზერვო ასლის გარეშე მუშაობა ჰგავს ღია ცის ქვეშ ცხოვრებას - ამინდი ნებისმიერ დროს შეიძლება გაუარესდეს და დასამალი არსად არის. მაგრამ როგორ მოვაწყოთ ის სწორად, რომ არ დაკარგოთ მნიშვნელოვანი მონაცემები და არ დახარჯოთ მასზე ფანტასტიკური თანხები?

ჩვეულებრივ, სტატიები სარეზერვო ასლების ორგანიზების თემაზე ძირითადად ეხება ტექნიკური გადაწყვეტილებებიდა მხოლოდ ხანდახან ყურადღება ექცევა მონაცემთა შენახვის ორგანიზების თეორიასა და მეთოდოლოგიას.

ეს სტატია საპირისპიროზე იქნება ფოკუსირებული: ყურადღება გამახვილებულია ზოგად ცნებებზე და ტექნიკურ ინსტრუმენტებს მხოლოდ მაგალითების სახით შევეხებით. ეს მოგვცემს საშუალებას, აბსტრაქტი გავხადოთ ტექნიკისა და პროგრამული უზრუნველყოფისგან და ვუპასუხოთ ორ მთავარ კითხვას: "რატომ ვაკეთებთ ამას?", "შეგვიძლია ამის გაკეთება უფრო სწრაფად, იაფად და უფრო საიმედოდ?"

სარეზერვო მიზნები და ამოცანები

სარეზერვო ასლის ორგანიზების პროცესში დაყენებულია ორი ძირითადი ამოცანა: ინფრასტრუქტურის აღდგენა წარუმატებლობის შემთხვევაში (Disaster Recovery) და მონაცემთა არქივის შენარჩუნება, რათა შემდგომში უზრუნველყოს ინფორმაციაზე წვდომა გასული პერიოდებისთვის.

Disaster Recovery-ის სარეზერვო ასლის კლასიკური მაგალითია სერვერის სისტემის დანაყოფის სურათი, რომელიც შექმნილია Acronis True Image-ის მიერ.

არქივის მაგალითი შეიძლება იყოს მონაცემთა ბაზების ყოველთვიური გადმოტვირთვა 1C-დან, ჩაწერილი კასეტებზე შემდგომი შენახვით სპეციალურად გამოყოფილ ადგილას.

არსებობს რამდენიმე ფაქტორი, რომელიც განასხვავებს სარეზერვო ასლს სწრაფი აღდგენაარქივიდან:

• მონაცემთა შენახვის პერიოდი.საარქივო ასლებისთვის ის საკმაოდ გრძელია. ზოგიერთ შემთხვევაში ის რეგულირდება არა მხოლოდ ბიზნესის მოთხოვნებით, არამედ კანონითაც. კატასტროფის აღდგენის ასლები შედარებით მცირე რაოდენობითაა. ჩვეულებრივ, კატასტროფის აღდგენის ერთი ან ორი (გაზრდილი სანდოობის მოთხოვნებით) სარეზერვო ასლი იქმნება მაქსიმუმ ერთი ან ორი დღის ინტერვალით, რის შემდეგაც ისინი იწერება ახალით. განსაკუთრებით კრიტიკულ შემთხვევებში, ასევე შესაძლებელია კატასტროფის აღდგენის სარეზერვო ასლის უფრო ხშირად განახლება, მაგალითად, რამდენიმე საათში ერთხელ.
• სწრაფი წვდომა მონაცემებზე.გრძელვადიან არქივზე წვდომის სიჩქარე უმეტეს შემთხვევაში არ არის კრიტიკული. ჩვეულებრივ, "პერიოდის მონაცემების მოპოვების" საჭიროება წარმოიქმნება დოკუმენტების შეჯერების დროს, დაბრუნება წინა ვერსიადა ა.შ., ანუ არა საგანგებო რეჟიმში. სხვა საქმეა კატასტროფის აღდგენა, როდესაც საჭირო მონაცემები და სერვისების შესრულება რაც შეიძლება მალე უნდა დაბრუნდეს. ამ შემთხვევაში, სარეზერვო ასლის წვდომის სიჩქარე ძალზე მნიშვნელოვანია.
• კოპირებული ინფორმაციის შემადგენლობა.დაარქივებული ასლი ჩვეულებრივ შეიცავს მხოლოდ მომხმარებლის და ბიზნესის მონაცემებს მითითებული პერიოდისთვის. კატასტროფის აღდგენის ასლი შეიცავს, ამ მონაცემების გარდა, სისტემის სურათებს ან ოპერაციული სისტემის და აპლიკაციის პროგრამული უზრუნველყოფის პარამეტრების ასლებს და აღდგენისთვის საჭირო სხვა ინფორმაციას.

ზოგჯერ შესაძლებელია ამ ამოცანების გაერთიანება. მაგალითად, ფაილების სერვერის ყოველთვიური სრული „სნეპშოტების“ წლიური ნაკრები, პლუს კვირის განმავლობაში განხორციელებული ცვლილებები. True Image შესაფერისია, როგორც ინსტრუმენტი ასეთი სარეზერვო ასლის შესაქმნელად.

ყველაზე მნიშვნელოვანი ის არის, რომ ნათლად გვესმოდეს, თუ რატომ ხდება დაჯავშნა. ნება მომეცით მოგცეთ მაგალითი: კრიტიკული SQL სერვერი გაფუჭდა დისკის მასივის გაუმართაობის გამო. საწყობში არის შესაფერისი აპარატურაასე რომ, პრობლემის ერთადერთი გამოსავალი იყო პროგრამული უზრუნველყოფა და მონაცემთა აღდგენა. კომპანიის მენეჯმენტი სვამს გასაგებ კითხვას: "როდის დაიწყებს მუშაობას?" - და უსიამოვნოდ გაკვირვებულია იმის გაგებით, რომ გამოჯანმრთელებას ოთხი საათი დასჭირდება. ფაქტია, რომ სერვერის მთელი მომსახურების ვადის განმავლობაში, რეგულარულად იქმნებოდა მხოლოდ მონაცემთა ბაზის სარეზერვო ასლები, არ გათვალისწინებულ იქნა თავად სერვერის აღდგენის საჭიროება ყველა პარამეტრით, მათ შორის პროგრამული უზრუნველყოფათავად DBMS. მარტივად რომ ვთქვათ, ჩვენმა გმირებმა შეინახეს მხოლოდ მონაცემთა ბაზები და დაივიწყეს სისტემა.

კიდევ ერთ მაგალითს მოგიყვან. მთელი თავისი კარიერის განმავლობაში, ახალგაზრდა სპეციალისტმა შექმნა ფაილური სერვერის ერთი ასლი, რომელიც მუშაობს Windows Server 2003-ზე, ntbackup პროგრამის გამოყენებით, მათ შორის მონაცემები და სისტემის მდგომარეობა, სხვა კომპიუტერის გაზიარებულ საქაღალდეში. დისკზე სივრცის ნაკლებობის გამო, ეს ასლი მუდმივად იწერებოდა. ცოტა ხნის შემდეგ მას სთხოვეს მრავალგვერდიანი მოხსენების წინა ვერსიის აღდგენა, რომელიც შენახვისას დაზიანდა. ცხადია, რომ არქივის ისტორია გამორთული Shadow Copy-ით, მან ვერ შეასრულა ეს მოთხოვნა.

რა დასკვნა მოჰყვება: თქვენ უნდა გამოიყენოთ ორივე ტიპის სარეზერვო საშუალება: კატასტროფის აღდგენისთვის და არქივის შესანახად. ამ შემთხვევაში აუცილებელია კოპირებული რესურსების ჩამონათვალის, დავალებების შესრულების დროის განსაზღვრა, ასევე სად, როგორ და რამდენ ხანს შეინახება სარეზერვო ასლები.

მცირე რაოდენობით მონაცემებით და არც ისე რთული IT ინფრასტრუქტურით, შეგიძლიათ სცადოთ ორივე ამ ამოცანის გაერთიანება ერთში, მაგალითად, გააკეთოთ დისკის ყველა დანაყოფის და მონაცემთა ბაზის ყოველდღიური სრული ასლი. მაგრამ მაინც ჯობია განასხვავოთ ეს ორი ბოლო და აირჩიოთ სწორი საშუალება თითოეული მათგანისთვის. შესაბამისად, თითოეული ამოცანისთვის გამოიყენება ცალკე ინსტრუმენტი, თუმცა არსებობს უნივერსალური გადაწყვეტილებები, როგორიცაა იგივე Acronis True Image პაკეტი ან ntbackup პროგრამა.

ნათელია, რომ სარეზერვო მიზნებისა და ამოცანების განსაზღვრისას, ასევე განხორციელების გადაწყვეტილებების განსაზღვრისას აუცილებელია ბიზნესის მოთხოვნებიდან გამომდინარე.

არსებობს სხვადასხვა სტრატეგია, რომელიც შეიძლება გამოყენებულ იქნას კატასტროფის აღდგენის ამოცანის განსახორციელებლად.

ზოგიერთ შემთხვევაში, საჭიროა სისტემის პირდაპირი აღდგენა შიშველ ლითონზე. ეს შეიძლება გაკეთდეს, მაგალითად, Acronis True Image-ის გამოყენებით უნივერსალური აღდგენით. ამ შემთხვევაში, სერვერის კონფიგურაცია შეიძლება დაუბრუნდეს სერვისს ძალიან მოკლე დროში. მაგალითად, სავსებით შესაძლებელია 20 გბ ოპერაციული სისტემით დანაყოფის ამოღება სარეზერვო ასლიდან რვა წუთში (იმ პირობით, რომ საარქივო ასლი ხელმისაწვდომია 1 გბ/წმ ქსელში).

სხვა შემთხვევაში, უფრო მიზანშეწონილია პარამეტრების უბრალოდ „დაბრუნება“ ახლად დაინსტალირებულ სისტემაში, მაგალითად, კონფიგურაციის ფაილების კოპირება / etc საქაღალდიდან UNIX-ის მსგავს სისტემებში (Windows-ში ეს დაახლოებით იგივეა, რაც კოპირება და აღდგენა. სისტემის მდგომარეობა). რა თქმა უნდა, ამ მიდგომით სერვერი ამოქმედდება არა უადრეს ოპერაციული სისტემის დაინსტალირებამდე და აღდგება საჭირო პარამეტრები, რაც გაცილებით მეტს მიიღებს. გრძელვადიანი... მაგრამ ნებისმიერ შემთხვევაში, გადაწყვეტილება იმის შესახებ, თუ რა უნდა იყოს კატასტროფის აღდგენა, გამომდინარეობს ბიზნესის საჭიროებიდან და რესურსების შეზღუდვით.

ფუნდამენტური განსხვავება სარეზერვო და ზედმეტ სარეზერვო სისტემებს შორის

ეს არის კიდევ ერთი საინტერესო კითხვა, რომლის დაყენებაც მსურს. ჭარბი აღჭურვილობის ჭარბი სისტემები ნიშნავს გარკვეული სიჭარბის დანერგვას აპარატურაში, რათა დარჩეს ფუნქციონირება ერთ-ერთი კომპონენტის უეცარი გაუმართაობის შემთხვევაში. ამ შემთხვევაში შესანიშნავი მაგალითია RAID (დამოუკიდებელი დისკების ზედმეტი მასივი). ერთი დისკის უკმარისობის შემთხვევაში, ინფორმაციის დაკარგვის თავიდან აცილება და უსაფრთხო ჩანაცვლება შესაძლებელია, მონაცემების შენახვა თავად დისკის მასივის სპეციფიკური ორგანიზაციის გამო (დაწვრილებით RAID-ის შესახებ).

მე გამიგია ფრაზა: "ჩვენ გვაქვს ძალიან საიმედო აღჭურვილობა, ყველგან არის RAID-მასივები, ამიტომ არ გვჭირდება სარეზერვო ასლები." დიახ, რა თქმა უნდა, იგივე RAID მასივი დაზოგავს მონაცემებს განადგურებისგან, თუ ერთი მყარი დისკი მარცხდება. მაგრამ აქ არის მონაცემების კორუფცია კომპიუტერული ვირუსიან ის არ გიხსნით მომხმარებლის არასწორი ქმედებებისგან. ის არ დაზოგავს RAID-ს, მაშინაც კი, თუ ფაილური სისტემა ავარიულია არაავტორიზებული გადატვირთვის შედეგად.

ერთ მაგალითს მოგიყვან. არის შემთხვევები, როდესაც მოვლენები ვითარდება შემდეგი სცენარის მიხედვით: დისკის ჩავარდნისას მონაცემები აღდგება ჭარბი მექანიზმის გამო, კერძოდ, შენახულის დახმარებით. გამშვები ჯამები... ამავდროულად, შეინიშნება შესრულების მნიშვნელოვანი შემცირება, სერვერი იყინება, კონტროლი პრაქტიკულად იკარგება. Სისტემის ადმინისტრატორისხვა გამოსავალს ვერ ხედავს, ის გადატვირთავს სერვერს ცივი გადატვირთვით (სხვა სიტყვებით რომ ვთქვათ, ის დააჭერს "RESET"-ს). ამ ცოცხალი გადატვირთვის შედეგად ხდება ფაილური სისტემის შეცდომები. საუკეთესო რამ, რასაც ამ შემთხვევაში უნდა ველოდოთ, არის დისკის შემოწმების ხანგრძლივი მოქმედება ფაილური სისტემის მთლიანობის აღსადგენად. უარეს შემთხვევაში მოგიწევთ დამშვიდობება ფაილების სისტემადა გაგიკვირდებათ კითხვა, სად, როგორ და რა ვადაშია შესაძლებელი მონაცემთა და სერვერის მუშაობის აღდგენა.

თქვენ არ შეგიძლიათ თავიდან აიცილოთ სარეზერვო ასლები მაშინაც კი, თუ თქვენ გაქვთ კლასტერული არქიტექტურა. Failover კლასტერი, ფაქტობრივად, ინარჩუნებს მასზე მინდობილი სერვისების ფუნქციონირებას ერთ-ერთი სერვერის გაუმართაობის შემთხვევაში. ზემოაღნიშნული პრობლემების შემთხვევაში, როგორიცაა: ვირუსის შეტევაან მონაცემების კორუფცია ყბადაღებული „ადამიანური ფაქტორის“ გამო, არცერთი კლასტერი არ დაზოგავს.

ერთადერთი, რაც შეიძლება იმოქმედოს, როგორც კატასტროფის აღდგენის არასრულფასოვანი სარეზერვო ჩანაცვლება, არის სარკისებული სარეზერვო სერვერი, მონაცემთა უწყვეტი რეპლიკაციით მთავარი სერვერიდან სარეზერვო ასლამდე (პირველადი  ლოდინის პრინციპის მიხედვით). ამ შემთხვევაში, თუ მთავარი სერვერი ვერ ხერხდება, მის დავალებებს სარეზერვო აიღოს და თქვენ არც კი გჭირდებათ მონაცემების გადაცემა. მაგრამ ასეთი სისტემის ორგანიზება საკმაოდ ძვირი და შრომატევადია. არ დაივიწყოთ მუდმივი გამეორების აუცილებლობა.

ცხადი ხდება, რომ ასეთი გამოსავალი ეფექტურია მხოლოდ კრიტიკული სერვისების შემთხვევაში, ხარვეზების ტოლერანტობისა და მინიმალური აღდგენის დროის მაღალი მოთხოვნებით. როგორც წესი, ასეთი სქემები გამოიყენება ძალიან დიდ ორგანიზაციებში მაღალი სასაქონლო და ფულის ბრუნვით. და ეს სქემა არის სარეზერვო კოპირების არასრულფასოვანი შემცვლელი, რადგან არ აქვს მნიშვნელობა მონაცემები დაზიანებულია კომპიუტერული ვირუსით, მომხმარებლის არასწორი ქმედებებით ან არასწორი სამუშაოაპლიკაციები, მონაცემები და პროგრამული უზრუნველყოფა ორივე სერვერზე შეიძლება დაზარალდეს.

და, რა თქმა უნდა, არც ერთი ზედმეტი სარეზერვო სისტემა არ გადაჭრის პრობლემას მონაცემთა არქივის გარკვეული პერიოდის განმავლობაში.

სარეზერვო ფანჯარა

სარეზერვო ასლის შესრულება დიდ დატვირთვას აყენებს ზედმეტ სერვერს. ეს განსაკუთრებით ეხება დისკის ქვესისტემას და ქსელურ კავშირებს. ზოგიერთ შემთხვევაში, როდესაც კოპირების პროცესი საკმარისია მაღალი პრიორიტეტი, ამან შეიძლება გამოიწვიოს გარკვეული სერვისების მიუწვდომლობა. გარდა ამისა, ცვლილებების განხორციელების დროს მონაცემების კოპირება მნიშვნელოვან სირთულეებთან არის დაკავშირებული. რა თქმა უნდა, არსებობს ტექნიკური საშუალებები, რათა თავიდან ავიცილოთ პრობლემები ამ შემთხვევაში მონაცემთა მთლიანობის შენარჩუნებისას, მაგრამ თუ ეს შესაძლებელია, უმჯობესია თავიდან აიცილოთ ასეთი კოპირება ფრენაზე.

ზემოთ აღწერილი პრობლემების გადაჭრისას გამოსავალი თავისთავად გვთავაზობს: ასლების შექმნის პროცესის დაწყების გადადება დროის უმოქმედო პერიოდზე, როდესაც სარეზერვო და სხვა გაშვებული სისტემების ურთიერთგავლენა მინიმალური იქნება. ამ პერიოდს ეწოდება "სარეზერვო ფანჯარა". მაგალითად, ორგანიზაციისთვის, რომელიც მუშაობს 8x5 ფორმულით (კვირაში ხუთი რვა საათიანი სამუშაო დღე), ასეთი „ფანჯარა“ ჩვეულებრივ შაბათ-კვირას და ღამის საათებს წარმოადგენს.

24x7 ფორმულის მიხედვით მომუშავე სისტემებისთვის (მთელი კვირა მთელი საათის განმავლობაში), მინიმალური აქტივობის დრო გამოიყენება როგორც პერიოდი, როდესაც სერვერებზე არ არის მაღალი დატვირთვა.

სარეზერვო ასლების ტიპები

სარეზერვო ასლის ორგანიზებისას ზედმეტი მატერიალური ხარჯების თავიდან ასაცილებლად, ასევე, თუ ეს შესაძლებელია, არ გასცდეს სარეზერვო ფანჯარას, შემუშავებულია რამდენიმე სარეზერვო ტექნოლოგია, რომლებიც გამოიყენება კონკრეტული სიტუაციიდან გამომდინარე.

სრული სარეზერვო (ან სრული სარეზერვო)

ეს არის სარეზერვო ასლების შექმნის მთავარი და ფუნდამენტური მეთოდი, რომელშიც არჩეული მონაცემთა მასივი კოპირდება მთლიანად. ეს არის ყველაზე სრულყოფილი და საიმედო სარეზერვო მეთოდი, თუმცა ის ასევე ყველაზე ძვირია. თუ საჭიროა მონაცემთა რამდენიმე ასლის შენახვა, მთლიანი შენახული მოცულობა გაიზრდება მათი რაოდენობის პროპორციულად. ასეთი ნარჩენების თავიდან ასაცილებლად გამოიყენება შეკუმშვის ალგორითმები, ასევე ამ მეთოდის კომბინაცია სხვა სახის სარეზერვო: დამატებითი ან დიფერენციალური. და, რა თქმა უნდა, სრული სარეზერვო ასლი შეუცვლელია, როდესაც თქვენ გჭირდებათ სარეზერვო ასლის მომზადება სისტემის სწრაფი აღდგენისთვის ნულიდან.

დამატებითი ასლი

სრული სარეზერვო ასლისგან განსხვავებით, ამ შემთხვევაში, ყველა მონაცემი (ფაილი, სექტორი და ა.შ.) არ კოპირდება, არამედ მხოლოდ ის, რაც შეიცვალა ბოლო სარეზერვო ასლის შემდეგ. კოპირების დროის გასარკვევად, შეგიძლიათ გამოიყენოთ სხვადასხვა მეთოდებიმაგალითად, Windows ოპერაციული სისტემით გაშვებული სისტემები იყენებენ ფაილის შესაბამის ატრიბუტს (არქივის ბიტი), რომელიც დაყენებულია სარეზერვო პროგრამის მიერ ფაილის შეცვლისა და გასუფთავებისას. სხვა სისტემებზე შეიძლება გამოყენებულ იქნას ფაილის შეცვლის თარიღი. ნათელია, რომ ამ ტიპის სარეზერვო ასლის გამოყენებით სქემა არასრული იქნება, თუ დროდადრო არ განახორციელებთ სრულ სარეზერვო ასლს. სისტემის სრულად აღდგენისას, თქვენ უნდა აღადგინოთ სრული სარეზერვო ასლის მიერ შექმნილი ბოლო ასლიდან და შემდეგ გადაახვიოთ მონაცემები დამატებითი ასლებიდან სათითაოდ მათი შექმნის თანმიმდევრობით.

რისთვის გამოიყენება ამ ტიპის კოპირება? საარქივო ასლების შექმნის შემთხვევაში საჭიროა შემცირდეს მოხმარებული მოცულობები შესანახ მოწყობილობებზე (მაგალითად, გამოყენებული ფირის მედიის რაოდენობის შემცირება). ის ასევე საშუალებას მოგცემთ მინიმუმამდე დაიყვანოთ სარეზერვო ამოცანების შესრულების დრო, რაც შეიძლება იყოს ძალიან მნიშვნელოვანი იმ პირობებში, როდესაც გიწევთ იმუშაოთ დატვირთული 24x7 გრაფიკით ან გადაიტანოთ დიდი რაოდენობით ინფორმაცია.

დამატებითი კოპირება არის ერთი რამ, რაც უნდა იცოდეთ. ნაბიჯ-ნაბიჯ აღდგენა საჭიროებს უკან აბრუნებს წაშლილი ფაილებიაღდგენის პერიოდში. მოდი მაგალითს მოგიყვან. ვთქვათ, სრული ასლი შესრულებულია შაბათ-კვირას, ხოლო დამატებითი ასლი სამუშაო დღეებში. მომხმარებელმა შექმნა ფაილი ორშაბათს, შეცვალა სამშაბათს, დაარქვა ოთხშაბათს და წაშალა ხუთშაბათს. ასე რომ, ყოველკვირეული პერიოდის განმავლობაში მონაცემთა თანმიმდევრული ნაბიჯ-ნაბიჯ აღდგენით, ჩვენ მივიღებთ ორ ფაილს: ძველი სახელით სამშაბათს, გადარქმევამდე და ახალი სახელით, რომელიც შეიქმნა ოთხშაბათს. ეს მოხდა იმის გამო, რომ სხვადასხვა დამატებითი ასლები ინახებოდა სხვადასხვა ვერსიებიიგივე ფაილი და საბოლოოდ ყველა ვარიანტი აღდგება. ამიტომ, არქივიდან მონაცემების "როგორც არის" თანმიმდევრული წესით აღდგენისას, აზრი აქვს დისკზე მეტი სივრცის დაჯავშნას, რათა წაშლილი ფაილებიც მოთავსდეს.

დიფერენციალური სარეზერვო საშუალება

ის განსხვავდება დამატებითისგან იმით, რომ მონაცემები კოპირებულია სრული სარეზერვო ასლის ბოლო მომენტიდან. ამ შემთხვევაში მონაცემები მოთავსებულია არქივში „კუმულაციურ ჯამზე“. Windows ოჯახის სისტემებში ეს ეფექტი მიიღწევა იმით, რომ არქივის ბიტი არ იშლება დიფერენციალური კოპირების დროს, ამიტომ შეცვლილი მონაცემები შედის საარქივო ასლში, სანამ სრული ასლი არ გაასუფთავებს არქივის ბიტებს.

გამომდინარე იქიდან, რომ ამ გზით შექმნილი ყოველი ახალი ეგზემპლარი შეიცავს მონაცემებს წინადან, ის უფრო მოსახერხებელია კატასტროფის დროს მონაცემთა სრული აღდგენისთვის. ამისათვის საჭიროა მხოლოდ ორი ეგზემპლარი: სრული და ბოლო დიფერენციალური, ასე რომ თქვენ შეძლებთ მონაცემების გაცოცხლებას ბევრად უფრო სწრაფად, ვიდრე ყველა ნამატის ეტაპობრივად გადატანა. გარდა ამისა, ამ ტიპის კოპირება თავისუფალია ინკრემენტულის ზემოაღნიშნული მახასიათებლებისგან, როდესაც სრული აღდგენის შემდეგ ძველი ფაილები, როგორიცაა Phoenix ფრინველი, ხელახლა იბადება ფერფლიდან. ნაკლები დაბნეულობა წარმოიქმნება.

მაგრამ დიფერენციალური კოპირება მნიშვნელოვნად ჩამოუვარდება დამატებით კოპირებას საჭირო სივრცის დაზოგვისას. ვინაიდან ყოველი ახალი ასლი შეიცავს მონაცემებს წინადან, სარეზერვო მონაცემების მთლიანი რაოდენობა შეიძლება შედარდეს სრულ ასლთან. და, რა თქმა უნდა, განრიგის დაგეგმვისას (და გამოთვლით, მოერგება თუ არა სარეზერვო პროცესი დროებით „ფანჯარას“), თქვენ უნდა გაითვალისწინოთ დრო, რომელიც სჭირდება ბოლო, „ყველაზე სქელი“ დიფერენციალური ასლის შექმნას.

სარეზერვო ტოპოლოგია

მოდით განვიხილოთ რა არის სარეზერვო სქემები.

დეცენტრალიზებული სქემა

ამ სქემის ბირთვი არის ქსელის წილი (იხ. სურათი 1). მაგალითად, გაზიარებული საქაღალდე ან FTP სერვერი. ასევე საჭიროა სარეზერვო პროგრამების ნაკრები, დროდადრო ინფორმაციის ატვირთვა სერვერებიდან და სამუშაო სადგურებიდან, ისევე როგორც სხვა ქსელის ობიექტები (მაგალითად, კონფიგურაციის ფაილები მარშრუტიზატორებიდან) ამ რესურსზე. ეს პროგრამები დაინსტალირებულია თითოეულ სერვერზე და მუშაობს ერთმანეთისგან დამოუკიდებლად. უდავო უპირატესობა არის ამ სქემის განხორციელების სიმარტივე და მისი დაბალი ღირებულება. ოპერაციულ სისტემაში ჩაშენებული სტანდარტული ხელსაწყოები ან პროგრამული უზრუნველყოფა, როგორიცაა DBMS, შესაფერისია ასლის პროგრამებისთვის. მაგალითად, ეს შეიძლება იყოს ntbackup პროგრამა Windows ოჯახისთვის, tar პროგრამა UNIX-ის მსგავსი ოპერაციული სისტემებისთვის, ან სკრიპტების ნაკრები, რომელიც შეიცავს ჩაშენებულ SQL Server ბრძანებებს მონაცემთა ბაზების სარეზერვო ფაილებში გადაყრისთვის. კიდევ ერთი პლიუსი არის სხვადასხვა პროგრამებისა და სისტემების გამოყენების შესაძლებლობა, თუ მათ შეუძლიათ წვდომა სარეზერვო ასლების შესანახად სამიზნე რესურსზე.

მინუსი არის ამ სქემის დუნე. ვინაიდან პროგრამები დამონტაჟებულია ერთმანეთისგან დამოუკიდებლად, თქვენ უნდა დააკონფიგურიროთ თითოეული მათგანი ცალკე. საკმაოდ რთულია გრაფიკის თავისებურებების გათვალისწინება და დროის ინტერვალების გამოყოფა სამიზნე რესურსისთვის კონკურენციის თავიდან აცილების მიზნით. მონიტორინგი ასევე რთულია, თითოეული სერვერიდან კოპირების პროცესი უნდა იყოს მონიტორინგი სხვებისგან განცალკევებით, რაც თავის მხრივ შეიძლება გამოიწვიოს მაღალი შრომითი ხარჯები.

ამიტომ, ეს სქემა გამოიყენება მცირე ქსელებში, ასევე იმ სიტუაციაში, როდესაც შეუძლებელია ცენტრალიზებული სარეზერვო სქემის ორგანიზება ხელმისაწვდომი საშუალებებით. მეტი დეტალური აღწერაეს სქემა და პრაქტიკული ორგანიზაცია შეგიძლიათ იხილოთ.

ცენტრალიზებული სარეზერვო

წინა სქემისგან განსხვავებით, ამ შემთხვევაში, გამოიყენება მკაფიო იერარქიული მოდელი, რომელიც მუშაობს კლიენტ-სერვერის პრინციპზე. კლასიკურ ვერსიაში თითოეულ კომპიუტერზე დამონტაჟებულია სპეციალური აგენტის პროგრამები, ხოლო ცენტრალურ სერვერზე დამონტაჟებულია პროგრამული პაკეტის სერვერის მოდული. ამ სისტემებს ასევე აქვთ გამოყოფილი სერვერის მართვის კონსოლი. კონტროლის სქემა ასეთია: კონსოლიდან ვქმნით დავალებებს კოპირების, აღდგენის, სისტემის შესახებ ინფორმაციის შეგროვების, დიაგნოსტიკისა და ა.შ. და სერვერი აძლევს აგენტებს აუცილებელ ინსტრუქციებს ამ ოპერაციების შესასრულებლად.

ასე მუშაობს ყველაზე პოპულარული სარეზერვო სისტემები, როგორიცაა Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula და სხვა (იხ. სურათი 2).

ოპერაციული სისტემების უმეტესობისთვის სხვადასხვა აგენტების გარდა, არსებობს განვითარებები პოპულარული მონაცემთა ბაზების სარეზერვო ასლისთვის და კორპორატიული სისტემებიმაგალითად, MS SQL სერვერისთვის, MS Exchange, Oracle მონაცემთა ბაზისთვის და ა.შ.

ძალიან მცირე კომპანიებისთვის, ზოგიერთ შემთხვევაში, შეგიძლიათ სცადოთ ცენტრალიზებული სარეზერვო სქემის გამარტივებული ვერსია აგენტის პროგრამული უზრუნველყოფის გამოყენების გარეშე (იხ. სურათი 3). ასევე, ამ სქემის გამოყენება შესაძლებელია, თუ გამოყენებული სარეზერვო პროგრამული უზრუნველყოფის სპეციალური აგენტი არ არის დანერგილი. ამის ნაცვლად, სერვერის მოდული გამოიყენებს არსებულ სერვისებსა და სერვისებს. მაგალითად, "scoop" მონაცემები დამალული გაზიარებული საქაღალდეები Windows სერვერებზე ან დააკოპირეთ ფაილები SSH პროტოკოლისერვერებიდან, რომლებიც მუშაობენ UNIX სისტემებზე. ამ სქემას აქვს ძალიან მნიშვნელოვანი შეზღუდვები, რომლებიც დაკავშირებულია ჩაწერისთვის ღია ფაილების შენახვის პრობლემებთან. ასეთი ქმედებების შედეგად, ღია ფაილები ან გამოტოვებული იქნება და არ შეიქმნება სარეზერვო ასლი, ან დაკოპირდება შეცდომით. ამ პრობლემის გადაჭრის სხვადასხვა გზა არსებობს, მაგალითად, სამუშაოს ხელახლა გაშვება მხოლოდ ადრე გახსნილი ფაილების კოპირებისთვის, მაგრამ არცერთი არ არის სანდო. ამიტომ, ასეთი სქემა შესაფერისია მხოლოდ გარკვეულ სიტუაციებში გამოსაყენებლად. მაგალითად, პატარა 5x8 ორგანიზაციებში მოწესრიგებული თანამშრომლებით, რომლებიც ინახავენ ცვლილებებს და ხურავენ ფაილებს სახლიდან გასვლამდე. ასეთი შეკვეცილი ცენტრალიზებული სქემის ორგანიზება, რომელიც მუშაობს ექსკლუზიურად Windows გარემო, ntbackup კარგად მუშაობს. თუ თქვენ გჭირდებათ მსგავსი სქემის გამოყენება ჰეტეროგენულ გარემოში ან ექსკლუზიურად UNIX კომპიუტერებს შორის, გირჩევთ გადახედოთ სარეზერვო კომპიუტერს (იხ.).

სურათი 4. შერეული სარეზერვო სქემა

რა არის off-site?

ჩვენს მშფოთვარე და არასტაბილურ სამყაროში შეიძლება მოხდეს მოვლენები, რამაც შეიძლება გამოიწვიოს უსიამოვნო შედეგები IT ინფრასტრუქტურისა და ზოგადად ბიზნესისთვის. მაგალითად, ხანძარი შენობაში. ან ცენტრალური გათბობის ბატარეის გარღვევა სერვერის ოთახში. ან აღჭურვილობისა და კომპონენტების ბანალური ქურდობა. ასეთ სიტუაციებში ინფორმაციის დაკარგვის თავიდან აცილების ერთ-ერთი მეთოდი არის სარეზერვო ასლების შენახვა სერვერის აღჭურვილობის ძირითადი მდებარეობიდან დაშორებულ ადგილას. ამ შემთხვევაში აუცილებელია უზრუნველყოს სწრაფი გზააღდგენისთვის საჭირო მონაცემებზე წვდომა. აღწერილ მეთოდს უწოდებენ off-site (სხვა სიტყვებით რომ ვთქვათ, ასლების შენახვა საიტის გარეთ). ძირითადად, ამ პროცესის ორგანიზების ორი მეთოდი გამოიყენება.

მონაცემების ჩაწერა მოსახსნელ მედიაზე და ფიზიკურად გადატანა. ამ შემთხვევაში, თქვენ უნდა იზრუნოთ მარცხის შემთხვევაში მედიის სწრაფად მიწოდების საშუალებებზე. მაგალითად, შეინახეთ ისინი ახლომდებარე შენობაში. ამ მეთოდის უპირატესობა არის ამ პროცესის ყოველგვარი სირთულის გარეშე ორგანიზების შესაძლებლობა. მინუსი არის მედიის დაბრუნების სირთულე და ინფორმაციის შესანახად გადაცემის აუცილებლობა, ასევე ტრანსპორტირების დროს მედიის დაზიანების რისკი.

მონაცემთა კოპირება სხვა ადგილას ქსელის არხის საშუალებით. მაგალითად, VPN გვირაბის გამოყენება ინტერნეტით. უპირატესობა ამ შემთხვევაში ის არის, რომ არ არის საჭირო მედიის სადმე გადატანა ინფორმაცია, მინუსი არის საკმარისად ფართო არხის გამოყენების აუცილებლობა (როგორც წესი, ეს ძალიან ძვირია) და გადაცემული მონაცემების დაცვა (მაგალითად, გამოყენებით იგივე VPN). დიდი რაოდენობით მონაცემების გადაცემისას წარმოქმნილი სირთულეები შეიძლება მნიშვნელოვნად შემცირდეს შეკუმშვის ალგორითმების ან დედუპლიკაციის ტექნოლოგიის გამოყენებით.

ცალკე, უნდა ითქვას უსაფრთხოების ზომების შესახებ მონაცემთა შენახვის ორგანიზებისას. უპირველეს ყოვლისა, აუცილებელია მონაცემთა მატარებლების დაცულ ტერიტორიაზე ყოფნა და ზომების შესახებ, რომლებიც ხელს უშლის არაავტორიზებული პირების მიერ მონაცემების წაკითხვას. მაგალითად, გამოიყენეთ დაშიფვრის სისტემა, გააფორმეთ ხელშეკრულება გამჟღავნების შესახებ და ა.შ. თუ ჩართულია მოსახსნელი მედია, მასზე არსებული მონაცემები ასევე უნდა იყოს დაშიფრული. ამ შემთხვევაში გამოყენებული მარკირების სისტემა არ უნდა დაეხმაროს თავდამსხმელს მონაცემთა ანალიზში. გადაცემული ფაილების სახელების მატარებლების აღსანიშნავად აუცილებელია უსახური ნუმერაციის სქემის გამოყენება. ქსელში მონაცემთა გადაცემისას აუცილებელია (როგორც უკვე აღვნიშნეთ) მონაცემთა გადაცემის უსაფრთხო მეთოდების გამოყენება, მაგალითად, VPN გვირაბი.

ჩვენ განვიხილეთ ძირითადი პუნქტები სარეზერვო ასლის ორგანიზებისას. შემდეგ ნაწილში განიხილება მეთოდოლოგიური რეკომენდაციები და პრაქტიკული მაგალითებიეფექტური სარეზერვო სისტემის შესაქმნელად.

1. სარეზერვო ასლის აღწერა შიგნით ვინდოუსის სისტემა, სისტემის მდგომარეობის ჩათვლით - http://www.datamills.com/Tutorials/systemstate/tutorial.htm.
2. Shadow Copy-ის აღწერა - http://ru.wikipedia.org/wiki/Shadow_Copy.
3. Acronis ოფიციალური საიტი - http://www.acronis.ru/enterprise/products.
4. ntbackup-ის აღწერა - http://en.wikipedia.org/wiki/NTBackup.
5. ა. ბერეჟნოი MS SQL სერვერის ოპტიმიზაცია. // სისტემის ადმინისტრატორი, No1, 2008 - გვ. 14-22 ().
6. ა. ბერეჟნოი. ჩვენ ვაწყობთ სარეზერვო სისტემას მცირე და საშუალო ზომის ოფისებისთვის. // სისტემის ადმინისტრატორი, No6, 2009 - გვ. 14-23 ().
7. Markelov A. Linux Windows-ის დაცვაზე. სარეზერვო სისტემის BackupPC-ის მიმოხილვა და ინსტალაცია. // სისტემის ადმინისტრატორი, No 9, 2004 - S. 2-6 ().
8. VPN აღწერა - http://ru.wikipedia.org/wiki/VPN.
9. მონაცემთა დედუპლიკაცია - http://en.wikipedia.org/wiki/Data_deduplication.

კონტაქტში

თითქმის ყველა ჩვენი მომხმარებელი, რომლებმაც დანერგეს სარეზერვო სისტემები (DBS) თვლის, რომ ამან გადაჭრა მათი ყველა პრობლემა. მათ ყველაფერი გააკეთეს იმისთვის, რომ ყველაფერი დამყარებულიყო და უბედური შემთხვევის შემთხვევაში, სწორად აღდგეს. მაგრამ ეს ხშირად ხდება ასე: კომპანიას სერიოზული პრობლემის წინაშე დგას და ტრადიციული სარეზერვო სისტემა არ იძლევა აღდგენას იმ დროში, რომელსაც კომპანია თვლის სამიზნედ. სინამდვილეში, SLA, რომელსაც სარეზერვო სისტემა უნდა აკმაყოფილებდეს, არ არის დაკმაყოფილებული. სამწუხაროდ, ჩვენი მუშაობის დროს დაგვიგროვდა ამის დამადასტურებელი მრავალი სამწუხარო მაგალითი. ქვემოთ მოგცემთ ორ შემთხვევას და მივცემთ რჩევებს, თუ რა ტექნიკური საშუალებები შეამცირებს აღდგენის დროს. საქმეების არჩევისას შევჩერდით მონაცემთა ბაზებთან დაკავშირებულ მაგალითებზე, სადაც ინახებოდა ბიზნესისთვის ყველაზე კრიტიკული ინფორმაცია.

საცალო გამოწვევები

კლიენტი:დიდი სადაზღვევო კომპანია.

ავარიის მიზეზის მოკლე აღწერა: პერსონალის შეცდომა, არასწორი პაჩის დაყენება Oracle-ზე.

პრობლემის აღწერა

ეს არის მსხვილი კომპანია, რომელსაც აქვს მომწიფებული IT დეპარტამენტი და საკმარის ინვესტიციას ახდენს მის აღჭურვილობასა და პერსონალში. საკმარისია ითქვას, რომ Oracle DBMS მუშაობდა ორ Oracle Exadata-ზე, განაწილებული ორ ტექნოლოგიურ საიტზე, კარგად განვითარებული DR გადაწყვეტილებით და კონფიგურირებული სარეზერვო სისტემით.

ერთ სამწუხარო დღეს გადაწყდა პაჩის დაყენება Oracle DBMS-ზე. სამწუხაროდ, ინჟინერმა ბოლომდე არ წაიკითხა ინსტრუქცია: "მე რა ვარ, ქაღალდის გარეშე არ დავაყენებ პატჩს?!" - და არასწორად მოიქცა. შეცდომა შენიშნეს რამდენიმე საათის შემდეგ, როდესაც DBMS-მა დაიწყო უცნაურად ქცევა და ამის შესახებ მოხსენებებში. შემდეგ ინჟინერმა გადაწყვიტა უკან დაბრუნებულიყო. ამ მოქმედებამ საბოლოოდ გააუქმა მონაცემთა ბაზის ორივე ასლი (ყველა ცვლილება განმეორდა Standby-ზე) და დაზიანდა ყველა მონაცემი.

კომპანია დარჩა ძირითადი საინფორმაციო აქტივის - მონაცემთა ბაზის გარეშე, რომლის მეშვეობითაც ყველა ბიზნეს პროცესი მუშაობდა. ბიზნესი პრაქტიკულად შეჩერდა.

გამოსავალი

მომხმარებელმა გადაწყვიტა აღდგენა სარეზერვოდან. იმ დროს 5 TB მონაცემთა ბაზის აღდგენას (ახლა ~ 15 TB) - ყურადღება! - 30 საათზე მეტი!საერთო ჯამში, 1,5 დღის შემდეგ, ბაზა ავარიამდე ერთი დღით ადრე აღდგა. მაგრამ იყო მეტი მონაცემი! ყველაფერი დანარჩენი აღადგინეს პროგრამისტებმა და თანამშრომლებმა კომპანიის სხვა სისტემებიდან, პირველადი დოკუმენტაციიდან (განაცხადის ფორმები, ასლები, სკანირება). დასჭირდა კიდევ 1,5 დღე მძიმე შრომას.

სულ

2 მაღალი დონის Oracle Exadata სისტემა, Oracle Standby, სამუშაო სარეზერვო სისტემა და 3 !!! დღის სრული შეფერხებაზე არასწორი ინსტალაციაპატჩი. იყო თუ არა ეს დასაშვები კომპანიის წესების მიხედვით? Რათქმაუნდა არა.

მთავარი პრობლემა: ლოგიკური შეცდომებისგან სწრაფი აღდგენის ხელსაწყოების ნაკლებობა.

როგორ შეგეძლო თავიდან აეცილებინა

ასეთი ავარიების შედეგების შესამცირებლად, თქვენ უნდა იმოძრაოთ ორი მიმართულებით. ერთის მხრივ, უფრო ხშირად გააკეთეთ სარეზერვო ასლები და, მეორე მხრივ, შეძლებთ სწრაფად აღდგენას. შემდეგი პროდუქტები შეიძლება დაგეხმაროთ:

Oracle FlashBack- ტექნოლოგია, რომელიც საშუალებას გაძლევთ არა მხოლოდ „გადააგდოთ“ ახალი მონაცემები სარეზერვო სისტემა Oracle, არამედ სასურველ ტრანზაქციაზე დაბრუნება. ასეთი სქემით შესაძლებელი იქნება სისტემის უკან დაბრუნება პატჩის პრობლემების დაწყებამდე, რაც მნიშვნელოვნად შეუწყობს ხელს მონაცემთა აღდგენას.

Snapshot ტექნოლოგია. Snapshots საშუალებას გაძლევთ შექმნათ სარეზერვო ასლები და აღადგინოთ მონაცემები წამებში. ამავდროულად, ისინი მცირე გავლენას ახდენენ შესრულებაზე და შესაძლებელია ფოტოების გადაღება საკმაოდ ხშირად (მაგალითად, საათში ერთხელ). ამრიგად, შესაძლებელი გახდა ერთი საათის უკან დაბრუნება და დაკარგული მონაცემების მხოლოდ ერთი საათის აღდგენა.

მონაცემთა უწყვეტი დაცვა- მონაცემთა უწყვეტი დაცვა. ეს არის საკუთრების მოწყობილობა ან პროგრამული უზრუნველყოფა, რომელიც საშუალებას გაძლევთ შეიყვანოთ ყველა ჩანაწერი დროის ნებისმიერ მომენტში დაბრუნების შესაძლებლობით. მოქმედებს როგორც Oracle FlashBack, მაგრამ ნებისმიერი მონაცემისთვის.

შემთხვევა: აპარატურის უკმარისობა

კლიენტი:ფედერალური სამსახური რუსეთის ფედერაციის ერთ-ერთ სუბიექტში

ავარიის მიზეზის მოკლე აღწერა: აპარატურის შეცდომა დისკის მასივში.

პრობლემის აღწერა

ამჯერად კომპანიას აქვს ოდნავ ნაკლებად განვითარებული IT ინფრასტრუქტურა, მაგრამ ის უფრო ხშირია ჩვენს მომხმარებლებს შორის: არ გამოიყენება საშუალო დონის დისკის მასივები, Oracle DBMS, Standby.

როგორც ხშირად ხდება, პარასკევს, როცა ყველა უკვე სიამოვნებით მიდიოდა სახლში, იყო მასივის ტექნიკის გაუმართაობა. პროგრამული უზრუნველყოფის შეცდომის გამო, თუ დისკი იშლება, მასივი მონაცემებს არეულობაში აქცევს. ამის გამო ფედერალური დონის სამსახურის მონაცემთა ბაზებმა შეწყვიტეს მუშაობა. დღეზე მეტი ხნის განმავლობაში მომხმარებელი ელოდა გამოსავალს შენახვის გამყიდველისგან. ყველა ჟურნალის გაანალიზების შემდეგ, გამყიდველმა დაასკვნა: მონაცემები დაკარგულია!

გამოსავალი

მომხმარებელმა მიიღო გადაწყვეტილება სარეზერვოდან აღდგენის შესახებ. ამ პროცესს დაახლოებით ერთი დღე დასჭირდა, მიუხედავად ყველა შესწორებისა და შესრულების დარეგულირებისა (ბაზა საკმაოდ დიდია). სანამ მონაცემთა ბაზის აღდგენა ხდებოდა, ჟურნალების სარეზერვო ასლი დაიკარგა (შეკავების პერიოდი ძალიან მცირე იყო, SRK-მ ისინი თავად წაშალა).

შემდგომი - უფრო ღრმა. კომპანია, ისევე როგორც მრავალი სხვა, რაღაც მომენტში იყენებდა არალოგის ოპერაციებს Oracle-ში, რაც სერიოზულად აუმჯობესებს შესრულებას, მაგრამ არ ტოვებს აღდგენის შანსს, გარდა სარეზერვო. ანუ, ეს უნდა გაკეთდეს დაუყოვნებლივ ოპერაციების სესიის გავლის შემდეგ. ბუნებრივია, ეს წლების განმავლობაში დავიწყებას მიეცა ტექნიკური განყოფილებაში. ამრიგად, მონაცემების ნაწილი მთლიანად დაიკარგა.

კიდევ რამდენიმე დღე დასჭირდა ინფრასტრუქტურის სერვისების სრულად აღდგენას - არ იყო ოპერაციული სისტემების სარეზერვო ასლები, ბინარები, კონფიგურაციები და ა.შ.

ყველა დაკარგული ინფორმაცია შეგროვდა პირველადი დოკუმენტებიდან (მესამე მხარის მონაცემთა ბაზები, ქაღალდის დოკუმენტები, მონაცემები მთვლელების კომპიუტერებზე), რასაც კიდევ 3 დღე დასჭირდა. ზოგიერთი დოკუმენტი შესაძლოა არასოდეს აღმოჩენილიყო.

სულ

მასივის პრობლემამ გამოიწვია მონაცემთა დაკარგვა და შეფერხება დაახლოებით ერთი კვირის განმავლობაში! თანამედროვე პირობებში ამან შეიძლება გამოიწვიოს კომპანიის გაკოტრება.

ძირითადი პრობლემები:

• IBS არასწორად იყო კონფიგურირებული და არ ჩატარებულა საცდელი რესტავრაცია.
• არ არსებობდა სწრაფი აღდგენის საშუალებები კატასტროფის და ზედმეტი სისტემების შემთხვევაში.
• არ იყო მკაფიო DR გეგმა.

როგორ შეიძლებოდა ამის თავიდან აცილება:

• გამოიყენეთ Oracle Standby, რომელიც მდებარეობს სხვა მასივზე. ეს საშუალებას მისცემს მოკლე დროში გადახვიდეთ გაშვებულ მონაცემთა მაგალითზე.
• Oracle ZDLRA საშუალებას მოგცემთ აღადგინოთ მონაცემთა ბაზა სარეზერვო მოწყობილობაზე ბევრად უფრო მოკლე დროში.
• სარეზერვო და აღდგენის პროცესების ჭკვიანურმა დაგეგმვამ შეიძლება თავიდან აიცილოს ასეთი დიდი დანაკარგები და აღდგეს ერთ დღეში ნაკლებ დროში.

გამომავალი.ზემოთ მოყვანილი მაგალითებიდან ჩანს, რომ სარეზერვო სისტემები დაინსტალირებული და კონფიგურირებული იყო, მაგრამ ამის მიუხედავად, მათ ვერ მოახერხეს აღდგენა SLA-ში მითითებულ ვადებში.

სარეზერვო სისტემების ძირითადი პრობლემები

ჩვენი გამოცდილებიდან გამომდინარე, გადავწყვიტეთ გამოვყოთ მთელი რიგი პრობლემები, რომლებსაც, ჩვენი აზრით, განსაკუთრებული ყურადღება უნდა მიექცეს.

სარეზერვო და აღდგენის სიჩქარე

ჩართულია ამ მომენტშისარეზერვო სიჩქარე პირდაპირპროპორციულია მონაცემთა მოცულობის, მაშინ როცა ყველა ჩვენს მომხმარებელს აქვს მონაცემების წლიური ზრდა მინიმუმ 30%. 3-4 წელიწადში მონაცემები მინიმუმ გაორმაგდება, მაგრამ ზოგიერთი კომპანიისთვის ეს მაჩვენებელი კიდევ უფრო მაღალია, ხოლო სარეზერვო სიჩქარე არ იცვლება ამავე დროს. აქ შეგვიძლია გავაკეთოთ მარტივი დასკვნა, რომ ის ტერმინები და ის SLA-ები, რომლებიც აქტუალური იყო 3-4 წლის წინ, ახლა მინიმუმ ორჯერ უნდა გაიზარდოს. ამავდროულად, ბიზნეს მოთხოვნები მონაცემთა აღდგენისთვის (RPO / RTO) მუდმივად იზრდება.

თანდათანობით, კომპანიის ყველა ბიზნეს პროცესი გადადის IT-ზე და ქაღალდის პირველადი (დოკუმენტების ასლები და ორიგინალები, განცხადებები, სკანირება და ა.შ.) კვდება. ყველაფერი ტრიალებს IT სისტემებში და მონაცემთა დაკარგვა, ფაქტობრივად, ყველაფრის დაკარგვაა. IT-ს შეცდომის ადგილი აღარ აქვს. ჩვენ მიერ მოწოდებულ საქმეებში მუდმივად, როცა მონაცემები არ იყო ხელმისაწვდომი სხვადასხვა გარემოებების გამო, კომპანიები ვერ ფუნქციონირებდნენ. ამან გამოიწვია როგორც პირდაპირი ზარალი, როდესაც შეუძლებელი იყო ორგანიზაციის ძირითადი ბიზნეს პროცესის განხორციელება, ასევე იმპლიციტური, მაგალითად, რეპუტაციის ზარალი, რომელიც არც ისე ადვილია გაზომვა ფულადი თვალსაზრისით, მაგრამ რომელიც გრძელვადიან პერსპექტივაშია. ვადამ შეიძლება არანაკლებ ზიანი მიაყენოს კომპანიას.

სურათზემე ასახული მაქვს ჩემი დაკვირვებები აღდგენის დროზე (RTO). როგორც თქვენი მონაცემები იზრდება, აღდგენის რეალური დრო აუცილებლად გაიზრდება და SLA მოთხოვნები მხოლოდ მკაცრდება. გრაფიკის წერტილი, სადაც ფაქტობრივი დრო უდრის საჭირო დროს, უკვე გავლილია კლიენტების უმეტესობისთვის.

აღდგენის დრო მონაცემთა მოცულობასთან შედარებით

აღდგენის დაბალი მარცვლოვნება

სინამდვილეში, შეცდომების უმეტესობა დაკავშირებულია მონაცემთა გარკვეული ნაწილის დაკარგვასთან. ამავდროულად, ტრადიციული სარეზერვო ინსტრუმენტები საშუალებას გაძლევთ აღადგინოთ მონაცემები პირდაპირ სარეზერვოდან, მაგრამ უფრო ხშირად თქვენ უნდა აღადგინოთ მთელი სისტემა. თუ თქვენი მონაცემთა ბაზა 15 ტბაიტია, ამას რამდენიმე დღე დახარჯავთ. ჩვენ არ ვიცნობთ კლიენტებს, რომლებსაც აქვთ RTO (აღდგენის დროის მიზანი) მოთხოვნა 2 დღის განმავლობაში. ჩვენს პრაქტიკაში არ იყო ისეთი მაგალითები, როდესაც კლიენტი იტყოდა: ”ბიჭებო, კარგია, რომ გამოჯანმრთელდეს 2 დღეში, მე ამას მოვითმენ” - თუ ადმინისტრატორმა შემთხვევით წაშალა რამდენიმე სტრიქონი მონაცემთა ბაზიდან. საკმაოდ გავრცელებული პრობლემა, რომელსაც ჩვენი კლიენტები აწყდებიან: როგორ ამოიღოთ მონაცემთა მცირე ნაწილი სარეზერვო ასლიდან მისი აღდგენის გარეშე (და არ დახარჯოთ მასზე რამდენიმე დღე).

გადაჭარბებული RPO (აღდგენის წერტილის მიზანი)

მსოფლიოში, სადაც პირველადი ქაღალდი გაქრა და ყველაფერი ინახება IT სისტემებში, ყოველი წამი ქმნის მონაცემებს, რომელთა დაცვაც მსურს დაუყოვნებლივ - სწორედ იმ მომენტში, როდესაც ის შეიქმნა. მაგრამ ეს არ შეიძლება გაკეთდეს კლასიკური სარეზერვო სისტემების გამოყენებით. თითოეული მონაცემისთვის არის გარკვეული ხანგრძლივი პერიოდი, რომლის განმავლობაშიც ეს მონაცემები არსებობს მთელ მსოფლიოში ერთ ეგზემპლარად. ჩვენს მომხმარებლებს სურთ თავიანთი მონაცემების დაცვა უწყვეტად, მათი გამოჩენის მომენტიდან. სარეზერვო ასლიდან აღდგენის გადაწყვეტილების მიღებისას, დიდი ალბათობით მოგიწევთ აღდგენა ერთი დღის წინ, შემდეგ მონაცემების მიღება დაგჭირდებათ სხვაგან დღეში. როგორც წესი, არის ხანგრძლივი მუშაობაადმინისტრატორებს რამდენიმე დღე სჭირდება. მოვლენების ყველაზე უარყოფითი განვითარებით, ამან შეიძლება გამოიწვიოს ზარალი. კრიტიკული ინფორმაცია... რა თქმა უნდა, საკითხი არ შემოიფარგლება მხოლოდ სარეზერვო საშუალებით, ეს ეხება მთლიანად IT სისტემის მშენებლობას, მაგრამ SRK-ის თემა ამ შემთხვევაში ძალიან მნიშვნელოვანია, მისი უგულებელყოფა არ შეიძლება.

ფარული შეცდომები

სამწუხაროდ, ჯერ კიდევ არ არის იაფი და სწრაფი ვარიანტები იმის შესამოწმებლად, თუ რამდენად კარგად არის გაკეთებული სარეზერვო საშუალება. რა თქმა უნდა, ეს შეიძლება გაკეთდეს პერიოდული ტესტის აღდგენით, მაგრამ ეს არის ძალიან ძვირი ოპერაცია ადამიანის ძალისხმევისა და IT რესურსების თვალსაზრისით. ეს არის ცალკე გუნდის მუშაობა ცალკე აპარატზე.

სამწუხაროდ, ჩვენი კლიენტების უმეტესობა ამას არ აკეთებს. ხშირად ხდება, რომ ყველა აკეთებს სარეზერვო ასლებს, მაგრამ აღდგენის დროისთვის აღმოჩნდება, რომ მათი გაკეთება შეუძლებელი იყო - მათი აღდგენა უბრალოდ შეუძლებელია, მიუხედავად RMS-ის გარეგნულად სწორი მუშაობისა. ეს ხდება სხვადასხვა მიზეზის გამო. ეს საუკეთესოდ ილუსტრირებულია მაგალითით. ერთ-ერთმა ჩვენმა მომხმარებელმა გამოიყენა SAP სისტემა Oracle-ის მონაცემთა ბაზით. სარეზერვო ასლი განხორციელდა ჩაშენებული SAP ინსტრუმენტებით, ერთ-ერთი უმსხვილესი SRK გამყიდველის დახმარებით.

კონფიგურირებული იყო ორი განსხვავებული სარეზერვო პოლიტიკა: ერთი მათგანი იყო ფაილზე დაფუძნებული - კოპირებული იყო ოპერაციული სისტემებისა და პროგრამული პარამეტრების მონაცემები, ხოლო მეორე - თავად მონაცემთა ბაზა. ვინაიდან ისინი მიმართული იყვნენ იმავე სისტემაზე, კონფიგურირებული იყო გამორიცხვის სია და შევიდა მონაცემთა ბაზაში. ფაილური პოლიტიკა ითვალისწინებდა ამ სიას და არ იტოვებდა დირექტორიას, რომელშიც განთავსებული იყო მონაცემთა ბაზა. SRK არქიტექტურის თავისებურებების გამო, მონაცემთა ბაზის სარეზერვო პოლიტიკამ უგულებელყო გამონაკლისების სია და სწორად დააკოპირა საჭირო მონაცემები.

ერთ-ერთ პროგრამულ გამოცემაში ამ გამყიდველმა გამოასწორა ეს „შეცდომა“, იმ დღიდან ორივე პოლიტიკოსმა დაიწყო გამორიცხვების სიის გათვალისწინება და მონაცემთა ბაზის გვერდის ავლით. უფრო მეტიც, ამან არანაირად არ იმოქმედა SRK პროგრამულ შეცდომებზე, რადგან ის ნორმალურად მუშაობდა: სიაში არ მითითებული ყველა მონაცემი ნორმალურად იყო სარეზერვო ასლი. სისტემამ იტყობინება, რომ ის გამართულად მუშაობდა.

ამრიგად, ყველაფერი მუშაობდა ექვს თვეზე მეტი ხნის განმავლობაში. იმ მომენტამდე, სანამ საჭირო გახდა აღდგენა ...

არასისტემური მიდგომა

მნიშვნელოვანი პრობლემაა სარეზერვო პრობლემის არასისტემური მიდგომა. SRK ისტორიულად აშენებულია ან თავად კომპანიის მიერ ან ინტეგრატორის მიერ. მშენებლობის დროს ის რა თქმა უნდა აკმაყოფილებდა ყველა მოთხოვნას და მთლიანად ასრულებდა თავის ფუნქციას. წლების განმავლობაში შეიცვალა კომპანიის IT ლანდშაფტი. ამავდროულად, სარეზერვო სისტემა უბრალოდ მორგებული იყო მასზე, როგორც სისტემა განვითარდა, და ყველაზე ხშირად არ იყო დაცული სისტემატური მიდგომა, რომელიც ითვალისწინებდა სისტემის შესაბამისობის მნიშვნელობას საწყის ინდიკატორებთან ყველა მომდევნო ეტაპზე. თქვენს ორგანიზაციაში მონაცემთა დაცვის სისტემის შექმნისას გახსოვდეთ - ეს თქვენი მონაცემთა დაცვის სტრატეგიის მხოლოდ ნაწილია.

ჩვენ წარმოვადგინეთ რამდენიმე შემთხვევის შესწავლა, რომელიც აჩვენებს, რომ მონაცემთა დაცვის მიდგომა უნდა იყოს ყოვლისმომცველი. სამწუხაროდ, SRK არის მხოლოდ სარეზერვო პარაშუტი და არა ვერცხლის ტყვია, ასე რომ, როდესაც დაიწყებთ მის შექმნას, ნათლად უნდა გესმოდეთ, რა ადგილს დაიკავებს იგი მონაცემთა დაცვის გლობალურ სტრატეგიაში.

იმის შესამოწმებლად, თუ რამდენად სისტემატიურად მიუდგეთ IMS-ის აგების საკითხს, უპასუხეთ რამდენიმე მარტივ კითხვას:

• გაქვთ ჩაშენებული რისკის მოდელი, რომლის ფარგლებშიც გაწერილია IBS-ის ადგილი?
• რა ჩავარდნებისაგან გიცავთ IBS?
• როგორ იცავთ თავს სხვა რისკებისგან (ეს შეიძლება იყოს არა მხოლოდ ტექნიკური გადაწყვეტილებები, არამედ სხვა კომპენსატორული ზომებიც)?
• დარწმუნებული ხართ, რომ სისტემა დროულად აღდგება?
• ეს პრაქტიკაში გამოსცადე?

გამოსავალი

საკუთარი გამოცდილებიდან და ჩვენი მომხმარებლების გამოცდილებიდან გამომდინარე, შევეცადეთ შეგვემუშავებინა ისეთი მიდგომა, რომელიც მოაგვარებდა ან მნიშვნელოვნად შეამცირებდა ჩამოთვლილი პრობლემების შედეგებს. ჩვენი მიდგომის არსი:

პირველ რიგში, აუცილებელია სარეზერვო და აღდგენის სიჩქარის გამორთვა სისტემის მოცულობიდან.მონაცემთა შენახვის სისტემების, აპლიკაციის პროგრამული უზრუნველყოფის და RMS მწარმოებლები ვარაუდობენ, რომ გამოიყენონ რამდენიმე ინსტრუმენტი, რომელიც შეიძლება გამოყენებულ იქნას ამ პრობლემის გადასაჭრელად. ქვემოთ აღვწერ მათგან ყველაზე პერსპექტიულს.

Snapshots (snapshots) საშუალებას გაძლევთ შექმნათ სარეზერვო ასლები და აღადგინოთ მონაცემები წამებში, მცირედი ან ყოველგვარი ზემოქმედებით შესრულებაზე. ეს კეთდება მასივის საშუალებით და ამავდროულად SRK შეიძლება კონტროლდებოდეს, იყოს მისი პოლიტიკის ნაწილი. ამ სახის სარეზერვო ასლსა და აღდგენას ნამდვილად სჭირდება წამები, რაც განასხვავებს ამ ტექნოლოგიას კლასიკური სისტემებისგან უცხო მედიით.

სხვა გამოსავალი შეიძლება იყოს სხვადასხვა აპლიკაციის ხელსაწყოების გამოყენება, როგორიცაა Oracle Standby, DB2 HADR, MS SQL Always On. ყველა ეს ხელსაწყო საშუალებას გაძლევთ გქონდეთ წარმოების სისტემის სამუშაო ასლი, ორიგინალისგან მოწყვეტილი, რომელიც შეიძლება მყისიერად განთავსდეს. ეს საშუალებას გაძლევთ დაუყოვნებლივ დაიწყოთ მუშაობა წარუმატებლობის შემდეგ.

მეორე არის შესაძლებელი გახდეს მხოლოდ თქვენთვის საჭირო მონაცემების აღდგენა.ჩვენი მიდგომა ითვალისწინებს, რომ მონაცემთა ნაწილის აღდგენისას არ გვჭირდება მთლიანი სისტემის კოპირება, ჩვენ შეგვიძლია აღვადგინოთ ის მონაცემები, რაც ჩვენ გვჭირდება მოცემულ მომენტში. ეს მიიღწევა ამ მონაცემების შემცველი უკვე განლაგებული სისტემების სწრაფად განლაგების ან გამოყენების შესაძლებლობით. როგორც პირველ შემთხვევაში, Snapshot გაძლევთ საშუალებას მოაგვაროთ ეს პრობლემა (შეგიძლიათ სწრაფად გახსნათ სნეპშოტი მეზობელ სერვერზე და ამოიღოთ საჭირო მონაცემები). ეს ასევე მოიცავს მონაცემთა უწყვეტი დაცვის ტექნოლოგიებს, მაგალითად, Oracle Standby ერთად Flashback, მონაცემთა უწყვეტი დაცვის (CDP) გადაწყვეტილებებს. ისინი საშუალებას გაძლევთ სწრაფად განათავსოთ თქვენი მონაცემების სამუშაო ასლი შესაფერისი მომენტიდრო.

როდესაც გჭირდებათ ერთი ლოგიკური ბლოკის მიღება, მაგალითად, სტრიქონი ან მონაცემთა ბაზის ცხრილი, ეს ხელსაწყოები მნიშვნელოვნად უწყობს ხელს დავალებას, რაც საშუალებას გაძლევთ აღადგინოთ საჭირო მონაცემები მთელი ასლის აღდგენის გარეშე.

მესამე არის შემცირდეს უფსკრული მონაცემთა გამოჩენასა და მათ დაცვას შორის.ამის მიღწევა შესაძლებელია რამდენიმე გზით, კონკრეტული შემთხვევის სპეციფიკიდან და მონაცემთა მნიშვნელოვნების ხარისხიდან გამომდინარე.

მაგალითად, ნაკლებად კრიტიკული სისტემებისთვის, სარეზერვო ასლების დროის ინტერვალი შეიძლება შემცირდეს რამდენიმე საათამდე. ამ შემთხვევაში, ჩვენ ვიყენებთ სნეპშოტებს. ისინი შეიძლება იყოს აღდგენის წერტილი, რომელიც შეიძლება გაკეთდეს საათში ერთხელ. ზოგიერთი თანამედროვე მასივი საკმარისად კარგად უმკლავდება ამ პროცესებს და შეუძლია საკმარისად შენახვა დიდი რიცხვისისტემის კადრები. ეს შესანიშნავი გამოსავალია სიტუაციიდან, როდესაც ცოტა ხნით უკან დაბრუნება გჭირდებათ.

ყველაზე კრიტიკული სისტემებისთვის შეიძლება საერთოდ არ იყოს დროის მონაკვეთი - მონაცემები მუდმივად უნდა იყოს დაცული. ამ კლასის რამდენიმე გამოსავალი არსებობს, მაგალითად, Oracle Standby FlashBack-ით, რომელიც საშუალებას გაძლევთ გარკვეული დროით დააბრუნოთ მონაცემთა ბაზა ყველა ცვლილების ჩაწერით. თქვენ ასევე შეგიძლიათ გამოიყენოთ Oracle ZDLRA PAK, რომელიც თითქმის სინქრონულად იღებს ყველა ცვლილებას მონაცემთა ბაზაში, ან აპარატურულ და პროგრამულ სისტემებში. ძირითადი მიზანიროგორიცაა EMC RecoverPoint, Vision Solutions Double-Take პროგრამული უზრუნველყოფა. ისინი ასევე იწერენ ყველა ცვლილებას და საშუალებას გაძლევთ აღადგინოთ დროის ინტერვალის ნებისმიერ წერტილში.

Oracle Zero Data Loss Recovery Appliance (ZDLRA) უნდა აღინიშნოს, როდესაც საქმე ეხება ინოვაციას სარეზერვო და აღდგენის სისტემებში. Oracle Engineered Systems-ის ეს მოწყობილობა უზრუნველყოფს Oracle-ის მონაცემთა ბაზის სარეზერვო და სწრაფ აღდგენის შესაძლებლობებს ნებისმიერ პლატფორმაზე და ნებისმიერ გამოცემაზე (Enterprise და Standard). ZDLRA ეფუძნება ვირტუალურ სარეზერვო ბაზებს (Virtual Full Backup), მიღებული პირველი სრული სარეზერვო და შემდგომი ცვლილებების ჟურნალის საფუძველზე. ამ ვირტუალური სარეზერვო ასლების გამო, მონაცემთა ბაზის აღდგენა შესაძლებელია დროის ნებისმიერ მომენტში ბევრად უფრო სწრაფად, ვიდრე SRK-ის კლასიკური გამოყენებით სქემის მიხედვით "კვირაში ერთხელ სრული სარეზერვო, დღეში ერთხელ დამატებითი". შეიძლება ითქვას, რომ ZDLRA აგრძელებს Oracle Exadata-ს მიერ დადგენილ მიმართულებას. Exadata იყენებს სპეციალურ პროგრამულ უზრუნველყოფას Oracle Database ამოცანებისთვის ოპტიმიზირებული შენახვის ინოვაციური სისტემის დასანერგად. და ZDLRA-ში არის სპეციალური პროგრამული უზრუნველყოფა, რომელიც ოპტიმიზებს Oracle მონაცემთა ბაზის სარეზერვო ასლს.

ახლა ჩვენ მხოლოდ სწრაფ აღდგენაზე ვსაუბრობთ. დიდი კატასტროფების ან დიდი ხნის წინ აღდგენის აუცილებლობის შემთხვევაში, ჩვეულებრივი სარეზერვო ასლები შეუცვლელ ინსტრუმენტად რჩება. მაგრამ ამჟამინდელ პირობებში ეს არის მხოლოდ სარეზერვო პარაშუტი, რომელიც განლაგებულია ბოლო მომენტში.

მეოთხე არის ფარული შეცდომების შემცირება.არსებობს მხოლოდ ერთი გზა, რათა დარწმუნდეთ, რომ სარეზერვო ასლი მუშაობს სწორად - სცადოთ მისი აღდგენა. ეს არის ყველაზე სწორი და იშვიათად გამოყენებული მეთოდი ჩვენი მომხმარებლების მიერ.

მაგრამ ამ სიტუაციიდან გამოსავალსაც გთავაზობთ. პირველ რიგში, გქონდეთ სისტემების ადვილად აღდგენითი შემთხვევები. ეს კიდევ ერთხელ არის ამბავი სნეპშოტის და ლოდინის სისტემების შესახებ, რომელთა სწრაფად განლაგება და ტესტირება შესაძლებელია. შეუდარებლად ნაკლები დრო და ძალისხმევა დასჭირდება, ვიდრე მთლიანი სარეზერვო ასლის „გაშლას“. რა თქმა უნდა, ეს ყოველთვის არ ეხმარება, მაგრამ ცოტა მეტ იმედს ტოვებს, რომ საგანგებო სიტუაციის შემთხვევაში შესაძლებელი იქნება მონაცემების აღდგენა სულ მცირე ამ საშუალებებით.

მეორეც, ზოგიერთი SRC საშუალებას იძლევა ავტომატური ტესტირება. გრაფიკის გარკვეულ დროს შეგიძლიათ სირბილი ვირტუალური მანქანებიიზოლირებულ გარემოში და წინასწარ განსაზღვრული ალგორითმების გამოყენებით შეამოწმეთ არის თუ არა მონაცემები რეალურად აღდგენილი, არის თუ არა აპლიკაცია ხელმისაწვდომი, არის თუ არა ის თანმიმდევრული და პასუხობს თუ არა საჭირო მოთხოვნებს. ამ გზით ადმინისტრატორებს შეუძლიათ თავი დააღწიონ ხანგრძლივ რუტინულ სამუშაოს.

მეხუთე, სარეზერვო სისტემის გამჭვირვალობა.აღწერილი ინტეგრირებული მიდგომა მოიცავს კომპლექსური სისტემის მშენებლობას სხვადასხვა მწარმოებლის სხვადასხვა ტექნოლოგიების გამოყენებით. ამ სისტემის რეალურად ფუნქციონირების ამოცანა, მასში შემდგომი ცვლილებებისა და მასშტაბების შესაძლებლობა, არატრივიალურია და მისი გადაჭრა შესაძლებელია ორი გზით:

• პირველი გზა არის იმ პირობით, რომ მომხმარებელი თავად არის საკმარისად კომპეტენტური და სურს ამ სისტემის ამოქმედება. აქ, როგორც ინტეგრატორი, ჩვენ ვეხმარებით ყველა საჭირო პროცესის აწყობას, მარეგულირებელი ჩარჩოს შექმნას, ყველა საჭირო ინსტრუქციისა და გეგმის შემუშავებას, რათა მომხმარებელთა IT დეპარტამენტმა დამოუკიდებლად შეძლოს სისტემის განვითარება და ფუნქციონირება. სწორი გზა... შემდეგ კი რეგულაციებისა და ამოცანების მთელი ეს პრაქტიკული ბაზა გადასცეს მომხმარებელს ბიზნეს პროცესების სამუშაო სისტემის სახით.

• მეორე გზა, როდესაც მომხმარებელი არ არის დარწმუნებული, რომ შეძლებს SRK სისტემის მუდმივად შენარჩუნებას საბრძოლო მდგომარეობაში, გამოსავალი იქნება სისტემის ნაწილობრივი ან სრული აუთსორსინგის გადატანა. და ჩვენ გვყავს ასეთი კლიენტები, რომლებიც წარმატებით იყენებენ ამ სერვისს, მუდმივად ზრდიან როგორც SLA მოთხოვნებს, ასევე ჩვენი, როგორც IT აუთსორსერის ჩართულობის მასშტაბებს.

სამწუხაროდ, ჯერ არ არსებობს უნივერსალური რეცეპტი, რომელიც გადაწყვეტს მონაცემთა აღდგენის პრობლემას სისტემების მუდმივი ზრდისა და გართულების ამჟამინდელ პირობებში. მხოლოდ ზემოაღნიშნული გადაწყვეტილებების ერთობლიობა და სისტემატური მიდგომა საშუალებას მისცემს კომპანიებს აღადგინონ მონაცემები ბიზნესისთვის საჭირო დროში.