Perencanaan Pemulihan Bencana
RPO, RTO, dan buku panduan operasional.
Perencanaan Pemulihan Bencana adalah pelajaran SQL Academy gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar SQL Academy, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus SQL Academy mencakup 4 pelajaran total.
Apa Itu Pemulihan Bencana?
Pemulihan Bencana (DR) adalah serangkaian kebijakan, alat, dan prosedur yang dirancang untuk memungkinkan pemulihan infrastruktur dan sistem teknologi penting setelah bencana alam atau bencana yang disebabkan oleh manusia.
Dalam konteks basis data, perencanaan DR memastikan data tetap aman dan sistem dapat kembali daring dalam batas waktu yang dapat diterima setelah peristiwa seperti kegagalan perangkat keras, penghapusan data yang tidak disengaja, serangan perangkat lunak pemeras, atau pemadaman pusat data.
Sasaran Titik Pemulihan (RPO)
RPO menentukan jumlah maksimum kehilangan data yang dapat diterima, diukur berdasarkan waktu. Jika RPO Anda adalah 1 jam, Anda harus dapat memulihkan data hingga setidaknya 1 jam sebelum bencana terjadi.
RPO yang lebih singkat memerlukan pencadangan yang lebih sering atau replikasi berkelanjutan. Anda dapat menjalankan kueri pada riwayat pencadangan untuk memverifikasi bahwa sasaran RPO Anda terpenuhi.
-- 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;Sasaran Waktu Pemulihan (RTO)
RTO menentukan durasi maksimum sistem Anda boleh luring setelah bencana. Jika RTO Anda adalah 4 jam, basis data Anda harus beroperasi penuh dalam waktu 4 jam sejak kegagalan.
RTO memengaruhi keputusan tentang server siaga, otomatisasi pengalihan, dan prosedur pemulihan. Melacak durasi pemulihan dari waktu ke waktu membantu Anda memperkirakan apakah RTO dapat dipenuhi.
-- 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 dan RTO — Perbedaan Utama
Kedua metrik ini sering tertukar. Berikut cara paling sederhana untuk mengingatnya:
- RPO = Berapa banyak data yang sanggup Anda kehilangan? (berorientasi ke masa lalu, diukur berdasarkan waktu sebelum bencana)
- RTO = Berapa lama Anda sanggup sistem tidak beroperasi? (berorientasi ke masa depan, diukur berdasarkan waktu setelah bencana)
Bersama-sama, keduanya menentukan rentang pemulihan dan secara langsung memengaruhi frekuensi pencadangan, strategi replikasi, serta anggaran infrastruktur Anda.
-- 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');Jenis Pencadangan
Ada tiga strategi pencadangan utama, masing-masing menyeimbangkan kecepatan dan penyimpanan:
- Pencadangan penuh: Salinan lengkap seluruh basis data. Paling lambat dibuat, paling cepat dipulihkan.
- Pencadangan diferensial: Hanya perubahan sejak pencadangan penuh terakhir. Kecepatannya sedang untuk pembuatan maupun pemulihan.
- Pencadangan inkremental: Hanya perubahan sejak pencadangan terakhir, apa pun jenisnya. Paling cepat dibuat, paling lambat dipulihkan (memerlukan beberapa berkas).
Sebagian besar strategi DR menggabungkan pencadangan penuh mingguan dengan pencadangan inkremental harian untuk menyeimbangkan RPO dan biaya penyimpanan.
-- 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');Pemulihan Titik Waktu (PITR)
Pemulihan Titik Waktu memungkinkan Anda memulihkan basis data ke waktu tertentu, bukan hanya ke waktu pencadangan terakhir. Hal ini dilakukan dengan memutar ulang catatan transaksi (WAL dalam PostgreSQL) di atas cadangan dasar.
PITR sangat penting ketika Anda perlu memulihkan data dari kerusakan atau penghapusan yang tidak disengaja dan terjadi pada waktu yang diketahui. Anda dapat memulihkan data ke waktu tepat sebelum peristiwa yang merusak terjadi.
-- 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;Basis Data Siaga dan Replikasi
Basis data siaga (replika) adalah salinan basis data utama yang terus diperbarui dan berjalan pada perangkat keras terpisah. Basis data ini memiliki dua tujuan DR:
- Siaga panas: Dapat menerima kueri baca dan beralih dalam hitungan detik (RTO hampir nol).
- Siaga hangat: Tetap disinkronkan tetapi tidak melayani lalu lintas; pengalihan memerlukan waktu beberapa menit.
Memantau keterlambatan replikasi sangat penting — replika yang tertinggal berarti RPO aktual Anda lebih buruk daripada yang diharapkan.
-- 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;Buku Panduan Operasi: Mendokumentasikan Prosedur Pemulihan
Buku panduan operasi adalah kumpulan instruksi langkah demi langkah yang terdokumentasi dan diikuti operator selama peristiwa pemulihan bencana. Tanpa buku panduan operasi, bahkan administrator basis data yang berpengalaman dapat melakukan kesalahan mahal saat berada di bawah tekanan.
Buku panduan operasi DR yang baik mencakup: siapa yang harus dihubungi, sistem apa yang terdampak, perintah tepat yang harus dijalankan, keluaran yang diharapkan pada setiap langkah, dan prosedur pengembalian jika pemulihan gagal. Menyimpan metadata buku panduan operasi dalam basis data membantu melacak versi dan mengaudit penggunaannya.
-- 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');Pencatatan Pelaksanaan Buku Panduan Operasi
Setiap kali buku panduan operasi dijalankan — baik dalam bencana nyata maupun simulasi — pelaksanaannya harus dicatat. Catatan pelaksanaan memungkinkan Anda mengukur berapa lama pemulihan sebenarnya berlangsung (untuk memvalidasi RTO), mengidentifikasi langkah yang lambat atau rentan terhadap kesalahan, dan menunjukkan kepatuhan kepada auditor.
-- 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;Pengujian DR: Simulasi Berkala
Rencana DR yang belum pernah diuji bukanlah rencana — melainkan harapan. Simulasi berkala wajib dilakukan untuk memastikan tim Anda benar-benar dapat menjalankan buku panduan operasi dalam batas RTO yang ditetapkan dan bahwa cadangan benar-benar dapat dipulihkan.
Menjadwalkan dan melacak simulasi dalam basis data membuat jejak audit serta membantu Anda menemukan buku panduan operasi yang sudah waktunya diuji.
-- 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;Kebijakan Penyimpanan Cadangan
Kebijakan penyimpanan menentukan berapa lama cadangan disimpan. Menyimpan setiap cadangan selamanya memboroskan ruang penyimpanan; menghapusnya terlalu cepat melanggar RPO dan persyaratan kepatuhan.
Kebijakan yang umum adalah: pencadangan inkremental harian selama 7 hari, pencadangan penuh mingguan selama 4 minggu, dan pencadangan penuh bulanan selama 12 bulan. Anda dapat menerapkan dan mengaudit kebijakan penyimpanan dengan kueri SQL terhadap catatan pencadangan.
-- 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;Uji Cepat
Uji pemahaman Anda tentang definisi RPO dan RTO.
Ringkasan: Perencanaan Pemulihan Bencana
Dalam pelajaran ini, Anda mempelajari dasar-dasar perencanaan pemulihan bencana untuk basis data:
- RPO menentukan kehilangan data maksimum yang masih dapat ditoleransi berdasarkan waktu; RPO yang lebih singkat memerlukan pencadangan lebih sering atau replikasi berkelanjutan.
- RTO menentukan seberapa cepat sistem harus dipulihkan; RTO yang lebih singkat memerlukan server siaga aktif dan pengalihan otomatis.
- Jenis pencadangan — penuh, diferensial, inkremental — masing-masing memberikan kompromi berbeda antara kapasitas penyimpanan, kecepatan pembuatan, dan kecepatan pemulihan.
- PITR (Pemulihan pada Titik Waktu) menggunakan log transaksi untuk memulihkan data ke waktu tertentu secara tepat, sehingga melindungi dari perubahan yang tidak disengaja.
- Buku panduan operasional mendokumentasikan setiap langkah prosedur pemulihan; pencatatan pelaksanaan memvalidasi bahwa RTO Anda dapat dicapai dalam praktik.
- Latihan DR secara berkala merupakan satu-satunya cara untuk memastikan pencadangan dapat dipulihkan dan tim Anda dapat memenuhi target RPO dan RTO dalam tekanan nyata.
- Kebijakan retensi menyeimbangkan biaya penyimpanan dengan persyaratan kepatuhan dan pemulihan.
Rencana DR yang telah diuji dengan baik merupakan salah satu investasi paling berharga yang dapat dilakukan tim basis data.
Belajar SQL dengan tutor AI — gratis
Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.
- Kursus
- 46
- Pelajaran
- 183
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Perencanaan Pemulihan Bencana” gratis?
Ya — teks lengkap “Perencanaan Pemulihan Bencana” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus SQL Academy, upgrade ke CoddyKit PRO. Kursus SQL Academy mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Perencanaan Pemulihan Bencana”?
RPO, RTO, dan buku panduan operasional. Kamu berlatih SQL Academy dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai SQL Academy?
Tidak diperlukan pengalaman sebelumnya. SQL Academy di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Perencanaan Pemulihan Bencana” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran SQL Academy ini?
Ya. Setiap pelajaran SQL Academy menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Cadangan Logis vs Fisik
- Pemulihan Titik Waktu
- Menguji Pemulihan Anda
- Perencanaan Pemulihan Bencana