{"id":19249,"date":"2026-05-12T11:52:55","date_gmt":"2026-05-12T09:52:55","guid":{"rendered":"https:\/\/webhosting.de\/server-time-synchronization-ntp-chrony-hosting-zeitsync\/"},"modified":"2026-05-12T11:52:55","modified_gmt":"2026-05-12T09:52:55","slug":"server-time-synchronization-ntp-chrony-hosting-time-sync","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/server-time-synchronization-ntp-chrony-hosting-zeitsync\/","title":{"rendered":"Server Time Synchronization with NTP and Chrony in hosting: A comprehensive guide"},"content":{"rendered":"<p>This guide shows how to reliably align server time with NTP and Chrony in hosting environments - from stratum design to monitoring. Who <strong>ntp chrony hosting<\/strong> correctly prevents time drift, protects authentication and keeps logs consistent.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>I will first summarize the most important aspects so that you can read the following chapters in a targeted manner.<\/p>\n<ul>\n  <li><strong>Chrony<\/strong> synchronizes faster and remains more accurate in unstable networks.<\/li>\n  <li><strong>stratum<\/strong>-architecture relieves the Internet and delivers consistent time.<\/li>\n  <li><strong>NTS<\/strong> protects time signals from manipulation and interception.<\/li>\n  <li><strong>Monitoring<\/strong> reports deviations early, before users notice them.<\/li>\n  <li><strong>Cluster<\/strong>Uniform time prevents data and log conflicts.<\/li>\n<\/ul>\n<p>I use these points as a common thread for planning, implementation and operation. This allows me to structure decisions, save effort and minimize <strong>Risks<\/strong>.<\/p>\n\n<h2>Why exact time synchronization in hosting is business-critical<\/h2>\n\n<p>Even small time deviations shift log sequences, break TLS handshakes and disrupt token validities. I often see in audits that a few seconds of drift leads to hours of troubleshooting. Consistent time strengthens <strong>Security<\/strong>, improves troubleshooting and keeps SLA promises. In multi-tier applications, milliseconds decide whether replication works properly or conflicts escalate. Failures, incorrectly triggered cron jobs and hard certificate errors can be avoided with a clean time basis. The article provides a practical introduction to the effects <a href=\"https:\/\/webhosting.de\/en\/server-time-drift-effects-applications-ntpcluster\/\">Effects of time drift<\/a>. Who takes time seriously, wins <strong>Transparency<\/strong> in every incident.<\/p>\n\n<h3>Compliance and operational reality<\/h3>\n<p>In regulated environments, I anchor time specifications in policies and SLOs: servers always run in UTC, applications are given tolerances for \u201eclock skew\u201c (e.g. 60-120 seconds in OIDC), and logs always carry time zone information. Audits (e.g. in accordance with ISO 27001) regularly check the correlation and immutability of timestamps. A viable time synchronization significantly reduces audit efforts because evidence (tracking, drift, stratum) is consistent.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/serverzeit-synchronisation-4827.png\" alt=\"Server time synchronization with NTP and Chrony\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NTP and Chrony in comparison: functionality, strengths, limitations<\/h2>\n\n<p>NTP is the protocol, Chrony is a modern implementation that scores particularly well with packet loss and intermittent connections. Compared to the classic ntpd, Chrony settles faster and keeps the local clock closer to the reference. I use Chrony as a client and as a server, depending on my role in the network. In edge locations with a shaky line, I see stable offsets and short recovery times. Important advantage: With NTS, Chrony can authenticate sources and fend off attacks, which I clearly prefer in sensitive networks. These features pay off directly <strong>Availability<\/strong> and data integrity.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspect<\/th>\n      <th>Chrony<\/th>\n      <th>ntpd<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Initial synchronization time<\/td>\n      <td>Very <strong>fast<\/strong><\/td>\n      <td>Slower<\/td>\n    <\/tr>\n    <tr>\n      <td>Packet loss behavior<\/td>\n      <td>High <strong>Tolerance<\/strong><\/td>\n      <td>More sensitive<\/td>\n    <\/tr>\n    <tr>\n      <td>Offline\/Intermittent<\/td>\n      <td>Good offline strategies<\/td>\n      <td>Restricted<\/td>\n    <\/tr>\n    <tr>\n      <td>NTS support<\/td>\n      <td>Yes (recommended)<\/td>\n      <td>Partially, depending on the build<\/td>\n    <\/tr>\n    <tr>\n      <td>Role in the network<\/td>\n      <td>Client and <strong>Server<\/strong><\/td>\n      <td>Client and server<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h3>Practical details that make the difference<\/h3>\n<ul>\n  <li><strong>IBurst and Polling<\/strong>With <em>iburst<\/em> I speed up the start significantly. I adjust Minpoll\/Maxpoll conservatively (e.g. 6\/10) to balance mains load and accuracy.<\/li>\n  <li><strong>Interleaved Mode<\/strong>Chrony can use interleaved mode if servers support it. This reduces jitter over rough connections.<\/li>\n  <li><strong>Step vs. slew<\/strong>: I deliberately correct large offsets using <em>makestep<\/em>, otherwise I let chronyd \u201eslewen\u201c so that services do not experience time travel.<\/li>\n  <li><strong>Orphan\/Holdover<\/strong>For isolated segments, I set up a local authority (with low priority) to keep clocks organized until external sources are back.<\/li>\n<\/ul>\n\n<h2>Stratum architecture: internal design for hosters and teams<\/h2>\n\n<p>I plan time hierarchies with clear strata to reduce internet dependency and control latency. Internal Stratum 3 servers supply nodes, VMs and containers centrally. This means that not every host has to radio outside, which improves range and security. The structure smoothes offsets in logs, keeps certificates valid and correctly orders events in databases. For isolated networks, I use a small internal cluster with redundant time sources and priorities. This order strengthens <strong>Consistency<\/strong> in operation and reduces surprises.<\/p>\n\n<h3>Anycast, DNS and locations<\/h3>\n<p>I distribute internal NTP servers via Anycast or DNS-Round-Robin. Anycast reduces latency automatically; DNS allows weights per location. It is important that the strata remain traceable and that sources from different sources (external pools, GPS\/PPS, reliable partners) are combined. In multi-region environments, local stratum servers isolate network interference and prevent cross-region drift.<\/p>\n\n<h3>IPv6, NAT and firewalls<\/h3>\n<p>I activate NTP and NTS consistently on IPv4 and IPv6. Behind NATs, I pay attention to outgoing UDP\/123 and incoming responses. I plan TCP port 4460 for NTS-KE and set restrictive ACLs on segment boundaries: Only defined client networks are allowed to make requests; only the stratum layer initiates outwards.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server_sync_meeting_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Set up Chrony: Configuration, parameters and clean defaults<\/h2>\n\n<p>The file \/etc\/chrony.conf controls the behavior of chronyd, and I deliberately keep it short. I set time sources with server, pool and peer, each with options for minpoll\/maxpoll and IBurst for fast start. I allow access via allow so that clients only request from designated networks. I use makestep to define the deviation at which a jump is made instead of a smooth correction - this prevents long drift phases after reboots or sleep states. rtcsync synchronizes the hardware clock; I use hwtimestamp on capable NICs for more precise time stamps. The driftfile speeds up the settling after reboots, which saves a lot of time in maintenance windows. <strong>Time budget<\/strong> saves.<\/p>\n\n<p>I also set clear source priorities: Internal servers first, then external pools, at the end individual entries for fall-back. This keeps the chain predictable even in the event of failures. For container hosts, I deactivate hypervisor time agents when Chrony is running to avoid duplicate corrections. Test runs in Staging uncover misconfigurations early on. I like to collect concrete steps in cheat sheets, such as these <a href=\"https:\/\/webhosting.de\/en\/how-time-drift-ntp-chrony-hosting-time-synchronization-praktica\/\">Practical time sync tips<\/a>. This reduces the error rate and raises my <strong>Quality<\/strong> in Changes.<\/p>\n\n<h3>Example chrony.conf with NTS and logging<\/h3>\n<pre><code># Sources with priorities\nserver ntp-intern-1.example.net iburst minpoll 6 maxpoll 10 prefer\nserver ntp-intern-2.example.net iburst minpoll 6 maxpoll 10\npool pool.ntp.org iburst maxsources 3\n# NTS-secured source (key exchange via TCP 4460)\nserver nts.example.net iburst nts\n\n# Access control (internal networks only)\nallow 10.0.0.0\/8\nallow 192.168.0.0\/16\n# optional: deny all; and explicitly set individual allow rules\n\n# Stability and correction\ndriftfile \/var\/lib\/chrony\/drift\nmakestep 1.0 3\nrtcsync\nmaxslewrate 1000 # ppms, limited aggressive corrections\nmaxdistance 3.0 # Ignore sources with too high delay distance\nminsources 2\n\n# Hardware timestamp (if supported by NIC\/kernel)\nhwtimestamp eth0\nhwtimestamp eth1\n\n# NTS trust and cookies\nntsdumpdir \/var\/lib\/chrony\/nts\n# ntstrustedcerts \/etc\/pki\/ca-trust\/extracted\/pem\/tls-ca-bundle.pem\n\n# Logging and diagnostics\nlogdir \/var\/log\/chrony\nlog tracking measurements statistics\nlogchange 0.5\n\n# Secure admin access\nbindcmdaddress 127.0.0.1\nDeactivate cmdport 0 # for pure clients\n<\/code><\/pre>\n\n<h3>Boot sequence and service dependencies<\/h3>\n<p>I only start chronyd when the network is \u201eonline\u201c and allow critical services (e.g. TLS gateways) to start after chronyd. The initial jump takes place via <em>makestep<\/em> - On systems with sensitive databases, I test in advance whether a step is tolerated. I keep the real-time clock up to date (<em>rtcsync<\/em>); after major interventions I deliberately write back (<em>hwclock -systohc<\/em>) so that reboots become stable more quickly.<\/p>\n\n<h3>Leap seconds and smearing<\/h3>\n<p>I make a conscious decision between a \u201ehard\u201c leap second and smearing. In environments with strict monotony requirements, I run smearing evenly over a window to avoid backward jumps. Important: The approach must be uniform cluster-wide, otherwise you artificially create jitter between services.<\/p>\n\n<h2>Monitoring and chronyc: read status, limit deviations<\/h2>\n\n<p>I check the status with chronyc tracking, sources and sourcestats because these commands quickly provide a clear picture. I set thresholds operationally, such as warning from 50 ms, alarm from 200 ms offset. chronyc activity and clients show me whether servers are using capacities properly. If necessary, I trigger a targeted jump with chronyc makestep, for example after long maintenance windows. For dashboards, I record offset, skew, stratum and reach so that trends become visible. Trends that are recognized early prevent incidents and preserve <strong>Quiet time<\/strong> in operation.<\/p>\n\n<h3>Operational thresholds and metrics<\/h3>\n<ul>\n  <li><strong>Offset<\/strong>Target in LAN under 1-5 ms, in WAN under 20-50 ms.<\/li>\n  <li><strong>Jitter<\/strong>Stable below 5 ms in LAN; outliers trigger investigations.<\/li>\n  <li><strong>stratum<\/strong>Clients ideal at 3-4; jumps indicate loss of source.<\/li>\n  <li><strong>Reach<\/strong>Convergence on 377 (octal) is my health indicator.<\/li>\n<\/ul>\n<p>I export tracking\/source data to the central monitoring system. Alerts only come in waves (with attenuation) to avoid flooding in the event of short-term packet losses. For change windows, I deactivate alerts specifically and document offsets before\/after the intervention.<\/p>\n\n<h3>Diagnostic snippets<\/h3>\n<pre><code># Overview\nchronyc tracking\nchronyc sources -v\nchronyc sourcestats -v\n\n# Check network path\nss -lunp | grep ':123'\ntcpdump -ni any udp port 123 -vv\n\n# Server load and clients\nchronyc activity\nchronyc clients\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server-sync-ntp-chrony-hosting-5842.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Clusters, VMs and containers: keep a consistent clock throughout<\/h2>\n\n<p>In clusters, no node can be out of line, otherwise election procedures, locks or replications will fail. I therefore set a common internal source and actively balance offsets. I switch off VM tools for time correction as soon as Chrony binds to the host in order to avoid rule conflicts. Containers inherit time from the host; I only use independent Chrony instances in the container for special requirements. For edge locations without Internet access, I provide local stratum servers. This discipline prevents <strong>Split-Brain<\/strong>-scenarios and reduces elusive race conditions.<\/p>\n\n<h3>Setting up virtualization cleanly<\/h3>\n<ul>\n  <li><strong>VMware\/Hyper-V<\/strong>Deactivate host time sync in guests if chronyd is leading in the guest or host. One system per level is responsible for the time.<\/li>\n  <li><strong>KVM<\/strong>: On stable <em>clocksource<\/em> pay attention. Modern CPUs provide stable TSC; otherwise rely on proven sources such as <em>kvm-clock<\/em> and observe jitter.<\/li>\n  <li><strong>Snapshots<\/strong>Check immediate offsets after resume. If necessary <em>makestep<\/em> before the read\/write load starts.<\/li>\n<\/ul>\n\n<h3>Kubernetes and containers<\/h3>\n<p>Nodes (workers) obtain time from the internal stratum server; pods inherit this time. Time manipulation in the pod requires elevated rights (CAP_SYS_TIME) - I avoid this by default. For time-critical (e.g. MTA, auth gateways) I position pods close to the source (network topology) and observe \u201ecold start\u201c offsets after deployment rollouts.<\/p>\n\n<h2>Safety: NTS, hardware timestamp and leap seconds<\/h2>\n\n<p>NTS protects me from man-in-the-middle attacks and secures the authenticity of the source. In sensitive networks, I activate NTS on exposed servers first and then scale it inwards. Hardware timestamps smooth out network latencies; on capable NICs, this significantly reduces fluctuations in the offset. I deliberately plan the handling of leap seconds so that time does not jump backwards. System services tolerate jumps differently well; I document behavior per service. This care strengthens <strong>Integrity<\/strong> of the measured values and prevents side effects.<\/p>\n\n<h3>NTS in practice<\/h3>\n<ul>\n  <li><strong>Key Exchange<\/strong> via TCP\/4460: Manage certificates and CA trust cleanly, test rotations at an early stage.<\/li>\n  <li><strong>Cookies<\/strong>Chrony stores NTS cookies locally; I secure the directories, set restrictive rights and monitor failures in logs.<\/li>\n  <li><strong>Fallback<\/strong>For failures, I define clear sequences (NTS \u2192 authenticated NTP \u2192 internal sources) to maintain predictability.<\/li>\n<\/ul>\n\n<h3>Rate limits and abuse protection<\/h3>\n<p>I limit requests per <em>rate limit<\/em> and activate kiss-o\u2018-death behavior to prevent amplification and abuse. On exposed servers <em>allow<\/em>\/<em>deny<\/em> strictly, and I log query spikes to detect botnet traffic early.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server_sync_ntp_chrony_8723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Troubleshooting: common errors and quick solutions<\/h2>\n\n<p>Mistake number one: Double correction by hypervisor tools and Chrony at the same time - I decide on one source and deactivate the rest. Secondly, firewalls often block UDP\/123; I check directions and rules on both sides. Thirdly, DNS entries or reverse lookups are not correct; Chrony then shows \u201eunreachable\u201c or \u201eno response\u201c. Fourthly, incorrect time zones interfere with task schedulers; a look at <a href=\"https:\/\/webhosting.de\/en\/cron-time-zone-issues-cron-jobs-scheduling-errors\/\">Cron Timezone Issues<\/a> saves hours here. Fifthly, incorrect makestep sabotages long recovery times; I set sensible limits and test reboots in the maintenance window. Clear runbooks and fixed <strong>Checklists<\/strong> help me to isolate errors quickly.<\/p>\n\n<h3>Systematic troubleshooting<\/h3>\n<ol>\n  <li><strong>Status<\/strong>: <em>timedatectl status<\/em>, <em>chronyc tracking<\/em> and <em>sources -v<\/em> check. Does the stratum or reach deviate?<\/li>\n  <li><strong>Net<\/strong>: <em>tcpdump<\/em> check for UDP\/123 and firewalls. Identify NAT asymmetries.<\/li>\n  <li><strong>RTC\/HW<\/strong>: <em>hwclock -show<\/em> and kernel logs. Note the drift of the hardware clock.<\/li>\n  <li><strong>Conflicts<\/strong>Disable other time services (systemd-timesyncd, VM-Tools).<\/li>\n  <li><strong>Source<\/strong>With <em>chronyc ntpdata<\/em> Validate the selected source. Mirror delay\/offset\/jitter against expectations.<\/li>\n<\/ol>\n\n<h3>Typical special cases<\/h3>\n<ul>\n  <li><strong>Resume from suspend<\/strong>Allow step or start services with a delay so that applications remain consistent.<\/li>\n  <li><strong>Silent partition<\/strong>In island mode, temporarily authorize internal source, but with clear identification of the stratum.<\/li>\n  <li><strong>Container<\/strong>Missing CAP_SYS_TIME results in \u201eOperation not permitted\u201c - therefore always obtain time from the host.<\/li>\n<\/ul>\n\n<h2>Operating guidelines, performance and costs under control<\/h2>\n\n<p>I define roles: Sources, relays and pure clients - this defines the responsibility per machine. Maintenance windows contain time checks before and after work, including capture of offsets. I reduce costs by bundling external queries and distributing internal servers via anycast or DNS round robin. I plan capacity with client numbers per server and practical reserves. This saves unnecessary exits to the Internet and reduces attack surfaces. Structured approach reduces <strong>Downtime costs<\/strong> and strengthens resilience.<\/p>\n\n<h3>Change and risk management<\/h3>\n<ul>\n  <li><strong>Before Changes<\/strong>Document baseline offsets, dampen alarms, clarify rollback paths.<\/li>\n  <li><strong>After Changes<\/strong>Measure time to synchronicity, compare offsets, explain deviations.<\/li>\n  <li><strong>Chaos tests<\/strong>Simulate packet loss and source failure to validate slew\/failover behavior.<\/li>\n<\/ul>\n\n<h3>Capacity and sizing<\/h3>\n<p>For large fleets, I plan fixed upper limits of clients per stratum server and activate rate limits. Measurements help to set poll intervals in such a way that the network and CPU load remain low without sacrificing accuracy. This saves costs and provides predictable buffers in the event of disruptions.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server_sync_ntp_3105.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Practical examples, metrics and performance measurement<\/h2>\n\n<p>I measure success with two figures: average offset in milliseconds and time to synchronicity after reboot. Both key figures belong in the dashboard and in the SLOs. I can see the effect immediately in log pipelines: fewer out-of-order entries, more stable correlations. In databases, the risk of conflicts during replication and locking is reduced. Certificate errors are visibly reduced because validity windows work properly. If you like experience reports and manuals, you will find additional orientation for <strong>Everyday life<\/strong> and operation.<\/p>\n\n<h3>Practical target values<\/h3>\n<ul>\n  <li><strong>Warm start<\/strong>Under 60 seconds to offset &lt; 20 ms in typical WAN segments.<\/li>\n  <li><strong>Cold start<\/strong>Less than 3 minutes to stable state (incl. RTC drift compensation).<\/li>\n  <li><strong>Long-term<\/strong>95th percentile offset in LAN &lt; 3 ms, in WAN &lt; 25 ms.<\/li>\n<\/ul>\n\n<h3>Evaluation and trends<\/h3>\n<p>I visualize offset and jitter distributions as histograms and correlates to network events. Predictable patterns (e.g. offsets after nightly backups) indicate bottlenecks in the network path or overly conservative polling. If limits are exceeded, I start upstream: check the source, measure latency, then examine the client side (jitter, CPU, IO).<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/hosting-serverzeit-4596.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Outlook and brief summary<\/h2>\n\n<p>With Chrony, I achieve short settling times, resilient offsets and predictable behavior in the event of an error. A clean stratum architecture keeps the load internal and protects external edges. NTS secures sources, monitoring recognizes trends early, and runbooks stop classic errors. Clusters remain consistent, logs remain organized, certificates remain valid. If you use these components consistently, you get reliable time as a silent performance factor. This is exactly where <strong>Discipline<\/strong> in daily operation.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guide to server time synchronization with NTP Chrony in hosting. Learn about Linux time management, stratum hierarchy and secure time synchronization.<\/p>","protected":false},"author":1,"featured_media":19242,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19249","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"98","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"ntp chrony hosting","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19242","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19249","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=19249"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19249\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19242"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19249"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19249"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19249"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}