0Pricing
SQL Academy · Lekcja

Planowanie odtwarzania po awarii

RPO, RTO i runbooki

Planowanie odtwarzania po awarii to bezpłatna lekcja SQL Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej SQL Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs SQL Academy zawiera 4 lekcji w sumie.

Czym jest odzyskiwanie po awarii

Odzyskiwanie po awarii (Disaster Recovery, DR) to zbiór zasad, narzędzi i procedur mających umożliwić odzyskanie kluczowej infrastruktury technologicznej i systemów po klęsce żywiołowej lub katastrofie spowodowanej przez człowieka.

W kontekście baz danych planowanie DR zapewnia bezpieczeństwo danych i możliwość przywrócenia systemów online w akceptowalnym czasie po zdarzeniach takich jak awaria sprzętu, przypadkowe usunięcie danych, ataki ransomware lub przestoje centrum danych.

Cel punktu odzyskiwania (RPO)

RPO określa maksymalną akceptowalną ilość danych, którą można utracić, wyrażoną w czasie. Jeśli RPO wynosi 1 godzinę, należy móc odzyskać dane co najmniej do momentu przypadającego 1 godzinę przed wystąpieniem awarii.

Krótszy RPO wymaga częstszych kopii zapasowych lub ciągłej replikacji. Historię kopii zapasowych można odpytać, aby zweryfikować spełnianie docelowej wartości RPO.

-- Check the last backup time and calculate data loss window
SELECT
  backup_id,
  backup_type,
  started_at,
  finished_at,
  EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;

Docelowy czas odzyskiwania (RTO)

RTO określa maksymalny akceptowalny czas, przez który system może pozostawać niedostępny po awarii. Jeśli RTO wynosi 4 godziny, baza danych musi być w pełni sprawna w ciągu 4 godzin od wystąpienia awarii.

RTO wpływa na decyzje dotyczące serwerów zapasowych, automatyzacji przełączania awaryjnego i procedur odtwarzania. Śledzenie czasu odtwarzania w kolejnych testach pomaga prognozować, czy można spełnić wymagania RTO.

-- Track restore durations to validate RTO compliance
SELECT
  restore_id,
  triggered_at,
  completed_at,
  EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
  CASE
    WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
    THEN 'WITHIN RTO'
    ELSE 'RTO BREACHED'
  END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;

RPO a RTO — kluczowa różnica

Te dwa wskaźniki są często mylone. Oto najprostszy sposób, aby je zapamiętać:

  • RPO = Jaką ilość danych można utracić? (patrzy wstecz, mierzony czasem przed awarią)
  • RTO = Jak długo system może pozostawać niedostępny? (patrzy w przyszłość, mierzony czasem po awarii)

Razem wyznaczają okno odzyskiwania i bezpośrednio wpływają na częstotliwość tworzenia kopii zapasowych, strategię replikacji oraz budżet infrastruktury.

-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
  db_name       VARCHAR(100) PRIMARY KEY,
  rpo_minutes   INT NOT NULL,
  rto_minutes   INT NOT NULL,
  tier          VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
  updated_at    TIMESTAMP DEFAULT NOW()
);

INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
  ('orders_db',    15,   60, 'CRITICAL'),
  ('analytics_db', 120, 240, 'MEDIUM'),
  ('archive_db',   480, 480, 'LOW');

Typy kopii zapasowych

Istnieją trzy podstawowe strategie tworzenia kopii zapasowych, z których każda stanowi kompromis między szybkością a zajętością pamięci:

  • Pełna kopia zapasowa: Pełna migawka całej bazy danych. Najwolniejsza do utworzenia, najszybsza do odtworzenia.
  • Różnicowa kopia zapasowa: Tylko zmiany od czasu wykonania ostatniej pełnej kopii zapasowej. Umiarkowana szybkość tworzenia i odtwarzania.
  • Przyrostowa kopia zapasowa: Tylko zmiany od czasu wykonania ostatniej kopii zapasowej dowolnego typu. Najszybsza do utworzenia, najwolniejsza do odtworzenia (wymaga wielu plików).

Większość strategii DR łączy cotygodniowe pełne kopie zapasowe z codziennymi kopiami przyrostowymi, aby zachować równowagę między RPO a kosztem przechowywania danych.

-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
  backup_id   SERIAL PRIMARY KEY,
  db_name     VARCHAR(100) NOT NULL,
  backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
  started_at  TIMESTAMP NOT NULL,
  finished_at TIMESTAMP,
  size_mb     NUMERIC(12, 2),
  status      VARCHAR(20) DEFAULT 'IN_PROGRESS'
);

INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
  ('orders_db', 'FULL',        '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00',   320, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00',   290, 'SUCCESS');

Odzyskiwanie do punktu w czasie (PITR)

Odzyskiwanie do punktu w czasie umożliwia odtworzenie bazy danych z dowolnego określonego momentu, a nie tylko z chwili wykonania ostatniej kopii zapasowej. Osiąga się to przez odtwarzanie dzienników transakcji (w PostgreSQL dziennika WAL) na podstawie kopii bazowej.

PITR jest niezbędne, gdy trzeba odzyskać dane po przypadkowym uszkodzeniu lub usunięciu danych, które nastąpiło w znanym momencie. Bazę można odtworzyć do chwili tuż przed wystąpieniem szkodliwego zdarzenia.

-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
  segment_name  VARCHAR(200) PRIMARY KEY,
  archived_at   TIMESTAMP DEFAULT NOW(),
  size_bytes    BIGINT,
  storage_path  TEXT
);

-- Find all WAL segments archived within a recovery window
SELECT
  segment_name,
  archived_at,
  ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;

Bazy zapasowe i replikacja

Baza zapasowa (replika) to stale aktualizowana kopia głównej bazy danych działająca na oddzielnym sprzęcie. Służy dwóm celom w ramach DR:

  • Hot standby: może przyjmować zapytania odczytu i przełączyć się awaryjnie w ciągu kilku sekund (niemal zerowy RTO).
  • Warm standby: jest utrzymywana w synchronizacji, ale nie obsługuje ruchu; przełączenie awaryjne trwa kilka minut.

Monitorowanie opóźnienia replikacji ma kluczowe znaczenie — opóźniona replika oznacza, że rzeczywiste RPO jest gorsze od oczekiwanego.

-- Monitor replication lag on a PostgreSQL primary
SELECT
  client_addr,
  application_name,
  state,
  sent_lsn,
  replay_lsn,
  (sent_lsn - replay_lsn) AS lag_bytes,
  EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;

Runbooki: Dokumentowanie procedur odzyskiwania

Runbook to udokumentowany zestaw instrukcji krok po kroku, których operator przestrzega podczas zdarzenia wymagającego odzyskiwania po awarii. Bez runbooka nawet doświadczeni administratorzy baz danych popełniają pod presją kosztowne błędy.

Dobry runbook zawiera informacje o tym, z kim się skontaktować, jakie systemy są objęte awarią, dokładne polecenia do wykonania, oczekiwane wyniki każdego kroku oraz procedury wycofania zmian w przypadku niepowodzenia odzyskiwania. Przechowywanie metadanych runbooków w bazie danych pomaga śledzić wersje i kontrolować ich użycie.

-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
  runbook_id   SERIAL PRIMARY KEY,
  title        VARCHAR(200) NOT NULL,
  scenario     VARCHAR(100),
  version      VARCHAR(20) DEFAULT '1.0',
  last_tested  DATE,
  owner        VARCHAR(100),
  doc_url      TEXT
);

INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
  ('Full Database Restore from S3', 'total_loss',     '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
  ('Failover to Hot Standby',       'primary_down',   '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
  ('PITR to Specific Timestamp',    'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');

Rejestrowanie wykonywania runbooków

Za każdym razem, gdy runbook jest wykonywany — podczas rzeczywistej awarii lub ćwiczeń — należy to zarejestrować. Dzienniki wykonania pozwalają zmierzyć rzeczywisty czas odzyskiwania (weryfikując RTO), zidentyfikować powolne lub podatne na błędy kroki oraz wykazać audytorom zgodność z wymaganiami.

-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
  execution_id  SERIAL PRIMARY KEY,
  runbook_id    INT REFERENCES runbook(runbook_id),
  triggered_by  VARCHAR(100),
  is_drill      BOOLEAN DEFAULT FALSE,
  started_at    TIMESTAMP NOT NULL,
  completed_at  TIMESTAMP,
  outcome       VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);

-- Report average restore time per runbook
SELECT
  r.title,
  COUNT(*) AS executions,
  ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
  MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;

Testowanie DR: Regularne ćwiczenia

Plan DR, który nigdy nie został przetestowany, nie jest planem — jest tylko życzeniem. Regularne ćwiczenia są niezbędne, aby upewnić się, że zespół potrafi wykonać runbooki w ramach określonego RTO, a kopie zapasowe rzeczywiście można odtworzyć.

Planowanie i śledzenie ćwiczeń w bazie danych tworzy ścieżkę audytową i pomaga wykrywać runbooki, których testowanie jest opóźnione.

-- Find runbooks that have not been drilled in over 90 days
SELECT
  r.runbook_id,
  r.title,
  r.scenario,
  MAX(e.completed_at) AS last_drill,
  CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
  ON e.runbook_id = r.runbook_id
  AND e.is_drill = TRUE
  AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
    OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;

Polityki retencji kopii zapasowych

Polityki retencji określają, jak długo przechowywane są kopie zapasowe. Przechowywanie każdej kopii bez końca marnuje miejsce, a usuwanie ich zbyt szybko narusza wymagania RPO i zgodności.

Typowa polityka obejmuje: codzienne kopie przyrostowe przez 7 dni, cotygodniowe pełne kopie przez 4 tygodnie oraz comiesięczne pełne kopie przez 12 miesięcy. Retencję można egzekwować i kontrolować za pomocą zapytań SQL wykonywanych względem dziennika kopii zapasowych.

-- Identify backups that are outside their retention window and ready to purge
SELECT
  backup_id,
  db_name,
  backup_type,
  finished_at,
  CURRENT_DATE - finished_at::DATE AS age_days,
  CASE backup_type
    WHEN 'INCREMENTAL' THEN 7
    WHEN 'DIFFERENTIAL' THEN 28
    WHEN 'FULL'         THEN 365
  END AS retention_days,
  CASE
    WHEN (CURRENT_DATE - finished_at::DATE) >
         CASE backup_type
           WHEN 'INCREMENTAL' THEN 7
           WHEN 'DIFFERENTIAL' THEN 28
           WHEN 'FULL'         THEN 365
         END
    THEN 'PURGE'
    ELSE 'KEEP'
  END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;

Szybki test

Proszę sprawdzić swoją znajomość definicji RPO i RTO.

Podsumowanie: planowanie odtwarzania po awarii

W tej lekcji poznali Państwo podstawy planowania odtwarzania bazy danych po awarii:

  • RPO określa maksymalną dopuszczalną utratę danych wyrażoną w czasie; krótszy RPO wymaga częstszych kopii zapasowych lub replikacji ciągłej.
  • RTO określa, jak szybko system musi zostać przywrócony; krótszy RTO wymaga gorących serwerów zapasowych i automatycznego przełączania awaryjnego.
  • Typy kopii zapasowych — pełne, różnicowe i przyrostowe — oferują różne kompromisy między ilością zajmowanego miejsca, szybkością tworzenia a szybkością przywracania.
  • PITR (odzyskiwanie do punktu w czasie) wykorzystuje dzienniki transakcji, aby przywrócić dane do dowolnego, dokładnie określonego momentu i chronić je przed przypadkowymi zmianami.
  • Runbooki dokumentują każdy etap procedury odzyskiwania; rejestrowanie wykonania procedur pozwala sprawdzić, czy osiągnięcie założonego RTO jest w praktyce możliwe.
  • Regularne ćwiczenia DR to jedyny sposób, aby potwierdzić, że kopie zapasowe można przywrócić oraz że zespół jest w stanie osiągnąć cele RPO i RTO w warunkach rzeczywistej presji.
  • Polityki retencji równoważą koszty przechowywania z wymaganiami dotyczącymi zgodności i odzyskiwania danych.

Dobrze przetestowany plan DR to jedna z najcenniejszych inwestycji, jakie może poczynić zespół baz danych.

Często zadawane pytania

Czy lekcja „Planowanie odtwarzania po awarii” jest bezpłatna?

Tak — pełny tekst „Planowanie odtwarzania po awarii” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu SQL Academy, przejdź na CoddyKit PRO. Kurs SQL Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Planowanie odtwarzania po awarii”?

RPO, RTO i runbooki Ćwiczysz SQL Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć SQL Academy?

Nie wymagamy żadnego doświadczenia. SQL Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Planowanie odtwarzania po awarii”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji SQL Academy?

Tak. Każda lekcja SQL Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Kopie logiczne a fizyczne
  2. Odzyskiwanie do określonego momentu
  3. Testowanie przywracania kopii
  4. Planowanie odtwarzania po awarii
← Powrót do SQL Academy