Papelera movida y otras carpetas! ¿Cómo recuperarlos?

Si aún tiene un shell raíz, es posible que tenga la oportunidad de reparar su sistema. Digamos que movió todos los directorios comunes (/bin , /etc , /lib , /sbin , /usr — estos son los que podrían dificultar la recuperación) en /oops .

No podrá emitir el mv comando directamente, incluso si especifica la ruta completa /oops/bin/mv . Eso es porque mv está vinculado dinámicamente; porque has movido el /lib directorio, mv no puede ejecutarse porque no puede encontrar las bibliotecas que constituyen parte de su código. De hecho, es incluso peor que eso:mv no puedo encontrar el cargador dinámico /lib/ld-linux.so.2 (el nombre puede variar dependiendo de su arquitectura y variante de Unix, y el directorio podría tener un nombre diferente, como /lib32 o /lib64 ). Por lo tanto, hasta que haya movido el /lib directorio de nuevo, debe invocar el enlazador explícitamente y debe especificar la ruta a las bibliotecas movidas. Aquí está el comando probado en Debian squeeze i386.

export LD_LIBRARY_PATH=/oops/lib:/oops/lib/i386-linux-gnu
/oops/lib/ld-linux.so.2 /oops/bin/mv /oops/* /

Es posible que deba ajustar esto un poco para otras distribuciones o arquitecturas. Por ejemplo, para CentOS en x86_64:

export LD_LIBRARY_PATH=/oops/lib:/oops/lib64
/oops/lib64/ld-linux-x86-64.so.2 /oops/bin/mv /oops/* /

Cuando has estropeado algo /lib , ayuda tener una caja de herramientas enlazada estáticamente por ahí. Algunas distribuciones (no sé sobre CentOS) proporcionan una copia vinculada estáticamente de Busybox. También hay sash, un shell independiente con muchos comandos integrados. Si tiene uno de estos, puede hacer su recuperación desde allí. Si no los ha instalado antes, es demasiado tarde.

# mkdir /oops
# mv /lib /bin /oops
# sash
Stand-alone shell (version 3.7)
> -mv /oops/* /
> exit

Si ya no tiene un shell raíz, pero todavía tiene un demonio SSH escuchando y puede iniciar sesión directamente como raíz sobre ssh, y tiene una de estas cajas de herramientas vinculadas estáticamente, es posible que pueda ingresar ssh. Esto puede funcionar si ha movido /lib y /bin , pero no /etc .

ssh [email protected] /oops/bin/sash
[email protected]'s password:
Stand-alone shell (version 3.7)
> -mv /oops/* /

Algunos administradores configuran una cuenta alternativa con un shell vinculado estáticamente, o hacen que la cuenta raíz use un shell vinculado estáticamente, solo para este tipo de problemas.

Si no tiene un shell raíz y no ha tomado precauciones, deberá arrancar desde un CD/USB en vivo de Linux (cualquiera funcionará siempre que sea lo suficientemente reciente como para poder acceder a sus discos y sistemas de archivos) y mover los archivos hacia atrás.

Probablemente pueda recuperarse sin reiniciar, así que no reinicie hasta que haya probado otras cosas porque no se iniciará. Si aún tiene su sesión SSH abierta, pruebe con estos:

• El lugar desde donde se ejecutan los programas se establece mediante la variable $PATH. Puede agregar su nueva ubicación de contenedor a la ruta ejecutando export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin" . Es posible que deba agregar el sbin correspondiente directorios también. También puede ejecutar programas manualmente a través de su ruta completa /path/to/mv [from] [to] por ejemplo, debería funcionar incluso si mv está en una ubicación diferente. La parte complicada es que la mayoría de los comandos querrán acceder a bibliotecas comunes y dices /lib se movió, por lo que también debe establecer una variable para dónde está eso. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/lib

• Una vez que pueda ejecutar algunos comandos básicos, ¡mueva las cosas hacia atrás! mv /path/to/subfolder/* / estaría en orden! Una vez que todo esté en su lugar, el sistema debería comportarse normalmente.

Si eso falla, iniciar CUALQUIER LiveCD y montar la unidad debería permitirle mover las carpetas a donde pertenecen. No necesita volver a instalar o incluso usar su distro livecd, solo necesita montar la unidad y mover las carpetas a la ubicación correcta en el disco. Muchos discos de rescate basados ​​en Linux se especializan en brindarle solo algunas herramientas básicas de consola para realizar este tipo de reparación.

Debería poder reiniciar la computadora con un CD de instalación en modo de usuario único, montar el sistema de archivos raíz y volver a mover los archivos a Linux. No conozco mucho centos, pero es como RHEL, así que esto debería funcionar.