{"id":15937,"date":"2025-12-09T15:24:23","date_gmt":"2025-12-09T14:24:23","guid":{"rendered":"https:\/\/webhosting.de\/wie-time-drift-ntp-chrony-hosting-zeitsynchronisation-praktica\/"},"modified":"2025-12-09T15:24:23","modified_gmt":"2025-12-09T14:24:23","slug":"how-time-drift-ntp-chrony-hosting-time-synchronization-praktica","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/wie-time-drift-ntp-chrony-hosting-zeitsynchronisation-praktica\/","title":{"rendered":"How time drift can slow down servers \u2013 NTP, Chrony, and time synchronization"},"content":{"rendered":"<p><strong>NTP<\/strong> Chrony Hosting stops time drift, which slows down servers, by quickly synchronizing clocks, organizing log times, and keeping authentications reliable. I'll show you how. <strong>Chrony<\/strong>, NTP, and systemd-timesyncd interact, why drift occurs, and which settings prevent outages and security risks in hosting environments.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Time drift<\/strong>: Causes, consequences, and why milliseconds matter<\/li>\n  <li><strong>NTP hierarchy<\/strong>Stratum design for internal time sources<\/li>\n  <li><strong>Chrony<\/strong> vs. ntpd vs. systemd-timesyncd in data centers<\/li>\n  <li><strong>NTS<\/strong> &amp; Hardware timestamps: Security and accuracy<\/li>\n  <li><strong>Monitoring<\/strong> &amp; Troubleshooting for lasting consistency<\/li>\n<\/ul>\n\n<h2>How server time drift occurs and what its effects are<\/h2>\n\n<p>Time drift occurs because the <strong>RTC<\/strong> A host may run slightly too fast or too slow, and the error accumulates with each passing day. Even small deviations can generate contradictory results. <strong>Timestamp<\/strong>, which disrupts transactions, caches, and replication. Certificates can suddenly appear \u201etoo early\u201c or \u201etoo late,\u201c and authentications fail. In distributed systems, the order of events is lost and debugging becomes difficult or impossible. In hosting environments, I regularly see that a lack of synchronization leads to failures that can be avoided with solid time design.<\/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\/2025\/12\/zeitdrift-serverproblem-2861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NTP stratum explained briefly<\/h2>\n\n<p>The <strong>stratum<\/strong>The model organizes time sources hierarchically and reduces dependencies on the Internet. Stratum 0 are <strong>reference watches<\/strong> such as GPS or radio; Stratum 1 servers are directly connected to them; Stratum 2 obtains data from Stratum 1. In hosting environments, it is worth having an internal Stratum 3 server that supplies all nodes and reduces external load. This allows me to distribute a uniform time to hosts and containers without sending each node to the Internet. This architecture enables consistent logs, matching certificate windows, and replicated databases with clean sequencing.<\/p>\n\n<h2>NTP, Chrony, or systemd-timesyncd? The comparison<\/h2>\n\n<p>I set <strong>Chrony<\/strong> in productive setups because it engages faster and tracks cleanly on unstable networks. The classic <strong>ntpd<\/strong> Works reliably, but takes longer to \u201esettle in.\u201c systemd-timesyncd is lightweight and sufficient for simple hosts, but cannot be used as a server. For clusters or hosting, I recommend a uniform implementation on all nodes to avoid mixed operation and side effects. The following table summarizes the most important differences.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>implementation<\/th>\n      <th>Strengths<\/th>\n      <th>Weaknesses<\/th>\n      <th>Suitable for<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>Chrony<\/strong><\/td>\n      <td>Fast synchronization, tolerant of packet loss, server and client mode, good offline handling<\/td>\n      <td>More options require clean configuration<\/td>\n      <td>Productive servers, clouds, VMs, containers<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>ntpd<\/strong><\/td>\n      <td>Tried and tested over many years, widely available<\/td>\n      <td>Slow to start up, less flexible with mobile hosts<\/td>\n      <td>Legacy environments, conservative setups<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>systemd-timesyncd<\/strong><\/td>\n      <td>Slim, SNTP client, virtually \u201ezero config\u201c<\/td>\n      <td>No server mode, limited features<\/td>\n      <td>Small servers, appliances, simple VMs<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/timedrift_meeting_9273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Role model: Clearly separate time clients and internal servers<\/h2>\n\n<p>In practice, I make a strict distinction between <strong>Client only<\/strong>-Hosts and internal <strong>NTP servers<\/strong>. Clients only query defined sources and do not offer an NTP port themselves. Internal servers aggregate multiple sources, check quality, and distribute time to the environment. This reduces the attack surface and keeps the chain of dependency short.<\/p>\n\n<p>It is important to set polling intervals and preferences correctly. I mark a reliable internal source with <code>prefer<\/code> and keep external providers as a fallback. In networks with latency fluctuations, I occasionally lower <code>minpoll<\/code>, To measure corrections more quickly, but increase <code>maxpoll<\/code> again once stability has been achieved in order to keep network load low.<\/p>\n\n<h2>Chrony in practice: Configuration for hosting<\/h2>\n\n<p>I start with a clear <strong>chrony.conf<\/strong>, which defines drift, stratum, and accesses. A minimal basis includes:<\/p>\n<p><code>driftfile \/var\/lib\/chrony\/drift<br\/>\nlocal stratum 8<br\/>\nmanual<br\/>\nallow 192.168.0.0\/16<\/code><\/p>\n<p>The <strong>drift file<\/strong> remembers the clock error and speeds up the correction after reboots. With \u201elocal stratum 8,\u201c the internal server remains low priority if external sources are available. \u201eallow\u201c controls which networks are allowed to obtain time and prevents abuse. I activate the service with <code>systemctl start chronyd<\/code> and <code>systemctl enable chronyd<\/code> and then check the status and sources.<\/p>\n\n<h3>Client-only and server profiles<\/h3>\n<p>On pure clients, I disable the server port and keep the configuration lean:<\/p>\n<p><code># Client-only profile<br\/>\nserver ntp-internal.example iburst prefer<br\/>\nserver ntp-external-1.example iburst<br\/>\nserver ntp-external-2.example iburst<br\/>\nport 0<br\/>\nmakestep 1.0 3<br\/>\nrtcsync<br\/>\nleapsectz right\/UTC<\/code><\/p>\n<p><code>port 0<\/code> prevents the host itself from offering time. <code>makestep 1.0 3<\/code> Allows a hard correction &gt;1s in the first three measurements, after which only <em>geslewt<\/em> (slightly adjusted). <code>rtcsync<\/code> keeps the RTC synchronized at reasonable intervals so that reboots start without major jumps.<\/p>\n\n<p>On internal NTP servers, I consolidate sources and finely control access:<\/p>\n<p><code># Internal NTP server<br\/>\npool 0.pool.example iburst maxsources 4<br\/>\nserver ref1.example iburst prefer nts<br\/>\nserver ref2.example iburst nts<br\/>\nallow 10.0.0.0\/8<br\/>\nallow 192.168.0.0\/16<br\/>\nbind address 0.0.0.0<br\/>\nbindcmdaddress 127.0.0.1<br\/>\ncmdallow 127.0.0.1<br\/>\ndriftfile \/var\/lib\/chrony\/drift<br\/>\nmakestep 0.5 5<br\/>\nlocal stratum 8<br\/>\nleapsectz right\/UTC<\/code><\/p>\n<p>I bind the command socket to <code>127.0.0.1<\/code> and only allow it locally. <code>pool<\/code> automatically keeps multiple sources up to date. <code>prefer<\/code> sets the desired primary source. In larger setups, I set <code>bind address<\/code> targeted at a management VLAN.<\/p>\n\n<h3>Polling, source quality, and stability<\/h3>\n<p>In the case of unstable networks, I initially increase the measurement density and then scale up after stabilization:<\/p>\n<p><code>server ntp-external-1.example iburst minpoll 6 maxpoll 10<\/code><\/p>\n<p>With <code>minsamples<\/code>, <code>maxsamples<\/code> and <code>maxdistance<\/code> I cancel bad sources early on. For asynchronous paths or asymmetric routing, it helps to <code>hw timestamp<\/code> Reducing jitter on suitable NICs:<\/p>\n<p><code>hwtimestamp eth0<\/code><\/p>\n\n<h2>Security and accuracy: NTS, hardware timestamps, leap seconds<\/h2>\n\n<p>I protect NTP connections with <strong>NTS<\/strong>, so that an attacker cannot inject false time data. An entry such as <code>server time.cloudflare.com iburst nts<\/code> provides a quick start through <strong>iburst<\/strong> and cryptographic security. Where the network card allows it, I activate hardware timestamping to circumvent latency fluctuations in the kernel. For leap seconds, I use \u201eleapsectz right\/UTC\u201c so that services do not experience hard time jumps. This combination keeps services reliable and prevents errors in sensitive applications.<\/p>\n\n<h3>Curing and mesh design<\/h3>\n<p>I limit myself <strong>UDP\/123<\/strong> strictly to the designated networks, both in the direction of <em>in detail<\/em> (clients \u2192 internal server) as well as <em>outgoing<\/em> (Server \u2192 external sources). On clients, I set <code>port 0<\/code>, so that they cannot be misused as a source in the first place. <code>allow<\/code>\/<code>deny<\/code> Chrony provides additional filtering. In segmented networks, I position the internal servers in a network with low latency to the workers and keep the path deterministic (no asymmetric routes, no excessive shaping).<\/p>\n\n<p>NTS requires an initial key agreement via a dedicated port. I only allow this target port to be used by trusted providers. If NTS fails, I define a deliberate fallback behavior (strict alarm instead of silent switching to unsecured sources). This way, I avoid a \u201esilent decay\u201c of security.<\/p>\n\n<h3>Leap second strategies and smearing<\/h3>\n<p>I decide per environment: classic leap handling (UTC with leap second) or <strong>Leapsmearing<\/strong>, where the second is smoothed over a window. Important: Do not mix. If some sources smear and others do not, permanent offsets will occur. In critical clusters, I keep the entire fleet on the same line and document the choice. Chrony allows clean leap handling via <code>leapsectz<\/code>; if you smooth, you must plan this consistently for all nodes.<\/p>\n\n<h2>Monitoring and troubleshooting: Making drift visible<\/h2>\n\n<p>I check status and offsets with <strong>timedatectl<\/strong> as well as Chrony tools such as <code>chronyc sources<\/code> and <code>tracking<\/code>. Deviations between RTC and system time are normal at first, but should quickly become smaller. For long-term monitoring, I integrate metrics and alarms into a <a href=\"https:\/\/webhosting.de\/en\/grafana-prometheus-hosting-monitoring-stack-dashboard-serverwatch-enhance\/\">monitoring stack<\/a>. This allows me to identify trends, peaks, and outliers before users notice anything. Alerts are triggered automatically when offsets exceed defined thresholds.<\/p>\n\n<h3>Key figures and alarm thresholds<\/h3>\n<ul>\n  <li><strong>system offset<\/strong> (Tracking last\/avg offset): Warning from 5 ms, critical from 25 ms in web\/DB stacks.<\/li>\n  <li><strong>Root dispersion<\/strong>Indicates the uncertainty of the source. If it increases permanently, I respond by changing sources.<\/li>\n  <li><strong>Reachability<\/strong> and <strong>Jitter<\/strong> Source: Early detection of packet loss and instability.<\/li>\n  <li><strong>stratum<\/strong>Unexpected stratum increases indicate insulation or source loss.<\/li>\n<\/ul>\n<p>For ad hoc diagnoses, I also use:<\/p>\n<p><code>chronyc sourcestats -v<br\/>\nchronyc ntpdata<br\/>\nchronyc rtcdata<br\/>\nchronic activity<\/code><\/p>\n<p>Shows <code>activity<\/code> many invalid sources, I check the firewall, MTU\/fragmentation, and asymmetric paths. For large jumps after reboots, <code>makestep<\/code> often not set or blocked by thresholds that are too narrow.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/zeitdrift-server-synchronisation-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Best practices for consistent time in clusters<\/h2>\n\n<p>I consider the time source redundant, typically with at least three <strong>Servers<\/strong>, so that one can fail. An internal Stratum 3 server supplies the fleet and itself draws from several Stratum 2 sources. I avoid mixed operation with ntpd and Chrony, as different algorithms can cause unexpected <strong>offsets<\/strong> I save the RTC in UTC with <code>timedatectl set-local-rtc 0<\/code>, so that summer time changes don't bring any surprises. I document every change so that I can quickly understand the history in the event of a malfunction.<\/p>\n\n<h3>Kubernetes and orchestration<\/h3>\n<p>In Kubernetes and similar orchestrations, I only set Chrony on the <strong>nodes<\/strong>, not in individual pods. Containers inherit the host time; duplicate corrections lead to drift. Components such as etcd are sensitive to time errors \u2013 even double-digit milliseconds can affect election timeouts. I make sure that the control plane and worker use the same internal source and that no pod\/node with leapsmear mix is in use.<\/p>\n\n<h3>Cloud features<\/h3>\n<p>Many cloud providers offer <strong>internal time servers<\/strong> ready. I like to use these as my primary source (low latency) and supplement them with external NTS sources as a fallback. For instances with <em>hibernation<\/em> or <em>stops<\/em> I allow initial steps via <code>makestep<\/code>. I disable host-to-guest time synchronization via agents when Chrony is active to avoid double corrections.<\/p>\n\n<h2>Special scenarios: VMs, containers, and cloud<\/h2>\n\n<p>In VMs, I pay attention to host-to-guest time, because duplicate <strong>Corrections<\/strong> (Hypervisor and guest) create chaos. Containers draw time from the host, so maintenance focuses on the underlying infrastructure. In elastic environments where instances start frequently, fast <strong>convergence<\/strong> from Chrony. At edge locations with poor connectivity, you benefit from Chrony's behavior in the event of packet loss and temporary offline phases. For performance analyses related to time reference and latency, this helps me <a href=\"https:\/\/webhosting.de\/en\/server-response-time-analysis-ttfb-tti-optimization-speed-glance\/\">Response time analysis<\/a>.<\/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\/2025\/12\/zeitdrift-servercloud-4392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Performance effects: databases, logs, and certificates<\/h2>\n\n<p>Clean time reduces strange <strong>Deadlocks<\/strong> in databases because transaction sequences remain consistent. Caches invalidate correctly, CRLs and OCSPs work in real time windows. In practice, many \u201eghost errors\u201c disappear when offsets are under control. For correct correlation of events, I rely on central <a href=\"https:\/\/webhosting.de\/en\/log-aggregation-hosting-server-optimization-insights-dashboard-backup\/\">log analysis<\/a> with an identical time source. Certificates behave more reliably because validity windows match the system time.<\/p>\n\n<h2>Migration path to Chrony without interruptions<\/h2>\n\n<p>I plan to implement the change in waves so that <strong>Services<\/strong> I'll build an internal Chrony server first and have some staging hosts point to it. Once the sources are running smoothly, I'll gradually switch over the productive nodes. During the migration, I'll measure offsets and wait times to spot any deviations early on. Once everything is consistent, I'll deactivate the old ntpd instances and clean up any old data.<\/p>\n\n<h3>Rollback and contingency plan<\/h3>\n<p>I hold a <strong>Rollback<\/strong> Ready: I version old configurations and document a sequence for returning to ntpd or systemd-timesyncd, if necessary. For emergencies, I write a short runbook: pause services, <code>chronyd<\/code> Stop, set time manually (only if absolutely necessary), restart service, check sources, monitor offsets. It is critical to limit manual intervention to avoid jumps in applications.<\/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\/2025\/12\/zeitdrift_server_ntp_2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Checklist for implementation<\/h2>\n\n<p>I start by defining clear <strong>time sources<\/strong> and the target hierarchy with an internal Stratum 3 server. I then create a uniform configuration for all hosts, test it in staging, and document it. I activate NTS where appropriate and check hardware timestamping on the appropriate network card. I then integrate metrics into alarms and set offset thresholds. Finally, I schedule regular checks so that time errors don't become significant in the first place.<\/p>\n\n<h3>Runbook: 10-minute health check<\/h3>\n<p>When something seems \u201estrange,\u201c I proceed as follows:<\/p>\n<ol>\n  <li><strong>system status<\/strong>: <code>timedatectl<\/code> (NTP active? RTC in UTC?)<\/li>\n  <li><strong>Sources<\/strong>: <code>chronyc sources -v<\/code> (Reach, Stratum, Jitter)<\/li>\n  <li><strong>Tracking<\/strong>: <code>chronyc tracking<\/code> (Offset, skew, root dispersion)<\/li>\n  <li><strong>Net<\/strong>Check firewalls\/ACLs for UDP\/123, measure latency\/loss<\/li>\n  <li><strong>Drift<\/strong>: <code>chronyc source stats<\/code> observe for several minutes<\/li>\n  <li><strong>RTC<\/strong>: <code>chronyc rtcdata<\/code>, if applicable. <code>rtcsync<\/code> activate<\/li>\n  <li><strong>Security<\/strong>Check NTS status, no silent degradation<\/li>\n<\/ol>\n\n<h2>Costs and benefits in euros<\/h2>\n\n<p>An incorrect <strong>clock<\/strong> quickly costs time and money: failed deployments, support cases, and SLA deductions add up. Setting up an internal Chrony server and monitoring is inexpensive, often costing only a few hundred dollars. On the other hand, avoided downtime can easily save four to five figures in <strong>Euro<\/strong> endanger. Especially in clusters with many transactions, synchronization pays off day after day. I therefore see NTP\/NTS and Chrony as a must rather than an option.<\/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\/2025\/12\/zeitdrift-server-ntp-8412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Summary<\/h2>\n\n<p><strong>Time drift<\/strong> slows down servers, confuses logs, and throws certificates out of sync. With Chrony, NTP, and an internal stratum design, I keep clocks synchronized and services reliable. NTS protects the source, hardware timestamping smooths latency, and correct leap second handling prevents jumps. Monitoring with metrics and alarms shows deviations before users notice them. Those who set up NTP Chrony Hosting cleanly will enjoy consistent time windows, fewer disruptions, and measurable benefits in dollars.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how to fix server time drift with NTP and Chrony. Our complete guide to hosting accuracy shows practical implementations.<\/p>","protected":false},"author":1,"featured_media":15930,"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-15937","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":"2490","_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":null,"_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":"15930","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/15937","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=15937"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/15937\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/15930"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=15937"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=15937"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=15937"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}