Reparación de la máquina de tiempo que no se montará

Tengo un informe sobre cómo probar y reparar los errores sparsebundle basados en NAS en mi blog . En resumen:

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

   Entonces verás algo como

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

   Donde x es la identificación del disco para el disco externo. x puede ser 2, 3, 4 o mayor. Usted está interesado en el etiquetado Apple_HFSX o Apple_HFS.

2. fsck_hfs -drfy /dev/diskxs2 usando cualquier dispositivo relevante ubicado en el Paso 1.

   Con suerte, eventualmente verás

     

   El volumen fue reparado exitosamente

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 no supere su verificación. Incluso si el proceso anterior logra recuperar la copia de seguridad, es posible que aún deba eliminar las marcas negras que escribió Time Machine cuando falló la verificación.

4. Desbloquear el sparsebundle

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

5. Moverlo de nuevo a su ubicación 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 ten cuidado, es posible que el regazo se haya protegido porque realmente está roto.

No es tan simple como chmod. Primero, aparece que 10.5 / 10.6 / 10.7 tienen pequeñas diferencias en cómo se maneja un paquete disperso. En segundo lugar, las banderas y el estado sucio / malo de un paquete disperso se almacenan en otra parte. En tercer lugar, es posible que deba atacar el paquete disperso en sí mismo, no el sistema de archivos que contiene.

Su mejor opción es permitir que la Utilidad de Discos se tome un momento para reparar la imagen antes de mirar el sistema de archivos integrado. Funciona tanto en el paquete como en los sistemas de archivos, y también sabe cómo Apple ha almacenado las cosas.

Los detalles del paquete son de propiedad exclusiva o difíciles de distinguir de los documentos del desarrollador, y ciertamente no es algo que otras utilidades de terceros estén dispuestos a solucionar en este momento. Siempre y cuando esté utilizando una versión igual o más nueva de la Utilidad de Discos que la mac que realizó las copias de seguridad, debería estar bien. Una vez que hayas renunciado a la Utilidad de Disco, puedes probar algo como Drive Genius o Disk Warrior, pero me quedo con la herramienta de Apple si deseas reutilizar este paquete.

La naturaleza de los paquetes dispersos, específicamente los enlaces duros y 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 aún no he completado un pase de reparación en un archivo con un tamaño de 800 MB.

En la práctica, quizás sea mejor volver a una versión anterior de su NAS si tiene instantáneas o si se hace una copia de seguridad. Al final, si hay errores que fsck / Disk Utility no puede solucionar, su conjunto disperso se marcará como incorrecto y se bloqueará. Luego puedes leer cosas, pero nunca escribirlas de nuevo. Verifique si puede conectar una máquina al almacenamiento y arreglar cosas (el DAS o las conexiones de alta velocidad son mejores, ya que es una máquina que puede tener el tiempo para arreglar las cosas y no reiniciarse, lo ideal)

La mejor de las suertes: es posible que esto no se pueda recuperar de los detalles que proporcionó.

Tengo un NAS de Syology y recibí el error NO-WRITE al intentar ejecutar la revisión, pero encontré esta versión modificada que me salvó el tocino.

enlace

Si realiza una copia de seguridad de una imagen de disco de paquete disperso en una máquina e intenta abrirla en otra, puede aparecer el mensaje de error "no hay sistemas de archivos que no se pueden montar", 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 ejecutarlo

sudo chown -R MyUserName nonmounting.sparsebundle

en él.

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

Realicé todos los pasos anteriores, pero después de un tiempo la imagen no se pudo reparar usando fsck_hfs o hdutil, muchos errores relacionados con subprocesos o nodos dañados.

Lo que funcionó para mí fue:

1. (Opcional) Conecte una unidad USB externa de 1TB con formato HFS Jornaled.

2. (Opcional) En Airport Utility, vaya a Time Capsule Disks - > Archivar el disco en la unidad conectada a Time Capsule por USB. Esto me llevó 12 horas para 600 GB.

3. hdiutil attach -nomount -noverify -noautofsck     /Volumes/DISK/MyFile.sparsebundle

4. Entonces el disco fue visible usando DiskWarrior . En la pestaña Directorio, haga clic en Reconstruir . Tomó aproximadamente 1 hora.

Una vez arreglado, finalmente pude montar y hacer una copia de seguridad de mis archivos.

La respuesta de @ Garth no funcionó para mí. Tuve que agregar la opción -readwrite a hdiutil para que funcione con mi imagen encriptada. Sin esa opción, hdiutil no solicita la contraseña.

En el paso fsck, encontré un Disk full error . Para solucionarlo, utilicé la opción resize para ampliar el tamaño de la imagen antes de ejecutar fsck.

Aquí están los comandos que usé para solucionarlo:

# chflags -R nouchg MyImage.sparsebundle

# hdiutil attach -nomount -noverify -readwrite -noautofsck MyImage.sparsebundle
Enter the password to access „MyImage.sparsebundle“: 
/dev/disk2              GUID_partition_scheme           
/dev/disk2s1            EFI                             
/dev/disk2s2            Apple_HFS                       

# hdiutil resize -size 1.5t MyImage.sparsebundle
Enter the password to access „MyImage.sparsebundle“: 

# fsck_hfs -drf /dev/disk2s2
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
** Rebuilding catalog B-tree.
…

# hdiutil detach /dev/disk2s2

Como se explica en las otras respuestas, la ruta del dispositivo puede variar, por lo que en lugar de disk2s2 , debe usar el disco impreso por el comando hdiutil attach . Además, solo necesita el paso resize si obtuvo el Disk full error al ejecutar el comando fsck_hfs . Además, en lugar de mi 1.5t , debe ingresar un tamaño nuevo razonable que sea un poco más grande que el tamaño de su imagen actual (verifique con du -hs MyImage.sparsebundle ).

Esto me funcionó:

• Haga clic derecho en la imagen del disco, cambie "Todos" para leer y escribir.
• Terminal abierta
• chmod -R 777 {disk image path}

Aparentemente era un problema de permisos.

NOTA: ESTO HACERÁ ACCESO A SU RESPALDO PARA CUALQUIERA QUE TENGA ACCESO FÍSICO A ELLO

Acabo de tener el mismo problema

** /dev/rdisk2s2 (NO WRITE)

cuando se trata de arreglar un buje de TM con un currupted en un QNAP 419II.

"Expulsé" el montaje TM utilizando Finder y ejecuté

hdiutil attach -nomount -noverify -noautofsck ...

comando (se encuentra aquí Corrección Time Machine Sparsebundle NAS Based Backup Errors ) otra vez, que (a diferencia de la primera ejecución con la que imprimió "/ dev / disk2s2 Apple_HFSX") esta vez dio

/dev/disk1s2            Apple_HFSX  

Comprobando el sys-log con

tail -f /var/log/fsck_hfs.log

No se mostró

/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 TM todavía resultó en un mensaje de copia de seguridad corregido :(

¡Buena suerte!