Blog

Una copia de seguridad que nunca has restaurado

Cuál de las dos pruebas te toca depende de quién guarda tus copias de seguridad, y una de ellas cabe entre dos citas.

Empieza por definir qué tipo de sitio tienes, porque aquí hay dos pruebas. Si tu sitio está en Wix, Squarespace o el editor de GoDaddy, tu hosting guarda las copias de seguridad por ti. No hay un archivo de copia que puedas descargar. Si está en WordPress con su propia cuenta de hosting, o en cualquier cuenta de hosting con panel de control, casi siempre puedes descargar una copia por tu cuenta. Si no lo tienes claro, entra a la cuenta que pagas cada mes y busca una página de copias de seguridad. Si no hay ninguna, trata tu sitio como el primer tipo.

Una copia de seguridad que se ejecutó todas las noches durante dos años y reportó éxito 728 veces, junto a la única línea que nunca se marcó: un archivo restaurado de verdad desde ella. Un ejemplo con números inventados, no el sistema de nadie.

"Tenemos copias de seguridad" y "podemos restaurar" son dos frases distintas. Es fácil comprobar la primera y no comprobar nunca la segunda. Una copia de seguridad que nunca has restaurado es una afirmación, no una red de seguridad.

Si tu sitio está en Wix, Squarespace o el editor de GoDaddy

Nada de lo que va del Paso 1 en adelante te toca a ti, y no hay ningún archivo comprimido que descargar. Quedan dos preguntas más pequeñas, y las dos caben en el hueco entre dos citas.

Saca tu propio contenido. Busca en tu configuración una opción de exportar. Lo que abarca cambia según la plataforma. Suele ser una lista de productos, pedidos, clientes o entradas, no el sitio entero. Descárgala, abre el archivo y comprueba que tus registros más nuevos estén ahí. Todo lo que la plataforma no exporte es algo que alguien tendría que volver a escribir a mano.

Prueba el historial del sitio en una página que puedas darte el lujo de perder. Busca en tu editor un historial del sitio o un historial de versiones. No lo pruebes en una página que usen tus clientes. Crea una página nueva y escribe una línea en ella. Déjala fuera de tu menú. Bórrala y luego restáurala desde el historial. Si vuelve con su texto, la función sirve y ya sabes dónde está el botón. Si no hay historial, el soporte de tu hosting es el único camino de vuelta. Ten su número a mano.

La página que menos te gustaría perder es la que tiene tu teléfono y tu horario de atención. Una exportación que nunca has abierto es la misma afirmación que una copia de seguridad que nunca has restaurado.

La prueba de restauración, para un sitio con base de datos propia

Abre el panel de control de tu hosting y busca la página de copias de seguridad. La mayoría muestra una lista de fechas con un estado al lado de cada una. Una fila marcada como correcta dice que una tarea se ejecutó. No dice que esa tarea haya producido algo que puedas volver a poner en su lugar.

Las formas en que una copia de seguridad puede fallar no tienen nada de raro. Una tarea nocturna puede ejecutarse sin incluir la base de datos. Una tarea puede fallar durante semanas mientras la alerta llega a un correo que nadie revisa. Una copia puede restaurarse bien y aun así tardar más de lo que alcanza un día.

Esto lo puedes resolver por tu cuenta. Aparta una mañana tranquila de este mes y haz la prueba de abajo. Lleva más tiempo que las revisiones rápidas que puedes hacer en el sitio mismo, y responde a otra pregunta.

Paso 1. Lee la copia de seguridad antes de restaurar nada

Descarga la copia más reciente a tu propia computadora y descomprímela. Vas a buscar dos cosas.

  • Un volcado de la base de datos. Suele ser un archivo terminado en .sql, a veces .sql.gz. Si en el archivo comprimido no hay base de datos, lo que tienes es una carpeta de archivos y nada más. Ni páginas, ni productos, ni pedidos, ni mensajes de formularios.
  • Tus archivos subidos. En un sitio WordPress eso es wp-content/uploads, y en cualquier otro sitio es la carpeta donde están tus fotos. Ábrela y comprueba que las carpetas de los últimos meses tengan imágenes de verdad.

Después abre el archivo .sql en un editor de texto plano. Si es .sql.gz, descomprímelo primero. Busca unas cuantas palabras que hayas publicado hace una semana o dos. Elige una frase corta sin apóstrofos ni comillas. Esos caracteres se guardan con una barra invertida delante, así que una búsqueda exacta no los encuentra. El volcado de un sitio grande puede ser demasiado pesado para un editor básico. En ese caso, búscalo desde la terminal con grep.

Paso 2. Restáurala en un lugar que no sea tu sitio real

Sirven tres lugares.

  1. El sitio de pruebas de tu hosting. Muchos paneles de control tienen un botón de "crear sitio de pruebas". Úsalo si lo tienes.
  2. Tu propia computadora. Local es gratuito, lo hace WP Engine y ejecuta un sitio WordPress en tu propia máquina. No se publica nada en línea. El formulario de descarga pide una dirección de correo.
  3. Un subdominio, por ejemplo restoretest.yourbusiness.com.au. Ponle una contraseña para que ni los clientes ni los buscadores lo vean nunca.

No restaures encima de tu sitio real para averiguar si la restauración funciona. Eso no es una prueba. Eso es la emergencia, organizada a propósito.

Anota la hora a la que empiezas y la hora a la que el sitio restaurado carga por primera vez. Sin ese dato sabes que la restauración funciona, pero no si es lo bastante rápida.

Paso 3. Decide qué significa "funcionó" antes de mirar

Abre la copia restaurada y comprueba cinco cosas.

  • La página de inicio carga.
  • Las imágenes cargan dentro de una página, no solo la página misma.
  • Puedes entrar al administrador.
  • Funciona algo que lee de la base de datos: un formulario de reservas, una lista de precios, una página de la tienda, una lista de consultas.
  • Está tu contenido real más reciente. Busca algo que hayas publicado la semana pasada.

Si las cinco se cumplen, tienes una red de seguridad, y ya sabes más o menos cuánto tarda en volver a estar en pie.

Cómo se ve un mal resultado

  • No hay ningún archivo .sql en todo el archivo comprimido.
  • El sitio restaurado muestra un error de conexión a la base de datos.
  • Las páginas cargan y las imágenes no. La carpeta de archivos subidos no estaba en la copia.
  • Falta el contenido más nuevo. La base de datos se tomó de una copia vieja.
  • La restauración necesita la clave de licencia de un plugin, o un acceso que ya no tiene nadie del negocio.
  • Funcionó, y tomó el día entero, en una mañana tranquila y sin nada en juego.

Ninguno de estos casos significa que hoy estés en problemas. Significan que la lista de marcas verdes medía otra cosa, y ahora sabes cuál. Un acceso que ya nadie tiene es un problema de cuentas, no de copias de seguridad, y hay una lista de las cuentas que conviene revisar.

Lo que no debería preocuparte

Mucho de lo que parece roto en una copia restaurada es normal. Ignora todo esto.

  • La copia no envía correos. Es lo esperable. Los sitios de pruebas y las copias locales casi nunca tienen el correo configurado.
  • Un aviso de seguridad del navegador en una copia local. Es lo esperable, salvo que la herramienta te haya instalado un certificado local. Una copia en tu computadora no tiene certificado para tu dominio real.
  • Algunos enlaces siguen apuntando al dominio real. Es normal. Las direcciones se guardan dentro de la base de datos, y restaurarla no las reescribe. Así que un enlace puede devolverte al sitio real sin que te des cuenta. Eso hace que una prueba fallida parezca aprobada. Mira la barra de direcciones antes de dar por buena una página.
  • Un plugin dice que su licencia no es válida en este dominio. Es normal. Las licencias suelen estar atadas al dominio real.
  • Las analíticas. Una copia restaurada sigue llevando tu código de seguimiento, así que puede sumar visitas de prueba a los reportes de tu sitio real. Ponle una contraseña a la copia, o quítale el código de seguimiento antes de andar haciendo clic. Si la copia no registra nada, está bien. En cualquier caso no es parte de la prueba.

Si están las páginas, las imágenes, el contenido de la base de datos y el acceso, la prueba pasó. Todo lo de esa lista es ruido.

Paso 4. Escribe cuatro líneas y fija la próxima fecha

Anota la fecha. Dónde restauraste. Cuánto tardó, de principio a fin. Qué faltaba.

Bastan cuatro líneas en un archivo de texto plano, guardado junto a los datos de tu hosting. Así la próxima persona que haga esto arranca desde lo que tú encontraste.

Después pon la siguiente en tu calendario, dentro de un trimestre. Una prueba de restauración solo vale mientras sea reciente. Se agrega un plugin, se cambia de hosting, alguien cambia la programación de las copias.


Este mes vas a aprender una de dos cosas. O la red de seguridad es real, o era solo una afirmación. Cualquiera de las dos es mejor saberla un martes tranquilo que el día en que la necesitas.

Nosotros hacemos esta prueba por ti si prefieres que la haga alguien más. Lo que importa es que la prueba se haga, no quién la hace. Elige la mañana y hazla.

Lo que nos preguntan

Mi sitio está en Wix, Squarespace o GoDaddy. ¿Necesito una prueba de restauración?
No la de este artículo, porque no hay un archivo de copia que puedas descargar ni un servidor donde ponerlo. Tu hosting las guarda por ti. En su lugar te tocan dos revisiones más cortas. Exporta lo que la plataforma te deje exportar y abre el archivo, y luego prueba el historial del sitio: crea una página, bórrala y restáurala.
¿Cada cuánto debo probar la restauración de un sitio web?
Elige un intervalo y mantenlo. Cada trimestre funciona bien, porque es lo bastante corto para descubrir una copia dañada antes de perder mucho, y lo bastante largo para que la prueba no se vuelva una carga. Hazla también justo después de cualquier cambio por debajo del sitio, como un hosting nuevo, una herramienta de copias nueva o un servidor nuevo.
¿Dónde debo restaurar una copia de seguridad para probarla?
En cualquier lugar que no sea tu sitio real. Sirve un sitio de pruebas creado desde el panel de control de tu hosting, una copia en tu propia computadora con un programa gratuito como Local, o un subdominio protegido con contraseña. Nunca restaures encima del sitio real para averiguar si la restauración funciona, porque un intento fallido deja fuera de servicio el sitio que ven tus clientes.
¿Cómo compruebo si mi copia de seguridad incluye la base de datos?
Descarga la copia y descomprímela. Busca un archivo terminado en .sql o .sql.gz, que es el volcado de la base de datos. Si no hay ninguno, la copia solo tiene archivos, es decir, ni páginas, ni productos, ni pedidos, ni mensajes de formularios. Abre el archivo .sql en un editor de texto plano y busca algo que hayas publicado hace poco para confirmar que la base de datos está al día.
Mi copia restaurada no puede enviar correos. ¿Significa que la copia de seguridad falló?
No. Los sitios de pruebas y las copias locales casi nunca tienen configurado el servicio de correo, así que ahí el envío falla por diseño. Lo mismo vale para los avisos de certificado del navegador, los avisos de licencia de los plugins, las páginas que cargan más lento y las analíticas que no registran nada. Para juzgar la restauración, fíjate en si están las páginas, las imágenes, el contenido de la base de datos y el acceso al administrador.