BACKUP, RESTORE & RECOVERY

Hanya sekedar memberi informasi tentang perbedaan pengertian backup, restore dan recovery dalam
database. Sebagian kalangan kadang belum begitu tepat dalam mengartikan kata RECOVERY. Ada yang
mengatakan “Saya sudah melakukan recovery”, padahal dia hanya melakukan proses restore.

BACKUP

Backup secara sederhana diartikan sebagai proses copy data operasional ke media lain. Pilihan metode
dan strategi backup yang digunakan tergantung dari kebutuhan dan kondisi.

Perhatikan gambar dibawah ini, t0 adalah database dalam kondisi awal, kemudian database dibackup pada
saat t1 (1). Setelah dibackup database digunakan untuk operasional.

Pada tn database mengalami kerusakan atau crash (2)

RESTORE

Proses mengembalikan atau copy file backup database ke server database (3). Setelah proses restore
selesai berarti database kembali pada kondisi saat terakhir kali dibackup atau kalau pada gambar database
kembali ke kondisi t1.

RECOVERY

Pada saat crash database berada pada posisi tn, kemudian dilakukan restore. Restore hanya
mengembalikan database ke kondisi backup yang terakhir. Proses mengembalikan transaksi yang terjadi
antara posisi backup terakhir sampai terjadinya crash inilah yang disebut proses recovery (4). Jadi proses
recovery secara normal harus bisa mengembalikan semua transaksi sampai sesaat sebelum terjadinya
crash database. Lebih lanjut proses recovery ini nantinya dibagi menjad beberapa mode dan strategi
tergantung dari jenis backup yang kita miliki dan jenis kerusakan yang terjadi pada database.
A. Backup dan Metode Recovery

Pengertian backup data adalah memindahkan atau menyalin kumpulan informasi (data) yang tersimpan di
dalam hardisk komputer yang biasanya dilakukan dari satu lokasi/perangkat ke lokasi/perangkat lain.
Data atau kumpulan informasi tersebut bisa berupa file dokumen, gambar, video, audio, system windows,
driver, atau software/program tertentu.

Backup adalah hal yang sangat penting dilakukan.

Dikarenakan banyak kemungkinan untuk kehilangan data, baik kesalahan yang diakibatkan oleh
pengguna atau kesalahan teknis lainnya seperti hardisk yang tak layak pakai. Untuk mempermudah
backup maka para pengembang software membuat aplikasi khusus dengan sistem network client sarver
sehingga data-data yang akan dibackup lebih teratur dan aman.

1. Metode Backup data

Backup data merupakan salah satu kegiatan yang harus dilakukan oleh pengelola database untuk
melakukan penyalinan sistem,data,dan aplikasi. Backup data harus dilakukan untuk terjadinya kerusakan
sistem dari luar maupun dalam sistem yang disengaja atau ditentukan.

a. Konsep Backup

Proses backup dalam teknologi informasi mengacu pada penyalinan data, sehingga salinan tambahan
tersebut bisa digunakan untuk mengembalikan (restore) setelah peristiwa kehilangan data. Backup sangat
berguna terutama untuk dua tujuan yaitu untuk memulihkan keadaan setelah bencana (disaster recovery)
dan untuk mengembalikan beberapa file yang sengaja dihapus atau rusak. 66% pengguna internet telah
kehilangan data yang serius. Konsistensi data dalam proses backup harus dijaga sebelum melakukan
backup data. Mengecek konsistensi data dengan membandingkan data pada struktur direktori dengan data
pada blok. Lalu, apabila ditemukan kesalahan maka program backup akan mencoba memperbaiki.
Pengecekan kekonsistenan data inilah yang disebut dengan Recovery.
Backup dapat dibagi berdasarkan lingkup datanya menjadi :

· Full Backup
· Network Backup
· Dump Backup
· Incremental Backup
· Diferensial Backup
b. Konsep Replikasi

Replikasi adalah suatu teknik untuk melakukan copy dan pendistribusian data dengan objek-objek
database dari satu database ke database lain dan melakukan sinkronasi antara database sehingga
konsistensi data dapat terjamin. Jenis-jenis replikasi meliputi :
· Snapshot Replication
· Transactional Replication
· Merge Replication

c. Konsep MySQL Dump

Untuk keperluan ini MySQL memerlukan utility yang dinamakan MySQL Dump. MySQL Dump adalah
utilitas berupa program cadangan yang pertama kali ditulis oleh Igor Romanenko, digunakan untuk
pembuangan (dump) data sebuah database, untuk cadangan (backup) atau pemindahan (transfer) data
keserver lain. Hasil dumping dapat berisi pernyataan SQL untuk membuat tabel,insert dan yang lain
dalam bentuk file CSV,teks editor , atau format XML.
Berikut ini adalah metode yang bisa dilakukan saat akan melakukan backup data :

a) Backup Logika dan Backup Physic

Backup logika adalah menyimpan perintah logic dari struktur database dan isinya yang dipresentasikan
dalam perintah SQL. Seperti CREATEDATABASE, CREAT TABLE dan INSERT DATA.
Berikut ini karakteristik backup secara logika :
1) Backup dilakukan melalui server MySQL untuk mengambil struktur dan informasi data.
2) Backup berjalan lebih lambat karena server harus mengakses informasi data dan mengirimkannya
dalam bentuk logika pada file backup.
3) Output bisa lebih besar daripada bentuk fisik, misalkan data yang disimpan 5MB dalam bentuk file
SQL maka pada saat recovery akan terjadi kehabisan memori karena prosesnya akan menghabiskan
banyak memori untuk mengembalikan dalam bentuk semula.
4) Backup dan restore dilakukan dengan mengabaikan mesin yang digunakan.
5) Backup logika tidak melibatkan banyak file hanya 1 file logika yang biasanya disimpan dalam file
SQL.
6) Data disimpan dalam bentuk logika yang merupakan bahasa DDL dan DML.
7) Backup data dilakukan saat server sudah dijalankan.
8) Program untuk backup digunakan mysqldum.exe yang memanggil file dikeluarkan dalam bentuk
logika file seperti tsiswa.sql
9) Untuk mengeluarkan data dalam bentuk file lain bisa digunakan perintah : SELECT ….. INTO
OUTFILE
Backup fisik adalah mengambil database dalam bentuk fisik,untuk database yang menggunakan Appserv
secara fisik data disimpan pada folder C:\\Appserv\Mysql\data\.
Pada folder tersebut terdapat file database, setiap table diciptakan dari 3 file yaitu ; MYD,FRM, Dan
MYI. Pada saat pengambilan data dilakukan dengan mengcopy folder yang didalamnya menyimpan data
dari database yang kita punya. Data yang diambil adalah seluruh database dan tidak bisa terpilih, sangat
berbeda dengan backup secara logika, data yang diambil bisa dipilih sesuai keinginan.
Karakteristik backup fisik :
1) Backup terdiri dari salinan file dan database, ini adalah salinan dari semua bagian direktori MyQSL,
data dari tabel memori tidak disimpan pada disk.
2) Backup data secara fisik lebih cepat karena tidak melakukan pemrosesan logika, hanya mengcopy
secara fisik.
3) Outputnya lebih sederhana dibandingkan dengan backup logika.
4) Sebagai tambahan dari database, backup dapat meliputi file manapun yang terdiri atas file MYI, MYD
dan FRM.

b) Backup Online dan Bacup Offline

Backup online dilakukan saat server MySQL sedang berjalan; sedang Backup Offline dilakukan saat
server sedang dihentikan.
Media penyimpanan Backup data yang paling simpel dan sederhana adalah Flashdisk, Memori
card,CD/DVD, hardisk external atau data cadangan dikomputer lain. Untuk versi online kita bisa
menyimpannya diserver tempat penyimpanan layanan sata seperti Couls Service Dropbox (jika sudah
menginstall aplikasi ini kita bisa selalu mengsingkronkan semua data-data di laptop dengan data yang ada
diserver dropbox, Visual SVN Server, atau media penyimpanan diinternet seperti 4Shared dan yang
lainnya.
Atau bisa memanfaatkan tempat penyimpanan dari Google seperti Google Drive, Dengan google drive
kita bisa membuat, berbagi dan menyimpan semua file di satu tempat, setelah itu kita juga bisa mengakses
dokumen dari mana saja, dirumah, dikantor, saat menjalankan tugas, dan dari semua perangkat anda.
Kapasitas yang diberikan adalah 5 GB (Gratis). Khusus untuk pengguna wordpress dengan hosting
sendiri, dengan Google Drive kita juga bisa memanfaatkannya untuk tempat penyimpanan hasil backup
database WordPress kita secara otomatis. Penyimpanan backup database wordpress bisa disetting harian
atau bulanan.
Untuk backup data kontak, email dan agenda (kalender) kita bisa memanfaatkan layanan Google Sync
(Backup gratis nomor ponsel dengan Google Sync) . dengan fasilitas sinkronasi maka data kontak yang
ada diphonebook ponsel/tablet akan dicopi kedalam daftar kontak Gmail. Sebaliknya data kontak yang
ada diGmail juga akan dicopikan kedalam ponsel. Ketika ponsel kita rusak/hilang maka tinggal kita
setting akun gmail kita dan otomatis akan menyalin hasil backup data kontak/agenda dari Gmail keponsel
kita.

c) Back Up database di Cpanel

Melakukan backup file diakun Cpanel kita secara mandiri akan memudahkan kita jika suatu saat ada
sesuatu yang bermasalah diserver. Misalnya, hardisk utama mengalami kebakaran ataupun bad
sector/crash yang membutuhkan waktu lama untuk repair/perbaikan. Biasanya dalam hal ini webhoster
akan memindahkan akun kita keserver lain yang masil berjalan normal.
Backup bisa digunakan untuk restore serelah failure. Failure disebabkan oleh :
Ø Media Failure;
Ø User error, misal : tidak sengaja drop table;
Ø Hardware failure, misal : disk-drive rusak atau permanent loss sebuah server dan;
Ø Natural disasters

Strategi Backup dan Restore meliputi :

Ø Tipe dan frekuensi Backup
Ø Kecepatan hardware
Ø Bagaimana backup diuji
Ø Dimana dan bagaimana media backup disimpan

Strategi restore meliputi :

Ø Siapa yang melakukan Restore.

d) Desain Strategi Backup

Apakah berubahan kecil atau besar terjadi pada database? Untuk database besar yang terkonsentrasi pada
bagian file atau filegroups, pilih partial backup atau file backup.
Berapa banyak ruang disk dibutuhkan untuk backup? Perkiraan disk space terutama untuk full database
backup. Backup berisi data actual pada database , tidka termasuk space kosong/ tidak digunakan.
Seharusnya ukuran backup lebih kecil dibanding database itu sendiri. Gunakan system Stored Procedure
sp_spaceused.

2. Recovery

Adalah suatu proses untuk mengupdate database dengan file backup yang telah disimpan terakhir kalinya. Recovery
ini memiliki model yaitu Recovery model yang digunakan untuk menentukan tipe backup dan skenario restore dan
mengkontrol bagaimana transaction log dikelola. Database yang menggunakan model recovery adalah sebagai
berikut :
a. Full Recovery Model
Pada model ini, transaction log akan di truncate (dipotong) pada saat dilakukan backup transaction log. Pemotongan
Transaction log hanya terjadi pada saat backup transcation log. Pada full recovery model, backup transaction log
harus dilakukan secara berkala agar transaction log tidak membengkak. Sebagai catatan, perintah truncate
transaction log tidak akan berpengaruh pada ukuran transaction log.
Full recovery model menggunakan Log backup untuk menghindari kehilangan data karena skrenario kegagalan.
Dapat me-restore database kesuatu titik waktu yang terdapat dalam log backup (pint-in-time recovery). Dapat
menggunakan log backup untuk roll-for-ward database kesuatu titik pada suatu log-backup. Misal, bisa membackup
active log (tail) setelah terjadi bencana maka dapat merestore database ketitik terjadi kegagalan tanpa kehilangan
data. Kelemahannya membutuhkan media penyimpanan besar dan waktu restore dan kompleksitas meningkat.
Ilustrasi Full Recovery Model
1. Full database backup + log (yang paling mudah)
– Backup full database : Db_1 ; Log Backup ; Log_1 , Log_2
– Setelah Log_2, hilangnya data terjadi
– Sebelum ketiga backup direstore, db admin harus membackup acvtive log (tail of the log/tail)
– Restore db_1 , Log_1 , Log_2 tanpa recovery database
– Db admin merestore dan merecover tail
– Database ter-recover ketitik kegagalan , merecover semua data
2. Strategi backup mengurangi workloss exposure dengan
– Differential Backup+log
– Transaction log backup mengurangi workless exposure potensial setelah log backup terbaru, t14
– Rangkaian 3 diff backup digunakan mengurangi jumlah transaction log that akan direstore kalau ada kegagalan
– 3 diff backup cukup besar untuk backup berikutnya sebagai full database backup.
3. Sebelum backup database pertama, ada kemungkinan hilangnya data pada t0-t1
4. Setelah itu Log Backup yang rutin mengurangi kemungkinan hilangnya data setelah log backup terakhir
5. Bila ada kegagalan, maka db admin membackup tail of the log (tail) atau log yang belum dibackup.
6. Bila tail-log sukses dibackup. Db admin dapat menghindari kehilangan data dengan merestore ketitik kegagalan.

b. Bulk-Logged Recovery model

Beberapa operasi akan bersifat minumally logged. Misalnya, bulk insert, insert .. select, create index, alter index,
drop index, dsb. Sama seperti full recovery, transaction log akan dipotong hanya pada saat backup transaction log.
Sehingga backup transaction log harus dijalankan secara berkala.
Bulk-logged recovery model akan menuliskan data page yang telah dimodifikasi kedalam file data sebelum transaksi
dinyatakan selesai. Berlawanan dengan full revocery model yang hanya membutuhkan penulisan ke log untuk
menyatakan transaksi selesai. Operasi bulk akan lebih pelan pada sistem IO yang pelan.
Hal ini juga berpengaruh pada backup transaction log. Untuk minimally logged transaction, kadang menyertakan
data page dalam backupnya. Sehingga backup transaction log dibulk logged bisa lebih besar dari full recovery
model.

c. Simple recovery model

Hampir sama dengan bulk-logged, beberapa operasi bersifat minimally logged. Macam-macam transaksi tersebut
sama persis dengan bulk-logged. Perbedaan mendasar adalah pemotongan transaction log. Transaction log otomatis
terpotong pada saat Checkpoint selesai.
Karena tidak ada backup log maka ketika terjadi database failure yang bisa dilakukan adalah merestore full backup
atau differential backup yang terakhir. Contoh :
Ada 5 backup database (Hanya yang terbaru) :t1-t5
Dimisalkan harus direstore ke waktu t5 maka:
– Database kembali kewaktu t5
– Semua update setelah t5 hilang

Ilustrasi Simple Recovery Model :

1). Full databasebackup
Cocok untuk database kecil sehingga dapat dibackup

2). Strategi backup mengurangi workloss exposure dengan :

Ø Differential database backup
Ø Dibanding full database
Ø Setelah database backup pertama,sekumpulan differential backup dibuat (3 diff backup)
Ø Setelah diff backup ke 3 cukup besar, backup berikutnya adalah database backup untuk membuat differential base
baru.