Server yang sehat hari ini bukan jaminan sehat bulan depan: paket menunggu patch keamanan, disk menyusut pelan-pelan, sertifikat mendekati kedaluwarsa, dan backup bisa diam-diam berhenti berjalan. Perawatan server adalah disiplin jangka panjang — bukan tindakan panik saat semuanya sudah terlambat. Chapter penutup section ini menyusun ritmenya: apa yang dicek harian, mingguan, bulanan, dan kuartalan, termasuk reboot terencana dan pembersihan disk. Seperti sebelumnya, perintah systemctl, apt, dan wall tidak bisa dijalankan di container latihan ini, jadi kita pelajari lewat konsep dan contoh tampilan, sementara skrip pemeriksa kesehatan kita uji sungguhan dengan data yang dibekukan.

Siklus Perawatan: Harian hingga Kuartalan #

Kuncinya adalah memetakan pekerjaan ke frekuensi yang sesuai dengan laju kemundurannya:

FrekuensiPekerjaanMengapa
Hariancek backup terakhir, service hidup, ruang diskkegagalan kecil ketahuan dalam sehari, bukan sebulan
Mingguanapt update lalu apt full-upgrade, review log, lihat tren diskpatch keamanan dipasang sebelum dieksploitasi
Bulananuji restore backup, reboot untuk patch kernel, review akses userkepercayaan diri harus dibuktikan berkala
Kuartalanaudit sertifikat dan masa berlakunya, review hardeninghal yang berubah lambat tetap perlu ditinjau

Update paket dan pembacaan log sudah kita kuasai dari Chapter Updating dan Upgrading System dan Web Server Logs , sedangkan sisi keamanannya dirinci di Chapter Security Updates .

Tiga Angka yang Menceritakan Kesehatan Server #

Pemeriksaan harian paling murah adalah membaca snapshot: berkas kecil berisi angka yang ditulis berkala oleh cron atau systemd timer dari Chapter systemd timers . Misalnya df --output=pcent / | tail -1 menghasilkan 72% — persentase pemakaian disk — yang tinggal disimpan ke berkas. Tiga angka yang paling sering menyelamatkan kita: ruang disk terpakai, umur backup terakhir (jam), dan jumlah paket yang menunggu update. Nilai nyata ketiganya berubah-ubah di tiap mesin, jadi latihan ini memakai fixture yang dibekukan:

bash
for berkas in disk-persen.txt backup-umur.txt update-pending.txt; do
  echo "== $berkas"
  cat "$berkas"
done

Output yang Dihasilkan:

text
== disk-persen.txt
72%
== backup-umur.txt
26
== update-pending.txt
14

Angka-angka itu belum berarti apa-apa tanpa ambang pembanding. Disk 72% masih lega, tetapi 26 jam sejak backup terakhir mulai mengkhawatirkan bila jadwalnya harian, dan 14 paket menunggu update tergolong menumpuk. Tiga ambang inilah yang menentukan laporan kita nanti.

Skrip Pemeriksa: cek-maintenance.sh #

Bundle chapter ini membawa skrip cek-maintenance.sh yang membaca ketiga berkas di atas lalu mencetak laporan satu baris per item — OK bila nilai masih di bawah ambang, PERIKSA bila melewatinya:

bash
bash cek-maintenance.sh

Output yang Dihasilkan:

text
== Laporan Pemeliharaan ==
disk   : OK      (72% terpakai, batas 80%)
backup : OK      (26 jam sejak terakhir, batas 48 jam)
paket  : PERIKSA (14 paket menunggu update, batas 10)

Mari kita bedah bagian demi bagian dari isi skripnya:

  1. BATAS_DISK, BATAS_BACKUP, BATAS_PAKET: ketiga ambang dideklarasikan di puncak skrip — satu-satunya tempat yang perlu disesuaikan dengan kebijakan tim, misalnya disk 80% untuk server basis data yang besar.
  2. disk=$(tr -d '%' < disk-persen.txt): membaca snapshot lalu membuang tanda % agar bisa dibandingkan sebagai angka; dua berkas lain sudah polos.
  3. status() { ... }: fungsi kecil yang menerima nilai, batas, label, dan keterangan. Uji [ "$1" -le "$2" ] memilih kata OK atau PERIKSA, lalu printf '%-7s: ...' merapikan kolomnya.
  4. Tiga pemanggilan status: baris terakhir skrip hanya memasangkan tiap angka dengan ambang dan keterangannya — menambah pemeriksaan baru berarti menambah satu berkas snapshot dan satu baris pemanggilan.

Skrip ini sengaja selalu berakhir sukses: laporannya adalah informasi, bukan alarm. Format ringkasnya enak dipanggil cron setiap pagi dengan hasil dikirim ke email admin atau sistem monitoring — satu baris PERIKSA sudah cukup menjadi agenda kerja hari itu.

Reboot Terencana #

Sebagian patch — terutama kernel dan libc — baru benar-benar aktif setelah reboot, jadi reboot adalah bagian rutin perawatan, bukan keadaan darurat. Yang membedakan reboot terencana dari kecelakaan adalah pengumuman dan persiapan: pastikan tidak ada backup berjalan, lalu siarkan pesan ke sesi yang aktif dengan wall:

bash
echo "Server akan direboot pukul 22:00 untuk patch kernel. Simpan pekerjaan Anda sebelum 21:55." | wall
sudo systemctl reboot

Berikut contoh tampilan yang diterima setiap pengguna yang sedang login:

text
Broadcast message from budi@server-kantor (pts/0) (Thu Jan 15 21:55:01 2026):

Server akan direboot pukul 22:00 untuk patch kernel.
Simpan pekerjaan Anda sebelum 21:55.

Setelah mesin kembali hidup, verifikasi tiga hal: systemctl --failed untuk service yang gagal start, ss -tln untuk memastikan port-port layanan kembali mendengarkan (pola dari Chapter ss dan netstat ), dan uptime baru dengan uptime. Baru setelah itu reboot bisa dinyatakan selesai.

Housekeeping Disk #

Disk penuh adalah cara paling memalukan untuk meruntuhkan server, karena semuanya bisa dicek dari jauh lebih dulu — trennya dipantau di Chapter Disk Monitoring . Pengisinya biasanya tiga kumulatif: log lama, cache paket, dan image container. Kita latihan menyaring log lama dengan pola yang bisa dijalankan ulang di mesin manapun:

bash
mkdir -p log-arsip
printf 'log lama\n' > log-arsip/app.log.2.gz
printf 'log lama\n' > log-arsip/app.log.3.gz
printf 'log baru\n' > log-arsip/app.log.4.gz
touch -d "2026-01-18" log-arsip/app.log.2.gz
touch -d "2026-01-25" log-arsip/app.log.3.gz
touch -d "2026-02-08" log-arsip/app.log.4.gz
echo "kandidat diarsipkan (lebih tua dari 2026-02-01):"
find log-arsip -name '*.gz' ! -newermt 2026-02-01 | sort

Output yang Dihasilkan:

text
kandidat diarsipkan (lebih tua dari 2026-02-01):
log-arsip/app.log.2.gz
log-arsip/app.log.3.gz

Mari kita bedah baris demi baris:

  1. Baris 1–6: menyiapkan tiga berkas log dengan isi sembarang, lalu touch -d menempelkan tanggal tetap sebagai waktu modifikasinya — mensimulasikan arsip berumur beda-beda tanpa menunggu waktu sungguhan berlalu.
  2. Baris 7–8 (find ... ! -newermt 2026-02-01): find menyaring berkas *.gz yang waktunya tidak lebih baru dari 1 Februari 2026 — dua berkas terpilih sebagai kandidat dipindah ke arsip jangka panjang atau dihapus; sort menjaga urutan daftarnya.
  3. Di produksi: patokan tanggalnya biasanya relatif — find /var/log -name '*.gz' ! -newermt "$(date -d '30 days ago' +%F)" — idenya sama, hanya jangkar waktunya yang bergerak mengikuti hari ini.

Dua kumulatif lainnya dibereskan sekali jalan: sudo apt clean mengosongkan cache berkas .deb di /var/cache/apt/archives, sudo journalctl --vacuum-time=30d memangkas log systemd yang lebih tua dari 30 hari, dan docker image prune menghapus image tak terpakai bila kita menjalankan container.

Runbook: Kontrak Perawatan Tertulis #

Semua di atas tidak bergantung pada ingatan admin. Runbook — buku panduan operasi — mengubah siklus perawatan menjadi baris perintah yang bisa dijalankan siapa pun:

TugasFrekuensiPerintahIndikator sehat
Laporan perawatanharianbash cek-maintenance.shsemua baris OK
Service hiduphariansystemctl is-active nginxactive
Update paketmingguansudo apt update && sudo apt full-upgrade0 to upgrade
Uji restorebulanantar -xf backup-mingguan.tar.gz -C /tmp/uji-restoreisi berkas terbaca
Reboot patchbila perlusudo systemctl rebootservice kembali active
Audit sertifikatkuartalsudo certbot certificatessemua VALID, sisa > 30 hari

Indikator kolom terakhir itulah definisi “sehat” yang kita sepakati — bukan perasaan. Runbook sekaligus menjadi jejak audit: bila ditanya kapan terakhir backup diuji, jawabannya baris runbook bertanggal, bukan “kayaknya kemarin”. Kebiasaan ini berjalan beriringan dengan sertifikat yang diaudit di Chapter TLS dan SSL Certificates dan hardening yang ditinjau di Chapter Security Hardening .

Dari Server Basics yang membedah arti sebuah server sampai di sini, section Server Administration telah menuntaskan satu putaran penuh: memasang layanan, mengunci pintunya, membaca catatannya, lalu merawatnya agar terus hidup. Dunia berikutnya setelah server fisik adalah server yang digandakan lunak — mesin virtual dan container — dengan set problem dan set perawatannya sendiri.

Referensi lanjut: halaman manual wall untuk opsi pengumuman, serta Debian Administrator’s Handbook untuk praktik operasional Debian secara menyeluruh.

Berkas Sumber

Berkas pendukung halaman ini dapat diunduh dan dijalankan langsung sesuai penjelasan di atas.

cek-maintenance.sh

Unduh berkas
bash
#!/usr/bin/env bash
# cek-maintenance.sh — rangkum status perawatan dari berkas snapshot.
# Di server sungguhan, berkas snapshot ditulis oleh cron atau systemd timer;
# di latihan ini nilainya dibuat tetap supaya hasilnya bisa dibandingkan.

BATAS_DISK=80     # persen terpakai
BATAS_BACKUP=48   # jam sejak backup terakhir
BATAS_PAKET=10    # paket yang menunggu update

disk=$(tr -d '%' < disk-persen.txt)
backup=$(cat backup-umur.txt)
paket=$(cat update-pending.txt)

status() {
    # $1=nilai, $2=batas, $3=label, $4=keterangan hasil
    if [ "$1" -le "$2" ]; then
        printf '%-7s: OK      %s\n' "$3" "$4"
    else
        printf '%-7s: PERIKSA %s\n' "$3" "$4"
    fi
}

echo "== Laporan Pemeliharaan =="
status "$disk"   "$BATAS_DISK"   disk   "($disk% terpakai, batas $BATAS_DISK%)"
status "$backup" "$BATAS_BACKUP" backup "($backup jam sejak terakhir, batas $BATAS_BACKUP jam)"
status "$paket"  "$BATAS_PAKET"  paket  "($paket paket menunggu update, batas $BATAS_PAKET)"