Backup & Recovery System. Teknik Informatika

Transkripsi

1 Backup & Recovery System Teknik Informatika

2 Adi Nanda Saputra Adam Fadilla Bayu Dwi Yulianto H1D H1D H1D Satria Kries Budiarto H1D Adrian Dwinanda A. H1D M. Aufar Hibatullah H1D Adi Permana Putra Pradana Nirwana Axl Adilla H1D H1D H1D016019

3 Failure Classification Transaction failure System crash Disk failure

4 Transaction Failure Logical Error Transaksi tidak lagi dapat melanjutkan eksekusi normal karena beberapa kondisi internal, seperti input yang buruk, data tidak ditemukan, kelebihan arus, atau batas sumber daya terlampaui System Error Sistem telah memasuki keadaan yang tidak diinginkan (misalnya, deadlock), akibatnya transaksi tidak dapat dilanjutkan dengan eksekusi normal. Transaksi, bagaimanapun, dapat reexecuted di lain waktu.

5 System Crash Ada kerusakan perangkat keras, atau bug dalam perangkat lunak basis data atau sistem operasi, yang menyebabkan hilangnya konten penyimpanan yang mudah menguap, dan membuat proses transaksi terhenti. Konten penyimpanan non-volatile tetap utuh, dan tidak rusak. Asumsi bahwa kesalahan perangkat keras dan bug dalam peranti lunak membawa sistem ke data, tetapi tidak dapat merusak isi ulang data, yang dikenal sebagai asumsi gagal-berhenti. Sistem yang dirancang dengan baik dapat melakukan pemeriksaan internal, pada perangkat lunak dan piranti lunak, yang membawa sistem ke ketika ada kesalahan. Oleh karena itu, asumsi gagal-berhenti adalah salah satu yang masuk akal.

6 Disk Failure Blok disk kehilangan kontennya sebagai akibat dari kerusakan kepala atau kegagalan selama operasi transfer data. Pelacakan data pada disk lain, atau cadangan arsip pada media tersier, seperti DVD atau kaset, digunakan untuk memulihkan dari kegagalan.

7 Storage

8 Pengertian Storage adalah penyimpan, tempat penyimpanan, media yang digunakan untuk menyimpan data yang diolah oleh komputer. Fungsi storage adalah menyimpan data atau file dalam jangka panjang dan pendek.

9 Kategori Storage Jenis-jenis storage berdasarkan kecepatan relatif dan ketahanan terhadap kegagalan, antara lain : Volatile Storage, biasanya informasi yang terdapat pada volatile akan hilang, jika terjadi kerusakan sistem (system crash).co : RAM Non-Volatile Storage, biasanya informasi yang terdapat pada non volatile strorage tidak akan hilang jika terjadi kerusakan sistem. Co : ROM Stable Storage, informasi yang terdapat dalam stable storage tidak pernah hilang. Co Hardisk RAID

10 Implementasi Stable Storage Berdasarkan definisi, informasi yang berada di dalam stable storage tidak akan pernah hilang. Untuk mengimplementasikan storage seperti itu, kita perlu mereplikasiinformasi yang dibutuhkan ke banyak peralatan storage (biasanya disk-disk) dengan failure modes yang independen. Kita perlu mengkoordinasikan penulisan update-update dalam sebuah cara yang menjamin bila terjadi kegagalan selagi meng-updatetidak akan membuat semua kopi yang ada menjadi rusak, dan bila sedang recover darisebuah kegagalan, kita bisa memaksa semua kopi yang ada ke dalam keadaan yang bernilai benar dan konsisten, bahkan bila ada kegagalan lain yang terjadi ketika sedangrecovery. Untuk selanjutnya, kita akan membahas bagaimana kita bisa mencapaikebutuhan kita.

11 Implementasi Stable Storage Sebuah disk write menyebabkan satu dari tiga kemungkinan: Successful completion Data disimpan dengan benar di dalam disk. Partial failure Kegagalan terjadi di tengah-tengah transfer, menyebabkan hanya bebe rapasektor yang diisi dengan data yang baru, dan sektor yang diisi ketika terjadikegagalan menjadi rusak. Total failure Kegagalan terjadi sebelum disk write dimulai, jadi data yang sebe lumnya ada pada disk masih tetap ada.

12 Implementasi Stable Storage Kita memerlukan, kapan pun sebuah kegagalan terjadi ketika sedang menulis ke sebuah blok, system akan mendeteksinya dan memanggil sebuah prosedur recovery untuk me-restore blok tersebut ke sebuah keadaan yang konsisten. Untuk melakukan itu, sistem harus menangani dua blok physical untuk setiap blok logical.sebuah operasi output dieksekusi seperti berikut: Tulis informasinya ke blok physical yang pertama. Ketika penulisan pertama berhasil, tulis informasi yang sama ke blok physicalyang kedua. Operasi dikatakan berhasil hanya jika penulisan kedua berhasil.

13 Implementasi Stable Storage Pada saat recovery dari sebuah kegagalan, setiap pasang blok physi caldiperiksa. Jika keduanya sama dan tidak terdeteksi adanya kesalahan, tetapi berbedadalam isi, maka kita mengganti isi dari blok yang pertama dengan isi dari blok yangkedua. Prosedur recovery se perti ini memastikan bahwa sebuah penulisan ke stable storage akan sukses atau tidak ada perubahan sama sekali.kita bisa menambah fungsi prosedur ini dengan mudah untuk memboleh kan penggunaan dari kopi yang banyak dari setiap blok pada stable storage. Meski punsejumlah besar kopi semakin mengurangi kemungkinan untuk terjadinya sebuahkegagalan, maka biasanya wajar untuk men simulasi stable storage hanya dengan dua kopi. Data di dalam stable storage dijamin aman kecuali sebuah kegagalan menghancurkan semua kopi yang ada.

14 Recovery dan Atomicy

15 Recovery and Atomicity Ketika system crash, kemungkinan system sedang memproses beberapa proses transaksi dan membuka file untuk memodifikasi data. Transaksi terdiri dari berbagai operasi yang bersifat atomic secara alami. Tetapi berdasarkan ACID properti DBMS, atomicity dari transaksi semuanya harus dimaintain, yang berarti, semua operasi harus dieksekusi atau tidak sama sekali.

16 Ketika DBMS pulih dari crash, harus memaintain beberapa hal sebagai berikut : DMBS harus mengecek keadaan dari semua transaksi yang sedang di eksekusi. Tranksaksi mungkin sedang berada ditengah-tengah beberapa operasi; Dalam kasus inidbms harus memastikan atomicity dari transaksi. DBMS haru mengecek apaka transaksi bisa di finalisasi atau harus di rolled back. Tidak ada transaksi yang meninggalkan DBMS dalam keadaan inkonsisten.

17 Ada beberapa teknik untuk membantu DBMS dalam merecovery dan memaintain atomicity dari transaksi salah satunya yaitu : Memaintain log dari semua proses transaksi yang terjadi, dan menuliskannya kedalam penyimpanan yang stabil sebelum memodifikasi database.

18 Log Record Struktur yang paling banyak digunakan untuk merekam perubahan database adalah log. Log berisi record-record dari aktivitas yang terjadi di database, isi dari log file biasanya terdiri dari : Transaction identifier Data identifier Old value New value

19 How it work File log disimpan di penyimpanan yang stabil Ketika transaksi masuk kedalam sistem dan memulai eksekusi, akan tertulis di log sebagai : <Tn, Start> Ketika transaksi merubah nilai dari item X akan tertulis di log sebagai : <Tn, X, V1, V2> -> Tn telah merubah nilai X dari V1 ke V2 Ketika Transaksi selesai akan tertulis di log sebagai berikut : <Tn, commit>

20 Database Modification Suatu transaksi dikatakan memodifikasi database ketika ia melakukan update (perubahan) pada sebuah disk buffer, atau di dalam disk itu sendiri. Perubahan pada bagian khusus (private part) dari memori utama tidak termasuk modifkasi database. Terdapat dua teknik dalam modifikasi database; deferred-modification dan immediatemodification.

21 Teknik Deferred-Modification Cirinya: suatu transaksi tidak memodifikasi database sampai transaksi tersebut di-commit. Teknik ini mampu menyederhanakan beberapa aspek proses recovery, tapi membuat transaksi-transaksi harus membuat salinan lokal dari semua item data yang telah diperbaru; ketika suatu transaksi membaca sebuah item data yang telah diperbarui, ia harus membaca nilai dari salinan lokalnya.

22 Teknik Immediate- Modification Ciri: modifikasi database terjadi ketika transaksi masih aktif (berjalan). Artinya teknik ini memungkinkan untuk melakukan pembaruan (update) dari suatu transaksi yang belum di-commit ke dalam buffer/disk. Pembaruan catatan log harus di tulis sebelum item database ditulis Keluaran dari blok-blok yang telah diperbarui ke penyimpanan stabil dapat dilakukan kapan saja, sebelum maupun sesudah commit transaksi dengan urutan yang dapat berbeda dengan urutan masuk.

23 Contoh Immediate-Database- Modification

24 Concurrency Control and Recovery Dalam suatu transaksi yang konkuren (bersamaan), semua transaksi berbagi sebuah disk buffer dan sebuah log. sebuah blok buffer dapat memiliki item-item data yang diperbarui oleh satu atau lebih transaksi. Jika skema kontrok konkurensi mengijinkan item data X yang telah diperbarui oleh transaksi T1 untuk kemudian dimodifikasi oleh transaksi lain T2 sebelum T1 diikat (commit), maka melakukan undo efek T1 akan berefek pada T2. Untuk itu, algoritma pemulihan biasanya membuat aturan jika suatu item data dimodifikasi oleh suatu transaksi, tidak ada transakasi lain yang dapat memodifikasi data tersebut sebelum transaksi pertama diikat atau dibatalkan.

25 Concurrency Control and Recovery (cont.) Aturan tersebut dapat dipastikan dengan menggunakan kunci eksklusif (exclusive locks) pada item yang diperbarui dan menahan kuncinya sampai transaksi selesai. (disebut penguncian ketat dua fase/ strict twophase locking)

26 Transaction Commit Transaksi telah dilakukan ketika catatan catatan komitnya, yang merupakan catatan log terakhir dari transaksi, telah di-output ke penyimpanan stabil; Pada saat itu semua catatan log sebelumnya telah dioutput ke penyimpanan yang stabil. Dengan demikian, ada cukup informasi dalam log untuk memastikan bahwa bahkan jika ada sistem crash, pembaruan transaksi dapat diatur ulang. Jika sistem crash terjadi sebelum log record <T i commit> adalah output ke penyimpanan stabil, transaksi T i akan dibatalkan. Maka, output dari blok yang berisi catatan log komit adalah aksi atom tunggal yang menghasilkan transaksi Mendapatkan komitmen. Dengan sebagian besar teknik pemulihan berbasis log, blok yang berisi item data yang dimodifikasi oleh transaksi tidak harus di-output ke penyimpanan yang stabil ketika transaksi dilakukan, tetapi dapat menjadi keluaran beberapa waktu kemudian.

27 Undo Undo dari sebuah operasi <Ti, X, V1, V2> menulis nilai lama dari V1 ke X. Undo (Ti) mengembalikan nilai dari data yang terupdate oleh Ti ke nilai lama mereka, berjalan ke belakang dari log record terakhir untuk Ti. Setiap kali sebuah data X dikembalikan ke nilai lamanya V, sebuah log record spesial <Ti, X, V> ditambahkan. Ketika transaksi undo selesai, sebuah log record ditambahkan.

28 Redo Redo dari sebuah operasi <Ti, X, V1, V2> menulis nilai baru dari V2 ke X. Redo (Ti) men-set nilai dari data yang ter-update oleh Ti ke nilai baru mereka, berjalan ke depan dari log record pertama untuk Ti. Tidak ada log pada kasus ini.

29 Recovery dari Kegagalan Ketika Recovering setelah kegagalan: Transaksi Ti butuh di undo jika log: Memuat record <Ti start>, tapi Tidak memuat record <Ti commit>atau<ti abort>. Transaksi Ti butuh di redo jika log: Memuat record <Ti start>, dan memuat record <Ti commit>atau<ti abort>.

30 Catatan Jika transaksi Ti di-undo sebelumnya dan record <Ti abort> sudah tercatat ke log, dan kemudian kegagalan terjadi, saat recovery dari kegagalan maka Ti di redo. Redo seperti ini disebut juga mengulang sejarah ( repeating history). Menyederhanakan proses recovery.

31 Checkpoint Ketika terjadi kerusakan sistem, kita harus melihat log untuk menentukan penyebab kerusakan yang perlu diundo atau redo. Pada prinsipnya, perlu melihat seluruh log untuk menentukan informasi ini. Proses pencarian dalam seluruh log merupakan proses yang redudan.

32 Checkpoint (cont.) Checkpoint adalah tempat semua transaksi yang dilakukan ditulis ke log. Administrator basis data menentukan frekuensi checkpoint berdasarkan volume transaksi. Checkpoint yang terlalu sering dapat memengaruhi kinerja. Checkpoint yang terlalu sering akan menyebabkan waktu pemulihan yang lebih lama karena lebih banyak log yang harus diterapkan.

33 Checkpoint (cont.) Alur prosedur recovery dengan melakukan checkpoint secara berkala : 1. Output semua catatan log yang saat ini berada di memori utama ke penyimpanan yang stabil. 2. Output semua blok buffer yang dimodifikasi ke disk. 3. Menulis catatan log <checkpoint L> ke penyimpanan yang stabil di mana L adalah daftar semua transaksi yang aktif pada saat checkpoint. Semua pembaruan dihentikan saat melakukan checkpoint

34 Checkpoint (cont.) Selama recovery hanya perlu mempertimbangkan transaksi Ti yang dimulai sebelum checkpoint, dan transaksi yang dimulai setelah Ti. 1. Pindai log untuk menemukan catatan <Checkpoint L> terbaru. Hanya transaksi yang ada di L atau dimulai setelah checkpoint yang harus undo atau redo. Transaksi yang dilakukan atau dibatalkan sebelum checkpoint sudah memiliki semua output pembaruan dalam penyimpanan yang stabil. Beberapa bagian awal dari log mungkin diperlukan untuk membatalkan operasi. 1. Lanjutkan pemindaian hingga catatan <Ti start> ditemukan setiap transaksi Ti dalam L. Bagian-bagian dari log sebelum catatan <Ti start> tidak diperlukan dalam recovery, dan dapat dihapus kapan pun diinginkan.

35 Contoh Checkpoint

36 Backup dan Recovery

37 Backup Kerusakan terhadap disk (yang merupakan jenis media penyimpanan permanent yang paling umum), kerusakan data karena aktivitas pemakai ataupun kerusakan data oleh aplikasi eksternal, dapat diantisipasi dengan melakukan operasi backup secara periodik. Menjalankan operasi backup secara rutin merupakan tugas pengelolaan basis data yang penting.

38 Disamping menunjukkan salah satu jenis operasi yang penting dalam sebuah sistem basis data, istilah backup dapat pula merujuk pada objek dari operasi tersebut. Sebagai objek, backup adalah salinan dari data. Data disini, yaitu: Tidak hanya meliputi data pada level pemakai akhir/enduser. Tetapi juga bisa mencakup bagian-bagian penting dari basis data secara keseluruhan, seperti file-file kontrol (meta data) ataupun file-file log.

39 Ditinjau dari objeknya, backup dapat dikelompokkan kedalam: Backup Fisik (Physical Backup) Backup Lojik (Logical Backup)

40 Backup Fisik Backup Fisik (Physical Backup) adalah salinan fisik filefile basis data seperti tabel-tabel data, file kontrol, file log. Backup fisik dapat dihasilkan dari pengeksekusian program utilitas yang disediakan oleh DBMS yang bersangkutan ataupun program utilitas yang disediakan oleh sistem operasi (Operating System) dimana DBMS itu berada.

41 Backup Lojik Backup Lojik (Logical Backup), backup lojik kita dapatkan dari pembentukan file-file/objek yang berisi perintah (bisa berupa teks bahasa SQL ataupun perintah biner) yang jika dieksekusi dapat mengembalikan basis data ke kondisi semula. Backup lojik hanya dapat dihasilkan dari pengeksekusian program utilitas khusus yang disediakan oleh DBMS yang bersangkutan.

42 Berdasarkan waktu pelaksanaan atau strateginya, ada 2 jenis operasi backup yang dapat kita pilih, yaitu: Backup Statis Backup Dinamis

43 Backup Statis Backup Statis, di mana backup dilakukan dengan lebih dulu menonaktifkan basis data secara keseluruhan.

44 Backup Dinamis Backup Dinamis, di mana backup dilakukan tanpa penonaktifan basis data (sehingga user tetap bisa bekerja).

45 Remote Backup System

46 Penjelasan Menyediakan tingkat ketersediaan yang tinggi, memungkinkan transfer memproses tindakan untuk melanjutkan bahkan jika situs utama dihancurkan oleh api, banjir, atau gempa bumi. Data dan catatan log dari situs utama terus-menerus sekutu dicadangkan ke situs cadangan jarak jauh. Jika situs utama gagal, remote situs cadangan mengambil alih pemrosesan transaksi, setelah menjalankan pemulihan tertentu tindakan.. Situs cadangan jarak jauh kadang-kadang juga disebut situs sekunder. Situs remote harus tetap disinkronisasi dengan situs utama, karena pembaruan dilakukan di utama. Kami mencapai sinkronisasi dengan mengirim semua catatan log dari situs utama ke situs cadangan jarak jauh.

47 Kerja Sistem

48 Pejelasan Kerja Sistem Ketika situs utama gagal, situs cadangan jauh mengambil alih pemrosesan. Namun, pertama, ia melakukan pemulihan, menggunakan salinannya (yang mungkin sudah ketinggalan zaman) data dari primer, dan catatan log yang diterima dari primer. Sebenarnya, situs cadangan jauh melakukan tindakan pemulihan yang seharusnya dilakukan di situs utama ketika yang terakhir pulih. Standar pemulihan algo-rithms, dengan sedikit modifikasi, dapat digunakan untuk pemulihan di backup jarak jauh situs. Setelah pemulihan dilakukan, situs cadangan jauh mulai diproses transaksi. Ketersediaan sangat meningkat melalui sistem satu situs, karena sistem dapat memulihkan bahkan jika semua data di situs utama hilang.

49 Pencegahan Masalah Deteksi kegagalan Transfer kontrol Waktu untuk berkomitmen

50 Summary

51 Kesimpulan Kegagalan Sistem Disebabkan oleh Disk Rusak, Mati daya, Software Error, kebakaran pada ruang mesin, sabotase Bagian penting dari database adalah Skema Recovery & Ketersediaan tinggi Klasifikasi kegagalan : Kegagalan Transaksi, Sistem Error, Kegagalan Disk Kategori Penyimpanan : Volatile, nonvolatile, Stabil Untuk Mencapai Recovery dan Atomicity : Log Record, Database Modification, Concurency control and recovery, Transaksi Commit, Redo Undo Transaction, Chekpoint masalah Remote backup sistem : deteksi kegagalan, Transfer of Control, Time to Recover, Time to Commit