Tengo un sparsebundle creado por Time Machine (HFS+) que reporta los siguientes límites al usar hdiutil resize -limits
:
min cur max
403186088 403186088 34359738368
Eso es un tamaño actual de 206 GB y un máximo de 17,5 TB . Llego a la conclusión de que no necesito hdiutil resize
el sparsebundle para permitir su expansión. El volumen anfitrión tiene 200 GB adicionales libres, por lo que el paquete debería poder expandirse aproximadamente al 100%:
- La utilidad de disco indica que el espacio libre es de 1 GB
- Time Machine informa que el espacio libre es de 1 GB
Esperaba que detectaran 200 GB de espacio libre disponible en el volumen del host. Esto es un problema ya que Time Machine empezará a borrar las copias de seguridad antes de tiempo.
¿Cómo puedo hacer que el sparsebundle se expanda cuando sea necesario para llenar el espacio disponible en el sistema de archivos del host?
Algunas preguntas adicionales que surgieron y que podrían ayudar a acotar el tema:
- ¿Qué parte del sistema es responsable de ampliar el paquete ¿cuándo es necesario? ¿Hace esto Time Machine explícitamente o lo hace de forma transparente por debajo de él? Es decir, ¿es un problema de Time Machine o de algo más fundamental?
- ¿Hay algo más forma fiable de comprobar si Time Machine se ha quedado/se quedará sin espacio que mirar la cifra de "espacio libre" en los ajustes de Time Machine? Es decir, ¿se puede confiar en las cifras? He eliminado y añadido el paquete como destino de la copia de seguridad con
tmutil setdestination
antes de comprobar el espacio libre. - Si Time Machine se encarga explícitamente de expandir un sparsebundle utilizado como destino de la copia de seguridad, ¿sólo lo hará cuando él mismo monte el sparsebundle como un paso de una copia de seguridad en red ? En otras palabras, al tomar la unidad en red y conectarla localmente con USB3, y luego montar manualmente el sparsebundle, ¿podría Time Machine simplemente omitir el paso en el que normalmente expande el objetivo del sparsebundle, ya que el paquete se considera ahora almacenamiento local (que generalmente no utiliza sparsebundles)?
MacOS Mojave 10.14.6
Actualización
Hay varias razones sutiles que se combinan en por qué creo que mi sparsebundle no se expande automáticamente, y por qué formé la hipótesis nula de que el espacio libre reportado por Time Machine no es erróneo. Ellos incluyen:
- No tengo ninguna buena razón para suponer que el número reportado en Time Machine y en la interfaz de la Utilidad de Discos sea erróneo. Por el contrario, no me han dado ninguna garantía explícita de que el volumen de destino se expandirá, ni en qué medida.
- Según recuerdo, Time Machine ya ha fallado anteriormente en ampliar el objetivo de sparsebundle en el que estaba haciendo la copia de seguridad, a pesar de tener mucho espacio disponible en el volumen anfitrión.
- El historial de diseño de Apple me sugiere que si sólo expusieran una única cifra (espacio restante disponible) en la interfaz de usuario de Time Machine para que yo basara mis decisiones con respecto a las acciones que tomará TM a su vez, ya la habrían eliminado si fuera una cifra poco fiable. No considero que el uso de sparsebundles (es decir, la copia de seguridad en red) sea un caso tan pequeño como para justificar que se ignore ese nivel de falta de fiabilidad en su fase de diseño de la UI.
- Cuando la unidad se utiliza como objetivo de red, TM parece informar de ~200/400 GB disponibles, mientras que conectada como objetivo de copia de seguridad local informará de ~200/200 GB disponibles. Un sparsebundle montado localmente tampoco aparece en la interfaz de usuario "add target" en TM, sino que tiene que ser añadido usando
tmutil
. Esto sugiere una incoherencia en el manejo de los objetivos de las copias de seguridad y que Time Machine gestiona los sparsebundles explícitamente.
Me doy cuenta de que esto no es concluyente, así que lo probé:
- Monté el volumen del host a través de USB, y procedí a redimensionar el sparsebundle con
hdiutil
para que fuera tan pequeño como pudiera hacerlo, de modo que pareciera tener ~20 GB libres según todas las herramientas de la interfaz gráfica del sistema. Se redujo en más de 100 GB en ese sentido, por lo que hay mucho espacio de sobra en el volumen anfitrión. - Monté el paquete como un volumen local, y procedí a copiar un archivo Xcode.xip de 11 GB en él dos veces.
- La primera transferencia tuvo éxito.
- La segunda transferencia falló incluso antes de empezar: "no hay suficiente espacio libre". Se necesitaban 1,54 GB de espacio adicional. Esto era de esperar.
- Conclusión: el sparsebundle no se expandió de forma transparente, a pesar de tener más de 100 GB de espacio libre en el volumen anfitrión. No hay ninguna razón para creer que la cifra que informa Time Machine sea errónea, ni que el volumen se expanda de forma transparente durante el funcionamiento de TM.