Categories
Database Backup

** Discover how DevOps engineers and DBAs can detect corrupted database backups before disaster strikes. Learn advanced techniques for PostgreSQL, SQL Server, and MySQL, including automated restore testing and checksum validation.

Dalam dunia administrasi basis data dan rekayasa keandalan situs yang berisiko tinggi, terdapat aksioma yang terkenal: Cadangan Schrödinger. Kondisi cadangan apa pun tidak diketahui sampai Anda mencoba memulihkannya. Hingga saat itu, cadangan tersebut berada dalam kondisi kuantum, yaitu antara berfungsi sempurna atau rusak total.

Bagi insinyur DevOps dan DBA, menemukan bahwa cadangan basis data yang kritis rusak selama insiden aktif adalah skenario mimpi buruk yang paling utama. Hal ini mengubah operasi pemulihan rutin menjadi peristiwa kehilangan data yang katastrofik. “Pembunuh senyap” integritas data ini sering kali tidak disadari karena pekerjaan pencadangan sering kali melaporkan Exit Code 0 yang sukses meskipun muatan dasarnya telah dikompromikan.

Dalam panduan komprehensif ini, kita akan membedah anatomi kerusakan cadangan, mengeksplorasi teknik validasi khusus basis data, dan mendemonstrasikan cara membangun saluran pemulihan otomatis yang antipeluru untuk lingkungan produksi.

Anatomi Kerusakan Cadangan

Untuk mendeteksi kerusakan, Anda harus terlebih dahulu memahami bagaimana hal itu terjadi. Kerusakan cadangan umumnya terbagi menjadi dua kategori: fisik (tingkat infrastruktur) dan logis (tingkat aplikasi).

Kerusakan Fisik

Kerusakan fisik terjadi ketika bit aktual pada media penyimpanan diubah. Hal ini dapat terjadi selama proses pembacaan dari disk sumber, selama transit jaringan, atau saat diam di penyimpanan target.
* Bit Rot: Degradasi bertahap pada media penyimpanan dapat mengubah bit secara diam-diam.
* **Kesalahan Transit:** Meskipun TCP memiliki checksum, checksum tersebut dikenal lemah (16-bit). Lingkungan dengan throughput tinggi dapat mengalami kerusakan data senyap melalui kabel yang gagal ditangkap oleh TCP.
* **Kesalahan Pengontrol Penyimpanan:** Bug perangkat keras pada pengontrol RAID atau fabric SAN dapat menulis data sampah sambil melaporkan keberhasilan ke OS.

Kerusakan Logis

Kerusakan logis bisa dibilang lebih berbahaya karena file cadangan itu sendiri utuh sepenuhnya, tetapi data di dalamnya rusak.
* Sampah Masuk, Sampah Keluar (GIGO): Jika basis data langsung Anda memiliki indeks yang rusak atau halaman yang sobek, alat pencadangan Anda mungkin menyalin halaman yang rusak tersebut dengan setia. Pekerjaan pencadangan berhasil, tetapi pemulihan akan gagal atau menghasilkan basis data yang rusak.
* Transaksi Tidak Lengkap: Snapshot tingkat sistem file yang diambil tanpa membekukan I/O basis data dengan benar (misalnya, tidak menggunakan FLUSH TABLES WITH READ LOCK di MySQL) mengakibatkan halaman yang sobek dan status yang tidak dapat dipulihkan.

Deteksi Proaktif: Checksum dan Hashing Kriptografis

Garis pertahanan pertama terhadap kerusakan fisik adalah validasi kriptografis. Mengandalkan ukuran file atau tanggal modifikasi saja tidak cukup.

Mengaktifkan Checksum Tingkat Basis Data

Sistem manajemen basis data relasional (RDBMS) modern mendukung checksum tingkat halaman. Saat diaktifkan, basis data menghitung checksum untuk setiap halaman sebelum menulisnya ke disk. Saat halaman dibaca (baik oleh kueri atau proses pencadangan), checksum diverifikasi.

Untuk PostgreSQL, Anda dapat mengaktifkan checksum data selama inisialisasi klaster:

# Inisialisasi klaster PostgreSQL baru dengan checksum diaktifkan
initdb --data-checksums -D /var/lib/postgresql/data

Catatan: Jika Anda memiliki klaster PostgreSQL yang sudah ada, Anda dapat menggunakan utilitas pg_checksums untuk mengaktifkannya secara offline.

Untuk Microsoft SQL Server, pastikan PAGE_VERIFY diatur ke CHECKSUM (default pada versi modern, tetapi perlu diverifikasi pada sistem lama):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

Memvalidasi Cadangan Saat Diam

Setelah cadangan mendarat di target penyimpanan Anda, integritasnya harus diverifikasi secara kriptografis. Platform pencadangan perusahaan seperti CloudSave secara otomatis menghitung dan memverifikasi hash SHA-256 dari blok cadangan selama transit dan saat diam. Jika Anda mengelola skrip kustom, Anda harus mengimplementasikannya secara manual:

# Hasilkan hash SHA-256 setelah pembuatan cadangan
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# Verifikasi hash pada server penyimpanan
sha256sum -c prod_db_backup.tar.gz.sha256

Teknik Validasi Khusus Basis Data

Mesin basis data yang berbeda menawarkan alat asli untuk memverifikasi integritas artefak cadangan mereka.

PostgreSQL: pg_verifybackup

Diperkenalkan di PostgreSQL 13, pg_verifybackup adalah pengubah permainan untuk cadangan fisik yang diambil dengan pg_basebackup. Alat ini membaca file backup_manifest yang dihasilkan selama pencadangan dan memverifikasi bahwa semua file ada dan checksum-nya cocok.

# Jalankan verifikasi terhadap direktori cadangan dasar fisik
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

Jika satu bit saja berubah di salah satu file data, pg_verifybackup akan memberikan kesalahan fatal, yang memungkinkan sistem pemantauan Anda untuk segera memberi tahu tim DBA.

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server menyediakan perintah asli untuk memverifikasi integritas fisik file cadangan tanpa benar-benar memulihkannya. Perintah ini memeriksa header cadangan dan memvalidasi checksum halaman (jika diaktifkan selama pencadangan).

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

Peringatan: RESTORE VERIFYONLY hanya mengonfirmasi bahwa file cadangan dapat dibaca dan checksum fisik cocok. Hal ini tidak menjamin integritas logis. Untuk memastikan integritas logis, Anda harus melakukan pemulihan penuh dan menjalankan DBCC CHECKDB.

MySQL / InnoDB: Percona XtraBackup

Untuk lingkungan MySQL, cadangan fisik sering kali ditangani oleh Percona XtraBackup. Proses pencadangan terdiri dari penyalinan file, tetapi cadangan tidak konsisten sampai log transaksi (redo logs) diterapkan. Fase --prepare bertindak sebagai pemeriksaan integritas bawaan.

# Menyiapkan cadangan menerapkan redo logs. 
# Jika cadangan rusak, langkah ini akan gagal.
xtrabackup --prepare --target-dir=/data/backups/mysql/

Standar Emas: Pengujian Pemulihan Otomatis

Checksum dan perintah verifikasi memang diperlukan, tetapi tidak cukup. Satu-satunya cara untuk membuktikan secara definitif bahwa cadangan layak digunakan adalah dengan memulihkannya. Dalam lingkungan DevOps modern, proses ini harus sepenuhnya otomatis.

Dengan memperlakukan cadangan sebagai kode, Anda dapat membangun saluran CI/CD untuk pemulihan basis data Anda. Saluran ini harus menyediakan infrastruktur sementara, menjalankan pemulihan, menjalankan kueri validasi, dan menghapus lingkungan tersebut.

Membangun Saluran Pemulihan Otomatis

Di bawah ini adalah contoh skrip Bash yang dapat dipicu setiap hari oleh cron job atau CI runner (seperti GitLab CI atau GitHub Actions) untuk memvalidasi dump logis PostgreSQL.

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] Memulai Uji Pemulihan Otomatis..."

# 1. Jalankan kontainer PostgreSQL sementara
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# Tunggu PostgreSQL siap
echo "[INFO] Menunggu basis data untuk diinisialisasi..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. Buat basis data target
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. Jalankan pemulihan
echo "[INFO] Memulihkan cadangan..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# 4. Jalankan Kueri Validasi Logis
echo "[INFO] Menjalankan kueri validasi..."
# Periksa apakah tabel pengguna memiliki lebih dari 10.000 catatan
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] Validasi logis gagal. Diharapkan >10000 pengguna, ditemukan $USER_COUNT"
    # Picu peringatan PagerDuty / Slack di sini
    exit 1
else
    echo "[SUCCESS] Validasi logis berhasil. Jumlah pengguna: $USER_COUNT"
fi

# 5. Hapus lingkungan sementara
echo "[INFO] Membersihkan..."
docker rm -f $CONTAINER_NAME

echo "[INFO] Uji Pemulihan Otomatis Berhasil Diselesaikan."

Apa yang Harus Anda Validasi?

Saat melakukan pengujian pemulihan otomatis, jangan hanya memeriksa apakah basis data dimulai. Jalankan kueri validasi khusus aplikasi:
1. Jumlah Baris: Pastikan tabel inti memiliki jumlah baris yang diharapkan (misalnya, tabel users tidak boleh kosong).
2. Data Terbaru: Kueri untuk catatan yang dibuat dalam 24 jam terakhir untuk memastikan cadangan tidak basi.
3. Integritas Referensial: Jalankan skrip untuk memeriksa kunci asing yang yatim piatu, yang menunjukkan kerusakan logis.

Pemantauan dan Peringatan untuk Anomali Cadangan

Mendeteksi kerusakan sebelum bencana terjadi memerlukan observabilitas yang kuat. Di luar status keberhasilan/kegagalan biner, Anda harus memantau metadata pekerjaan pencadangan Anda untuk mendeteksi anomali.

Pemantauan Heuristik

Integrasikan metadata pencadangan Anda ke dalam Prometheus dan visualisasikan dengan Grafana. Siapkan peringatan untuk heuristik berikut:
* Penurunan Ukuran Mendadak: Jika cadangan harian Anda secara konsisten berukuran 500GB, dan cadangan hari ini berukuran 50MB, pekerjaan mungkin telah selesai dengan sukses (Exit Code 0), tetapi kemungkinan besar mencadangkan skema kosong.
* Anomali Durasi: Jika cadangan yang biasanya memakan waktu 2 jam selesai dalam 5 menit, ada sesuatu yang terlewat. Sebaliknya, jika memakan waktu 10 jam, Anda mungkin mengalami degradasi I/O disk yang dapat menyebabkan kerusakan.
* Akumulasi WAL/Archive Log: Jika basis data Anda menghasilkan Write-Ahead Logs (WAL) tetapi sistem pencadangan tidak mengarsipkannya cukup cepat, Anda berisiko mengalami celah dalam rantai Point-in-Time Recovery (PITR) Anda.

Menerapkan Aturan 3-2-1 dengan Pemeriksaan Integritas

Aturan pencadangan 3-2-1 standar industri (3 salinan data, 2 media berbeda, 1 di luar lokasi) hanya efektif jika semua salinan diverifikasi.

Di sinilah memanfaatkan solusi perusahaan seperti CloudSave secara drastis mengurangi overhead operasional. Alih-alih menulis dan memelihara skrip bash yang kompleks untuk setiap node basis data, CloudSave berintegrasi langsung dengan infrastruktur Anda untuk mengotomatiskan siklus hidup 3-2-1. Ini menyediakan penyimpanan yang tidak dapat diubah—melindungi dari ransomware—dan fitur jadwal verifikasi pemulihan otomatis bawaan. CloudSave dapat secara otomatis menjalankan lingkungan sandbox terisolasi, memasang cadangan, menjalankan skrip validasi SQL kustom Anda, dan melaporkan status kesehatan kembali ke dasbor pusat Anda.

Kesimpulan

Cadangan basis data yang rusak adalah pembunuh senyap yang dapat menghancurkan bisnis. Mengandalkan semata-mata pada Exit Code 0 dari skrip pencadangan adalah perjudian yang berbahaya.

Untuk benar-benar melindungi lingkungan produksi Anda, Anda harus mengadopsi strategi pertahanan mendalam:
1. Aktifkan checksum tingkat halaman di dalam mesin basis data Anda.
2. Gunakan alat verifikasi asli (pg_verifybackup, RESTORE VERIFYONLY) segera setelah pembuatan cadangan.
3. Pantau metadata cadangan (ukuran, durasi) untuk anomali heuristik.
4. Implementasikan pengujian pemulihan otomatis sebagai bagian dari saluran operasional harian Anda.

Dengan beralih dari mentalitas pencadangan pasif “pasang dan lupakan” ke model “validasi pemulihan berkelanjutan” yang aktif, Anda memastikan bahwa ketika bencana tak terelakkan terjadi, data Anda siap, andal, dan dapat dipulihkan sepenuhnya.

Kategori