Bacaps და disaster recovery

Bacaps და Disaster Recovery

1) განსაზღვრა და მიზანი

Bacap არის მონაცემთა/კონფიგურაციების შეთანხმებული ასლი შემდგომი აღდგენისთვის (შემთხვევითი ამოღებიდან, შეცდომებიდან, კრიპტოკერებიდან, კატასტროფებიდან).
DR (Disaster Recovery) - ინფრასტრუქტურა/სერვისების აღდგენის პროცესი SLO მუშაკებისთვის დიდი უბედური შემთხვევის შემდეგ (ხანძარი, რეგიონის დაკარგვა, მასობრივი კომპრომისი).
RPO (Recovery Point Objective) - მაქსიმალური დასაშვები დროის მონაცემების დაკარგვა (მაგალითად, 15 წუთი).
RTO (Recovery Time Objective) - მომსახურების აღდგენის სამიზნე დრო (მაგალითად, 30 წუთი).

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

2) მონაცემთა კლასიფიკაცია და კრიტიკის დონე

• Tier-0 (სასიცოცხლო): გარიგების მონაცემთა ბაზა, გადახდები, ნაშთების აღრიცხვა, საიდუმლოებები/PKI.
• Tier-1 (კრიტიკული): სერვისების კონფიგურაცია, რიგები, CI/CD არტეფაქტები, კონტეინერების რეესტრები.
• Tier-2 (მნიშვნელოვანი): ანალიტიკა, მოხსენებები, მეორადი ინდექსები, ლოგიკური არქივები.
• Tier-3 (დამხმარე): ქეში, დროებითი მონაცემები (შესაძლებელია რეკონსტრუქცია).

თითოეული კლასისთვის განსაზღვრეთ RPO/RTO, შენახვის ვადა, უცვლელი და ადგილმდებარეობის მოთხოვნები.

3) შენახვის სტრატეგიები: წესი 3-2-1-1-0

მონაცემთა 3 ასლი (prod + 2 სარეზერვო).
2 სხვადასხვა ტიპის გადამზიდავი/საცავი.
offsite 1 ასლი (სხვა რეგიონი/ღრუბელი).
1 immutable/air-gap (WORM/Object Lock/Tape).
0 შეცდომა აღდგენის შემოწმებებში (რეგულარული ტესტები).

4) ზურგჩანთა ტიპები

Full არის სრული ასლი. ნელა/ძვირი, მაგრამ ბაზა ყველა სტრატეგიისთვის.
Incremental არის განსხვავება ბოლოში ნებისმიერი ზურგჩანთით. ოპტიმალურად მოცულობით.
Differential არის განსხვავება ამ უკანასკნელის full. სწრაფი აღდგენა, მეტი ადგილი.
Snapshot არის ტომი/დისკის მყისიერი დისკი (EBS/ZFS/LVM). ჩვენ გვჭირდება app-consistent snaphots (quiesce).
PITR (Point-in-Time Recovery) - ძირითადი ზურგჩანთა + ჟურნალები (WAL/binlog) ზუსტი დროისთვის დაბრუნებისთვის/LSN.
ობიექტის/ფაილური/ფორმის - კონკრეტული ტიპის მონაცემებისთვის (VM გამოსახულებები, S3 ობიექტები, BD Damps).

5) Bekap- ის კოორდინაცია

Crash-consistent: როგორც უეცარი გამორთვის შემდეგ - შესაფერისია FS- სთვის/ჟურნალისთვის.
App-consistent: პროგრამა „გაყინავს“ ოპერაციებს (fsfreeze/pre-post scripts) გარანტირებულ მთლიანობას.
BD თანმიმდევრულობა: API bacap ინსტრუმენტი (pgBackRest, XtraBackup), ცხელი ქულების რეჟიმები, საკონტროლო წერტილების გაყინვა.

6) დაშიფვრა, გასაღებები და წვდომა

at-rest და in-transit დაშიფვრა ყველა ასლისთვის.
გასაღებები KMS/HSM- ში, პოლიტიკის როტაცია (90/180 დღე), ცალკეული გასაღებები გარემოში.
პასუხისმგებლობის გამიჯვნა: ვინ ქმნის/აშორებს ზურგჩანთებს, ვის შეუძლია მათი გაშიფვრა/წაკითხვა.
ნუ შეინარჩუნებთ გაშიფვრის გასაღებებს იმავე ნდობის დომენში, როგორც მიზნობრივი ასლები.

7) უცვლელი ასლები და დაცვა ransomware- სგან

Object Lock/WORM (Compliance/Governance) ერთად retence და Legal Hold.
Air-gap: იზოლირებული/ოფლაინ საცავი (ფირზე, ოფლაინ ღრუბელი/ანგარიში).
გადავადებული გააქტიურების მოხსნის პოლიტიკოსები, MFA-Delete, ცალკეული ანგარიში ზურგჩანთებისთვის, საზოგადოებრივი წვდომის აკრძალვა.
გადამოწმება malware/დამონტაჟების წინ კომპრომისული ინდიკატორები.

8) სიხშირე, გრაფიკი და ჭერი

GFS (Grandfather-Father-Son): დღის ჩანართები, ყოველკვირეული სრული/დიფტი, ყოველთვიური ფულადი სახსრები გრძელი შენახვით.
RPO კარნახობს სავარაუდო სიხშირეს და WAL/binlog არქივს (მაგალითად, ყოველ 5-15 წუთში).
შენახვა: კრიტიკული - 35-90 დღე + ყოველთვიური 12-36 თვის განმავლობაში (იურიდიული მოთხოვნები).
სეზონური მწვერვალები - ცალკეული საკონტროლო წერტილები (აქციების წინ/გამოშვებამდე).

9) DR მოდელები და სკრიპტები

აქტიური აქტივობა: ორივე რეგიონი ემსახურება ტრაფიკს. მინიმალური RTO, მონაცემთა დაჭერა მოითხოვს კონფლიქტების მკაცრ პოლიტიკას.
აქტიური (ცხელი/თბილი): ცხელი - განლაგებულია და სინქრონიზებულია (RTO წუთი), თბილი - ნაწილობრივ მზად (RTO საათი).
ცივი: შეინახეთ ასლები და Terraform/Ansible/სურათები, ჩვენ მოთხოვნით ვაყენებთ (RTO დღე +).
DRaaS: სხვა ზონაში VM/ქსელების/მისამართების პროვაიდერის ორკესტრი.

10) ფეილოვერის ორკესტრი და აღდგენის პრიორიტეტები

გაშვების პრიორიტეტი: ქსელი/VPN/DNS - საიდუმლოებები/KMS - ბაზები/მტევანი, რიგის/ქეშის მტევანი, პროგრამები/პერიმეტრი/CDN - ანალიტიკა.
ავტომატიზაცია: სკრიპტები/Runbook მოქმედებები, Terraform/Ansible/Helm/ArgoCD პროფილები DR გარემოსთვის.
მონაცემები: DB PITR - reindex/replica - warm-chash- ის საშუალებით სერვისების გაშვება სქემების თავსებადობის დროშებით.
DNS/GSLB: TTL- ის წინასწარ შემცირება, მოქმედების შეცვლის სცენარები.

11) აღდგენის ტესტები

სარეზერვო ტესტები გრაფიკით: ბეკოპის N% ნიმუში, განლაგება „ქვიშის ყუთში“, სქემების/ინვარიანტების ავტომატური შემოწმება.
სრული DR-drill: რეგიონის გამორთვა/AZ, RTO/RPO გადამოწმება ცოცხალ ტრაფიკზე (ან ტრაფიკი-ჩრდილში).
მთლიანობის ტესტები: მძიმე კატალოგები, საკონტროლო თანხები, ყველა ფენის წაკითხვის მცდელობა (სრული + ჩენი).
დოკის ანგარიში: დრო, ნაბიჯები, ანომალიები, სამიზნეების შესვენების ზომა, კორექტირება.

12) ძირითადი ტექნოლოგიის პრაქტიკა

მონაცემთა ბაზები

PostgreSQL: base backup + WAL არქივი (PITR), pgBackRest/Barman ინსტრუმენტები; რეპლიკაციის სლოტები, კონტროლი 'lsn'.
MySQL/MariaDB: Percona XtraBackup/Enterprise Backup, ბინოგის არქივი.
MongoDB: 'mongodump' ლოგიკური ასლისთვის + snapshot დიდი ნაკრებისთვის; Oplog for PITR.
Redis: RDB/AOF კრიტიკულთათვის (თუ Redis არა მხოლოდ ქეში), არამედ უფრო ხშირად - ლოგიკური რეკონსტრუქცია წყაროსგან + snapshot ავარიებისთვის.
Kafka/Pulsar: მეტამონაცემების ზურგჩანთა (ZK/Kraft/BookKeeper), დისკების სნაიპშოტები, ტოპების/ლოგების მარცვლეული.

Kubernetes

etcd snapshot + Velero რესურსებისთვის/ტომებისთვის (CSI snapshots).
საიდუმლო Bacap/PKI ცალკე (Vault snapshot).
სურათების ცალკეული რეესტრი: არტეფაქტების შენახვის პოლისი (immutable tags).

VM და ფაილური სისტემები

ZFS: 'zfs snapshot' + 'zfs send | zstd | send-recv' ecrements, შემოწმება 'scrub'.
LVM/EBS snapshots ერთად pre/post სკრიპტები (app-consistent).
ობიექტის საცავი: ვერსია + Object Lock.

13) ბეკოპის ვერსიების კატალოგიზაცია და კონტროლი

კატალოგი (მეტამონაცემების კატალოგები): რა, სად, როდის, როდის, რა გაკეთდა, Heshi, KMS გასაღები, მფლობელი, შენახვის ვადა.
Метки/теги: `env=prod|stage`, `system=db|k8s|vm`, `tier=0|1|2`, `retention=35d|1y`.
ოქროს საკონტროლო წერტილები: მიგრაციამდე/DDL/ფართომასშტაბიანი გამოშვებებით.

14) დაკვირვება და მეტრიკა

დავალებების წარმატება:% წარმატებული/შევსებული, მიზეზები.
Becape/research დრო, ფანჯრის სიგანე.
RPO ფაქტობრივი: ჟურნალის არქივების ლაგი (WAL/binlog) p95.
მთლიანობა: დადასტურებული ჯაჭვების წილი, უხეში კრეკერის შეცდომები.
ღირებულება: კლასებში შენახვის მოცულობა, დედუპლიკაციის/შეკუმშვის კოეფიციენტი.
DR მზადყოფნა: ვარჯიშების სიხშირე და შედეგი (pass/fail).

15) წვდომის პოლიტიკა და შესაბამისობა

ცალკეული ანგარიშები/პროექტები საცავის საცავებისთვის; NaC პრინციპით წვდომა (ჩვენ არ ვუშვებთ ამოღებას/დაშიფვრას პროდუქტებიდან).
წვდომის/ცვლილების ლოგოები (audit trail), ალერტები მასობრივი წაშლის/რეტენსიის ცვლილებებისთვის.
შესაბამისობა სტანდარტებთან: GDPR (vs არქივების მოხსნის უფლება), PCI DSS (დაშიფვრა, გასაღებები, სეგმენტი), ადგილობრივი რეგულატორები.

16) ანტი შაბლონები

„არსებობს რეპლიკა - ეს ნიშნავს, რომ არ არის საჭირო ზურგჩანთა“.
არ არსებობს immutable/air-gap: ერთი შეცდომა/მავნე იარაღი წაშლის ყველაფერს.
Bacapes იმავე ანგარიშში/რეგიონში, როგორც პროდ.
არასოდეს შეამოწმოთ აღდგენა (ზურგჩანთა „მკვდარია შემოწმებამდე“).
არ არსებობს უბედური შემთხვევის დროს ქაოსის ვერსიების კატალოგიზაცია და კონტროლი.
დაშიფვრის ზოგადი გასაღებები ყველა გარემოსთვის.
Snaphots გარეშე app-consistent რეჟიმი BD- სთვის.
ზურგჩანთა ფანჯარა კვეთს მწვერვალებს (გავლენას ახდენს p99 და SLO).

17) განხორციელების სიის სია (0-60 დღე)

0-10 დღე

სისტემების/მონაცემების ინვენტარიზაცია, კრიტიკული კლასები.
დააყენეთ RPO/RTO მიზნები კლასებში.
ჩართეთ full + incremental Tier-0/1, WAL/binlog არქივი.
განაწილება bacaps: ცალკეული რეგიონი/ანგარიში + ჩართეთ KMS დაშიფვრა.

11-30 დღე

კრიტიკული ასლებისთვის immutable (Object Lock/WORM) კონფიგურაცია.
შემოიღეთ კატალოგები, ჭდეები, მოხსენებები; ალერტები ჟურნალების წარუმატებლობებსა და კლდეებზე.
პირველი DR-drill: აღადგინეთ ცალკეული მომსახურება bacap- დან იზოლირებულ გარემოში.

31-60 დღე

Runbook: Terraform/Ansible/Helm პროფილების DR ავტომატიზაცია.
რეგულარული restore ტესტები (კვირა/თვე) + კვარტალური სრული DR სცენარი.
ფასის ოპტიმიზაცია: დედუპლიკაცია/შეკუმშვა/შენახვის ციკლები.

18) სიმწიფის მეტრიკა

Restore ტესტები: 1/კვირა Tier-0 (შერჩევითი), 1/თვე - სრული სცენარი.
Immutable coverage для Tier-0/1 = 100%.
RPO ფაქტობრივი p95 სამიზნე (მაგ., 15 წუთი).
RTO ფაქტობრივი სამიზნე DR ვარჯიშებზე (მაგალითად, 30 წუთი).
კომპონენტურობის კატალოგი = 100% (აღწერილია და გადამოწმებულია თითოეული ზურგჩანთა).
Incident to-restore: აღმოჩენის დრო გამოჯანმრთელების დაწყებამდე.

19) მაგალითები (სიპეტები)

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) კომუნიკაციები და ოპერაციული როლები

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.
შეტყობინებების შაბლონები სტეიკჰოლდერების/რეგულატორების/მომხმარებლებისთვის.
Post-mortem მოქმედებებით: სადაც მათ დაკარგეს წუთი, სადაც გააუმჯობესეთ ავტომატიზაცია.

21) დასკვნა

ბეკოპებისა და DR- ების საიმედო წრე არ არის "ასლის გაკეთება", არამედ ციკლი: კლასიფიკაცია - RPO/RTO მიზნები - მულტფილმები და immutable ასლები - ავტომატიზირებული runbook "და რეგულარული აღდგენა და წვრთნები. დაიცავით 3-2-1-1-0, გამოყავით რეპლიკაცია bacaps- სგან, დაშიფვრა და იზოლირება კლავიშები, დოკუმენტირება და შემოწმება. შემდეგ „შავი გედიც“ კი გადაიქცევა კონტროლირებად პროცესად პროგნოზირებადი დროით და მონაცემების მინიმალური დაკარგვით.