სარეზერვო ასლები და აღდგენა, რომელსაც ნამდვილად დაეყრდნობით

ხშირად დასმული კითხვები

რა განსხვავებაა RTO-სა და RPO-ს შორის?

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

როგორ იცავთ სარეზერვო ასლებს გამოსასყიდი პროგრამისგან?

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

რამდენად ხშირად ტესტავთ აღდგენას?

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

იცავთ თუ არა ღრუბლისა და SaaS მონაცემებსაც?

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

რამდენად სწრაფად შეგვიძლია აღდგენა კატასტროფის შემდეგ?

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

რა არის 3-2-1 სარეზერვო წესი და მიჰყვებით თუ არა მას?

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

გვაწვდით თუ არა დოკუმენტირებულ აღდგენის პროცედურებს?

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

რა ხდება, თუ სარეზერვო პროცესი ჩავარდება?

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

შეგიძლიათ ჩვენს არსებულ სარეზერვო მოწყობასთან მუშაობა?

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