Comenzó un sábado por la noche con mi esposa preguntando por qué nuestro DVR de repente dejó de reproducir un programa que estaba viendo. Le dije que probablemente era solo un problema técnico, pero le echaría un vistazo. Entro en la sala familiar para mirar, y el error básicamente indicó que el disco subyacente ya no estaba disponible. ¡No está bien! Este fue el comienzo de mi historia de terror de tres días …
Un poco de historia
Mi DVR en realidad es solo un software especializado (SageTV para aquellos que tienen curiosidad) que se ejecuta en una PC. El software es muy flexible y le permite separar todos los diversos aspectos del mismo. Tengo una máquina separada para el control centralizado, la programación y la grabación, máquinas separadas para la reproducción y la estrella de esta historia, una máquina separada para el almacenamiento. Para el almacenamiento utilizo un servidor de archivos Linux, que utiliza LVM (Logical Volume Manager) para agregar muchas unidades separadas, no idénticas, en una unidad lógica grande (~ 6 TB en la actualidad) que ve el sistema operativo. Dado que hacer copias de seguridad de múltiples TB de datos no es práctico, y dado que dichos datos son "solo" programas de TV, mi filosofía de respaldo para esto siempre ha sido simplemente no importarme. Hasta eventos recientes, esta filosofía no había sido probada por un evento del mundo real.
Intentando recuperar los datos
Al ver el error en el DVR, inmediatamente comienzo a mirar el servidor de almacenamiento. El sistema de archivos es increíblemente lento y lento para responder, por lo que le pregunto a LVM sobre el estado de las unidades físicas subyacentes a su volumen lógico. Después de un largo retraso, aparece y dice que falta una unidad de 750 GB. ¡UH oh! Reinicio el servidor y, sorprendentemente, la unidad vuelve. Emito un comando pvmove para migrar automáticamente todos los datos de esa unidad, pero falla al completar el 2%.
Frente a una unidad que no coopera con la lectura de sus datos, pero que al menos aparece en el BIOS, recurro a mi herramienta de recuperación de unidades favorita, Spinrite. Aunque Spinrite normalmente arranca desde medios extraíbles, hace años configuré el arranque de red en mi casa para varias utilidades, por lo que no tuve que preocuparme por hacer un seguimiento de ningún medio. Normalmente solo me conecto a mi red, selecciono el arranque desde la red y tengo una variedad de herramientas a mi disposición para solucionar muchos problemas. El problema es que la máquina que hace que todo este trabajo mágico sea la misma máquina que está inactiva actualmente. No es gran cosa, digo, simplemente arrancaré desde un CD Spinrite. Excepto hace un par de años, la unidad óptica en mi servidor de archivos abandonó el fantasma. En el momento en que sucedió, decidí que dado que nunca uso medios ópticos en esa máquina, no necesitaba reemplazarlo. No se preocupe, me dije, solo sacaré la unidad óptica de mi computadora principal. Apago mi computadora principal y saco la unidad óptica. Luego busco mi CD de arranque Spinrite. No puedo encontrarlo! Nos mudamos a una nueva casa hace unos meses, por lo que todo está un poco desordenado. Supongo que grabaré una nueva copia, ¡pero ni siquiera puedo encontrar ningún medio óptico en blanco! En el próximo plan, ¡una unidad flash de arranque! Después de unos minutos en Google para actualizar mi memoria, tengo una unidad flash Spinrite de arranque. Arranco mi caja de Linux y lanzo Spinrite. La computadora se congela y parece fallar. Buscando eliminar las variables, muevo la unidad defectuosa para que no se conecte a una tarjeta de expansión PCI-e para que se conecte directamente a la placa base. Ahora Spinrite se inicia bien, pero lleva años y años enumerar las unidades conectadas a él. Desconecto sistemáticamente todas las demás unidades, excepto la mala, pero nunca termina de enumerar las unidades, no importa cuánto tiempo espere. En el próximo plan! Saco la unidad de disco de mi Linux box, la conecto a mi computadora principal y arranco desde mi nueva y brillante unidad flash Spinrite. Spinrite se inicia y ve el disco de inmediato, y le digo que comience a recuperar datos, satisfecho de que finalmente estoy progresando. Vuelvo a revisarlo después de unos 10 minutos, y hay un error en la pantalla, y parece que la unidad ha desaparecido una vez más. Frustrado, lo intento un par de veces más, y le digo a Spinrite que comience en varias partes del disco, pero obtengo el mismo resultado cada vez. Parece que esto no me va a ayudar después de todo.
En un ataque de esperanza irracional, volví a poner el disco en mi caja de Linux y lo encendí. Para mi sorpresa, el disco aparece y LVM pone todo activo. Después de probar suerte, emití otro comando pvmove para intentar mover los datos fuera de la unidad nuevamente. Al principio, veo mensajes de error sobre no poder leer desde el disco, pero sorprendentemente, pvmove continúa progresando, acercándose cada vez más al 100%. Una mezcla de confusión, alivio y emoción me invade. ¿Me voy a escapar de este ileso? Lamentablemente, lo último que hace LVM debajo de las cubiertas para terminar limpiamente un pvmove es escribir un registro actualizado en todas las unidades bajo su control. Esto, por supuesto, falla cuando intenta escribir en el disco defectuoso y, por lo tanto, aborta todo el proceso. ¡Derrota una vez más de las fauces de la victoria! Vuelvo a Google y descubro que es posible controlar la cantidad de datos que mueve el comando pvmove en lugar de mover TODOS los datos de una sola vez. Experimento con esto y tengo mucho éxito moviendo una pequeña porción de mis datos a la vez. Me vuelvo codicioso y el disco desaparece varias veces, pero siempre vuelve después de un ciclo de encendido de la computadora. Teorizando que quizás solo ciertas partes de la unidad son malas, empiezo a saltar en lugar de trabajar en el comienzo de la unidad. Después de algunas iteraciones de esto, tengo todos menos 40 GB de 750 GB movidos de forma segura fuera de la unidad. Para los 40 GB restantes, no se pudo mover sin importar lo que intenté. Era domingo por la noche y estaba exhausto, así que decidí acostarme y abordar este problema más al día siguiente.
Al día siguiente, después de dormir un poco y la primera mitad de mi día en el trabajo, decido morder la bala porque no me importaban los últimos 40 GB de programas de TV grabados, y decidí quitar el disco de mi configuración LVM . He hecho esto muchas veces antes, por lo que va bastante bien. Lo siguiente en la lista de limpieza es reparar el agujero en el medio del sistema de archivos. Supongo que solo faltan 40 GB en lugar de 750 GB, no puede ser tan malo, ¿verdad? ¡Incorrecto! Después de la reparación, tenía 900 GB de espacio libre adicional en comparación con antes del inicio de la prueba, por lo que me dolió bastante. Bueno, me digo a mí mismo, de todos modos, solo era televisión. Mi DVR finalmente vuelve a funcionar después de su pausa de tres días, y finalmente puedo dejar de pensar en esto con cada ciclo cerebral libre.
Lecciones aprendidas
Entonces, ¿qué aprendí de todo esto? Debería haber hecho un mejor trabajo de lo que realmente importaba. Esto sucedió hace unas semanas, y en ese momento ni siquiera me perdí el contenido de TV que desapareció. Sin embargo, lamento haberme impedido, pero lo más importante, a mi familia, poder usar el televisor durante tres días y ponerme en modo de crisis de alto estrés durante esos tres días. Si hubiera renunciado a recuperar mis datos al principio, la función se habría restaurado en aproximadamente una hora, no en tres días. Sé muy bien que la mayoría de las veces nuestros datos son preciosos, pero en esta situación no lo era.
En segundo lugar, si sus datos son realmente preciosos, y el 99% de las veces realmente lo son, ¡debe protegerlos! Copia de seguridad de sus datos, no hay excusas. Para mis datos que son irremplazables, como miles de fotos de mi hijo que tengo en mi computadora, me aseguro de hacer una copia de seguridad en no menos de tres lugares, uno de los cuales es un proveedor de respaldo en la nube. En cuanto al almacenamiento de DVR, todavía no creo que sea práctico hacer una copia de seguridad en la nube, pero con el precio de las unidades en estos días, no tengo excusa para no tenerlo protegido por RAID, y eso es lo que estoy haciendo. va a hacer Cuando configuré por primera vez mi clúster de almacenamiento hace años, creo que me llevó 10 unidades o más llegar a un grupo de TB múltiple. Acabo de comprobar los precios, y ahora puedes comprar una unidad de 3 TB por menos de $ 100. Simplemente no tengo excusa para dejar mis datos desprotegidos, y si una pérdida de datos como esta me ocurre nuevamente, es realmente mi culpa.
