Time Machine ridículamente lento después de la actualización de El Capitán

Parte del problema es que las operaciones de entrada / salida (E / S) de baja prioridad ahora parecen acelerarse en gran medida. Puede verificarlo a través de la Terminal (se puede encontrar a través de Spotlight (generalmente vinculado a ⌘ Espacio ) e ingresando terminal ) luego ingresando en el indicador de bash:

fs_usage backupd

y busque las entradas THROTTLED . Si los ve, la copia de seguridad está estrangulada.

Entonces, si tiene una tonelada de archivos, solo el tiempo que lleva hacer la E / S tarda una eternidad, incluso si los archivos son pequeños (porque realiza muchas más operaciones de E / S alrededor de xattrs etc. que solía hacerlo).

Vaya a una terminal y escriba:

sudo sysctl debug.lowpri_throttle_enabled=0

Para mí, esto lo acelera de 72 horas a ~ 4 horas en un sistema de archivos con 2.5 millones de archivos.

También es una buena idea volver a habilitar la limitación después de que la copia de seguridad haya finalizado correctamente con el siguiente comando

sudo sysctl debug.lowpri_throttle_enabled=1

Confirmo que el comando:

sudo sysctl debug.lowpri_throttle_enabled=0 

funciona perfectamente.

Si desea hacerlo permanente en el reinicio, puede hacer lo siguiente.

• crea un archivo bajo /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
      <key>Label</key>
      <string>fix-el-capitan-slow-time-machine-speed</string>
      <key>ProgramArguments</key>
      <array>
        <string>/usr/sbin/sysctl</string>
        <string>debug.lowpri_throttle_enabled=0</string>
      </array>
      <key>RunAtLoad</key>
      <true/>
    </dict>
  </plist>
  

• asegúrese de que el archivo pertenece a la raíz

  sudo chown root /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist
  

• ejecute el comando

  sudo launchctl load /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist
  

Puede encontrar el contenido del archivo en este gist

Encontré este artículo en los foros de discusión de Apple sobre el mensaje que aparece en la Consola (mientras no hace nada o realiza una copia de seguridad a 10 bytes / segundo):

com.apple.backupd: Waiting for index to be ready (100)

En mi caso, pude descartar todas las copias de seguridad antiguas, así que desmonté el volumen de la problemática Mac, monté la unidad / recurso compartido de red desde otra computadora (no una Mac), eliminé todo el directorio .sparsebundle (lo que llevó un tiempo sorprendentemente largo) y luego comenzó la copia de seguridad de nuevo. Creó un nuevo .sparsebundle y ahora está realizando una copia de seguridad de aproximadamente 10 MB / seg.

Si no desea eliminar sus copias de seguridad existentes, puede probar una de las otras sugerencias en esa página:

• reiniciar en modo seguro y luego volver a la normalidad;
• diga a Spotlight que no indexe el volumen / disco de Time Machine;
• eliminando el índice de Spotlight, .Spotlight-V100 (que no tenía);
• usando mdutil para deshabilitar y volver a habilitar la indexación de Spotlight en el volumen:
  • sudo mdutil -i off /Volumes/Time\ Machine\ Backups
  • sudo mdutil -i on /Volumes/Time\ Machine\ Backups

(vea esa discusión para obtener más detalles e ideas).

Después de mudarme a El Capitán, tuve problemas similares: las copias de seguridad (incluso las pequeñas incrementales) se redujeron a un rastreo real. Así que hice un volcado de la charla entre Mac y NAS, y vi numerosas solicitudes fallidas de FPGetFileDirParms. AFP es (¿era?) La máquina de tiempo de protocolo que se usa para hablar con las unidades NAS, pero he leído que se están mudando a SMB.

174 0.390744    192.168.0.9 192.168.0.10    AFP 107 FPGetFileDirParms request: Vol=3 Did=62779 Name=._1b6c
176 0.391729    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object not found (-5018)[Malformed Packet]
178 0.392002    192.168.0.9 192.168.0.10    AFP 101 FPGetFileDirParms request: Vol=3 Did=93632
179 0.392909    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object is the wrong type (-5025)[Malformed Packet]

No tengo ni idea de por qué fallaron estas solicitudes, pero el número de estos intentos fallidos es GRANDE: los datos reales transferidos son minúsculos en comparación con la cantidad de solicitudes fallidas, y por lo tanto la velocidad es lenta y constante.

Lo que funcionó para mí fue:

1. Fui a Time Machine Preferences- > Select Disk y quité el disco asociado actualmente (que estaba conectado a afp: //MyBookLive.local/TimeMachine)
2. Fui a Finder- > Go- > Connect to Server. Escribí la dirección IP de la unidad NAS en el espacio "Dirección del servidor" (smb: //192.168.0.10 para mí)
3. Conectar. Lanzé una lista de volúmenes para montar: elegí el volumen usado para Time Machine (TimeMachine para mí). TimeMachine se montó en / Volúmenes.

4. Desde la terminal, corrió:

   sudo tmutil setdestination /Volumes/TimeMachine
   

Eso es todo. La máquina del tiempo ahora está asociada con / Volumes / TimeMachine en lugar de afp: //MyBookLive.local/TimeMachine. Las copias de seguridad anteriores eran buenas, y las copias de seguridad incrementales que ocurrieron después de esto han sido RÁPIDAS. Un volcado de Wirehark que hice después de esto no mostró solicitudes de AFP fallidas (aunque AFP aún era el protocolo que se estaba usando).

No pude solucionar el problema, sin embargo, descubrí que mi máquina del tiempo se ralentiza cuando realiza copias de seguridad de los datos de otros usuarios (no ha iniciado sesión en uno). Podría haber algún problema con el permiso existente en los archivos de la carpeta de otros usuarios. Cuando agregué a ese usuario a la lista de excepciones, TM oscila.

Relacionado con la respuesta de Daniel Berlin, arriba (pero soy nuevo aquí, así que no tengo suficiente credibilidad para simplemente comentar allí), encontré que su comando de terminal funcionó EXCELENTE para mí en OSX 10.11.3. ¡Convirtió la copia de seguridad de 30 horas en 4 horas! Sin embargo, no permanece después de un reinicio.

No quería tener que escribir en el terminal cada vez que reinicio, así que ...

Como no estoy muy versado en los scripts de shell, busqué en Google lo suficiente como para crear un flujo de trabajo de Automator que solicite al usuario que ingrese la contraseña de root y luego ejecute el comando del terminal. Elegí confirmar el éxito con una alerta del centro de notificaciones.

Guardé el flujo de trabajo como una aplicación y lo agregué a mis elementos de inicio de sesión. Así que ahora, con cada inicio de sesión, se me solicita que ingrese mi contraseña nuevamente para "desacelerar" la Máquina del Tiempo.

Hay formas de hacer que el proceso sea invisible con los scripts de shell, pero es un poco complicado necesitar el acceso a la raíz obtenido por el comando sudo. Uno también podría incluir la contraseña dentro de la aplicación Automator si no le preocupa la seguridad. (No lo recomiendo.)

Publicaré la aplicación de flujo de trabajo aquí, pero aparentemente no puedo cargar un archivo a esta respuesta. Así que adjuntaré un jpg para que cualquiera pueda recrearlo si lo desean. PD Nota la entrada de paso "como argumento" para el script de shell

Mi problema se solucionó con el artículo de DWHoard: reinicie en modo seguro, luego retroceda (para mí , la computadora pareció apagarse durante el arranque seguro).

Macbook Air a mediados de 2011, OS X 10.11.3, retrocediendo a Time Capsule.

Editar: En realidad, parece que después del inicio seguro & arranque normal, Time Machine solo llegó a aproximadamente 41 / 55GB (dentro de una hora) y se volvió a rastrear (ha progresado solo en 2,75GB en 12 horas desde entonces. Muy mal: compré la Time Capsule simplemente para evitar este tipo de incompatibilidades y Aquí estoy: todos los dispositivos Apple y una pésima experiencia, una pérdida de tiempo. Espero que otros encuentren una solución duradera.

La consola está obteniendo una nueva entrada para mdworker cada segundo. ¿Esto es normal mientras se realiza la copia de seguridad?

Edit 2: Exitoso! La computadora portátil tiene dos cuentas de usuario y puede ser que el inicio de sesión en la segunda haya provocado el resto de las copias de seguridad. Vale la pena probar si estás en una situación similar.

Tengo el mismo problema, y encontré lo que parece una solución (no es maravilloso, pero funciona)

  

formatee su disco duro externo y verifique que tenga un buen ancho de banda real (pruebe su usb3)   Preste atención a la configuración de TM. Aquí, olvidé tantas otras particiones e imágenes de disco que no quiero hacer una copia de seguridad, esto aumentaría el tiempo de bck.   Inicia la primera copia de seguridad.   CADA 2-3 horas, reinicie su computadora (sí, no es divertido, pero me di cuenta de que la primera hora suele ser rápida, y después de esta hora se vuelve más lenta)   eso es todo, pude hacer una copia de seguridad de 1,5 a una mañana ..

Consulte esta nota de Apple :

  

OS X El Capitán: si Time Machine es lento

     

Prueba estas sugerencias si Time Machine es lento.

     

• La primera vez que uses Time Machine, configúralo por la noche para que la copia de seguridad inicial se pueda hacer durante la noche.

  

• Si su disco de copia de seguridad es una Time Capsule, deje su Mac en la misma sala que la Time Capsule para la copia de seguridad inicial, o use un cable Ethernet para conectar su Mac a uno de los puertos Ethernet de la Time Capsule. .

  

• El software de detección de virus puede hacer que las copias de seguridad de Time Machine sean muy lentas. Si usa Norton AntiVirus o un producto similar, intente excluir su disco de respaldo del escaneo automático. Asegúrese también de que está ejecutando la última versión del software de detección de virus.