Disaster Recovery

Pengantar

Disaster Recovery (DR) adalah serangkaian kebijakan, prosedur, dan infrastruktur yang dirancang untuk memulihkan sistem TI dan data organisasi setelah terjadinya bencana - baik bencana alam (gempa, banjir, kebakaran) maupun bencana buatan manusia (serangan siber besar, sabotase, kesalahan operasional massal). DR adalah sub-komponen dari Business Continuity Planning (BCP) yang secara spesifik berfokus pada pemulihan teknologi informasi.

Disaster berbeda dengan insiden biasa karena skalanya yang besar dan dampaknya yang meluas. Sebagai contoh, serangan ransomware yang mengenkripsi seluruh server di pusat data utama adalah disaster, bukan sekadar insiden. Demikian pula, kebakaran yang menghanguskan ruang server adalah disaster yang memerlukan DR Plan untuk dipicu.

Disaster Recovery Planning

DR Planning adalah proses berkelanjutan yang mencakup:

1. Risk Assessment - Identifikasi ancaman yang mungkin menyebabkan disaster.
2. Business Impact Analysis (BIA) - Dampak jika sistem tidak tersedia dalam waktu lama.
3. Recovery Strategies - Pemilihan strategi pemulihan yang paling cost-effective.
4. Plan Development - Penulisan DR Plan yang detail dan actionable.
5. Testing & Maintenance - Pengujian dan pemutakhiran DR Plan secara berkala.

Komponen Dokumen DR Plan

Sebuah DR Plan yang komprehensif harus mencakup:

**DISASTER RECOVERY PLAN DOCUMENT STRUCTURE**

1.0 PENDAHULUAN
  1.1 Tujuan
  1.2 Ruang Lingkup
  1.3 Asumsi Dasar
  1.4 Definisi dan Singkatan

2.0 RISK ASSESSMENT
  2.1 Daftar Ancaman (Threat Catalog)
  2.2 Risk Matrix (Likelihood vs Impact)
  2.3 Mitigation Controls

3.0 RECOVERY STRATEGY
  3.1 Strategi Backup
  3.2 Strategi DR Site
  3.3 Strategi Komunikasi Darurat

4.0 RTO DAN RPO
  4.1 Matriks RTO/RPO per Sistem
  4.2 Prioritas Pemulihan
  4.3 Service Level Agreements

5.0 PROSEDUR AKTIVASI
  5.1 Kriteria Deklarasi Disaster
  5.2 Rantai Komunikasi
  5.3 Prosedur Eskalasi

6.0 PROSEDUR RECOVERY
  6.1 Recovery Infrastruktur Jaringan
  6.2 Recovery Server dan Aplikasi
  6.3 Recovery Database
  6.4 Recovery Data dan File Storage
  6.5 Recovery Endpoint dan Workstation

7.0 PROSEDUR RETURN TO NORMAL
  7.1 Failback dari DR Site ke Primary
  7.2 Verifikasi Pasca-Recovery
  7.3 Dokumentasi dan Lessons Learned

8.0 PENGUJIAN
  8.1 Jenis Testing
  8.2 Jadwal Pengujian
  8.3 Template Laporan Hasil Uji

9.0 LAMPIRAN
  A: Diagram Jaringan DR Site
  B: Daftar Kontak Tim DR
  C: Vendor Contact List
  D: Configuration Templates
  E: Script Recovery Otomatis

DR Sites (Hot / Warm / Cold)

Strategi DR site menentukan seberapa cepat organisasi dapat memulihkan operasi TI setelah bencana. Ada tiga kategori utama:

Hot Site

Hot site adalah pusat data cadangan yang sepenuhnya identik dengan pusat data utama dan siap beroperasi dalam hitungan menit.

Karakteristik:

• Infrastruktur lengkap: server, storage, network, cooling, power.
• Data direplikasi secara real-time atau near-real-time.
• Aplikasi sudah terinstal dan dikonfigurasi.
• Personil on-site atau remote siap mengaktifkan.
• RTO: < 1 jam.
• RPO: Mendekati 0 (zero data loss).

Biaya: Sangat mahal - bisa mencapai 100% dari biaya primary site.

Tools untuk hot site:

Contoh arsitektur hot site dengan AWS Multi-AZ:

# Terraform: RDS Multi-AZ untuk hot standby database
resource "aws_db_instance" "production" {
  engine             = "postgres"
  engine_version     = "16.3"
  instance_class     = "db.r6g.large"
  allocated_storage  = 500
  storage_type       = "gp3"
  multi_az           = true  # Hot standby di AZ berbeda
  backup_retention_period = 35
  auto_minor_version_upgrade = false

  # Performance Insights untuk monitoring
  performance_insights_enabled = true

  # Deletion protection
  deletion_protection = true

  tags = {
    Environment = "production"
    DR          = "hot-site"
  }
}

Warm Site

Warm site adalah pusat data cadangan yang memiliki infrastruktur dasar tetapi mungkin tidak memiliki semua data terkini.

Karakteristik:

• Server dan network tersedia tetapi belum dikonfigurasi penuh.
• Data direplikasi secara periodik (misalnya setiap 1 - 4 jam).
• Aplikasi perlu diinstal/dikonfigurasi saat aktivasi.
• Personil perlu beberapa jam untuk aktivasi.
• RTO: 4 - 24 jam.
• RPO: 1 - 4 jam.

Biaya: Sedang - sekitar 40 - 60% dari primary site.

Contoh implementasi warm site:

#!/bin/bash
# Script aktivasi warm site - replikasi data periodik
DR_SITE="dr.example.com"
PRIMARY_IP="10.0.1.100"

# Replikasi database setiap 2 jam
rsync -avz --delete \
    -e "ssh -i /root/.ssh/dr_key -o StrictHostKeyChecking=no" \
    /var/lib/postgresql/14/main/ \
    postgres@"$DR_SITE":/var/lib/postgresql/14/main/

# Replikasi file aplikasi
rsync -avz --delete \
    -e "ssh -i /root/.ssh/dr_key" \
    /var/www/html/ \
    root@"$DR_SITE":/var/www/html/

# Ambil snapshot untuk point-in-time recovery
ssh root@"$DR_SITE" "pg_ctl -D /var/lib/postgresql/14/main \
    -o '--recovery-target-time=2026-07-20 03:00:00+07' start"

Cold Site

Cold site adalah fasilitas kosong yang menyediakan ruang, power, dan konektivitas dasar. Semua perangkat keras dan data harus didatangkan saat terjadi disaster.

Karakteristik:

• Tidak ada server, storage, atau network equipment yang terpasang.
• Data dan konfigurasi disimpan di backup offline (tape, removable disk).
• Perlu pengadaan perangkat keras - bisa memakan waktu berhari-hari.
• Personil harus melakukan instalasi dari nol.
• RTO: 24 jam - 2 minggu.
• RPO: 24 jam - 7 hari.

Biaya: Rendah - sekitar 10 - 20% dari primary site.

Cocok untuk: Organisasi dengan anggaran terbatas atau sistem non-kritis.

Perbandingan DR Sites

Backup Strategies

Jenis Backup

Full Backup: Salinan lengkap seluruh data.

• Keunggulan: Restore paling cepat (hanya 1 sumber).
• Kelemahan: Paling lambat dan paling besar kapasitasnya.
• Frekuensi: Mingguan/bulanan.

Incremental Backup: Hanya data yang berubah sejak backup terakhir (full atau incremental).

• Keunggulan: Paling cepat dan paling kecil ukurannya.
• Kelemahan: Restore paling lambat (harus restore full + semua incremental).
• Frekuensi: Harian/jam.

Differential Backup: Semua data yang berubah sejak full backup terakhir.

• Keunggulan: Lebih cepat restore daripada incremental (full + 1 differential).
• Kelemahan: Ukuran terus membesar seiring waktu.
• Frekuensi: Harian.

Ilustrasi restore time:

Full Backup (Minggu)      = besar, lambat backup, cepat restore
Incremental Backup (Senin) = kecil, cepat backup, lambat restore
Incremental Backup (Selasa)= kecil, cepat backup, lambat restore
--- Saat restore ---
Restore = Full + Incremental Senin + Incremental Selasa + ...

Differential Backup (Senin)= sedang, sedang backup, sedang restore
Differential Backup (Selasa)= lebih besar, sedang backup, sedang restore
--- Saat restore ---
Restore = Full + Differential terakhir

Rekomendasi strategi backup kombinasi:

#!/bin/bash
# Strategi backup kombinasi dengan rsync
BACKUP_DIR="/mnt/backup"
SOURCE_DIR="/data/production"
DATE=$(date +%Y%m%d)

case $(date +%u) in
  7)  # Minggu - Full backup
      echo "[*] Melakukan full backup..."
      rsync -avz --delete "$SOURCE_DIR" "$BACKUP_DIR/full/$DATE/"
      echo "[+] Full backup selesai: $DATE"
      ;;
  1|2|3|4|5|6)  # Senin-Sabtu - Incremental backup
      echo "[*] Melakukan incremental backup..."
      rsync -avz --link-dest="$BACKUP_DIR/full/$(date +%Y%m%d -d 'last sunday')/" \
            "$SOURCE_DIR" "$BACKUP_DIR/inc/$DATE/"
      echo "[+] Incremental backup selesai: $DATE"
      ;;
esac

Aturan 3-2-1 Backup

Aturan emas backup yang diakui secara internasional:

Implementasi 3-2-1:

1. Salinan 1 (Primary): Data asli di production server (SSD RAID 10).
2. Salinan 2 (Local Backup): Backup harian ke NAS lokal (HDD RAID 6).
3. Salinan 3 (Offsite Backup): Backup ke cloud (AWS S3 + Glacier) atau tape vaulting.

Contoh script backup ke S3 dengan enkripsi:

#!/bin/bash
# Backup 3-2-1: Offsite copy to AWS S3 with server-side encryption
BACKUP_FILE="backup-$(date +%Y%m%d-%H%M%S).tar.gz.gpg"
SOURCE_DIR="/mnt/backup/daily"
BUCKET="s3://company-d-backup-offsite"

echo "[*] Membuat archive terenkripsi..."
tar czf - "$SOURCE_DIR" | gpg --encrypt --recipient [email protected] \
    > "/tmp/$BACKUP_FILE"

echo "[*] Mengupload ke S3 dengan SSE-S3..."
aws s3 cp "/tmp/$BACKUP_FILE" "$BUCKET/daily/" \
    --sse AES256 \
    --storage-class STANDARD_IA \
    --metadata "backup-type=daily,created=$(date -Iseconds)"

echo "[*] Memberlakukan lifecycle policy..."
aws s3api put-bucket-lifecycle-configuration \
    --bucket "company-d-backup-offsite" \
    --lifecycle-configuration '{
        "Rules": [{
            "ID": "backup-lifecycle",
            "Status": "Enabled",
            "Filter": {"Prefix": "daily/"},
            "Transitions": [
                {"Days": 30,  "StorageClass": "GLACIER"},
                {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}
            ],
            "Expiration": {"Days": 730}
        }]
    }'

echo "[+] Offsite backup selesai: $BACKUP_FILE"

Backup Validation (Test Restore)

Backup yang tidak pernah diuji bukanlah backup - itu harapan kosong. Validasi backup harus dilakukan secara rutin.

Metode validasi:

Contoh automated test restore:

#!/bin/bash
# Automated test restore untuk PostgreSQL
set -e

echo "[*] Membuat database sementara untuk test restore..."
createdb test_restore_$(date +%Y%m%d)

echo "[*] Mengunduh backup terbaru dari S3..."
LATEST_BACKUP=$(aws s3 ls s3://company-d-backup-offsite/daily/ \
    | sort | tail -1 | awk '{print \$4}')
aws s3 cp "s3://company-d-backup-offsite/daily/$LATEST_BACKUP" /tmp/

echo "[*] Mendekripsi dan merestore backup..."
gpg --decrypt "/tmp/$LATEST_BACKUP" | tar xz -C /tmp/restore_test/
pg_restore -d test_restore_$(date +%Y%m%d) /tmp/restore_test/dump.sql

echo "[*] Memvalidasi integritas data..."
psql -d test_restore_$(date +%Y%m%d) -c "
    SELECT COUNT(*) as total_tables FROM information_schema.tables
    WHERE table_schema = 'public';
"
psql -d test_restore_$(date +%Y%m%d) -c "
    SELECT COUNT(*) as total_rows FROM transactions;
"

echo "[+] Test restore berhasil!"
psql -c "DROP DATABASE test_restore_$(date +%Y%m%d);"

DR Testing

DR testing adalah satu-satunya cara untuk memastikan bahwa DR Plan benar-benar berfungsi. Tanpa pengujian, DR Plan hanyalah dokumen yang menenangkan hati manajemen - bukan jaring pengaman yang sesungguhnya.

Jenis DR Testing

1. Tabletop Exercise

Diskusi berbasis skenario tanpa menyentuh sistem produksi. Tim duduk bersama dan membahas langkah-langkah yang akan diambil dalam skenario bencana.

Format:

• Durasi: 1 - 2 jam.
• Skenario: "Data center utama kebakaran. Apa yang Anda lakukan?"
• Output: Gap analysis, prosedur yang perlu diperbaiki.
• Cocok untuk: Validasi prosedur awal, tim baru.

2. Walkthrough

Langkah lebih lanjut dari tabletop - tim benar-benar membaca dan menelusuri DR Plan langkah demi langkah.

Format:

• Durasi: 2 - 4 jam.
• Aktivitas: Baca setiap langkah, verifikasi kelengkapan dokumentasi.
• Output: Daftar dokumentasi yang kurang atau ambigu.

3. Simulation Test

Pengujian di lingkungan terisolasi (non-produksi) tanpa dampak ke produksi.

Format:

• Durasi: 4 - 8 jam.
• Aktivitas: Restore sistem dari backup di environment test.
• Output: Bukti bahwa proses restore berfungsi.

Contoh simulation test orchestration dengan Ansible:

---
- name: DR Simulation Test
  hosts: dr_test_environment
  vars:
    dr_backup_bucket: s3://company-d-backup-offsite
    test_date: "{{ ansible_date_time.date }}"

  tasks:
    - name: Create test sandbox
      cloudformation:
        stack_name: "dr-test-{{ test_date }}"
        state: present
        template: templates/dr-sandbox.yml
        parameters:
          Environment: dr-test

    - name: Restore latest database backup
      shell: |
        LATEST=$(aws s3 ls {{ dr_backup_bucket }}/daily/ \
          | sort | tail -1 | awk '{print \$4}')
        aws s3 cp {{ dr_backup_bucket }}/daily/$LATEST /tmp/
        pg_restore -d restored_db /tmp/restore/dump.sql

    - name: Deploy application from golden image
      ec2_instance:
        image_id: "{{ golden_ami_id }}"
        instance_type: t3.medium
        security_group: dr-test-sg
        wait: yes
      register: restored_app

    - name: Validate application health
      uri:
        url: "http://{{ restored_app.instances[0].public_ip }}/health"
        return_content: yes
      register: health
      failed_when: "'OK' not in health.content"

    - name: Generate DR test report
      template:
        src: templates/dr-test-report.j2
        dest: "/tmp/dr-test-report-{{ test_date }}.md"

    - name: Cleanup test sandbox
      cloudformation:
        stack_name: "dr-test-{{ test_date }}"
        state: absent

4. Parallel Test

Pengujian dengan sistem produksi yang masih berjalan. DR site diaktifkan secara paralel untuk memverifikasi fungsionalitas.

Format:

• Durasi: 8 - 24 jam.
• Aktivitas: DR site diaktifkan, aplikasi dijalankan, traffic uji dikirimkan.
• Risiko: Rendah (tidak mengganggu produksi).
• Output: SLA validation, performance comparison.

5. Full Interruption Test

Pengujian paling realistis - produksi benar-benar dimatikan dan DR site mengambil alih.

Format:

• Durasi: 24 - 48 jam.
• Aktivitas: Failover penuh ke DR site + failback.
• Risiko: Tinggi (downtime nyata).
• Frekuensi: Tahunan (atau sesuai regulasi).

Perbandingan DR Testing

Cloud Disaster Recovery

Cloud DR memanfaatkan infrastruktur cloud sebagai DR site, mengurangi kebutuhan investasi pusat data fisik.

AWS Disaster Recovery

AWS menyediakan beberapa layanan untuk DR:

Contoh konfigurasi AWS DRS untuk server on-premise:

{
  "sourceServer": {
    "hostname": "app-server-01.company.id",
    "ipAddress": "10.0.1.100",
    "os": "Ubuntu 22.04",
    "replicationConfiguration": {
      "bandwidthThrottling": 100,
      "usePrivateIP": true,
      "volumeGroups": [
        {
          "volumes": [
            {"device": "/dev/sda1", "iops": 3000},
            {"device": "/dev/sdb1", "iops": 8000}
          ]
        }
      ]
    },
    "launchConfiguration": {
      "targetInstanceType": "m6i.large",
      "targetSubnet": "subnet-dr-private-1",
      "targetSecurityGroup": "sg-dr-app-servers"
    }
  },
  "recoveryPlan": {
    "name": "Production-DR-Plan",
    "steps": [
      {"order": 1, "action": "LAUNCH", "group": "Database"},
      {"order": 2, "action": "LAUNCH", "group": "Application"},
      {"order": 3, "action": "LAUNCH", "group": "Web-Servers"},
      {"order": 4, "action": "TEST", "group": "Health-Check"}
    ]
  }
}

Azure Site Recovery

Azure Site Recovery (ASR) adalah layanan DRaaS (Disaster Recovery as a Service) untuk workload on-premise dan Azure.

Fitur utama ASR:

• Replikasi VM VMware, Hyper-V, dan server fisik.
• Orchestrated recovery dengan recovery plan.
• Automated failover dan failback.
• Non-disruptive testing (test failover terisolasi).

Contoh PowerShell script untuk Azure Site Recovery:

# Azure Site Recovery - Initiate test failover
$asrVault = Get-AzRecoveryServicesVault -ResourceGroupName "RG-DR"
$protectionContainer = Get-AzRecoveryServicesAsrProtectionContainer `
    -Fabric (Get-AzRecoveryServicesAsrFabric)

$recoveryPlan = Get-AzRecoveryServicesAsrRecoveryPlan -Name "Production-RP"

# Test failover ke Azure DR region
Start-AzRecoveryServicesAsrTestFailoverJob `
    -RecoveryPlan $recoveryPlan `
    -Direction PrimaryToRecovery `
    -AzureVMNetworkId (Get-AzVirtualNetwork -Name "vnet-dr" `
        -ResourceGroupName "RG-Network").Id

# Monitoring status failover
$job = Get-AzRecoveryServicesAsrJob -Name "TestFailover"
while ($job.State -eq "InProgress") {
    Write-Host "DR test in progress... State: $($job.State)"
    Start-Sleep -Seconds 30
    $job = Get-AzRecoveryServicesAsrJob -Name $job.Name
}

Write-Host "DR test completed: $($job.State)"

# Cleanup test environment
Start-AzRecoveryServicesAsrTestFailoverCleanupJob `
    -RecoveryPlan $recoveryPlan `
    -Comment "Test completed successfully"

DR Strategy Migration ke Cloud

Organisasi dapat mengadopsi beberapa pola DR di cloud:

Contoh DR Plan Document Structure Lengkap

**DISASTER RECOVERY PLAN**
PT. TEKNOLOGI NUSANTARA
=======================================

Dokumen #: DRP-001 | Versi: 3.2 | Tanggal: 20 Juli 2026
Klasifikasi: CONFIDENTIAL | Pemilik: CISO

### DISTRIBUSI DOKUMEN
| Salinan # | Pemegang | Departemen |
|---|---|---|
| 001 | CISO (asli) | Information Security |
| 002 | VP Engineering | Technology |
| 003 | COO | Operations |
| 004 | Legal Counsel | Legal |

### SKENARIO DISASTER
| ID | Skenario | Kriteria Aktivasi | Contoh |
|---|---|---|---|
| DR-01 | Kehilangan Data Center Utama | DC tidak bisa diakses > 1 jam | Kebakaran, gempa |
| DR-02 | Ransomware Skala Besar | > 50% server terenkripsi | Serangan ransomware |
| DR-03 | Data Corruption Massal | Data hilang/rusak > 24 jam | Bug migration, human error |
| DR-04 | Cloud Provider Outage | Region tidak tersedia > 30 menit | AWS/Azure outage |

### PROSEDUR AKTIVASI CEPAT
1. Incident Commander mendeklarasikan disaster berdasarkan kriteria.
2. Tim DR diaktifkan melalui panggilan conference + Slack channel #dr-activation.
3. DR Site (AWS ap-southeast-1) diaktifkan via automation pipeline.
4. Proses failover dimulai dalam urutan: Network > Database > Application > Web.
5. Setiap langkah diverifikasi sebelum melanjutkan ke langkah berikutnya.
6. Komunikasi status dikirim ke stakeholders setiap 30 menit.

### MATRIKS PEMULIHAN SISTEM
| Sistem | Platform | RTO | RPO | DR Site | Prioritas |
|---|---|---|---|---|---|
| Database Transaksi | PostgreSQL 16 | 1 jam | 0 (sync) | AWS RDS Multi-AZ | 1 |
| API Gateway | Nginx + Node.js | 30 menit | 5 menit | AWS ECS Fargate | 1 |
| Web Frontend | React + CloudFront | 15 menit | stateless | AWS S3 + CDN | 2 |
| Email Server | MS Exchange | 4 jam | 1 jam | Backup restore | 3 |
| ERP Internal | SAP S/4HANA | 8 jam | 4 jam | DR cold site | 4 |

### SKRIP OTOMATIS RECOVERY
Semua skrip recovery tersedia di: https://git.company.internal/dr-scripts
Pull request untuk perubahan harus direview oleh minimal 2 anggota tim DR.

### JADWAL PENGUJIAN TAHUNAN
| Bulan | Jenis Test | Lingkup | PIC |
|---|---|---|---|
| Jan | Tabletop | Ransomware scenario | CISO |
| Apr | Simulation | Database recovery | DBA Team |
| Jul | Parallel Test | Full stack DR site | Infra Lead |
| Oct | Full Interruption | Complete failover + failback | CTO |

### LAMPIRAN
A. Diagram Jaringan - Primary Site
B. Diagram Jaringan - DR Site (AWS ap-southeast-1)
C. Daftar Kontak Tim DR
D. Checklist Aktivasi DR
E. Checklist Failback
F. Template Post-Mortem Report
G. SLA Vendor - AWS Support, ISP, Colocation

Kesimpulan

Disaster Recovery adalah komponen esensial dari ketahanan organisasi yang sering diabaikan sampai bencana benar-benar terjadi. Kunci sukses DR Plan meliputi:

1. Pilih DR site yang tepat - Hot, warm, atau cold sesuai anggaran dan kebutuhan.
2. Terapkan aturan 3-2-1 backup - Minimal 3 salinan, 2 media, 1 offsite.
3. Validasi backup secara berkala - Test restore bukan pilihan, melainkan keharusan.
4. Lakukan DR testing bertahap - Dari tabletop hingga full interruption.
5. Manfaatkan Cloud DR - AWS DRS, Azure Site Recovery, atau layanan DRaaS lainnya.
6. Dokumentasikan dengan detail - DR Plan harus actionable oleh tim yang berbeda.

DR Plan yang baik tidak hanya melindungi data dan sistem - ia melindungi kelangsungan bisnis, reputasi organisasi, dan kepercayaan pelanggan. Investasi dalam DR adalah investasi dalam ketahanan jangka panjang.