Strategii de backup și replicare

Scurt rezumat

O strategie fiabilă de date se bazează pe trei piloni: backup, replicare, recuperare. Replica reduce RTO (timpul de recuperare), copia de rezervă garantează RPO (pierderea de date) și protejează împotriva erorilor logice/ransomware. Principii de bază: 3-2-1-1-0 (3 copii, 2 tipuri de medii, 1 - offsite, 1 - neschimbabile, 0 erori în verificări), teste DR regulate și imutabilitatea seturilor critice.

Termeni și obiective

RPO - cât de multe date pot fi pierdute (de exemplu, ≤ 5 minute).
RTO - cât timp este permis pentru a restabili (de exemplu, ≤ 15 minute).
PITR (Point-in-Time Recovery) - recuperarea „momentului X” cu reluarea jurnalului.
Data SLO este un contract de nivel de servicii pentru RPO/RTO și succesul sarcinilor de backup.

Exemplu de matrice:

Clasa de date	RPO	RTO	Note
Tranzacții/Portofel	≤ 1-5 min	≤ 5-15 min	Busteni + Replica Core sincron
Raportare/PII	≤ 1 oră	≤ 1 oră	VIERME/imutabilitate, arhive
Jurnale/Evenimente brute	≤ 24 h	≤ 4 ore	Obiect, ciclu de viață

Modele de toleranță la erori și replicare

Opțiuni de topologie

Activ-pasiv (cald/cald/rece): fylovere mai simple, previzibile.
Active-Active: disponibilitate ridicată, dar soluționarea conflictelor și coerența sunt mai dificile.
Multi-Zone/Regiune/Cloud: Echilibrul costurilor de întârziere și ieșire.

Sincron vs asincron

Sincron: RPO≈0, peste latență, limita distanței.
Asincron: aproape de zero RTO la RPO scăzut (minute), rezistă la regiuni/nori.
Hibrid: sincron într-o zonă, asincron la o regiune îndepărtată.

Replica ≠ copie de rezervă

Replica poartă erori/ștergeri după sursă. Copie de rezervă - copie off-path cu versioning, verificări și izolare.

Politica 3-2-1-1-0 și imutabilitatea

3 copii (prod + backup local + offsite).
2 tipuri de suporturi (bloc/NAS/obiect/bandă).
1 offsite (alt site/cloud/bandă).
1 copie imuabilă (WORM: Object Lock, instantanee/bandă imuabilă).
0 Eroare (erori): Verificare regulată a integrității (sumă de verificare/verificare/restaurare).

Practică:

Activați versionarea și Object Lock (Conformitate/Guvernanță) pentru obiectele cu backup-uri critice.
Pentru NAS/blocuri - instantanee imuabile cu retenție și interzicerea ștergerii până la termenul limită.

Tipuri de copii de rezervă și programe

Copie completă.
Incremental - numai modificări față de copia de rezervă anterioară.
Diferențial - modificări de la ultima completă.
Incremental pentru totdeauna cu planul GFS (Bunicul-Tatăl-Fiul): creșteri zilnice, săptămânale și lunare „sintetice complete”.

Recomandare (exemplu):

Prod DB: complet zilnic (sau sintetic complet), incremente/busteni la fiecare 5-15 minute (PITR).
Servere de fișiere: arhive săptămânale complete, zilnice incrementale, lunare.
Obiect: ciclu de viață + versiuni; rece - pentru a arhiva clasa de stocare/bandă.

Aplicații și baze de date: practici PITR

PostgreSQL

Activați arhivarea WAL și backup de bază; PITR prin 'restore _ command'.
Instrumente: 'pgBackRest',' wal-g '(obiect),' pg _ basebackup 'pentru complet.
Volume împărțite: date și WAL; scrie WAL pe NVMe rapid cu PLP.

MySQL/MariaDB

Jurnal binar pentru PITR, complet prin „Percona XtraBackup” (backup la cald).
Replicarea GTID; pentru DR - asincron la regiune/nor.

MongoDB

Oplog pentru PITR; instantanee la nivel de storaj + „mongodump” pentru copii logice.
Testați consistența replica înainte de backup.

Redis/Caches

Nu este considerat o copie de rezervă: păstrați RDB/AOF + offsite; restabili ca cald-cache sau de la o sursă de adevăr.

Kubernete și containere

etcd cluster - un obiectiv critic separat (instantanee frecvente, offsite).
Velero: manifeste de rezervă/resurse + instantanee CSI/PV; depozitarea într-o găleată S3-compatible (cu Object Lock).
Descărcări statutare: instantanee consistente pentru aplicații (cârlige pre/post), în caz contrar - consistente.
Versionarea artefactelor de obiect (modele/medii) - la nivelul găleților.

Virtualizare și servere de fișiere

Instantanee VM: utilizați CBT (Changed Block Tracking), stocați offsite-ul, faceți periodic quiesce (VSS pentru Windows).
Servere de fișiere (NAS): instantanee + replica și teste regulate de restaurare a catalogului (eșantionare de fișiere).

Securitate de backup

Criptare în repaus (LUKS/ZFS/cloud KMS/Vault) și în timpul transmisiei (TLS/mTLS).
Managementul cheilor: roluri individuale, dual-control, rotație, stocare offline a cheilor principale.
Izolare: conturi software de rezervă fără drepturi de ștergere a copiilor imuabile; rețele individuale/VLAN-uri.
Rezistență la ransomware: imuabil, aer-decalaj (benzi/cont izolat/laborator).
Audit: jurnal de operațiuni de sistem de backup, notificări despre ștergerea/reducerea retenției.

Planificarea ferestrelor și a lățimii de bandă

Fereastră de backup vs încărcare: accelerarea rețelelor I/O/, eliminarea duplicatelor, compresie.
Rețea: incrementează fiecare N minute, canale individuale/VPN, replica pe timp de noapte sau permanent cu QoS.
Schimbați Block Tracking/CDC pentru a reduce traficul.
Baze mari: fluxuri paralele/streaming, multipart multicanal la obiect.

Monitorizare, Metrics și SLO

Măsurători tehnice:

Succesul sarcinilor de backup/replicare (%), durata, viteza, log lag (WAL/binlog/oplog).
Spațiu de stocare de rezervă, coeficient de deducere, alte cheltuieli.
Timpul și succesul recuperărilor testelor.

SLO (exemplu):

Succesul backup-urilor ≥ 99. 9 %/30 zile.
RPO a atins ≥ 99% din timp (log lag ≤ target).
RTO (test-restore) ≤ 15 min pentru portofel, ≤ 1 h pentru raportare.
Lunar DR-burghiu: 100% de scenarii de rutină finalizate.

Alerte:

Copie de rezervă ratată/nereușită, PITR> prag de întârziere, cădere de eliminare a duplicatelor, lipsă de spațiu, schimbare a politicii de retenție, lipsă de restaurare a testelor proaspete.

Exerciții DR și verificări de recuperare

Tabelul-top: coordonarea rolului, contacte, comunicații.
Tehnic: recuperare sandbox, măsurare RTO, verificare/comparare date.
Black-start: fier gol complet/recuperare cluster curat.
Cataloage de date: etape de recuperare pre-descrise (runbooks) pentru fiecare clasă de sistem.
Automatizare: restaurarea periodică „canar” și verificarea sumelor de control.

Șabloane practice

1) PostgreSQL (pgBackRest + Arhiva WAL la obiect)

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 (exemplu 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) Velero (K8s - obiect + imutabilitatea găleții)

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) Politica de blocare a obiectului (exemplu „mc”)

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

5) Exemplu de program GFS (concept)

Zilnic: incremente la fiecare 15 min (reviste), zilnic plin sintetic.

Săptămânal: Un „plin” (sintetic), magazin timp de 8 săptămâni

Lunar: complet, magazin 12-24 luni (arhivă/bandă).

Lista de verificare a implementării

Clase de date definite, proprietari, RPO/RTO/SLO.
Modele de replicare (sincronizare/async) și topologie (AZ/regiune/cloud) selectate.
Backup-urile sunt configurate: full/incremental/PITR, programe, directoare.
Include imutabilitate (WORM/Object Lock/instantanee imuabile) și offsite/air-gap.
Criptare și KMS/Vault, roluri separate și rotații de taste.
Monitorizarea: succesul sarcinii, log lag, locul, restaurarea testului; alerte.
Runbooks recuperare și feilover; contacte, escaladări, șabloane de comunicare.
Lunar DR burghiu + raport, ajusta planurile.
Buget și FinOps: cost de stocare/ieșire, arhivare/rupere proiect.

Erori comune

„Există o replică - nu este nevoie de backup”: ștergerile logice și ransomware vor pleca pentru replica.
Nu există teste de recuperare - de rezervă există „teoretic”.
Lipsa de imutabilitate și offsite este un singur punct de risc.
Același cont/chei pentru vânzări și backup-uri - compromis = pierderea a tot.
Ferestre de rezervă prea lungi → conflict cu vârfurile; fără accelerare și QoS.
PITR fără log lag control.
Ignorați instantaneele consistente ale aplicațiilor - volume murdare recuperabile.

iGaming/fintech specific

Portofel/bază de plată: RPO ≤ 1-5 min, RTO ≤ 15 min; jurnalele (WAL/binlog) unui obiect cu WORM; sincron în zona + regiunea asincronă.
Raportare/reglementare: depozite neschimbabile, păstrare îndelungată (ani), integritate verificabilă, proceduri clare pentru emiterea datelor către autoritățile de reglementare.
Jurnale/evenimente brute/anti-fraudă: stocare ieftină cu durată lungă de viață (obiect) + ciclu de viață; indici și vitrine - separat.
Vârfuri (meciuri/turnee): ferestre de rezervă în afara vârfurilor, accelerări; Planuri DR pentru perioada evenimentului; canar restabilește înainte de stocuri.

Total

Protecția datelor este o disciplină arhitecturală: 3-2-1-1-0, versioning și imutabilitate, RPO/RTO ca SLO, exerciții DR regulate și testare de recuperare „la fața locului”. Combinați replicarea pentru uptime și eșecuri rapide cu backup-uri pentru erori logice și compromisuri. Automatizați, măsurați, documentați - și veți avea întotdeauna o cale de lucru înapoi, chiar și în cea mai proastă zi.