Category: Server

  • Memperbaiki Chrony Setelah Rollback Snapshot VM di Proxmox (Rocky 9)

    Memperbaiki Chrony Setelah Rollback Snapshot VM di Proxmox (Rocky 9)

    Setelah rollback snapshot, jam VM ikut mundur ke waktu snapshot dibuat. Kalau chrony tidak langsung menyinkronkan ulang, jam tetap salah dan service yang sensitif waktu ikut bermasalah. Panduan ini fokus memperbaiki jam lewat chrony di Rocky Linux 9.

    Informasi lab

    KomponenDetail
    HypervisorProxmox VE
    OS VMRocky Linux 9
    Time syncchrony (chronyd)
    Aksesroot atau sudo

    Kenapa chrony tidak otomatis membetulkan

    • Default makestep 1.0 3: chronyd cuma melompatkan (step) jam di 3 update pertama setelah start, sesudah itu hanya slew (koreksi pelan). Selisih besar praktis tidak kekejar.
    • Kalau sumber NTP tak terjangkau (firewall UDP 123, DNS, atau network putus), status chrony Not synchronised dan jam tidak dikoreksi sama sekali.
    • Snapshot include RAM mengembalikan VM dalam keadaan running dengan jatah step chrony sudah habis, jadi jam paling sering nyangkut di kondisi ini.

    1. Cek jam dan status chrony

    timedatectl
    chronyc tracking
    chronyc sources -v

    Tanda bermasalah: System clock synchronized: no, Leap status : Not synchronised, offset besar, atau kolom Reach masih 0. Kalau Reach sudah 377, sumber NTP sehat.

    2. Paksa chrony step jam

    Kalau sumber NTP sudah terjangkau, lompatkan jam ke waktu benar:

    chronyc makestep

    Verifikasi:

    timedatectl

    Diharapkan waktu sudah benar dan System clock synchronized: yes.

    Kalau makestep belum mempan, pakai mode one-shot (ganti pool sesuai kebutuhan):

    systemctl stop chronyd
    chronyd -q 'pool 2.rocky.pool.ntp.org iburst'
    systemctl start chronyd

    3. Kalau sumber NTP tak terjangkau

    Cek konfigurasi:

    cat /etc/chrony.conf

    Pastikan ada baris pool atau server. Default Rocky 9:

    # /etc/chrony.conf
    pool 2.rocky.pool.ntp.org iburst

    Untuk NTP internal, ganti (sesuaikan ntp.domain.lokal):

    # /etc/chrony.conf
    server ntp.domain.lokal iburst

    Terapkan

    systemctl restart chronyd

    Setelah Reach naik, ulangi chronyc makestep.

    Pencegahan

    • Pastikan chronyd aktif: systemctl enable --now chronyd.
    • Pasang QEMU Guest Agent supaya Proxmox bisa menyinkronkan waktu guest setelah snapshot atau resume, lalu aktifkan juga di menu Options VM:
    dnf install qemu-guest-agent -y
    systemctl enable --now qemu-guest-agent
    • Kalau sering rollback, biasakan langsung chronyc makestep sesudahnya.

    Troubleshooting

    GejalaPenyebabSolusi
    System clock synchronized: no, jam mundurSelisih besar, chrony cuma slewchronyc makestep
    Reach 0 atau sumber ?Sumber NTP tak terjangkauPerbaiki chrony.conf, buka UDP 123, lalu makestep
    Jam mundur lagi tiap rollbackSnapshot include RAM atau guest agent matiAktifkan qemu-guest-agent, biasakan makestep

    Penutup

    Kalau ada service bermasalah sesudah rollback, cek jam dan chrony dulu sebelum menyalahkan aplikasinya. Semoga bermanfaat.

    Referensi

    • Chrony Frequently Asked Questions: https://chrony.tuxfamily.org/faq.html
    • Manual: man chrony.conf dan man chronyc
  • 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.

  • 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.

  • 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!

  • Menambahkan OSD Baru dan Mengatur Class SSD/HDD pada Ceph

    Menambahkan OSD Baru dan Mengatur Class SSD/HDD pada Ceph

    Hari ini saya mencoba melanjutkan latihan pada cluster Proxmox yang sudah saya bangun sebelumnya. Saya menulis catatan ini karena saya merasa masih perlu banyak latihan dan troubleshooting, terutama pada bagian storage. Saat ini saya memang masih sering menemukan hal-hal yang perlu saya pahami lebih dalam, baik di Nextcloud maupun di Ceph, sehingga saya ingin mendokumentasikan setiap percobaan yang saya lakukan supaya alurnya tidak hilang dan bisa saya pelajari ulang ketika dibutuhkan.

    Tujuan percobaan hari ini adalah menambahkan disk baru pada Proxmox, menjadikannya sebagai OSD Ceph, lalu mengatur class storage supaya bisa dibedakan antara SSD dan HDD. Hal ini penting karena di lingkungan storage seperti Ceph, pengelompokan disk berdasarkan class sangat membantu untuk mengatur distribusi data, menentukan pool, dan memisahkan storage yang dipakai untuk kebutuhan cepat dan kebutuhan biasa. Dengan begitu, saya bisa mulai memahami bagaimana Ceph bekerja bukan hanya sebagai storage cluster, tetapi juga sebagai sistem yang mengatur penempatan data berdasarkan aturan tertentu.


    1. Mengecek disk baru yang tersedia

    Langkah pertama yang saya lakukan adalah memastikan disk baru benar-benar terdeteksi di node. Saya cek dengan lsblk.

    lsblk | grep sdd

    Dari hasil pengecekan, disk sdd muncul sebagai disk 20 GB. Ini menandakan bahwa disk tersebut sudah terbaca oleh sistem dan siap untuk dipakai sebagai kandidat OSD.

    Pada tahap ini saya hanya memastikan disk baru tersedia dan belum dipakai oleh partisi lama, LVM, atau Ceph. Ini penting karena kalau disk masih memiliki sisa konfigurasi lama, proses pembuatan OSD bisa gagal atau menghasilkan status yang tidak sehat.


    2. Membuat OSD baru dari disk tersebut

    Setelah yakin disk tersedia, saya langsung mencoba menjadikannya OSD dengan ceph-volume.

    ceph-volume lvm create --data /dev/sdd

    Dari output yang muncul, terlihat bahwa physical volume berhasil dibuat di /dev/sdd.

    Saya memahami bahwa perintah ini cukup penting karena Ceph akan menangani proses pembuatan LVM dan OSD secara otomatis. Jadi saya tidak perlu membuat PV, VG, atau LV satu per satu secara manual. Dengan ceph-volume, proses pembuatan OSD menjadi lebih singkat dan terstruktur.


    3. Mengecek hasil OSD di cluster

    Setelah OSD dibuat, saya cek lagi struktur OSD yang ada dengan:

    ceph osd tree

    Dari hasil ini saya melihat bahwa OSD baru sudah masuk ke cluster dan statusnya up. Namun, class yang digunakan masih default, yaitu hdd.

    Di tahap ini saya membuktikan bahwa OSD baru memang sudah berhasil bergabung ke cluster. Artinya disk baru tidak hanya terbaca di sistem, tetapi juga sudah dikenal oleh Ceph sebagai bagian dari storage cluster.


    4. Mencoba mengubah class OSD menjadi SSD

    Karena saya ingin mensimulasikan pemisahan storage antara HDD dan SSD, saya mencoba mengubah salah satu OSD menjadi class SSD.

    ceph osd crush set-device-class ssd osd.3

    Namun ternyata muncul error bahwa OSD tersebut sudah terikat pada class hdd, sehingga class tidak bisa langsung diganti.

    Dari sini saya belajar bahwa Ceph tidak mengizinkan class OSD diubah secara langsung jika OSD tersebut sudah memiliki class sebelumnya. Jadi saya tidak bisa langsung melakukan perubahan dari hdd ke ssd tanpa menghapus class lama terlebih dahulu. Ini cukup penting karena saya sempat mengira class bisa diganti begitu saja.


    5. Menghapus class lama terlebih dahulu

    Untuk mengatasi error tadi, saya terlebih dahulu menghapus class yang lama.

    ceph osd crush rm-device-class osd.3

    Setelah perintah ini dijalankan, Ceph menghapus class yang menempel pada OSD tersebut.

    Langkah ini menunjukkan bahwa perubahan class di Ceph harus dilakukan secara berurutan. Saya harus membersihkan label class lama sebelum menetapkan class baru. Jadi alurnya bukan langsung mengganti, tetapi hapus dulu lalu set ulang.


    6. Menetapkan class baru menjadi SSD

    Setelah class lama dihapus, barulah saya bisa menetapkan class baru untuk osd.3, osd.4 dan osd.5.

    ceph osd crush set-device-class ssd osd.3

    Setelah itu saya cek kembali hasilnya dengan ceph osd tree.

    Pada titik ini saya berhasil mengubah OSD tersebut menjadi class SSD. Ini penting karena sekarang saya bisa mulai memisahkan storage berdasarkan jenis disk, walaupun di lab ini semua masih berupa simulasi. Hasil akhirnya, di cluster saya ada OSD dengan class HDD dan ada OSD dengan class SSD.


    7. Hasil akhir pembagian class OSD

    Setelah dicek kembali, hasil akhirnya menjadi seperti ini:

    • rafi1
      • osd.0 → hdd
      • osd.3 → ssd
    • rafi2
      • osd.2 → hdd
      • osd.4 → ssd
    • rafi3
      • osd.1 → hdd
      • osd.5 → ssd

    Dari hasil ini saya berhasil membuat simulasi storage tiering sederhana. Dengan adanya pemisahan class, saya bisa melanjutkan ke tahap berikutnya yaitu membuat CRUSH rule dan pool berdasarkan class tersebut. Ini membuka jalan agar saya bisa memisahkan storage cepat dan storage biasa dalam satu cluster Ceph.


    Dari percobaan hari ini, saya mendapatkan beberapa poin penting:

    Pertama, disk baru harus dipastikan benar-benar terbaca dan bersih sebelum dijadikan OSD. Kedua, ceph-volume sangat membantu karena proses pembuatan OSD bisa dilakukan otomatis. Ketiga, class OSD di Ceph tidak bisa langsung diganti, sehingga saya harus menghapus class lama terlebih dahulu sebelum menetapkan class baru. Keempat, pembagian class seperti SSD dan HDD sangat berguna untuk menyiapkan struktur storage yang lebih rapi dan mudah diatur.


    Akhir Kata

    Percobaan hari ini membuat saya lebih paham bagaimana Ceph mengelola OSD dan class storage. Walaupun terlihat sederhana, ternyata ada alur yang harus diikuti dengan benar supaya hasilnya sesuai. Saya juga jadi lebih mengerti bahwa Ceph sangat ketat dalam hal metadata storage, terutama saat mengatur device class.

    Catatan ini saya buat sebagai dokumentasi pribadi supaya ketika saya mengulang setup ini lagi, saya tidak perlu menebak-nebak dari awal. Ke depannya mungkin saya melanjutkan ke pembuatan CRUSH rule, pool berdasarkan class, lalu menghubungkannya dengan pengujian VM dan storage yang lebih real.

  • Backup File ke PBS Menggunakan proxmox-backup-client

    Backup File ke PBS Menggunakan proxmox-backup-client

    Hari ini saya melanjutkan training Proxmox VE, dan seperti biasa, saya mencoba mensimulasikan skenario yang mendekati kondisi production. Kali ini yang saya uji adalah backup file langsung dari dalam VM menggunakan Proxmox Backup Client, bukan hanya backup VM atau LXC ke PBS seperti biasanya, tapi backup folder spesifik seperti /etc langsung dari dalam sistem operasi guest.

    Setup lab saya waktu itu cukup sederhana:

    Semuanya terlihat lancar sampai saya jalanin perintah ini:

    Command:

    apt install proxmox-backup-client

    Output nya malah:

    Saya sempat bingung. Ini fitur Proxmox, tapi kenapa tidak ada di Ubuntu?


    Penyebabnya

    Setelah saya telusuri dan tanya-tanya AI, jawabannya ternyata sederhana, “Ubuntu tidak memiliki repository Proxmox secara default.”

    Paket proxmox-backup-client memang tidak ada di repo bawaan Ubuntu. Jadi apt tidak tahu harus mengambilnya dari mana. Ini berbeda dengan node Proxmox VE atau PBS yang sudah menyertakan repository mereka sendiri sejak awal instalasi.

    Di sinilah saya mulai memahami satu hal yang sebelumnya tidak terlalu saya perhatikan, ekosistem Proxmox tidak bergantung pada repository Ubuntu atau Debian standar. Proxmox punya repository sendiri, dan kalau kita ingin menggunakan tool seperti Proxmox Backup Client di luar ekosistem itu, kita harus menambahkan repository-nya secara manual.


    Langkah-langkah

    Berikut cara yang saya gunakan sampai akhirnya berhasil:

    1. Tambahkan repository Proxmox Backup Client

    echo "deb http://download.proxmox.com/debian/pbs-client bookworm main" > /etc/apt/trusted.gpg.d/pbs-client.list

    2. Tambahkan GPG key

    wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release.gpg

    3. Update package list

    apt update

    4. Install ulang

    apt install proxmox-backup-client

    Setelah itu, instalasi berjalan tanpa error. Verifikasi dengan menjalankan:

    proxmox-backup-client version

    Output versi muncul — client sudah siap digunakan.


    Percobaan Backup

    Kemudian saya langsung jalankan backup folder /etc dengan command:

    proxmox-backup-client backup etc.pxar:/etc --repository pvebackup@pbs@192.168.X.X:pbsstore

    Hasilnya: backup berhasil, file muncul di datastore PBS, dan bisa dilihat langsung dari web UI. Persis seperti yang diharapkan.


    Catatan

    Pertama, soal repository. Ubuntu 24.04, meskipun sudah modern, tidak secara otomatis menyertakan paket-paket dari ekosistem Proxmox. Kita perlu menambahkan repository-nya sendiri.

    Kedua, soal versi codename. Harus menggunakan bookworm karena Proxmox berbasis Debian Bookworm, dan repository PBS Client pun mengikuti codename yang sama. Ini penting agar tidak terjadi konflik dependensi.

    Ketiga, dan ini yang paling saya highlight, error ini bukan sesuatu yang salah. Ini normal, dan banyak orang yang baru masuk ke dunia Proxmox pasti akan menemuinya.


    Akhir Kata Rafi

    Dari uji coba hari ini, saya jadi lebih paham bahwa belajar Proxmox bukan hanya tentang virtualisasi atau manajemen VM. Ada sisi ekosistem yang perlu dipahami juga, mulai dari bagaimana repository-nya bekerja, sampai bagaimana tool seperti PBS Client berinteraksi dengan sistem operasi guest.

    Seharusnya sih saya menulis tentang cara pembuatan PBS dulu ya. Tapi tidak apa lah ini untuk catatan saya untuk kedepannya. Kalau kalian sedang di tahap yang sama, sedang mengeksplorasi PBS dan ingin mencoba backup client langsung dari dalam VM — kemungkinan besar kamu juga akan menemui error yang sama. Semoga tulisan ini bisa menghemat waktu yang biasanya habis untuk trial and error.

  • Memahami Swap Usage di Linux

    Memahami Swap Usage di Linux

    Setiap kali saya login ke server, selalu muncul informasi seperti system load, CPU usage, memory usage, sampai swap usage. Awalnya saya hanya melihat sekilas tanpa terlalu memperhatikan, tapi lama-lama jadi penasaran, terutama di bagian swap usage yang angkanya kadang terlihat cukup besar dibanding yang lain.

    Kalau system load atau memory usage masih cukup mudah dipahami, swap ini terasa agak “abu-abu”. Kadang nilainya tinggi, tapi server tetap terasa normal, tidak ada tanda-tanda lambat atau error. Dari situ mulai muncul pertanyaan, sebenarnya swap ini apa, kenapa bisa terpakai, dan apakah itu sesuatu yang harus dikhawatirkan atau tidak.

    Karena penasaran, saya akhirnya coba cari tahu lebih dalam, bukan hanya dari sisi definisi, tapi juga bagaimana cara kerjanya di sistem Linux. Di sini saya jelaskan dari konsep sampai teknis, pakai sudut pandang real case supaya lebih mudah dipahami dan tidak terasa terlalu teoritis.


    Apa Itu Swap?

    Swap adalah bagian dari storage (disk) yang dipakai sebagai “memori cadangan” ketika RAM mulai penuh. Di sistem seperti Ubuntu, swap bisa berupa file atau partisi.

    Secara sederhana:

    • RAM = cepat
    • Swap = lambat (karena di disk)

    Ketika RAM tidak cukup, sistem akan memindahkan sebagian data dari RAM ke swap supaya sistem tetap jalan.


    Cara Kerja Swap (Technically)

    Linux menggunakan konsep virtual memory. Artinya, setiap proses tidak benar-benar tahu apakah datanya ada di RAM atau di swap.

    Ketika RAM mulai penuh:

    1. Kernel akan mencari data yang jarang dipakai
    2. Data tersebut dipindahkan ke swap
    3. RAM jadi kosong untuk proses yang aktif

    Kalau data yang sudah dipindahkan itu dibutuhkan lagi:

    1. Sistem akan ambil dari swap
    2. Dimasukkan kembali ke RAM

    Masalahnya, proses ini jauh lebih lambat dibanding akses RAM, karena disk I/O jauh lebih lambat dari memory access.


    Mengapa Swap bisa terpakai padahal RAM banyak?

    Ini salah satu hal yang paling sering membingungkan. Secara logika, kalau RAM masih banyak, seharusnya swap tidak digunakan. Tapi kenyataannya tidak begitu.

    Misalnya:

    • RAM sempat penuh sebelumnya
    • Sistem memindahkan data ke swap

    Setelah itu:

    • RAM sudah lega lagi
    • Tapi data di swap tidak langsung dipindahkan balik

    Jadi kondisi seperti ini bisa terjadi:

    • RAM masih banyak tersedia
    • Tapi swap usage tetap tinggi

    Ini normal behavior di Linux, bukan bug.


    Apa harus khawatir saat Swap tinggi?

    Swap usage sering disalahartikan sebagai indikator bahwa server sedang dalam kondisi buruk. Padahal tidak selalu seperti itu. Nilai swap yang tinggi tidak otomatis berarti sistem bermasalah.

    Kondisi normal

    • Swap terpakai sedikit
    • Sistem tetap responsif

    Kondisi tidak normal

    • Swap tinggi
    • Server terasa lambat
    • Banyak delay saat akses aplikasi

    Biasanya ini terjadi kalau:

    • RAM memang kurang
    • Aplikasi terlalu berat
    • Atau konfigurasi tidak optimal

    Jadi swap usage lebih tepat dilihat sebagai indikator tambahan, bukan satu-satunya acuan.


    Swappiness: Seberapa Agresif Swap Digunakan

    Linux punya parameter bernama swappiness. Ini menentukan seberapa cepat sistem mulai menggunakan swap.

    Cek nilai:

    # cat /proc/sys/vm/swappiness

    Nilai default biasanya:

    Interpretasi:

    • Nilai tinggi → swap lebih sering dipakai
    • Nilai rendah → lebih mengutamakan RAM

    Untuk VPS kecil, biasanya lebih aman pakai:

    vm.swappiness=10

    Tujuannya supaya sistem tidak terlalu cepat “buang data” ke swap.

    Ubah dengan command:

    # sysctl vm.swappiness=10


    Melihat Penggunaan Swap

    Ketikkan di CLI:

    # free -h

    Output:

    Artinya:

    • Total swap: 255MB
    • Terpakai: 200MB
    • Padahal penggunaan RAM 437 MB dan available ~523 MB

    Reset Swap

    Kalau swap sudah tinggi tapi RAM sebenarnya masih lega, kamu bisa reset swap:

    # swapoff -a && swapon -a

    Apa yang terjadi:

    • Semua data di swap dipindahkan kembali ke RAM
    • Swap jadi kosong

    Catatan:
    Pastikan RAM cukup sebelum menjalankan ini.


    Jenis Swap: File vs Partisi

    1. Swap Partition

    • Dibuat saat install OS
    • Lebih stabil
    • Lebih jarang dipakai di VPS modern

    2. Swap File

    • Dibuat manual
    • Fleksibel (bisa resize)
    • Paling umum di VPS

    Contoh membuat swap file:

    fallocate -l 512M /swapfile
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile

    Kapan Swap Dibutuhkan

    Swap tetap penting, terutama di VPS kecil:

    • Mencegah sistem crash saat RAM habis
    • Memberi “buffer” untuk lonjakan beban
    • Menghindari OOM (Out Of Memory Killer)

    Tanpa swap, kalau RAM habis:

    • proses bisa langsung dimatikan paksa

    Akhir Kata Rafi

    Swap bukan musuh, tapi juga bukan sesuatu yang bisa diabaikan.

    • Swap adalah backup saat RAM tidak cukup
    • Swap lambat karena berbasis disk
    • Swap usage tinggi tidak selalu berarti masalah
    • Tapi kalau disertai lag, itu tanda harus optimasi

    Untuk VPS kecil:

    • gunakan swap secukupnya
    • turunkan swappiness
    • dan pastikan konfigurasi service efisien

    Kalau dipahami dengan benar, swap justru membantu menjaga sistem tetap stabil, bukan sebaliknya.