როგორ უნდა დაგეგმოთ სარეზერვო ასლისა და კატასტროფის აღდგენის სტრატეგია?

Question

Accepted Answer

სარეზერვო ასლისა და კატასტროფის აღდგენის (DR) სტრატეგია პასუხობს: თუ მივ失ოთ მონაცემები ან მთელი რეგიონი, **რამდენი მონაცემის დაკარგვა შეიძლება, რამდენად სწრაფად შეგვიძლია ქსელში დაბრუნება, და აქვთ თუ არა ნამდვილი აღდგენის შესაძლებლობა?** ეს დაფუძნებულია **3-2-1 წესზე**, სწორ **RPO/RTO** მიზნებზე, და — განსაკუთრებით მნიშვნელოვნად — **რეგულარულად გამოცდილ აღდგენაზე**.

## 3-2-1 წესი

```text
3 copies of the data
2 different media / storage types
1 copy offsite (different region or provider)
→ no single failure (disk, host, datacenter, ransomware) destroys every copy
```

სარეზერვო ასლები უნდა იყოს **ავტომატიზირებული** (ადამიანი არ უნდა მოვიყვანოთ მათ) და **გარეგნული** ისე, რომ რეგიონული კატასტროფა არ დაკარგოს ძირითადი და სარეზერვო ასლი ერთად.

## RPO და RTO

ეს ორი მიზანი მართავს ყველა დიზაინის არჩევანს:

- **RPO (Recovery Point Objective)** — ტოლერანტული მონაცემების დაკარგვა, რომელიც იზომება დროში. RPO 1 საათი ნიშნავს, რომ დაკარგული იქნება ბოლო საათის წერტილი, რაც განსაზღვრავს სარეზერვო ასლის/რეპლიკაციის სიხშირეს.
- **RTO (Recovery Time Objective)** — აღდგენაზე დახარჯული დრო. RTO 30 წუთი ნიშნავს, რომ სისტემა უნდა აღდგეს და იმსახურებს 30 წუთში, რაც განსაზღვრავს DR არქიტექტურას.

```text
frequent backups / replication → smaller RPO (less data lost)
hotter standby infrastructure  → smaller RTO (faster recovery)
both cost money → pick targets per business criticality
```

## DR დონეები (ხარჯი vs RTO)

```text
Backup & restore  → cheapest; restore from backups on demand   (RTO: hours)
Pilot light       → minimal core running, scale up on disaster  (RTO: tens of min)
Warm standby      → scaled-down live copy, scale up to take over (RTO: minutes)
Multi-site active → full live copies serving traffic            (RTO: ~seconds)
```

## გამოცადეთ აღდგენა

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

## რატომ არის მნიშვნელოვანი

მონაცემების დაკარგვა და რეგიონული გაუმართობა არის, როდესაც კომპანიის გამძლეობა ტესტირდება. 3-2-1 უზრუნველყოფს ასლის გადარჩენას ნებისმიერი ერთიანი წარუმატებლობის შემთხვევაში; RPO/RTO აქცევს ბუნდოვან "გვაქვს სარეზერვო ასლი" გაზომვადი ვალდებულებებში; DR დონეები საშუალებას გაძლევთ შეუთავსოთ ხარჯი კრიტიკულობას; და გამოცდილი აღდგენა არის ერთადერთი მტკიცებულება, რომ ყველაფერი რეალურად მუშაობს. ტესტის გამოტოვება არის ის, თუ როგორ აღმოაჩენენ გუნდები, აითვრის შუაში, რომ მათი სარეზერვო ასლი უსარგებელი იყო.