Copia de seguridad y plan de recuperación ante desastres web
¿Qué pasa si su sitio es hackeado, falla el servidor o se borra una página por error? Un plan claro para la frecuencia de copias y la prueba de restauración.
Equipo de rabbitclipPublicación: 6 min. de lectura
En breve
Un plan de copia de seguridad debe responder tres preguntas: con qué frecuencia se hace la copia, se guarda separada del servidor en producción, y se ha probado realmente una restauración. Si falta una de las tres, la copia con la que cuenta es solo una suposición, hasta el momento exacto en que la necesita.
La recuperación ante desastres suena a algo propio de grandes empresas, pero es igual de real para un negocio pequeño. Si el sistema de reservas de una cadena de spas se rompe durante una actualización, o la base de datos de una tienda online se borra por error, el tiempo de recuperación se convierte directamente en ingresos perdidos.
Qué debe cubrir realmente una copia de seguridad
La copia de seguridad de un sitio tiene dos partes: los archivos, tema, plugins, imágenes subidas, y la base de datos, productos, pedidos, cuentas de usuario, entradas de blog. Si ambas no se respaldan juntas, una restauración a la que le falte una deja medio sitio funcionando y la otra mitad en blanco.
En una tienda online, la base de datos cambia constantemente, puede hacer falta una copia diaria o incluso horaria; para un sitio corporativo de presentación, una copia semanal suele bastar. La frecuencia correcta sigue la frecuencia real con la que cambia el sitio.
Dónde debe guardarse la copia de seguridad
Guardar la copia en el mismo servidor que el sitio en producción es el error más habitual. Si el servidor queda totalmente inaccesible, la copia que está ahí desaparece en el mismo momento. Una copia también debería existir en un lugar completamente aparte, otro servidor, un servicio de almacenamiento en la nube, o el propio archivo de la empresa.
No hay una única respuesta correcta a cuántas copias y dónde; depende del tamaño del negocio. La regla que no cambia es esta: al menos una copia debe estar en un lugar totalmente independiente del servidor que aloja el sitio.
Por qué se salta la prueba de restauración, y por qué no debería
La mayoría de los negocios saben que hacen copias de seguridad, pero nunca han probado realmente a restaurar una. Un archivo de copia corrupto, una tabla de base de datos ausente o una versión de plugin incompatible solo aparecen al intentar una restauración, y raras veces en un momento conveniente.
Una prueba de restauración puede hacerse en un entorno de pruebas separado, sin tocar el sitio en producción. Hecha unas pocas veces al año, convierte horas de incertidumbre en una crisis real en minutos.
Qué debe contener realmente un plan de recuperación ante desastres
A diferencia de una copia de seguridad, un plan de recuperación ante desastres deja por escrito quién hace qué cuando algo sale mal. Puede ser una sola página, pero debe responder tres preguntas.
- Si el sitio queda totalmente inaccesible, a quién se llama en los primeros 30 minutos, y quién tiene acceso al panel de hosting
- Dónde está la última copia de seguridad que funcionaba, y quién puede acceder a ella
- Qué mensaje deberían ver los clientes, o una página de ventas en vivo, mientras dura la restauración
Qué tipo de sucesos activan este plan
La recuperación ante desastres no es solo cosa de fallos de servidor. Un sitio que se rompe tras una actualización, un conflicto de plugins, una página borrada por error, un intento de hackeo, o una caída del propio proveedor de hosting, todo eso exige el mismo plan.
Si la página de catálogo de un fabricante de suelos se rompe durante una actualización, no es un desastre a gran escala, pero el mismo plan debería funcionar también a pequeña escala: a qué copia volver, quién lo aprueba, y en cuánto tiempo.
Errores frecuentes en las copias de seguridad
El error más frecuente es respaldar solo a nivel de archivos y olvidar la base de datos. Si la copia semanal de un sitio industrial solo cubre el tema y las imágenes, un formulario de pedido o un registro de contacto puede perderse en el momento de la restauración.
El segundo error es que nadie lee realmente la notificación de la copia de seguridad. Una herramienta automática puede enviar un correo cada noche, pero si queda sin leer durante semanas, una copia que lleva un tiempo fallando en silencio pasa inadvertida igual de tiempo.
El tercero es depender por completo del propio sistema del proveedor de hosting sin ninguna copia en otro lugar. Si el sitio de una cadena de spas se apoya en una única copia guardada en el servidor del proveedor, una disputa o un problema de cuenta con ese proveedor puede llevarse también el acceso a la copia.
Cómo se aplica la recuperación ante desastres, paso a paso
En el momento de una caída, lo primero que hay que hacer, sin entrar en pánico, es entender el alcance del problema: ¿está afectada solo una página, o el sitio está totalmente inaccesible?
- Determine el alcance del problema: una sola página, todo el sitio, o solo el correo afectado
- Localice la última copia de seguridad que se sabe funcionó y anote su fecha
- Pruebe la restauración primero en un entorno de pruebas si es posible
- Prepare un mensaje temporal para los clientes antes de poner la restauración en producción
- No vuelva a poner en producción la misma copia sin haber corregido antes la causa del problema
Qué mirar al elegir una herramienta o servicio de copia de seguridad
Lo primero a comprobar al elegir una herramienta de copia de seguridad es dónde se guarda realmente la copia; una herramienta que solo respalda en el mismo servidor no ofrece protección real si ese servidor cae. El segundo punto es cuánto conocimiento técnico exige realmente una restauración; una herramienta que un dueño de negocio puede restaurar con un clic desde un panel permite actuar rápido sin esperar a un equipo técnico.
El tercer punto es la retención, hasta dónde conserva realmente las versiones la herramienta. Algunas solo guardan los últimos días, lo cual es inútil si un problema pasa inadvertido durante semanas antes de detectarse; una herramienta que conserva varias semanas de versiones ofrece una protección real frente a ese tipo de descubrimiento tardío.
Un buen plan de copia de seguridad no se mide por si la copia existe, sino por si funciona de verdad una vez restaurada; dónde se guarda y hasta dónde llega hacia atrás importa tanto como la herramienta misma. En una revisión técnica con rabbitclip podemos revisar su configuración actual de copias de seguridad y cerrar juntos los huecos.
Preguntas frecuentes
¿Las copias de seguridad deberían ser automáticas o manuales?
Automáticas. Una copia manual acaba olvidándose. Un calendario regular configurado desde el panel de hosting o un plugin elimina el error humano del proceso.
¿Cuántas copias de seguridad deberían guardarse?
No hay un número fijo; al menos una copia actual debe estar independiente del servidor en producción, y unas cuantas versiones anteriores protegen frente a problemas que pasaron inadvertidos un tiempo.
Si el sitio es hackeado, ¿basta con una copia de seguridad?
Una copia permite volver a una versión limpia, pero no cierra la brecha que usó el atacante; la vulnerabilidad debe encontrarse y corregirse antes de restaurar, o el mismo problema regresa.
¿Quién debería escribir el plan de recuperación ante desastres?
Quien aloja o gestiona el sitio, a menudo una agencia, debería redactarlo, pero el dueño del negocio también debe saber a quién llamar y qué tiene prioridad.
¿A qué hay que prestar más atención al elegir una herramienta de copia de seguridad?
A dónde guarda la copia y a cuántas versiones conserva; una copia que solo vive en el mismo servidor y cubre un único día no basta frente a problemas detectados tarde.
