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
Komponen
Detail
Hypervisor
Proxmox VE
OS VM
Rocky Linux 9
Time sync
chrony (chronyd)
Akses
root 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):
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.
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.
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!
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.
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.
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:
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.
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:
Kernel akan mencari data yang jarang dipakai
Data tersebut dipindahkan ke swap
RAM jadi kosong untuk proses yang aktif
Kalau data yang sudah dipindahkan itu dibutuhkan lagi:
Sistem akan ambil dari swap
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.