Database Administration:

The Complete Guide to

Practices and Procedures
Chapter 15: Database Backup and Recovery

Your Date Here Clarissa Luthfia Rachmad (H96218054)

Daftar Isi
1. Preparing for Problems
2. Image Copy Backups
3. Recovery
4. Alternatives to Backup and Recovery

Your Date Here Your Footer Goes Here 2

1. Preparing for Problems
Bereaksi terhadap kegagalan dan gangguan layanan adalah komponen utama
dari pekerjaan DBA. Kemampuan DBA untuk bereaksi sesuai tergantung
langsung pada keinginannya untuk memiliki rencana yang baik pendekatan
untuk pencadangan dan pemulihan basis data.
Banyak bahaya harian dapat menyebabkan kegagalan sistem. Saat Anda
merencanakan pencadangan dan pemulihan basis data Anda strategi, pastikan
untuk mempertimbangkan semua berbagai ancaman ini terhadap integritas
dan ketersediaan basis data. Dari tentu saja, bijaksana untuk mengambil
tindakan pencegahan untuk mencegah kegagalan.
Adalah umum bagi organisasi untuk mengelola satu terabyte atau lebih data
pada satu basis data server.
 LANJUTAN
Kegagalan basis data yang mungkin memerlukan pemulihan dapat dibagi menjadi
tiga kategori:
• Kegagalan instan adalah hasil pengecualian internal dalam DBMS, operasi
kegagalan sistem, atau kegagalan basis data terkait perangkat lunak lainnya.
• Kegagalan aplikasi (atau transaksi) terjadi ketika program atau skrip dijalankan
dengan cara yang salah waktu, menggunakan input yang salah, atau dalam urutan
yang salah. Kegagalan aplikasi biasanya menghasilkan data korup yang
membutuhkan pemulihan atau pemulihan basis data.
• Kegagalan media kemungkinan juga akan merusak data. Kegagalan media
termasuk kerusakan pada penyimpanan disk perangkat, kegagalan sistem file,
degradasi atau kerusakan pita, dan file data yang dihapus. Meskipun kurang
umum dalam prakteknya, chip memori yang rusak juga dapat menyebabkan
korupsi data. Setelah kegagalan media, database kemungkinan akan berada dalam
keadaan di mana data yang valid tidak dapat dibaca, tidak valid data dapat
dibaca, atau integritas referensial dilanggar. 
 2. Image Copy Backups
Komponen mendasar dari cadangan database dan rencana pemulihan adalah
membuat salinan cadangan data. Ketika terjadi kesalahan yang merusak integritas
database, salinan cadangan data bisa digunakan sebagai dasar untuk memulihkan
atau mengembalikan basis data. Mencadangkan basis data mencakup membuat
salinan data secara konsisten, biasanya dalam bentuk gambar salinan Untuk
memutuskan frekuensi yang digunakan untuk membuat cadangan objek database,
pertimbangkan berapa banyak waktu akan diperlukan untuk memulihkan objek
itu. Durasi pemulihan ditentukan oleh faktor-faktor seperti
• Jumlah catatan log yang harus diproses untuk pulih
• Apakah log dipadatkan atau dikompresi
• Waktu yang dibutuhkan operator untuk memasang dan melepas kaset yang
diperlukan
• Waktu yang diperlukan untuk membaca bagian dari log yang diperlukan untuk
pemulihan
• Waktu yang dibutuhkan untuk memproses ulang halaman yang diubah
Selain itu, durasi pemulihan tergantung pada arsitektur DBMS.
 LANJUTAN
DBA harus memutuskan berapa banyak generasi cadangan yang lengkap (untuk kedua salinan objek basis data
dan mencatat salinan) untuk disimpan.Pedoman berikut tentang membuat cadangan salinan gambar akan
membantu memastikan lingkungan yang dapat dipulihkan.
• Buat setidaknya dua salinan lokal dari setiap cadangan salinan gambar untuk membantu menghindari yang
tidak dapat dipulihkan status dalam kasus kesalahan media  
• Koordinasikan strategi cadangan lokal Anda dengan strategi cadangan pemulihan bencana Anda. Banyak
utilitas cadangan memungkinkan cadangan lokal dan luar kantor dibuat secara bersamaan.
• Simpan setidaknya dua generasi cadangan salinan gambar untuk setiap objek basis data
• Pertimbangkan untuk membuat cadangan salinan gambar ke disk, dan kemudian memigrasikannya ke tape,
yang bisa mempercepat proses penyalinan gambar.
• Ketika cadangan salinan gambar dimigrasikan ke tape, pertimbangkan untuk mengompresi file untuk
mengurangi jumlah kaset yang dibutuhkan untuk menyalin file cadangan gambar besar. Ini biasanya bisa
dicapai dengan menggunakan fasilitas tape drive.
• Pastikan untuk memasukkan objek basis data katalog sistem ke dalam cadangan dan paket pemulihan Anda.
• Pastikan proses pencadangan dapat dimulai kembali. 
• Setelah cadangan selesai, gunakan fasilitas DBMS untuk memverifikasi kebenaran cadangan
• Data yang tidak disimpan dalam database, tetapi digunakan oleh aplikasi database, harus didukung pada saat
yang sama dengan objek database.
Seringkali merupakan keputusan bijak untuk mengambil cadangan salinan gambar penuh dari objek database.
2.1 Cadangan Penuh vs Tambahan
Ada dua jenis cadangan salinan gambar yang dapat diambil: penuh dan inkremental. Sebuah salinan gambar full
backup adalah salinan lengkap dari semua data dalam objek database pada saat salinan gambar
dijalankan. Sebuah tambahan copy gambar cadangan, kadang-kadang disebut sebagai diferensial
cadangan, hanya berisi data yang telah berubah sejak salinan gambar penuh atau inkremental terakhir
terbuat. Keuntungan dari mengambil incremental backup daripada full backup adalah bisa kadang-kadang
dibuat lebih cepat, dan menempati lebih sedikit ruang pada disk atau tape. Kerugiannya adalah bahwa
pemulihan berdasarkan salinan tambahan dapat memakan waktu lebih lama karena, dalam beberapa kasus, baris
yang sama diperbarui beberapa kali sebelum perubahan terakhir dipulihkan. Beberapa DBMS menyediakan
kemampuan untuk menganalisis objek database untuk menentukan apakah suatu database penuh atau tidak
cadangan tambahan direkomendasikan atau diperlukan. Ini biasanya dilakukan menggunakan opsi utilitas
salin. Jika opsi semacam itu ada, DBA dapat menjalankan utilitas salin untuk memeriksa jumlah data yang telah
berubah sejak cadangan salinan gambar terakhir diambil. Selanjutnya, DBA dapat mengatur a ambang batas
sehingga salinan gambar penuh diambil ketika lebih dari jumlah data tertentu berubah; salinan gambar
tambahan diambil ketika jumlah data yang telah berubah kurang dari ambang batas. Ketika opsi ini tidak
tersedia, DBA perlu mengatur jenis salinan gambar backup harus diambil berdasarkan pengetahuannya tentang
aplikasi dan penggunaannya atas database.DBA membuat ini penentuan didasarkan tidak hanya pada volatilitas
data tetapi juga pada faktor-faktor seperti kekritisan data, persyaratan ketersediaan, dan fungsionalitas
DBMS.Mendukung salinan gambar penuh untuk objek basis data kecil.Beberapa skenario tidak kompatibel
dengan cadangan salinan gambar tambahan.
2.2 Menggabungkan Salinan Tambahan
Jika DBMS mendukung cadangan salinan gambar tambahan, itu juga dapat
mendukung salinan tambahan penggabungan. Utilitas penggabungan, kadang-
kadang disebut sebagai MERGECOPY, dapat digunakan untuk menggabungkan
beberapa cadangan salinan gambar inkremental menjadi cadangan salinan
inkremental tunggal, atau untuk menggabungkan gambar penuh salin cadangan
dengan satu atau lebih cadangan salinan gambar tambahan untuk membuat
cadangan lengkap baru.
2. 3 Objek dan Cadangan Basis Data
Cadangan salinan gambar dibuat di tingkat basis data, tablespace, atau tabel.
2.4 Index Salinan
perlu memeriksa timbal balik dari indeks penyalinan.
2.5 Control DBMS
Beberapa DBMS tidak mencatat informasi cadangan dan pemulihan dalam katalog
sistem.
 2.6 Masalah Akses Bersamaan
DBA harus memahami kemampuan cadangan setiap DBMS dalam organisasi dan merencanakan
strategi cadangan yang tepat yang mempertimbangkan
• Kebutuhan untuk akses bersamaan dan modifikasi selama proses pencadangan
• Jumlah waktu yang tersedia untuk proses pencadangan dan dampak akses bersamaan kecepatan
mencadangkan data
• Kecepatan utilitas pemulihan
• Kebutuhan akan akses ke log basis data
Beberapa DBMS menggunakan istilah cadangan panas dan cadangan dingin untuk menjelaskan
akses bersamaan yang dapat dilakukan terjadi saat data sedang dicadangkan. Cadangan dingin
diselesaikan dengan mematikan contoh basis data dan membuat cadangan file database yang
relevan. Cadangan panas dilakukan saat contoh database tetap online, artinya akses bersamaan
dimungkinkan. cadangan panas bisa bermasalah karena
• Mereka bisa lebih kompleks untuk diterapkan.
• Mereka dapat menyebabkan overhead tambahan dalam bentuk CPU yang lebih tinggi, I / O
tambahan, dan arsip log basis data tambahan.
• Mereka dapat meminta DBA untuk membuat skrip khusus situs untuk melakukan cadangan panas.
• Mereka membutuhkan pengujian ekstensif untuk memastikan bahwa cadangan layak untuk
pemulihan.
2.7 Konsistensi pencadangan
Pastikan paket cadangan Anda membuat titik pemulihan yang konsisten untuk objek basis data. Untu
memastikan konsistensi cadangan, Anda harus menyadari semua hubungan antara objek database sedang
dicadangkan dan objek database lainnya. Ini termasuk hubungan yang diberlakukan aplikasi, kendala
referensial, dan pemicu.

2.7.1 Kapan Membuat Titik Konsistensi

ika memungkinkan, DBA harus menciptakan titik konsistensi selama pemrosesan harian. Sebuah titik
konsistensi dapat berguna jika pemulihan point-in-time diperlukan. Anda harus mempertimbangkan untuk
membuat titik konsistensi dalam situasi berikut:
• Sebelum mengarsipkan log aktif.
• Sebelum menyalin objek database terkait.
• Hanya setelah membuat cadangan salinan gambar.
• Tepat sebelum modifikasi database yang berat
• Selama masa tenang.
DBA harus menciptakan titik konsistensi selama pemrosesan harian.

2.8 Pengarsipan dan Pencadangan Log

DBA biasanya mengontrol frekuensi proses pengarsipan log.
 2.9 Menentukan Jadwal Cadangan
Tidak semua data dibuat sama. Beberapa database dan tabel Anda berisi data yang diperlukan untuk inti dari bisnis
Anda. Objek database lain berisi data yang kurang kritis atau mudah didapat sumber lain. Sebelum Anda dapat mengatur
strategi dan jadwal cadangan yang layak, Anda perlu menganalisis database dan data Anda untuk menentukan sifat dan
nilainya bagi bisnis. Untuk melakukannya, jawab mengikuti pertanyaan untuk setiap objek basis data. Nilai setiap objek
basis data dalam hal kritikalitas dan volatilitasnya.

2.10 Cadangan Instance DBMS

Selain dipersiapkan untuk kegagalan objek database individual, DBA harus dipersiapkan untuk itu pulih dari kegagalan
seluruh instance atau subsistem DBMS. Pastikan untuk mendukung semua yang penting komponen instance database,
termasuk file DBMS, katalog sistem dan objek direktori, database (arsip) log, konfigurasi dan pengaturan file, pustaka
sistem, pustaka manajemen tape, pustaka sumber program, dan pustaka yang dapat dieksekusi

2.11 Merancang Lingkungan DBMS untuk Pemulihan

Mengalokasikan log database yang berlebihan.

2.12 Pendekatan Alternatif untuk Pencadangan Database

Metode cadangan yang dibahas sejauh ini telah mengambil file data fisik untuk objek database dan menyalinnya kata
demi kata (atau hampir kata demi kata) ke perangkat cadangan. Namun, pendekatan lain juga bisa
digunakan. Pendekatan-pendekatan ini seharusnya dianggap sebagai prosedur khusus untuk digunakan hanya dalam
keadaan tertentu.
 2.12.1 Menggunakan Ekspor Basis Data untuk
Membuat Cadangan yang Logis
Pendekatan alternatif untuk pemulihan basis data adalah membuat ekspor, atau bongkar, dari data
yang disimpan di objek basis data. Terkadang proses mencadangkan hanya data, dan bukan
seluruh file fisik, adalah disebut sebagai cadangan logis. Dalam hal seperti berikut ini, cukup
berguna untuk menggunakan logika backup:
• Pemulihan objek atau baris.
• Peningkatan rilis DBMS
• Migrasi database yang heterogen. 
• Pergerakan data.
Cadangan logis dilakukan dengan database aktif dan berjalan, sehingga hanya berdampak pada
kinerja akan menjadi kemungkinan akses bersamaan ke data melalui transaksi dan program
produksi lainnya. Namun, sebagai DBA, Anda harus mengingat integritas data cadangan
logis. walaupunDBMS akan menggunakan mekanisme pengunciannya untuk memastikan data
yang konsisten, integritas referensial tidak dijamin kecuali ada upaya untuk menghentikan
aktivitas bersamaan selama proses ekspor data. Gunakan cadangan logis untuk melengkapi
strategi cadangan fisik Anda. Pembuatan cadangan logis yang teratur dapat melengkapi strategi
cadangan fisik Anda.
2.12.2 Menggunakan Perangkat Lunak
Manajemen Penyimpanan untuk Membuat Salinan
Cadangan
Perlakuan khusus terhadap file database diperlukan saat membuat cadangan
dengan manajemen penyimpanan perangkat lunak.
2.12.3 Dokumentasikan Strategi Cadangan Anda
Jadwalkan evaluasi berkala cadangan dan rencana pemulihan untuk setiap
produksi basis data.
2.13 Cadangan Definisi Objek Basis Data
Selain mencadangkan data secara teratur, DBA harus mempertimbangkan
untuk mencadangkan basis data secara teratur definisi objek. Definisi objek
basis data dapat berubah seiring waktu ketika parameter diubah dan diubah. 
.
 3. Recovery
Pemulihan basis data bisa menjadi tugas yang sangat kompleks. Pemulihan
melibatkan lebih dari sekadar mengembalikan gambar data seperti yang terlihat di
beberapa titik waktu sebelumnya. Pemulihan basis data akan melibatkan
mengembalikan data ke statusnya di (atau sebelum) waktu masalah. Seringkali
pemulihan melibatkan mengembalikan database dan kemudian menerapkan
kembali perubahan yang benar yang terjadi pada database itu dalam urutan yang
benar.
3.1 Menentukan Opsi Pemulihan
Selidiki rincian cadangan dan pemulihan untuk setiap versi DBMS baru
sebelumnya migrasi.Tentu saja, ini hanya beberapa pertanyaan yang harus
disiapkan DBA untuk dijawab memulihkan objek database secara efektif. Selain
itu, DBA perlu memahami semua detail khusus untuk DBMS yang digunakan
3.2 Langkah Umum untuk Pemulihan
Objek Database
1. Identifikasi kegagalannya.
2. Analisis situasinya. 
3. Tentukan apa yang perlu dipulihkan.
4. Identifikasi dependensi antara objek database yang akan dipulihkan. 
5. Temukan cadangan salinan gambar yang diperlukan.
6. Kembalikan cadangan salinan gambar.
7. Gulir maju melalui log basis data. 
3.3 Jenis Pemulihan
Jenis pemulihan pertama pulih ke saat ini.
Pemulihan ke titik waktu menghilangkan efek dari semua
transaksi yang telah terjadi sejak itu titik waktu yang
ditentukan.
emulihan PIT yang digambarkan dapat dilakukan dalam satu
dari dua cara, tergantung pada fitur-fitur DBMS dan jumlah
data yang akan dipulihkan. Itu bisa:
• Kembalikan salinan gambar dengan menggulir maju melalui log dan menerapkan basis data
berubah hingga titik pemulihan.
• Tidak mengembalikan salinan gambar, sebaliknya menggulung mundur melalui log dan menghapus
perubahan basis data yang terjadi setelah titik pemulihan.
ika DBMS mendukung kedua jenis pemulihan, DBA harus
memilih untuk menggunakan yang membuat paling tidak
downtime. Jika sejumlah besar perubahan perlu dihapus, maka
kembalikan dan gulung maju biasanya menghasilkan downtime paling sedikit. Perangkat lunak pihak ketiga
diperlukan untuk melakukan pemulihan transaksi. Sejumlah masalah seperti berikut ini dapat terjadi di tingkat
aplikasi.
• Edit-cek dalam program atau database tidak didefinisikan dengan benar atau mengandung bug.
• Seseorang mengubah perangkat lunak penjadwalan pekerjaan atau tidak memeriksa kode penyelesaian yang
valid, jadi proses tertentu kehabisan urutan, menyebabkan masalah data.
• Kode yang diuji tidak memadai mengenai produksi.
• Bug dalam perangkat lunak sistem.
Setelah Anda mengidentifikasi transaksi yang akan dipulihkan, Anda memiliki tiga opsi pemulihan:
• pemulihan PIT.
• pemulihan UNDO.
• REDO recovery.
Pemulihan bencana di luar lokasi adalah jenis pemulihan basis data yang paling komprehensif.
Pertama mari kita periksa pemulihan UNDO. Pemulihan UNDO adalah versi paling sederhana berbasis SQL
pemulihan transaksi karena hanya melibatkan SQL. Untuk mencapai pemulihan UNDO, database llog harus
dipindai untuk transaksi yang diidentifikasi dan anti-SQL diproduksi. Anti-SQL membalikkan
pengaruh SQL oleh
• Konversi sisipan ke dalam penghapusan
• Konversi menghapus menjadi sisipan
• Membalikkan nilai-nilai pembaruan
Pemulihan REDO adalah kombinasi dari pemulihan PIT dan
pemulihan UNDO, dengan twist. Berbeda dengan proses UNDO,
yang menciptakan pernyataan SQL yang dirancang untuk
mendukung semua masalah transaksi, proses REDO membuat
pernyataan SQL yang dirancang untuk mengajukan kembali hanya
valid transaksi dari titik waktu yang konsisten. Karena proses
REDO tidak menghasilkan SQL untuk masalah transaksi,
melakukan pemulihan dan kemudian mengeksekusi REDO SQL
dapat mengembalikan objek database ke keadaan saat ini yang
tidak termasuk masalah transaksi.Ketika mengulang transaksi di
lingkungan di mana ketersediaan sangat penting,
1. Lakukan pemulihan ke titik waktu.
2. Bawa aplikasi dan database online.
3. Ulangi transaksi valid berikutnya untuk menyelesaikan pemulihan. Langkah ini harus dilakukan sementara
database online untuk operasi baca / tulis bersamaan.
 3.4 Memilih Strategi Pemulihan Optimal
Kesalahan pengguna dan kegagalan aplikasi adalah alasan paling umum untuk pemulihan basis data dan
karenanya menjadi penyebab utama sistem tidak tersedianya. alam menentukan jenis pemulihan yang akan
dilakukan, DBA harus mempertimbangkan beberapa pertanyaan:
• Identifikasi Transaksi. 
• Integritas Data.
• Kecepatan.
• Ketersediaan. 
• Ketidakaktifan. 
Banyak faktor yang mempengaruhi lamanya proses pemulihan. DBA dapat menerapkan langkah-langkah untuk
mengurangi downtime dengan mengembangkan cadangan cerdas dan rencana pemulihan. Faktor-faktor berikut
bisa mempersingkat durasi pemulihan.
• Semakin kecil ukuran komponen yang perlu dipulihkan, semakin pendek pemulihannya proses akan.
• Pertimbangkan mempartisi objek basis data dan mencadangkan dan memulihkan pada tingkat partisi.
• Pertimbangkan untuk menyimpan cadangan salinan gambar dan mencatat file arsip pada disk.
• Uji cadangan salinan gambar Anda untuk memastikan valid
• Otomatis prosedur pencadangan dan pemulihan sejauh mungkin.
• Kapan pun memungkinkan, rancang basis data dengan sesedikit mungkin dependensi.
• Terakhir, pastikan bahwa setiap DBA memahami prosedur pemulihan untuk setiap basis data objek di bawah
kendalinya.
3.5 Mencocokkan Jenis Kegagalan dengan
Jenis Pemulihan
Menyesuaikan jenis kegagalan dengan jenis pemulihan yang sesuai adalah praktik yang baik
Memulihkan dari kegagalan media biasanya melibatkan pemulihan ke saat ini. Ketika media
gagal, maka objek basis data yang berada di media itu kemungkinan besar tidak akan dapat
diakses atau diubah. Itu keinginan umum dalam situasi seperti ini adalah untuk memulihkan
semua objek database pada media yang gagal ke titik sesaat sebelum kegagalan — dengan kata
lain, DBA akan mencoba memulihkan semua aktivitas dan data untuk iniobjek basis data.
Memulihkan dari kegagalan transaksi biasanya melibatkan pemulihan point-in-time atau
transaksi pemulihan. Menurut definisi, pemulihan transaksi disebabkan oleh eksekusi yang
salah atau tidak benar dari program. Perubahan basis data yang dihasilkan dari program yang
dijalankan dengan tidak benar harus dihapus semua objek basis data yang terpengaruh.
Memulihkan dari instance database atau kegagalan subsistem kemungkinan besar akan
melibatkan pemulihan arus. Tujuan dari pemulihan semacam itu adalah untuk membawa data
dalam semua objek database dalam instance atau subsistem kembali seperti semula sebelum
titik kegagalan, dan dalam keadaan konsisten.
3.6 Pemulihan Index
ada dua opsi untuk indeks pemulihan:
• Membangun kembali indeks dari data tabel
• Memulihkan indeks dari salinan cadangan indeks itu sendiri
Metode pemulihan indeks harus dipilih ketika metode pemulihan tablespace adalah terpilih.

3.7 Menguji Rencana Pemulihan

Kembangkan rencana pemulihan dan sering-seringlah mengujinya.
Untuk mengembangkan rencana pemulihan Anda:
• Tuliskan semua aspek rencana pemulihan secara rinci, dokumentasikan setiap langkah.
• Sertakan semua skrip yang diperlukan untuk mencadangkan dan memulihkan setiap objek basis data.
• Tinjau rencana dengan semua orang yang dapat dipanggil untuk mengimplementasikannya.
• Sertakan daftar kontak dengan nama dan nomor telepon semua orang yang mungkin terlibat pemulihan.
• Tetap perbarui rencana pemulihan dengan memodifikasi rencana untuk memasukkan setiap basis data baru
objek yang dibuat.

3.8 Memulihkan Objek Database yang Jatuh

Memulihkan objek yang jatuh membutuhkan langkah-langkah tambahan di luar pemulihan normal. Tergantung
pada DBMS dan alat yang tersedia, kadang-kadang bisa sangat rumit.
3.9 Memulihkan Blok dan Halaman yang
Rusak
Blok atau halaman yang rusak adalah bagian dari tablespace atau indeks yang
berisi data yang buruk atau tidak konsisten.Data mungkin tidak konsisten
karena rantai yang rusak atau yatim piatu, pelanggaran batasan referensial, log
pemulihan yang rusak, entri indeks yang hilang atau ekstra, atau beberapa
masalah misterius lainnya. Untuk memulihkan indeks dengan halaman yang
rusak Anda hanya dapat membangun kembali indeks dari data di tablespace.
3.10 Mengisi Basis Data Uji
Populasikan lingkungan pengujian dengan cadangan basis data produksi.
Membuat sistem pengujian dari database produksi dapat memaksakan
persyaratan spesifik pada struktur dan waktu cadangan produksi, serta struktur
lingkungan pengujian
4. Alternatives to Backup and Recovery
Penciptaan cadangan salinan gambar untuk pemulihan adalah metode yang paling umum dan dapat
diandalkan mengasuransikan terhadap kegagalan dan kehilangan data. Namun, ada beberapa alternatif
yang menambah atau mungkin ganti metode pencadangan dan pemulihan standar. Beberapa bagian
berikutnya secara singkat memeriksa beberapa dari alternatif ini.

4.1 Database Siaga

Database siaga cukup mudah diimplementasikan.Database siaga bisa ideal untuk pemulihan bencana.

4.2 Replikasi
Replikasi data melibatkan penyimpanan dan pemeliharaan data yang berlebihan dalam salinan terpisah
dari database. Beberapa DBMS menyediakan fitur replikasi otomatis.
Ada dua teknologi dasar untuk mereplikasi data di antara basis data:
1. Replikasi snapshot menghasilkan salinan tabel database pada sistem target berdasarkan permintaan
basis data sumber
2. Replikasi simetris adalah implementasi replikasi yang lebih kuat karena menjaga replika mutakhir.
Replikasi bukan pengganti cadangan dan pemulihan.

4.3 Disk Mirroring

Disk mirroring dapat menghilangkan kebutuhan untuk memulihkan dari kegagalan media.