0Pricing
SQL Academy · Ders

Felaket Kurtarma Planlaması

RPO, RTO ve çalışma kitapları.

Felaket Kurtarma Planlaması, CoddyKit'te ücretsiz bir SQL Academy dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, SQL Academy öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. SQL Academy kursu toplamda 4 dersten oluşur.

Felaket Kurtarma Nedir?

Felaket Kurtarma (DR), doğal veya insan kaynaklı felaketlerden sonra hayati teknoloji altyapısının ve sistemlerin kurtarılmasını mümkün kılmak üzere tasarlanmış politika, araç ve yordamlar bütünüdür.

Veritabanları bağlamında DR planlaması, donanım arızası, yanlışlıkla veri silinmesi, fidye yazılımı saldırıları veya veri merkezi kesintileri gibi olaylardan sonra verilerinizin güvende kalmasını ve sistemlerinizin kabul edilebilir süre sınırları içinde yeniden çevrimiçi duruma getirilebilmesini sağlar.

Kurtarma Noktası Hedefi (RPO)

RPO, zaman cinsinden ölçülen kabul edilebilir azami veri kaybını tanımlar. RPO'nuz 1 saatse felaketten en az 1 saat öncesine kadar olan verileri kurtarabilmeniz gerekir.

Daha kısa bir RPO, daha sık yedekleme veya sürekli çoğaltma gerektirir. RPO hedefinizi karşılayıp karşılamadığınızı doğrulamak için yedekleme geçmişinizi sorgulayabilirsiniz.

-- 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;

Kurtarma Süresi Hedefi (RTO)

RTO, sisteminizin bir felaketten sonra çevrimdışı kalabileceği kabul edilebilir azami süreyi tanımlar. RTO'nuz 4 saatse veritabanınızın bir arızadan sonraki 4 saat içinde tamamen çalışır durumda olması gerekir.

RTO; bekleme sunucuları, yük devretme otomasyonu ve geri yükleme yordamlarıyla ilgili kararları belirler. Geri yükleme sürelerini zaman içinde izlemek, RTO'nuzu karşılayıp karşılayamayacağınızı öngörmenize yardımcı olur.

-- 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 ve RTO — Temel Fark

Bu iki ölçüt sıklıkla karıştırılır. Bunları hatırlamanın en basit yolu şöyledir:

  • RPO = Ne kadar veriyi kaybetmeyi göze alabilirsiniz? (geçmişe dönüktür, felaketten önceki zamanla ölçülür)
  • RTO = Ne kadar süre devre dışı kalmayı göze alabilirsiniz? (ileriye dönüktür, felaketten sonraki zamanla ölçülür)

Birlikte kurtarma pencerenizi tanımlar ve yedekleme sıklığınızı, çoğaltma stratejinizi ve altyapı bütçenizi doğrudan etkilerler.

-- 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');

Yedek Türleri

Her biri hız ile depolama arasında denge kuran üç temel yedekleme stratejisi vardır:

  • Tam yedekleme: Tüm veritabanının eksiksiz bir anlık görüntüsüdür. Oluşturulması en yavaştır, geri yüklenmesi en hızlıdır.
  • Fark yedekleme: Yalnızca son tam yedeklemeden bu yana yapılan değişiklikleri içerir. Her iki yönde de orta hızdadır.
  • Artımlı yedekleme: Yalnızca herhangi türdeki son yedeklemeden bu yana yapılan değişiklikleri içerir. Oluşturulması en hızlı, geri yüklenmesi en yavaştır (birden fazla dosya gerekir).

Çoğu DR stratejisi, RPO ile depolama maliyetini dengelemek için haftalık tam yedekleri günlük artımlı yedeklerle birleştirir.

-- 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');

Belirli Bir Zamana Kurtarma (PITR)

Belirli Bir Zamana Kurtarma, bir veritabanını yalnızca son yedekleme zamanına değil, belirli herhangi bir ana geri yüklemenizi sağlar. Bu işlem, işlem günlüklerinin (PostgreSQL'de WAL) temel yedeğin üzerine yeniden oynatılmasıyla gerçekleştirilir.

PITR, belirli bir zamanda gerçekleşen yanlışlıkla veri bozulması veya silinmesinden kurtulmanız gerektiğinde zorunludur. Zarar verici olayın gerçekleşmesinden hemen öncesine geri yükleme yapabilirsiniz.

-- 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;

Bekleme Veritabanları ve Çoğaltma

Bekleme (replika) veritabanı, ayrı donanım üzerinde çalışan ve birincil veritabanının sürekli güncellenen bir kopyasıdır. İki DR amacıyla kullanılır:

  • Sıcak bekleme: Okuma sorgularını kabul edebilir ve saniyeler içinde yük devreder (sıfıra yakın RTO).
  • Ilık bekleme: Eşitlenmiş halde tutulur ancak trafiğe hizmet vermez; yük devretme dakikalar sürer.

Çoğaltma gecikmesini izlemek kritiktir — geride kalan bir replika, gerçek RPO'nuzun beklenenden daha kötü olduğu anlamına gelir.

-- 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;

İşletim Kılavuzları: Kurtarma Yordamlarını Belgeleme

İşletim kılavuzu, bir işletici tarafından felaket kurtarma olayı sırasında izlenen, belgelenmiş adım adım yönergeler bütünüdür. İşletim kılavuzu olmadan deneyimli veritabanı yöneticileri bile baskı altında maliyetli hatalar yapar.

İyi bir DR işletim kılavuzu şunları içerir: kiminle iletişime geçileceği, hangi sistemlerin etkilendiği, çalıştırılacak tam komutlar, her adımda beklenen çıktılar ve kurtarma başarısız olursa geri alma yordamları. İşletim kılavuzu üst verilerini bir veritabanında saklamak, sürümlemeyi izlemeye ve kullanımı denetlemeye yardımcı olur.

-- 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');

İşletim Kılavuzu Yürütme Günlüğü

Bir işletim kılavuzu her yürütüldüğünde — gerçek bir felakette veya tatbikatta — bu yürütme günlük kaydına alınmalıdır. Yürütme günlükleri, kurtarmanın gerçekte ne kadar sürdüğünü ölçmenizi (RTO'yu doğrulamanızı), yavaş veya hataya açık adımları belirlemenizi ve denetçilere uyumluluğu göstermenizi sağlar.

-- 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;

DR Sınaması: Düzenli Tatbikatlar

Hiç sınanmamış bir DR planı plan değildir — bir dilektir. Ekibinizin işletim kılavuzlarını tanımlanan RTO içinde gerçekten uygulayabilmesini ve yedeklerin gerçekten geri yüklenebilir olmasını sağlamak için düzenli tatbikatlar zorunludur.

Tatbikatları veritabanınızda planlamak ve izlemek bir denetim izi oluşturur ve sınama zamanı geçmiş işletim kılavuzlarını ortaya çıkarmanıza yardımcı olur.

-- 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;

Yedek Saklama Politikaları

Saklama politikaları, yedeklerin ne kadar süre tutulacağını tanımlar. Her yedeği sonsuza kadar saklamak depolama alanını israf eder; yedekleri çok hızlı silmek RPO'nuzu ve uyumluluk gerekliliklerini ihlal eder.

Yaygın bir politika şöyledir: 7 gün boyunca günlük artımlı yedekler, 4 hafta boyunca haftalık tam yedekler ve 12 ay boyunca aylık tam yedekler. Saklama süresini, yedekleme günlüğünüzü sorgulayan SQL sorgularıyla uygulayabilir ve denetleyebilirsiniz.

-- 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;

Hızlı Kontrol

RPO ve RTO tanımları hakkındaki anlayışınızı sınayın.

Özet: Felaket Kurtarma Planlaması

Bu derste veritabanı felaket kurtarma planlamasının temellerini incelediniz:

  • RPO, zaman açısından tolere edilebilecek en fazla veri kaybını tanımlar; daha kısa bir RPO, daha sık yedekleme veya sürekli çoğaltma gerektirir.
  • RTO, sistemin ne kadar hızlı geri yüklenmesi gerektiğini tanımlar; daha kısa bir RTO, sıcak yedek sunucular ve otomatik yük devretme gerektirir.
  • Yedekleme türlerinin — tam, diferansiyel ve artımlı — her biri depolama, oluşturma hızı ve geri yükleme hızı arasında farklı ödünleşimler sunar.
  • PITR (Belirli Bir Zamana Kurtarma), herhangi bir kesin ana geri yükleme yapmak için işlem günlüklerini kullanır ve kazara yapılan değişikliklere karşı koruma sağlar.
  • Kurtarma kılavuzları, kurtarma prosedürünün her adımını belgeler; çalıştırmaların günlüğe kaydedilmesi, RTO'nuzun uygulamada karşılanabilir olduğunu doğrular.
  • Düzenli DR tatbikatları, yedeklerin geri yüklenebildiğini ve ekibinizin gerçek baskı altında RPO ve RTO hedeflerini karşılayabildiğini doğrulamanın tek yoludur.
  • Saklama politikaları, depolama maliyetini uyumluluk ve kurtarma gereksinimleriyle dengeler.

İyice sınanmış bir DR planı, bir veritabanı ekibinin yapabileceği en değerli yatırımlardan biridir.

Sıkça Sorulan Sorular

“Felaket Kurtarma Planlaması” dersi ücretsiz mi?

Evet — “Felaket Kurtarma Planlaması” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve SQL Academy kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. SQL Academy kursu toplamda 4 dersten oluşur.

“Felaket Kurtarma Planlaması” dersinde ne öğreneceğim?

RPO, RTO ve çalışma kitapları. SQL Academy ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

SQL Academy öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te SQL Academy, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Felaket Kurtarma Planlaması” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu SQL Academy dersinde kod yazıp çalıştırabilir miyim?

Evet. Her SQL Academy dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. Mantıksal ve Fiziksel Yedeklemeler
  2. Belirli Bir Zamana Kurtarma
  3. Geri Yüklemelerinizi Test Etme
  4. Felaket Kurtarma Planlaması
← SQL Academy Sayfasına Dön