კლიენტთან backup-ზე საუბრისას ყველაზე ცუდი პასუხი არის: „კი, მგონი კეთდება“. მონაცემის დაკარგვის შემდეგ „მგონი“ უკვე არაფერს შველის. Managed VPS-ის ყიდვისას management და backup ცალ-ცალკე გადაამოწმეთ - ერთი მეორეს ავტომატურად არ ნიშნავს.
SERVER1-ის Managed VPS გვერდზე backup და გარე storage ვარიანტები მომსახურების ნაწილად არის აღწერილი, თუმცა კონკრეტული პაკეტის retention და restore პირობები შეკვეთამდე მაინც ცალკე გადაამოწმეთ.
რვა კითხვა, რომელსაც შეკვეთამდე დავსვამდი
- ზუსტად რა შედის backup-ში? მთელი VPS, მხოლოდ ფაილები, database-ები თუ კონკრეტული directories?
- რა სიხშირით იქმნება ასლი? დღეში ერთხელ, საათობრივად თუ სხვა გრაფიკით?
- რამდენ ხანს ინახება? ერთი ბოლო restore point და ხანგრძლივი ისტორია სრულიად განსხვავებული დაცვაა.
- სად ინახება ასლი? იგივე storage failure-ის შემთხვევაში backup გადარჩება?
- არის თუ არა database consistency გათვალისწინებული? უბრალოდ disk snapshot ყოველთვის არ ნიშნავს application-consistent მონაცემს.
- ვინ იწყებს restore-ს და როგორ? self-service, ticket თუ managed recovery?
- შეიძლება ერთი ფაილის აღდგენა? სრული server restore ყოველთვის საჭირო არ არის.
- ბოლოს როდის გამოიცადა აღდგენა? backup job-ის „success“ სტატუსი restore-ის წარმატების გარანტია არ არის.
RPO და RTO - ორი აბრევიატურა, რომელიც ბიზნესის ენაზე უნდა გადაითარგმნოს
| ტერმინი | მარტივი კითხვა | მაგალითი |
|---|---|---|
| RPO | რამდენი ბოლო მონაცემის დაკარგვა შემიძლია? | თუ შეკვეთები მუდმივად შემოდის, დიდი ინტერვალი შეიძლება მიუღებელი იყოს |
| RTO | რამდენ ხანს შემიძლია სერვისის გარეშე ყოფნა? | ბლოგი და ონლაინ გადახდის სისტემა ერთნაირ აღდგენის პრიორიტეტს არ მოითხოვს |
Backup გრაფიკი სწორედ ამ ორი ბიზნეს მოთხოვნიდან უნდა გამოვიდეს და არა ფრაზიდან „ყველას დღიური backup აქვს“.
თუ Unmanaged VPS-ს იყენებთ, backup პოლიტიკის მფლობელი თქვენ ხართ და დამატებითი backup/storage ვარიანტიც თქვენი recovery მოთხოვნებიდან უნდა შეარჩიოთ.
Snapshot-ს თავისი ადგილი აქვს - მაგრამ მას ყველაფერს ნუ დააკისრებთ
Snapshot ძალიან კარგია სწრაფ rollback-ზე, მაგალითად დიდი განახლების წინ. მაგრამ თუ snapshot იგივე infrastructure/storage failure domain-ზეა დამოკიდებული, დამოუკიდებელი backup-ის სრულ ჩანაცვლებად არ უნდა ჩათვალოთ. სხვადასხვა failure სცენარს სხვადასხვა დაცვის ფენა სჭირდება.
Backup-ს მნიშვნელობა განსაკუთრებით კარგად ჩანს downtime-ის დროს; ვებ გვერდის downtime-ის სტატიაში განხილული რისკები კარგი შეხსენებაა, რატომ უნდა იცოდეთ recovery დრო წინასწარ.
15-წუთიანი restore drill უფრო ღირებულია, ვიდრე კიდევ ერთი checkbox
პერიოდულად აიღეთ შემთხვევითი ფაილი ან სატესტო database და აღადგინეთ ცალკე გარემოში. შეამოწმეთ permissions, encoding, application login და ის, რეალურად იცის თუ არა გუნდმა პროცედურა. Disaster recovery-ის დროს პირველად ინსტრუქციის კითხვა ცუდი დროა.
თუ მართვის პროცესიც თქვენთვის მნიშვნელოვანია, სერვერ მენეჯმენტისა და დროის ეკონომიის თემაც დაგეხმარებათ infrastructure პასუხისმგებლობების სწორად შეფასებაში. სარეზერვო ასლების თემაზე დამატებითი კონტექსტისთვის შეგიძლიათ ნახოთ SERVER1-ის ძველი backup სტატია.
ჩემი საზომი მარტივია: backup არსებობს მხოლოდ მაშინ, როცა ვიცით რას ვინახავთ, სად ვინახავთ და როგორ ვაბრუნებთ.
