2 hari yang lalu saya begadang sampai jam 2 pagi, sampai tertidur didepan laptop
. Ada seorang rekan yang mengelola sistem Zimbra mail server disebuah perusahaan yang cukup besar dengan jumlah account sekitar 1300-an. Ia mengirimkan pesan mengenai masalah yang mengganggu Zimbra Mail Server di kantornya dan apakah saya bisa mencoba membantu untuk mengatasinya.
Setelah menemani Zeze Vavai main counter strike, saya mulai mencoba mendiagnosa masalah Zimbra Mail Servernya menggunakan account ssh yang ia berikan. Setelah memintanya melakukan backup dan membuat beberapa salinan data backup, saya memulai penelusuran melalui file log yang ada di /opt/zimbra/log/mailbox.log dan di /var/log/zimbra.log. Saya juga mencoba mengecek status Zimbra melalui perintah zmcontrol status yang menghasilkan pesan bahwa semua service berjalan kecuali service yang paling penting : MTA. Penelusuran lebih jauh menemukan bahwa problem utama ada pada database MySQL tempat mailbox disimpan yang tidak bisa terkoneksi dengan Zimbra.
Setelah mencoba melakukan recovery database innodb MySQL tanpa hasil yang memuaskan, saya mencoba menganalisa mengenai integritas data secara fisik dan justru menemukan banyak sekali log MySQL yang menyatakan : I/O input output error. Dugaan saya, ini ada masalah dengan data yang ada secara fisik sehingga saya mencoba melakukan perintah rsync untuk membackup data-data utama database MySQL yang ada difolder /opt/zimbra/db/data. Meski sudah ada salinan backup yang dilakukan teman saya, saya tetap mencoba membackup karena saya menduga problem utama ada didata fisik setelah recovery data MySQL tidak berhasil.
Ternyata perintah rsync tidak berhasil membackup data karena ada masalah I/O error ! Saya coba test dengan perintah standar cp untuk membackup data utama ibdata1 juga tidak berhasil sehingga kesimpulannya, masalah memang ada pada harddisk secara fisik.
Berbekal informasi bahwa teman saya sudah melakukan backup data, saya memintanya mengecek ukuran file ibdata1. Mestinya diatas 1 GB, namun ia bilang hanya 48 MB !!
Setelah mencoba berbagai cara tidak ada hasil, saya menanyakan padanya mengenai salinan backup yang pernah ia lakukan sebelum terjadi masalah, entah itu 1-2 hari yang lalu ataupun 1 minggu hingga 1 bulan kemarin. Ternyata ini juga tidak ada.
Sayang sekali, peluang satu-satunya untuk melakukan recovery data adalah melakukan proses fsck dan proses recovery disk yang bisa dilakukan dalam kondisi harddisk offline. Melakukan fsck dalam kondisi sedang terpakai tentu akan sangat beresiko pada integritas data. Untuk sementara, menunggu data bisa direcovery, saya melakukan export account melalui LDAP dan kemudian melakukan import data account tersebut ke mesin Zimbra Mail Server yang baru.
Berkaca pada pengalaman ini, backup data apalagi untuk data penting semacam email bukan lagi sesuatu yang dapat ditawar. Saya pribadi lebih baik dianggap sebagai admin yang paranoid karena membuat salinan backup untuk beberapa kondisi daripada harus terjebak pada masalah data corrupt. Untuk sistem yang saya setup dikantor saat ini, proses backup lebih sederhana karena saya memiliki salinan email di Google Apps dan juga memiliki image Zimbra Mail Server didalam VirtualBox. Adanya Zimbra Mail Server didalam VirtualBox mempercepat proses recovery karena saya tidak perlu melakukan setup Zimbra dari awal. Selain itu, Zimbra di dalam media virtualisasi (VirtualBox atau VMWare atau Xen atau KVM) dapat dibackup secara gradual dengan menyimpan beberapa perubahan terakhir.
Bagi rekan-rekan yang memerlukan script sederhana backup image virtualisasi yang otomatis membuat salinan untuk 1 bulan terakhir silakan merujuk ke artikel berikut : Script Sederhana untuk Live Backup pada Zimbra Mail Server.
jay August 14th, 2009, 8:17 am
kalo backup non virtual gmn ya?
misal dari zimbra server ke PC backup .
thx
Dedhi August 15th, 2009, 11:58 pm
AFAIK, Type II hypervisor macam VirtualBox dan VMWare Server tidak mengindahkan cache flush semantics demi menampilkan performance setinggi mungkin. Running production server yang high concurrent I/O macam email server diatasnya, IMO, tidak bijaksana.
Coba deh cari cari pakai keyword cache flush virtualbox atau vmware server di Google untuk melihat para korban-nya.