Backup tidak ada gunanya kalau kita tidak paham cara mengembalikannya. Di Carbonio, hampir semua operasi restore dilakukan lewat CLI, dan fiturnya cuma ada di versi berlisensi, bukan Community Edition. Tulisan ini saya ringkas dari dokumentasi resmi Zextras plus beberapa hal yang saya temui sendiri waktu praktik restore dan migrasi di lab sertifikasi.

Sebelum restore, pastikan dulu

• Modul backup harus aktif dengan urutan yang benar: lisensi aktif, start service module, baru doSmartScan start. Tanpa ini, operasi restore tidak akan jalan.
• SmartScan harus dalam keadaan jalan. Kalau mati, restore apa pun akan gagal.
• Item baru ditandai sebagai deleted setelah dihapus dari mailbox melalui operasi Purge. Selama belum di-purge, item masih tersedia untuk dipulihkan.

Pilihan strategi restore

Ada beberapa strategi, dan masing-masing punya kegunaannya sendiri:

• doItemRestore untuk mengembalikan satu item tertentu ke sebuah mailbox berdasarkan itemID. Bisa juga dikembalikan ke folder yang berbeda dari aslinya.

carbonio backup doItemRestore john@example.com 4784

• doUndelete alias Time-range Undelete, untuk memulihkan item dalam satu titik atau rentang waktu tertentu, termasuk status item pada saat itu. Carbonio otomatis mengirim email ke pemicu restore dan admin di awal dan akhir proses.

carbonio backup doUndelete ...

• doRestoreOnNewAccount untuk mengembalikan isi sebuah akun ke akun baru, cocok kalau kita tidak mau menimpa akun yang sudah ada. Setelah selesai, konfigurasi mailbox baru bisa dicek dengan carbonio config dump.

• doExternalRestore untuk mengimpor backup dari infrastruktur yang berbeda. Ini pilihan untuk migrasi akun atau seluruh domain, membangun environment testing, sampai disaster recovery. Ini satu-satunya strategi yang server sumber dan tujuannya boleh beda, dan selain data, share milik akun ikut dikembalikan. Begitu dijalankan, domain dan akun langsung dibuat sehingga user bisa langsung kirim dan terima email walau item lama masih dipulihkan.

carbonio backup doExternalRestore /path/to/the/old/store

Restore Account adalah satu-satunya yang lewat GUI, ada di Admin Panel, Domains, Manage, Restore Account. Sisanya semua via CLI.

Disaster recovery singkat

Untuk pemulihan penuh setelah hardware atau infrastruktur rusak, alurnya: install Carbonio di server baru, atur Server dan Global settings, mount folder backup server lama (atau pakai backup eksternal terakhir kalau tidak tersedia), lalu jalankan doExternalRestore dengan Backup Path lama sebagai sumber. Kalau pulih dari snapshot VM, pastikan Backup Path tidak ikut di-rollback supaya datanya tetap ada untuk diimpor.

Tips

Beberapa hal di bawah ini yang sempat bikin saya tersendat waktu praktik external restore:

1. doExternalRestore tidak mem-provision akun apa pun kalau SmartScan belum diinisialisasi. Jalankan doSmartScan start dulu, baru restore.
2. doSmartScan butuh argumen start. Kalau cuma ketik doSmartScan, tidak jalan.
3. Lisensi NFR belum aktif bikin error module ZxBackup is disabled. Aktifkan lisensi dan start service module dulu sebelum apa-apa.
4. Saat External Restore banyak domain, stop dulu service backup-realtime, baru aktifkan lagi dan jalankan SmartScan setelah selesai, supaya beban server tidak melonjak. Nama service-nya backup-realtime, bukan RealTimeScanner.
5. Log restore yang valid bukan output terminal. Output terminal cuma berisi operationId. File log yang benar ada di /opt/zextras/log/op_ExternalRestore_<uuid>.log. Saya pernah kehilangan poin di submission gara-gara salah ambil ini.
6. Migrasi Files (Drive) dilakukan terpisah setelah restore email. Cari map file dengan ls /opt/zextras/backup/zextras/map_*, lalu jalankan carbonio-drive-migration -b <path_backup> -m /opt/zextras/backup/zextras/map_<uuid> -t https://hostname/. Flag -t itu URL server Carbonio, bukan domain yang diimpor, dan default-nya sudah ke hostname jadi bisa dihilangkan.
7. Selalu validasi setelah restore. Waktu praktik, saya cek email masuk, recurring calendar event, kontak, dan signature memang ikut termigrasi dengan utuh, jadi tidak cuma mengandalkan pesan sukses di terminal.

Penutup

Kuncinya, pilih strategi restore sesuai kebutuhan: item tunggal pakai doItemRestore, item terhapus pakai doUndelete, dan migrasi atau disaster recovery pakai doExternalRestore. Tapi semua itu cuma jalan kalau modul backup diaktifkan dengan urutan yang benar dan SmartScan menyala. Detail di sini saya ambil dari dokumentasi resmi dan praktik di lab, jadi tetap cek dokumentasi versi yang kalian pakai karena perintah dan default bisa berubah antar rilis.

Proxmox resmi merilis Virtual Environment versi 9.2. Saya kebetulan sedang aktif belajar Proxmox di lab pribadi dengan cluster tiga node, jadi rilis ini langsung menarik perhatian saya. Beberapa fitur barunya bahkan terasa “kebetulan banget” karena adalah hal yang baru-baru ini saya oprek manual di lab. Di tulisan ini, saya rangkum poin penting rilisnya, sekalian saya bahas catatan upgrade yang menurut saya wajib diketahui sebelum tergoda untuk langsung naik versi.

Stack di Balik Rilis Ini

Proxmox VE 9.2 berdiri di atas kombinasi versi berikut:

• Debian 13.5 Trixie sebagai base OS
• Linux kernel 7.0 sebagai default stable
• QEMU 11.0 untuk virtualisasi KVM
• LXC 7.0 untuk container
• ZFS 2.4
• Ceph Tentacle 20.2.1 sebagai default stable yang baru, dengan Ceph Squid 19.2.3 tetap tersedia sebagai opsi

Lompatan dari PVE 9.0 yang masih pakai kernel 6.14 ke kernel 7.0 di 9.2 ini cukup signifikan. Kernel baru membawa dukungan hardware modern yang lebih luas, tapi sekaligus jadi alasan kenapa saya tidak akan langsung upgrade cluster lab tanpa testing dulu.

Highlight Fitur Baru

Yang paling impactful dari daftar fiturnya adalah:

• Dynamic Load Balancer native untuk pemerataan resource cluster otomatis. Sebelumnya, fitur seperti ini biasanya didapatkan lewat project pihak ketiga seperti ProxLB. Sekarang sudah jadi bagian inti, jauh lebih maintainable untuk production.
• WireGuard sebagai fabric protocol baru di SDN, melengkapi protocol yang sudah ada. Ini bisa menyederhanakan setup overlay network terenkripsi antar node, terutama untuk skenario site-to-site.
• BGP/EVPN dengan route maps dan prefix lists, jadi filtering route antar fabric sekarang bisa jauh lebih granular. Berguna untuk skenario multi-tenant.
• Custom CPU model dari GUI, tidak perlu lagi edit /etc/pve/datacenter.cfg manual. Kecil tapi praktis.
• HA arm/disarm toggle, biar cluster tidak panik dan trigger fence saat kita sengaja maintenance node.
• Enrollment sertifikat Microsoft dan Windows UEFI 2023 lewat GUI dan API, mempermudah deployment guest Windows dengan Secure Boot aktif.
• Bugfix dan perbaikan performa di banyak area lain di seluruh platform.

Catatan Upgrade

Bagian ini saya rangkum dari FAQ resmi Proxmox, karena pertanyaan-pertanyaan ini hampir pasti akan muncul di forum dan grup beberapa hari ke depan.

Upgrade dari Proxmox VE 8.4 ke 9.2 bisa dilakukan via apt. Ikuti panduan resmi Upgrade from 8 to 9 di wiki. Jangan lupa jalankan pve8to9 checker dulu untuk mendeteksi konfigurasi yang berpotensi bermasalah setelah upgrade.

Upgrade dari 9.1 ke 9.2 bisa dilakukan via apt maupun GUI. Untuk pengalaman paling stabil, Proxmox menyarankan switch ke repository pve-enterprise saat upgrade.

Proxmox VE 8.4 akan tetap menerima security update dan bugfix kritis sampai Agustus 2026. Itu memberi sekitar satu tahun overlap untuk perencanaan migrasi. Buat environment besar dengan dependency vendor, gunakan window ini untuk testing menyeluruh, jangan tunggu mepet deadline.

Proxmox VE 9.2 bisa dipasang di atas instalasi Debian 13 Trixie yang sudah ada. Panduannya tersedia di wiki resmi.

Untuk cluster PVE 8.4 dengan Ceph Reef yang ingin naik ke PVE 9.2 dengan Ceph Squid atau Tentacle, prosesnya tiga langkah dan urutannya tidak boleh dibolak-balik:

1. Upgrade Ceph dari Reef ke Squid dulu, sementara masih di PVE 8.4.
2. Setelah Ceph stabil di Squid, upgrade Proxmox VE dari 8.4 ke 9.2.
3. Setelah PVE 9.2 stabil, baru upgrade Ceph dari Squid ke Tentacle.

Loncat langsung dari Reef ke Tentacle berisiko merusak cluster karena setiap layer punya compatibility matrix yang ketat. Ikuti dokumentasi resmi secara berurutan, jangan dipotong langkahnya.

Best Practice Singkat Sebelum Upgrade

Beberapa hal yang biasa saya pegang sebelum naik versi di lab maupun production:

1. Baca release notes resmi dulu, terutama section known issues.
2. Pastikan backup PBS sudah berjalan dan terverifikasi sebelum mulai.
3. Upgrade satu node dulu kalau cluster, monitoring 24 jam, baru lanjut node berikutnya.
4. Sediakan window maintenance yang cukup, kernel dan stack berubah cukup banyak di rilis ini.

Penutup

Proxmox VE 9.2 bukan rilis dengan fitur eksperimental yang berisiko, melainkan rilis pematangan yang banyak menambahkan polish dan native support untuk hal-hal yang selama ini dilakukan dengan workaround. Buat saya pribadi, Dynamic Load Balancer dan WireGuard fabric adalah dua yang paling menarik untuk diuji di lab.

Tapi sekali lagi, jangan terburu-buru upgrade production. Test di lab, baca release notes, dan kalau cluster kalian ada Ceph, perhatikan baik-baik urutan upgrade tiga langkah yang saya sebutkan di atas. Saya akan tulis ulasan lanjutan setelah eksperimen di lab saya jalan.

Referensi:

• Press release: https://www.proxmox.com/en/about/company-details/press-releases/proxmox-virtual-environment-9-2
• Roadmap dan release notes: https://pve.proxmox.com/wiki/Roadmap
• Upgrade PVE 8 ke 9: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9
• Ceph Reef ke Squid: https://pve.proxmox.com/wiki/Ceph_Reef_to_Squid
• Ceph Squid ke Tentacle: https://pve.proxmox.com/wiki/Ceph_Squid_to_Tentacle

Sejak saya pertama kali ikut training Carbonio oleh Zextras, salah satu hal yang menarik perhatian saya adalah cara Zextras menyediakan playbook resmi lewat Ansible Galaxy. Bukan sekadar script install biasa, tapi sebuah role yang siap deploy seluruh komponen Carbonio dari satu titik. Dan kunci dari semua itu ada di satu file: inventory.

Di tulisan ini saya mau bahas singkat soal apa itu inventory di konteks Carbonio Ansible, isinya apa saja, dan kenapa setiap grup di dalamnya penting kalian pahami sebelum tekan enter pada perintah ansible-playbook.

Apa Itu Inventory Carbonio

Secara konsep, inventory di Ansible adalah daftar host beserta peran masing-masing. Di Carbonio, inventory ini berfungsi sebagai peta jalan: server mana yang akan jadi mailbox, mana yang jadi MTA, mana yang menjalankan Consul, dan seterusnya. Ansible akan baca file ini lalu mengeksekusi task yang sesuai di setiap node sesuai grupnya.

Ada dua varian playbook resmi yang tersedia di Ansible Galaxy:

• zxbot.carbonio_install untuk skenario multi-server (essential, full-standard, full-redundant)
• zxbot.carbonio_ssinstall untuk skenario single-server

Dua varian ini punya struktur inventory yang mirip, tapi tidak identik. Beberapa grup yang muncul di multi-server justru tidak boleh diisi di single-server.

Catatan Sebelum Mengisi Inventory

Tiga hal yang sering bikin instalasi gagal kalau diabaikan:

1. Inventory hanya menerima FQDN, bukan IP address. Pastikan resolusi DNS internal sudah jalan, atau setidaknya /etc/hosts sudah diisi konsisten di semua node.
2. Multi-master untuk directory server (LDAP) tidak didukung. Cuma boleh satu master, sisanya replica.
3. dbsConnector akan otomatis dipasang di server Postgres, jadi grup [dbsConnectorServers] di skenario standar harus dibiarkan kosong. Grup ini baru relevan kalau kalian pakai HA dengan Patroni (versi 24.12.0 ke atas).

Isi Inventory dan Peran Setiap Grup

Berikut grup-grup utama yang kalian akan temui di file inventory Carbonio, beserta peran singkatnya:

Komponen inti (wajib ada)

• [postgresServers]: database utama untuk metadata Carbonio dan storage Files
• [masterDirectoryServers]: LDAP master, satu-satunya sumber kebenaran untuk akun dan domain
• [replicaDirectoryServers]: LDAP replica untuk redundansi (opsional di single-server)
• [serviceDiscoverServers]: Consul, service mesh yang menghubungkan semua komponen Carbonio
• [mtaServers]: Postfix, gerbang masuk dan keluar email
• [proxyServers]: Nginx proxy untuk webmail, IMAP, POP, dan trafik HTTP
• [applicationServers]: mailbox server, tempat data email sebenarnya disimpan

Variabel penting

• [proxyServers:vars] dengan webmailHostname=mail.example.com: hostname publik yang dipakai user untuk akses webmail

Komponen opsional (fitur kolaborasi)

• [filesServers]: Carbonio Files, fitur cloud storage internal
• [docsServers]: Carbonio Docs, editor dokumen kolaboratif
• [taskServers]: modul tasks
• [previewServers]: service untuk preview file di webmail dan Files
• [videoServers]: Carbonio Meeting, harus disertai public_ip_address=x.y.z.t di sebelah hostname
• [workStreamServers]: chat dan messaging

Komponen observability

• [prometheusServers]: metrics collector
• [syslogServer]: sentralisasi log

Perbedaan di Skenario Single-Server

Kalau kalian pakai zxbot.carbonio_ssinstall, semua grup inti di atas diarahkan ke satu hostname yang sama. Beberapa komponen opsional seperti taskServers, docsServers, videoServers, dan workStreamServers boleh dipisah ke VM lain, atau dikomentari kalau memang tidak dipakai. Grup [dbsConnectorServers] harus tetap kosong karena tidak didukung di single-server.

Best Practice

Beberapa hal yang saya pelajari selama training dan ngulik di lab:

1. Simpan inventory di direktori khusus, misal ~/carbonio-inventories/lab/, supaya bisa kelola beberapa environment paralel
2. Beri nama file inventory yang deskriptif (bukan sekadar inventory), karena nama file ini akan jadi prefix untuk file password yang digenerate seperti inventoryname_postgrespassword, inventoryname_ldap_password, dan inventoryname_consulpassword
3. Selalu pakai versi playbook yang sesuai dengan versi Carbonio target. Versi playbook dan versi Carbonio saling terikat
4. Sebelum jalankan playbook, validasi dulu dengan ansible all -i inventoryname -m ping untuk memastikan semua node bisa dihubungi via SSH
5. Backup file inventory dan file password ke tempat aman setelah instalasi, karena file yang sama dipakai lagi untuk upgrade lewat zxbot.carbonio_upgrade

Penutup

Inventory di Carbonio Ansible itu bukan sekadar daftar hostname. Dia adalah dokumen arsitektur instalasi kalian dalam bentuk paling padat. Sekali kalian paham peran setiap grup, kalian sudah punya mental model yang cukup untuk memahami bagaimana komponen-komponen Carbonio saling terhubung di balik layar, termasuk waktu nanti harus troubleshoot kalau ada service yang ngambek.

Untuk eksplorasi lebih lanjut, dua repo resmi Zextras yang saya rekomendasikan kalian baca: carbonio-install-ansible dan carbonio-ansible-ssinstall di GitHub. Di sana kalian bisa lihat contoh inventory lengkap untuk masing-masing skenario, sekalian ngintip role-nya kalau penasaran sama yang terjadi di balik layar.

Catatan singkat hasil belajar saya selama proses training dan praktik di lapangan. Bukan dokumentasi lengkap, tapi inti yang bisa dipakai sehari-hari.

Arsitektur singkat

Carbonio terdiri dari beberapa role utama yang bisa dipasang di satu server atau dipisah di multi-node:

• Mailbox: tempat data email disimpan, sisi Java/Jetty
• MTA: Postfix untuk kirim dan terima email, plus Amavis dan ClamAV
• Proxy: nginx untuk handle koneksi user (HTTPS, IMAPS, POP3S)
• Directory Server: OpenLDAP untuk identitas dan konfigurasi
• Consul: service discovery dan health check

Service-service ini saling tergantung. Di multi-node, urutan startup dan restart penting.

Service management

Semua operasi dijalankan sebagai user zextras:

su - zextras

# Cek status semua service di node ini
zmcontrol status

# Restart semua service (handle dependency otomatis)
zmcontrol restart

# Start atau stop semua
zmcontrol start
zmcontrol stop

# Cek versi Carbonio
zmcontrol -v

# Info core dan environment
carbonio core core-info

Untuk service systemd modern Carbonio (untuk carbonio terbaru memerlukan kontrol melalui systemd):

systemctl status carbonio-*
systemctl restart carbonio-mailbox

pending-setups wajib di-cek setelah upgrade atau install komponen baru. Kalau ada langkah setup yang belum selesai, command ini akan ngasih tau.

Manajemen akun

Lewat CLI carbonio prov (versi baru) atau zmprov (warisan Zimbra, masih jalan):

# Masuk ke shell interaktif prov
su - zextras -c "carbonio prov"

# Buat akun baru
su - zextras -c "carbonio prov ca user@domain.com password123 displayName 'Nama User'"

# Reset password
su - zextras -c "carbonio prov sp user@domain.com newpassword"

# Lihat info akun
su - zextras -c "carbonio prov ga user@domain.com"

# List semua akun di domain
su - zextras -c "carbonio prov -l gaa domain.com"

# Delete akun
su - zextras -c "carbonio prov da user@domain.com"

Untuk domain dan COS (Class of Service), command-nya cd, gd, cc, gc. Detail lengkapnya bisa di-cek dengan help di dalam shell prov.

Log dan troubleshooting

Lokasi log utama:

• /opt/zextras/log/mailbox.log: aktivitas mailbox (IMAP, POP3, autentikasi, index)
• /opt/zextras/log/audit.log: autentikasi
• /var/log/carbonio.log: MTA, Postfix, Amavis, ClamAV via syslog
• /var/log/mail.log: Postfix langsung
• journalctl -u carbonio-*: service systemd

Pola umum troubleshooting:

# Cari error di mailbox.log
grep -iE "error|fatal|exception" /opt/zextras/log/mailbox.log | tail -50

# Tail log realtime
tail -f /opt/zextras/log/mailbox.log

# Liat log dalam rentang waktu tertentu
journalctl -u carbonio-mailbox --since "2 hours ago"

# Debug per-user tanpa restart mailbox
su - zextras -c "zmprov addAccountLogger user@domain.com zimbra.imap debug"

Frasa “caused by” di stack trace biasanya pointer ke root cause.

Backup

Yang wajib di-backup:

• /opt/zextras/ untuk data utama Carbonio (mailbox blob, config, LDAP)
• Database MariaDB (metadata mailbox)
• LDAP dump untuk recovery cepat tanpa restore filesystem penuh
• Konfigurasi system di /etc/

Carbonio Enterprise punya backup native. Untuk Community Edition, strategi umum: snapshot di hypervisor, atau Proxmox Backup Server di level VM, plus dump LDAP berkala via slapcat atau equivalent.

Cek harian

Rutinitas pagi yang saya biasakan:

bash

# Status semua service
su - zextras -c "zmcontrol status"

# Mail queue (deferred message di Postfix)
su - zextras -c "mailq | tail"

# Disk usage partisi data
df -h /opt/zextras

# Pending setups
pending-setups

# Liat ada antrian yang stuck
su - zextras -c "postqueue -p | tail"

Mail queue yang menumpuk biasanya pertanda ada masalah delivery, baik dari sisi DNS, antivirus stuck, atau penerima yang menolak.

Penutup

Panduan ini cuma scratching the surface. Tiap deployment Carbonio punya konteks sendiri, jadi sesuaikan sama topologi yang kalian punya. Tapi untuk operasi harian, command-command di atas udah cover sebagian besar kebutuhan.

Sampai jumpa di catatan berikutnya.

Salah satu istilah yang langsung bikin saya berhenti pas pertama kali membaca saat training Carbonio adalah Carbonio Mesh. Awalnya saya pikir ini sekadar nama keren untuk salah satu service, tapi setelah saya pelajari lebih dalam, ternyata Mesh ini justru jadi salah satu komponen paling fundamental yang membedakan Carbonio dengan platform mail server lain yang biasa saya temui di artikel-artikel. Tulisan ini saya buat dari catatan saya sendiri selama mencerna materinya, semoga membantu teman-teman yang juga lagi belajar.

Pendahuluan

Sebelum membahas Mesh-nya, saya mau cerita dulu kenapa komponen ini ada. Carbonio itu sebenarnya bukan satu aplikasi raksasa, tapi kumpulan banyak komponen kecil yang saling ngobrol: ada Mailstore yang menyimpan email, ada MTA (Postfix) yang menerima dan mengirim email, ada Proxy (Nginx) yang jadi pintu depan, ada LDAP, ada PostgreSQL, dan masih banyak lagi. Pertanyaan sederhananya: bagaimana cara satu komponen tahu di mana komponen lain berada? Apalagi kalau instalasinya multi-server, di mana setiap komponen bisa duduk di mesin yang berbeda-beda.

Cara lama yang dipakai Zimbra dulu adalah dengan menyimpan informasi lokasi di LDAP secara statis. Cukup berfungsi, tapi kaku. Kalau ada komponen baru ditambahkan, kalau ada server yang pindah IP, atau kalau ada service yang tiba-tiba mati, sistem nggak punya cara dinamis untuk tahu. Di sinilah Carbonio Mesh masuk.

Apa Carbonio Services Mesh?

Di balik layar, Carbonio Mesh sebenarnya adalah HashiCorp Consul yang sudah di-bundle dan dikonfigurasi khusus oleh Zextras. Consul ini bukan teknologi baru, sudah dipakai di banyak perusahaan besar untuk arsitektur microservice. Yang Zextras lakukan adalah memanfaatkannya jadi “tulang punggung” komunikasi antar komponen Carbonio.

Fungsi Service Mesh

Setelah saya pelajari, ada tiga fungsi utama yang menurut saya paling penting untuk dipahami sebagai sysadmin:

1. Service discovery. Ini yang sudah saya ceritakan di atas — Mesh tahu di mana setiap service berada dan bisa ditanya kapan saja oleh komponen lain.
2. Health check. Mesh secara berkala mengecek apakah setiap service yang terdaftar masih hidup dan responsif. Kalau ada yang mati, Mesh akan menandainya sehingga komponen lain nggak akan kirim request ke service yang sudah tumbang.
3. Key-value store. Mesh juga berfungsi sebagai tempat menyimpan konfigurasi bersama yang bisa diakses semua komponen. Jadi semacam papan pengumuman terpusat.

Catatan

Ada satu detail yang ditekankan instruktur dan saya rasa worth diingat: kredensial Mesh disimpan terenkripsi di cluster-credentials.tar.gpg, dan password untuk mendekripsinya ada di /var/lib/service-discover/password, yang hanya bisa dibaca oleh user root. File ini krusial. Kalau file ini hilang atau rusak, banyak proses administrasi Carbonio (termasuk upgrade dan pending-setups) akan macet.

Satu insight lain: kalau suatu hari ada masalah aneh di Carbonio, misalnya MTA nggak bisa kirim email ke Mailstore padahal kedua service-nya jalan, selalu cek dulu apakah keduanya ter-register dengan benar di Mesh. Pelajaran ini sering disebut di training, dan saya kira ke depannya akan banyak terbukti sendiri waktu troubleshooting di lapangan.

Penutup

Buat saya yang sebelumnya cuma kenal Zimbra, Carbonio Mesh ini awalnya terasa seperti lapisan tambahan yang bikin sistem makin rumit. Tapi semakin saya pelajari, semakin saya sadar bahwa justru Mesh inilah yang bikin Carbonio jauh lebih siap untuk arsitektur modern. Seperti menjadi jembatan antar services.

Catatan ini masih akan terus saya update seiring saya menemukan hal baru di training. Kalau ada teman-teman yang punya pengalaman troubleshooting yang melibatkan Mesh, silahkan comment ya.

Kembali lagi bersama Rafi. Beberapa minggu terakhir ini, saya cukup banyak menghabiskan waktu dengan ekosistem dan training Carbonio. Awalnya saya mengenal nama ini sebagai “alternatif Zimbra dengan UI yang lebih modern”, tapi makin lama saya mendalami, makin saya sadar bahwa Carbonio adalah jenis platform yang berbeda dari yang biasanya saya temui di dunia kolaborasi enterprise.

Tulisan ini bukan tutorial atau review fitur. Lebih sebagai catatan pribadi tentang apa yang membuat platform ini menarik buat saya, dan kenapa saya rasa Carbonio relevan dengan kondisi pasar IT, khususnya di Indonesia, saat ini.

Tentang Kedaulatan Data (Data Sovereignity)

Topik digital sovereignty atau kedaulatan data sebenarnya bukan istilah baru. Tapi yang dulu saya pikir hanya soal “data disimpan di mana”, ternyata jauh lebih kompleks. Kedaulatan data setidaknya mencakup tiga hal:

• di mana data tersimpan,
• siapa saja yang bisa mengaksesnya, dan
• hukum negara mana yang berlaku atas data tersebut.

Yang ketiga ini sering luput dari pembahasan. Misalnya, ketika sebuah organisasi memakai layanan cloud dari perusahaan Amerika, walaupun server fisiknya berada di data center Singapura, data tersebut tetap bisa diminta oleh pemerintah US berdasarkan US CLOUD Act. Ini bukan sekadar teori, melainkan fakta hukum yang sudah diterapkan dalam beberapa kasus.

Di Indonesia, hal ini relevan dengan UU 27 Tahun 2022 tentang Perlindungan Data Pribadi, PP 71 Tahun 2019 yang mengatur Penyelenggara Sistem Elektronik, dan untuk sektor finansial ada Surat Edaran OJK 21/2017 yang mengatur tata kelola TI dan data. Intinya, organisasi-organisasi tertentu, terutama di sektor publik dan industri teregulasi, secara hukum sudah tidak bebas lagi memilih layanan kolaborasi.

Pertanyaannya kemudian: apa pilihan yang tersedia? Inilah yang membuat platform seperti Carbonio menjadi relevan.

Apa itu Carbonio?

Singkatnya, Carbonio adalah self-hosted digital workplace. Dalam satu platform, kita mendapatkan email, calendar, dan contacts kelas enterprise; files dengan versioning dan sharing control yang mirip Google Drive atau OneDrive; real-time co-editing untuk dokumen, spreadsheet, dan presentasi; chat dan video meeting dengan screen sharing serta guest access; ditambah admin tools, security, backup, dan auditability yang terintegrasi.

Yang membedakan Carbonio dari Microsoft 365 atau Google Workspace bukan sekadar daftar fiturnya, karena dua platform tersebut juga punya semua itu. Yang membedakan adalah di mana semua itu berjalan: di infrastruktur kita sendiri, bukan di data center milik vendor.

Carbonio bisa di-deploy di on-premise data center, di private cloud milik provider lokal, atau dalam pola hybrid. Yurisdiksi yang berlaku adalah yurisdiksi tempat server fisiknya berada. Tidak ada extraterritorial law yang mengintai di belakang layar.

Untuk konteks Indonesia, ini bukan kemewahan, melainkan compliance.

Mengubah Pandangan

Tapi ada satu hal lain yang justru lebih banyak mengubah cara saya melihat Carbonio. Bukan soal fitur, bukan juga soal sovereignty. Melainkan soal filosofi platformnya.

Microsoft 365 dan Google Workspace dirancang sebagai produk akhir yang lengkap. Pengguna akhir berlangganan, vendor menyediakan semuanya, mulai dari branding, hosting, support, sampai antar muka. Posisi reseller di tengah lebih sekadar menjadi billing layer.

Carbonio dirancang dengan filosofi yang berkebalikan: software-nya adalah sebuah mesin, dan partner yang membangun mobilnya. Deployment, konfigurasi, paket layanan, branding, support, semuanya berada di tangan partner. Bahkan customer akhir pun bisa tidak pernah melihat nama “Carbonio” sama sekali, karena white-label dilakukan dari ujung ke ujung.

Bagi saya yang sehari-hari berkutat dengan infrastruktur dan operasional, ini menarik. Karena artinya, platform ini menghargai keahlian teknis lokal. Tidak ada disintermediasi yang otomatis menggerus peran partner atau system integrator. Justru sebaliknya, kapabilitas teknis lokal menjadi nilai yang dihargai dalam model bisnisnya.

Arsitektur yang Layak Diperhatikan

Selain filosofi, arsitekturnya juga membuat saya cukup terkesan. Carbonio dibangun dengan tiga prinsip utama: open-core, modular, dan terdistribusi.

Open-core berarti komponen fundamental seperti mail, directory, dan core services berbasis open source dan bisa diaudit. Sementara modul enterprise seperti multi-tenancy lanjutan, real-time backup, dan white-label UI bersifat komersial. Ini penting untuk sektor publik dan industri teregulasi yang harus bisa memverifikasi cara data mereka diproses.

Modular berarti setiap fungsi seperti mailbox, MTA, web proxy, Files, Docs, Video, storage, dan backup berjalan sebagai komponen independen. Setiap komponen bisa di-scale sesuai kebutuhan beban kerjanya. Masalah di video server tidak akan menjatuhkan email.

Terdistribusi berarti semua komponen tersebut bisa di-deploy di node-node terpisah, dengan load balancing dan service mesh yang menjaga komunikasi antar layanan. Untuk yang sehari-hari main dengan Proxmox cluster seperti saya, peta arsitektur ini langsung terasa familiar dan tinggal dieksekusi dengan pola yang sudah biasa.

Mau di-deploy untuk 50 user di sebuah firma hukum, atau 5.000 user di sebuah kementerian, arsitekturnya tetap sama, hanya sizing-nya yang menyesuaikan.

Bukan Sekadar Soal Software

Yang saya tarik dari semua pengalaman ini, Carbonio bukan sekadar perangkat lunak yang bisa diinstal dan dijual ulang. Carbonio lebih mirip sebuah ekosistem yang membuka ruang ekonomi bagi MSP, system integrator, dan IT shop lokal untuk menyediakan layanan kolaborasi enterprise dengan standar yang sebanding dengan hyperscaler, tapi dengan kontrol penuh atas data dan operasionalnya.

Untuk pasar Indonesia, kombinasi ini terasa pas. Regulasi yang makin tegas soal perlindungan data, ditambah dengan kebutuhan akan partner lokal yang bisa memberi dukungan dengan responsif, membuka peluang yang menurut saya layak diperhatikan oleh siapa saja yang berkecimpung di dunia infrastruktur dan kolaborasi enterprise.

Saya sendiri masih dalam tahap belajar lebih dalam. Akan saya bagikan terus apa yang saya temukan di postingan-postingan berikutnya.

Stay tuned.