Reparar el sparsebundle de Time Machine que ya no se monta

Tengo un escrito sobre cómo tratar de reparar los errores de sparsebundle basado en NAS en mi blog . En resumen:

1. hdiutil attach -nomount -noverify -noautofsck /Volumes/{name of your disk}/{name of}.sparsebundle

   Entonces verá algo como

   /dev/diskx Apple_partition_scheme
   /dev/diskxs1 Apple_partition_map
   /dev/diskxs2 Apple_HFSX

   Dónde x es el identificador del disco externo. x puede ser 2, 3, 4 o superior. Te interesa el que está etiquetado como Apple_HFSX o Apple_HFS.

2. fsck_hfs -drfy /dev/diskxs2 utilizando cualquier dispositivo relevante que se haya localizado en el paso 1.

   Esperemos que con el tiempo vea

   El volumen fue reparado con éxito

3. hdiutil detach /dev/diskxs2

Sin embargo, desde OS X 10.6.3, Time Machine se negará a escribir en un volumen de destino que falle su verificación. Incluso si el proceso anterior consigue recuperar la copia de seguridad, es posible que tengas que eliminar las marcas negras que Time Machine escribió cuando falló la verificación.

4. Desbloquear el paquete disperso

   chflags -R nouchg /Volumes/{name of your disk}/{name of}.sparsebundle

5. Volver a colocarlo en su lugar original

   mv /Volumes/{name of your disk}/{name of}_YYYY-MM-DD.sparsebundle /Volumes/{name of your disk}/{name of}.sparsebundle

6. En el directorio de nivel superior del sparsebundle, edite el archivo com.apple.TimeMachine.MachineID.plist .

   • Eliminar

     <key>RecoveryBackupDeclinedDate</key>
     <date>{whatever-the-date}</date>

   • Cambiar

     <key>VerificationState</key>
     <integer>2</integer>

     a

     <key>VerificationState</key>
     <integer>0</integer>

Los atributos extendidos en el sparsebundle pueden estar impidiendo las escrituras en el archivo:

Ejecutar

chflags -R nouchg flattop.sparsebundle

Pero cuidado, el sparsebundle puede haber sido protegido porque realmente está roto.

No es tan simple como chmod. En primer lugar, es aparece que 10.5 / 10.6 / 10.7 tienen pequeñas diferencias en el manejo de un paquete disperso. Segundo, las banderas y el estado dirty/bad de un sparse bundle se almacenan en otro lugar. En tercer lugar, es posible que tenga que atacar el propio paquete disperso, no el sistema de archivos que contiene.

Lo mejor es dejar que la Utilidad de Discos repare la imagen antes de mirar el sistema de archivos que contiene. Funciona tanto en el paquete como en los sistemas de archivos, además de saber cómo ha almacenado Apple las cosas.

Los detalles del paquete son propiedad o son difíciles de discernir en los documentos del desarrollador, y ciertamente no es algo que otras utilidades de terceros estén dispuestas a arreglar en este momento. Mientras estés usando una versión igual o más nueva de Disk Utility que la del mac que hizo las copias de seguridad, deberías estar bien. Una vez que hayas renunciado a la Utilidad de Discos, podrías probar algo como Drive Genius o Disk Warrior, pero yo me quedaría con la herramienta de Apple si esperas reutilizar este paquete.

La naturaleza de los paquetes dispersos - específicamente los enlaces duros, así como el concepto de que no se compacta cuando se eliminan los archivos, hay un mucho trabajo por hacer . He tenido DiskUtility ejecutado durante dos semanas y todavía no ha completado un pase de reparación en un archivo de 800MB de tamaño.

En la práctica, podría ser mejor volver a una versión anterior de su NAS si tiene instantáneas o se hace una copia de seguridad de sí mismo. Al final, si hay errores que fsck/Disk Utility no puede solucionar, su paquete disperso se marcará como malo y se bloqueará. Entonces podrás leer cosas, pero no podrás volver a escribir en él. Vea si puede conectar una máquina al almacenamiento y arreglar las cosas (las conexiones DAS o de alta velocidad son mejores - así como una máquina que pueda tener el tiempo para arreglar las cosas y no ser reiniciada es ideal)

Mucha suerte: es posible que no se pueda recuperar a partir de los datos que has proporcionado.

Si haces una copia de seguridad de una imagen de disco de paquete disperso en una máquina e intentas abrirla en otra, puedes obtener el mensaje de error "no hay sistemas de archivos montables", especialmente si los nombres de usuario de los propietarios difieren entre las dos máquinas.

Mi solución fue copiar el paquete en mi disco local y ejecutar

sudo chown -R MyUserName nonmounting.sparsebundle

en él.

Después de eso se abrió bien y todo estaba bien con el mundo.

Acabo de tener el mismo problema

** /dev/rdisk2s2 (NO WRITE)

cuando se trata de arreglar un TM-sparsebundle dañado en un QNAP 419II.

He "expulsado" el TM-mount usando Finder y he ejecutado

hdiutil attach -nomount -noverify -noautofsck ...

(que se encuentra aquí) Solucionar los errores de las copias de seguridad basadas en el NAS de Time Machine Sparsebundle ) de nuevo, que (al contrario de la primera ejecución con la que imprimió "/dev/disk2s2 Apple_HFSX") esta vez dio

/dev/disk1s2            Apple_HFSX  

Comprobación del sys-log con

tail -f /var/log/fsck_hfs.log

No se ha mostrado

/dev/rdisk1s2: fsck_hfs run at Sun Feb 17 17:53:20 2013
/dev/rdisk1s2: ** /dev/rdisk1s2
/dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-540.1~34).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
... LOTS-OF-OUTPUT ...
QUICKCHECK ONLY; FILESYSTEM CLEAN

Sin embargo, la reactivación de la TM sigue dando lugar a un mensaje de copia de seguridad curreta :(

Buena suerte.