Hari ini seharusnya cuma setup seperti biasa. Tambah datastore baru di PBS, backing-nya pakai S3 (MinIO lokal), selesai dalam 30 menit. Kenyataannya? Tidaaaaak.
Awal Mulanya Simpel
Setup-nya sebenarnya tidak rumit. Punya PBS jalan di 192.168.14.200, punya MinIO di 192.168.14.100:9000, tinggal mount bucket-nya via s3fs ke /mnt/s3-datastore, lalu daftarkan ke PBS sebagai datastore. Done.
Mount jalan, ls bisa, bahkan touch file ke mount point berhasil dan filenya muncul di MinIO UI. Semua terlihat normal.
Klik Add Datastore di PBS Web UI.
TASK ERROR: EIO: I/O error
Output:
Investigasi Pertama: Salah Sangka
Pikiran pertama: pasti koneksi ke MinIO bermasalah. Langsung cek, curl ke MinIO health endpoint ok, credential di /root/.passwd-s3fs benar, bucket accessible. Tidak ada yang salah dari sisi network.
Di sinilah titik yang menarik. touch bisa, buat file bisa, tapi PBS tetap gagal. Setelah lihat lebih dalam, ternyata PBS saat inisialisasi datastore tidak cuma nulis 1 file. Ia langsung buat 256 subdirektori sekaligus di dalam .chunks/ — dari 00/ sampai ff/.
256 mkdir call dalam waktu sangat singkat ke s3fs yang bicara ke MinIO via HTTP. s3fs setiap mkdir = 1 API call. Burst sebesar itu langsung overwhelmed.
Jadi bukan masalah mount, bukan masalah credential, bukan masalah network. Masalahnya adalah PBS terlalu agresif saat init, dan s3fs tidak punya buffer untuk menyerap itu.
Percobaan Pre-create Manual
Ide selanjutnya, kalau PBS yang buat 256 dir sekaligus tidak bisa, buat manual dulu dengan throttle, PBS tinggal pakai strukturnya.
mkdir -p /mnt/s3-datastore/.chunks
for i in $(seq 0 255); do
printf -v hex "%02x" $i
mkdir -p /mnt/s3-datastore/.chunks/$hex
sleep 0.2
done
Status Sekarang
Sudah jam sore. Mount bersih, MinIO hidup, credential valid, write manual bisa. Tapi PBS masih belum mau terima /mnt/s3-datastore sebagai datastore yang sah.
Troubleshoot masih jalan. Mungkin solusinya di throttle yang lebih lambat, mungkin di ganti s3fs ke rclone yang punya VFS cache layer, mungkin ada hal lain yang belum kelihatan.
Yang jelas, setup yang harusnya 30 menit sudah jalan hampir seharian. Asik.
Akan diupdate kalau sudah ketemu root cause-nya. Kemungkinan bakal pakai rclone daripada s3fs.
Selamat datang kembali di blog Rafi. Kali ini saya mau sharing pengalaman setup Proxmox Backup Server (PBS) sebagai dedicated backup target untuk cluster Proxmox VE. Kalau kalian udah punya homelab atau production environment berbasis Proxmox, setup PBS ini wajib banget, supaya backup VM kalian lebih terstruktur, deduplicated, dan mudah di-restore.
Di lab saya sendiri, PBS ini dijalankan sebagai VM di atas node Proxmox dengan IP statis 192.168.14.200. Yuk langsung kita mulai dari awal!
Langkah 1 — Buat VM untuk Proxmox Backup Server
Langkah pertama adalah membuat VM baru di Proxmox yang nantinya akan menjalankan PBS. Klik Create VM di Proxmox Web UI.
Tab General
Di tab General, isi konfigurasi berikut:
Node: pve23
VM ID: 200
Name: pbs-rafi-192.168.14.200
Resource Pool: Rafi
Tab OS — Pilih ISO Proxmox Backup Server
Pindah ke tab OS. Di sini kita pilih ISO yang akan dipakai untuk instalasi:
Storage ISO: dataisoonnfs
ISO Image:proxmox-backup-server_4.1-1.iso (1.51 GB)
Guest OS Type: Linux
Version: 6.x – 2.6 Kernel
Spesifikasi VM yang Direkomendasikan
Komponen
Minimum
vCPU
2 core
RAM
4 GB
Disk OS
32 GB
Disk Backup
Sesuai kebutuhan
Network
VirtIO, 1 NIC
Setelah semua tab dikonfigurasi (System, Disks, CPU, Memory, Network), klik Finish lalu boot VM. Proses instalasi PBS berlangsung seperti instalasi Debian biasa, jadi ikuti saja wizard-nya hingga selesai.
Langkah 2 — Buat Datastore di PBS
Login ke https://192.168.14.200:8007
Navigasi ke Datastore → Add Datastore via panel kiri
Isi form Name, Path, GC Schedule via GUI
Verifikasi langsung dari dashboard datastore PBS
Langkah 3 — Daftarkan PBS sebagai Storage di Proxmox VE
PBS sudah siap. Sekarang kita daftarkan PBS ke Proxmox VE cluster agar bisa digunakan sebagai backup target dari semua node.
Navigasi ke Storage di Datacenter
Dari Proxmox Web UI, buka Datacenter → Storage → Add → Proxmox Backup Server.
Isi konfigurasi koneksi ke PBS
Field
Keterangan
ID
Nama storage di Proxmox VE
Server
IP address VM PBS
Username
User PBS (format: user@realm)
Password
Password user PBS
Nodes
Semua node cluster bisa akses
Content
Tipe konten yang disimpan
Datastore
Nama datastore yang dibuat tadi
Namespace
Namespace PBS (default)
Fingerprint
Wajib untuk self-signed cert
Fingerprint: PBS default menggunakan self-signed certificate, sehingga fingerprint wajib diisi. Cara termudah: coba klik Add tanpa fingerprint — Proxmox akan menampilkan fingerprint PBS untuk dikonfirmasi. Copy dan paste ke field Fingerprint.
Best Practice: Jangan gunakan root@pam di environment production. Buat user PBS khusus dengan permission minimal yang diperlukan — misalnya hanya bisa backup dan restore ke datastore tertentu saja. Ini meminimalkan risiko jika credential bocor.
Klik Add dan tunggu Proxmox verifikasi koneksi ke PBS.
Langkah 4 — Verifikasi Integrasi Berhasil
Jika semua langkah berjalan lancar, storage pbs-backup akan muncul di daftar storage Datacenter dengan status Enabled: Yes dan Shared: Yes.
Dari storage list final, terlihat pbs-backup sudah terdaftar dengan type Proxmox Backup Server, content Backup, dan bisa diakses oleh semua node di cluster. Selamat — PBS sudah terintegrasi penuh!
Tabel Perbandingan Backup PBS dengan NFS
Fitur
Backup NFS/Local
Proxmox Backup Server
Deduplication
❌
✅ (chunk-level)
Enkripsi end-to-end
❌
✅
Incremental backup
Terbatas
✅ (via dirty-bitmap)
Verifikasi integritas
❌
✅ (built-in verify job)
Retention management
Manual
✅ (otomatis)
Dedicated Web UI
❌
✅
Backup saat VM running
Tergantung mode
✅ (snapshot mode)
Dengan deduplication, storage yang digunakan jauh lebih efisien. Untuk environment yang punya 5+ VM, PBS benar-benar sangat worth it dibanding backup konvensional ke NFS.
Troubleshooting
“Connection refused” saat add PBS storage Cek apakah port 8007 di PBS bisa diakses. Coba buka https://192.168.14.200:8007 dari browser. Cek juga firewall di VM PBS.
“Certificate verification failed” Isi field Fingerprint dengan SHA-256 fingerprint certificate PBS via CLI: proxmox-backup-manager cert info, via GUI: Dashboard -> Button “Show Fingerprint”
Datastore tidak muncul di dropdown Pastikan username dan password sudah benar. Coba login manual ke web UI PBS dengan credential yang sama untuk verifikasi.
Halo! Jadi begini ceritanya, beberapa waktu lalu saya ada list tugas untuk migrate beberapa VM dari VMware ESXi ke Proxmox. Awalnya saya pikir ini bakal ribet banget, tapi ternyata setelah dicoba, prosesnya cukup mudah kok. Walaupun awalnya saya salah menafsirkan untuk import VM.
Nah, di artikel ini saya mau share cara yang menurut saya paling mudah dan aman untuk import VM dari VMware ke Proxmox. Saya akan fokus ke satu metode saja supaya kalian nggak bingung dengan terlalu banyak pilihan.
Kebutuhan
Sebelum mulai, pastikan kalian sudah punya:
Akses ke VMware ESXi/vCenter
Username dan password (minimal user biasa, tapi lebih baik root)
Bisa login ke web interface
Proxmox yang sudah jalan
Minimal 1 node (di tutorial ini saya pakai 3 node)
Storage dengan space yang cukup
Koneksi internet atau network yang stabil
Untuk download/transfer file VM
Langkah 1 — Tambahkan Storage ESXi di Datacenter
Masuk ke Datacenter → Storage → Add → ESXi (paling bawah di dropdown).
Masukkan kredensial ESXi kemudian Klik Add. Storage akan otomatis muncul di semua node cluster (VMware (rafi1) dan VMware (rafi2)).
Langkah 2 — Verifikasi Storage Terdaftar
Di sidebar kiri, pastikan sudah muncul:
VMware (rafi1) — dengan ikon cloud
VMware (rafi2) — dengan ikon cloud
Klik salah satu, lalu pilih tab Virtual Guests. Kamu akan melihat dua VM yang tersedia dari ESXi:
ha-datacenter/vmforvmware/Debian12/Debian12.vmx — format vmx
ha-datacenter/vmforvmware/Talos/Talos.vmx — format vmx
Langkah 3 — Mulai Import VM
Pilih baris VM yang ingin di-import (misal Debian12.vmx), lalu klik tombol Import di atas tabel.
Best practice: Pilih storage yang mendukung shared storage cluster.
Langkah 5 — Opsi Live Import (Opsional)
Centang Live Import hanya jika VM di ESXi masih dalam keadaan mati (stopped) dan kamu ingin Proxmox menyalakannya di sisi Proxmox sambil disk disalin di background. Untuk migrasi normal, biarkan tidak dicentang.
Langkah 6 — Klik Import dan Monitor Progress
Klik tombol Import. Proxmox akan mulai menyalin disk image dari ESXi via jaringan. Pantau progress di panel Logs di bagian bawah Proxmox GUI.
THE END. Jadi seperti itu untuk import vm dari vmware yang menurut saya cara tercepat.
Melanjutkan pembelajaran menjadi Proxmox Engineer cukup menantang, karena memang harus paham, mulai dari networking hingga pengetahuan tentang storage.
Pada artikel kali ini, saya membuat catatan dari pembelajaran yang sudah saya lakukan yaitu menambahkan storage ZFS sebagai datastore. Langsung saja ke langkah-langkahnya…
Kita sudah punya 3 node:
rafi1 rafi2 rafi3
Dan tujuan kita:
Setiap node punya ZFS pool dengan nama sama (zfs-pool)
Storage muncul di Proxmox
Siap dipakai untuk replication
Kondisi Awal
Dari rafi1, kalian sudah cek disk:
lsblk
Output:
sda 100G → OS sdb 20G → disk tambahan (target ZFS)
Belakangan ini pekerjaan saya banyak berkutat dengan server management, dan salah satu hal yang cukup menarik adalah ternyata ada banyak sekali jenis filesystem dengan karakteristik yang berbeda-beda – ext4, XFS, ZFS, Btrfs, NFS, dan masih banyak lagi. Karena informasinya cukup banyak dan kadang butuh referensi cepat, saya putuskan untuk membuat catatan di blog ini supaya bisa refresh memory kapan pun diperlukan. Sebelum membahas perbedaan masing-masing tipe, ada baiknya kita pahami dulu konsep dasarnya.
Filesystem adalah komponen fundamental dalam sistem operasi yang mengatur bagaimana data disimpan, diorganisir, dan diakses dalam media penyimpanan. Pemilihan filesystem yang tepat sangat penting karena mempengaruhi performa, keamanan, dan keandalan sistem secara keseluruhan. Artikel ini akan membahas berbagai jenis filesystem yang umum digunakan beserta karakteristik masing-masing.
1. ext4 (Fourth Extended Filesystem)
ext4 adalah filesystem default untuk sebagian besar distribusi Linux modern dan merupakan evolusi dari ext3.
Karakteristik Utama:
Maksimal ukuran file hingga 16 TB
Maksimal ukuran volume hingga 1 EB (Exabyte)
Mendukung journaling untuk recovery data
Backward compatible dengan ext2 dan ext3
Delayed allocation untuk meningkatkan performa
Multiblock allocation untuk mengurangi fragmentasi
Kelebihan:
Stabil dan mature, sudah teruji bertahun-tahun
Performa yang baik untuk penggunaan umum
Dukungan luas dari berbagai tools dan sistem operasi
Recovery yang cepat setelah crash
Kekurangan:
Tidak mendukung snapshot
Tidak memiliki fitur compression built-in
Proteksi data corruption terbatas dibanding filesystem modern
Penggunaan Ideal: Desktop Linux, server general purpose, sistem yang membutuhkan kompatibilitas tinggi
2. XFS (XFS Filesystem)
XFS dikembangkan oleh Silicon Graphics dan dioptimalkan untuk performa tinggi dengan file berukuran besar.
Karakteristik Utama:
Dirancang untuk skalabilitas tinggi
Maksimal ukuran file hingga 8 EB
Allocation groups untuk paralelisasi operasi
Delayed allocation dan extent-based allocation
Journaling metadata
Online defragmentation dan resize (hanya expand)
Kelebihan:
Performa sangat baik untuk file besar
Excellent untuk workload dengan banyak file besar
Scalability yang superior
Parallel I/O yang efisien
Kekurangan:
Tidak bisa shrink (hanya bisa expand)
Recovery lebih lambat dibanding ext4
Membutuhkan RAM lebih banyak untuk operasi optimal
Kurang cocok untuk banyak file kecil
Penggunaan Ideal: Media server, database server, video editing, aplikasi yang menangani file berukuran besar
3. ZFS (Zettabyte File System)
ZFS adalah filesystem dan volume manager yang dikembangkan oleh Sun Microsystems (sekarang Oracle), terkenal dengan fitur enterprise-grade.
Karakteristik Utama:
Copy-on-write (COW) architecture
Checksumming untuk deteksi data corruption
Built-in RAID (RAIDZ, RAIDZ2, RAIDZ3)
Snapshot dan cloning
Compression dan deduplication
Self-healing dengan data redundancy
Maksimal ukuran teoretis 256 quadrillion zettabytes
Kelebihan:
Integritas data sangat tinggi dengan checksum
Snapshot yang efisien dan instant
Compression transparan menghemat storage
RAID software yang powerful
Protection terhadap bit rot dan silent corruption
Send/receive untuk replikasi data
Kekurangan:
Konsumsi RAM sangat tinggi (minimal 1GB per 1TB storage)
Licensing issues di Linux (CDDL vs GPL)
Kompleksitas konfigurasi
Performa bisa menurun dengan fragmentasi
Tidak bisa shrink pool
Penggunaan Ideal: Storage server, backup server, sistem yang membutuhkan integritas data maksimal, NAS enterprise
4. Btrfs (B-tree File System)
Btrfs adalah filesystem modern untuk Linux yang dirancang untuk menggantikan ext4 dengan fitur-fitur advanced.
Karakteristik Utama:
Copy-on-write (COW) seperti ZFS
Built-in snapshot dan subvolume
Online resizing (expand dan shrink)
Built-in RAID (0, 1, 10, 5, 6)
Compression transparan (LZO, ZLIB, ZSTD)
Self-healing dengan metadata duplication
Defragmentation online
Kelebihan:
Snapshot yang cepat dan space-efficient
Subvolume untuk organisasi data yang fleksibel
Compression menghemat space
Bisa shrink dan expand secara online
Checksum untuk deteksi corruption
Native di kernel Linux (tidak seperti ZFS)
Kekurangan:
RAID 5/6 masih belum stabil (2024)
Kadang ada issue performa dengan database workload
Belum se-mature ZFS untuk production critical
Fragmentasi bisa menjadi masalah
Penggunaan Ideal: Desktop Linux modern, development server, sistem yang membutuhkan snapshot regular, backup incremental
5. NFS (Network File System)
NFS sebenarnya bukan filesystem lokal, melainkan protokol untuk mengakses filesystem melalui jaringan.
Karakteristik Utama:
Client-server architecture
Mounting remote filesystem seperti lokal
Versi terbaru: NFSv4 dengan security enhancement
Stateless protocol (NFSv3) dan stateful (NFSv4)
Support untuk locking dan caching
Kelebihan:
Sharing file antar sistem Unix/Linux dengan mudah
Centralized storage management
Transparansi akses (seolah lokal)
Mature dan widely supported
Kekurangan:
Performa tergantung network latency
Security concerns (terutama NFSv3)
Tidak cocok untuk workload yang latency-sensitive
Kompleksitas konfigurasi untuk security
Penggunaan Ideal: Sharing file di environment Linux/Unix, home directories di cluster, centralized storage
6. NTFS (New Technology File System)
NTFS adalah filesystem default Windows sejak Windows NT.
Karakteristik Utama:
Journaling untuk reliability
Access Control Lists (ACL) untuk security
Encryption (EFS – Encrypting File System)
Compression di level file
Disk quota
Hard links dan symbolic links
Maksimal file size 16 EB
Kelebihan:
Security features yang robust
Metadata journaling
Compression dan encryption built-in
Support file besar
Mature dan stabil di Windows
Kekurangan:
Support terbatas di Linux (perlu driver tambahan)
Fragmentasi masih terjadi
Tidak ada snapshot native (butuh Volume Shadow Copy)
Performa di Linux tidak optimal
Penggunaan Ideal: Windows desktop dan server, dual-boot system, external drive untuk Windows
7. FAT32 dan exFAT
FAT32 adalah filesystem legacy yang masih banyak digunakan untuk kompatibilitas maksimal.
FAT32:
Maksimal file size 4 GB
Maksimal partition size 8 TB (praktis 2 TB)
Tidak ada journaling
Kompatibel dengan hampir semua OS
Sederhana dan reliable
exFAT:
Dikembangkan Microsoft untuk flash drive
Maksimal file size 16 EB
Tidak ada batasan praktis untuk partition size
Lebih efisien untuk flash media
Support yang luas di OS modern
Penggunaan Ideal: USB flash drive, SD card, media yang perlu dibaca di berbagai device (TV, kamera, console)
8. APFS (Apple File System)
APFS adalah filesystem modern Apple yang menggantikan HFS+.
Karakteristik Utama:
Copy-on-write
Native encryption (full disk, per-file)
Snapshot
Cloning files dan directories
Optimized untuk SSD
Space sharing antar volume
Kelebihan:
Performa sangat baik di SSD
Encryption yang kuat
Snapshot yang efisien
Optimized untuk Apple hardware
Kekurangan:
Hanya untuk macOS/iOS
Tidak ada support resmi di platform lain
Masih relatif baru (2017)
Penggunaan Ideal: macOS devices, iOS devices, Apple ecosystem
Perbandingan dan Rekomendasi Pemilihan
Untuk Desktop Linux:
ext4: Pilihan aman dan stabil
Btrfs: Jika ingin fitur modern dan snapshot
Untuk Server dengan File Besar:
XFS: Performa optimal
ZFS: Jika integritas data prioritas
Untuk Storage/Backup Server:
ZFS: Fitur enterprise terlengkap
Btrfs: Alternatif open-source friendly
Untuk Sharing File:
NFS: Antar Unix/Linux
SMB/CIFS: Cross-platform dengan Windows
Untuk Kompatibilitas Maksimal:
exFAT: External drive
NTFS: Jika dominan Windows
Kesimpulan
Pemilihan filesystem harus disesuaikan dengan kebutuhan spesifik: performa, integritas data, fitur yang dibutuhkan, dan kompatibilitas. Tidak ada filesystem yang sempurna untuk semua skenario. ext4 tetap pilihan solid untuk general purpose, XFS excellent untuk performa file besar, ZFS unggul dalam integritas data dan fitur enterprise, sementara Btrfs menawarkan modernitas dengan dukungan native di Linux.
Jadi hari ini saya memulai training proxmox kembali dengan penuh keseriusan dan saya belum memiliki tulisan mengenai pembuatan NFS yang diintegrasi dengan proxmox. Saat saya mencoba cukup mudah dan minim error, karena di proxmox memang dibantu dengan virtualisasi Web UI nya.
Dalam setup virtualisasi, urusan storage sering jadi hal yang “terasa penting” ketika sudah mulai penuh atau ribet dikelola. Awalnya mungkin masih aman pakai storage lokal di Proxmox, tapi begitu VM mulai banyak, ISO numpuk, dan container bertambah, pengelolaan jadi kurang fleksibel. Di titik ini, biasanya kita mulai butuh storage terpusat.
Di lab kali ini, saya coba setup NFS Server dengan OS Debian 12 yang nantinya akan diintegrasikan ke Proxmox VE. Tujuannya simpel: semua disk VM, ISO, dan template LXC disimpan di satu tempat, jadi lebih mudah dikelola dan bisa dipakai bersama.
Konsep Dasar NFS (Network File System)
NFS (Network File System) adalah protokol yang memungkinkan sebuah server membagikan folder ke client melalui jaringan. Jadi dari sisi client (dalam hal ini Proxmox), folder tersebut terasa seperti storage lokal, padahal sebenarnya berada di server lain.
Dalam implementasi Proxmox, NFS biasanya digunakan untuk:
Menyimpan disk VM
Menyimpan file ISO
Menyimpan template LXC
Cara kerjanya:
Server NFS melakukan export directory
Proxmox mount directory tersebut sebagai storage
Semua data diakses lewat jaringan
Kelebihan NFS:
Setup relatif cepat dan tidak ribet
Native di Linux (tidak perlu tambahan kompleks)
Cocok untuk lab dan skala kecil
Kekurangannya:
Bergantung pada performa jaringan
Tidak sekuat solusi seperti Ceph untuk high availability
1. Persiapan Server NFS
Spesifikasi:
OS: Debian 12
IP Address: 192.168.1.254
Role: NFS Server
Update sistem:
apt update && apt upgrade -y
Set hostname:
hostnamectl set-hostname nfs.server
2. Instalasi NFS Server
Install service NFS:
apt install nfs-kernel-server -y
Output:
Cek service:
systemctl status nfs-server
Output:
3. Pembuatan Directory Share
Saya buat dua direktori utama:
/srv/nfs/vm → untuk disk VM & container
/srv/nfs/iso → untuk ISO & template
mkdir -p /srv/nfs/vm
mkdir -p /srv/nfs/iso
Set permission:
chown -R nobody:nogroup /srv/nfs
chmod -R 777 /srv/nfs
Note: ⚠️ Untuk production, sebaiknya gunakan permission lebih ketat (misalnya berdasarkan UID/GID Proxmox
Upload template Debian (.tar.zst) di tab CT Templates
Atau bisa juga download langsung dari repository Proxmox.
8. Verifikasi di Server NFS
showmount -e
Pastikan ada:
ls /srv/nfs/vm
ls /srv/nfs/iso
Kesimpulan & Tips Teknis
Setup NFS ini sebenarnya cukup “ringan” tapi impact-nya lumayan terasa, terutama kalau mulai banyak VM atau sering bongkar pasang environment lab. Dengan storage terpusat, kita jadi tidak terlalu bergantung pada disk lokal di Proxmox.
Beberapa hal yang sebaiknya diperhatikan dari pengalaman setup ini:
Untuk lab, permission 777 masih oke, tapi jangan dipakai di production.
Usahakan pakai jaringan yang stabil (kalau bisa dipisah khusus storage).
Performa NFS sangat tergantung network, jadi bottleneck biasanya bukan di server.
Kalau mulai scale up, bisa pertimbangkan solusi lain seperti distributed storage.
Backup masih diperlukan, NFS bukan solusi redundancy.
Dengan setup ini, storage Proxmox jadi lebih fleksibel dan enak dipakai untuk eksperimen maupun deployment kecil.
Halo! Jadi saya hari ini sempat bereksperimen dengan server Nextcloud saya, dan merasa perlu mendokumentasikan cara menonaktifkan fitur Talk melalui command line. Siapa tahu kalian juga butuh melakukan hal yang sama.
Ceritanya, saya lagi cek server Nextcloud yang sudah selesai saya instalasi, dan terus menerus selalu liat ini di overview (lihat penjelasan High-performance backend):
Seperti ada yang mengganjal kalo liat tanda silang warna merah. Makanya saya putuskan untuk disable sementara sambil monitoring performa server.
Kebutuhan
Sebelum mulai, pastikan kalian punya:
Server Nextcloud dengan fitur Talk aktif
Akses SSH ke server (saya pakai terminal biasa)
Hak akses sudo atau root
Langkah-Langkah
Langkah 1: Masuk ke Folder Nextcloud
Hal pertama yang saya lakukan adalah navigasi ke direktori instalasi:
cd /var/www/nextcloud
Di setup saya, Nextcloud terinstall di path ini. Kalian bisa cek dulu path milik kalian ya, bisa jadi berbeda seperti /var/www/html/nextcloud atau lokasi lain.
Langkah 2: Disable Talk dengan Perintah OCC
Nah, ini bagian intinya. Saya menggunakan tool occ bawaan Nextcloud:
sudo -u www-data php occ app:disable spreed
Catatan: Nama aplikasinya adalah “spreed”, bukan “talk”. Awalnya saya bingung juga, tapi ternyata itu memang nama internalnya di Nextcloud.
Oh iya, www-data adalah user web server saya. Kalau kalian pakai Nginx atau setup lain, bisa jadi usernya berbeda seperti nginx, apache, atau http. Sesuaikan ya!
Langkah 3: Verifikasi Hasilnya
Setelah menjalankan perintah di atas, saya langsung cek apakah berhasil:
sudo -u www-data php occ app:list
Lihat bagian disabled:
Perintah ini akan menampilkan daftar semua aplikasi. Saya cek bagian “Disabled”, dan Talk (spreed) sudah ada di sana. Sukses!
Mengaktifkan Kembali
Saya juga sudah coba untuk mengaktifkan kembali (sekadar testing), caranya gampang:
CLI
sudo -u www-data php occ app:enable spreed
Jadi kalian nggak perlu khawatir, prosesnya reversible kok.
KendalaLanjutan
Setelah disable, kemudian liat log di web UI ada ini:
Catatan: Ini akan dijelaskan di blog berikutnya.
Kesimpulan
Menonaktifkan Nextcloud Talk via CLI hanya satu baris perintah. Yang penting adalah memahami bahwa nama internal aplikasinya adalah “spreed” dan menggunakan user yang tepat saat menjalankan perintah.
Jadi gini ceritanya, saya lagi instalasi dan optimasi Nextcloud lalu ada satu langkah yang bikin bingung yaitu, setup notify_push. Buat yang belum tau, notify_push ini basically adalah high-performance backend yang bikin client Nextcloud kalian gak perlu terus-terusan “nanya” ke server “apakah update?” setiap 5 menit.
Dengan notify_push ini, server yang bakal push notification ke client. Jadi lebih hemat resource dan lebih cepet. Win-win lah.
Nah setelah install, app-nya udah ada tapi belom jalan. Kemudian, kita perlu setup binary-nya.
Langkah 2: Setup Binary notify_push
App notify_push ini include binary yang harus di-run sebagai service. Binary-nya udah ada di folder app, tinggal kita bikin systemd service-nya.
Terus bikin file systemd service:
nano /etc/systemd/system/notify_push.service
Isi dengan config ini dan sesuaikan path-nya:
Note penting: Saya set ALLOW_SELF_SIGNED=true karena saya pake self-signed certificate dan deploy di lokal saja. Kalau kalian pake SSL/TLS, mungkin gak perlu.
Trusted proxies – Nextcloud strict soal ini. Dan emang harus strict buat security.
Selalu periksa log – Saya sering lupa check log saat error. Padahal tinggal copy /var/log/nextcloud/nextcloud.log atau journalctl -u notify_push. Lalu tanya AI.
Conclusion
Setup notify_push sebenernya cukup mudah kalau semua persyaratan dan setup nya benar. Yang buat saya ribet dan banyak trial dan error adalah:
Self-signed certificate
Trusted proxies belum di deklarasikan
nginx/apache reverse proxy salah config
Tapi once it works, performance improvement-nya noticeable banget. Server load berkurang dan sync jadi real-time.
Sekian tulisan saya, kalau kalian nemuin masalah yang sama atau di langkah-langkah ini, pastikan check log lagi. Masalah bisa solved dengan baca error message dengan teliti.
Helow, kali ini saya mau bahas sedikit soal pengalaman waktu lagi setup Nextcloud, khususnya bagian yang sering dianggap sepele tapi sebenarnya penting pada bagian Overview yaitu security & setup warnings.
Jadi ceritanya, setelah instalasi Nextcloud selesai dan dashboard sudah bisa diakses dengan normal, saya masuk ke menu Administration → Overview. Di situ kelihatannya biasa saja, tapi ternyata ada beberapa warning yang muncul. Salah satu yang selalu keliatan adalah:
Awalnya saya juga tidak terlalu memperhatikan, karena sistem tetap bisa dipakai seperti biasa. Upload file jalan, login normal, tidak ada error yang benar-benar menghentikan sistem. Tapi setelah dibaca lebih detail, ternyata ini bukan sekadar warning biasa, melainkan indikator bahwa ada bagian dari Nextcloud yang belum optimal, khususnya untuk fitur komunikasi.
Apa Itu High-performance Backend?
Untuk memahami ini, kita perlu tahu dulu bahwa Nextcloud bukan cuma sekadar cloud storage. Di dalamnya ada fitur komunikasi real-time yang disebut Nextcloud Talk. Fitur ini memungkinkan pengguna untuk chat, voice call, sampai video conference langsung dari dalam Nextcloud.
Nah, supaya fitur ini bisa berjalan dengan baik, terutama untuk banyak user sekaligus, Nextcloud membutuhkan komponen tambahan yang disebut High-performance backend (HPB).
Kalau komponen ini belum dikonfigurasi, maka Nextcloud akan tetap mengaktifkan Talk, tapi dengan kemampuan yang sangat terbatas sekitar 2-3 user saja.
Kenapa Warning Ini Muncul?
Warning ini muncul karena Nextcloud mendeteksi bahwa:
Fitur Talk aktif
Tidak ada backend khusus yang menangani komunikasi real-time
Secara default, Nextcloud akan menggunakan metode sederhana, yaitu koneksi langsung antar user (peer-to-peer). Metode ini memang cukup untuk penggunaan kecil, tapi tidak dirancang untuk skala yang lebih besar.
Itulah kenapa muncul penjelasan bahwa tanpa high-performance backend, panggilan hanya direkomendasikan untuk maksimal 2–3 peserta.
Penjelasan Teknis
Dalam sistem komunikasi real-time, ada beberapa komponen penting yang biasanya digunakan, seperti:
Signaling server → untuk mengatur koneksi antar user
STUN server → untuk membantu koneksi melewati NAT/firewall
TURN server → sebagai relay jika koneksi langsung gagal
Media server → untuk mengelola aliran audio dan video
Tanpa high-performance backend, sebagian besar fungsi ini tidak berjalan secara optimal atau bahkan tidak tersedia sama sekali. Akibatnya, setiap user harus terhubung langsung ke user lain tanpa perantara yang mengatur traffic.
Masalahnya, semakin banyak peserta, semakin kompleks koneksi yang harus dibangun. Ini menyebabkan:
Beban jaringan meningkat drastis
Kualitas video dan audio tidak stabil
Latensi tinggi
Risiko koneksi terputus
Dengan kata lain, sistem tidak scalable.
Dampak pada User Experience
Kalau Nextcloud hanya digunakan untuk kebutuhan seperti:
Penyimpanan file
Berbagi dokumen
Backup data
Maka warning ini tidak akan terlalu terasa dampaknya.
Namun, ketika mulai digunakan untuk:
Meeting internal tim
Diskusi online
Video conference dengan banyak peserta
Keterbatasannya akan terlihat jelas.
Biasanya gejala yang muncul antara lain:
Video call sering nge-freeze
Delay saat komunikasi
Peserta tidak bisa bergabung
Koneksi tiba-tiba terputus
Ini bukan karena Nextcloud-nya rusak, tapi karena infrastrukturnya belum lengkap.
Kesimpulan
Dari warning yang muncul di halaman Overview tadi, bisa disimpulkan bahwa high-performance backend (HPB) bukanlah error yang menyebabkan sistem gagal berjalan, melainkan peringatan bahwa fitur komunikasi di Nextcloud belum siap untuk digunakan secara optimal, terutama dalam skala banyak pengguna.
Nextcloud tetap bisa digunakan seperti biasa untuk kebutuhan penyimpanan dan berbagi file. Namun, untuk penggunaan yang melibatkan komunikasi real-time seperti video call atau meeting online, keberadaan high-performance backend menjadi sangat penting.
Jadi intinya, ini bukan masalah “Nextcloud error”, tapi lebih ke “Nextcloud belum lengkap konfigurasinya” sesuai dengan kebutuhan aplikasi TALK.
Kurang lebih itu penjelasan dari warning di overview yang muncul. Kasus seperti ini cukup umum, terutama setelah instalasi awal, karena memang banyak fitur Nextcloud yang sifatnya modular dan perlu dikonfigurasi tambahan sesuai kebutuhan. See you next blog.
Helow, kali ini saya mau cerita soal pengalaman mencoba Netdata buat monitoring server. Jujur aja, sebelumnya saya agak males urusan monitoring karena endingnya cuma liat grafik. Tapi setelah nyoba Netdata, ternyata jauh lebih gampang dari yang saya kira. Dalam hitungan menit, dashboard-nya udah jalan dan saya bisa langsung lihat kondisi server secara real-time. Mari kita pelajari bersama langkah-langkahnya.
Apa Itu Netdata?
Netdata adalah tools monitoring server open-source yang bisa kasih kalian informasi real-time tentang kondisi server, mulai dari penggunaan CPU, RAM, disk, jaringan, sampai proses yang lagi berjalan. Semuanya ditampilkan dalam bentuk grafik yang interaktif dan mudah dipahami.
Netdata gratis dan open-source jadi nggak perlu bayar apa-apa, instalasinya super cepat cukup satu perintah langsung jalan, dashboard sudah built-in jadi nggak perlu setup tools tambahan dulu, data ditampilkan real-time per detik bukan per menit, dan cukup ringan di resource sehingga nggak bikin server tambah berat.
Sistem yang digunakan
Linux Ubuntu 22.04,
RAM 1 GB
Storage 1 GB
Langkah 1: Install Netdata
Ini bagian yang paling saya suka: instalasinya cuma satu baris perintah. Nggak perlu download manual, nggak perlu compile dari source. Cukup jalankan ini di terminal server kalian:
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh
Perintah di atas akan otomatis mendeteksi sistem operasi server kalian, menginstall semua dependency yang dibutuhkan, lalu langsung menjalankan Netdata sebagai service.
Proses instalasi biasanya memakan waktu 2 sampai 5 menit tergantung koneksi internet. Waktu pertama kali saya coba, saya sempat kira error karena layarnya penuh teks — tapi ternyata itu normal, itu cuma log proses instalasinya.
Langkah 2: Cek Apakah Netdata Sudah Berjalan
Setelah instalasi selesai, cek dulu status service-nya dengan perintah berikut:
sudo systemctl status netdata
Langkah 3: Akses Dashboard Netdata
Netdata punya web dashboard yang bisa diakses langsung lewat browser. Secara default, dashboard berjalan di port 19999. Buka browser kalian dan akses:
http://IP_SERVER_ATAU_DOMAIN_KALIAN:19999
Kalau berhasil, kalian akan disambut dashboard penuh grafik real-time. Di sana ada ringkasan kondisi server secara keseluruhan, penggunaan CPU per core, penggunaan RAM dan swap, aktivitas baca tulis disk, traffic jaringan masuk dan keluar, serta daftar proses yang sedang berjalan.
Langkah 4: Amankan Dashboard (Penting!)
Secara default, dashboard Netdata bisa diakses siapa saja yang tahu IP server kalian. Ini tidak aman kalau server terhubung ke internet publik. Cara paling sederhana adalah pakai Nginx sebagai reverse proxy dengan basic authentication.
Pertama, install Nginx dan Apache Utils:
sudo apt install nginx apache2-utils -y
Kedua, buat password untuk akses dashboard. Ganti “namauser” dengan username yang kalian mau, lalu kalian akan diminta memasukkan password dua kali:
sudo htpasswd -c /etc/nginx/.htpasswd namauser
Ketiga, buat file konfigurasi Nginx:
sudo nano /etc/nginx/sites-available/netdata
Isi dengan konfigurasi berikut, ganti IP_SERVER_ATAU_DOMAIN_KALIAN sesuai milik kalian:
Sekarang dashboard Netdata hanya bisa diakses dengan username dan password yang tadi kalian buat.
Langkah 5: Kenalan dengan Dashboard Netdata
Oke, dashboard sudah bisa diakses. Tapi banyak grafik dan angka, harus lihat yang mana dulu?
Untuk CPU, lihat bagian System CPU. Kalau angkanya terus-terusan di atas 80-90%, itu tanda ada sesuatu yang berat di server. Scroll ke bagian Processes untuk cari tahu proses mana yang paling banyak gunain CPU-nya.
Untuk Memory, di bagian System RAM perhatikan nilai used dan free. Kalau RAM hampir habis dan swap mulai kepake banyak, itu pertanda server mulai kewalahan.
Untuk Disk, bagian Disk I/O menunjukkan seberapa sibuk aktivitas baca-tulis disk. Kalau grafiknya selalu tinggi, bisa jadi ada database atau aplikasi yang terlalu sering akses disk.
Untuk Network, di bagian Net eth0 kalian bisa lihat traffic masuk (received) dan keluar (sent) secara real-time. Berguna buat deteksi kalau ada traffic yang tidak normal.
Langkah 6: Setup Alert / Notifikasi (Opsional tapi Berguna)
Netdata sudah punya sistem alert bawaan yang bisa kirim notifikasi kalau ada kondisi bahaya di server, misalnya RAM hampir penuh atau disk mau habis. Untuk setup notifikasi via email, edit file konfigurasi berikut:
sudo nano /etc/netdata/health_alarm_notify.conf
Cari baris yang berisi SEND_EMAIL dan ubah seperti ini:
Netdata juga mendukung notifikasi ke Slack, Telegram, dan PagerDuty. Tapi untuk yang simpel, email sudah lebih dari cukup.
Kesimpulan
Netdata beneran bisa jadi tools monitoring terbaik. Yang paling saya suka adalah kemudahan instalasinya, cuma satu perintah, dan dalam beberapa menit dashboard sudah bisa diakses.
Buat kalian yang baru mulai belajar server administration, Netdata bisa jadi titik yang pas untuk mulai kenal dengan monitoring. Kalian bisa langsung lihat kondisi server secara visual tanpa harus hafal perintah top atau htop dulu, walau itu juga tetap penting dipelajari.
Kalau kalian ada pertanyaan atau stuck di salah satu langkah, jangan ragu tulis di kolom komentar ya. Saya juga masih terus belajar, jadi mari kita diskusi bareng. Semoga bermanfaat dan selamat mencoba!