Server Rumahan & Self-Hosting

Shutdown Otomatis dengan UPS untuk Home Server Debian - Ubah Waktu Baterai Menjadi Berhenti Aman

Ditulis oleh Adam Muiz Diperbarui: 14 Sep 2026 10 menit baca
Shutdown Otomatis dengan UPS untuk Home Server Debian - Ubah Waktu Baterai Menjadi Berhenti Aman

Home server dapat bertahan saat listrik padam sebentar hanya jika ada sesuatu yang tetap memasok daya. Namun, bertahan bukanlah pertanyaan yang paling berguna. Pertanyaan yang lebih tepat adalah: bisakah mesin mengenali bahwa pemadaman berlangsung terlalu lama, menyelesaikan proses penulisan data, berhenti dengan aman, lalu kembali bekerja secara terprediksi ketika listrik sudah stabil?

Uninterruptible power supply (UPS) dapat menyediakan jendela waktu singkat yang diperlukan untuk rangkaian tersebut. Namun, baterai saja tidak akan menjalankan rangkaian itu. Server juga memerlukan jalur komunikasi, software yang dapat menafsirkan status UPS, dan kebijakan shutdown yang sudah diuji pada hardware sebenarnya. Tanpa semua bagian itu, UPS mungkin hanya menunda pemutusan daya secara mendadak.

Artikel ini menyusun rencana yang tidak bergantung pada merek hardware untuk home server Debian dengan Network UPS Tools (NUT). Ini bukan klaim tentang model UPS tertentu, runtime baterai, ataupun instalasi di server Adam. Detail semacam itu tidak dapat disimpulkan dengan aman tanpa perangkatnya, manual, beban, dan pengujian terkontrol.

Tujuannya Adalah Berhenti dengan Tertib, Bukan Uptime Maksimal

UPS kecil sering dibicarakan seolah tugasnya adalah mempertahankan semua layanan selama mungkin. Itu bisa menjadi sasaran yang keliru untuk home server. Dalam pemadaman panjang, setiap menit tambahan menghabiskan energi yang seharusnya dapat disisakan untuk menghentikan aplikasi, menyelesaikan penulisan data, melepas filesystem, dan mematikan sistem operasi.

Ada baiknya memisahkan empat pertanyaan yang sering diringkas oleh label produk menjadi satu:

  • Kapasitas: Apakah UPS mampu menopang beban yang terhubung tanpa mengalami overload?
  • Runtime: Dengan beban nyata dan kondisi baterai saat ini, berapa lama daya baterai yang berguna masih tersedia?
  • Komunikasi: Apakah Debian dapat memperoleh status yang andal dari perangkat dan driver ini secara spesifik?
  • Pemulihan: Setelah shutdown terkontrol, apakah UPS dan komputer akan kembali ke kondisi yang diketahui saat listrik menyala lagi?

Keempatnya saling berkaitan, tetapi tidak dapat saling menggantikan. Baterai besar tidak membuktikan kompatibilitas software. Port USB tidak membuktikan bahwa NUT memahami protokolnya. Shutdown yang berhasil tidak membuktikan bahwa mesin akan menyala kembali. Karena itu, target praktisnya bukan angka durasi yang dijanjikan, melainkan rangkaian yang terukur dengan margin cukup agar tetap selesai dengan aman ketika baterai menua.

Periksa Jalur Daya Sebelum Memasang Software

Mulailah dengan inventaris. Catat server, perangkat penyimpanan, perangkat jaringan, dan semua perangkat lain yang harus tetap menyala agar jalur shutdown dapat bekerja. Jika server sekunder menerima status UPS melalui jaringan, misalnya, switch yang berkaitan juga memerlukan daya selama kejadian. Monitor atau printer dapat menghabiskan baterai tanpa membantu shutdown tanpa pengawasan.

Bandingkan perangkat yang terhubung dengan kedua batas yang dicantumkan produsen UPS, umumnya watt dan volt-ampere (VA), lalu ikuti manual perangkat untuk kelompok outlet dan jenis beban yang didukung. Jangan menganggap penjumlahan kasar nameplate sebagai jaminan runtime. Konsumsi nyata berubah mengikuti workload, ada rugi-rugi konversi, kondisi baterai berubah seiring waktu, dan kurva runtime produsen bersifat spesifik untuk tiap model.

Dukungan komunikasi perlu diperiksa dengan ketelitian yang sama. Panduan konfigurasi NUT mengarahkan pengguna ke Hardware Compatibility List saat memilih driver. Cari model yang persis sama dan baca catatan driver yang ditautkan. Meski demikian, status didukung belum tentu berarti setiap field telemetry atau instant command tersedia. Kesimpulan yang dapat dipertanggungjawabkan hanya diperoleh dengan melakukan query pada unit yang terpasang dan menguji fungsi yang diperlukan oleh rancangan shutdown.

Cara NUT Membagi Pekerjaan

NUT adalah sebuah stack, bukan satu daemon yang mengetahui semuanya. Panduan konfigurasi resminya menjelaskan tiga lapisan yang relevan:

  • Driver perangkat berkomunikasi dengan UPS melalui USB, serial, SNMP, atau protokol lain yang didukung.
  • upsd membaca status driver, menyimpan cache lokal, dan menyajikan data tersebut kepada client yang diizinkan.
  • upsmon mengawasi satu atau beberapa definisi UPS, mengirim notifikasi, dan menjalankan perintah shutdown host ketika kondisi daya menjadi kritis.

Pemisahan ini penting saat mendiagnosis kegagalan. Jika driver tidak dapat berkomunikasi dengan UPS, mengubah script notifikasi tidak akan memperbaiki jalur data. Jika upsc dapat membaca nilai yang masuk akal tetapi shutdown tidak pernah dimulai, masalahnya berada di bagian rantai berikutnya. Setup bertahap membuat setiap batas terlihat.

Pada Debian dan turunannya, konfigurasi NUT dari package umumnya berada di /etc/nut, tetapi dokumentasi package yang terpasang harus menjadi rujukan utama. Rilis upstream dan distribusi tidak selalu memiliki default atau istilah yang identik. Dokumentasi upstream saat ini memakai peran primary dan secondary; panduan lama mungkin menampilkan istilah terdahulu untuk hubungan yang sama.

Bangun Setup dalam Tahap yang Dapat Diamati

1. Pastikan driver melaporkan data yang masuk akal

Konfigurasikan definisi perangkat terlebih dahulu. Driver harus sesuai dengan metode komunikasi dan dukungan model yang tepat. Setelah driver dan upsd berjalan, gunakan client ringan upsc yang didokumentasikan Debian untuk memeriksa nilai yang benar-benar disediakan UPS:

upsc myups@localhost
upsc myups@localhost ups.status

Nama myups hanyalah placeholder. Panduan NUT menunjukkan OL untuk daya online, OB untuk kondisi menggunakan baterai, dan LB untuk baterai lemah. Sebuah perangkat dapat melaporkan beberapa token status sekaligus. Perangkat juga mungkin tidak menyediakan runtime baterai, beban, atau variabel lain, sehingga otomatisasi sebaiknya hanya bergantung pada data yang telah dikonfirmasi pada perangkat tersebut.

Amati perubahan, bukan hanya satu snapshot yang tampak meyakinkan. Apakah status berubah ketika daya input dihentikan dengan cara yang diizinkan produsen? Apakah status kembali online ketika listrik kembali? Apakah komunikasi tetap stabil? Pada tahap ini, otomatisasi shutdown seharusnya masih dinonaktifkan atau dibuat tidak berbahaya.

2. Tambahkan monitor dengan least privilege

upsmon melakukan autentikasi ke upsd dengan akun monitoring. File konfigurasi NUT dapat memuat credential dan data access control, sehingga panduan resmi menyatakan file tersebut tidak boleh dapat dibaca oleh semua pengguna. Catatan keamanan NUT juga menyarankan pembatasan interface dan jalur firewall yang dapat menjangkau upsd. Client monitoring tidak memerlukan akses bebas ke semua perintah administratif.

Untuk satu server yang terhubung langsung ke UPS, upsmon biasanya memakai peran primary. Dalam setup bersama, satu sistem dapat mengelola UPS sementara sistem lain yang ikut mendapat daya menjalankan monitor secondary melalui jaringan. Kabel fisik dan peran software harus menggambarkan keadaan yang sama. Mesin yang hanya mengamati UPS jarak jauh tidak boleh tanpa sengaja dikonfigurasi seolah UPS itu juga memasok dayanya.

3. Tentukan makna “kritis” melalui perangkat

Jalur shutdown normal NUT dimulai ketika UPS sekaligus menggunakan baterai dan melaporkan baterai lemah, yang ditampilkan sebagai OB LB dalam panduan. Keputusan low-battery dapat bergantung pada threshold yang dilaporkan perangkat dan perilaku driver. Keputusan tersebut tidak semestinya diganti begitu saja dengan persentase universal yang disalin dari model lain.

Ada caveat penting mengenai waktu. Jika sisa interval setelah LB lebih pendek daripada durasi shutdown nyata host, trigger default datang terlambat. NUT mendukung kebijakan berbasis waktu melalui upssched, tetapi manual upsmon sendiri menyebut timed shutdown sebagai kompleksitas tambahan dan menyarankan penggunaan penanganan kritis normal jika memungkinkan. Ukur terlebih dahulu; tambahkan kebijakan hanya untuk menyelesaikan masalah waktu yang benar-benar teramati.

4. Jadikan pemulihan sebagai bagian dari rancangan

Shutdown hanyalah separuh siklus pemadaman. NUT dapat menandai status forced shutdown, menghentikan sistem yang bergantung, mematikan primary, dan meminta UPS yang didukung untuk memutus daya beban pada tahap akhir shutdown sistem operasi. Memutus beban dapat mencegah kondisi balapan ketika listrik kembali setelah komputer berhenti, tetapi sebelum UPS sempat mati. Keberhasilan perintah memutus beban dan menyalakannya kembali dengan jeda bergantung pada UPS dan driver.

Firmware komputer juga memerlukan kebijakan restore-after-power-loss yang sesuai. Pengaturan itu berada di luar NUT dan berbeda pada setiap mesin. Uji perilaku gabungannya, jangan berasumsi bahwa opsi “power on” pada satu antarmuka berarti pemulihan tanpa pengawasan sudah lengkap.

Pengujian Harus Bergerak dari Aman ke Disruptif

File konfigurasi yang berhasil diparse bukanlah bukti bahwa sistem dapat pulih dari pemadaman. Pengujian sebaiknya meningkat secara bertahap:

  1. Observasi read-only: Lakukan query status dan log saat listrik tersedia. Pastikan layanan driver, server, dan monitor berjalan setelah reboot.
  2. Transisi ke baterai: Dengan beban yang berada dalam batas produsen, amati transisi ke baterai dan kembali sesuai petunjuk perangkat. Pastikan notifikasi serta status berubah tanpa mendekati kondisi baterai habis.
  3. Simulasi logika shutdown: Gunakan dummy shutdown command atau jalur notifikasi saja agar kejadian kritis mencatat apa yang seharusnya terjadi tanpa menghentikan host.
  4. Uji end-to-end terkontrol: Jadwalkan downtime, hentikan workload penting dengan aman, pertahankan akses console, lalu uji proses halt, pemutusan beban UPS, kembalinya listrik, dan urutan boot yang sebenarnya.

Langkah terakhir memang sengaja tidak nyaman. Menurut manual upstream maupun halaman upsmon(8) Debian, upsmon -c fsd memulai rangkaian forced shutdown. Ini bukan perintah diagnostik yang aman. Perintah tersebut dapat mematikan primary, memberi sinyal kepada secondary, dan berujung pada pemutusan output UPS. Gunakan hanya dalam uji disruptif yang sudah dipersiapkan.

Catat timestamp selama pengujian: transisi baterai, keputusan shutdown, berhentinya aplikasi, host halt, pemutusan output, kembalinya input, dan pulihnya layanan. Hasil yang berguna bukan benchmark bagi orang lain, melainkan bukti bahwa sistem khusus ini memiliki margin cukup. Ulangi pengujian secara berkala dan setelah mengganti baterai UPS, beban terhubung, layout penyimpanan, shutdown job, kebijakan firmware, atau konfigurasi NUT.

Sistem dengan UPS Bersama Memerlukan Urutan

Ketika beberapa mesin memakai satu UPS, shutdown yang bersih menjadi masalah koordinasi. Monitor secondary menerima status dari upsd di sisi primary. Saat kejadian kritis, secondary seharusnya berhenti dan memutus koneksi sebelum primary memutus daya dari beban bersama. Manual upstream mendokumentasikan timer sinkronisasi, tetapi nilai default-nya tidak dapat membuktikan bahwa database, virtual machine, atau layanan penyimpanan tertentu akan selesai tepat waktu.

Susun urutan yang eksplisit. Hentikan aplikasi dengan aktivitas tulis tinggi sebelum host penyimpanannya. Pertahankan jalur jaringan sampai monitor secondary menerima keputusan. Sisakan cadangan yang cukup untuk shutdown paling lambat yang diperkirakan, sambil menerima bahwa primary tidak dapat menunggu secondary yang gagal untuk selamanya. Jika kompromi itu tidak dapat diuji dengan andal, domain daya yang terpisah atau topologi yang lebih sederhana mungkin lebih aman daripada pengaturan waktu yang cerdik.

Hal yang Tidak Diselesaikan oleh UPS

UPS bukan pengganti backup. UPS tidak dapat memulihkan file yang tidak sengaja dihapus, database rusak yang sudah tertulis ke disk, credential yang dicuri, atau drive yang gagal. UPS juga menambah komponen yang dapat gagal: baterai menua, koneksi USB terputus, credential monitoring salah dikonfigurasi, dan client jaringan tidak dapat dijangkau.

Tidak setiap perpindahan singkat ke baterai juga harus langsung memicu shutdown. Gangguan singkat mungkin selesai sebelum mematikan server layak dilakukan. Sebaliknya, menunggu persentase baterai paling akhir dapat menghilangkan margin yang diperlukan untuk berhenti dengan aman. Kebijakan yang tepat bergantung pada pola pemadaman setempat, laporan UPS, durasi shutdown workload, dan biaya downtime. Tidak ada threshold universal yang dapat dijanjikan dengan jujur.

Pekerjaan kelistrikan tetap berada di luar cakupan konfigurasi software. Gunakan outlet dengan grounding dan beban yang didukung sesuai petunjuk produsen, jaga ventilasi tetap terbuka, dan jangan membuka enclosure UPS hanya karena sebuah panduan software membahas baterainya.

Definisi Keberhasilan yang Praktis

Setup UPS home server berhasil ketika perilakunya diketahui, bukan ketika dashboard-nya terlihat rinci. Perangkat yang tepat muncul dalam bukti kompatibilitas; Debian dapat membaca status yang stabil; credential dan eksposur jaringan dibatasi; rangkaian shutdown selesai dengan margin terukur; host yang bergantung berhenti dalam urutan yang direncanakan; dan sistem kembali secara terprediksi setelah daya pulih.

Definisi itu sengaja dibuat sederhana. UPS tidak dapat membuat jaringan listrik menjadi andal, dan NUT tidak dapat menciptakan telemetry yang tidak disediakan perangkat. Keduanya dapat mengubah interval baterai yang terbatas menjadi keputusan yang terkontrol. Pertanyaan yang tersisa bersifat empiris: apakah seluruh siklus sudah diuji pada perangkat yang kelak harus menjalankannya tanpa pengawasan?

References