Strategie tworzenia kopii zapasowych i replikacji

Krótkie podsumowanie

Wiarygodna strategia danych opiera się na trzech filarach: kopii zapasowej, replikacji, odzysku. Replika skraca RTO (czas odzyskiwania), kopia zapasowa gwarantuje RPO (utrata danych) i chroni przed błędami logicznymi/ransomware. Podstawowe zasady: 3-2-1-1-0 (3 egzemplarze, 2 rodzaje mediów, 1 - offsite, 1 - niezmienne, 0 błędów w kontrolach), regularne badania DR i niezmienność zestawów krytycznych.

Warunki i cele

RPO - ile danych można stracić (na przykład ≤ 5 minut).
RTO - ile czasu można przywrócić (na przykład ≤ 15 minut).
PITR (Point-in-Time Recovery) - odzyskiwanie „moment X” z powtórzeniem dziennika.
Data SLO to umowa na poziomie usług dla RPO/RTO i sukces zadań kopii zapasowych.

Przykład macierzy:

Klasa danych	RPO	RTO	Uwagi
Transakcje/Portfel	≤ 1-5 min	≤ 5-15 min	Dzienniki + synchroniczna replika rdzenia
Sprawozdawczość/PII	≤ 1 godzina	≤ 1 godzina	WORM/immutability, archiwum
Dzienniki/zdarzenia surowe	≤ 24 h	≤ 4 h	Obiekt, cykl życia

Modele tolerancji błędów i replikacji

Opcje topologii

Aktywny-pasywny (gorący/ciepły/zimny): prostsze, przewidywalne fylovery.
Active-Active: wysoka dostępność, ale rozwiązywanie konfliktów i spójność są trudniejsze.
Multi-Zone/Region/Cloud: Saldo opóźnienia i koszty wyjścia.

Synchroniczny vs asynchroniczny

Synchroniczny: RPO ≤ 0, powyżej opóźnienia, granica odległości.
Asynchron: blisko zera RTO przy niskim RPO (minuty), wytrzymuje regiony/chmury.
Hybryda: synchroniczna w strefie, asynchroniczna do odległego regionu.

Kopia zapasowa

Replika zawiera błędy/usunięcia po źródle. Kopia zapasowa - kopia poza ścieżką z wersją, czekami i izolacją.

Polityka 3-2-1-1-0 i immutability

3 kopie (prod + lokalna kopia zapasowa + offsite).
2 rodzaje nośników (blok/NAS/obiekt/taśma).
1 offsite (inne miejsce/chmura/taśma).
1 kopia niezmienna (WORM: blokada obiektu, migawki/taśma).
0 Błędy: Regularne sprawdzanie integralności (checksum/verify/restore tests).

Praktyka:

Włącz wersję i blokadę obiektów (Zgodność/Zarządzanie) dla obiektów z krytycznymi kopiami zapasowymi.
Dla NAS/bloków - niezmienne migawki z zachowaniem i zakazem usuwania do terminu.

Rodzaje kopii zapasowych i harmonogramów

Pełna kopia.
Przyrostowe - tylko zmiany z poprzedniej kopii zapasowej.
Różnica - zmiany od ostatniego kompletu.
Forever-incremental with GFS-plan (dziadek-ojciec-syn): dzienne przyrosty, tygodniowe i miesięczne „syntetyczne pełne”.

Zalecenie (przykład):

Prod DB: dziennie pełne (lub syntetyczne pełne), przyrosty/dzienniki co 5-15 minut (PITR).
Serwery plików: tygodniowo pełne, dziennie przyrostowe, miesięczne archiwa.
Obiekt: cykl życia + wersje; zimno - do archiwizowania klasy pamięci masowej/taśmy.

Aplikacje i bazy danych: Praktyki PITR

PostgreSQL

Włącz archiwizację WAL i kopię zapasową bazy; PITR poprzez 'restore _ command'.
Narzędzia: 'pgBackRest', 'wal-g' (obiekt), 'pg _ basebackup' dla kompletnych.
Podzielone wolumeny: dane i WAL; napisz WAL na szybki NVMe z PLP.

MySQL/MariaDB

Dziennik binarny dla PITR, zakończony za pomocą 'Percona XtraBackup' (kopia zapasowa na gorąco).
replikacja GTID; DR - asynchroniczny do regionu/chmury.

MongoDB

Oplog dla PITR; migawki na poziomie storaj + 'mongodump' dla kopii logicznych.
Sprawdź konsystencję repliki przed kopią zapasową.

Redis/Caches

Nieuwzględnione kopie zapasowe: przechowywać RDB/AOF + offsite; przywrócić jako ciepłą pamięć lub ze źródła prawdy.

Kubernety i kontenery

itcd cluster - osobny krytyczny cel (częste migawki, offsite).
Velero: manifesty kopii zapasowych/zasoby + migawki CSI/PV; przechowywanie w wiadrze S3-compatible (z blokadą obiektu).
Pliki do pobrania: aplikacja spójne migawki (pre/post haki), w przeciwnym razie - crash-consistent.
Wersioning artefaktów obiektowych (modele/media) - na poziomie wiader.

Wirtualizacja i serwery plików

Migawki VM: używać CBT (Changed Block Tracking), przechowywać offsite, okresowo zrobić gościa świadomy ciszy (VSS dla systemu Windows).
Serwery plików (NAS): migawki + repliki i regularne testy przywracania katalogu (próbkowanie plików).

Zabezpieczenie kopii zapasowych

Szyfrowanie w stanie spoczynku (LUKS/ZFS/cloud KMS/Vault) i podczas transmisji (TLS/mTLS).
Zarządzanie kluczami: indywidualne role, podwójna kontrola, rotacja, przechowywanie w trybie offline kluczy głównych.
Izolacja: rezerwowe konta oprogramowania bez praw do usunięcia niezmiennych kopii; poszczególne sieci/sieci VLAN.
Odporność na oprogramowanie ransomware: niezmienna, szczelina powietrza (taśmy/izolowane konto/laboratorium).
Audyt: dziennik operacji systemu kopii zapasowych, powiadomienia o usunięciu/zmniejszeniu zatrzymania.

Planowanie okien i przepustowości

Backup window vs load: throttling I/O/networks, deduplication, compression.
Sieć: przyrosty co N minut, poszczególne kanały/VPN, replika w nocy lub na stałe z QoS.
Zmień blok śledzenia/CDC, aby zmniejszyć ruch.
Duże podstawy: równoległe strumienie/strumień, wielokanałowy multipart do obiektu.

Monitoring, mierniki i SLO

Metryki techniczne:

Sukces zadań kopii zapasowej/replikacji (%), czas trwania, prędkość, opóźnienie dziennika (WAL/binlog/oplog).
Zapasowa przestrzeń magazynowa, współczynnik odpływu, inne wydatki.
Czas i sukces odzyskiwania testów.

SLO (przykład):

Sukces kopii zapasowych ≥ 99. 9 %/30 dni.
RPO osiągnęła ≥ 99% czasu (log lag ≤ cel).
RTO (test-restore) ≤ 15 min dla portfela, ≤ 1 h dla raportowania.
Miesięczne DR-wiertło: 100% rutynowych scenariuszy zakończonych.

Wpisy:

Brak/nieudana kopia zapasowa, PITR> opóźnienie progowe, spadek deduplicacji, brak miejsca, zmiana polityki zatrzymywania, brak przywrócenia nowych testów.

Ćwiczenia DR i kontrole odzysku

Tabela-top: koordynacja ról, kontakty, komunikacja.
Techniczne: sandbox recovery, RTO measurement, checksum/data comparison.
Czarny start: pełne żelazo/czyste odzyskiwanie klastra.
Katalogi danych: wstępnie opisane kroki odzyskiwania (zakładki) dla każdej klasy systemu.
Automatyzacja: okresowe „kanarkowe” przywracanie i weryfikacja checksums.

Szablony praktyczne

1) PostgreSQL (pgBackRest + archiwum WAL do sprzeciwu)

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 (Przykład wal-g)

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 - obiekt + niezmienność wiadra)

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) Polityka blokady obiektu (przykład 'mc')

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

5) Przykład harmonogramu GFS (koncepcja)

Dziennie: przyrosty co 15 min (czasopisma), dziennie syntetyczne pełne.

Tygodnik: Jeden „pełny” (syntetyczny), przechowywać przez 8 tygodni

Co miesiąc: pełny, przechowywać 12-24 miesiące (archiwum/taśma).

Lista kontrolna implementacji

Zdefiniowane klasy danych, właściciele, RPO/RTO/SLO.
Wybrane modele replikacji (synchronizacja/async) i topologii (AZ/Region/chmura).
Kopie zapasowe są skonfigurowane: pełny/przyrostowy/PITR, harmonogramy, katalogi.
Obejmuje immutability (WORM/Object Lock/immutable snapshots) oraz offsite/air-gap.
Szyfrowanie i KMS/Skarbiec, oddzielne role i rotacje kluczy.
Monitorowanie: sukces zadania, opóźnienie w log, miejsce, przywrócenie testu; wpisy.
Odzyskiwanie i feilover książek startowych; kontakty, eskalacje, szablony komunikacyjne.
Miesięczne ćwiczenia DR + raport, dostosować plany.
Budżet i FinOps: koszt magazynowania/zużycie, archiwizacja/łzawienie projektu.

Częste błędy

„Jest replika - nie jest potrzebna kopia zapasowa”: logiczne usunięcia i ransomware pozostawi do repliki.
Brak testów odzyskiwania - kopia zapasowa istnieje „teoretycznie”.
Brak immutability i offsite jest jednym punktem ryzyka.
To samo konto/klucze do sprzedaży i kopii zapasowych - kompromis = utrata wszystkiego.
Zbyt długie okna zapasowe → konflikt ze szczytami; bez rozdrabniania i QoS.
PITR bez kontroli opóźnienia dziennika.
Ignoruj migawki spójne aplikacji - brudne woluminy odzyskiwalne.

iGaming/specyficzne dla fintechu

Portfel/rdzeń płatniczy: RPO ≤ 1-5 min, RTO ≤ 15 min; kłody (WAL/binlog) do obiektu z WORM; synchroniczny w strefie + regionie asynchronicznym.
Sprawozdawczość/regulacja: niezmienne repozytoria, długie przechowywanie (lata), możliwa do zweryfikowania integralność, jasne procedury wydawania danych organom regulacyjnym.
Kłody/zdarzenia surowe/przeciwdziałanie oszustwom: tanie przechowywanie długotrwałe (obiekt) + cykl życia; indeksy i sklepy - oddzielnie.
Szczyty (mecze/turnieje): kopie zapasowe okien na zewnątrz szczytów, dławienie; Plany DR na okres imprezy; restauracje kanaryjskie przed zapasami.

Razem

Ochrona danych to dyscyplina architektoniczna: 3-2-1-1-0, wersioning i niezmienność, RPO/RTO jako SLO, regularne ćwiczenia DR oraz testy odzysku na miejscu. Połączyć replikację dla uptime i szybkich awarii z kopiami zapasowymi dla błędów logicznych i kompromisów. Automatyzuj, mierz, dokumentuj - i zawsze będziesz miał ścieżkę roboczą do tyłu, nawet w najgorszy dzień.