{"id":20100,"date":"2026-07-28T15:05:55","date_gmt":"2026-07-28T13:05:55","guid":{"rendered":"https:\/\/webhosting.de\/redis-persistence-rdb-aof-hosting-server-anleitung\/"},"modified":"2026-07-28T15:05:55","modified_gmt":"2026-07-28T13:05:55","slug":"redis-persistence-rdb-aof-hosting-server-guide","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/redis-persistence-rdb-aof-hosting-server-anleitung\/","title":{"rendered":"Choosing the Right Redis Persistence Method: Redis RDB or Redis AOF for Hosting Servers?"},"content":{"rendered":"<p>I determine the appropriate Redis persistence option for hosting servers by carefully weighing RTO, RPO, I\/O profiles, and workload significance against one another. When choosing between Redis RDB, Redis AOF, or Hybrid, I consider data criticality, recovery time, and hardware performance to ensure that performance and data security are well-balanced.<\/p>\n\n<h2>Key points<\/h2>\n<p>To ensure that the decision is well-informed, I will briefly summarize the most important aspects and weigh their <strong>Relevance<\/strong> for hosting servers.<\/p>\n<ul>\n  <li><strong>Data loss<\/strong>: RDB risks minutes, while AOF risks about one second with everysec.<\/li>\n  <li><strong>Startup Period<\/strong>: RDB starts up faster; AOF depends on the log size.<\/li>\n  <li><strong>I\/O Profile<\/strong>: RDB generates spikes, while AOF writes continuously.<\/li>\n  <li><strong>File size<\/strong>: RDB remains compact, while AOF grows and rewrites.<\/li>\n  <li><strong>Hybrid<\/strong>: Kombi offers security and flexible restarts.<\/li>\n<\/ul>\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\/07\/redis-persistence-8234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Specify RTO and RPO<\/h2>\n\n<p>I begin every decision with clear goals for <strong>RTO<\/strong> and RPO, because they directly determine how strictly I back up Redis. If I can accept a maximum of one second of data loss, AOF works well with \"everysec,\" while RDB can take on significantly more risk with a 5-minute snapshot. If I need very short restart times, I use RDB as a fast anchor and keep AOF on standby as a safety net. If I\u2019m writing to slow disks, I throttle AOF\u2019s fsync or optimize storage to avoid latency spikes. This is how I derive a suitable approach from measurable goals. <strong>Strategy<\/strong> ...and link technology to operational requirements.<\/p>\n\n<h2>How Redis RDB Works in Everyday Hosting<\/h2>\n\n<p>RDB creates periodic snapshots and stores a compact <strong>.rdb<\/strong>-A file that loads very quickly. I set save intervals based on data volume and change rate so that the gap between snapshots remains predictable. During the fork, I monitor RAM headroom to ensure that copy-on-write doesn\u2019t cause memory pressure. If the focus is on caching or less critical metrics, I use RDB-only with short intervals and maintain offsite backups. This way, I ensure fast restarts, minimize I\/O during normal operation, and keep the RDB files <strong>backup-capable<\/strong>.<\/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\/07\/RedisPersistenceOptionen1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Setting AOF Correctly: \"appendfsync everysec\" Is a Good Default<\/h2>\n\n<p>In the AOF log, I write every write operation <strong>Operation<\/strong> and control durability using `appendfsync`. With `everysec`, I typically lose at most one second in the event of a crash, without slowing down throughput too much. For very sensitive data, `always` can be useful, but in that case I calculate the performance loss and test it under realistic conditions. I schedule regular AOF rewrites to prevent the file from growing unchecked and to ensure that restores remain fast. For queues, configurations, and transactions, AOF thus provides a reliable <strong>Protection<\/strong>.<\/p>\n\n<h2>Direct Comparison and Impact on Hosting Servers<\/h2>\n\n<p>Before making a choice, I document the key differences in a structured way so that I can assign workloads accurately and <strong>Resources<\/strong> plan. The following table provides a concise overview of the characteristics, behavior, and typical effects on the hosting environment. I use this comparison as a quick reference when defining profiles for caches, sessions, and queues. Especially on mixed-use servers hosting many projects, this overview helps me identify I\/O spikes and mitigate them effectively. This ensures the technology aligns with the application and remains reliable in day-to-day operations. <strong>predictable<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterion<\/th>\n      <th>RDB<\/th>\n      <th>AOF<\/th>\n      <th>Impact on Hosting Servers<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Data loss<\/td>\n      <td>Everything since the last snapshot<\/td>\n      <td>Depends on fsync; everysec ~1 second<\/td>\n      <td>Select policies strictly in accordance with the RPO<\/td>\n    <\/tr>\n    <tr>\n      <td>Startup Period<\/td>\n      <td>Very fast (one file)<\/td>\n      <td>Slower, log is being played<\/td>\n      <td>Calculate Maintenance Windows Realistically<\/td>\n    <\/tr>\n    <tr>\n      <td>File size<\/td>\n      <td>Compact<\/td>\n      <td>Larger; rewrite needed<\/td>\n      <td>Plan for Storage Space and Rewrites<\/td>\n    <\/tr>\n    <tr>\n      <td>I\/O Profile<\/td>\n      <td>Peaks in the Snapshot<\/td>\n      <td>Continuously, depending on fsync<\/td>\n      <td>Consider SSD IOPS and Latencies<\/td>\n    <\/tr>\n    <tr>\n      <td>Transparency<\/td>\n      <td>Binary, unreadable<\/td>\n      <td>Readable Commands<\/td>\n      <td>Simplifies error analysis and audits<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Hybrid Mode: Combining Security with Fast Restarts<\/h2>\n\n<p>I combine AOF and RDB when I have minimal <strong>Data gap<\/strong> and need good startup times. AOF captures almost all changes, while RDB serves as a lightweight anchor for backups and fast clones. With Redis 7, hybrid improvements result in shorter restore times and, in some cases, smaller logs. I\u2019m testing the restart with both artifacts so I know how long a recovery would take in a real-world scenario. This way, I leverage the strengths of both methods and keep the risks manageable. <strong>small<\/strong>.<\/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\/07\/redis-persistence-choice-4897.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Typical Uses on Hosting Servers<\/h2>\n\n<p>For HTTP sessions and user state, I prefer Hybrid with AOF everysec, so that only very short <strong>Gaps<\/strong> may occur. I often run pure caches with volatile data in RDB-only mode or disable persistence if the source fills up quickly. I back up jobs, queues, and events using AOF every second and supplement this with regular snapshots for offsite backups. If you\u2019d like to understand sessions in more detail, you can find background information at <a href=\"https:\/\/webhosting.de\/en\/session-management-webhosting-redis-database-storage\/\">Sessions with Redis<\/a>. This ensures that each application receives the appropriate <strong>Durability<\/strong> without unnecessary I\/O overhead.<\/p>\n\n<h2>Best Practices for Operation and Maintenance<\/h2>\n\n<p>I schedule offsite backups of the RDB and AOF files and regularly test the restore process in the staging environment so that the <strong>RTO<\/strong> remains real. I manage AOF rewrites to keep log size and restore time within reasonable limits. Monitoring tracks I\/O latencies, AOF file size, and rewrite duration so that trends don\u2019t catch me off guard. Documentation clearly records save intervals and the appendfsync policy, especially on multi-tenant servers. If I encounter unexpected slowness, I check I\/O, the fsync policy, and fork behavior; I provide suggestions via <a href=\"https:\/\/webhosting.de\/en\/why-redis-is-slower-than-expected-typical-misconfigurations-cacheopt\/\">Is Redis Slow? Causes<\/a>, which I test in real-world situations before adopting them. That way, the service remains practical in everyday life <strong>conclusive<\/strong> manageable.<\/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\/07\/redis_persistence_auswahl_3245.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Storage, IOPS, and Hosting Layout<\/h2>\n\n<p>AOF needs fast <strong>SSDs<\/strong> with stable IOPS; otherwise, latencies increase and the application experiences delays. When writing to network storage, I evaluate throughput and latency spikes, because `appendfsync` directly affects these values. I separate Redis storage if other services cause spikes, or I reserve dedicated resources for AOF logs. For shared hosts, I check whether dedicated instances make sense; I get guidance from <a href=\"https:\/\/webhosting.de\/en\/redis-shared-vs-dedicated-performance-security-cacheboost\/\">Shared vs. dedicated<\/a>. Only with a clean I\/O profile can Redis achieve the low <strong>Latencies<\/strong> deliver what I expect.<\/p>\n\n<h2>Recommended Settings for Common Scenarios<\/h2>\n\n<p>For production web applications that use caching and sessions, I choose RDB + AOF and set `appendfsync` to `everysec` to ensure high performance and minimize data loss. In pure cache tiers, RDB-only is often sufficient\u2014sometimes even without persistence\u2014because the data source populates quickly; I clearly document this risk. Business-critical queues run with AOF set to everysec or, in rare cases, always, when no data loss is acceptable; RDB snapshots supplement offsite backups and speed up cloning processes. Before going live, I test for failures, restores, startup time, and data consistency to avoid any surprises. Based on this, I calculate storage requirements, plan rewrites, and verify whether the <strong>Hardware<\/strong> that safely supports the load.<\/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\/07\/redis-persistence-8493.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Thinking About Replication, Failover, and Persistence as a Whole<\/h2>\n<p>I keep roles clearly separated: The primary server provides low latency, while a replica handles the additional persistence load. Specifically: Primary with RDB + AOF every second, replica with an identical or stricter policy. In the event of a failover (Sentinel\/cluster), the replica takes over with complete artifacts, and I don\u2019t lose more than my RPO allows. If I want to smooth out peaks on the primary, I enable AOF there sparingly or even disable AOF on the primary altogether and back up more strictly on the replica\u2014knowing full well that in the event of a primary failure, more data may be lost until the last replica ACK is received. I explicitly document this trade-off. It\u2019s important that replications are stable and that backups are taken from a replicated, <strong>consistent<\/strong> may be appealed to a higher court.<\/p>\n\n<h2>Configuration Details That Are Often Overlooked<\/h2>\n<ul>\n  <li><strong>aof-use-rdb-preamble<\/strong>: Creates an RDB base in AOF, speeds up restarts, and keeps logs smaller\u2014my default setting for hybrid mode.<\/li>\n  <li><strong>aof-rewrite-incremental-fsync<\/strong>: Smooths I\/O during the rewrite; avoids long Fsync pauses.<\/li>\n  <li><strong>auto-aof-rewrite-percentage \/ -min-size<\/strong>: I choose practical thresholds (e.g., 100% and 64\u2013256 MB), depending on the volume of changes.<\/li>\n  <li><strong>no-append-fsync-on-rewrite<\/strong>: On underpowered storage, I sometimes set this to \"yes,\" but I accept a slightly larger loss window during the rewrite.<\/li>\n  <li><strong>rdb-save-incremental-fsync<\/strong>: Enabled to distribute snapshot I\/O.<\/li>\n  <li><strong>rdbcompression \/ rdbchecksum<\/strong>: Compression saves space, and the checksum enhances security; I'm willing to accept the slight CPU load.<\/li>\n  <li><strong>stop-writes-on-bgsave-error<\/strong>: I'll leave it set to \"yes\" so that errors stand out and people don't keep writing without noticing them.<\/li>\n  <li><strong>aof-load-truncated<\/strong>: On yes, Redis also starts with a slightly truncated log and discards corrupted tail data\u2014which is good for availability, but I have restore tests ready just in case.<\/li>\n  <li><strong>dir, dbfilename, appendfilename<\/strong>: I specifically set paths to fast, reliable storage devices and configure secure permissions (umask\/Owner) to ensure compliance.<\/li>\n  <li><strong>lazyfree options<\/strong>: lazyfree-lazy-eviction\/expire help reduce block times and relieve the load on Fork-CoW, especially during large key cleanups.<\/li>\n<\/ul>\n\n<h2>OS and File System Tuning for Stable Fsyncs<\/h2>\n<p>I'm disabling Transparent Huge Pages (<strong>THP=never<\/strong>), set <strong>vm.overcommit_memory=1<\/strong> and make sure there are enough free Hugepage reserves\u2014this noticeably reduces fork latencies. At the filesystem level, I avoid risky tweaks; I stick to safe defaults (e.g., ext4 or XFS with barriers enabled) and use <strong>noatime<\/strong>, to avoid unnecessary metadata writes. I tune the scheduler and queue depth to the SSD so that Fsync spikes are handled smoothly. I pay special attention to virtualization and network storage: I verify that Fsync actually reaches the physical disk and that no caching layer causes any surprises.<\/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\/07\/hosting-server-raum-4892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Accurately Calculate Memory and Fork Headroom<\/h2>\n<p>During the BGSAVE\/Rewrite fork, the child process requires memory for Copy-on-Write. I reserve: the instance\u2019s RAM plus 10\u201330% headroom, depending on the change rate and object size. If the dataset grows significantly during the fork, the CoW requirement increases; therefore, I schedule maintenance windows for large rewrites or briefly throttle the write load. In multi-tenant setups, I distribute instances across hosts so that a fork doesn\u2019t put all services under pressure at the same time.<\/p>\n\n<h2>Backup Strategy and Recovery Tests in Progress<\/h2>\n<p>I secure <strong>both<\/strong> Artifact types: current RDB and consistent AOF segments. For hot backups, I start a <em>BGREWRITEAOF<\/em> Or use filesystem snapshots (LVM\/ZFS) to ensure the files in the package are consistent. I verify backups using `redis-check-rdb` and `redis-check-aof` and regularly load them into staging to measure actual restore times. Rotation is important: I maintain multiple generations, encrypt offsite copies, and document the recovery plan, including responsibilities and the maximum tolerable <strong>Downtime<\/strong>.<\/p>\n\n<h2>Sizing: Planning Space and I\/O Requirements<\/h2>\n<p>I\u2019m roughly estimating: data set size in RAM plus 20\u201350% for the RDB file (depending on compression), as well as AOF growth proportional to write commands. Example: 20,000 writes\/s \u00d7 120 bytes\/command equals 2.4 MB\/s raw log; this shrinks with rewrites, but the storage must be able to handle peaks. I set auto-rewrite thresholds so that rewrites occur during periods of moderate load and the AOF base isn\u2019t rebuilt unnecessarily often. For redundancy, I plan for at least 2\u20133 times the dataset size in disk space so that parallel snapshots\/rewrites don\u2019t start up and immediately run out of space.<\/p>\n\n<h2>Containers and Cloud Volumes in a Hosting Context<\/h2>\n<p>In containers, I strictly decouple data from the pod\u2019s lifecycle: persistent volumes with guaranteed IOPS, no overlay file systems for AOF. Readiness checks account for longer startup times with large AOF files. On cloud block storage, I secure IOPS budgets so that fsync plateaus (every second\/always) do not slow down the application. For high availability, I maintain one replica per zone with local persistence; cross-zone backups supplement protection against site failures.<\/p>\n\n<h2>Identifying and Resolving Common Problems<\/h2>\n<ul>\n  <li><strong>Sudden spikes in latency<\/strong>: Check whether a BGSAVE\/AOF rewrite is in progress. If necessary, enable rdb-save-incremental-fsync, reschedule the rewrites, or increase the IOPS.<\/li>\n  <li><strong>Slow Start<\/strong>: AOF too large \u2013 trigger a rewrite, check `aof-use-rdb-preamble`, and fine-tune save intervals and rewrites.<\/li>\n  <li><strong>Stop-the-world on a fork<\/strong>: Disable THP, increase memory headroom, and manage object fragmentation using `activedefrag`.<\/li>\n  <li><strong>Damaged Files<\/strong>: Use redis-check tools to check the system, load the latest clean generation, and resolve the causes (hardware issues, abrupt shutdowns).<\/li>\n  <li><strong>Excessive AOF Growth<\/strong>: Tighten auto-rewrite limits, bundle write-intensive operations (pipelines), and reduce unnecessary key changes.<\/li>\n<\/ul>\n\n<h2>Checklist: Make a Decision in Five Minutes<\/h2>\n\n<p>First, I determine how many seconds of downtime I can tolerate; if the result is zero to one, I go with AOF everysec; if a tolerance of minutes is sufficient, RDB is the right choice. Second, I check startup time requirements; if I need very fast restarts, I prioritize RDB or use the hybrid mode. Third, I check storage performance; if I\/O is weak, I loosen the Fsync settings or invest in better SSDs. Fourth, I define backup and restore tests so that I truly understand the times and behavior. Fifth, I document save intervals, `appendfsync`, and the offsite strategy so that operations and <strong>Audits<\/strong> stay informed at all times.<\/p>\n\n<h2>Briefly summarized<\/h2>\n\n<p>I choose between RDB, AOF, and Hybrid based on RPO, RTO, I\/O performance, and data volume, rather than relying solely on habit. RDB excels with fast startup times and compact files, while AOF offers better durability and readable logs, but requires more <strong>Resources<\/strong>. In many hosting scenarios, I find that using \"hybrid\" with \"appendfsync everysec\" is the most reliable approach. If you use caches, you can use RDB-only and repopulate the source; if you maintain queues, protect yourself with AOF and test restores regularly. This keeps Redis fast, efficient, and reliable, and I run the <strong>Persistence<\/strong> with clear, measurable goals.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find out which Redis persistence option\u2014RDB or AOF\u2014is best suited for your hosting servers and how to best balance performance and data security.<\/p>","protected":false},"author":1,"featured_media":20093,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20100","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"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":"154","_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":"redis persistence","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":"20093","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20100","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=20100"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20100\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20093"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20100"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20100"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20100"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}