სარეზერვო ასლები, რომლებიც მართლა აღდგება: 3-2-1 წესი და აღდგენის ტესტირება

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

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

სარეზერვო ასლი იმდენად კარგია, რამდენადაც მისი ბოლო შემოწმებული აღდგენა

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

3-2-1 წესი — და რატომ არის ის მინიმუმი

3-2-1 წესი მარტივი და ფართოდ გავრცელებული საბაზისო მიდგომაა:

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

დაიწყეთ RPO-თი და RTO-თი და არა პროგრამით

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

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

რა რჩება ხშირად სარეზერვო ასლის მიღმა

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

როგორ ფუჭდება სარეზერვო ასლები პრაქტიკაში

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

აღდგენის ტესტირება: პრაქტიკული განრიგი

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

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

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

პასუხისმგებლობა ცალსახა უნდა იყოს

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

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