Un respaldo que nunca restauraste no es un respaldo
Casi todos los respaldos que fallan corrían perfectamente todas las noches. El problema nunca es el respaldo: es que nadie lo había restaurado nunca. Aquí está el simulacro y su lista de verificación.
Casi todos los respaldos que fallan en el peor momento habían estado corriendo perfectamente todas las noches durante meses. El trabajo programado se ejecutaba, el archivo se generaba, el correo de confirmación llegaba. Y el día que hubo que usarlo, el archivo estaba truncado, o le faltaba una pieza indispensable, o nadie sabía con qué comando se restauraba. El respaldo nunca fue el problema. El problema fue que jamás se había restaurado.
La pregunta correcta no es «¿tenemos respaldos?». Todo mundo tiene respaldos. La pregunta es «¿cuándo fue la última vez que restauramos uno completo y lo verificamos?», y si la respuesta es «nunca», lo que tienes no es una estrategia de respaldo: es un archivo comprimido con buenas intenciones.
Este artículo es la estrategia completa para un ERP en producción: qué incluir, cada cuándo, dónde guardarlo, cómo probarlo y qué dos números hay que acordar con el dueño del negocio antes de configurar nada. Los ejemplos están sobre ERPNext, pero la estructura aplica a cualquier sistema con base de datos y archivos adjuntos.
Sumario
- 01Qué se respalda de un ERP, además de la base
- 02Lo que no hace falta respaldar
- 03Dónde se guarda: regla 3-2-1, retención y cifrado
- 04Los dos números que no son decisión de TI
- 05El simulacro trimestral, con su lista
- 06Siete formas de tener un respaldo inútil
- 07Monitoreo: alertar por ausencia
Qué se respalda de un ERP, además de la base
El error más común no es no respaldar: es respaldar solamente la base de datos. Un ERP no vive en la base de datos: vive en la base de datos más cuatro cosas más, y sin esas cuatro la restauración se queda a medias de una forma que no se nota hasta que alguien abre un documento.
| Pieza | Qué es | Qué pasa si falta |
|---|---|---|
| Base de datos | El volcado SQL completo del sitio | No hay nada. Es la pieza obvia y la única que casi todos sí tienen |
| Archivos públicos | Los adjuntos accesibles por URL: logos, imágenes de producto, archivos de la web | El sistema levanta pero los documentos aparecen con enlaces rotos |
| Archivos privados | Adjuntos sujetos a permisos: contratos escaneados, comprobantes, documentos de nómina | Lo mismo, pero con los documentos que más importan. Suele ser lo que se olvida |
| Configuración del sitio | El archivo de configuración con credenciales de base de datos y la llave de cifrado | Aquí está el problema grave. Va abajo con su propio recuadro |
| Código de las apps a medida | El repositorio y el commit exacto de cualquier desarrollo propio, más la lista de apps y versiones | La base restaura datos que apuntan a estructuras que no existen. El sitio no levanta |
El archivo de configuración del sitio contiene una llave de cifrado con la que el sistema guarda los campos sensibles: contraseñas de integraciones, credenciales de servicios de correo, tokens de proveedores. Si restauras la base de datos sin esa llave, el sitio levanta y parece estar bien, pero todos esos campos quedan ilegibles para siempre. No se recuperan: se vuelven a capturar uno por uno, si alguien se acuerda de cuáles eran. Respalda ese archivo y guárdalo en un lugar distinto del respaldo mismo.
En un Frappe o ERPNext, el comando base de la herramienta ya contempla las tres primeras piezas si se le pide explícitamente:
# produce tres archivos:
# ..._database.sql.gz la base
# ..._files.tar adjuntos públicos
# ..._private-files.tar adjuntos privados
Lo que no genera es la configuración del sitio ni el código de tus apps. Esas dos piezas se respaldan aparte, y por eso se olvidan. La configuración se copia como archivo; el código no se respalda: se versiona, y lo que se respalda es la referencia al commit exacto que estaba corriendo en producción, para poder reconstruir el mismo entorno y no «la versión más nueva», que puede no ser compatible con los datos.
Lo que no hace falta respaldar
Tan importante como la lista anterior, porque respaldar de más hace los respaldos lentos, caros y difíciles de probar, y un respaldo que tarda seis horas se acaba desactivando.
| No lo respaldes | Por qué |
|---|---|
| Redis | Es caché y cola de trabajos. Se reconstruye solo al arrancar |
| Los assets compilados | Se regeneran con un comando de construcción |
| El entorno de Python y los paquetes | Se reinstalan desde la definición de versiones |
| La imagen o el contenedor | Se reconstruye desde su archivo de definición, que sí debe estar versionado |
| Los logs | Útiles para diagnosticar, no para restaurar. Si los guardas, que sea en otro ciclo y con otra retención |
Respalda lo que no se puede volver a generar: datos y archivos que escribieron las personas, y los secretos. Todo lo que un comando puede reconstruir desde código versionado no es respaldo, es despliegue. Confundir las dos cosas es lo que produce respaldos de ochenta gigabytes que nadie prueba nunca.
Dónde se guarda: regla 3-2-1, retención y cifrado
La regla clásica sigue siendo la referencia correcta y se resume en tres números: tres copias de los datos, en dos medios distintos, con una copia fuera del sitio.
Traducido a un ERP en un servidor virtual: el sistema en producción es la copia uno. El respaldo en el disco del mismo servidor es la copia dos, que sirve para restaurar rápido un error humano. El respaldo en un almacenamiento de objetos de otro proveedor, o en otra región, es la copia tres, y es la única que te sirve el día que el problema es el servidor completo.
Un respaldo que vive en el mismo servidor comparte su destino con todo lo que le puede pasar al servidor: el disco, el proveedor, una eliminación accidental, y sobre todo un programa malicioso de cifrado, que hoy busca y cifra los respaldos locales primero, precisamente porque sabe que ahí está la salida. Si tu respaldo se puede borrar con las mismas credenciales con las que se accede a producción, no es una copia independiente.
Sobre la retención, el esquema que funciona sin ocupar un almacén entero es escalonado: muchas copias recientes y pocas antiguas.
| Ciclo | Cuántas se guardan | Para qué sirve |
|---|---|---|
| Cada hora o cada pocas horas | Las últimas 24 a 48 horas | Deshacer un error humano reciente sin perder el día |
| Diario | Los últimos 14 a 30 días | El caso normal de recuperación |
| Semanal | Las últimas 8 a 12 semanas | Detectar un dato corrompido hace un mes |
| Mensual | Los últimos 12 meses | Consulta histórica y requerimientos de auditoría |
| Anual | Según la obligación de conservación aplicable | Cumplimiento. Confírmalo con el contador, no lo decidas en TI |
Y el cifrado: el respaldo se cifra antes de salir del servidor, no en el destino. Eso vale sobre todo si la copia remota está con un tercero. Dos reglas que parecen obvias y se rompen seguido: la llave de cifrado no viaja dentro del respaldo, y alguien más que la persona que configuró el sistema tiene que poder llegar a ella. Un respaldo cifrado cuya llave sólo conoce el administrador que renunció es un respaldo perdido.
Los dos números que no son decisión de TI
Antes de configurar frecuencias y retenciones hay que acordar dos cifras, y la conversación es con la dirección, no entre técnicos. Se llaman objetivo de punto de recuperación y objetivo de tiempo de recuperación.
| Número | La pregunta que contesta | Qué lo determina |
|---|---|---|
| Punto de recuperación | ¿Cuántos datos podemos perder, medidos en tiempo? | La frecuencia del respaldo. Si respaldas cada 24 horas, puedes perder hasta 24 horas de captura |
| Tiempo de recuperación | ¿Cuánto tiempo puede estar caído el sistema? | Qué tan preparado está el procedimiento, no qué tan bueno es el respaldo |
La razón por la que esto no es una decisión técnica es que los dos números tienen precio, y el precio sube rápido. Pasar de perder un día a perder una hora significa respaldos más frecuentes y más almacenamiento. Pasar de ocho horas de recuperación a una significa tener un entorno alterno listo, probado y pagándose todos los meses sin usarse.
No preguntes «¿cuánto respaldo quieres?», porque la respuesta siempre es «todo». Pregunta: «si mañana a las once de la mañana el sistema se cae y perdemos la captura de ayer, ¿qué pasa en la empresa y cuánto cuesta?» Con esa respuesta en la mano, los dos números se fijan solos, y además queda por escrito que se fijaron entre los dos.
Y hay un dato que casi nadie tiene: el tiempo de recuperación real no se estima, se mide. Sale del simulacro de la siguiente sección, y la primera vez casi siempre es tres o cuatro veces mayor de lo que el equipo creía.
El simulacro trimestral, con su lista
Ésta es la parte central del artículo y la que casi nadie hace. Un simulacro de restauración es tomar el respaldo real, levantarlo en un entorno limpio y verificar que el sistema resultante sirve. Cada tres meses, con fecha en el calendario, y con alguien responsable.
El respaldo se toma del destino remoto, no del servidor de producción. Lo que se está probando no es el archivo: es toda la cadena, incluido el envío, el cifrado, los permisos de acceso al almacenamiento y la capacidad de alguien de recuperarlo. Si pruebas con el archivo que está en el mismo servidor, no probaste la parte que de verdad falla.
Lista del simulacro de restauración
El objetivo de un simulacro no es confirmar que el respaldo sirve. Es encontrar, con calma y sin presión, las tres cosas que te habrían detenido a las dos de la mañana.
Un detalle de procedimiento que vale mucho: que el simulacro lo haga alguien que no fue quien configuró el sistema, siguiendo únicamente el manual escrito. Si sólo el administrador puede restaurar, tu plan de continuidad depende de que esa persona esté disponible, de buen humor y con señal. Ese no es un plan.
Siete formas de tener un respaldo inútil
Todas éstas se ven bien desde afuera. Son las que aparecen cuando se revisa una instalación que «sí tiene respaldos».
| La falla | Cómo se detecta antes de que importe |
|---|---|
| El archivo se genera pero está vacío o truncado | Verificar tamaño mínimo y comparar contra el del día anterior. Una caída brusca es la señal |
| El respaldo vive sólo en el mismo servidor | Revisar que exista una copia en otro proveedor y que se pueda bajar |
| Falta la llave de cifrado del sitio | Intentar leer un campo cifrado en el entorno restaurado |
| Falta el código de la app a medida | Que el simulacro se haga desde cero, sin copiar nada del servidor original |
| El volcado se tomó sin consistencia transaccional | Correr un reporte financiero en el entorno restaurado y ver si cuadra |
| El aviso de falla llega a un correo que nadie lee | Mandar una falla de prueba a propósito y ver si alguien reacciona en el día |
| Nunca se restauró | Es la única que no se detecta: se corrige haciendo el simulacro |
Un volcado tomado sin aislamiento transaccional, mientras el sistema opera, puede capturar una factura cuyos movimientos de inventario todavía no estaban escritos. El archivo pesa lo que debe, restaura sin un solo error, y la contabilidad del entorno restaurado no cuadra. Es la falla más difícil de ver y la razón por la que la verificación del simulacro tiene que incluir un reporte financiero y no sólo un conteo de renglones.
Monitoreo: alertar por ausencia
El último punto, y el más barato de implementar. La mayoría de los respaldos avisan cuando terminan bien, y eso es exactamente lo contrario de lo que se necesita.
Un correo diario que dice «respaldo exitoso» se convierte en ruido en dos semanas, y cuando dejan de llegar nadie nota la ausencia, porque nadie nota la ausencia de un correo que ya no lee. Lo que hay que vigilar es justamente eso: que el respaldo no corrió.
| Qué vigilar | Cuándo debe alertar |
|---|---|
| Que el proceso haya terminado | Si no hay señal de finalización dentro de la ventana esperada, alertar |
| El tamaño del archivo | Si cae por debajo de un mínimo o se desvía mucho del día anterior, alertar |
| La llegada al destino remoto | Si el archivo no apareció en el almacenamiento externo, alertar |
| La antigüedad del respaldo más reciente | Si el más nuevo tiene más horas de las acordadas, alertar |
| La fecha del último simulacro | Si pasaron más de tres meses, alertar. Es el indicador que más se ignora |
Ese último renglón conviene tomarlo en serio. La antigüedad del último simulacro exitoso es el único indicador que mide si tu plan de respaldo existe de verdad, y es el único que no se puede automatizar, porque requiere que una persona haga el ejercicio. Ponlo en el tablero junto a los demás, con su fecha a la vista.
Qué verificar esta semana
Si administras un ERP en producción, estas cuatro cosas se revisan en una tarde y te dicen en qué situación estás realmente.
Uno: baja el respaldo de anoche desde el destino remoto a tu máquina. Si no puedes, o no sabes con qué credenciales, ya encontraste el primer hueco y es el grande.
Dos: ábrelo y confirma que trae las tres piezas: base, archivos públicos y archivos privados. Revisa aparte si tienes guardada la configuración del sitio con su llave de cifrado.
Tres: busca en tu repositorio si está versionado el código de todo desarrollo propio que esté corriendo, y si sabes qué commit es el que está en producción.
Cuatro: agenda el simulacro. Con fecha, con responsable y con dos horas bloqueadas. El trimestre que no se agenda es el trimestre que no se hace.
Hosting administrado de ERPNext, con restauración probada
Operamos tu ERPNext con respaldos cifrados fuera del servidor, retención escalonada, monitoreo por ausencia y simulacro de restauración documentado cada trimestre. Te entregamos el reporte del simulacro con el tiempo de recuperación medido, no estimado.
- —Respaldo de base, archivos públicos y privados, configuración y código
- —Copia cifrada fuera del servidor con retención escalonada
- —Monitoreo que alerta cuando el respaldo NO corre
- —Simulacro de restauración trimestral con reporte y manual actualizado