Guía de políticas de retención de copias de seguridad para sitios web
Publicado el 6 de noviembre de 2026
Tener una copia de seguridad que no pueda restaurar la versión adecuada de tu sitio web no sirve de mucho a las 2 de la mañana. Una guía práctica de políticas de retención de copias de seguridad empieza con una pregunta sencilla: ¿hasta qué momento anterior podrías necesitar volver si algo falla, se elimina o se ve comprometido?
En el caso de un sitio web de una pequeña empresa, la respuesta pueden ser unas pocas semanas. Para una agencia que gestiona tiendas, bases de datos y correo electrónico de clientes, pueden ser varios meses o más. La política adecuada no consiste en conservar todas las copias de seguridad para siempre. Se trata de conservar suficientes copias limpias y recuperables para resolver problemas reales sin convertir los costes de almacenamiento y la gestión en otro problema.
Qué hace realmente una política de retención de copias de seguridad
Un programa de copias de seguridad indica cuándo se crean las copias. Una política de retención indica durante cuánto tiempo está disponible cada copia antes de eliminarse. Necesitas ambas cosas.
Sin reglas de retención, el almacenamiento se llena poco a poco hasta que las copias de seguridad fallan o aumentan las facturas sin motivo útil. Con reglas demasiado estrictas, puede que la copia de seguridad que necesitas ya haya desaparecido. Esto ocurre más a menudo de lo que la gente espera: puede que no se detecte durante varios días una actualización de un complemento que se haya dañado, que una eliminación accidental se descubra a final de mes o que un problema en la base de datos se haya copiado en todas las copias de seguridad recientes.
Una buena política distingue entre la recuperación a corto plazo y la protección a largo plazo. Las copias de seguridad recientes sirven para incidentes habituales, como una implementación fallida o una actualización de WordPress que haya causado problemas. Los puntos de restauración más antiguos ayudan a resolver problemas de evolución lenta, auditorías, informes estacionales o una brecha que tardó en detectarse.
Empieza por las necesidades de recuperación, no por el espacio de almacenamiento
Es tentador elegir los periodos de retención en función del espacio de almacenamiento disponible. En su lugar, empieza por los riesgos. El almacenamiento es un coste que hay que gestionar, pero perder datos del sitio web, dejar pasar pedidos y sufrir una interrupción prolongada suelen costar más.
Dos objetivos de recuperación facilitan la decisión. El objetivo de punto de recuperación, o RPO, es la cantidad máxima de datos que puedes permitirte perder. Si una tienda en línea solo puede perder una hora de pedidos, necesita copias de seguridad o protección de la base de datos con esa frecuencia, como mínimo. Un sitio web informativo que se actualiza una vez por semana puede tolerar un intervalo mucho mayor.
El objetivo de tiempo de recuperación, o RTO, indica con qué rapidez debe restablecerse el servicio. Una copia de seguridad solo sirve si puedes restaurarla dentro de ese plazo. Las copias de seguridad diarias pueden cumplir tu RPO, pero restaurar un servidor grande desde un almacenamiento remoto podría incumplir tu RTO. La retención y la velocidad de recuperación deben planificarse conjuntamente.
En la mayoría de los sitios web, clasifica los sistemas según su impacto. Un portafolio personal, el sitio web de marketing de una empresa, una tienda WooCommerce con mucho tráfico, una cuenta de alojamiento de un cliente y un servidor de correo no deberían seguir automáticamente las mismas reglas. Cuanto más a menudo cambien los datos y más ingresos o confianza dependan de ellos, más frecuentes y cuidadosamente retenidas deben ser las copias de seguridad.
Guía práctica de políticas de retención de copias de seguridad
Un programa por niveles funciona bien porque proporciona puntos de restauración frecuentes sin conservar indefinidamente todas las copias de seguridad completas. Un punto de partida razonable para un sitio web empresarial típico es conservar las copias de seguridad diarias durante 14 a 30 días, las semanales durante 8 a 12 semanas y las mensuales durante 6 a 12 meses.
Es un punto de partida, no una norma inamovible. Un sitio con actualizaciones diarias de contenido puede necesitar 30 versiones diarias. Un negocio de comercio electrónico puede necesitar copias de seguridad de la base de datos más frecuentes, especialmente durante las temporadas de ventas. Un desarrollador que trabaje en un rediseño importante puede aumentar temporalmente la retención hasta que la nueva versión sea estable. Un sitio estático pequeño puede estar bien protegido con copias semanales y mensuales.
En sistemas con registros financieros, contractuales o sujetos a regulación, puede ser necesario un periodo de retención más largo. Sin embargo, no confundas la retención operativa de copias de seguridad con la conservación formal de registros. Una copia de seguridad está diseñada para la recuperación. No siempre es el formato, el método de acceso o el sistema de control adecuado para archivos legales. Si tu empresa tiene requisitos de cumplimiento normativo, defínelos por separado con la orientación jurídica u operativa adecuada.
Conserva más versiones en torno a los cambios
El riesgo no se distribuye uniformemente a lo largo del calendario. Las actualizaciones importantes de complementos, las migraciones, los cambios en servidores, las nuevas integraciones y las importaciones masivas son los momentos en que es más probable que un sitio web se comporte de forma imprevisible.
Crea una copia de seguridad verificada antes del cambio. Consérvala durante más tiempo de lo habitual hasta que la nueva versión haya funcionado correctamente durante un periodo razonable. Por ejemplo, si migras el sitio de un cliente, conserva la copia de seguridad previa a la migración hasta que el cliente confirme que los formularios, la entrega de correo, los pagos y las páginas clave funcionan como se espera.
Este pequeño hábito evita un error común: eliminar la última copia que se sabe que funciona justo antes de descubrir que el problema empezó varias semanas atrás.
Aplica el principio 3-2-1 sin complicarte la vida
El enfoque 3-2-1 sigue siendo útil porque protege frente a distintos tipos de fallos. Conserva al menos tres copias de los datos importantes, en dos tipos distintos de almacenamiento, y guarda una copia fuera de las instalaciones.
En el caso de un sitio web, esto puede significar los datos activos en el servidor, una copia de seguridad local o gestionada por el proveedor y una copia cifrada en un almacenamiento de copias de seguridad independiente. La clave es la separación. Las copias de seguridad guardadas únicamente en el mismo servidor pueden desaparecer junto con él. Las copias de seguridad de la misma cuenta pueden quedar expuestas si se ven comprometidas las mismas credenciales.
Guardar una copia fuera de las instalaciones no tiene por qué ser complicado. Significa que la copia está protegida frente al fallo del que intentas recuperarte. Elige una ubicación de almacenamiento y un modelo de acceso que tu equipo pueda mantener realmente.
Protege las copias de seguridad contra la eliminación y el ransomware
Una política de copias de seguridad debe especificar quién puede eliminar copias, cambiar la configuración de retención y acceder a los datos de restauración. Estos permisos son importantes porque un atacante que obtenga acceso de administrador puede intentar eliminar los puntos de recuperación antes de cifrar o borrar los datos de producción.
Cuando sea posible, utiliza copias de seguridad inmutables o protegidas contra escritura durante un periodo definido. Esto evita que las copias de seguridad se modifiquen o eliminen demasiado pronto, incluso desde una cuenta con amplios permisos de acceso. Es especialmente útil para sitios críticos, proveedores de alojamiento y agencias responsables de varios entornos de clientes.
El cifrado también es importante. Las copias de seguridad suelen contener bases de datos, archivos de configuración, datos de clientes y, a veces, credenciales. Cifra los datos tanto en tránsito como en reposo, limita el acceso a quienes lo necesiten y guarda las claves de recuperación en un lugar seguro. Una copia de seguridad conservada a la perfección que nadie puede descifrar sigue siendo un plan de recuperación fallido.
Prueba las restauraciones antes de necesitarlas
Los mensajes de éxito de las copias de seguridad no son pruebas de restauración. Un proceso puede completarse correctamente aunque el archivo esté incompleto, el volcado de la base de datos esté dañado o la restauración sea demasiado lenta para tus necesidades.
Prueba una restauración con una frecuencia acorde con la importancia del sistema. Una vez por trimestre puede ser suficiente para un sitio sencillo. Las tiendas con mucho tráfico y los entornos de alojamiento deberían hacer pruebas más a menudo, sobre todo después de cambiar las herramientas de copia de seguridad, las configuraciones del servidor o los destinos de almacenamiento.
Cuando sea posible, restaura en un entorno de pruebas seguro. Comprueba algo más que si se carga la página de inicio. Confirma que la base de datos se conecta, que el contenido reciente está presente, que los usuarios pueden iniciar sesión, que aparecen los archivos multimedia, que se ejecutan las tareas programadas y que las integraciones de pago o de los formularios de contacto funcionan con normalidad. Anota cuánto tardó la recuperación y qué pasos causaron dificultades. Ese registro se convertirá en el manual de procedimientos que agradecerás tener durante un incidente.
Redacta la política para que otra persona pueda seguirla
Una política de retención debería ocupar una o dos páginas, no convertirse en un documento que todo el mundo evita abrir. Especifica qué se incluye en las copias de seguridad, con qué frecuencia se ejecutan, durante cuánto tiempo se conserva cada tipo de copia, dónde se guardan, quién es responsable del proceso y cómo se prueban las restauraciones.
Define también las excepciones. Por ejemplo, una cuenta de cliente con una base de datos de gran volumen puede usar copias de seguridad más frecuentes, mientras que los proyectos archivados pueden pasar a una retención exclusivamente mensual. Documentar las excepciones evita que la configuración se convierta en una colección de decisiones aisladas y enigmáticas.
Los usuarios de FASTPANEL pueden tener este trabajo más a la vista si gestionan sitios web, bases de datos y operaciones de servidores desde un único panel de control claro, en lugar de buscar la configuración en varias herramientas. La visibilidad no sustituye a una política, pero facilita mucho su aplicación.
Tu política de retención debería parecer aburrida cuando todo va bien. Es un cumplido. Cuando se produzca una actualización problemática, una migración fallida o una eliminación accidental, que todo parezca aburrido significa que la copia correcta sigue ahí, se sabe cómo restaurarla y tu equipo tiene una base sólida desde la que empezar.