Los backups son importantes
Los backups son importantes, y casi igual de importante es validar que los backups sirvan.
Les voy a contar una historia de cómo se me volvió a grabar este concepto recientemente.
La situación
Se me ocurrió que todos los cables que tengo en donde tengo las “cosas de la internet” estaban demasiado desorganizados, y como tenía que enchufar una computadora nueva, era un buen momento para organizarlos. Así que me puse a mover cables. El tema es que algo hice que la raspberry pi quedó mal enchufada, y cuando la enchufé bien no levantaba. Saqué la tarjeta SD, y se había muerto. Algo raro, una tarjeta de 128GB con dos particiones se había convertido en una tarjeta mucho más chica con una partición única con un archivo .bin adentro. Debería haberla guardado para intentar mejor.
El backup
Por suerte tengo un backup, pensé. Estaba un poco desactualizado, sí, pero al menos podía levantar todo de nuevo relativamente rápido, o eso pensé.
El backup que tenía era algo sencillo, hecho simplemente con:
| |
Sí, no me quemé demasiado. El punto era tener un respaldo por si pasaba algo.
Los problemas
Y bueno, pasó algo.
La tarjeta muerta
Lo primero que intenté fue ver si podía volver a usar la misma tarjeta. Capaz que no era un tema físico, sino lógico.
| |
Simple. Obviamente no funcionó. Me dijo que no había espacio en la tarjeta. La tarjeta SD estaba físicamente convencida de que se había achicado.
Bueno, no esperaba que esto funcionara, era sólo por las dudas, hubiese sido más barato.
Necesito una tarjeta nueva
Primer problema serio: no tengo otra tarjeta. Busqué por todos lados y sólo encontré algunas de 16GB. La tarjeta vieja era de 128GB. Si bien el contenido del filesystem entraría, andá a saber en qué parte de la imagen estaba eso y si iba a entrar.
- Lección aprendida: El respaldo de los datos no es suficiente. Tenés que tener un respaldo del hardware también, porque cuando falle, no querés tener que salir corriendo a buscarlo.
Por suerte, vivimos en el 2026, y no es tan loco conseguir una tarjeta SD un domingo. En el Geant venden. Fui hasta ahí y compré dos, ya que estaba.
Copiar la imagen a la tarjeta nueva
Así que, de nuevo:
| |
Y sentarme a esperar. Escribir 128GB en una tarjeta SD lleva un rato. Bastante rato. Tendría que haber puesto time para ver cuánto.
- Lección aprendida: Respaldar una imagen de 128GB de la cual sólo importan 2GB es una mala idea. Incluso cuando la imagen comprimida son 2GB.
Eventualmente me puse a jugar Patchwork con mi pareja, y cuando terminamos volví y tenía un error. Porque por supuesto que sí.
Resulta que no todas las tarjetas SD de 128GB tienen el mismo tamaño. No sé de qué depende, pero la que compré era más chica que la anterior, y la imagen no entró.
Por las dudas, intenté ver si el filesystem estaba intacto. No, tenía errores. Y no, fsck no ayudó. Cagamos.
Recuperando los datos
Bueno, claramente ya no estamos dentro del camino feliz de recuperar el backup. La buena noticia: los datos están, la imagen está ahí. La mala noticia: va a demorar un poco más recuperar esto.
La partición de boot de la tarjeta SD está bien y entera, el problema es la partición root. No la puedo montar, no la puedo fsckear. Vamos a dejarnos de joder con copiar imágenes y copiemos el contenido del filesystem. Para eso, mkfs sobre la partición root de la SD, montar la imagen, y hacer un cp -a. Sencillo. Por las dudas miré que todo estuviese como corresponde, y sí, sin dramas.
Así que puse la SD en la rpi, la prendí, y… error. Obviamente, no podía ser tan fácil.
El tema es que el booteo de la rpi determina el filesystem root en base a PARTUUID. En mis intentos de fsck, o con el mkfs, se borró el PARTUUID, y la rpi no encontraba la partición.
Buenísimo, sólo tengo que ponerle el PARTUUID nuevo a la partición y estamos. Pero ahí es donde empecé a hacer cagada tras cagada intentando arreglar esto.
No soy muy experto en los distintos tipos de particiones, fdisk, gdisk, y todas esas cosas, así que el primer paso fue ir a Google (sí, porque mi SearXNG estaba en esa raspberry pi), y buscar cómo cambiar el PARTUUID. Encontré resultados diciéndome gdisk, y fui con eso. gdisk me dijo que cambiara el tipo de tabla de particiones (de MBR a GPT) para poder setear el uuid a mano, así que lo hice. Mala idea, cuando quise ponerle el uuid que tenía antes, no me dejó, porque el uuid que tenía era de MBR y no de GPT y tienen un tamaño diferente.
Así que de vuelta a Google. Volví para atrás con el cambio de tipo de tabla de particiones, y usando fdisk pude ponerle el uuid. Excelente. Puse la tarjeta en la rpi, la prendí, y… error.
Peor error que antes, de hecho. Una pantalla rosada mientras la rpi buscaba entre las particiones. Google decía que era síntoma de que la tarjeta SD estuviese mal, pero no, si antes levantaba. Casi que me daban ganas de llorar.
Arrancando de cero
Al final la solución vino por arrancar de cero. No exactamente, pero casi. Sobreescribí la tarjeta con la herramienta oficial de raspberry pi, borré los datos en la partición root, copié el filesystem (cp -a), y listo. Lo probé y no anduvo, obvio. Me mostraba un splash screen (que antes no), y quedaba ahí.
No quiero un splash screen. Las letras que pasan serán feas, pero dan información. Y si se frena, puedo ver dónde se frena. Así que fui a editar la línea de comandos del kernel para sacar el splash, y ya de paso la hice igual que en la tarjeta vieja (excepto el PARTUUID), lo cual no solucionó el problema, pero lo hizo visible. Odio las splash screens.
El problema era que cuando copié todo el filesystem root de la tarjeta vieja, eso obviamente incluía /etc/fstab, que estaba queriendo montar / a partir de un PARTUUID que ya no existe. Ok, eso es fácil de arreglar. Lo cambié y… levantó.
Me llevó toda la tarde del domingo, pero pude volver a levantar todo como estaba. O casi, estaba el problema de que el respaldo tenía un par de cosas desctualizadas, pero eso es (comparativamente) menor. Al menos la mayoría de los servicios estaban corriendo de nuevo.
El nuevo respaldo
Luego de actualizar las cosas que había cambiado desde el respaldo anterior, era hora de hacer un nuevo respaldo. Obviamente no iba a hacer lo mismo, ya que no funcionó tan bien.
Al final terminé respaldando varias cosas, con la idea de luego probar qué necesito para restaurar el estado actual.
Primero, la fácil, la partición boot, la hice con una copia directa de la imagen:
| |
En este caso, no voy a tener problemas porque sé que la partición boot va a ser siempre del mismo tamaño.
Para la partición root no puedo hacer lo mismo porque ocupa el resto de la tarjeta SD y ya vimos que eso fue lo que me dio problemas. Además, está el tema de la cantidad de datos innecesarios. Así que pasé directo a la opción de archivar el filesystem. Tengo overlayroot para que el filesystem sea sólo lectura, lo cual me deja montada la partición original en /media/root-ro. Así que fui a ese directorio e hice:
| |
Con eso tengo todos los datos, pero otro de los problemas que tuve fue la tabla de particiones. Quiero una copia exacta. Acá es donde copié la información de tres maneras, para después probar cómo restaurar de la manera más sencilla posible.
| |
Para el tercero, en teoría con count=1 sería más que suficiente, pero pedirle la información con file me daba más información con 10 sectores que con 1, así que mejor guardar eso por las dudas.
| |
Con eso tengo suficiente información. Con qué me quedo va a depender de cómo ande la prueba.
Hay que probarlo
Tengo la segunda tarjeta que compré el otro día, así que podría probar con eso. Pero ya que estamos, mejor probar el escenario más catastrófico posible: usar una de las tarjetas de 16GB que tenía tiradas por ahí. Si puedo levantar el respaldo con la tarjeta de 16GB y funciona, sé que no voy a tener problemas con la de 128.
Empecemos con lo básico:
| |
Ok, eso debería ser todo. Un poco mucho trabajo, pero bastante lineal. La cuestión es si funcionó o no. La prueba de fuego sería reemplazar la tarjeta en la raspberry pi y ver si levanta. Pero primero hay que hacer algunas pruebas.
Y sí, tengo un problema: blkid me confirma que el PARTUUID no sobrevivió al mkfs.
| |
Otro problema es que al hacer umount root empezó a tirar errores. Me parece que agarrar una tarjeta SD muy vieja que no sabía si funcionaba pudo no haber sido la mejor idea. Por suerte tengo otra igualmente dudosa.
Luego de copiar la otra tarjeta, sigo con el problema del PARTUUID. Primero, por las dudas, arreglé el tamaño de la partición usando parted:
$ sudo parted /dev/sdb resizepart 2 16GB
Error: Can't have a partition outside the disk!
Ignore/Cancel? i
Error: Can't have a partition outside the disk!
Ignore/Cancel? i
Partition number? 2
End? [125GB]? 16GB
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? Y
Information: You may need to update /etc/fstab.
No entiendo por qué me ignoró los parámetros en la línea de comandos, en teoría estoy siguiendo lo que dice parted --help. Pero anduvo. E increíblemente, reapareció el PARTUUID.
Con un poco más de investigación y reintentar, me di cuenta del tema: el backup inicial no tiene el PARTUUID, pero parted lo arregla. Dado que igual tengo que meter el parted para ajustar el tamaño de la partición, eso me rinde. Por supuesto, para evitar problemas, debería hacer el resize antes de mkfs.
Arranqué de cero, hice todos los pasos, y listo. Quedó. Y ahí sí a la prueba real: cambiar la tarjeta. Apagué la raspberry pi, saqué una tarjeta, puse la otra, reinicié y… ¡anduvo! De hecho, ahora tengo todo corriendo desde la tarjea chica y vieja. La tarjeta de 128GB que estaba puesta, la tengo como respaldo listo para cambiar cuando sea necesario.
Final
El paso final es anotar todo. Este post podría servir como guía, pero es demasiado narrativo. Lo que necesito es una serie de pasos que pueda seguir cuando esté ansioso por tener todo andando lo más rápido posible, no algo que tenga que pensar y tener una buena chance de errarle.
Creé dos archivos y los puse junto al respaldo. Uno, con los pasos para crear o actualizar el respaldo. Otro, con los pasos para restaurarlo. Y con eso, doy por listo el respaldo de la tarjeta SD.
Todavía tengo que probar el respaldo de los datos del servidor, que están en un disco aparte. En teoría debería ser mucho más sencillo, pero bueno, tengo que probarlo.