ბეკოპისა და რეპლიკაციის სტრატეგიები

მოკლე რეზიუმე

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

ტერმინები და მიზნები

RPO - რამდენი მონაცემების დაკარგვა დასაშვებია (მაგალითად, 5 წუთი).
RTO - რამდენი დრო დასჭირდება აღდგენას (მაგალითად, 15 წუთი).
PITR (Point-in-Time Recovery) - აღდგენა „X დროს“ ჟურნალის წარწერით.
SLO მონაცემები - RPO/RTO სერვისის დონის ხელშეკრულება და Becap დავალებების წარმატება.

მატრიცის მაგალითი:

მონაცემთა კლასი	RPO	RTO	შენიშვნები
გარიგებები/საფულე	1-5 წუთი	5-15 წუთი	ჟურნალები + სინქრონული ბირთვის რეპლიკა
ანგარიში/PII	• 1 საათი	• 1 საათი	WORM/immutability, არქივები
ლოგიკური/ნედლეული მოვლენები	ევრო 24 საათი	4 საათი	ობიექტი, ცხოვრება

უკმარისობის და რეპლიკაციის მოდელები

ტოპოლოგიის ვარიანტები

აქტიური (ცხელი/თბილი/ცივი): უფრო მარტივი, პროგნოზირებადი ფეილოვერები.
აქტიური აქტივობა: მაღალი წვდომა, მაგრამ უფრო რთული კონფლიქტი და თანმიმდევრულობა.
Multi-Zone/Region/Cloud: შეფერხებების ბალანსი და egress ღირებულება.

სინქრონი ასინქრონი

სინქრონი: RPO-0, ლატვიის ზემოთ, მანძილის შეზღუდვა.
ასინქრონი: ნულოვანი RTO- სთან ახლოს მცირე RPO (წუთი), გაუძლებს რეგიონებს/ღრუბლებს.
ჰიბრიდი: სინქრონი ზონაში, ასინქრონი - შორეულ რეგიონში.

რეპლიკა

რეპლიკა იღებს შეცდომებს/ამოღებას წყაროს შემდეგ. Bacap არის off-path ასლი ვერსიფიკაციით, შემოწმებებით და იზოლაციით.

პოლიტიკა 3-2-1-1-0 და იმუნიტეტი

3 ეგზემპლარი (prod + ადგილობრივი სარეზერვო + ოფსეტური).
2 ტიპის გადამზიდავი (ბლოკი/NAS/ობიექტი/ფირზე).
1 ოფსიტი (კიდევ ერთი პლატფორმა/ღრუბელი/ლენტი).
1 უცვლელი ასლი (WORM: Object Lock, immutable snapshots/ფირზე).
0 შეცდომა: ინტეგრაციის რეგულარული შემოწმება (checksum/verify/restore ტესტები).

პრაქტიკა:

ჩართეთ ვერსია და Obpliance Lock (Compliance/Governance) კრიტიკული ზურგჩანთა ობიექტისთვის.
NAS/ბლოკისთვის - immutable snapshots ერთად retenshots და ვადაზე ამოღების აკრძალვა.

ტიპები და გრაფიკები

Full არის სრული ასლი.
Incremental - მხოლოდ ცვლილებები წარსული ზურგჩანთიდან.
Inferential - ცვლილებები ამ უკანასკნელის შემდეგ.
Forever-incremental GFS გეგმით (Grandfather-Father-Son): დღის ამინდი, ყოველკვირეული და ყოველთვიური „სინთეზური სრული“.

რეკომენდაცია (მაგალითი):

Scream BD: ყოველდღიური სრული (ან სინთეზური სრული), სავარაუდო/ჟურნალები ყოველ 5-15 წუთში (PITR).
ფაილური სერვერები: ყოველკვირეული სრული, ყოველდღიური incremental, ყოველთვიური არქივები.
ობიექტი: lifecycle + ვერსია; სიცივე - შენახვის/ფირის საარქივო კლასში.

პროგრამები და მონაცემთა ბაზა: PITR პრაქტიკა

PostgreSQL

ჩართეთ WAL საარქივო და ბაზის პაკეტი; PITR 'restore _ command- ით'.
ინსტრუმენტები: 'pgBackRest', 'wal-g' (ობიექტი), 'pg _ basebackup' სრული.
გააზიარეთ ტომი: მონაცემები და WAL; WAL დაწერეთ სწრაფი NVMe PLP- ით.

MySQL/MariaDB

PITR- ის ბინარული ჟურნალი სავსეა 'Percona XtraBackup- ით' (ცხელი ქილა).
GTID- ის რეპლიკაცია; DR- სთვის - ასინქრონი რეგიონში/ღრუბელში.

MongoDB

Oplog for PITR; სნაიპერები storaja + 'mongodump- ის დონეზე ლოგიკური ასლებისთვის.
შეამოწმეთ რეპლიკის თანმიმდევრულობა bacp- ის წინ.

Redis/Kashi

არ ჩაითვალოს ზურგჩანთა: შეინახეთ RDB/AOF + offsite; აღადგინეთ როგორც warm-cache ან ჭეშმარიტების წყაროდან.

Kubernetes და კონტეინერები

etcd მტევანი - ცალკეული კრიტიკული მიზანი (ხშირი snapshots, ოფსეტური).
ველერო: მანიფესტების/რესურსების ზურგჩანთა + CSI Snaphots/PV; შენახვა S3- თავსებადი ბანკეტში (Obect Lock- ით).
Stateful Awards: app-consistent snapshots (pre/post hooks), წინააღმდეგ შემთხვევაში - crash-consistent.
ობიექტის არტეფაქტების (მოდელის/მედიის) ვერსია - საბაკალავრო დონეზე.

ვირტუალიზაცია და ფაილური სერვერები

VM Snaphots: გამოიყენეთ CBT (Changed Block Tracking), შეინახეთ offsite, პერიოდულად გააკეთეთ საუკეთესო aware quiesce (VSS Windows- ისთვის).
ფაილური სერვერები (NAS): snapshots + რეპლიკა და რეგულარული კატალონიური ტესტები (ფაილების ნიმუში).

ზურგჩანთების უსაფრთხოება

დასვენების დაშიფვრა (LUKS/ZFS/ღრუბლოვანი KMS/Vault) და გადაცემის დროს (TLS/mTLS).
კლავიშების მართვა: ინდივიდუალური როლები, ორმაგი კონტროლი, როტაცია, მასტერკლასების ოფლაინ შენახვა.
იზოლაცია: მონაცემთა ბაზის ანგარიშები იმუნური ასლების ამოღების უფლების გარეშე; ინდივიდუალური ქსელები/VLAN.
Ransomware სტაბილურობა: immutable, air-gap (ფირები/იზოლირებული ანგარიში/ლაბი).
აუდიტი: სარეზერვო ოპერაციების ჟურნალი, შეტყობინებები ჭრილობის მოცილების/შემცირების შესახებ.

ფანჯრისა და გამტარუნარიანობის დაგეგმვა

Backup windows დატვირთვა: trottling I/O/ქსელები, დედუპლიკაცია, კომპრესია.
ქსელი: ყოველ N წუთში, ცალკეული არხები/VPN, რეპლიკა ღამით ან მუდმივად QoS- ით.
Change Block Tracking/CDC ტრაფიკის შესამცირებლად.
დიდი ბაზები: პარალელური ნაკადები/ნაკადი, მრავალარხიანი მულტიპარტი ობიექტში.

მონიტორინგი, მეტრიკა და SLO

მეტრიკა:

Becap/რეპლიკაციის ამოცანების წარმატება (%), ხანგრძლივობა, სიჩქარე, ჟურნალების lage (WAL/binlog/oplog).
ბეკოპის საცავის სივრცე, დედაპლატის კოეფიციენტი, სხვა ხარჯები.
ტესტის აღდგენის დრო და წარმატება.

SLO (მაგალითი):

ზურგჩანთების წარმატება - 99. 9 %/30 დღე.
RPO დაცულია დროის 99% -ზე (სამიზნე ჟურნალების ლაგი).
RTO (ტესტის აღდგენა) - 15 წუთი საფულისთვის, 1 საათი ანგარიშგებისთვის.
ყოველთვიური DR-drill: მარეგულირებელი სცენარების 100% დასრულებულია.

ალერტა:

გამოტოვებული/წარუმატებელი ზურგჩანთა, lag PITR> ბარიერი, დედაპლაციის ხარისხის ვარდნა, ადგილის ნაკლებობა, ჭრილობის პოლიტიკის ცვლილება, ახალი ტესტის ნაკადის არარსებობა.

DR სავარჯიშოები და აღდგენის შემოწმება

ტაბლეტები: როლების, კონტაქტების, კომუნიკაციების კოორდინაცია.
ტექნიკური: აღდგენა „ქვიშის ყუთში“, RTO გაზომვა, ტესტის თანხების/მონაცემების შედარება.
Black start: სრული აღდგენა „შიშველი რკინა/სუფთა მტევანი“.
მონაცემთა კატალოგები: სისტემის თითოეული კლასის წინასწარ აღწერილი აღდგენის ნაბიჯები.
ავტომატიზაცია: პერიოდული „კანარის“ აღდგენა და საკონტროლო თანხების გადამოწმება.

პრაქტიკული შაბლონები

1) PostgreSQL (pgBackRest + WAL არქივი ობიექტში)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (მაგალითი ENV)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) ველერო (K8s - ობიექტი + ბუკეტის იმუნიტეტი)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) Obect Lock პოლიტიკა (მაგალითი 'mc')

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) GFS გრაფიკის მაგალითი (კონცეფცია)

Daily: ინციდენტები ყოველ 15 წუთში (ჟურნალები), დღის სინთეზური სრული.
შაბათ: ერთი „სრული“ (სინთეზური), შენახვა 8 კვირის განმავლობაში.
Monthly: სრული, შენახვა 12-24 თვის განმავლობაში (არქივი/ფირზე).

ჩეკის განხორციელების სია

განისაზღვრა მონაცემთა კლასები, მფლობელები, RPO/RTO/SLO.
შეირჩა რეპლიკაციის მოდელები (sync/async) და ტოპოლოგია (AZ/Region/Cloud).
განლაგებულია bacaps: full/incremental/PITR, გრაფიკები, კატალოგები.
ჩართულია იმუნიტეტი (WORM/Object Lock/immutable snapshots) და offsite/air-gap.
დაშიფვრა და KMS/Vault, ცალკეული როლები და გასაღებების როტაცია.
მონიტორინგი: დავალებების წარმატება, ჟურნალების ყუთები, ადგილი, ტესტის აღდგენა; ალერტა.
Runbooks აღდგენა და ფეილოვერი; კონტაქტები, ესკალაცია, კომუნიკაციის შაბლონები.
ყოველთვიური DR სავარჯიშოები + ანგარიში, გეგმის კორექტირება.
ბიუჯეტი და FinOps: შენახვის ღირებულება/egress, არქივის პროექტი/ტირინგი.

ტიპიური შეცდომები

„არსებობს რეპლიკა - თქვენ არ გჭირდებათ ზურგჩანთა“: ლოგიკური წაშლა და დაშიფვრა რეპლიკზე წავა.
აღდგენის ტესტები არ არსებობს - ზურგჩანთა არსებობს „თეორიულად“.
იმუნიტეტისა და ოფსეტური არარსებობა ერთი რისკის წერტილია.
იგივე ანგარიში/საწყობის გასაღებები და ხელფასი - კომპრომისი = ყველაფრის დაკარგვა.
ძალიან გრძელი bacap ფანჯრები - კონფლიქტი მწვერვალებთან; არ არის trotling და QoS.
PITR ჟურნალების ბლოკის კონტროლის გარეშე.
App-consistent snapshots- ის უგულებელყოფა არის „ბინძური“ აღდგენილი ტომი.

სპეციფიკა iGaming/fintech

საფულე/გადახდის ბირთვი: RPO - 1-5 წთ, RTO - 15 წთ; ჟურნალები (WAL/binlog) ობიექტში WORM- ით; სინქრონი ზონაში + ასინქრონის რეგიონში.
მოხსენებები/მარეგულირებელი: უცვლელი საცავი, გრძელვადიანი გადაკეთება (წლები), დადასტურებული მთლიანობა, რეგულატორებისთვის მონაცემების გაცემის მკაფიო პროცედურები.
ლოგიკური/ნედლეული მოვლენები/ანტიფროდი: იაფი გრძელი სიცოცხლის შენახვა (ობიექტი) + lifecycle; ინდექსები და ფანჯრები - ცალკე.
Piki (მატჩები/ტურნირები): bacap ფანჯრები მწვერვალების მიღმა, throttling; DR გეგმები მოვლენების პერიოდისთვის; კანარის restore აქციების წინ.

შედეგი

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