Storage Tingkat Lanjut

Server yang kehabisan ruang disk di tengah malam, database yang butuh tambahan kapasitas tanpa boleh mati sedetik pun, atau satu disk yang tiba-tiba rusak dan membawa serta seluruh data production, semua skenario ini adalah kenyataan sehari-hari yang dihadapi Sysadmin begitu server naik ke tahap production. Partisi statis ala instalasi desktop yang "sekali pasang lalu dilupakan" tidak lagi memadai. Server production butuh storage yang bisa tumbuh, bertahan dari kegagalan hardware, dan dipantau kesehatannya sebelum masalah benar-benar terjadi.

Bab ini membahas empat pilar storage tingkat lanjut yang wajib dikuasai Sysadmin: LVM untuk fleksibilitas volume, RAID software untuk redundansi dan performa, prosedur menambah disk baru ke server yang sedang berjalan tanpa downtime, serta kebiasaan memantau kesehatan fisik disk melalui smartctl sebelum kegagalan benar-benar terjadi. Kita juga akan membahas satu perubahan default Ubuntu yang sering luput dari perhatian: /tmp yang kini berjalan di atas tmpfs.

7.1 Review Partisi dan Filesystem

Setiap disk yang dikenali Linux perlu dibagi ke dalam satu atau lebih partisi sebelum bisa diisi data, dan setiap partisi butuh filesystem yang menentukan bagaimana data disusun, dibaca, dan ditulis di dalamnya. Tabel partisi modern memakai skema GPT (GUID Partition Table), yang sudah menjadi default instalasi Ubuntu Server sejak beberapa rilis terakhir karena mendukung disk berkapasitas besar dan jumlah partisi yang jauh lebih fleksibel dibanding skema MBR lama yang dibatasi hanya empat partisi utama.

Untuk filesystem, ext4 tetap menjadi pilihan default Ubuntu Server karena kematangan, stabilitas, dan tooling recovery yang sudah teruji bertahun-tahun. XFS menjadi alternatif yang sering dipilih untuk workload dengan file berukuran besar dan I/O paralel tinggi, seperti server database atau media, karena performanya yang unggul pada skenario tersebut. Satu batasan penting yang perlu diingat: XFS mendukung operasi grow (memperbesar) secara online, tetapi tidak mendukung shrink (memperkecil) sama sekali. Jika ada kemungkinan volume perlu diperkecil di masa depan, ext4 adalah pilihan yang lebih aman.

Verifikasi Cepat

lsblk -f
df -hT
sudo blkid

lsblk -f menampilkan struktur disk, partisi, dan filesystem beserta UUID-nya dalam satu tampilan pohon yang ringkas. df -hT menunjukkan ruang yang terpakai dan tersisa di setiap mount point beserta tipe filesystem-nya. blkid berguna saat kita butuh UUID partisi secara spesifik, misalnya untuk menuliskan entri /etc/fstab yang akan kita praktikkan pada Bagian 7.4.

7.2 Logical Volume Manager (LVM) Mendalam

Partisi biasa bersifat kaku: begitu dibuat dengan ukuran tertentu, memperbesarnya berarti berurusan dengan disk fisik secara langsung, dan memperkecilnya nyaris selalu berisiko kehilangan data. LVM (Logical Volume Manager) menambahkan lapisan abstraksi di atas disk fisik sehingga ukuran volume menjadi fleksibel, bisa digabung dari beberapa disk, dan bisa diubah kapan saja tanpa membongkar ulang partisi. Seperti yang sudah disinggung pada Bab 2, installer Subiquity Ubuntu Server memakai LVM secara default pada opsi guided partitioning, jadi kemungkinan besar server yang kita kelola sudah berjalan di atas LVM sejak hari pertama.

7.2.1 Physical Volume, Volume Group, Logical Volume

LVM bekerja dengan tiga lapisan konsep. Physical Volume (PV) adalah disk atau partisi fisik yang "didaftarkan" ke LVM. Beberapa PV kemudian digabung menjadi satu Volume Group (VG), yaitu kumpulan ruang penyimpanan gabungan yang diperlakukan sebagai satu pool besar. Dari VG inilah kita mengiris ruang menjadi satu atau lebih Logical Volume (LV), yang barulah diformat dengan filesystem dan di-mount seperti partisi biasa.

Langkah Praktik

1. Pastikan tool LVM sudah terpasang. Pada instalasi dengan LVM sejak awal, package ini sudah ada secara default.

   sudo apt update
   sudo apt install lvm2

2. Daftarkan disk baru (misalnya /dev/sdb yang masih kosong) sebagai Physical Volume.

   sudo pvcreate /dev/sdb
   sudo pvs

3. Buat Volume Group dari Physical Volume tersebut.

   sudo vgcreate vg_data /dev/sdb
   sudo vgs

4. Iris Volume Group menjadi Logical Volume dengan ukuran yang kita tentukan.

   sudo lvcreate -L 20G -n lv_data vg_data
   sudo lvs

5. Format Logical Volume dengan filesystem, lalu mount seperti partisi biasa.

   sudo mkfs.ext4 /dev/vg_data/lv_data
   sudo mkdir -p /mnt/data
   sudo mount /dev/vg_data/lv_data /mnt/data

Di lapangan, praktik yang jauh lebih fleksibel adalah membiarkan sebagian ruang VG tidak langsung dialokasikan ke LV mana pun saat pertama kali membuatnya. Ruang cadangan ini menjadi "tabungan" yang bisa langsung dipakai untuk resize darurat tanpa perlu menambah disk fisik baru terlebih dahulu, sebuah kebiasaan yang akan terasa manfaatnya pada Bagian 7.2.2 berikut.

7.2.2 Resize Volume tanpa Downtime

Keunggulan utama LVM dibanding partisi biasa adalah kemampuan memperbesar Logical Volume sambil filesystem tetap ter-mount dan aplikasi tetap berjalan menulis data ke atasnya, tanpa perlu unmount apalagi reboot. Ini menjadikan LVM pilihan wajib untuk volume data aplikasi atau database yang tidak bisa ditoleransi downtime-nya.

Langkah Praktik

1. Jika Volume Group masih memiliki ruang bebas, langsung perbesar Logical Volume dan filesystem-nya sekaligus menggunakan flag -r, yang otomatis memanggil resize2fs (untuk ext4) atau xfs_growfs (untuk XFS) di baliknya.

   sudo lvextend -L +10G -r /dev/vg_data/lv_data

2. Jika ruang bebas di VG sudah habis, tambahkan Physical Volume baru ke VG terlebih dahulu sebelum memperbesar LV.

   sudo pvcreate /dev/sdc
   sudo vgextend vg_data /dev/sdc
   sudo lvextend -L +20G -r /dev/vg_data/lv_data

Verifikasi dan Troubleshooting

• Konfirmasi ukuran baru sudah tercermin di level filesystem, bukan hanya di level LVM.

  df -h /mnt/data
  sudo lvs vg_data

• Mengecilkan (shrink) Logical Volume adalah operasi yang jauh lebih berisiko dibanding memperbesarnya, terutama untuk ext4 yang mengharuskan filesystem di-unmount terlebih dahulu, diperiksa integritasnya dengan e2fsck -f, baru kemudian resize2fs mengecilkan filesystem-nya sebelum lvreduce mengecilkan LV-nya di belakangnya. Urutan ini tidak boleh dibalik, karena mengecilkan LV lebih dulu sebelum filesystem-nya selesai menyusut akan memotong data yang masih terpakai. Untuk XFS, shrink bahkan tidak didukung sama sekali seperti sudah disinggung pada Bagian 7.1. Selalu backup data penting sebelum mencoba operasi shrink, sekecil apa pun risikonya terlihat.
• Praktik paling aman di lapangan: jangan pernah mengalokasikan 100 persen ruang VG ke satu LV sejak awal. Sisakan minimal beberapa persen sebagai buffer, karena resize LVM jauh lebih sederhana dibanding menambah disk fisik baru secara mendadak saat kapasitas benar-benar kritis.

7.2.3 Snapshot LVM

Snapshot LVM adalah salinan "beku" dari kondisi Logical Volume pada satu titik waktu tertentu, dibuat nyaris instan menggunakan mekanisme copy-on-write, yaitu data asli hanya benar-benar disalin ke area snapshot saat blok tersebut berubah setelah snapshot dibuat. Snapshot sangat berguna untuk mengambil backup yang konsisten dari volume yang sedang aktif ditulis, misalnya data directory PostgreSQL, tanpa perlu menghentikan service database-nya, sebuah teknik yang akan relevan lagi saat kita membahas strategi backup di Bab 23 dan Bab 40.

Langkah Praktik

1. Buat snapshot dari Logical Volume yang aktif. Ukuran yang dialokasikan bukan untuk menyalin seluruh data, melainkan ruang cadangan untuk menampung perubahan (delta) yang terjadi selama snapshot masih hidup.

   sudo lvcreate -L 5G -s -n lv_data_snap /dev/vg_data/lv_data

2. Mount snapshot tersebut secara terpisah, misalnya untuk keperluan backup melalui rsync atau tar, tanpa mengganggu volume asli yang tetap dipakai aplikasi.

   sudo mkdir -p /mnt/snapshot
   sudo mount -o ro /dev/vg_data/lv_data_snap /mnt/snapshot

3. Setelah proses backup selesai, unmount dan hapus snapshot agar tidak terus memakan ruang VG.

   sudo umount /mnt/snapshot
   sudo lvremove /dev/vg_data/lv_data_snap

Verifikasi dan Troubleshooting

• Pantau seberapa penuh ruang snapshot terpakai, karena snapshot yang penuh 100 persen akan menjadi invalid dan tidak bisa dipakai lagi.

  sudo lvs -o +snap_percent vg_data

• Snapshot LVM bukan pengganti backup off-site. Snapshot tetap berada di disk fisik yang sama dengan volume aslinya, sehingga jika disk tersebut rusak total, snapshot ikut hilang bersamanya. Perlakukan snapshot sebagai alat bantu untuk mengambil backup yang konsisten, bukan sebagai backup itu sendiri, sebuah prinsip yang akan kita perdalam lagi pada strategi 3-2-1 di Bab 40.

7.3 RAID Software dengan mdadm

RAID (Redundant Array of Independent Disks) menggabungkan beberapa disk fisik menjadi satu unit logis untuk mendapatkan kombinasi redundansi, performa, atau keduanya. Ubuntu Server menyediakan mdadm sebagai tool standar untuk mengelola RAID berbasis software, alternatif yang jauh lebih terjangkau dibanding RAID controller hardware khusus, dengan performa yang pada banyak kasus modern nyaris setara.

7.3.1 RAID 0, 1, 5, 10: Konsep dan Kapan Digunakan

Setiap level RAID menawarkan trade-off berbeda antara kapasitas, redundansi, dan performa. Memilih level yang salah untuk beban kerja tertentu bisa berakibat fatal, misalnya memakai RAID 0 untuk data production yang tidak boleh hilang sama sekali.

Sysadmin perlu jujur soal risiko RAID 5 yang sering diabaikan: saat satu disk gagal dan array masuk fase rebuild, seluruh disk yang tersisa dibaca penuh untuk merekonstruksi data yang hilang. Pada disk berkapasitas puluhan terabyte, proses ini bisa memakan waktu satu hingga dua hari, dan selama itu array berada dalam kondisi degraded tanpa redundansi sama sekali. Jika ada disk kedua yang ikut gagal sebelum rebuild selesai, seluruh data di array hilang. Inilah alasan RAID 10 lebih disukai untuk data kritis modern meski "mahal" secara kapasitas, karena waktu rebuild-nya jauh lebih singkat dan hanya perlu menyalin dari satu disk pasangannya, bukan membaca seluruh array.

7.3.2 Membangun RAID dengan mdadm

Bagian ini mempraktikkan pembuatan RAID 1 sebagai contoh, karena RAID 1 paling umum dipakai untuk melindungi volume OS atau data penting berskala kecil hingga menengah. Prinsip yang sama berlaku untuk level RAID lain, hanya berbeda pada parameter --level dan jumlah disk.

Langkah Praktik

1. Instal mdadm.

   sudo apt update
   sudo apt install mdadm

2. Buat array RAID 1 dari dua disk kosong, misalnya /dev/sdb dan /dev/sdc. Perintah ini bersifat destruktif terhadap seluruh data yang ada di kedua disk tersebut, pastikan disk benar-benar kosong atau sudah dibackup.

   sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

3. Pantau proses sinkronisasi awal antar disk, yang berjalan di latar belakang dan bisa memakan waktu tergantung ukuran disk.

   cat /proc/mdstat

4. Format dan mount array seperti disk biasa.

   sudo mkfs.ext4 /dev/md0
   sudo mkdir -p /mnt/raid1
   sudo mount /dev/md0 /mnt/raid1

5. Simpan konfigurasi array agar dikenali kembali secara otomatis setelah reboot, lalu perbarui initramfs supaya array bisa dirakit sejak tahap boot awal.

   sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
   sudo update-initramfs -u

Verifikasi dan Troubleshooting

• Lihat status kesehatan array secara detail, termasuk disk mana saja yang aktif dan apakah ada yang berstatus faulty.

  sudo mdadm --detail /dev/md0

• Jika salah satu disk pada array gagal, tandai sebagai rusak lalu keluarkan sebelum menggantinya dengan disk baru.

  sudo mdadm --manage /dev/md0 --fail /dev/sdb
  sudo mdadm --manage /dev/md0 --remove /dev/sdb

  Setelah disk fisik pengganti terpasang, tambahkan kembali ke array agar proses rebuild otomatis berjalan.

  sudo mdadm --manage /dev/md0 --add /dev/sdd

• Di lapangan, jangan menunggu sampai mdadm --detail dicek manual untuk tahu ada disk gagal. Aktifkan daemon monitoring mdadm agar notifikasi email dikirim otomatis begitu status array berubah, dan hubungkan ke sistem monitoring terpusat yang akan kita bahas pada Bab 38.

  sudo systemctl enable --now mdmonitor

• RAID dan LVM bukan pilihan yang saling meniadakan. Pola yang lazim dipakai Sysadmin di server production adalah menumpuk keduanya: array mdadm (misalnya RAID 10 untuk data database) dijadikan Physical Volume untuk LVM, bukan disk mentah secara langsung.

  sudo pvcreate /dev/md0
  sudo vgcreate vg_data /dev/md0

  Susunan ini memberi redundansi fisik dari RAID sekaligus fleksibilitas resize dan snapshot dari LVM yang sudah kita bahas pada Bagian 7.2, sebuah kombinasi yang jauh lebih tangguh dibanding memakai salah satunya saja.

7.4 Menambah Disk Baru ke Server yang Berjalan

Menambah kapasitas storage pada server production idealnya tidak pernah membutuhkan downtime. Baik di lingkungan virtual machine (KVM, VMware) maupun cloud, disk baru bisa "dicolokkan" secara virtual ke server yang sedang menyala, dan kernel Linux modern mampu mengenalinya tanpa reboot asalkan kita tahu cara memicu deteksi ulangnya.

7.4.1 Partisi, Format, dan Mount Permanen via /etc/fstab

Langkah Praktik

1. Setelah disk baru ditambahkan dari sisi hypervisor atau dashboard cloud provider, cek apakah kernel sudah mengenalinya.

   lsblk
   sudo dmesg | grep -i sd

   Jika disk belum terdeteksi, khususnya pada beberapa hypervisor berbasis SCSI virtual, paksa kernel melakukan pemindaian ulang bus SCSI tanpa reboot. Periksa dulu daftar host SCSI yang tersedia, karena nomornya tidak selalu host0 dan bisa berbeda antar server.

   ls /sys/class/scsi_host/
   echo "- - -" | sudo tee /sys/class/scsi_host/host0/scan

2. Buat partisi baru di disk tersebut menggunakan parted, yang lebih aman untuk skrip automasi dibanding fdisk interaktif.

   sudo parted /dev/sdb --script mklabel gpt mkpart primary ext4 0% 100%

3. Format partisi dengan filesystem pilihan.

   sudo mkfs.ext4 /dev/sdb1

4. Ambil UUID partisi, yang jauh lebih andal dipakai di /etc/fstab dibanding nama device seperti /dev/sdb1. Urutan penamaan device bisa berubah setelah reboot, terutama pada server dengan banyak disk, sementara UUID selalu tetap.

   sudo blkid /dev/sdb1

5. Buat mount point, lalu tambahkan entri permanen di /etc/fstab menggunakan UUID yang sudah didapat.

   sudo mkdir -p /mnt/data
   sudo nano /etc/fstab

   UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/data ext4 defaults,nofail 0 2

6. Uji entri fstab tanpa reboot terlebih dahulu.

   sudo mount -a
   df -h /mnt/data

Verifikasi dan Troubleshooting

• Selalu jalankan sudo mount -a setelah mengedit /etc/fstab, sebelum reboot. Jika ada kesalahan syntax atau UUID yang salah ketik, perintah ini akan langsung menampilkan error, jauh lebih aman dibanding menyadarinya saat server justru gagal boot dan masuk ke emergency mode tengah malam.
• Opsi nofail pada contoh di atas bukan sekadar formalitas. Tanpa opsi ini, jika suatu saat disk tersebut tidak terdeteksi saat boot (misalnya disk cloud yang terlepas atau storage eksternal yang belum siap), systemd akan menghentikan proses boot dan menunggu input manual di konsol. nofail membuat boot tetap lanjut meski mount gagal, sebuah kebiasaan aman yang wajib diterapkan terutama untuk volume data tambahan yang bukan filesystem root.
• Jika data akan dipakai bersama oleh container Docker, ingat bahwa volume yang dipasang di sini bisa langsung dijadikan bind mount untuk container, topik yang akan kita perdalam pada Bab 26 dan Bab 27.

7.5 /tmp sebagai tmpfs by Default: Implikasi untuk Aplikasi

Sejak Ubuntu 21.04, direktori /tmp berjalan di atas tmpfs secara default, yaitu filesystem yang seluruh isinya disimpan di RAM (dan sebagian bisa "meluber" ke swap jika RAM penuh), bukan lagi di atas disk fisik seperti pada rilis-rilis Ubuntu yang lebih lama. Perubahan ini mengikuti default upstream systemd melalui unit tmp.mount, dan berlanjut sebagai perilaku bawaan pada Ubuntu Server 26.04 LTS. Konsekuensinya signifikan: file apa pun yang ditulis ke /tmp ikut memakan RAM server, dan seluruh isinya otomatis lenyap setiap kali server reboot.

Verifikasi Cepat

findmnt /tmp
df -h /tmp

Perintah findmnt /tmp menunjukkan apakah /tmp benar-benar ter-mount sebagai tipe tmpfs pada server yang sedang kita kelola. Beberapa base image cloud atau provider tertentu kadang sudah mengubah default ini, jadi selalu cek langsung di server yang sedang kita tangani daripada berasumsi.

Secara default, kapasitas tmp.mount dibatasi hingga 50 persen dari total RAM fisik server. Pada server dengan RAM pas-pasan, misalnya VPS kecil dengan 1 sampai 2 GB RAM, ini bisa menjadi jebakan serius. Developer yang menjalankan proses build, kompresi file besar, atau aplikasi yang menumpuk file sementara berukuran besar di /tmp (dump database untuk migrasi, misalnya) berisiko memicu Out of Memory (OOM) killer yang mematikan proses secara paksa, padahal secara kasat mata disk utama server masih terlihat lapang.

Langkah Praktik: Menyesuaikan Batas Ukuran /tmp

1. Untuk memperbesar atau memperkecil batas ukuran tmpfs pada /tmp, buat file override untuk unit tmp.mount alih-alih mengedit file unit aslinya secara langsung.

   sudo systemctl edit tmp.mount

2. Tambahkan baris berikut di antara komentar yang disediakan editor.

   [Mount]
   Options=mode=1777,strictatime,nosuid,nodev,size=2G

3. Muat ulang konfigurasi systemd dan remount /tmp agar perubahan langsung berlaku tanpa reboot.

   sudo systemctl daemon-reload
   sudo systemctl restart tmp.mount

Verifikasi dan Troubleshooting

• Jika aplikasi tertentu memang butuh ruang scratch besar dan konsisten di disk, jangan memaksakannya tetap memakai /tmp. Cara yang lebih aman adalah mengarahkan variabel TMPDIR aplikasi tersebut ke direktori lain yang benar-benar berada di atas disk fisik, atau menonaktifkan tmp.mount sepenuhnya dan mengembalikan /tmp ke partisi disk biasa melalui entri eksplisit di /etc/fstab.

  sudo systemctl mask tmp.mount

• Pada praktik di lapangan, keputusan paling bijak bukan sekadar "aktifkan" atau "matikan" tmpfs secara membabi buta, melainkan menyesuaikan dengan profil beban kerja server. Server web stateless dengan RAM cukup umumnya diuntungkan oleh tmpfs karena I/O /tmp jadi lebih cepat. Server database atau processing data besar dengan RAM terbatas justru lebih aman memakai /tmp berbasis disk.

7.6 Monitoring Kesehatan Disk dengan smartctl

RAID dan LVM melindungi kita dari kegagalan disk setelah terjadi, tetapi keduanya tidak memberi peringatan dini bahwa sebuah disk sedang menuju kegagalan. Di sinilah S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) berperan, sebuah fitur bawaan hampir semua disk modern (HDD, SSD, maupun NVMe) yang terus mencatat metrik kesehatan internal, seperti jumlah bad sector, suhu, dan jam operasional. Package smartmontools menyediakan smartctl sebagai antarmuka untuk membaca data ini dari Linux.

Langkah Praktik

1. Instal smartmontools.

   sudo apt update
   sudo apt install smartmontools

2. Pastikan disk mendukung dan sudah mengaktifkan S.M.A.R.T.

   sudo smartctl -i /dev/sda

3. Cek ringkasan status kesehatan disk secara cepat.

   sudo smartctl -H /dev/sda

4. Untuk detail penuh seluruh atribut S.M.A.R.T. (jumlah bad sector, suhu, reallocated sector count, dan lainnya), gunakan opsi berikut.

   sudo smartctl -a /dev/sda

   Untuk disk NVMe, gunakan device path NVMe-nya, dan smartctl tetap bekerja karena sudah mendukung protokol NVMe secara native pada versi modern.

   sudo smartctl -a /dev/nvme0n1

5. Jalankan self-test untuk pemeriksaan yang lebih menyeluruh. Tipe short hanya memakan waktu beberapa menit, sedangkan long memindai seluruh permukaan disk dan bisa memakan waktu berjam-jam tergantung kapasitasnya.

   sudo smartctl -t short /dev/sda

6. Aktifkan smartd agar pemeriksaan kesehatan berjalan otomatis di latar belakang dan mengirim notifikasi saat ada tanda-tanda kegagalan.

   sudo systemctl enable --now smartmontools

Verifikasi dan Troubleshooting

• Status PASSED pada hasil smartctl -H artinya disk masih dalam kondisi baik menurut penilaian internalnya sendiri, tetapi ini bukan jaminan mutlak. Perhatikan juga tren atribut seperti Reallocated_Sector_Ct dan Current_Pending_Sector pada output smartctl -a. Angka yang terus bertambah dari waktu ke waktu, meski status keseluruhan masih PASSED, adalah sinyal dini bahwa disk sedang menuju kegagalan dan sebaiknya mulai direncanakan penggantiannya.
• Atribut yang relevan berbeda antara HDD dan SSD. Pada HDD, Reallocated_Sector_Ct dan Current_Pending_Sector adalah indikator utama kegagalan mekanis. Pada SSD, perhatikan Media_Wearout_Indicator atau Percentage_Used (tergantung merek), yang menunjukkan seberapa banyak sel flash sudah terpakai dari umur tulis maksimalnya. SSD tidak punya komponen mekanis yang aus, tetapi tetap punya batas jumlah siklus tulis yang perlu dipantau.
• Satu jebakan yang sering membingungkan Sysadmin yang baru pindah ke lingkungan virtual: disk virtual pada VM atau instance cloud pada umumnya tidak mengekspos data S.M.A.R.T. asli, karena hypervisor mengabstraksi storage fisik di baliknya. smartctl pada disk semacam ini biasanya menampilkan pesan seperti Unavailable - device lacks SMART capability. Monitoring kesehatan disk fisik dalam skenario cloud sepenuhnya menjadi tanggung jawab provider, bukan sesuatu yang bisa kita pantau dari dalam VM.
• Untuk server dengan banyak disk fisik (bare metal), hubungkan hasil pemeriksaan smartd ke sistem alerting terpusat, bukan cuma mengandalkan email lokal server yang mungkin tidak pernah benar-benar dicek. Topik ini akan kita satukan dengan monitoring sistem secara menyeluruh pada Bab 38.

Sampai di sini, kita sudah membekali diri dengan fondasi storage yang jauh lebih tangguh: LVM untuk fleksibilitas volume, RAID untuk redundansi, prosedur aman menambah disk ke server yang sedang berjalan, kesadaran soal implikasi /tmp berbasis RAM, hingga kebiasaan memantau kesehatan disk sebelum kegagalan benar-benar terjadi. Bab 8 akan membawa kita masuk ke Bagian III series ini, membahas konfigurasi jaringan server melalui Netplan sebagai fondasi sebelum server benar-benar bisa diakses dan melayani traffic dari luar.