{"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":"guia-sobre-la-persistencia-de-redis-rdb-aof-y-servidores-de-alojamiento","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/redis-persistence-rdb-aof-hosting-server-anleitung\/","title":{"rendered":"Elegir correctamente la persistencia de Redis: \u00bfRedis RDB o Redis AOF para servidores de alojamiento?"},"content":{"rendered":"<p>Para elegir la opci\u00f3n de persistencia de Redis m\u00e1s adecuada para los servidores de alojamiento, sopeso concretamente los valores de RTO, RPO, los perfiles de E\/S y la importancia de la carga de trabajo. A la hora de elegir entre Redis RDB, Redis AOF o el modo h\u00edbrido, tengo en cuenta la criticidad de los datos, el tiempo de recuperaci\u00f3n y el rendimiento del hardware, para garantizar que el rendimiento y la seguridad de los datos vayan de la mano.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Para que la decisi\u00f3n se tome con fundamento, voy a resumir brevemente los aspectos m\u00e1s importantes y a ponderar su <strong>Relevancia<\/strong> para servidores de alojamiento.<\/p>\n<ul>\n  <li><strong>P\u00e9rdida de datos<\/strong>: RDB se arriesga a perder minutos, mientras que AOF, con everysec, pierde aproximadamente un segundo.<\/li>\n  <li><strong>Etapa inicial<\/strong>: RDB se inicia m\u00e1s r\u00e1pido, mientras que AOF depende del tama\u00f1o del registro.<\/li>\n  <li><strong>Perfil de E\/S<\/strong>: RDB genera picos, mientras que AOF escribe de forma continua.<\/li>\n  <li><strong>Tama\u00f1o del archivo<\/strong>: RDB se mantiene compacto, mientras que AOF crece y reescribe los datos.<\/li>\n  <li><strong>H\u00edbrido<\/strong>: Kombi ofrece seguridad y reinicios flexibles.<\/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>Establecer de forma espec\u00edfica los valores de RTO y RPO<\/h2>\n\n<p>Tomo cada decisi\u00f3n partiendo de unos objetivos claros para <strong>RTO<\/strong> y RPO, ya que determinan directamente el nivel de seguridad que aplico a Redis. Si acepto como m\u00e1ximo un segundo de p\u00e9rdida, AOF con \u00abeverysec\u00bb es adecuado, mientras que RDB, con una instant\u00e1nea de 5 minutos, puede asumir un riesgo considerablemente mayor. Si necesito tiempos de reinicio muy cortos, utilizo RDB como punto de anclaje r\u00e1pido y mantengo AOF como escudo protector. Si escribo en discos lentos, reduzco el Fsync de AOF u optimizo el almacenamiento para evitar picos de latencia. De este modo, a partir de objetivos medibles, deduzco una configuraci\u00f3n adecuada <strong>Estrategia<\/strong> y vinculo la tecnolog\u00eda con las especificaciones operativas.<\/p>\n\n<h2>As\u00ed funciona Redis RDB en el d\u00eda a d\u00eda del alojamiento web<\/h2>\n\n<p>RDB crea instant\u00e1neas peri\u00f3dicas y almacena una versi\u00f3n compacta <strong>.rdb<\/strong>Un archivo que se carga muy r\u00e1pido. Establezco los intervalos de guardado en funci\u00f3n del valor de los datos y la tasa de cambio, para que el intervalo entre instant\u00e1neas sea predecible. Durante la bifurcaci\u00f3n, presto atenci\u00f3n al margen de RAM disponible, para que el \u00abcopy-on-write\u00bb no provoque una sobrecarga de memoria. Si el objetivo es el almacenamiento en cach\u00e9 o m\u00e9tricas poco cr\u00edticas, utilizo \u00abRDB-only\u00bb con intervalos cortos y dispongo de copias de seguridad externas. De este modo, garantizo reinicios r\u00e1pidos, minimizo las operaciones de E\/S en funcionamiento normal y, con los archivos RDB, <strong>apto para copias de seguridad<\/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>Configurar correctamente AOF: \u00abappendfsync everysec\u00bb como buena pr\u00e1ctica est\u00e1ndar<\/h2>\n\n<p>En el registro AOF, escribo cada vez que se realiza una escritura <strong>Operaci\u00f3n<\/strong> y controlo la vida \u00fatil mediante \u00abappendfsync\u00bb. Con \u00abeverysec\u00bb, en caso de fallo del sistema, suelo perder como m\u00e1ximo un segundo, sin ralentizar demasiado el rendimiento. En el caso de datos muy delicados, \u00abalways\u00bb puede resultar \u00fatil, pero en ese caso calculo la p\u00e9rdida de rendimiento y la pruebo en condiciones reales. Programo reescrituras peri\u00f3dicas del AOF para que el archivo no crezca sin control y las restauraciones sigan siendo r\u00e1pidas. Para colas, configuraciones y transacciones, el AOF ofrece as\u00ed una soluci\u00f3n fiable <strong>Protecci\u00f3n<\/strong>.<\/p>\n\n<h2>Comparaci\u00f3n directa y repercusiones en los servidores de alojamiento<\/h2>\n\n<p>Antes de tomar una decisi\u00f3n, recopilo de forma estructurada las diferencias fundamentales para poder asignar las cargas de trabajo con precisi\u00f3n y <strong>Recursos<\/strong> planificar. La siguiente tabla muestra, de forma resumida, las caracter\u00edsticas, el comportamiento y los efectos t\u00edpicos en el entorno de alojamiento. Utilizo esta comparaci\u00f3n como referencia r\u00e1pida cuando defino perfiles para cach\u00e9s, sesiones y colas. Especialmente en servidores mixtos con muchos proyectos, esta visi\u00f3n me ayuda a detectar picos de E\/S y a atenuarlos de forma adecuada. De este modo, la tecnolog\u00eda se adapta a la aplicaci\u00f3n y sigue funcionando en el d\u00eda a d\u00eda. <strong>previsible<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterio<\/th>\n      <th>RDB<\/th>\n      <th>AOF<\/th>\n      <th>Repercusi\u00f3n en los servidores de alojamiento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>P\u00e9rdida de datos<\/td>\n      <td>Todo desde la \u00faltima instant\u00e1nea<\/td>\n      <td>Depende de fsync; cada segundo, aproximadamente 1 segundo<\/td>\n      <td>Seleccionar las pol\u00edticas siguiendo estrictamente el RPO<\/td>\n    <\/tr>\n    <tr>\n      <td>Etapa inicial<\/td>\n      <td>Muy r\u00e1pido (un archivo)<\/td>\n      <td>M\u00e1s despacio, se est\u00e1 reproduciendo el registro<\/td>\n      <td>Calcular de forma realista los intervalos de mantenimiento<\/td>\n    <\/tr>\n    <tr>\n      <td>Tama\u00f1o del archivo<\/td>\n      <td>Compacto<\/td>\n      <td>M\u00e1s grande; es necesario reescribirlo<\/td>\n      <td>Prever espacio de almacenamiento y reescrituras<\/td>\n    <\/tr>\n    <tr>\n      <td>Perfil de E\/S<\/td>\n      <td>Picos en la instant\u00e1nea<\/td>\n      <td>De forma continua, dependiendo de fsync<\/td>\n      <td>Ten en cuenta las IOPS y las latencias de los SSD<\/td>\n    <\/tr>\n    <tr>\n      <td>Transparencia<\/td>\n      <td>Binario, ilegible<\/td>\n      <td>Comandos legibles<\/td>\n      <td>Facilita el an\u00e1lisis de errores y las auditor\u00edas<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Modo h\u00edbrido: combinar seguridad con reinicios r\u00e1pidos<\/h2>\n\n<p>Combino AOF y RDB cuando tengo un m\u00ednimo de <strong>Laguna en los datos<\/strong> y necesito buenos tiempos de arranque. AOF captura casi todos los cambios, mientras que RDB sirve como punto de anclaje ligero para copias de seguridad y clones r\u00e1pidos. Con Redis 7, las mejoras h\u00edbridas aportan tiempos de restauraci\u00f3n m\u00e1s cortos y, en algunos casos, registros m\u00e1s peque\u00f1os. Pruebo el reinicio con ambos artefactos para saber cu\u00e1nto tiempo lleva una recuperaci\u00f3n en caso de emergencia. De este modo, aprovecho las ventajas de ambos m\u00e9todos y mantengo los riesgos bajo control. <strong>peque\u00f1o<\/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>Usos habituales en servidores de alojamiento web<\/h2>\n\n<p>Para las sesiones HTTP y los estados de los usuarios, prefiero el modo h\u00edbrido con AOF cada segundo, para que solo se guarden datos muy breves <strong>Lagunas<\/strong> pueden suponer un riesgo. Los cach\u00e9s puros con datos renovables suelo ejecutarlos en modo \u00absolo RDB\u00bb o desactivo la persistencia si la fuente se rellena r\u00e1pidamente. Guardo los trabajos, las colas y los eventos con AOF cada segundo y complemento con instant\u00e1neas peri\u00f3dicas para las copias de seguridad externas. Quien desee comprender las sesiones con m\u00e1s detalle, encontrar\u00e1 informaci\u00f3n adicional en <a href=\"https:\/\/webhosting.de\/es\/gestion-de-sesiones-alojamiento-web-almacenamiento-de-bases-de-datos-redis\/\">Sesiones con Redis<\/a>. De este modo, cada aplicaci\u00f3n recibe la <strong>Durabilidad<\/strong> sin costes innecesarios de E\/S.<\/p>\n\n<h2>Buenas pr\u00e1cticas para el funcionamiento y el mantenimiento<\/h2>\n\n<p>Tengo previsto realizar copias de seguridad externas de los archivos RDB y AOF y compruebo peri\u00f3dicamente la restauraci\u00f3n en el entorno de prueba, para que la <strong>RTO<\/strong> se mantenga real. Controlo las reescrituras de AOF de tal forma que el tama\u00f1o del registro y el tiempo de restauraci\u00f3n se mantengan dentro de unos l\u00edmites razonables. El sistema de monitorizaci\u00f3n supervisa las latencias de E\/S, el tama\u00f1o del archivo AOF y la duraci\u00f3n de la reescritura, para que las tendencias no me pillen por sorpresa. La documentaci\u00f3n registra de forma clara los intervalos de guardado y la pol\u00edtica de \u00abappendfsync\u00bb, especialmente en servidores multitenant. Si se produce una ralentizaci\u00f3n inesperada, compruebo la E\/S, la pol\u00edtica de Fsync y el comportamiento de los forks; aporto sugerencias a trav\u00e9s de <a href=\"https:\/\/webhosting.de\/es\/por-que-redis-es-mas-lento-de-lo-esperado-errores-tipicos-de-configuracion-cacheopt\/\">\u00bfRedis va lento? Causas<\/a>, que compruebo en la pr\u00e1ctica antes de adoptarlas. As\u00ed es como funciona el servicio en el d\u00eda a d\u00eda <strong>concluyente<\/strong> manejable.<\/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>Almacenamiento, IOPS y configuraci\u00f3n del alojamiento<\/h2>\n\n<p>AOF necesita una r\u00e1pida <strong>Unidades SSD<\/strong> con IOPS estables; de lo contrario, aumentan las latencias y la aplicaci\u00f3n nota retrasos. Cuando escribo en un almacenamiento en red, eval\u00fao el rendimiento y los picos de latencia, ya que \u00abappendfsync\u00bb afecta directamente a estos valores. Separo el almacenamiento de Redis cuando otros servicios provocan picos, o reservo recursos propios para los registros AOF. En el caso de hosts compartidos, compruebo si tiene sentido utilizar instancias dedicadas; para ello, me sirvo de <a href=\"https:\/\/webhosting.de\/es\/redis-compartido-frente-a-dedicado-rendimiento-seguridad-cacheboost\/\">Compartido vs. dedicado<\/a>. Solo con un perfil de E\/S limpio, Redis puede alcanzar los bajos <strong>Latencias<\/strong> que yo espero.<\/p>\n\n<h2>Configuraciones recomendadas para situaciones habituales<\/h2>\n\n<p>Para aplicaciones web productivas con cach\u00e9 y sesiones, elijo RDB + AOF y configuro \u00abappendfsync\u00bb en \u00abeverysec\u00bb, para que el rendimiento se mantenga alto y la p\u00e9rdida de datos sea m\u00ednima. En los niveles dedicados exclusivamente a la cach\u00e9, a menudo basta con RDB-only, en algunos casos incluso sin persistencia, ya que la fuente de datos se rellena r\u00e1pidamente; documento este riesgo con claridad. Las colas cr\u00edticas para el negocio las ejecuto con AOF everysec o, en casos excepcionales, always, cuando no se puede permitir ninguna p\u00e9rdida; Las instant\u00e1neas de RDB complementan las copias de seguridad externas y aceleran los procesos de clonaci\u00f3n. Antes de la puesta en marcha, compruebo los fallos, la restauraci\u00f3n, el tiempo de arranque y la consistencia de los datos, para evitar sorpresas. Sobre esta base, calculo el espacio de almacenamiento, planifico las reescrituras y compruebo si la <strong>Hardware<\/strong> que soporte la carga de forma segura.<\/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>Pensar en la replicaci\u00f3n, la conmutaci\u00f3n por error y la persistencia de forma conjunta<\/h2>\n<p>Separo claramente las funciones: el servidor primario ofrece bajas latencias, mientras que una r\u00e9plica asume la carga adicional de persistencia. En concreto: el servidor primario con RDB + AOF cada segundo; la r\u00e9plica con una pol\u00edtica id\u00e9ntica o m\u00e1s estricta. En caso de conmutaci\u00f3n por error (Sentinel\/cl\u00faster), la r\u00e9plica toma el relevo con artefactos completos y no pierdo m\u00e1s de lo que permite mi RPO. Si quiero amortiguar los picos en el servidor primario, activo el AOF all\u00ed de forma moderada o incluso lo desactivo en el servidor primario y realizo copias de seguridad m\u00e1s rigurosas en la r\u00e9plica, sabiendo que, en caso de fallo del servidor primario, se puede perder m\u00e1s informaci\u00f3n hasta recibir el \u00faltimo ACK de la r\u00e9plica. Documento esta decisi\u00f3n de forma expl\u00edcita. Lo importante es que las replicaciones sean estables y que las copias de seguridad se realicen a partir de un sistema replicado, <strong>consistentes<\/strong> Se puede recurrir ante el tribunal correspondiente.<\/p>\n\n<h2>Detalles de configuraci\u00f3n que a menudo se pasan por alto<\/h2>\n<ul>\n  <li><strong>aof-use-rdb-pre\u00e1mbulo<\/strong>: Crea una base de datos RDB en el AOF, acelera los reinicios y reduce el tama\u00f1o de los registros; para m\u00ed, es la configuraci\u00f3n predeterminada en el modo h\u00edbrido.<\/li>\n  <li><strong>aof-rewrite-incremental-fsync<\/strong>: Suaviza las operaciones de E\/S durante la reescritura; evita las pausas prolongadas de Fsync.<\/li>\n  <li><strong>auto-aof-rewrite-percentage \/ -min-size<\/strong>: Elijo umbrales pr\u00e1cticos (por ejemplo, 100% y 64-256 MB), en funci\u00f3n del volumen de cambios.<\/li>\n  <li><strong>no-appendfsync-on-rewrite<\/strong>: En sistemas de almacenamiento poco potentes, a veces lo configuro en \u00abyes\u00bb, aunque acepto que haya una ventana de p\u00e9rdida algo mayor durante la reescritura.<\/li>\n  <li><strong>rdb-save-incremental-fsync<\/strong>: Activado para distribuir la E\/S de instant\u00e1neas.<\/li>\n  <li><strong>rdbcompression \/ rdbchecksum<\/strong>: La compresi\u00f3n ahorra espacio y la suma de comprobaci\u00f3n aumenta la seguridad; estoy dispuesto a aceptar la ligera carga que supone para la CPU.<\/li>\n  <li><strong>detener-las-escrituras-en-caso-de-error-en-bgsave<\/strong>: Lo dejo en \u00abs\u00ed\u00bb, para que se detecten los errores y no se siga escribiendo sin darse cuenta.<\/li>\n  <li><strong>aof-load-truncated<\/strong>: En \u00abyes\u00bb, Redis tambi\u00e9n se inicia con el registro ligeramente recortado y descarta los datos da\u00f1ados de \u00abtail\u00bb; esto es bueno para la disponibilidad, pero tengo preparadas pruebas de restauraci\u00f3n.<\/li>\n  <li><strong>dir, nombre_archivo_db, nombre_archivo_a\u00f1adir<\/strong>: Establezco rutas de forma espec\u00edfica en soportes de datos r\u00e1pidos y fiables, y configuro permisos seguros (umask\/propietario) para garantizar el cumplimiento normativo.<\/li>\n  <li><strong>Opciones de lazyfree<\/strong>: lazyfree-lazy-eviction\/expire ayudan a reducir los tiempos de bloqueo y a aliviar la carga de Fork-CoW, sobre todo en casos de grandes limpiezas de claves.<\/li>\n<\/ul>\n\n<h2>Optimizaci\u00f3n del sistema operativo y del sistema de archivos para garantizar la estabilidad de las operaciones fsync<\/h2>\n<p>Voy a desactivar las \u00abTransparent Huge Pages\u00bb (<strong>THP = nunca<\/strong>), pon <strong>vm.overcommit_memory=1<\/strong> y aseg\u00farate de que haya suficientes reservas libres de Hugepage, ya que esto reduce notablemente las latencias de las bifurcaciones. A nivel del sistema de archivos, evito ajustes arriesgados; me ci\u00f1o a los valores predeterminados seguros (por ejemplo, ext4 o XFS con barreras activadas) y utilizo <strong>noatime<\/strong>, para evitar escrituras innecesarias de metadatos. Ajusto el programador y la profundidad de la cola al SSD, para que los picos de Fsync se procesen correctamente. Presto especial atenci\u00f3n a la virtualizaci\u00f3n y al almacenamiento en red: compruebo que Fsync llegue realmente hasta el disco y que ninguna capa de cach\u00e9 provoque sorpresas.<\/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>Calcular con precisi\u00f3n el margen de memoria y de bifurcaci\u00f3n<\/h2>\n<p>Durante la bifurcaci\u00f3n para BGSAVE\/Rewrite, el proceso hijo necesita memoria para Copy-on-Write. Dejo libre: la memoria RAM de la instancia m\u00e1s un margen de 10\u201330%, dependiendo de la tasa de cambios y del tama\u00f1o de los objetos. Si el conjunto de datos crece considerablemente durante la bifurcaci\u00f3n, aumenta la necesidad de CoW; por eso, planifico ventanas de mantenimiento para reescrituras de gran envergadura o reduzco brevemente la carga de escritura. En configuraciones multitenant, distribuyo las instancias entre los hosts para que una bifurcaci\u00f3n no sature todos los servicios al mismo tiempo.<\/p>\n\n<h2>Estrategia de copias de seguridad y pruebas de recuperaci\u00f3n en curso<\/h2>\n<p>Aseguro <strong>ambos<\/strong> Tipos de artefactos: RDB actuales y partes AOF coherentes. Para las copias de seguridad en caliente, inicio un proceso antes de copiar <em>BGREWRITEAOF<\/em> o utilizo instant\u00e1neas del sistema de archivos (LVM\/ZFS) para garantizar que los archivos del paquete est\u00e9n coherentes. Compruebo las copias de seguridad con redis-check-rdb\/redis-check-aof y las cargo peri\u00f3dicamente en el entorno de prueba para medir los tiempos reales de restauraci\u00f3n. La rotaci\u00f3n es fundamental: mantengo varias generaciones, cifro las copias externas y documento el plan de recuperaci\u00f3n, incluyendo las responsabilidades y el tiempo m\u00e1ximo tolerado <strong>Tiempo de inactividad<\/strong>.<\/p>\n\n<h2>Dimensionamiento: planificar las necesidades de espacio y de E\/S<\/h2>\n<p>Hago un c\u00e1lculo aproximado: el tama\u00f1o del conjunto de datos en la RAM m\u00e1s 20\u201350% para el archivo RDB (dependiendo de la compresi\u00f3n), as\u00ed como el crecimiento del AOF proporcional a los comandos de escritura. Ejemplo: 20 000 escrituras\/s \u00d7 120 bytes\/comando dan como resultado 2,4 MB\/s de registro sin procesar; con las reescrituras, esta cifra se reduce, pero el almacenamiento debe soportar los picos de carga. Configur\u00e9 los umbrales de reescritura autom\u00e1tica de tal forma que las reescrituras se produzcan en momentos de carga moderada y que la base AOF no se reconstruya con una frecuencia innecesaria. Como reserva, preveo un espacio en disco de al menos 2-3 veces el tama\u00f1o del conjunto de datos, para que las instant\u00e1neas y reescrituras paralelas no se pongan en marcha y se queden sin espacio de inmediato.<\/p>\n\n<h2>Contenedores y vol\u00famenes en la nube en el contexto del alojamiento web<\/h2>\n<p>En los contenedores, separo estrictamente los datos del ciclo de vida del pod: vol\u00famenes persistentes con IOPS garantizadas, sin sistemas de archivos superpuestos (Overlay FS) para AOF. Las comprobaciones de disponibilidad tienen en cuenta los tiempos de arranque m\u00e1s largos cuando el AOF es grande. En el almacenamiento en bloque en la nube, aseguro los presupuestos de IOPS de tal forma que las mesetas de Fsync (cada segundo\/siempre) no ralenticen la aplicaci\u00f3n. Para garantizar una alta disponibilidad, mantengo una r\u00e9plica por zona con persistencia local; las copias de seguridad entre zonas complementan la protecci\u00f3n frente a fallos en las ubicaciones.<\/p>\n\n<h2>Detectar y solucionar aver\u00edas habituales<\/h2>\n<ul>\n  <li><strong>Picos repentinos de latencia<\/strong>: Comprueba si se est\u00e1 ejecutando una reescritura BGSAVE\/AOF. Si es necesario, activa rdb-save-incremental-fsync, pospone las reescrituras o ampl\u00eda las IOPS.<\/li>\n  <li><strong>Un comienzo lento<\/strong>: AOF demasiado grande: activar la reescritura, comprobar \u00abaof-use-rdb-preamble\u00bb y ajustar con mayor precisi\u00f3n los intervalos de guardado y las reescrituras.<\/li>\n  <li><strong>\u00abStop-the-world\u00bb en la bifurcaci\u00f3n<\/strong>: Desactivar THP, aumentar el margen de memoria y controlar la fragmentaci\u00f3n de objetos con \u00abactivedefrag\u00bb.<\/li>\n  <li><strong>Archivos da\u00f1ados<\/strong>: Comprobar con las herramientas de redis-check, cargar la \u00faltima generaci\u00f3n v\u00e1lida y solucionar las causas (hardware, apagado brusco).<\/li>\n  <li><strong>Crecimiento excesivo de AOF<\/strong>: Optimizar los l\u00edmites de la reescritura autom\u00e1tica, agrupar las operaciones que implican mucha escritura (pipelines) y reducir los cambios innecesarios en las claves.<\/li>\n<\/ul>\n\n<h2>Lista de comprobaci\u00f3n: una decisi\u00f3n en cinco minutos<\/h2>\n\n<p>En primer lugar, determino cu\u00e1ntos segundos de p\u00e9rdida puedo soportar; si el resultado es de cero a uno, me decanto por AOF everysec; si la tolerancia es de minutos, me decanto por RDB. En segundo lugar, compruebo los requisitos de tiempo de arranque; si necesito reinicios muy r\u00e1pidos, doy mayor prioridad a RDB o utilizo la opci\u00f3n h\u00edbrida. En tercer lugar, compruebo el rendimiento del almacenamiento; si el I\/O es d\u00e9bil, relajo la configuraci\u00f3n de Fsync o invierto en SSD de mayor calidad. En cuarto lugar, defino pruebas de copia de seguridad y restauraci\u00f3n para conocer realmente los tiempos y el comportamiento. En quinto lugar, documento los intervalos de guardado, el \u00abappendfsync\u00bb y la estrategia de copias de seguridad externas, para que el equipo de operaciones y <strong>Auditor\u00edas<\/strong> est\u00e9n informados en todo momento.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Elijo entre RDB, AOF e h\u00edbrido en funci\u00f3n del RPO, el RTO, el rendimiento de E\/S y el valor de los datos, en lugar de basarme \u00fanicamente en la costumbre. RDB destaca por sus arranques r\u00e1pidos y sus archivos compactos, mientras que AOF ofrece una mayor durabilidad y registros legibles, aunque requiere m\u00e1s <strong>Recursos<\/strong>. En muchos entornos de alojamiento, lo que me da mejores resultados en cuanto a fiabilidad es utilizar el modo h\u00edbrido con \u00abappendfsync everysec\u00bb. Quien utilice cach\u00e9s puede usar \u00abRDB-only\u00bb y rellenar la fuente; quien mantenga colas, se protege con AOF y comprueba las restauraciones peri\u00f3dicamente. As\u00ed, Redis sigue siendo r\u00e1pido, eficiente y, al mismo tiempo, fiable, y yo gestiono el <strong>Persistencia<\/strong> con objetivos claros y verificables.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre qu\u00e9 opci\u00f3n de persistencia de Redis \u2014RDB o AOF\u2014 es la m\u00e1s adecuada para tus servidores de alojamiento y c\u00f3mo combinar de forma \u00f3ptima el rendimiento y la seguridad de los datos.<\/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":"138","_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\/es\/wp-json\/wp\/v2\/posts\/20100","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20100"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20100\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20093"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20100"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20100"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20100"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}