Category: IT

  • Seharian Troubleshoot Error I/O di PBS

    Seharian Troubleshoot Error I/O di PBS

    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.

    Coba via CLI:

    proxmox-backup-manager datastore create s3-datastore /mnt/s3-datastore \
        --comment "S3 Backup Storage via MinIO"
    

    Output:

    TASK ERROR: EIO: I/O error

    Sama saja.


    Ternyata Write Biasa ≠ Write yang PBS Lakukan

    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.

  • Implementasi Proxmox Backup Server pada Proxmox VE

    Implementasi Proxmox Backup Server pada Proxmox VE

    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

    KomponenMinimum
    vCPU2 core
    RAM4 GB
    Disk OS32 GB
    Disk BackupSesuai kebutuhan
    NetworkVirtIO, 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

    FieldKeterangan
    IDNama storage di Proxmox VE
    ServerIP address VM PBS
    UsernameUser PBS (format: user@realm)
    PasswordPassword user PBS
    NodesSemua node cluster bisa akses
    ContentTipe konten yang disimpan
    DatastoreNama datastore yang dibuat tadi
    NamespaceNamespace PBS (default)
    FingerprintWajib 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

    FiturBackup NFS/LocalProxmox Backup Server
    Deduplication❌✅ (chunk-level)
    Enkripsi end-to-end❌✅
    Incremental backupTerbatas✅ (via dirty-bitmap)
    Verifikasi integritas❌✅ (built-in verify job)
    Retention managementManual✅ (otomatis)
    Dedicated Web UI❌✅
    Backup saat VM runningTergantung 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.

  • Import VM dari VMware ke Proxmox VE

    Import VM dari VMware ke Proxmox VE

    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:

    1. Akses ke VMware ESXi/vCenter
      • Username dan password (minimal user biasa, tapi lebih baik root)
      • Bisa login ke web interface
    2. Proxmox yang sudah jalan
      • Minimal 1 node (di tutorial ini saya pakai 3 node)
      • Storage dengan space yang cukup
    3. 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.


    Langkah 4 — Konfigurasi Import Guest

    Dialog “Import Guest” akan muncul. Sesuaikan parameter berikut (berdasarkan screenshot kamu):

    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.

  • Menambah ZFS Storage ke Proxmox VE

    Menambah ZFS Storage ke Proxmox VE

    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)

    Artinya:

    • sda = jangan disentuh
    • sdb = yang baru saja ditambah sebelumnya

    Output:


    STEP 1 — Buat ZFS Pool di rafi1

    Kalian sudah menjalankan:

    zpool create -f zfs-pool /dev/sdb

    Lalu cek:

    zpool status

    Output:

    Ini artinya:

    • ZFS berhasil dibuat
    • Disk sudah masuk ke pool
    • Tidak ada error

    STEP 2 — Tambahkan ke Proxmox Storage (rafi1)

    Kalian jalankan:

    pvesm add zfspool zfs-pool \
    --pool zfs-pool \
    --content images,rootdir

    Cek:

    pvesm status

    Output:

    Artinya:

    • Storage sudah dikenali Proxmox
    • Bisa dipakai untuk VM

    STEP 3 — Ulangi disetiap node (rafi2)

    Di rafi2, kalian jalankan:

    pvesm status

    Output:

    Catatan:

    • ZFS pool itu harus dibuat manual di tiap node

    STEP 4 — Ulangi disetiap node (rafi3)

    Langkah di rafi3 sama persis:

    zpool create -f zfs-pool /dev/sdb
    pvesm status

    Output:


    STEP 5 — Verifikasi

    Dan di tiap node:

    zpool list

    Harus sama:


    Kesimpulan

    Dari screenshot yang kalian kirim, kita bisa tarik kesimpulan:

    Yang sudah benar:

    • ZFS di rafi1,rafi2,rafi3 sudah dibuat
    • Storage sudah terdaftar
    • Status sudah active

    Insight Penting (ini yang sering bikin bingung)

    pvesm status = hanya config
    zpool status = kondisi real di node

    Jadi:

    • pvesm bisa bilang OK
    • Tapi kalau zpool tidak ada → tetap error

    Penutup dan Tips Rafi

    Dari pengalaman saya, kesalahan paling sering itu:

    • Mengira storage sudah siap hanya dari pvesm status
    • Padahal ZFS belum dibuat di semua node

    Tips dari saya:

    • Selalu cek zpool list di setiap node
    • Samakan nama pool dari awal
    • Gunakan disk yang konsisten (sdb di semua node kalau bisa)
    • Jangan campur nama (tank, zfs-pool, dll)
  • Mengenal Berbagai Tipe Filesystem

    Mengenal Berbagai Tipe Filesystem

    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.

  • Instalasi NFS Server (VM dan ISO) di Proxmox VE

    Instalasi NFS Server (VM dan ISO) di Proxmox VE

    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

    Output:


    4. Konfigurasi Export NFS

    Edit file:

    nano /etc/exports

    Tambahkan:

    /srv/nfs/vm 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
    /srv/nfs/iso 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

    Apply konfigurasi:

    exportfs -a
    systemctl restart nfs-server

    Cek:

    exportfs -v


    5. Integrasi NFS ke Proxmox

    Masuk ke Web UI Proxmox VE

    5.1 Storage ISO & Template

    • Datacenter → Storage → Add → NFS
    • ID: nfs-iso
    • Server: 192.168.1.254
    • Export: /srv/nfs/iso
    • Content:
      • ISO Image
      • Container Template

    5.2 Storage Disk VM

    • Datacenter → Storage → Add → NFS
    • ID: nfs-vm
    • Server: 192.168.1.254
    • Export: /srv/nfs/vm
    • Content:
      • Disk Image
      • Container

    6. Upload ISO dan Template

    Setelah storage muncul di Proxmox:

    • Upload ISO Alpine di tab ISO Images
    • 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.

  • Menonaktifkan Fitur Talk Nextcloud via CLI

    Menonaktifkan Fitur Talk Nextcloud via CLI

    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.

    Kendala Lanjutan

    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.

  • Cara Setup Notify Push di Nextcloud

    Cara Setup Notify Push di Nextcloud

    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.

    Pengecekan Awal

    Sebelum mulai, pastiin dulu kalian udah punya:

    • Nextcloud yang udah jalan (obviously)
    • Redis server yang udah configured
    • nginx atau apache sebagai web server
    • Akses root ke server

    Langkah 1: Install App notify_push

    Jalanin dari command line:

    sudo -u www-data php /var/www/nextcloud/occ app:install notify_push

    Output

    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.

    Terus reload systemd dan start service-nya:

    systemctl daemon-reload
    systemctl enable notify_push
    systemctl start notify_push
    systemctl status notify_push

    Kalau status-nya “active (running)” berarti oke!


    Langkah 3: Configure nginx (Reverse Proxy)

    Nah ini yang krusial. notify_push butuh endpoint di web server untuk bisa diakses dari luar.

    Buka config nginx Nextcloud kalian (di saya ada di /etc/nginx/conf.d/nextcloud.conf):

    nano /etc/nginx/conf.d/nextcloud.conf

    Tambahkan location block ini sebelum closing brace terakhir:

    PENTING: Pastikan kedua trailing slash-nya ada! Yang di /push/ dan yang di http://127.0.0.1:7867/. Kalau kurang bisa error 404.

    Reload nginx:

    systemctl reload nginx

    Langkah 4: Nextcloud and Push Server

    Sekarang kita kasih tau Nextcloud dimana push server-nya (untuk multi-server gunakan ip/domain server yang sudah disetup notify_push):

    sudo -u www-data php /var/www/nextcloud/occ notify_push:setup https://IP_ATAU_DOMAIN_PUSH_SERVER/push

    Kalau semua oke, kalian bakal liat checklist hijau dan tulisan ‘configuration saved’


    Verifikasi dengan Self-Test

    Jalanin self-test:

    sudo -u www-data php /var/www/nextcloud/occ notify_push:self-test

    Outputnya mungkin sama seperti sebelumnya, namun ini hanya pengecekan kembali. Ini bakal verifikasi semua komponen berfungsi dengan baik.

    Lessons Learned

    1. Read the documentation – Karena dari dokumentasi lah kita tau gambaran besar permasalahannya.
    2. Self-signed certificate ribet – Kalau bisa, pakai Let’s Encrypt untuk testing saja.
    3. Trusted proxies – Nextcloud strict soal ini. Dan emang harus strict buat security.
    4. 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.


    Referensi


    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.

  • Penjelasan Error High-performance Backend Nextcloud Talk

    Penjelasan Error High-performance Backend Nextcloud Talk

    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.

  • Monitoring Server Menggunakan Netdata

    Monitoring Server Menggunakan Netdata

    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:

    server {
        listen 80;
        server_name IP_SERVER_ATAU_DOMAIN_KALIAN;
    
        location / {
            auth_basic "Netdata Dashboard";
            auth_basic_user_file /etc/nginx/.htpasswd;
    
            proxy_pass http://127.0.0.1:19999;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_read_timeout 300;
        }
    }

    Keempat, aktifkan konfigurasinya:

    sudo ln -s /etc/nginx/sites-available/netdata /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl restart nginx

    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:

    SEND_EMAIL="YES"
    DEFAULT_RECIPIENT_EMAIL="emaikalian@gmail.com"

    Simpan file, lalu restart Netdata:

    sudo systemctl restart netdata

    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!