Accidentalmente comprimí todo mi servidor


10

Bien, si alguien quiere jugar a ser dios y hacer milagros, estoy deprimido.

Entonces, me dieron la tarea de hacer un script que encontrara archivos que tenían más de 6 meses, los comprimí y luego los eliminé. En mi camino al hacer el script de tihs ejecuté esto:

find / -type f -mtime -400 ! -mtime -180 | xargs gzip blablabla

Y eso le dio a CADA ARCHIVO UNA extensión .gz. Ahora lo deshice tan pronto como me di cuenta, pero ya era demasiado tarde. Al completar el comando, ninguno de mis comandos bash funcionaría porque la variable $ PATH se vació sola. Intenté muchas cosas antes de darme cuenta de cuál era el problema.

Después de descomprimir todo, todavía no puedo arrancar. Logré llegar al rescate de grub, después de lo cual seguí las instrucciones en línea para:

root (hd0,0)
setup (hd0)
kernel (hd0,0)/boot/vml[...]
initrd (hd0,0)/boot/initrd.im[...]

Después de lo cual mi Linux arranca parcialmente pero me da los siguientes errores:

Begin : Running /scripts/init-bottom ... mount : mounting /dev on /root/dev failed : No such file or directory
mount: mounting /sys/ on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed : No such file or directory
Target filesystem doesn't have requrested /sbin/init.
No init found. Try passing init= bootarg.

Intenté reparar el sistema de archivos, arranqué desde 3 LiveCDs / discos de rescate diferentes, ejecuté la reparación de arranque desde 2 dicsc diferentes. Forcé fscks ...

Realmente no tengo ideas y NECESITO que este servidor arranque al menos para poder recuperar mis bases de datos SQL. Estoy desesperado por ayuda, incluso pagaré si es necesario.

He estado al acecho en los foros durante 3 días seguidos todo el día para encontrar una posible solución y todavía estoy en el mismo punto ... ¿Ayuda por favor?


3
si son mysql db's no necesariamente necesita arrancar; en ese caso, trataría de montar el disco como esclavo y copiar sobre el directorio / var / lib / mysql
user16081-JoeT

8
Instalación limpia en nuevos dispositivos de almacenamiento. Monte la unidad anterior, transfiera los datos según sea necesario. Apuesto a que la reparación no valdrá la pena.
Zoredache

77
Este es el punto donde restaura desde la copia de seguridad. Y recuerde no correr haciendo acciones no privilegiadas como usuario root la próxima vez.
Magellan

1
because of version differences,reinstalar con la misma versión exacta. we have corruption issues,Sus datos pueden estar corruptos. Reparar el sistema para que sea de arranque, no lo ayudará si los datos han sido destruidos. Si su comando gzip comprimió los archivos de su base de datos mientras la base de datos estaba siendo usada, parece inevitable.
Zoredache

55
Si su software de base de datos se estaba ejecutando mientras ejecutaba esos comandos, es posible que no pueda recuperar las bases de datos. Gzip habría felizmente comprimido el archivo, luego lo desvinculó. Pero su software de base de datos todavía tenía el archivo abierto y estaba confirmando los cambios. Tan pronto como se detuvo, el archivo fue eliminado.
toppledwagon

Respuestas:


8

Esto dependerá de si los sistemas de archivos están reparados lo suficiente para que pueda montar esas particiones desde un LiveCD. No te molestes en intentar arrancar el sistema todavía. Primero, monte las particiones y descomprima todos los archivos .gz. Esto le dará copias de trabajo de init y binarios del sistema. Luego puede usar grub para reparar el sector de arranque. Luego, inicie en modo de usuario único y fsck el sistema de archivos nuevamente. Si eso funciona, tendrás un sistema en ejecución. También tendrá un montón de archivos descomprimidos (como páginas de manual) que realmente deberían comprimirse, pero es mejor que tener un sistema que no se pueda arrancar.

Si no puede montar las particiones desde un LiveCD, desafortunadamente no tiene suerte. Nada recuperará su sistema en ese punto.


1
Esto realmente funcionó a las mil maravillas ... ¡No puedo agradecerles lo suficiente por esto! MySQL no arrancó pero todavía no hice un --force fsck, ¡espero que lo solucione! GRACIAS
Dexirian

1
Increíble. Me alegra que haya ayudado.
Michael Martinez

9

Lo primero que probaría es ejecutar un entorno LiveCD e intentar descomprimir todo, con la esperanza de que el sistema vuelva a un estado de arranque. Nota: Me preocuparía la posible corrupción de datos si se interrumpiera el proceso original de gzip.

De lo contrario, trataría de migrar la base de datos a un nuevo sistema como lo han sugerido otros, pero como ha encontrado, puede haber problemas de dependencia y configuración intensivos en mano de obra que deberán resolverse individualmente.


Pregunta rápida: no estamos seguros del antiguo servidor de base de datos SQL, y el servidor más nuevo está utilizando una distribución de Linux diferente. El servidor más reciente ejecuta CentOS con WHM, y el servidor anterior era Debian / Unbuntu. Entonces mi pregunta es, ¿cómo puedo migrar efectivamente mis bases de datos SQL sin corrupción y otras cosas?
Dexirian

6

El consenso general aquí, de que solo debe montar el disco en un sistema que funcione y rescatar sus archivos, no está mal. Es lo más sensato que hacer. Pero la otra forma es más divertida y muy educativa. Aprendí mucho mientras luchaba para salir de situaciones desordenadas donde otras personas simplemente se habrían dado por vencidas y reinstaladas desde cero. (Sin embargo, no en un servidor del que dependen otras personas ...)

De todos modos, hasta ahora tienes un initramfs (initrd) que se ejecuta. Ese es un buen comienzo. ¿Pero no puede completar la transferencia a init porque init es ahora init.gztal vez? Para avanzar, sería útil saber exactamente qué distribución de Linux tiene, para que podamos buscar qué herramientas están disponibles en sus initramfs para uso de emergencia.

Parece que los mensajes de error que presentó podrían provenir de initramfs de Debian. Si es Debian, entonces debería haber recibido un (initramfs)indicador de shell en la siguiente línea después del último error. Si lo hiciste, deberías investigar qué sucede con esas monturas fallidas. está /root/devfaltando? ( /rootes donde se debe montar su raíz normal fs durante la ejecución de initramfs)

Si no obtuvo el indicador de shell, lo que vino después No init found. Try passing init= bootarg.será interesante. Incluso si no fuera más que un cursor parpadeante, eso es una pista. Si parece totalmente congelado, intente obtener información sobre los procesos que todavía existen utilizando magic sysrq o Ctrl + ScrollLock.

Debian initramfs también le permite solicitar un shell en algunos puntos de referencia especiales agregando un break=parámetro a la línea de comando del núcleo. Por ejemplo, para obtener un shell antes de la Running /scripts/init-bottomlínea, use break=bottom.

Aparte: no sé cómo el findcomando podría haber comprimido cada archivo ... me parece correcto con el propósito de seleccionar archivos entre 180 y 400 días de antigüedad.


Cuando hago un ls bajo / root no se encuentra nada. Entonces, ¿puedo tomarlo? ¿El montaje fs no está bien en el arranque? ¿Dónde puedo cambiarlo?
Dexirian

1
@Dexirian por lo que tuviste pronta una concha (¿ha tenido que usar break=bottom?) ... sí, en el momento en que está tratando de montar /root/devy /root/proce /root/sys, /rootdebería ser el verdadero sistema de ficheros raíz. Debe haber habido un mensaje de error anteriormente, sobre no poder montarlo. ¿Incluyó un root=parámetro en la línea de comando del núcleo? Mi memoria está un poco borrosa en este punto, pero creo que root (hd0,0)simplemente le dice a grub dónde encontrar sus archivos de soporte, y aún necesita decirle al núcleo por separado dónde está la raíz.

Sí, utilicé root =, kernel = initrd =, y setup =, no tuve que usar break = bottom. Y no vi un mensaje de montaje fallido anterior, ya que se desplaza muy rápido
Dexirian

@Dexirian ¿Está disponible el desplazamiento hacia atrás de la consola? Shift + PgUp. ¿Y puedes montarlo de (initramfs) inmediato, algo así mount -r /dev/sda1 /root? cat /proc/partitionspara ver qué discos están disponibles.

1
Bienvenido al mundo de la administración de sistemas.
Michael Martinez
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.