{"id":4255,"date":"2023-01-06T08:32:00","date_gmt":"2023-01-06T08:32:00","guid":{"rendered":"https:\/\/wowrack.com\/blog\/\/cara-backup-and-restore-pada-zimbra-mail-server-cek-selengkapnya-di-sini"},"modified":"2026-02-11T11:48:03","modified_gmt":"2026-02-11T04:48:03","slug":"cara-backup-and-restore-pada-zimbra-mail-server-cek-selengkapnya-di-sini","status":"publish","type":"post","link":"https:\/\/www.wowrack.com\/id-id\/blog\/news-updates-id\/cara-backup-and-restore-pada-zimbra-mail-server-cek-selengkapnya-di-sini\/","title":{"rendered":"Cara Backup Zimbra Mail and Restore Zimbra"},"content":{"rendered":"
Anda mungkin masih bingung bagaimana cara backup Zimbra email, restore, dan moving pada Zimbra Mail Server. Seperti yang Anda ketahui, Zimbra merupakan perangkat lunak open source yang dapat digunakan untuk email dan kolaborasi. Software ini menyediakan solusi email server yang powerfull, penjadwalan, kalender grup, kontak, bahkan manajemen penyimpanan melalui web.<\/div>\n
\n
<\/div>\n
Zimbra juga menyertakan pengelolaan pencadangan yang dapat dikonfigurasikan pada setiap servernya. Dengan begitu, Anda tidak perlu menghentikan server Zimbra untuk menjalankan proses pencadangan ini. Hal ini karena konfigurasi pada setiap server tersebut dapat menjalankan fungsinya untuk melakukan pencadangan dan pemulihan.<\/div>\n
<\/div>\n
Lantas, bagaimana menjalankan fungsi konfigurasi untuk melakukan fungsi pencadangan dan pemulihan tersebut? Pada artikel kali ini, akan dibahas mengenai cara mencadangkan dan memulihkan data pada Zimbra Mail Server. Pastikan Anda menyimaknya hingga akhir, ya!<\/div>\n

Mencadangkan Mail Server Zimbra<\/h2>\n
Seperti yang telah dikatakan sebelumnya, Zimbra memberikan solusi pencadangan yang bisa dikonfigurasikan pada setiap mail servernya<\/a>. Konfigurasi ini dapat dijalankan untuk melakukan pencadangan dan pemulihan.<\/div>\n
<\/div>\n
Dengan begitu, Anda tidak perlu menghentikan server untuk melakukan pencadangan. Pengaturan pencadangan ini dapat digunakan untuk memulihkan satu pengguna. Ini lebih baik daripada harus memulihkan seluruh sistem ketika satu pengguna email mengalami kerusakan.<\/div>\n
<\/div>\n
Adapun pencadangan penuh dan secara inkremental disimpan dalam file \/ opt \/ zimbra \/ backup<\/i>.<\/div>\n
<\/div>\n

Redo Log<\/h3>\n
Penting diketahui bahwa Zimbra Mail menghasilkan Redo Log yang berisi pertukaran data. Data tersebut diarsipkan dan diproses melalui server penyimpanan pesan sejak pencadangan inkremental terakhir.<\/div>\n
<\/div>\n
Begitu server dipulihkan dan file <\/i>dicadangkan serta dipulihkan sepenuhnya, redo log<\/i> akan masuk ke arsip. Penggunaan redo log<\/i> akan diputar ulang untuk membawa sistem ke titik sebelum mengalami kegagalan.<\/div>\n
<\/div>\n
File redo log<\/i> yang mencapai 100MB akan dialihkan ke direktori arsip. Saat itulah server memulai redo log<\/i> baru. Semua pemindahan file yang tidak terikat dengan redo log<\/i> sebelumnya akan dipertahankan.<\/div>\n
<\/div>\n
Jika terjadi crash<\/i>, saat server dimulai ulang, redo log<\/i> akan mendeteksi untuk kembali melakukan pemindahan file yang tidak terikat tersebut. Begitu cadangan inkremental dijalankan, redo log <\/i>dipindahkan dari arsip ke direktori cadangan.<\/div>\n

Metode Pencadangan<\/h2>\n
\"\"<\/span><\/span><\/div>\n
<\/div>\n
Ada dua metode pencadangan yang dapat dilakukan, yakni Standard Backup Method<\/i> dan Auto-Grouped Backup Method<\/i>. Untuk lebih jelasnya, mari simak penjelasannya berikut ini.<\/div>\n
<\/div>\n

Metode Pencadangan Standar<\/h3>\n
Disebut juga sebagai Standar Backup Method, dimana proses pencadangan penuh akan dijalankan secara mingguan dan pencadangan inkremental harian. Proses pencadangan ini mencakup semua informasi yang diperlukan untuk memulihkan email. Termasuk juga server direktori LDAP, database, direktori indeks, dan direktori pesan pada setiap email.<\/div>\n
<\/div>\n
Metode pencadangan standar ini juga dapat diterapkan pada perusahaan yang menjalankan pencadangan penuh selama bukan hari kerja.<\/div>\n
<\/div>\n

Metode Pencadangan Grup secara Otomatis<\/h3>\n
Auto-Grouped Backup Method<\/i> merupakan metode pencadangan otomatis yang direkomendasikan untuk kolaborasi Zimbra. Metode ini memungkinkan pencadangan secara penuh untuk semua akun sekaligus.<\/div>\n
<\/div>\n
Metode juga dapat mencadangkan secara penuh untuk Mail Group<\/i> yang berbeda pada setiap pencadangan terjadwal. Metode pencadangan grup secara otomatis ini dirancang untuk lingkungan kolaborasi Zimbra<\/a> di mana pencadangan akun dapat memakan waktu yang lama.<\/div>\n
<\/div>\n
Proses yang lama tersebut karena pencadangan dilakukan secara sekaligus antara pencadangan penuh dan inkremental. Setiap sesi yang dikelompokkan secara otomatis melakukan pencadangan penuh dari grup email yang ditargetkan.<\/div>\n

Struktur Direktori untuk File Cadangan<\/h2>\n
\"\"<\/span><\/span><\/div>\n
<\/div>\n
Struktur direktori cadangan yang dibuat melalui proses pencadangan standar dapat Anda lihat melalui tabel di bawah ini. Anda dapat menjalankan pencadangan terjadwal secara rutin ke area target yang sama tanpa menimpa sesi pencadangan sebelumnya.<\/div>\n
<\/div>\n
Pada file account.xml<\/b> tercantum semua akun yang terdapat pada semua cadangan gabungan. Setiap akun tersebut menampilkan ID, alamat email, dan label pencadangan lengkap terbaru.<\/div>\n
<\/div>\n
Jika Anda menyimpan sesi pencadangan ke lokasi lain, Anda harus menyimpan file account.xml<\/b> terbaru ke lokasi tersebut untuk akun selama pemulihan. Jika file tersebut tidak ada, Anda harus menentukan label cadangan untuk dapat dipulihkan.<\/div>\n
<\/div>\n
Sementara redo log<\/i> terletak di \/ opt \/ zimbra \/ redolog \/ redo.log<\/i>. Begitu ukuran file redo log<\/i> mencapai 100MB, redo log akan bergulir ke direktori arsip \/ opt \/ zimbra \/ redolog \/ archive<\/i>. Pemindahan yang dijalankan melalui redo log ini hanya dapat dilakukan jika jalur sumber dan tujuan berada pada volume sistem file yang sama.<\/div>\n
<\/div>\n
Dengan kata lain, redo log<\/i> dan redo-archive<\/i> log harus berada pada volume sistem file yang sama karena file arsip merupakan subdirektori dari sistem redo log<\/i>. Sementara semua sesi pencadangan tambahan dan pengelompokkan otomatis harus disimpan ke direktori yang sama, karena redo log<\/i> harus ditemukan pada target pencadangan yang sama. Sedangkan sesi pencadangan penuh secara standar dapat menggunakan direktori target yang berbeda.<\/div>\n
<\/div>\n
Di bawah ini merupakan tabel Struktur Direktori untuk File Cadangan.<\/div>\n
<\/div>\n
\n
\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n

\/opt\/zimbra\/backup<\/span><\/p>\n<\/td>\n

\n

Rooting<\/span> pencadangan <\/span>default<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

accounts.xml\/<\/span><\/p>\n<\/td>\n

\n

Daftar semua akun dengan alamat email, ID Zimbra, dan label cadangan lengkap terbaru. <\/span>Account.xml <\/span>mempertahankan pemetaan alamat email ke ID Zimbra dan juga pencadangan lengkap terbaru pada setiap akun<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

sessions\/<\/span><\/p>\n<\/td>\n

\n

Rooting<\/span> sesi pencadangan<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

full-<timestamp>\/<\/span><\/p>\n<\/td>\n

\n

Direktori cadangan lengkap. Label waktu untuk sesi, waktu mulai pencadangan dalam GMT, termasuk milidetik. GMT menggunakan waktu setempat untuk mempertahankan urutan visual seluruh transisi<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

session.xml<\/span><\/p>\n<\/td>\n

\n

Metadata tentang label pencadangan untuk sesi penuh atau tambahan, misalnya waktu mulai dan berhenti<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

shared_blobs\/<\/span><\/p>\n<\/td>\n

\n

Berisi file pesan yang dibagikan di antara akun berada di dalam cadangan ini<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

sys\/<\/span><\/p>\n<\/td>\n

\n

Tabel database global dan <\/span>localconfig<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

db_schema.xml<\/span><\/p>\n<\/td>\n

\n

Informasi skema database untuk tabel global. Setiap file <\/span>dump <\/span>tabel memiliki format .csv<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

localconfig.xml<\/span><\/p>\n<\/td>\n

\n

Salin <\/span>\/opt\/zimbra\/conf\/localconfig.xml <\/span>saat melakukan <\/span>backup<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

<table name>.dat<\/span><\/p>\n<\/td>\n

\n

Lokasi pembuangan data tabel database<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

LDAP\/ldap.bak<\/span><\/p>\n<\/td>\n

\n

Pembuangan LDAP<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

accounts\/<\/span><\/p>\n<\/td>\n

\n

Setiap data akun disimpan di subdirektori ini<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

<\u2026\u200b\/zimbraId>\/<\/span><\/p>\n<\/td>\n

\n

Rooting<\/span> untuk setiap akun<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

meta.xml<\/span><\/p>\n<\/td>\n

\n

Metadata cadangan akun<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

ldap.xml<\/span><\/p>\n<\/td>\n

\n

Informasi LDAP akun, ID, sumber data, daftar distribusi, dan lain sebagainya<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

ldap_latest.xml<\/span><\/p>\n<\/td>\n

\n

Jika ada, file ini tertaut ke ldap.xml cadangan inkremental terbaru<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

db\/<\/span><\/p>\n<\/td>\n

\n

Dump tabel database khusus akun<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

db_schema.xml<\/span><\/p>\n<\/td>\n

\n

Informasi skema database untuk tabel akun<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

<table name>.dat<\/span><\/p>\n<\/td>\n

\n

Lokasi pembuangan data tabel database<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

blobs\/<\/span><\/p>\n<\/td>\n

\n

File gumpalan<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

index\/<\/span><\/p>\n<\/td>\n

\n

File indeks Lucene<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

incr-<timestamp><\/span><\/p>\n<\/td>\n

\n

Direktori cadangan tambahan, mirip dengan skema direktori cadangan lengkap dan menyertakan metafile.<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

session.xml<\/span><\/p>\n<\/td>\n

<\/td>\n<\/tr>\n
\n

sys\/db_schema.xml<\/span><\/p>\n<\/td>\n

<\/td>\n<\/tr>\n
\n

accounts\/\u2026\u200b\/<zimbraID>\/ldap.xml<\/span><\/p>\n<\/td>\n

\n

incr-<timestamp> tidak termasuk accounts\/\u2026\/<zimbraID>\/db\/db_schema.xml karena cadangan inkremental membuang tabel akun.<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

<\/div>\n

Backup and Restore Menggunakan Konsol Administrasi<\/h2>\n
Berbagai prosedur backup and restore dapat dijalankan langsung melalui konsol administrasi. Pada panel navigasi, Monitoring > Backup<\/b> mencantumkan masing-masing server.<\/div>\n
<\/div>\n

Konfigurasi Pencadangan dari Konsol Admin<\/h3>\n
Cadangan dapat dikonfigurasi melalui konsol admin sebagai konfigurasi pengaturan global dan konfigurasi khusus server. Pengaturan server mengesampingkan pengaturan global.<\/div>\n
<\/div>\n
Sementara pada pengaturan global, Anda dapat mengkonfigurasi alamat email untuk menerima pemberitahuan hasil pencadangan. Standarnya adalah mengirim notifikasi ke akun admin. Untuk Auto-Grouped, Anda dapat mengatur jumlah grup untuk membagi cadangan.<\/div>\n
<\/div>\n
Sedangkan pencadangan standar adalah default dan dijadwalkan secara otomatis. Anda tidak perlu melakukan perubahan tambahan. Akan tetapi, saat menjalankan pencadangan yang dikelompokkan secara otomatis, Anda harus mengkonfigurasi jadwal pencadangan secara manual.<\/div>\n
<\/div>\n
Untuk melakukannya, Anda dapat mengakses CLI dan lakukan pengaturan penjadwalan Auto-Grouped Backup pada zmschedulebackup-D guna mengatur jadwal default dan melakukan pencadangan grup secara otomatis.<\/div>\n
<\/div>\n
Opsi Throttling dengan cadangan yang dikelompokkan secara otomatis.<\/b> Metode ini mencadangkan email yang belum pernah dicadangkan saat pencadangan berikutnya dijadwalkan. Ini bukan opsi terbaik setiap kali pencadangan penuh diperlukan pada semua email.<\/div>\n
<\/div>\n
Mengaktifkan Throttle Automatic Backups<\/i><\/b> akan membatasi jumlah email dalam pencadangan harian ke T\/N. Ini memecahkan batasan untuk mencadangkan semua email dan N secara harian, akan tetapi membantu pencadangan selesai selama jam istirahat.<\/div>\n
<\/div>\n
Semua email dicadangkan setidaknya sekali, nonaktifkan throttle: zmprov mcf zimbraBackupAutoGroupedThrottled TRUE<\/span><\/div>\n
\u00a0<\/span><\/div>\n

Backup and Restore Menggunakan Perintah Baris Antarmuka<\/h3>\n
Prosedur pencadangan dan pemulihan Zimbra dapat dijalankan sebagai perintah CLI. Berikut ini utilitas untuk membuat jadwal pencadangan, melakukan pencadangan penuh dan bertahap, memulihkan server email atau server LDAP.<\/div>\n
\n