Checklist Pemeliharaan Server Linux Mingguan dan Bulanan

Makna sebenarnya dari pemeliharaan server Linux

Pemeliharaan server Linux adalah daftar singkat pemeriksaan yang dijalankan berdasarkan jadwal tetap, bukan proyek yang memiliki akhir. Setiap minggu, pastikan pembaruan telah terpasang, disk masih memiliki ruang kosong, tidak ada service yang berhenti, dan tugas pencadangan telah selesai. Setiap bulan, uji pemulihan, periksa masa berlaku sertifikat, audit akun dan key, serta hapus kernel dan log lama. Satu kali untuk setiap rilis distribusi, rencanakan upgrade versi dan lakukan reboot yang terus ditunda.

Membangun server adalah tugas yang berbeda, dan sepuluh menit pertama pada VPS baru membahas bagian tersebut. Halaman ini membahas tahun setelahnya. Setiap item di bawah menyebutkan kegagalan yang dicegahnya, karena checklist tanpa konsekuensi adalah checklist yang perlahan berhenti dijalankan.

Perintah di sini hanya contoh dan dimaksudkan untuk dibaca sebelum dijalankan. Bandingkan outputnya dengan server Anda sendiri, karena nilai ruang kosong atau jumlah proses yang sehat bergantung pada fungsi server tersebut. Jika pemeriksaan berbeda antar-distribusi, teks akan menjelaskannya. Contoh menggunakan Debian dan Ubuntu dengan apt. Pada keluarga RHEL, tooling yang digunakan adalah dnf dan beberapa path berbeda.

Cara memilih jadwal pemeliharaan server Linux yang dapat Anda pertahankan

Pemeriksaan mingguan mencakup hal-hal yang berubah tanpa tindakan Anda: paket, penggunaan disk, status service, dan tugas terjadwal. Hal-hal tersebut berubah dengan sendirinya, sehingga satu minggu adalah batas waktu terlama untuk membiarkannya tanpa diperiksa.

Pemeriksaan bulanan mencakup penurunan kondisi yang berlangsung lambat: sertifikat yang mendekati masa berlaku, akun yang tidak dihapus, kernel yang menumpuk di /boot, serta file log yang ukurannya melebihi aturan rotasi yang sudah tidak sesuai. Tidak satu pun dari masalah ini akan menyebabkan kegagalan besok. Namun, semuanya pada akhirnya akan menyebabkan kegagalan.

Pemeriksaan rilis mengikuti kalender. Rilis distribusi adalah satu-satunya item pemeliharaan dengan tenggat eksternal karena dukungan untuk versi yang Anda gunakan akan berakhir, terlepas dari apakah Anda sudah siap.

Tetapkan waktu khusus untuk pelaksanaannya: Senin pagi untuk pemeriksaan mingguan dan tanggal 1 setiap bulan untuk pemeriksaan bulanan. Menjalankan checklist "saat ada waktu" bukanlah checklist. Jika jumlah mesin sudah lebih dari beberapa, jalankan pemeriksaan ini dari satu tempat, bukan secara manual. Topik tersebut dibahas dalam mengelola beberapa server Linux dari satu tempat.

Mingguan: apakah pembaruan benar-benar terpasang?

Mengaktifkan unattended-upgrades tidak sama dengan memastikan bahwa layanan tersebut berjalan. Service dapat di-mask, konfigurasi dapat dibatasi pada origin yang tidak Anda gunakan, dan satu paket yang ditahan dapat menyebabkan setiap proses berikutnya gagal. Cara memasangnya dijelaskan dalam pembaruan keamanan otomatis di Ubuntu. Tugas mingguan ini membuktikan bahwa komponen yang Anda pasang benar-benar menjalankan tugasnya.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable adalah ukuran yang paling akurat karena melaporkan status saat ini, bukan maksud konfigurasi. Jika pembaruan keamanan masih tercantum di sana, otomatisasi tidak menjalankan tugasnya. Baca log sebelum menganggap mesin sudah diperbarui. Paket yang dikunci dengan apt-mark hold akan selalu dilewati dan tidak melaporkan apa pun. Karena itu, apt-mark showhold harus diperiksa dalam pemeriksaan yang sama.

Kegagalan yang dicegah: menjalankan paket yang diketahui rentan selama berbulan-bulan karena mengira pembaruan berlangsung otomatis.

Rutin mingguan: ruang cadangan disk dan inode

Filesystem root yang penuh dapat menyebabkan masalah yang tampaknya tidak berkaitan dengan disk. Database menolak operasi tulis, logging berhenti, upgrade paket gagal setelah konfigurasi berjalan setengah, dan pada beberapa konfigurasi Anda tidak dapat membuka sesi baru karena sistem tidak dapat menulis file yang diperlukan.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i adalah separuh pemeriksaan yang paling sering dilewati. Inode adalah struktur berjumlah tetap yang menyimpan metadata file. Filesystem dapat kehabisan inode meskipun df -h masih melaporkan gigabyte yang tersedia. Operasi tulis kemudian gagal dengan No space left on device, sementara output menunjukkan bahwa ruang masih tersisa. Hal ini dapat menghabiskan waktu satu jam untuk mencari penyebabnya jika baru pertama kali mengalaminya. Jutaan file kecil, misalnya dari antrean email yang macet atau direktori sesi yang tidak pernah dibersihkan, biasanya menjadi penyebabnya.

du -xh tetap berada pada satu filesystem. Ini sesuai untuk server yang menggunakan bind mount atau storage terpasang. Pada host Docker, masalahnya biasanya berada pada image layer dan volume yang tidak lagi digunakan. Bersihkan bagian tersebut seperti yang dijelaskan dalam membersihkan penggunaan disk Docker pada VPS.

Ruang kosong menunjukkan kapasitas. Storage yang mendasarinya dapat gagal tanpa bergantung pada kapasitas tersebut. Pemeriksaan terpisah untuk hal ini dijelaskan dalam memantau kesehatan disk pada VPS.

Mingguan: apa yang berhenti tanpa memberi tahu Anda?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Unit yang mengalami crash dan mencapai batas restart akan berada dalam status failed dan tetap di sana tanpa suara. Tidak ada email yang memberi tahu Anda. list-timers adalah bagian yang lebih berguna: perintah ini menunjukkan kapan setiap timer terakhir berjalan dan kapan timer tersebut akan berjalan berikutnya. Dengan demikian, nilai LAST yang lebih lama daripada interval timer itu sendiri berarti job tersebut sama sekali tidak berjalan.

Baca journal untuk unit tersebut sebelum me-restart-nya menggunakan journalctl -u <unit> -n 100 --no-pager. Restart hanya menghapus gejalanya. Setelah itu, Anda tidak memiliki alasan untuk memeriksanya lagi sampai masalah yang sama terjadi pada waktu yang lebih buruk.

Kegagalan yang dapat dicegah: monitoring agent, queue worker, atau service backup yang telah mati sejak lonjakan penggunaan memori tiga minggu lalu.

Mingguan: apakah tugas pencadangan benar-benar selesai?

Pencadangan yang dijadwalkan dan pencadangan yang selesai adalah dua hal yang berbeda. Hanya pencadangan yang selesai yang dapat digunakan untuk pemulihan. Periksa penyelesaiannya.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Pastikan dua hal. Proses terakhir berakhir dengan kode 0, dan arsip terbaru masih baru serta ukurannya kira-kira sesuai yang diharapkan. File cadangan yang tiba-tiba berukuran sepersepuluh dari ukuran biasanya adalah dump yang gagal tetapi tetap menulis file. Ini adalah bentuk kegagalan pencadangan yang paling berbahaya karena semua proses setelahnya tampak normal.

Jika skrip Anda menyalurkan dump ke compressor, tambahkan set -o pipefail di bagian paling atas. Tanpa opsi ini, status keluar pipeline adalah status milik compressor. Compressor tersebut berhasil karena memampatkan pesan error. Akibatnya, tugas melaporkan keberhasilan setiap malam sambil menulis arsip kecil yang tidak berisi apa pun.

Bulanan: pulihkan cadangan di tempat lain

Ini adalah langkah yang paling sering dilewati. Langkah ini menentukan apakah langkah-langkah lain dalam daftar tersebut benar-benar berguna.

Pulihkan ke mesin lain atau container baru, bukan di atas data aktif. Kemudian buka hasil pemulihan dan pastikan datanya benar-benar ada. Hitung baris dalam tabel. Buka sebuah dokumen. Login ke aplikasi yang dipulihkan. Proses ekstraksi yang selesai hanya membuktikan bahwa arsip dapat dibaca, tidak lebih dari itu.

Tool repository memiliki verifikasi sendiri: restic check --read-data-subset=5% dan borg check --verify-data membaca data yang tersimpan, bukan indeksnya. Jalankan keduanya dan perlakukan sebagai smoke test, bukan sebagai pengganti pemulihan. Verifikasi memeriksa bahwa byte tetap utuh. Pemulihan memeriksa bahwa byte tersebut adalah data yang dibutuhkan aplikasi Anda.

Ada dua hal yang biasanya baru dipahami setelah mengalami masalah. Uji passphrase dekripsi pada mesin yang tidak menyimpan key di agent, karena cadangan yang tidak dapat Anda dekripsi bukanlah cadangan. Ukur juga durasi pemulihan. Durasi tersebut adalah waktu pemulihan nyata Anda, dan biasanya baru diketahui saat terjadi gangguan.

Bulanan: sertifikat mana yang segera kedaluwarsa?

Otomatisasi pembaruan dapat gagal tanpa pesan. Timer certbot dapat memperbarui file di disk, sementara web server tetap menyajikan sertifikat lama dari memori karena deploy hook yang memuat ulang service tidak berjalan. Jadi, tanyakan kepada server yang sedang berjalan sertifikat yang disajikannya, dari luar server tersebut.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Flag -servername menetapkan SNI (server name indication). Flag ini diperlukan pada alamat yang meng-host lebih dari satu situs. Jika tidak, Anda akan menerima sertifikat default, bukan sertifikat milik Anda. Jika certbot diinstal dari snap, nama timernya berbeda. Karena itu, cocokkan berdasarkan katanya, bukan berdasarkan unit yang Anda asumsikan.

Ingat sertifikat yang sama sekali tidak memiliki otomatisasi: sertifikat mail server, VPN, atau certificate authority internal. Sertifikat tersebut dapat kedaluwarsa pada akhir pekan. Browser dan client akan langsung menolaknya, bukan hanya menampilkan peringatan.

Bulanan: pengguna, akses sudo, dan kunci SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T menampilkan konfigurasi efektif setelah setiap Include digabungkan. Konfigurasi inilah yang benar-benar akan digunakan daemon. Image Ubuntu terbaru menyertakan file drop-in di /etc/ssh/sshd_config.d/. File tersebut dapat menimpa file utama. Karena itu, hanya membaca sshd_config dapat memberikan kesimpulan yang berlawanan dari kondisi sebenarnya. Pada keluarga RHEL, grup administratifnya adalah wheel, bukan sudo. Sesuaikan baris getent.

Kemudian, baca file authorized_keys itu sendiri. Akses diberikan berdasarkan kunci, bukan akun. Karena itu, kunci yang ditinggalkan kontraktor yang selesai bekerja enam bulan lalu tetap dapat digunakan untuk login, dan tidak akan terdeteksi dalam daftar pengguna. Kunci memiliki kolom komentar. Gunakan kolom tersebut, lalu hapus apa pun yang tidak dapat dikaitkan dengan seseorang.

Untuk riwayat login, journalctl -t sshd --since "30 days ago" | grep -i accepted mencocokkan berdasarkan pengenal syslog, bukan nama unit. Hal ini penting karena Ubuntu 24.04 mengaktifkan SSH melalui socket. Akibatnya, setiap koneksi dicatat di bawah unit per koneksi yang dibuat secara otomatis, dan journalctl -u ssh biasa dapat melewatkannya.

Bulanan: kernel lama dan /boot yang penuh

/boot sering kali merupakan partisi terpisah berukuran beberapa ratus megabita pada image VPS standar. Setiap pembaruan kernel menambahkan image dan initramfs ke partisi tersebut. Jika partisi penuh, pemutakhiran berikutnya gagal di tengah proses dan meninggalkan paket dalam keadaan belum dikonfigurasi. Kondisi ini tidak boleh baru diketahui secara tiba-tiba pada hari Jumat.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

Selalu periksa uname -r terlebih dahulu: nilai ini menunjukkan kernel yang sedang Anda jalankan, dan kernel tersebut harus tetap ada setelah kernel lain dihapus. apt autoremove menangani kondisi normal pada Debian dan Ubuntu, karena kernel ditandai sebagai terpasang otomatis dan kernel yang sedang digunakan dilindungi. Kasus khusus, yaitu kernel yang dipasang secara manual atau /boot yang sudah cukup penuh hingga memblokir apt, dibahas dalam menghapus kernel lama di Ubuntu.

Bulanan: pertumbuhan log dan journal systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug adalah uji coba dan tidak menulis apa pun, sehingga aman dijalankan pada server aktif. Perintah ini layak dijalankan karena aturan rotasi mencocokkan path: aplikasi yang mengubah lokasi log saat upgrade tidak lagi tercakup oleh aturannya sendiri, sehingga file tersebut terus bertambah tanpa batas hingga memenuhi disk.

Ukuran journal dibatasi oleh systemd, tetapi berdasarkan sebagian kapasitas filesystem, bukan angka yang Anda tentukan. Tetapkan SystemMaxUse= di /etc/systemd/journald.conf lalu restart systemd-journald jika Anda menginginkan batas maksimum tertentu. sudo journalctl --vacuum-time=14d segera membebaskan ruang, dan tindakan ini hanya dilakukan sekali, bukan kebijakan permanen. Karena itu, sertakan tindakan tersebut bersama perubahan konfigurasi.

Per rilis: reboot yang terus Anda tunda

Paket kernel yang telah diperbarui di disk bukan kernel yang sedang berjalan. Sebelum reboot dilakukan, mesin masih menjalankan kernel lama. Live patching, jika tersedia, hanya mencakup sebagian perbaikan.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

File penanda tersebut merupakan konvensi Debian dan Ubuntu yang ditulis oleh skrip paket. Sistem keluarga RHEL tidak membuatnya. Pada sistem tersebut, pertanyaan yang setara dijawab oleh needs-restarting -r, yang berasal dari dnf-utils. needrestart, yang terpasang secara default pada image server Ubuntu terbaru, memeriksa tingkat di bawah kernel. Perintah ini menampilkan proses yang masih memetakan library yang telah diganti di disk. Karena itu, OpenSSL yang telah ditambal belum berlaku sampai service yang menggunakannya dijalankan ulang.

Jadwalkan reboot, jangan menghindarinya. Dalam /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; dan Unattended-Upgrade::Automatic-Reboot-Time "03:00";, serahkan keputusan tersebut pada waktu yang Anda tentukan. Reboot terencana juga merupakan satu-satunya cara untuk menguji apakah server dapat kembali aktif. Entri fstab yang rusak atau service yang belum pernah Anda aktifkan akan terlihat saat boot, dan tidak di tempat lain.

Perencanaan distribusi per rilis: upgrade

Rilis Ubuntu LTS mendapatkan dukungan standar selama lima tahun, sedangkan rilis interim mendapatkan dukungan selama sembilan bulan. Karena itu, pilihan tersebut menentukan beban kerja upgrade Anda selama bertahun-tahun. Perbandingan tersebut dibahas dalam rilis LTS versus interim pada server.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade membaca file tersebut, sedangkan Prompt=lts membatasi prosesnya pada perpindahan dari LTS ke LTS. Jalur LTS ke LTS biasanya tersedia mulai dari point release pertama versi baru, bukan pada hari rilis. Karena itu, periksa versi yang ditawarkan kepada mesin Anda, alih-alih membuat rencana berdasarkan tanggal yang Anda asumsikan. Mekanisme proses upgrade tersebut dijelaskan dalam upgrade Ubuntu 24.04 ke 26.04.

Siapkan margin waktu selama tiga bulan. Buat snapshot dan uji pemulihannya. Catat repositori apt pihak ketiga yang digunakan, karena proses upgrade akan menonaktifkannya dan masing-masing memerlukan target baru untuk rilis baru. Tentukan prosedur rollback sebelum memulai. Per Agustus 2026, Ubuntu 24.04 LTS masih mendapatkan dukungan standar hingga April 2029. Jadi, proses ini merupakan penjadwalan, bukan keadaan darurat.

Hal yang perlu diotomatisasi dan hal yang tetap dilakukan secara manual

Otomatisasikan keputusan yang sudah Anda buat: pembaruan keamanan, rotasi log, pembaruan sertifikat, dan tugas pencadangan. Otomatisasikan juga pemberitahuannya, karena pemeriksaan yang bergantung pada ingatan Anda tidak akan dilakukan pada pukul 2am. Monitor eksternal, seperti pemantauan status yang di-host sendiri dengan Uptime Kuma, mendeteksi satu hal yang tidak dapat dilaporkan oleh skrip pada server, yaitu server tidak dapat dijangkau.

Pertahankan dua hal untuk dilakukan secara manual: pengujian pemulihan dan audit akun. Keduanya memerlukan seseorang untuk menentukan apakah hasilnya benar. Jika Anda lebih suka membaca status mesin melalui browser daripada terminal, Cockpit dibandingkan dengan Webmin untuk manajemen server membandingkan dua konsol web yang umum digunakan.

Otomatisasi juga memerlukan pemeriksaan tersendiri. Karena itu, item mingguan pertama dalam daftar ini adalah memverifikasi updater. Otomatisasi yang gagal tanpa memberikan pesan lebih buruk daripada tidak ada otomatisasi, karena sekaligus menghilangkan kegagalan dan kebiasaan untuk memeriksanya.

Seluruh checklist di satu tempat

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Seberapa sering saya harus menjalankan pemeliharaan server Linux?

Lakukan setiap minggu untuk hal-hal yang berubah secara otomatis: status update, ruang kosong disk dan inode, unit yang gagal, serta status penyelesaian tugas backup. Lakukan setiap bulan untuk penurunan kondisi yang berlangsung perlahan: uji restore, masa berlaku sertifikat, audit akun dan cryptographic key SSH, kernel lama, serta pertumbuhan log. Lakukan setiap kali distribusi merilis versi baru untuk upgrade versi dan reboot ke kernel saat ini. Pemeriksaan mingguan hanya memerlukan beberapa menit pada server yang sehat. Itulah alasan pemeriksaan ini dijalankan setiap minggu, bukan setelah muncul masalah.

Mengapa saya harus menguji restore jika tugas backup melaporkan keberhasilan?

Karena tugas tersebut melaporkan exit status-nya sendiri, dan status itu dapat menunjukkan berhasil meskipun archive tidak berguna. Dump yang dialirkan ke compressor tanpa set -o pipefail mengembalikan status milik compressor. Akibatnya, dump yang gagal dan hanya menghasilkan pesan error tetap exit dengan kode 0 serta menulis file berukuran kecil. Lakukan restore ke mesin lain, buka datanya, lalu hitung salah satu elemennya. Proses restore juga mencatat durasinya. Durasi tersebut adalah waktu pemulihan Anda yang sebenarnya.

Apakah saya harus melakukan reboot setelah setiap update kernel?

Anda harus melakukan reboot agar kernel baru menjadi kernel yang sedang berjalan. Pada Debian dan Ubuntu, keberadaan /var/run/reboot-required menunjukkan bahwa sebuah package memintanya, sedangkan /var/run/reboot-required.pkgs menunjukkan package yang dimaksud. Pada keluarga RHEL, file tersebut tidak ada. needs-restarting -r dari dnf-utils menjawab pertanyaan yang sama. Tetapkan jendela reboot otomatis di /etc/apt/apt.conf.d/50unattended-upgrades, bukan menundanya tanpa batas. Mesin yang tidak melakukan reboot selama satu tahun memiliki jalur boot yang belum diuji dan kernel yang sudah lama.

Pemeriksaan mana yang dapat saya otomatisasi dengan aman?

Otomatisasikan tindakan yang keputusannya sudah jelas: security update, rotasi log, perpanjangan sertifikat, dan backup terjadwal. Otomatisasikan juga notifikasinya agar unit yang gagal atau disk yang hampir penuh dapat diketahui tanpa seseorang menjalankan command secara manual. Pertahankan uji restore dan audit cryptographic key secara manual karena masing-masing memerlukan seseorang untuk menilai apakah hasilnya benar. Tambahkan satu pemeriksaan terhadap otomatisasi itu sendiri. Kegagalan updater yang tidak menghasilkan notifikasi terlihat sama seperti sistem yang berjalan normal.