El Capitan, no puede rsync, tar, cp ciertos archivos en Promise raid

En primer lugar: Soy un administrador de Linux, pero tengo que hacer algunas cosas de MacOS en el lugar (tenía muy poca exposición a ella anteriormente).

Una de las tareas que tengo es hacer una copia de seguridad de un array Promise Pegasus2 de 10TB conectado a un mac-mini con el capitan 10.11.4.

Soy Root en el mac (sudo -i desde la cuenta de administrador).

Estoy tratando de rsync los datos de la matriz a un servidor de copia de seguridad con un amplio almacenamiento (una caja de Linux). Todo fue muy bien hasta que el proceso llegó a cierto archivo de 52MB - en ese simplemente se "atasca". No hay tiempo de espera, no hay error, nada.

Los permisos/banderas tienen este aspecto:

ls -leO@  CCCBB15A-5DA6-433F-BD37-001CB6151E08.key
-r--r--r--@ 1 user  staff  compressed 54994229 17 Sep  2015 CCCBB15A-5DA6-433F-BD37-001CB6151E08.key
    com.apple.finder.copy.source.checksum#N        4 
    com.apple.genstore.info       91 
    com.apple.genstore.orig_perms_v1           1 
    com.apple.genstore.origdisplayname        31 
    com.apple.genstore.origposixname          31 
    com.apple.iwork.documentUUID#PS       16 
    com.apple.metadata:_kTimeMachineNewestSnapshot        50 
    com.apple.metadata:_kTimeMachineOldestSnapshot        50 
    com.apple.quarantine          22 
 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown

¿Cuál de ellos es el responsable de que Root esté "atascado"? :)

Y, lo que es más importante, ¿qué tengo que hacer para que se "despegue"?

Edit1: Y esto es lo que hace (indefinidamente, por lo que parece) ... dtruss usado.

stat64("Backups.backupdb/Chiltepin/2016-01-22-164610/Macintosh HD/.DocumentRevisions-V100/PerUID/502/24c/com.apple.documentVersions/805FC10B-F41B-4825-A0EB-41BE7505E79B.key/preview-micro.jpg\0", 0x7FFF5DEF6A08, 0x1000)       = 0 0
lstat64("Backups.backupdb/Chiltepin/2016-01-22-164610/Macintosh HD/.DocumentRevisions-V100/PerUID/502/24c/com.apple.documentVersions/805FC10B-F41B-4825-A0EB-41BE7505E79B.key/preview-web.jpg\0", 0x0, 0x0)      = 0 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0
read(0x3, "\0", 0x40000)         = 262144 0

No es un ritmo rápido, parece que lo intenta una vez cada 15 segundos.

Edición 2: La saga continúa. Probé con bsdtar y gnu tar (instalados a través de homebrew) para generar una bola tar local de los volúmenes de la matriz Promise. Esos procesos, también, se atascan, típicamente en archivos dentro de Backups.backupdb que parecen ser datos de TimeMachine? Siempre es un archivo con la extensión .key. ¿Hay alguna forma de copiarlos? Asumo que es una cosa de privilegio ya que la Utilidad de Discos -> Primeros Auxilios no mostró ningún problema con el sistema de archivos.

Edición3 : Sigo sin entender por qué un simple cp de los archivos que están actuando w / cualquier otro medio funciona, pero que parece ser el statu quo. Crear una imagen del dispositivo en cuestión parece haber funcionado, también. No estoy seguro de que //restaurar// desde esa imagen funcione, sin embargo ... suspiro