Recuperación a un punto en el tiempo frente a snapshots: qué pierdes
La recuperación a un punto en el tiempo frente a los snapshots se reduce a una cifra: cuántos datos puedes permitirte perder. Entiende el RPO, cuándo bastan los snapshots nocturnos y cuándo no.
Alguien ejecuta un DELETE sin una cláusula WHERE a las 16:15. Tu backup más reciente es de las 03:00. Todo lo ocurrido entre esos dos momentos se ha perdido, y ninguna restauración podrá recuperarlo.
Ese intervalo tiene un nombre: objetivo de punto de recuperación, o RPO, y la decisión entre recuperación a un punto en el tiempo frente a snapshots consiste por completo en determinar qué tamaño estás dispuesto a aceptar para ese intervalo.
Los dos modelos
Los snapshots capturan el estado de tus datos en un momento concreto. Se ejecutan según una programación, normalmente cada noche. Restaurar uno te devuelve exactamente al estado en el que estabas cuando se ejecutó, y todo lo posterior se pierde.
La recuperación a un punto en el tiempo combina un backup base con un flujo continuo del write-ahead log de la base de datos. Como cada cambio se registra en orden, puedes reproducirlo hasta cualquier momento cubierto por el log conservado, incluido las 16:14, un minuto antes del borrado.
La diferencia no es gradual. Es la diferencia entre «hemos perdido un día» y «hemos perdido un minuto».
La cifra que lo decide
Hazte una pregunta, con sinceridad: ¿qué ocurre si pierdes todo lo escrito durante las últimas doce horas?
En un proyecto personal, un sitio de documentación o una herramienta interna cuyos datos se pueden reproducir: no gran cosa. Los snapshots nocturnos son realmente la respuesta adecuada, y pagar por el archivado continuo sería un desperdicio.
Para cualquier sistema al que los clientes envían datos, la respuesta suele ser algo parecido a «tendríamos que escribir a la gente para explicárselo». Pedidos que ya no existen. Archivos subidos que han desaparecido. Mensajes que se enviaron y ahora ya no están. Solo el coste de soporte suele superar el de un año de diferencia en el gasto de infraestructura.
El error no es elegir snapshots. El error es elegirlos por defecto, sin preguntarse nunca cuánto costaría un agujero de doce horas.
Para qué sirven realmente los snapshots
No son un producto inferior. Cubren fallos que PITR no cubre:
- Pérdida completa del disco. Un snapshot en almacenamiento independiente restaura todo, incluidos los archivos que no pertenecen a la base de datos.
- Rollback rápido y general. Revertir una migración fallida en un entorno de staging es más rápido desde un snapshot que reproduciendo un log.
- Coste. Almacenar una copia al día es más barato que almacenar cada escritura.
- Simplicidad. Tener menos piezas es una ventaja operativa real, especialmente para un equipo pequeño.
La trampa está en tratarlos como suficientes para una base de datos que recibe escrituras continuamente.
Qué te cuesta PITR
No es gratis, y merece la pena poner nombre a sus costes:
- Almacenamiento. Conservas el backup base más cada escritura del periodo de retención.
- Complejidad. El archivado tiene que funcionar continuamente. Un archiver que lleva una semana fallando en silencio significa que tu ventana recuperable termina hace una semana; por eso monitorizar el archivo es tan importante como configurarlo.
- Tiempo de restauración. Reproducir un log tarda más que restaurar un snapshot. Tu RPO mejora; tu RTO normalmente empeora.
Este último intercambio suele sorprender. PITR significa que pierdes menos datos, no que vuelves a estar online más rápido.
La respuesta por capas que la mayoría de equipos necesita
En la práctica, no es una elección entre dos cosas. Las bases de datos de producción suelen necesitar tres capas, porque fallan de tres formas distintas:
Snapshots diarios, conservados durante una o dos semanas. Un seguro barato frente a la pérdida de la máquina. También cubren los archivos que no pertenecen a la base de datos y están en el mismo volumen.
Volcados lógicos diarios, guardados fuera del host. Un pg_dump es portable y coherente por construcción. Se restaura en otra major version, con otro proveedor o en un portátil; justo lo que necesitas cuando el problema es la plataforma y no los datos.
Archivado continuo, cuando la base de datos contiene datos de clientes. La capa que convierte «hemos perdido el día» en «hemos perdido un minuto».
Cada capa cubre lo que las demás no. Un snapshot no te ayuda a cambiar de proveedor. Un volcado lógico no te ayuda a recuperar un archivo que no estaba en la base de datos. Ninguno de los dos te ayuda a deshacer un borrado de hace cuatro horas.
Dónde encaja Dockup
Dockup te ofrece las dos capas que cubren los fallos más habituales, y merece la pena precisar cuáles son.
Snapshots de volumen, bajo demanda o según una programación con un número de copias conservadas:
dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api
Backups lógicos de bases de datos, enviados directamente a object storage y cifrados durante el proceso:
dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json
Hay dos propiedades de este último proceso que son importantes para la recuperación. El backup nunca llega al host de la base de datos: se envía por streaming al almacenamiento a medida que pg_dump lo genera, por lo que no comparte el destino del disco del que procede. Además, un volcado que termina con un código distinto de cero o que genera cero bytes se elimina y se registra como fallido, en lugar de quedarse en la lista con aspecto de backup válido.
Hoy, Dockup no ejecuta el archivado continuo por ti. Si tu RPO realmente necesita ser de unos minutos, debes saberlo antes de elegir, y es razonable ejecutarlo por tu cuenta contra una base de datos gestionada mientras utilizas la plataforma para todo lo demás.
El ejercicio que merece la pena hacer esta semana
Anota dos cifras para tu base de datos de producción:
- RPO: cuántos datos puedes perder. Se mide en tiempo.
- RTO: cuánto tiempo puedes estar inactivo. También se mide en tiempo.
Después, comprueba qué ofrece realmente tu configuración restaurando algo. Si las cifras que has anotado y las que ofrece tu configuración son distintas, has encontrado una decisión que puedes tomar cuando nada está ardiendo; y ese es el único buen momento para tomarla.
Preguntas frecuentes
¿Cuál es la diferencia entre RPO y RTO? El RPO indica cuántos datos pierdes: el intervalo entre el último momento recuperable y el fallo. El RTO indica cuánto tarda la recuperación. Los snapshots ofrecen un RPO amplio y un RTO corto; PITR invierte esa relación.
¿Puedo recuperar filas eliminadas hace una hora a partir de un snapshot nocturno? No. Un snapshot restaura el estado en el momento en que se tomó. Todo lo escrito después no está en el archivo. Para recuperar un momento arbitrario necesitas archivado continuo.
¿Un snapshot de volumen es lo mismo que un backup de base de datos? No. Un snapshot captura el disco, incluido el estado en el que se encontraba la base de datos en mitad de una escritura. Un volcado lógico es coherente internamente y portable a otras versiones y proveedores. La mayoría de las configuraciones de producción necesitan ambos.
¿Durante cuánto tiempo debería conservar los backups? Durante el tiempo suficiente para detectar un problema. La corrupción o una migración defectuosa suelen descubrirse días después, por lo que conservar los backups solo un día a menudo significa que las únicas copias disponibles ya contienen el daño.