Server Rumahan & Self-Hosting

Sinkronisasi Waktu pada Home Server Debian - Satukan Clock untuk Log dan Layanan

Ditulis oleh Adam Muiz Diperbarui: 07 Sep 2026 10 menit baca
Sinkronisasi Waktu pada Home Server Debian - Satukan Clock untuk Log dan Layanan

Home server dapat menampilkan jam yang benar tetapi tetap memiliki clock yang tidak andal. Timezone mungkin sudah tepat ketika sinkronisasi jaringan sebenarnya gagal. Layanan waktu dapat tetap berjalan saat sumbernya tidak bisa dijangkau. Dua mesin bisa tampak wajar jika dilihat sendiri-sendiri, tetapi perbedaannya cukup besar untuk mengacaukan timeline insiden bersama.

Karena itu, pertanyaan yang berguna bukan sekadar, “Jam berapa yang ditampilkan server?” Pertanyaan yang lebih tepat adalah: dari mana waktu itu berasal, kapan terakhir diperiksa, dan bukti apa yang menunjukkan clock masih dapat dipercaya?

Artikel ini menyajikan audit read-only untuk home server Debian biasa. Artikel ini membandingkan systemd-timesyncd dan chrony tanpa berasumsi salah satunya terpasang, serta membatasi pembahasan pada operasi server normal, bukan precision timing. Ini bukan klaim hasil pengukuran dari server Adam dan tidak menetapkan satu target akurasi untuk semua workload.

Mengapa Timeline Bersama Penting

Sinkronisasi clock dapat terlihat seperti urusan kosmetik sampai beberapa sistem menjelaskan kejadian yang sama. Reverse proxy mencatat request, aplikasi mencatat error, database mencatat write, dan firewall mencatat koneksi. Jika clock mereka berbeda, mengurutkan baris berdasarkan timestamp dapat menghasilkan cerita yang tidak pernah terjadi.

Debian Administrator's Handbook menyampaikan poin operasional ini secara langsung: mesin yang tersinkronisasi memudahkan cross-reference log dan rekonstruksi kronologi serangan. Wall time yang akurat juga penting bagi software yang mengevaluasi rentang waktu, termasuk masa berlaku certificate dan pekerjaan terjadwal. Namun, toleransi yang tepat bergantung pada aplikasi. Blog pribadi dan distributed database tidak otomatis membutuhkan jaminan waktu yang sama.

NTP bukan janji bahwa setiap clock akan menjadi sempurna. RFC 5905 menjelaskan pengukuran dan algoritma untuk memperkirakan offset, network delay, dispersion, dan jitter, lalu memilih serta menggabungkan sumber yang sesuai untuk mendisiplinkan system clock. Estimasi tersebut membawa ketidakpastian. Network congestion, rute asimetris, sumber yang rusak, atau client yang terputus dapat melemahkan hasilnya.

Pisahkan Empat Hal yang Sering Tercampur

Timezone

Timezone mengatur cara timestamp ditampilkan kepada manusia. Mengubah UTC menjadi Asia/Jakarta mengubah representasi, bukan menentukan apakah clock tersinkronisasi. Timezone yang benar dengan system clock yang salah tetap menghasilkan waktu lokal yang salah.

Real-time clock dan system clock

Mesin pada umumnya memiliki hardware real-time clock (RTC) yang dapat mempertahankan perkiraan waktu selama shutdown, serta clock sistem operasi yang dipakai ketika Linux berjalan. RTC dapat memberi titik awal saat boot; network time client kemudian dapat mengoreksi dan mendisiplinkan system clock. Dokumentasi timedatectl(1) Debian menyarankan RTC disimpan dalam UTC jika memungkinkan karena local time menimbulkan ambiguitas ketika timezone dan daylight-saving time berubah.

Wall clock dan monotonic clock

Aplikasi juga perlu membedakan “tanggal dan jam berapa sekarang?” dari “berapa lama waktu telah berlalu?” Linux menyediakan CLOCK_REALTIME untuk wall-clock time dan CLOCK_MONOTONIC untuk pengukuran durasi. Manual Linux clock_gettime(2) menjelaskan bahwa real time dapat mengalami lompatan terputus, sedangkan monotonic clock tidak mengikuti lompatan wall clock tersebut. Sinkronisasi waktu tidak dapat memperbaiki aplikasi yang memakai wall time secara ceroboh untuk durasi dan timeout.

Status sinkronisasi

Sinkronisasi adalah hubungan berkelanjutan antara system clock dan satu atau beberapa sumber referensi. Ini tidak sama dengan layanan yang sekadar enabled. Audit yang sehat menanyakan apakah sumber baru-baru ini menyediakan pengukuran yang dapat diterima dan apakah ketidakpastian yang tersisa sesuai bagi workload.

Periksa Sebelum Mengubah Apa Pun

Mulailah dengan command yang tidak mengubah clock:

date --iso-8601=seconds
timedatectl status
systemctl list-units --type=service | grep -E 'chrony|timesync|ntp'

Command pertama memberikan timestamp yang tidak ambigu beserta UTC offset. timedatectl status melaporkan local time, UTC, waktu RTC, timezone, status sinkronisasi system clock, dan apakah layanan network time yang dikenali sedang aktif. Pencarian layanan membantu menemukan provider yang sebenarnya, alih-alih berasumsi semua instalasi Debian memakai provider yang sama.

Baca field tersebut secara terpisah. “NTP service: active” menyatakan bahwa layanan sinkronisasi yang dikenali sedang aktif; field itu sendiri tidak membuktikan pengukuran baru telah diterima. “System clock synchronized: yes” merupakan bukti yang lebih kuat, tetapi tetap berupa ringkasan dari stack lokal, bukan jaminan akurasi eksternal.

Jika systemd-timesyncd menjadi provider, periksa pengukuran saat ini dan log terbarunya:

timedatectl timesync-status
systemctl status systemd-timesyncd.service
journalctl -u systemd-timesyncd.service --since today

Manual systemd-timesyncd(8) mendokumentasikan timesync-status untuk keperluan ini. Output-nya dapat mencakup server terpilih, poll interval, stratum, root distance, offset, delay, jitter, packet count, dan frequency correction. Satu snapshot berguna; rangkaian yang diamati dari waktu ke waktu memberi informasi lebih banyak.

Jika chrony terpasang, gunakan interface miliknya:

chronyc tracking
chronyc sources -v

Manual resmi chronyc(1) menjelaskan tracking sebagai tampilan performa system clock dan sources -v sebagai tampilan status sumber. Dalam daftar sumber, * menandai sumber terbaik yang dipilih, + sumber lain yang digabungkan, x sumber yang dianggap tidak konsisten, dan ? sumber yang saat ini tidak dapat dipilih. Field Reach merangkum response valid terbaru; field ini perlu dibaca bersama field lain, bukan sebagai satu-satunya health score.

Pilih Client Berdasarkan Bukti yang Dibutuhkan

systemd-timesyncd memang dirancang kecil. Manualnya menyebut layanan ini sebagai client SNTP-only yang melakukan step untuk offset besar dan menyesuaikan selisih kecil secara bertahap. Untuk host sederhana yang memakai sumber tepercaya dan andal, peran yang lebih sempit itu mungkin sudah cukup. Integrasinya dengan timedatectl juga membuat audit dasar mudah dilakukan.

chrony mencakup rentang operasional yang lebih luas. FAQ resmi dan manualnya mendokumentasikan penggunaan serta pemilihan beberapa sumber secara simultan, laporan offset dan frequency yang rinci, penanganan jaringan terputus-putus, operasi NTP server, dan Network Time Security (NTS) opsional. Kemampuan itu berguna ketika perbedaan sumber, konektivitas tidak stabil, atau monitoring yang lebih kuat menjadi penting.

Ini bukan benchmark yang membuktikan satu client selalu lebih baik. Kesederhanaan adalah fitur ketika kebutuhannya sederhana; source selection yang lebih kaya adalah fitur ketika failure model membutuhkannya. Aturan pentingnya adalah mengenali satu komponen yang bertanggung jawab mendisiplinkan system clock. Jangan mengaktifkan client kedua hanya karena output status client pertama belum familier.

Konfigurasi sumber juga perlu dibatasi. timesyncd.conf(5) mendokumentasikan drop-in administrator di /etc/systemd/timesyncd.conf.d/, yang lebih baik daripada mengedit file milik vendor. chrony membedakan entry server dari pool dan dapat memilih beberapa sumber hasil resolusi. Dalam kedua kasus, gunakan sumber dengan kebijakan operasi yang dipahami, patuhi aturan public pool, dan jangan memperpendek poll interval tanpa alasan yang terbukti.

Sehat Berarti Lebih dari Sekadar “Active”

Tidak ada satu field yang menjawab semua pertanyaan waktu. Penilaian praktis menggabungkan beberapa sinyal:

  • Status layanan: Apakah client yang dimaksud berjalan dan tidak ada client pesaing yang tidak diharapkan?
  • Sumber terbaru: Apakah sebuah sumber dipilih, dapat dijangkau, dan memberi pengukuran yang diterima?
  • Offset dan ketidakpastian: Apakah nilai offset, delay, dispersion, atau root distance yang dilaporkan masuk akal bagi jaringan dan workload ini?
  • Tren: Apakah client tetap sehat setelah reboot, link terputus, dan periode congestion biasa?
  • Kebutuhan aplikasi: Apakah kondisi yang diamati cukup baik bagi komponen yang bergantung padanya?

Stratum perlu dibaca dengan sangat hati-hati. Nilai ini menjelaskan posisi sumber dalam hierarki NTP. Angka lebih rendah tidak otomatis membuktikan jalur yang lebih baik dari client ini: network delay, stabilitas sumber, ketidakpastian, dan kesepakatan dengan sumber lain tetap penting. Begitu pula, offset kecil dalam satu output command adalah pengukuran pada satu waktu, bukan sertifikat akurasi seumur hidup.

Urutan Boot Dapat Membuka Celah Ketepatan

Server dapat boot dengan perkiraan RTC yang buruk dan baru tersinkronisasi setelah jaringan tersedia. Ini menciptakan jendela ketika layanan awal melihat wall clock yang tidak akurat. Manual systemd-timesyncd menyatakan bahwa pemulihan timestamp tersimpan dapat membuat waktu bergerak maju secara kurang lebih monoton antarreboot, termasuk pada sistem tanpa RTC berbaterai. Manual itu juga memberi perbedaan penting: inisialisasi biasa tidak menahan setiap layanan sampai sumber jaringan yang akurat berhasil dicapai.

Jika aplikasi benar-benar tidak dapat mulai dengan aman sebelum sinkronisasi akurat, hal itu merupakan dependency eksplisit yang perlu dirancang dan diuji, bukan sesuatu yang disimpulkan dari “NTP enabled.” systemd menyediakan systemd-time-wait-sync.service dan time-sync.target untuk jenis ordering ini, tetapi keputusan untuk menunggu, timeout, atau berjalan dalam degraded mode tetap menjadi keputusan aplikasi. Membuat seluruh boot menunggu layanan publik yang tidak dapat dijangkau tanpa batas dapat menciptakan kegagalan lain.

Koreksi besar menimbulkan trade-off lain. systemd-timesyncd maupun chrony membedakan step langsung dari slewing bertahap. Manual chrony memperingatkan bahwa lompatan dapat berdampak serius pada software tertentu. Step terkontrol di sekitar boot dapat masuk akal ketika belum banyak pekerjaan stateful berjalan; memaksa lompatan pada server sibuk tidak seharusnya menjadi refleks troubleshooting.

Keamanan NTP Memiliki Batas

Network time dasar tidak boleh dianggap authenticated hanya karena datang dari hostname yang dikenal. Attacker pada jalur dapat mencoba memalsukan, mengubah, menunda, mengalihkan, atau membuang pertukaran yang tidak terautentikasi. Beberapa sumber dan sanity limit dapat mengurangi sebagian risiko, tetapi tidak mengubah packet tanpa autentikasi menjadi bukti kriptografis.

RFC 8915 mendefinisikan NTS untuk mode client-server NTP. NTS memakai TLS untuk key establishment dan extension field NTP yang terautentikasi untuk pertukaran waktu berikutnya. NTS dapat mengautentikasi server dan packet, memberi replay protection, serta mengikat response ke request. NTS tetap tidak dapat mencegah attacker pada jalur menunda atau membuang packet, jadi authenticated time merupakan bukti yang lebih kuat, bukan kepastian ajaib.

NTS juga memiliki ketegangan saat bootstrap: validasi TLS certificate sendiri bergantung pada tanggal lokal yang cukup masuk akal. RTC yang bekerja atau timestamp sebelumnya yang dipulihkan dengan aman dapat membantu. Menonaktifkan pemeriksaan waktu certificate melemahkan jaminan yang hendak diberikan NTS dan tidak seharusnya dijadikan perbaikan rutin.

Investigasi Kegagalan Singkat

Ketika sinkronisasi tidak ada atau stale, ikuti jalurnya secara berurutan alih-alih mengubah beberapa setting sekaligus:

  1. Pastikan timezone, interpretasi RTC, ringkasan system clock, dan time client yang aktif.
  2. Periksa status serta log khusus provider untuk server terpilih, pengukuran terakhir yang diterima, dan error eksplisit.
  3. Periksa apakah nama sumber dapat di-resolve. Kegagalan DNS dapat terlihat seperti kegagalan waktu.
  4. Periksa routing dan kebijakan firewall. Pertukaran NTP tradisional biasanya memakai UDP port 123; NTS key establishment memakai koneksi TLS terpisah dan membutuhkan server yang kompatibel.
  5. Bandingkan perilaku selama beberapa poll, jangan memaksa perubahan clock setelah satu response hilang.
  6. Setelah pulih, verifikasi aplikasi yang memakai waktu, bukan hanya time daemon.

Konektivitas terputus-putus mengubah standar keberhasilan. Home server yang offline tidak dapat terus-menerus bertanya kepada sumber Internet, tetapi client yang mampu dapat memperkirakan oscillator drift dan melanjutkan pengukuran ketika link kembali. Itu tidak membuat clock tetap benar selamanya saat offline. Kemampuan tersebut membuat error lebih mudah dikelola dan, yang tidak kalah penting, dapat diamati.

Jadikan Waktu sebagai Dependency Eksplisit

Clock server yang dapat diandalkan bukan satu nilai offset yang mengesankan. Ia adalah rantai yang terdokumentasi: RTC memberi titik awal boot yang masuk akal, satu client yang dikenal mendisiplinkan system clock, sumber tepercaya tetap dapat dijangkau, status menunjukkan ketidakpastian, dan aplikasi memakai wall atau monotonic time sesuai hal yang diukurnya.

Kebiasaan maintenance terkecil yang berguna adalah mencatat client mana yang bertanggung jawab, memeriksa status khusus provider setelah perubahan jaringan atau sistem yang berarti, dan mendefinisikan makna “cukup baik” bagi layanan yang bergantung padanya. NTP dapat membangun timeline bersama, tetapi tidak dapat menentukan seberapa besar ketidakpastian yang dapat ditoleransi aplikasi. Batas terakhir itu tetap menjadi pertanyaan engineering lokal.

References