Una política de retención de copias de seguridad para sitios web que funciona
Publicado el 14 de agosto de 2026
Una política de retención de copias de seguridad para sitios web debería ofrecerle varios puntos de restauración recientes, algunas opciones de recuperación más antiguas y al menos una copia fuera del servidor que ejecuta el sitio. Si una actualización de plugin rompe el checkout a las 10:15 a. m., necesita una versión limpia de las 10:00 a. m., no una copia de seguridad del martes pasado y una expresión esperanzada.
El calendario adecuado depende de la frecuencia con que cambian sus datos, de cuánto cuesta el tiempo de inactividad y de la rapidez con que su equipo puede identificar cuándo comenzó un problema. Un sitio corporativo estático y una tienda WooCommerce con mucho movimiento no deberían protegerse de la misma manera. El servicio puede estar en línea, pero si faltan los pedidos de ayer, los envíos de formularios o los cambios de los clientes, la calma todavía no se ha restablecido por completo.
Qué debe cubrir una política de retención de copias de seguridad de un sitio web
La retención no es simplemente la cantidad de copias de seguridad que conserva. Es el conjunto de reglas que decide qué copias de seguridad siguen disponibles, dónde se almacenan, cuánto tiempo permanecen allí y cuándo se eliminan.
Una política útil tiene en cuenta tres necesidades de recuperación distintas. En primer lugar, necesita una recuperación operativa rápida para errores recientes: un despliegue fallido, archivos eliminados, una actualización fallida o un cambio accidental de configuración. En segundo lugar, necesita recuperación histórica cuando un problema ha permanecido silenciosamente durante semanas, como un acceso de administrador comprometido o código infectado. En tercer lugar, puede necesitar registros conservados por razones empresariales, contractuales o regulatorias.
Esos objetivos pueden entrar en conflicto. Conservar cada copia de seguridad para siempre genera costes de almacenamiento, trabajos de copia de seguridad más lentos y una lista de restauración confusa. Conservar demasiado poco ahorra espacio justo hasta que la única copia de seguridad que necesita ya ha caducado. La respuesta sensata es una retención por niveles, no una larga fila de copias de seguridad diarias idénticas.
Empiece por los objetivos de recuperación, no por una cifra de almacenamiento
Antes de establecer los periodos de retención, defina dos objetivos prácticos: el objetivo de punto de recuperación y el objetivo de tiempo de recuperación.
Su objetivo de punto de recuperación, a menudo llamado RPO, responde a cuánto volumen de datos recientes puede permitirse perder. Una tienda de comercio electrónico que procesa pedidos durante todo el día puede necesitar copias de seguridad horarias de la base de datos o copias de seguridad con reconocimiento de transacciones. Un sitio de presentación actualizado dos veces al mes puede aceptar una copia de seguridad diaria, siempre que los datos críticos del formulario de contacto se gestionen en otro lugar.
Su objetivo de tiempo de recuperación, o RTO, responde a la rapidez con que debe restaurarse el sitio. Una copia de seguridad reciente almacenada localmente o en un almacenamiento de copias de seguridad cercano normalmente puede restaurarse más rápido que un archivo en frío. Pero las copias locales por sí solas no son suficientes. Un fallo del servidor, un incidente de ransomware, una operación de disco equivocada o una vulneración a nivel de cuenta pueden afectar conjuntamente al sitio y a sus copias de seguridad locales.
Para la mayoría de los sitios web empresariales, defina estos objetivos en lenguaje sencillo. Por ejemplo: “No podemos perder más de una hora de pedidos, y la tienda en línea debe restaurarse en un plazo de dos horas.” Esto es mucho más útil que decir “hacemos copias de seguridad diarias” y descubrir más tarde que diario significa una vez cada 24 horas.
Compruebe qué cambia realmente
Los archivos del sitio web y los datos de la base de datos no cambian al mismo ritmo. Los archivos principales de WordPress pueden permanecer intactos durante meses, mientras que la base de datos recibe pedidos, comentarios, reservas, cambios de membresía y entradas de formularios durante todo el día.
Una copia de seguridad completa debería incluir archivos de la aplicación, bases de datos, archivos de configuración, medios subidos, configuración relacionada con SSL cuando corresponda, definiciones de tareas programadas y cualquier dato personalizado de la aplicación almacenado fuera de la raíz web. Si una copia de seguridad de la base de datos se realiza correctamente pero el directorio de subidas queda excluido, el sitio restaurado puede funcionar mientras las imágenes de productos o los documentos de clientes desaparecen silenciosamente.
En una aplicación más grande, documente también las dependencias. El almacenamiento de objetos, los servicios de correo, los sistemas de pago, las bases de datos externas y los registros DNS pueden no formar parte de una copia de seguridad del servidor. Aun así, siguen formando parte del plan de recuperación.
Un calendario práctico de retención para la mayoría de los sitios web
Un punto de partida habitual es conservar las copias de seguridad frecuentes durante un periodo corto y las menos frecuentes durante más tiempo. Esto ofrece opciones de restauración útiles sin hacer que el uso de almacenamiento crezca como un garaje abandonado.
Para un sitio típico de pequeña empresa, un sitio gestionado por una agencia o un sitio de marketing, conserve copias de seguridad diarias durante 14 a 30 días, copias semanales durante 8 a 12 semanas y copias mensuales durante 6 a 12 meses. Realice una copia de seguridad adicional antes de cambios importantes, como una actualización del CMS, el lanzamiento de un rediseño, una migración, la sustitución de un plugin o trabajos de configuración del servidor.
Para tiendas, paneles SaaS, sitios de membresía, plataformas de reservas y otros servicios con un uso intensivo de base de datos, añada una protección más frecuente de la base de datos. Las copias de seguridad horarias de la base de datos conservadas durante 24 a 72 horas pueden ser adecuadas, seguidas de copias de seguridad diarias durante 30 días, copias semanales durante 12 semanas y copias mensuales durante 12 meses. El intervalo exacto depende del volumen de transacciones y de si la aplicación puede realizar copias de seguridad de los datos activos de forma consistente.
Las agencias deberían considerar políticas específicas para cada cliente en lugar de aplicar un único calendario a todas las cuentas. El sitio de menú de un restaurante no necesita la misma retención que un portal de cliente que gestiona documentos subidos. Agrupe los sitios por riesgo e impacto empresarial, y luego haga visible la política en el acuerdo con el cliente o en el alcance del servicio.
Mantenga separados los puntos de restauración previos a cambios
Los calendarios automatizados no sustituyen a las copias de seguridad deliberadas antes de trabajos arriesgados. Cree un punto de restauración etiquetado antes de actualizaciones, migraciones, mantenimiento de base de datos, cambios de plantilla o ajustes a nivel de servidor.
Conserve las copias de seguridad previas a cambios durante al menos siete a catorce días después de que el trabajo haya finalizado. Algunos problemas solo aparecen después de un ciclo de facturación, un trabajo en segundo plano o la ejecución de una integración. Una vez que se confirme la estabilidad del cambio, la retención normal puede volver a aplicarse.
Siga el principio 3-2-1, con operaciones realistas
El modelo clásico 3-2-1 sigue siendo práctico: conserve tres copias de los datos, en dos tipos de almacenamiento diferentes, con una copia fuera de las instalaciones. Para las operaciones de sitios web, esto suele significar los datos de producción, una copia de seguridad en el entorno de hosting y una copia cifrada en un almacenamiento externo independiente.
La palabra clave es independiente. Una copia de seguridad almacenada en el mismo servidor virtual es conveniente, pero no protege frente a un fallo a nivel de servidor. Una copia de seguridad almacenada en la misma cuenta de hosting también puede quedar expuesta si un atacante obtiene las credenciales de la cuenta o si se ejecuta una acción de eliminación amplia.
Las copias externas deberían estar cifradas en tránsito y en reposo. El acceso debería usar credenciales separadas cuando sea posible, idealmente con autenticación multifactor y permisos limitados. Los permisos de eliminación de copias de seguridad merecen especial atención. Si un ransomware o un administrador comprometido puede borrar los datos de producción y todos los puntos de recuperación en una sola sesión, el calendario de retención se verá excelente sobre el papel y desamparado en la práctica.
En kodu.cloud, los sistemas de copia de seguridad y monitorización gestionados pueden reducir el trabajo rutinario, pero la responsabilidad sobre los requisitos de recuperación debería seguir estando clara. Su proveedor puede mantener el sistema; su empresa debería decidir cuánta pérdida de datos y cuánto tiempo de inactividad puede aceptar.
Haga que la retención tenga en cuenta los incidentes de seguridad
Una ventana de retención corta puede ser peligrosa cuando el malware se descubre tarde. Un sitio podría estar comprometido durante varias semanas antes de que se hagan visibles redirecciones sospechosas, actividad de spam o cuentas de administrador no autorizadas. Si cada copia de seguridad se sobrescribe después de siete días, puede que solo conserve copias infectadas.
Por eso importan los puntos de restauración semanales y mensuales. Para entornos de mayor riesgo, considere copias de seguridad inmutables o protegidas contra escritura durante un periodo definido. La inmutabilidad no hace que una copia de seguridad sea mágicamente correcta, pero puede impedir que un atacante la modifique o la elimine tras una vulneración.
Mantenga registros del éxito, fallo, eliminación y actividad de restauración de las copias de seguridad. Las alertas deberían llegar a una persona que pueda actuar, no a una bandeja de entrada que se ha convertido en un pequeño museo digital. La monitorización también debería comprobar la capacidad de almacenamiento, la duración de las copias de seguridad y los cambios inusuales en el tamaño de las copias de seguridad. Una copia de seguridad repentinamente diminuta puede indicar una base de datos excluida o una recopilación de archivos fallida; una repentinamente enorme puede indicar registros, archivos de caché o datos no deseados entrando en el conjunto de copia de seguridad.
Pruebe las restauraciones antes de necesitar una
Una copia de seguridad solo es una herramienta de recuperación después de haberse restaurado correctamente. El estado del trabajo de copia de seguridad confirma que los datos se copiaron. No demuestra que el archivo esté completo, sea legible, compatible con el entorno actual o utilizable bajo presión de tiempo.
Pruebe una restauración al menos trimestralmente para un sitio web empresarial estándar y con más frecuencia para aplicaciones críticas para los ingresos. Restaure en un entorno de staging o en una ubicación aislada donde no pueda sobrescribir producción. Confirme que la aplicación arranca, que la base de datos conecta, que los archivos multimedia cargan, que los formularios funcionan, que las tareas programadas están presentes y que las acciones críticas del usuario se comportan con normalidad.
Registre cuánto tiempo tardó la restauración y cualquier paso manual necesario. Si la recuperación depende de que un desarrollador recuerde una contraseña de base de datos, una secuencia DNS y un comando de shell de hace cinco años, eso no es un plan. Es un artefacto del folclore.
Documente las excepciones y revise la política
Su política de retención debería caber en una página y responder a unas pocas preguntas directas: qué se respalda, con qué frecuencia, dónde se almacenan las copias, cuánto tiempo se conserva cada copia, quién puede solicitar una restauración y cómo se documentan las pruebas de restauración. Mencione también los sistemas que no están incluidos, para que nadie suponga que una copia de seguridad cubre un servicio de terceros al que no puede acceder.
Revise la política después de un cambio importante en el sitio, un nuevo requisito de cumplimiento, crecimiento del tráfico o un incidente de recuperación. Puede que se necesiten copias de seguridad más frecuentes a medida que crece una tienda en línea. Por otro lado, almacenar copias de seguridad diarias durante varios años para un sitio con pocos cambios puede suponer un coste sin una protección útil.
Establezca la política de retención en torno al momento en que más la necesitará: un despliegue apresurado un viernes, una actualización maliciosa de plugin o un problema de disco a la hora equivocada. Puntos de restauración claros, una copia independiente y un proceso probado le dan a su equipo algo mejor que confianza. Le dan un siguiente paso viable.
Andres Saar Ingeniero de Atención al Cliente