1
Backup dan
Recovery
1.1
Overview
Aspek paling penting
untuk implementasi teknis adalah membangun sebuah backup efektif dan strategi
recovery. Proses ini memerlukan restore dari semuanya, atau sebagian, dari
database setelah kesalahan hardware atau software dan recovery selama sistemnya
terupdate ke poin sebelum terjadi kerusakan. Ada beberapa situasi selain kegagaln disk
yang memerlukan sebuah restore dan recovery.
Strategi backup anda
seharusnya tidak sulit. Kesulitan di strategi backup dapat membuat situasi
rumit selama proses restore dan recovery. Prosedur, identifikasi masalah, dan
penanganannya harus terdokumentasi dengan baik sehingga semua orang memahami
secara jelas peran mereka dan tugas yang diperlukan. Strategi ini seharusnya
juga tidak berakibat merugikan bisnis sehari-hari.
Bab ini membahas
backup dan restore system anda. Detil dari database tertentu dibahas pada bab
administrasi database. Informasi di bab ini akan membantu anda lebih baik dalam
memahami konsep yang meningkatkan lingkungan operasional anda dan metode akses
yang sesuai dengan kebutuhan anda.
1.2
Restore
Umumnya sebuah restore
dilakukan pada:
- recover setelah sebuah disaster
- Tes perencanaan disaster recovery
- Salin database anda ke system lainnya
Keperluan bisnis untuk
kecepatan dalan sebuah restore digerakkan oleh kebutuhan untuk mendapatkan
system kembali beroperasi secara cepat setelah sebuah disaster. Cara ini,
perusahaan dapat berlanjut untuk melakukan bisnis.
1.3
Strategi
Waktu recovery bisnis
adalah hasil dari waktu yang diperlukan untuk:
- mencari permasalahan
- memperbaiki kerusakan
- Restore database
Faktor-faktor yang
mempengaruhi strategi restore terpilih termasuk:
- biaya bisnis downtime untuk me-recover
- Jadwal operasional
- Pengguna global atau local
- Jumlah transaksi per jam
- Budget
Proses nyata untuk me-restore R/3 dan database tidak akan dibahas dibuku
ini. Tugas kritis ini memiliki kebergantungan system khusus, dan kami berikan
ke spesialis untuk mengajari. Jika sebuah restore harus dilakukan, kontak
seorang spesialis atau konsultan basis anda. Bekerja dengan DBA anda atau
konsultan untuk tes dan dokumentasikan proses restore dari system anda. Dengan
pelatihan yang tepat, anda seharusnya dapat melakukan restore.
Jika restore tidak
dilakukan secara tepat dan lengkap, restore dapat gagal dan harus diulang
kembali, atau kehilangan file-file lainnya. Ada data khusus yang anda harus
rekam tentang database anda untuk me-recovernya. Bekerja dengan spesialis
anda untuk mengidentifikasi dan mendokumentasikan data.
|
Tes Recovery
Karena prosedur restore adalah satu permasalahan utama dari system R/3,
recovery database harus dipelihara dan dites secara teratur.
1.4
Backup
Backup seperti
asuransi. Anda hanya perlu sebuah backup jika anda butuh untuk me-restore
system anda.
Apa yang dibackup dan kapan
- Database
- File log
- File sistem operasi
Catat; anda perlu
menggunakan peralatan yang berbeda untuk membackup semua file. Beberapa peralatan
hanya dapat dibackup satu atau dua dari 3 kategori file yang perlu untuk
dibackup. Contohnya, menggunakan SAP DBA Calendar DB13 untuk Microsoft SQL
Server, SAP DBA Calendar DB13 dapat membackup database dan log transaksi, tapi
bukan file system operasi.
1.5
Database
Apa
Ini adalah inti dari
system R/3 dan data anda. Tanpa backup database, anda tidak bisa merecover
system.
Kapan
Frekuensi dari
database backup full menentukan seberapa banyak hari terakhir pada waktu anda
harus mulai restore:
- Jika backup full harian dilakukan, anda
akan perlu backup full kemarin
- Hanya log sejak backup kemarin perlu
diaplikasikan untuk membawa kondisi ke sistem terkini.
- Jika backup full mingguan dilakukan,
anda akan butuh backup full minggu lalu.
- Semua log untuk tiap hari(sejak full
backup) harus diaplikasikan untuk membawa sistem ke kondisi terkini.
Backup full harian
mengurangi jumlah log yang perlu untuk diaplikasikan untuk membawa database ke
kondisi terkini. Backup ini mengurangi risiko untuk mendapatkan backup database
terkini karena sebuah file log yang “buruk” (tidak digunakan).
Jika sebuah backup
full harian tidak dilakukan, log yang lebih banyak akan perlu untuk
diaplikasikan. Langkah ini memperpanjang waktu proses recovery dan meningkatkan
risiko untuk tidak bisa direcover pada waktu terkini. Sebuah poin dapat dicapai
saat membutuhkan waktu lama untuk me-restore log, karena begitu banyak log
perlu untuk diaplikasikan. Untuk keamanan tambahan, kami merekomendasikan bahwa
anda melakukan backup database full bulanan sebagai tambahan untuk backup full
harian.
Contoh 1: Backup
Mingguan
Sebuah restore dari full backup mingguan
terakhir yang dilakukan 4 hari lalu.
|
Contoh 2 : Backup
Mingguan
Sebuah restore dari full backup tadi malam
Seperti yang anda lihat, backup mingguan
butuh 4 jam lebih lama untuk merecover daripada backup harian.
|
Contoh tadi
menunjukkan bahwa waktu yang dibutuhkan untuk melakukan sebuah restore log
bergantung pada berapa banyak hari terakhir yang anda dapatkan untuk
mendapatkan full backup terakhir. Semakin sering melakukan full backup ( dengan
waktu yang lebih sedikit antara full backup) mengurangi waktu recovery.
Juga pertimbangan
memelihara 2 siklus backup dari log pada disk untuk mengurangi kebutuhan untuk
me-restore log dari tape.
1.6 Transaction
log
Apa
Log transaksi adalah
kritis untuk recovery database. Log ini berisi rekaman unntuk perubahan dibuat
pada database, yang digunakan untuk operasi roll forward ( atau back ). Penting
untuk menyelesaikan rantaian backup log yang valid. Jika anda harus merestore
dan satu log korup, anda tidak dapat merestore log korup yang telah lalu.
Full backup mingguan
Jika sistem rusak pada hari rabu, sebuah log
pada hari selasa korup. Anda hanya dapat merecover ke log baik terakhir pada
hari Selasa. Semuanya setelah itu hilang.
|
Log transaksi disimpan dalam sebuah
direktori, yang tidak dapat dijadikan sebagai full. Jika log transaksi berisi
filespace tersedia, database akan berhenti, dan proses yang lebih lanjut tidak
dapat dilakukan pada database( dan akibatnya) di R/3. Hal yang penting untuk
proaktif dan backup log transaksi secara periodik.
Kapan
Frekuensi dari backup
log adalah sebuah keputusan bisnis didasarkan pada:
- volume transaksi
- Periode kritis dari sistem
- Jumlah data senior manajemen akan hilang
- Sumber daya untuk melakukan backup dan
menempatkannya di offsite
Juga lihat contoh dari
bagian database diatas.
Jika jumlah transaksi
anda banyak, kurangi interval waktu antar backup log. Hal ini mengurangi interval waktu
mengurangi jumlah data yang hilang di sebuah potensial data center disaster.
|
Bagaimana
Untuk membackup log
transaksi:
- Backup log transport ke disk.
- Salin backup log transaksi ke sebuah
backup file server offsite.
Backup file server ini seharusnya idealnya ada di bangunan lainnya atai
dikota lainnya. Sebuah lokasi terpisah meningkatkan kesempatan bahwa file
lognya akan terpelihara jika data center utama(berisi server R/3) hancur.
- Backup log transaksi backup pada dua
server( server R/3 dan backup file server offsite) untuk rekaman tiap hari
sepanjang dengan level file sistem operasi.
Jika anda tidak memiliki sebuah server backup offsite, backup log
transaksi backup untuk merekam setelah tiap log backup dan dengan seketika
mengirimkannya ke offsite.
Jangan backup log ke
drive tape di mode “append“ dan tambahkan berbagai backup pada tape yang
sama. Jika sebuah disaster data center terjadi, tape dengan semua lognya akan
hilang..
|
1.7
File Level
Sistem Operasi
Apa
File level sistem operasi, yang harus juga dibackup, adalah:
- lingkungan operasi( contohnya, konfigurasi
sistem dan jaringan)
- File R/3
- File Spool, jika disimpan pada level
sistem operasi
( profile sistem: rspo/ store_location = G)
- Manajemen perubahan pengiriman transport
terlokasi di /usr/sap/trans
- Aplikasi lain yang berkaitan dengan R/3
·
Interface
atau produk tambahan, seperti yang digunakan untuk EDI atau pajak, yang
menyimpan data mereka atau konfigurasi diluar database R/3.
Jumlah datanya kecil dihubungkan dengan database R/3. Bargantung pada
bagaimana sistem anda digunakan, daftar diatas seharusnya hanya memerlukan
penyimpanan beberapa ratus megabyte hingga beberapa gigabyte. Sebagai tambahan,
beberapa data dapat statis dan tidak berubah berbulan-bulan.
Kapan
Frekuensi dari backup level sistem operasi bergantung pada aplikasi
tertentu. Jika file aplikasi ini harus dipelihara secara sinkron dengan sistem
R/3, mereka harus dibackup pada frekuensi yang sama sebagai file log backup.
Contohnya pada situasi ini sebuah program pajak yang menyimpan data pajak
penjualan di file eksternal ke database R/3. File-file ini harus di sinkronkan
dengan sales order di sistem.
Metode sederhana dan cepat untuk backup file sistem operasi adalah untuk
menyalin semua direktori file data ke disk pada server kedua; dari server
kedua, anda dapat backup file tersebut sebagai rekaman. Proses ini meminimasi
file downtime.
Gunakan contoh jadwal berikut ini untuk menentukan frekuensi backup
anda.
1.8
Tipe-tipe
Backup
Tipe backup seperti matrik tiga dimensi, dimana sembarang kombinasi
dapat digunakan:
- Pakai back up apa: Full database vs log
incremental
- Bagaimana backupnya diambil: online vs
offline
- Kapan backupnya dibuat: terjadwal vs tidak
terjadwal(ad-hoc).
Pakai backup apa
1. Backup Full database
- Sebuah backup seluruh database
Keuntungannya:
- Seluruh database dibackup sekali, membuat
restore dari database lebih mudah dan cepat.
Kerugiannya:
- Butuh waktu lama untuk menjalankan
daripada backup log incremental. Karena lebih lama backup dilakukan, ada
lebih banyak akibat dari pengguna selama backupnya dijalankan.
2.Backup incremental dari log transaksi
- Sebuah backup log transaksi
Sebuah backup full database masih diperlukan
pada basis periodik. Penyusunan biasa adalah; sebuah full backup pada akhir
pekan dan backup incremental selama seminggu.
Keuntungan:
- lebih cepat dari backup full database.
Karena semakin pendek waktunya, memiliki dampak kecil ke pengguna.
Kerugian:
- Sebuah full backup diperlukan, sebagai
poin awal untuk merestore database
- Untuk merestore database membutuhkan
waktu lebih lama dan lebih sulit daripada me-restore backup full. Backup
database full terakhir harus direstore, kemudian semua backup log sejak
backup full. Ini berarti banyak log jika contohnya sistemnya rusak pada
hari Jumat, kemudian log-nya dari Senin hingga Jumat harus diaplikasikan.
- Jika satu log tidak dapat direstore, semua
log setelah poin tersebut tidak dapat direstore.
3.Backup differential
Bergantung pada database dan sistem operasi
anda, anda dapat(atau tidak) memiliki pilihan ketiga. Sebuah backup
differential adalah sebuah backup hanya yang berubah saja sejak backup full
terakhir. Sebuah backup full database masih diperlukan selama basis periodik.
Penyusunan umumnya adalah; sebuah fulll backup di akhir pekan dan backup
differential selama seminggu.
Backup differential tidak didukung oleh R/3
menggunakan DB13, anda harus menggunakan perangkat lainnya untuk melakukan
sebuah backup differential.
- Microsoft SQL Server; untuk melakukan
sebuah backup differential anda harus mengeksekusi backup differential
menggunakan peralatan Microsoft SQL Server.
Keuntungan:
- Keberadaan dari korup log backup
berkurang. Tiap backup differential memback up semua perubahan pada
database sejak full backup terakhir.
Kerugian:
- Seperti backup log incremental, sebuah
backup full diperlukan sebagai poin awal.
- Backup window untuk differential lebih panjang
daripada sebuah backup log transaksi. Ini mulai dari setelah backup full
dan mendapatkan lebih banyak data yang telah berubah.
Bagaimana
backup didapatkan
1.Offline
- Backup offline didapatkan saat database
dan sistem R/3 down.
Keuntungan:
- Sebuah backup offline lebih cepat
daripada backup online
- Selama backup, tidak ada permasalahan
data berubah pada database
- Jika file diback up diwaktu yang sama,
file sistem operasi yang berkaitan akan sinkron dengan database R/3.
Kerugian:
- R/3 tidak tersedia selama backup offline
- Buffer dari R/3 dan database dibersihkan
- Proses ini akan berakibat pada kinerja
hingga buffernya diisi.
2.Online
Sebuah backup online didapatkan selama R/3 dan
database sedang running.
Keuntungan:
- R/3 tersedia untuk pengguna selama proses
backup
- Ini diperlukan dimana sistem sedang jalan
dan digunakan 24 jam perhari dan 7 hari seminggu.
- Buffernya tidak dibersihkan
Karena buffernya tidak dibersihkan, sekali
backup terselesaikan, tidak ada dampak pada kinerja.
Kerugian:
- Sebuah backup online lebih lambat daripada
backup offline(waktu backup lebih lama)
- Waktu backup meningkat karena proses
seperti R/3 berjalan dan bersaing mendapatkan sumber daya sistem.
- Kinerja online menurun selama backup
berjalan
- Data dapat berubah pada database selama
proses backup
- Oleh karena itu, log transaksi menjadi
kritis untuk keberhasilan recovery.
- File level sistem operasi yang berhubungan
tidak sinkron dengan database R/3
Jika anda menggunakan
backup online, log transaksi adalah penting untuk kesuksesan database
recovery
|
Kapan
backup dibuat
1. Terjadwal
Backup terjadwal adalah backup yang berjalan
pada jadwal regular, seperti harian atau mingguan. Untuk operasi normal,
konfigurasikan sebuah backup terjadwal. Backup otomatis seharusnya menggunakan DBA Planning Calendar (transaction
DB13). Kalendar ini menyediakan kemampuan untuk membuat dan meninjau kembali
siklus backup. Anda juga dapat memasang CCMS ke proses backup log transaksi.
Bergantung pada platform beoperasi, backup dan
proses lainnya dikonfigurasi disini dapat dilihat di Batch Processing Monitor(transaksi SM 37) . Secara umum, status
dari backup dapat dilihat menggunakan Backup
Logs overview(transaksi DB12).
2.Sesuai permintaan
Backup sesuai permintaan dilakukakn pada basis
ad hoc. Ini dilakukan sebelum perubahan besar pada sistem, seperti upgrade R/3.
backup yang dikontrol secara langsung oleh operator, atau sesuai permintaan,
dapat dilakukan baik oleh DBA Planning
Calendar (transaksi DB13), pada database, atau pada level sistem operasi.
Meskipun DBA
Planning Calendar dapat menjadwal backup secara penggunaan periodik, ini
juga digunakan untuk melakukan backup dengan segera. Untuk backup sesuai permintaan , ini lebih
umum dari penggunaan perangkat dari level database seperti Enterprise Manager(
Microsoft SQL Server) atau SAPDBA(Oracle dan Informix).
Tanpa memperhatikan metode backup yang
dilakukan, anda seharusnya mencapai tujuan berikut ini:
§ menyediakan sebuah backup yang dapat diandalkan
yang dapat direstore
§ Buatlah backup yang sederhana
§ Kurangi jumlah operasi kebergantungan yang
diperlukan
§ Sediakan item diatas dengan sedikit atau tidak
berdampak pada unit bisnis.
1.9
Desain
Strategi Backup
SAP menyediakan perangkat dalam administrasi CCMS-DB di R/3 untuk
membantu dalam mengimplementasikan strategi anda. DBA Planning Calendar (transaksi DB13) didesain untuk backup
terjadwal. Perangkat lainnya, CCMS Monitoring Tool (transaksi DB12),
menyediakan informasi historis untuk meninjau ulang statisitik backup dan
informasi manajemen rekaman. Pada sistem operasi atau level database, ada
perangkat tambahan yang anda dapat gunakan untuk mengadministrasi backup dan
restore. Peralatan ini termasuk SQL Enterprise Manager(Microsoft SQL Server)
dan SAPDBA(Oracle dan Informix).
Untuk mendesain prosedur backup anda:
- Tetapkan persyaratan recovery berdasarkan outage/kekurangan
yang dapat diterima.
Sulit untuk didefinisikan bahwa konsep outage
yang dapat diterima, karena dapat diterima adalah subyektif dan akan berbeda
dari perusahaan satu dengan perusahaan lainnya. Biaya dari sebuah outage
termasuk kerugian produktivitas, waktu, uang, dll dihabiskan pada recovery.
Biaya ini seharusnya dievaluasi dalam sebuah cara yang sama dengan asuransi. (
Cakupan yang lebih yang anda inginkan, biaya asuransi semakin besar). Oleh karena
itu, lebih cepat waktu recovery, lebih mahal solusinya.
- Tetapkan hardware apa, software dan
kombinasi proses dapat menghasilkan solusi yang diinginkan.
Tinjau bagian dari kinerja untuk memutuskan
metode apa yang terbaik. Ikuti aturan “Keep It Simple Stupid”, tapi lebih
penting lagi, pastikan metode anda dapat diandalkan.
- Tes prosedur backup anda dengan
mengimplementasikan hardware dan meninjau kembali waktu running nyata dan
tes hasilnya.
Pastikan bahwa anda mendapatkan hasilnya dari
semua tipe backup yang dapat digunakan pada lingkungan anda, tidak hanya satu
yang anda kira dapat digunakan. Informasi ini akan menambah evaluasi lebih lama
dan keputusan perencanaan kapasitas dan menyediakan perbandingan informasi yang
berguna sesuai yang dibutuhkan.
- Tes prosedur recovery anda dengan membuat
berbagai situasi kegagalan
Dokumentasikan semua aspek dari recovery
termasuk prosesnya, siapa seharusnya melakukan tugas yang bermacam-macam, siapa
seharusnya yang diberitahu. Ingat bahwa recovery akan dibutuhkan saat anda
memiliki sedikit harapan, jadi bersiaplah. Tes tidaklah even satu kali. Ini
seharusnya terjadi secara regular, dengan tes tambahan dengan komponen hardware
dan software berubah.
Backup
tambahan
Backup tambahan dibuat pada hari khusus(akhir
bulan, akhir tahun), jadi anda dapat merestore database ke status sebelumnya.
Prosedur
Umum
Backup
Backup yang tanpa kendali dilakukan berdasarkan
pada backup frequency table. Fungsionalitas dari R/3 CCMS digunakan untuk
menjadwal backup. Di CCMS, rekaman yang diperlukan dapat didaftar dengan
memilih tombol Volume Needed pada layar backup terjadwal. Backup
ekstra, seperti backup bulanan dan tahunan, seharusnya dilakukan offline.
Backup
log transaksi
Jika backup log transaksi dilakukan selama
operasi sistem normal, tidak berdampak pada pengguna. Anda juga dapat mencari
rekaman yang dibutuhkan dengan memilih Volumes
Needed.
Tidak ada archiving khusus diperlukan pada
backup offline. (Karena backup dilakukan secara offline, database tetap dalam
status konsisten )
Verifikasi
Backup
Backup harus diuji mengikuti sebuah jadwal
teratur. Transaksi DB13 dan peralatan backup lainnya menyediakan tombol seperti
Verify Backup untuk melakukan tugas ini. Kecuali
jika backup diuji, anda akan tidak tahu bahwa anda secara tepat memback up semua
di tape.
Backup dari beberapa
file dilakukan, tapi tombol append tidak tepat digunakan untuk file kedua dan
seterusnya. Akibatnya, daripada menambah file satu dengan lainnya, untuk tiap
file, tape-nya rusak. Hasil akhirnya adalah hanya file back up terakhir yang
ada ditape.
|
Pengujian file harus
dilakukan setelah semua file telah diback up. Jika ini dilakukan setelah tiap
file, Ini tidak akan mendeteksi bahwa file sebelumnya dihapus.
|
Pemonitoran/Pengontrolan
Untuk tiap sistem, setelah memback up database
dan penyelesaian archive, semua log harus dicetak dan ditempatkan dalam folder.
Integritas
Database
Pemeriksaan integritas database harus dilakukan
pada satu periode retensi untuk memastikan bahwa tidak ada blok di database
yang korup. Blok ini dapat tidak dikenali selama backup.
Untuk menghindari backup tersembunyi, database
yang inkonsisten, database harus dicoba minimal sekali selama periode retensi.
System
|
Frequency dari Pemeriksaan DB
|
DEV
|
Setiap 2 minggu
|
QAS
|
Setiap 2 minggu
|
PRD
|
Setiap minggu
|
Role
dan tanggung jawabnya
Tugas
|
Role
|
Backup Database
|
Operator
|
Backup Archive
|
Operator
|
Pengujian backup
|
Operator/DBA
|
Pemonitoran/pengontrolan
|
Operator/DBA
|
Database check
|
DBA
|
Rekomendasi
Desain
1. Database
Anggap ukuran database anda dan backup window
mengizinkannya, kami merekomendasikan sebuah backup full database diambil tiap
hari. Untuk database yang terlalu besar untuk backup database full harian,
sebuah back up full seharusnya diambil mingguan.
- Log
transaksi
Back up log transaksi adalah kritis/penting.
Jika filespace habis, database akan berhenti, yang memberhentikan R/3.
Antara 6:00 a.m dan 9:00 pm, kami
merekomendasikan bahwa anda back up log ini minimal tiap 3 jam. Sebuah
perusahaan dengan volume transaksi tinggi
membawa risiko tinggi dan akan meningkatkan frekuensi, mungkin untuk
tiap jam. Sama, jika anda memiliki departemen shippin yang buka pada 3 a.m dan
departemen Finance yang tutup 10:00 p.m, anda akan perlu memperpanjang waktu
awal dan akhir.
- File
level sistem operasi
Frekuensi dari level backup sistem operasi
bergantung pada aplikasi. Jika file ini harus dijaga secara sinkron dengan R/3,
mereka harus diback up dengan frekuensi sama dan pada waktu yang sama pada
database dan backup log. Sebuah pilihan dari situasi non-sync-critical
adalahmemback up file level sistem operasi sekali sehari.
Daftar
Strategi
Hal penting untuk melakukan prosedur tepat
untuk memback up informasi sistem yang bernilai. Prosedur seharusnya
didefinisikan sedini mungkin untuk mencegah kemungkinan kehilangan data.
Memecahkan daftar permasalahan backup sebelum anda go live:
- Putuskan seberapa sering melakukan backup
database komplit
- Putuskan apakah parsial atau differential
yang diperlukan
- Putuskan kapan melakukan backup log
transaksi
- Miliki kemampuan untuk menyimpan log tiap
hari pada server
- Sediakan banyak space disk untuk direktori
log transaksi
- Pertimbangkan menggunakan DBA Planning Calendar(DBA13) untuk
menjadwal backup log transaksi
- Pasang R/3 yang sesuai, sistem operasi,
dan otorisasi database.
- Buat skema label volume untuk memastikan
operasinya lancar
- Putuskan sebuah periode retensi backup
- Tetapkan ukuran pool tape( tape yang
dibutuhkan perhari x retensi + 20 persen)
- Perbolehkan untuk perkembangan dan
kebutuhan khusus
- Initialisasi tape
- Tetapkan strategi penyimpanan tape secara
fisik
- Putuskan apakah menggunakan operasi tanpa
kendali(otomatis)
- Jika menggunakan operasi tanpa kendali,
putuskan dimana(di CCMS atau dilain tempat)
- Dokumentasikan prosedur backup dalam
manual operasi
- Latih operator dalam prosedur backup
- Implementasikan strategi backup
- Lakukan tes restore dan recovery
- Definisikan sebuah perencanaan darurat dan
tetapkan siapa yang dihubungi dalam kasus darurat
Prosedur
dan peraturan backup
Peraturan dan prosedur backup seharusnya
didefiniskan sedini mungkin untuk menyiapkan untuk kehilangan data potensial
selama implementasi.
Beberapa contoh dari peraturan dan prosedur
termasuk dibawah ini:
1.Lingkungan sistem
Pada landscape 3 sistem, back up CCMS dan
merestore komponen software.(Pada landscape 3 sistem di dokumen ini, DEV adalah
sebuah sistem development, QAS adalah sebuah sistem quality assurance, dan PRD
adalah sebuah sistem produksi)
2.Komponen hardware
Hardware yang terdaftar ditabel bawah ini
adalah backup dan restore database dan log transaksi.
Nama
sistem
|
Backup
Hardware
|
DEV
|
1x DLT 7000 35/70 GB, 1 DDS-3 12/24
|
QAS
|
1xDLT 7000 35/70 GB, 1 DDS-3 12/ 24
|
PRD
|
2xDLT 7000 35/70 GB, 2 DDS-3 12/24
|
Pemonitoran/pengontrolan
|
Operator/DBA
|
Database check
|
DBA
|
1.10 Manajemen Tape
Tracking dan Pendokumentasian
Untuk mendapatkan kembali tape dari storage secara mudah, anda perlu
untuk melakukan track dan pendokumentasian mereka.
Problemnya adlah:
- Pelabelan
- Track
- Penanganan
- Keperluan retensi
Pelabelan
Tape seharusnya secara jelas diberi label menggunakan satu dari banyak
metode pelabelan. Ada
3 metode sederhana yang digambarkan pada contoh dibawah ini. Dua dari metode
ini digunakan oleh R/3 dan penting jika anda menggunakan DB13 untuk menjadwal
backup anda. Manajemen backup software third party dapat menentukan nilai track
mereka untuk pelabelan. Pada kasus ini, anda harus menggunakan label khusus
oleh softwarenya.
Contoh 1
5 karakter konvensi penamaan digunakan oleh
DB13 pada Microsoft SQL Server 7 (lihat SAP note 141118). Microsoft SQL
Server 6.5 memiliki konvensi penamaan yang berbeda.
Tiap label memiliki data berikut ini:
R = R/3 database
atau log transaksi
M = msdb database
S = master
database
C = Kombinasi
L = log transaksi
D = database
F = file
G = file group
+ = differential
|
Contoh 2
6 karakter konvensi
penamaan digunakan oleh SAPDBA dan BRBACKUP(Oracle). Tiap label memiliki data
berikut ini:
- System ID(SID)
- Apa yang diback up
B = database
A = log
O = file sistem operasi
- Urutan nilai dari tape
Nilai ini adalah sebuah nilai tape urutan,
mulai dari 1 dan berkaitan dengan tanggal.
|
Contoh 3
Metode ini lebih visual, dimana panjang dari
label nama kurang dari pembatasan
Tiap label memiliki data berikut ini:
Db = database
Tl = transaction
log
Os = file sistem
operasi
|
Jika DB13 tidak digunakan, untuk semua konvensi penamaan diatas, kode
tambahan dapat digunakan untuk mengindikasikan penambahan tipe file yang diback
up.
Sebagai tambahan pada skema penamaan, gunakan label warna yang berbeda
untuk tiap system. Skema warna adalah satu atau lebih indicator untuk membantu
mengidentifikasi tape dan mengurangi kebingungan.
Sebuah contoh skema warna adalah:
Ø
PRD =
oranye
Ø
QAS =
hijau
Ø
DEV =
putih
Tracking
Tape seharusnya di log ke track dimana mereka disimpan, jadi anda dapat
menemukan mereka saat anda membutuhkan mereka.
Sebagai tambahan untuk tracking dan pendokumentasian tape saat lokasi
tape berubah, tape seharusnya di cari dan didokumentasikan saat mereka:
- Digunakan
- Dikirim ke storage offsite
- Dikembalikan ke storage offsite
- Dipindahkan ke lokasi baru
Untuk membantu track anda dan memindahkan kembali ke backup offsite,
catatlah:
- tanggal dari backup
- database
- angka tape
- Nilai penyimpanan tape storage perusahaan
Beberapa perusahaan penyimpanan melabeli
cartridge dengan label track mereka sendiri, sehingga mereka dapat mencarinya
secara internal ke system mereka dan fasilitas.
- Nilai OS level backup tape
- Tanggal dikirimkan offsite
- Tanggal dikembalikan
Tanggal
|
Label volume
|
Tujuan
|
Catatan
|
Label penyimpan perusahaan
|
Keluar
|
Kembali
|
7/15/98
|
PRDB01
|
Database
|
X7563
|
7/15/98
|
7/30/98
|
|
7/15/98
|
PRDO23
|
Operating Sys
|
X7564
|
7/15/98
|
8/15/98
|
Penanganan
Saat anda memindahkan cartridge tape, bawa
mereka dalam sebuah kotak terproteksi untuk meminimasi kerusakan dan kehilangan
data potensial jika mereka secara tidak sengaja terjatuh. Kotaknya seharusnya
memiliki potongan busa untuk tiap tape cartridge yang anda gunakan.
Untuk perusahaan
kecil, sebuah kumpulan perangkat yang ideal adalah kotak plastik ukuran kecil
dan medium dengan busa didalamnya untuk tiap tape cartridge. Plastik digunakan
karena nonmagnetik.
|
Kami merekomendasikan bahwa anda menggunakan 2
kotak. Satu kotak seharusnya mengumpulkan tape untuk dikirimkan ke offsite, dan
kota kedua
seharusnya berisi tape backup yang baru. Kotak kedua seharusnya kosong saat
anda selesai mengganti tape.
Saat merubah tape,
untuk menghindari kebingungan:
|
Untuk mengganti tape:
1.
Pindahkan
tape cartridge dari drive tape
2.
Masukkan
tape pada kotak pengumpulan
3.
Pindahkan
tape berikutnya
4.
Setelah
semua tape telah dipindahkan, masukkan tape baru di drive dengan perlakuan yang
sama
Jika anda menggunakan tape belum terinisialisasi, anda harus menggunakan
tape yang benar pada hari tersebut, atau program backup akan menolak tapenya.
Program backup membaca header tape untuk informasi inisialisasi (yang termasuk
nama label tape) dan membandingkannya ke label berikutnya sesuai urutan.
Jaga track yang tape
cartridge:
Mudah secara tidak sengaja meletakkan tape
cartridge yang salah dalam sebuah drive dan menghancurkan backup terbaru atau
karena backup berikutnya gagal.
|
Saat anda menginisialisasikan sebuah tape, beberapa program menulis
sebuah tanggal kadaluwarsa pada tape. Tape tidak bisa ditulis kembali dengan program yang sama sebelum tanggal
kadaluwarsa. Bagaimanapun, tape dapat di tulis kembali dengan program lainnya
yang mengabaikan header tape.
Bagian berikutnya membahas pentingnya persyaratan retensi.
Persyaratan Retensi
Sisi praktik dari retensi data adalah bahwa anda tidak dapat secara
nyata me-restore sebuah backup lama. Jika system operasi, database, dan system
R/3 telah diupgrade dua kali sejak backup, tidak mungkin backup dapat direstore
tanpa biaya berlebih.
Retensi berhubungan dengan siklus backup anda. Penting untuk memiliki
beberapa generasi dari full backup dan log mereka karena:
- Jika database korup, anda akan
mengembalikannya ke full backup terakhir sebelum korupsi database
- Jika full backup terakhir korup, anda akan
mengembalikannya ke full backup sebelumnya sebelum korupsi atau disaster
dan roll forward menggunakan log backup dari backup tersebut hingga
korupsi.
Seberapa jauh kembali bergantung pada level
korupsinya.
- Karena R/3 adalah system real-time online,
untuk merecover database dari database full backup, anda harus
mengaplikasikan semua log sejak backup. Jika lama waktu adalah penting,
jumlah log bisa jadi amat banyak. Oleh karena itu, jumlah log yang anda
perlu untuk mengaplikasikan sebuah batas praktik untuk seberapa jauh anda
mengembalikkannya.
Rekomendasi
- Jika sebuah full backup database diambil
tiap hari, kami merekomendasikan bahwa anda membuat paling sedikit backup
2 mingguan dan semua log untuk tiap minggu.
- Jika sebuah full backup database diambil
mingguan, anda seharusnya kembali paling sedikit 3 generasi.
Tiga generasi tradisional backup adalah:
- Kakek
- Ayah
- Anak
- Penyimpanan set backup terpilih (akhir
bulan, akhir-4 bulanan, akhir tahun dll) untuk periode perpanjangan,
sesuai dengan yang didefinisikan oleh departemen legal dan auditor.
- Periode Retensi Tape
Meskipun jika satu tape(backup/archive) rusak
atau hilang, periode retensi tape menjamin kemampuan untuk merecover database.
Nama Sistem
|
Backup regular
|
Backup akhir bulan
|
Backup akhir 4 bulan
|
Backup akhir tahun
|
Archive
|
|
DEV
|
14 hari
|
31 hari
|
||||
QAS
|
14 hari
|
31 hari
|
||||
PRD
|
31 hari
|
24 bulan
|
2 tahun
|
4 tahun
|
31 hari
|
Sistem administrator
tidak bisa menentukan periode retensi tape mereka sendiri.
Untuk menentukan periode retensi,
administrator harus mengkonsultasikannya dengan departemen yang terlibat,
seperti akunting dan legal. Ada ruang untuk beberapa negosiasi, tapi
administrator harus menuruti keputusan terakhir. Sebagai kebijaksanaan,
keputusan ini harus ditulis kembali.
|
1.11 Penyimpanan Data
Offsite
Apa
Penyimpanan offsite adalah fasilitas
terpisah(bangunan atau kampus) dari data center R/3.
Mengapa
Sebuah penyimpanan offsite menyimpan backup
jika fasilitas anda hancur.
Dimana
Besar dari disaster akan menentukan apa yang
dipertimbangkan untuk perlindungan memadai:
- Mengirim tape ke lokasi terpisah di gedung
atau gedung lainnya di kampus akan cukup.
Jika disaster dibatasi pada gedung dimana
lokasi data center.
- Jika disaster local atau regional
(contohnya, banjir atau gempa bumi) penjagaan memadai berarti mengirimkan
tape ke lokasi yang jauh beberapa ratus mile.
Fasilitas penyimpanan data offsite atau vendor
seharusnya memiliki sertifikat data storage. Tape data memiliki penanganan yang
berbeda dan persyaratan penyimpanan.
Sekali backup
selesai, kirim tape ke offsite secepatnya. Jika ada disaster di data center
dan tape backup hancur, anda dapat hanya merecover ke full backup terakhir
yang anda miliki di offsite. Untuk backup log, penting untuk mengirimkan tape
offsite segera. Jika tidak, semua sejak backup menjadi hilang.
|
Onsite
Apa
Penyimpanan onsite berarti menyimpan data anda
ke fasilitas sama seperti data center.
Bagaimana
Tape cartridge seharusnya disimpan secara
tepat, mengikuti persyaratan penyimpanan pabrikan.
Persyaratan paling
sulit untuk memenuhi medan magnet. Masalahnya adalah menentukan jika ada
medan magnet kuat dekat lokasi penyimpanan tape. Motor vacuum cleaner atau
sebuah motor listrik besar disisi lain dari tembok dimana tape data disimpan
dapat menghasilkan sebuah medan magnet kuat untuk menghancurkan tape.
|
Saat menyimpan tape cartridge, simpan semua
tape cartridge bersamaan. Semua tape digunakan dalam sebuah backup harian
seharusnya dipertimbangkan sebagai sebuah set, terdiri dari backup untuk:
- database
- log
- file system operasi
Tape dan file di sebuah set perlu untuk
direstore sebagai sebuah set. Contohnya, jika file system operasi tidak
disimpan dengan file log dan database, file system operasi tidak akan sinkron
dengan database dan informasi penting akan hilang.
Kinerja
Target kinerja paling penting adalah waktu yang
diperlukan untuk merestore database. Ini menentukan berapa lama system R/3 akan
down dan tidak tersedia untuk digunakan. Dengan R/3 down, operasi perusahaan
tertentu tidak akan terjadi.
Kinerja backup adalah penting, khususnya jika
system global atau digunakan 24 jam perhari. Saat melakukan backup, penting
untuk meminimasi akibat ke pengguna. Kunci untuk mengurangi waktu backup, yang
mengurangi akibat ke pengguna.
Untuk meningkatkan kinerja:
1.
Mengidentifikasi
kemacetan atau perangkat yang membatasi throughput.
2.
Mengeliminasi
kemacetan
Mengulangi langkah 1 dan 2 hingga kinerja
memadai atau biaya tambahan tidak lagi dibenarkan.
Proses yang berulang ini subyeknya adalah
pertimbangan biaya. Kinerja tambahan dapat selalu dibeli, yang hampir selalu
pelatihan pertimbangan biaya bisnis.
Backup
Semua kinerja item backup yang mengikuti juga mengaplikasikan untuk
merestore database.
- ukuran database
semakin besar database, semakin lama waktunya
dalam membackup
- Backup window
Backup window adalah waktu yang dialokasikan
untuk anda untuk mengambil backup regular dari system. Window ini digerakkan oleh
kebutuhna untuk meminimasi akibat dari pengguna.
- Online backup
Backup window untuk tipe backup didefinisikan
sebagai waktu saat ada pengguna yang jumlahnya kecil di system dan umumnya
dilakukan pada pagi hari.
- Offline backup
Backup window dari tipe backup ini
didefinisikan kapan dan berapa lama R/3 dapat dimatikan dan umumnya dilakukan
selama akhir pekan.
- Hardware throughput
Variabel yang membatasi seberapa cepat backup
dapat berjalan dan didefinisikan oleh jalur paling lambat pada siklus backup
seperti:
- Array drive database
- I/O channel yang digunakan
- Tape drive
Pilihan backup
Pilihan backup diasumsikan sebagai device backup di local database
server. Sebuah backup berjalan melalui jaringan akan dipengaruhi oleh topologi
jaringan, overhead dan lalu lintas jaringan. Jarang sekali kapasitas penuh dari
jaringan tersedia. Jika sebuah backup dilakukan melalui jaringan, prosesnya
akan menurunkan kinerja dari pengguna jaringan lainnya. Meskipun secara teknis
mungkin, melakukan backup via jaringan diluar dokumen ini.
Backup ke perangkat yang lebih
cepat
Semua pilihan backup berusaha untuk mengeliminasi kemacetan pada
perangkat backup. Perangkat backup, umumnya sebuah drive tape, adalah perangkat
throughput-limiting.
Tabel berikut ini berisi kapasitas dan nilai throughput untuk membantu
anda merencanakan pilihan drive tape:
Type
|
Kapasitas(GB)
(native/compressed)
|
Rate(GB/hr)
(native/compressed)
|
DAT(DDS-2)
|
4/6.8
|
1.8/3.1
|
DAT(DDS-3)
|
12/20.4
|
3.6/6.1
|
DLT 4000
|
20/34
|
5.4/9.2
|
DLT 7000
|
35/60
|
18/30.6
|
DLT 8000
|
40/68
|
21.6/36.7
|
Nilai kapasitas terkompresi pada table asumsi dari penggunaan kompresi
hardware dan penggunaan rasio 1.7x lebih konservatif dan nilai bergantung pada
jenis file dan seberapa banyak dapat dikompres.
Sebuah database 20 GB dengan hanya 9 GB data hanya kan perlu 9 GB ruang kosong tape. Seperti
volume data dari database meningkat, jadi akan membutuhkan ruang kosong tape.
Bagaimanapun, jika anda memback up pada level system operasi, seluruh file
diback up. Oleh karena itu, anda akan perlu untuk menyediakan ruang kosong tape
untuk seluruh 20 GB database.
Sebuah kemajuan teknologi, dan kapasitas dan throughput dari tape drive
meningkat, nilai ini akan menjadi terpakai. Kami merekomendasikan bahwa anda
menyelidiki apa yang tersedia kini saat anda membeli.
Keuntungan:
Lebih cepat dan lebih luas kapasitas drive tape memperbolehkan anda
mem-backup seluruh database pada cartridge tape tunggal pada periode waktu yang
layak( contohnya, 2 jam melakukan backup dari 60 GB database ke DLT7000).
Kerugian:
- Sebuah backup ke tape drive tunggal adalah
pilihan lambat.
- Kecuali kalau sebuah otomatis changer atau
library digunakan, tanpa merubah cartridge secara manual, anda dibatasi
oleh kapasitas maksimum dari cartridge tape.
Tidak semua database
dan perangkat backup didukung oleh tape changer atau librari; pastikan bahwa
perangkat ini sesuai sebelum membelinya. Contohnya, SAPDBA mendukung tape
changer, tapi Microsoft SQL Server Enterprise Manager dan NT Backup tidak.
|
Backup Paralel
Back up ke drive tape yang banyak menggunakan sebuah array
RAID-0(stripe), dimana beberapa drive tape ditulis secara parallel. Di
lingkungan tertentu, seperti Oracle, Tablespace individe atau file secara
simultan di back up ke tape drive terpisah. Karena anda menulis ke drive tape
yang banyak secara parallel, kinerja
total lebih cepat jika anda menggunakan drive tape tunggal.
Dengan tape drive secukupnya secara parallel, kemacetan dapat di rubah
dari drive tape ke komponen lainnya. Anda harus menganggap kinerja dari tiap
subsistem saat menggunakan drive tape secara parallel. Subsistem ini termasuk
drive tape, kontroler, CPU, dan I/O bus. Di beberapa konfigurasi, sebuah
kontroler atau bus adalah faktor terbatas.
Untuk merestore
backup paralel, semua tape yang diset harus dapat dibaca. Jika satu tape
buruk, seluruh set backup tidak akan digunakan. Lebih banyak tape yang anda
miliki dalam sebuah set, lebih besar kesempatan bahwa satu tape akan buruk
|
Back up ke Disk, kemudian ke Tape
Keuntungan:
- Untuk database, pilihanini adalah tercepat
Pada situasi tersebut, anda dapat backup ke
disk lebih cepat daripada ke tape.
- Pilihan ini membolehkan anda untuk membuat
beberapa salinan backup identik(contohnya, satu dari penyimpanan onsite
dan satu dari penyimpanan offsite)
- Sekali backup telah dibuat ke disk,
kinerja system R/3 berpengaruh sedikit. Karena backup tape dibuat dari
salinan disk, dan tidak live
database, backup ke tape tidak bersaing dengan aktivitas database
untuk seumberdaya system yang penting.
- Selama sebuah disaster recovery onsite
pada perangkat yang sama, recovery dapat dilakukan dari backup on-disk.
Kerugian:
- Ruang kosong disk tambahan penting,
bertambah hingga jumlah ruang kosong sama dengan database, diperlukan.
Ruang kosong tambahan ini membuat pilihan
paling mahal, khususnya untuk database yang besar.
- Hingga backup ke tape selesai, anda lemah bila terkena disaster
data center.
- Disaster recovery utama, anda harus
merestore file ke disk,kemudian menjalankannya ke database recovery dari
file ke disk.
Proses ini meningkatkan waktu untuk merecover
system.
Recovery
Keperluan menentukan bagaimana system secara cepat akan tersedia
menggunaakan dan bagaimana bisnis berulang sesegera mungkin. TUjuan ini adalah
merestore database dan file yang berhubungan dengannya untuk membuat system
secara cepat tersedia untuk penggunaan umum. Lebih lama waktu untuk restore,
lebih besar akibat dari bisnis anda.
Pilihan restore
Untuk meningkatkan kinerja restore database, semua dari pilihan backup
database diatas adalah valid. Pilihan juga ada untuk merestore ke array disk
lebih cepat dengan throughput data-write lebih tinggi.
- drive dedicated
Berhubungan backup parallel, merestore file dan
tablespace ke drive disk dedicated secara individu membuat proses lebih cepat.
Karena pada saat tertentu, hanya satu tablespace atau file ditulis ke drive,
anda tidak memiliki head contention menulis tablespace lainnya ke drive yang
sama.
- Tipe RAID
Mirrored stripe(RAID 0+1) lebih cepat daripada
RAID 5, tapi kecepatannya bergantung pada hardware khusus. Pada kasus lainnya,
tugas untuk menghitung data parity untuk drive parity(RAID 5) mengambil banyak
waktu daripada akan menulis semua data dua kali (RAID 0+1). Pilihan ini lebih
mahal karena kapasitas digunakan adalah 50 persen dari total kapasitas raw –
kurang dari RAID5:
- RAID 0+1 = [ kapasitas drive tunggal x (
jumlah drive /2)]
- RAID5 = [ kapasitas drive tunggal x (
jumlah drive -1)]
- Drive dengan kinerja penulisan lebih cepat
- Sistem drive arrat lebih dengan kinerja
penulisan lebih cepat
SAPNet-R3 Frontend Note #
|
Description
|
Microsoft
SQL server
|
|
141118
|
Kalendar penjadwalan baru di CCMS(DB13) SQL Server 7
|
102467
|
Dokumentasi online untuk SQL Server dengan SAP
|
50990
|
DB-Backup/Restore Microsoft SQL Server
|
142731
|
DBCC memeriksa SQL Server 7
|
28667
|
Microsoft SQL Server profile parameter khusus
|
128126
|
Koneksi database ke perangkat luar
|
111372
|
Stand by database untuk Microsoft SQL 7.0
|
126808
|
Parameter konfigurasi untuk Microsoft SQL Server 7.0
|
Oracle
|
|
68059
|
SAPDBA – pilihan – dengan daftar tablespace
|
43499
|
Semua catatan kolektif mengenai DBA tool
|
43491
|
Catatan kolektif : SAPDBA – pilihan Command line
|
43486
|
Catatan kolektif : SAPDBA umum
|
42293
|
SAPDBA – pilihan command line – analyze
|
34432
|
ORA-00020: jumlah maksimum proses
|
31073
|
SAPDBA – command line baru –next, -analyze
|
21568
|
SAPDBA: warning: hanya satu member dari redo online
|
16513
|
System file penuh – Apa yang harus saya lakukan?
|
15465
|
SAPDBA – shrinking tablespace
|
04754
|
Sinkronisasi buffer di system tersentral
|
03807
|
Tabelspace PSAPROLL, segmen rollback terlau kecil
|
02425
|
Fungsi dari tablespace/DBspace pada database
|
01042
|
Koneksi gagal ORACLE TWO_TASK
|
