Hay una frase que se repite en todas las empresas que han perdido datos: «pero si teníamos copia».
Tenían copia. Lo que no tenían era una restauración probada, que es otra cosa. Este artículo va de esa diferencia, que es la única que importa el día malo.
Las tres formas de tener copia y no tenerla
La copia en el mismo servidor. Si el disco muere, se lleva el original y la copia. Si alguien cifra el servidor con un ataque, cifra las dos. Una copia que comparte destino con el original no es una copia, es un duplicado.
La copia que nadie mira. El proceso falló hace cinco meses, envió un correo de aviso que fue a parar a una bandeja que nadie lee, y desde entonces no hay nada. Es el caso más frecuente con diferencia.
La copia que no se puede restaurar. Existe, está completa, y cuando hace falta resulta que faltaba la base de datos, o que los archivos están ahí pero sin el volcado que los relaciona. Esto se descubre siempre en el peor momento, salvo que lo hayas ensayado antes.
La regla de siempre, que sigue funcionando
Tres copias de los datos, en dos soportes distintos, y una de ellas fuera del sitio. Es vieja porque funciona.
Para una pyme con un servidor, eso se traduce en algo muy concreto: los datos en el servidor, una copia en almacenamiento externo, y otra en un sitio distinto del anterior. Y las dos copias, cifradas, porque están fuera de tu control físico.
Qué hay que copiar, exactamente
Aquí está el error técnico más caro: copiar los archivos y olvidar la base de datos, o al revés. Casi todos los sistemas de la pila libre guardan la información en dos sitios a la vez, y hacen falta los dos.
| Sistema | Base de datos | Archivos |
|---|---|---|
| Odoo | PostgreSQL | El almacén de adjuntos (filestore) |
| Nextcloud | MariaDB o PostgreSQL | El directorio de datos y la configuración |
| Vaultwarden | SQLite o PostgreSQL | Adjuntos y claves del servidor |
| WordPress | MariaDB | wp-content y la configuración |
Y un detalle que se pasa por alto: la base de datos hay que volcarla, no copiar sus ficheros en caliente. Copiar los archivos de PostgreSQL mientras está funcionando produce una copia que a veces restaura y a veces no, que es lo peor de ambos mundos.
Con qué hacerlo
Dos programas libres cubren el noventa y nueve por cien de los casos, y los dos hacen lo mismo bien: copia incremental, deduplicada y cifrada.
- Restic. Un solo ejecutable, sin dependencias, habla directamente con casi cualquier almacenamiento de objetos. Es el que recomendamos si empiezas de cero.
- BorgBackup. Más veterano, deduplicación excelente, algo más exigente con el destino. Muy sólido si el destino es un servidor tuyo.
Ambos cifran en origen. Eso significa que el proveedor donde guardas la copia no puede leerla, que es exactamente lo que quieres cuando el destino es de otro.
Guarda la clave de cifrado fuera del servidor. Si la única copia de la clave está en la máquina que se ha perdido, tienes una copia perfectamente cifrada e inútil. En papel, en una caja fuerte, junto a la clave maestra del gestor de contraseñas.
Cada cuánto, y cuánto guardar
La pregunta que ordena esto no es técnica: ¿cuánto trabajo puedes permitirte rehacer? Si la respuesta es «un día», copia diaria. Si es «una hora», necesitas algo más elaborado y más caro.
Para una pyme normal, una pauta razonable es guardar las copias diarias de la última semana, las semanales del último mes y las mensuales del último año. Con deduplicación, eso ocupa mucho menos de lo que parece.
El año de copias mensuales no es capricho. El daño que más tarda en detectarse no es el disco que muere —eso se nota el mismo día— sino el archivo que alguien borró en marzo y se echa de menos en agosto.
El ensayo de restauración
Esta es la parte del artículo que de verdad importa, y la que casi nadie hace.
Una vez al trimestre, coge la copia y levanta el sistema en otro sitio: otra máquina, o el mismo servidor en una carpeta aparte. Entra. Mira que los datos estén. Abre un documento con adjunto. Comprueba que la última factura emitida aparece.
La primera vez casi nunca sale a la primera, y eso es exactamente lo que buscas: descubrir en un ensayo lo que faltaba, en vez de descubrirlo con la empresa parada. Anota lo que falló, arréglalo, y repite hasta que salga.
Dos preguntas para cerrar el ensayo, que son las que un seguro o una auditoría te van a hacer: cuánto tardaste en tener el sistema funcionando, y cuánto trabajo se habría perdido. Si alguna de las dos respuestas no te gusta, ya sabes qué cambiar.
Lo mínimo aceptable
Si te quedas con una sola cosa de todo esto:
- Copia diaria, cifrada, fuera del servidor.
- Bases de datos volcadas, no copiadas en caliente.
- Un aviso que llegue a alguien cuando falle, a una bandeja que esa persona lea.
- Un ensayo de restauración cada tres meses, anotado.
- La clave de cifrado fuera de la máquina.
Es la capa sobre la que se apoya todo lo demás del ecosistema. Sin ella, autoalojar no es ahorrar: es asumir un riesgo que antes asumía otro.