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:
| Frekuensi | Pekerjaan | Mengapa |
|---|---|---|
| Harian | cek backup terakhir, service hidup, ruang disk | kegagalan kecil ketahuan dalam sehari, bukan sebulan |
| Mingguan | apt update lalu apt full-upgrade, review log, lihat tren disk | patch keamanan dipasang sebelum dieksploitasi |
| Bulanan | uji restore backup, reboot untuk patch kernel, review akses user | kepercayaan diri harus dibuktikan berkala |
| Kuartalan | audit sertifikat dan masa berlakunya, review hardening | hal 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:
for berkas in disk-persen.txt backup-umur.txt update-pending.txt; do
echo "== $berkas"
cat "$berkas"
doneOutput yang Dihasilkan:
== disk-persen.txt
72%
== backup-umur.txt
26
== update-pending.txt
14Angka-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 cek-maintenance.shOutput yang Dihasilkan:
== 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:
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.disk=$(tr -d '%' < disk-persen.txt): membaca snapshot lalu membuang tanda%agar bisa dibandingkan sebagai angka; dua berkas lain sudah polos.status() { ... }: fungsi kecil yang menerima nilai, batas, label, dan keterangan. Uji[ "$1" -le "$2" ]memilih kataOKatauPERIKSA, laluprintf '%-7s: ...'merapikan kolomnya.- 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:
echo "Server akan direboot pukul 22:00 untuk patch kernel. Simpan pekerjaan Anda sebelum 21:55." | wall
sudo systemctl rebootBerikut contoh tampilan yang diterima setiap pengguna yang sedang login:
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:
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 | sortOutput yang Dihasilkan:
kandidat diarsipkan (lebih tua dari 2026-02-01):
log-arsip/app.log.2.gz
log-arsip/app.log.3.gzMari kita bedah baris demi baris:
- Baris 1–6: menyiapkan tiga berkas log dengan isi sembarang, lalu
touch -dmenempelkan tanggal tetap sebagai waktu modifikasinya — mensimulasikan arsip berumur beda-beda tanpa menunggu waktu sungguhan berlalu. - Baris 7–8 (
find ... ! -newermt 2026-02-01):findmenyaring berkas*.gzyang waktunya tidak lebih baru dari 1 Februari 2026 — dua berkas terpilih sebagai kandidat dipindah ke arsip jangka panjang atau dihapus;sortmenjaga urutan daftarnya. - 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:
| Tugas | Frekuensi | Perintah | Indikator sehat |
|---|---|---|---|
| Laporan perawatan | harian | bash cek-maintenance.sh | semua baris OK |
| Service hidup | harian | systemctl is-active nginx | active |
| Update paket | mingguan | sudo apt update && sudo apt full-upgrade | 0 to upgrade |
| Uji restore | bulanan | tar -xf backup-mingguan.tar.gz -C /tmp/uji-restore | isi berkas terbaca |
| Reboot patch | bila perlu | sudo systemctl reboot | service kembali active |
| Audit sertifikat | kuartal | sudo certbot certificates | semua 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#!/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)"