Un standby frío en AWS para mi servidor casero: qué medí y qué falta probar
Copias en S3 y cómputo apagado para recuperar un servidor casero. Un ensayo preparó datos en 266 segundos; explico por qué eso todavía no mide el RTO.
Mi servidor de casa es una sola máquina. Una copia en un disco del mismo gabinete me ayuda si borro un archivo, pero no si pierdo el gabinete entero. Quería saber qué versión de los datos podría recuperar desde fuera de casa y cuánto tardaría en preparar un reemplazo.
Elegí una solución acotada: copias externas en Amazon S3 y una instancia de cómputo que permanece apagada. Si hace falta, una persona la enciende y ejecuta el procedimiento de recuperación. El ensayo que hice prepara los datos, pero no mueve tráfico ni levanta los servicios públicos. Es un standby frío, con intervención humana y con partes del sistema que todavía quedarían fuera.
Dos preguntas distintas
El RPO fija cuánto tiempo de cambios aceptás perder desde el último punto recuperable. El RTO expresa cuánto tiempo aceptás que el servicio esté interrumpido. AWS los define como objetivos separados : tener una copia reciente no dice cuánto tardarás en atender una petición otra vez.
En este diseño, algunos grupos de datos salen a S3 a diario y otros, semanalmente. Por frecuencia, las ventanas objetivo son de hasta 24 horas y hasta siete días, respectivamente. Son objetivos condicionados a que los trabajos terminen bien. Una copia con fecha reciente tampoco demuestra que una aplicación pueda arrancar con ella: hay que leerla, verificarla y restaurarla.
Para reducir el riesgo de borrado accidental, las copias externas usan versionado y S3 Object Lock. La retención se aplica a versiones de objetos; en modo governance un usuario con permisos especiales puede saltarla, mientras que compliance impone una protección más estricta. La documentación de S3 explica esos límites . Ninguna de las dos modalidades prueba que los datos sean restaurables.
Qué medí en el ensayo
El 18 de octubre de 2026 repetí un ensayo guiado. La instancia estaba apagada al empezar. Tardó 9 segundos en pasar a
running y 17 segundos más en responder por SSH. Después ejecuté el procedimiento en modo de ensayo: leyó los paquetes seleccionados de S3 y preparó los datos sin descifrar secretos, iniciar servicios ni cambiar las rutas de entrada. Esa fase tardó 240 segundos medidos desde fuera del script.Desde la orden de arranque hasta el final de esa preparación pasaron 266 segundos. Confirmar que la instancia volviera a estar apagada tomó 24 segundos; la operación completa duró 295 segundos. El ensayo terminó bien y dejó la instancia detenida.
En una prueba anterior, el 29 de septiembre, la preparación había tardado 204 segundos desde el arranque. Dos mediciones distintas muestran que no conviene convertir un único número en promesa. Tampoco permiten atribuir la diferencia a una causa concreta sin medir cada etapa con más detalle.
266 segundos no son mi RTO. No apagué el servidor principal, no moví DNS ni tráfico y no comprobé desde fuera que todas las aplicaciones respondieran. Algunos servicios ni siquiera están previstos en este standby. La medición cubre el arranque y la preparación de una parte del sistema.
También pruebo las copias locales por separado, en un entorno descartable. El 4 de octubre un test comprobó 13 de 13 grupos, sin fallos ni resultados desconocidos. Desde entonces agregué otro grupo al conjunto: ese resultado histórico no valida el nuevo. Además, ese test leía el disco local; el ensayo del standby leía paquetes de S3. Juntos aportan evidencia distinta, pero todavía no forman una restauración completa de punta a punta.
Lo próximo que tengo que demostrar
El siguiente ejercicio útil es simular que el servidor principal no está: recuperar desde S3, iniciar los servicios previstos, comprobar una petición desde fuera y medir también el regreso al servidor de casa. Eso requiere un plan de corte controlado para evitar que dos máquinas atiendan o procesen las mismas tareas a la vez.
Hasta que haga esa prueba, tengo un tiempo observado de preparación y objetivos de pérdida de datos, pero no un tiempo de recuperación del servicio observado. Para mí, esa distinción es la parte más valiosa del ensayo: saber exactamente qué medí y qué sigue siendo una hipótesis.
El código de este diseño, sin datos reales, está en GitHub: homelab-blueprint . La carpeta standby/ tiene el runbook, los scripts del ensayo y las políticas de IAM.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article